At the start of forming my team, I was tasked with designing a technical exercise for hiring purposes. It was our first mobile team, and we chose KMP technology. Few candidates have experience in KMP, and we were unsure if they would have the environment ready for conducting a live coding challenge. Besides this technical test, my engineering manager strongly insisted that I assess candidates’ soft skills, including problem-solving, adaptability, creativity, collaboration, and communication.
It occurred to me that evaluating someone's soft skills solely through questions was not an effective approach. Anyone can use AI tools to generate convincing answers that include all the words interviewers want to hear. Who hasn't made this mistake and hired a developer with excellent technical skills, only to find they lack soft skills? I have.
With these considerations in mind, I designed an exercise that simulates a developer’s daily work, comprising a pair programming session with the candidate as the driver and the interviewer acting as a junior developer being mentored. The candidate’s role is to select a task from the backlog and guide the interviewer through its execution. The interviewer's task is to follow instructions, occasionally admit they don’t understand or hear the candidate well, and sometimes disagree with the solutions proposed.
Our primary objective is to observe how the candidate adapts to a new project using new technology, how they employ creativity to solve problems, what questions they ask, how they provide instructions, how they handle frustration when faced with repeated failures, how they debug, and other relevant aspects.
Initially, we emphasise that there are no right or wrong results. We only want to assess how the candidate interacts and integrates into our team. I must tell you, I’ve never seen two candidates follow the same approach even when tackling the same story.
We’ve used this exercise with over ten individuals, and some insights emerged:
1. The candidate rarely asked what had already been implemented or how the feature worked.
2. Worse, they never requested to run the application to verify the code’s functionality or to interact with the solution.
3. Most candidates try to demonstrate their expertise by taking on the most challenging tasks, often leading to frustration and unnecessary coding.
4. Some become paralysed, refusing suggestions to move forward and failing to engage in conversation with the interviewer. It feels as though they are alone in the meeting.
5. When encountering communication or collaboration issues, they never asked if they could take control of the meeting or write in the chat. Only one person lost control and interrupted, claiming it was a waste of time because he wasn’t willing to teach the basics.
The main lessons I learned that I believe may apply to any interview are:
- Never hesitate to ask obvious questions like: “Could you please show me how the solution works?”
- Check the structure of the solution and ask any necessary questions.
- Find out if there are unit tests.
- Ask about the project's libraries.
- Inquire if there’s a business priority or if you can implement what makes you comfortable.
- After these steps, choose a task. Then, after examining the code, explain your plan to everyone. This clarifies your thought process and shows your potential, even if you don’t finish in time.
- Communicate clearly and kindly. If you encounter difficulties, consider alternative methods of communication, such as writing in the chat.
None of the candidates ever completed a task. Now you may ask, did we manage to hire someone? Yes, we have hired excellent developers so far, because completing a task has never been our main goal. For us, the most important thing is to know the people we hire live by the value "Alone we go fast, together we go further".
Top comments (0)