In 2023, we received more than 1,300 applications from engineers. We hired only 2% of them. While being so picky is time and resource-consuming, it pays off big time. When hiring only the most desirable candidates, our team can tackle tough challenges, adapt to changing markets, and drive growth while creating fantastic products with millions of users worldwide. What do we mean by “the most desirable candidates”? Where and how do we look for candidates? What does the hiring process look like? Keep reading to find out!
Engineer’s profile we’re looking for
At Railsware, we try to automate and streamline as many processes as possible. Creating clear guidelines and detailed descriptions of who we’re looking for helps us narrow the focus to the most suitable candidates. Here are the primary traits we expect our candidates to have:
- Strong general programming knowledge. We want candidates to have an engineering background and a strong understanding of basic and key programming principles. This helps them learn new languages, libraries, and frameworks faster.
- Full-Stack engineers with experience in TDD. The main goal for all specialists at Railsware is to create products, not to write lines of code. We expect engineers to have knowledge of both Back and Frontend technologies to have a holistic picture of how a product should look like, make their own decisions, and work autonomously with minimal blockers and bottlenecks. Developers at Railsware have to write reusable and maintainable code and cover it with tests.
- Decent commercial experience. We’ve noticed that candidates with less than 4+ years of commercial experience rarely pass our test task and interviews.
- Good level of spoken and written English. Our team members live in more than 25 countries all across the globe, and our official language is English. Without at least an upper-intermediate level and ability to clearly express thoughts and ideas, a person will not be able to comprehend all the information shared in meetings and other events.
- Passion for what they do. We are looking for people who are passionate about programming and problem-solving and want to constantly grow in this domain. To detect such traits, we ask candidates if they have pet projects and if they participate in conferences, hackathons, etc.
- Maturity and proactivity. By maturity, we mean skills and traits like ownership, prioritization, planning, meeting deadlines, structuring work, getting things done, diligence, reliability, and attention to detail. We want engineers to be comfortable taking the lead on projects and working without lots of oversight. Engineers at Railsware actively contribute to the identification of problems and their solutions and collaborate in a cross-functional team to ensure the project meets business objectives and compliance standards while working independently in a flat-structured company.
The hiring process
Our standard process has several key stages. Each stage serves to assess different aspects of candidates’ skills and fit for our team.
Sourcing while building long-term relationships
Our hiring flow starts with sourcing and goes far beyond posting job openings. It means actively reaching out to find and attract potential candidates who may not even be looking for jobs at the moment. We try to build long-term relationships. Each person in the hiring process is an ambassador for our company culture. They demonstrate our values to candidates. Creating a great candidate experience at each recruitment step is very important for us as it can leave a lasting impression.
Apart from job seekers who apply via our website, we usually search for candidates on Linkedin, GitHub, Stack Overflow, job boards in different countries, etc. Once we get an application, we carefully review it using the engineer’s portrait and strive to respond within a maximum of 2 working days.
Application process
After screening a CV, our recruiters conduct Intro Calls with candidates. These calls aim to assess candidates’ behavior, motivation, and career expectations. This stage gives us insight into cultural alignment and lets us find any initial red flags.
Test Task
The test task is a usual step for us as it helps check the general programming knowledge of candidates and their diligence and desire to join the team.
We use an assessment platform for a test task. It offers well-drawn-up exercises to check proficiency in the languages we are hiring for and records the process of the task completion. When watching the play-back, our engineers track the candidate’s thinking process and assess their problem-solving approach. Candidates advance to the next stage only if they master 100% of the tasks without copying or seeking outside help. Usually, it takes 1 to 1.5 hours for senior engineers and 2 to 2.5 hours for middle-level engineers to complete a test task.
Aleksandr Kunin
Full Stack Engineer
The fastest candidate I’ve met finished the test task in just 2 minutes. Obviously with the help of a Chat GPT. For me, it means ChatGPT is more proficient. Candidates either show their own skills or the lack of them.There are many ways to complete the test task. I’m looking for a solution that took minimal time but allowed for creating beautiful, neat code. I want to learn from those playbacks.
Railsware Pair Interview (RPI)
RPIs are the first technical filter in the hiring process where a candidate meets one of the Railsware engineers.
Usually, the session takes 1.5 hours. The candidate and an interviewer work on a given task in a pair programming fashion. The interviewer takes the role of a driver (writes the code), and the candidate takes a navigator role (tells the driver what to write, argues their decisions, and raises awareness of potential pitfalls along the way). We also ask for a Test Driven Development approach to the solution, so the flow matters a lot in the final evaluation.
Catalin Baciu
Full Stack Engineer
Personally, I find the RPI task useful in determining what kind of a developer our candidate is and consider it a relevant step in the hiring process, but I am aware that this opinion is contested.The argument I hear most often against the RPI task is that the task is no more than a toy app and it doesn’t test real-world programming skills. While I agree that the end result of the session is little more than a dummy data structure, I disagree that the flow itself doesn’t assess the candidate’s real-world approach to development.One shouldn’t underestimate the work done through pairing; the conversations and debates during these 1.5 hours are crucial. If a test starts failing along the way and the candidate’s decision is to alter the test to meet the implementation (instead of the other way around) or remove that assertion altogether, I immediately spot it as a major red flag. Or maybe a candidate chooses a less optimal solution in a specific context, but they mention better approaches and argue why they chose one over the other in a convincing manner. Then we know that the candidate’s knowledge is broader than the written final solution, and they could make better decisions if only they had more context.
During the activity, we want to assess the general problem-solving skills of candidates, their thinking patterns, balance on the over-engineering, loose implementation axis, testing and refactoring abilities, as well as their stress management and communication skills.
Catalin Baciu
Full Stack Engineer
Communication is of most importance, though. The interviewer is doing the coding, but the candidate must do the talking for that to happen, so they must state their intentions clearly. We discuss at least three potential solutions before writing down a final one, which helps both the interviewer and candidate understand each other better and contribute to the final question – if we are a match!
Full-day interview
Our Full Day Collaboration sessions are carefully designed to copy the typical working day of an engineer. They give us valuable insights into candidates’ work approaches, attitudes, and proactiveness. Given our emphasis on technological depth, the scope often spans both Frontend and Backend tasks.
During these sessions, we focus on evaluating the candidate’s working style. We look at how much help they need, their productivity, and the neatness and accuracy of their code.
Serhiy Yefremenko
Full Stack Engineer
I personally prefer full days much more than usual interview approaches, both as an interviewer and as a former job seeker. Working on an actual task in real time gives much more information than a traditional, theoretical interview or a take-home assignment. A full-day collaboration gives me a sense of what it’s really like to work with a person: how they communicate, how they find a solution, how they debug etc. – things I won’t be able to assess otherwise. And at the end of the day, it’s even less stressful for candidates as they don’t need to do anything special or try to give the right answers – they just do what they are good at and, in most cases, enjoy the collaborative work.
The day starts with a quick check-in call with a recruiter. Its goal is to ensure candidates are ready and have the tools they were asked to install, like a live-sharing plugin, etc.
Next is two 3.5 hour sessions dedicated to introducing candidates to the task, setting expectations, and engaging in pair programming as per our usual practice. During the session, a candidate and a Railswarian switch roles between a driver and a navigator. Railsware engineers share a real work environment, so candidates can see how we usually work and have everything they need during the full day.
Anastasia Vlasova
Full Stack Engineer
Usually, it is a task (or part of a task) from a current project. For Backend, it can be an integration with some 3rd party API or writing some background worker. For Frontend, it can be a component – edit one of the entities, for example.
Following this initial session, a midday sync is held where a Railswarian who worked with a candidate shares their impressions with the hiring team and an engineer who will lead the second session. They discuss aspects the first engineer notices and the second one needs to pay attention to. Feedback is noted, and a collective decision is made regarding whether to proceed to the second part of the day.
Alexey Zhaboyedov
Full Stack Engineer
During a full-day interview, I usually pay close attention to several crucial things. Firstly, it’s planning. Those who spend time thinking through their actions at the beginning of a task are usually capable of completing it successfully. Secondly, I evaluate ownership. People who don’t hesitate to lead the development of a feature show more confidence in their actions; they ask questions, clarify requirements, and, as a result, push harder to complete the task. Also, I observe how candidates debug. They should be able to get unstuck when the code works in an unexpected way. Communication is also vital. People who can clearly explain their thinking process have higher chances of completing the task correctly and in time. If they can describe what they are doing in a few precise words, it also saves time on needless back-and-forth communication. Lastly, genuineness is crucial. Sometimes, candidates are too reserved, serious, emotionless, and silent, which complicates the entire process. It’s hard to tell how they behave in real life as there won’t be another opportunity for us to communicate. Being genuine is key.
How we make the final decision
At the end of the day, the team holds an internal Summary session where we share feedback and insights gathered during the collaboration session. To make the correct and unbiased decision, each full-dayer should answer questions about hard and soft skills and productivity in the interview assessment matrix. We take all these results and formulate a score for the candidate.
When the score is calculated, we ask two important questions:
- Would you like to see this person in the company?
- Would you like to work in pairs with this person?
Aleksandr Kunin
Full Stack Engineer
When I was applying to Railsware, I noticed that the level of commitment from both sides was higher than in other companies. It’s not only efforts from a candidate’s side, it’s also Railsware’s commitment to the hiring process. Engineers spend a lot of time trying to give candidates a sense of how we work and what we actually do here. After all the steps, it’s really clear for both parties if we want to sign an agreement and work together or not.
If the decision is positive and a candidate is hired, they will have a period of onboarding. During this time, they may address any areas for improvement identified during the hiring process.
For candidates who were not hired, we are committed to providing timely and transparent feedback. This feedback is shared the next day, highlighting specific observations from the full-day assessment and any crucial areas for improvement. Also, we may recommend future opportunities for the candidate to apply to and keep an open dialogue about roles that match their skills and goals., We have had cases where candidates have applied again after they improved what we asked and, as a result, were hired.
Marcin Klocek
Full Stack Engineer
Providing timely feedback is crucial. First, because it may help people understand what skills they should improve to try again with us. We often say to our candidates that even if we don’t match now, it doesn’t mean we can’t try again later. Second is because our hiring process is time-consuming, especially the full-day interview. We invest our time to get to know candidates, and candidates invest their time too. We simply owe them honest, clear, and well-structured feedback as a “reward” for spending that time with us, even if we don’t end up giving them a contract. Finally, from the very beginning, we want to show that we are a feedback-driven company that not only provides feedback but also seeks to receive it from candidates in order to improve our hiring processes.