Hiring engineers is a painful, time-consuming, error-prone process. I think we can all agree to that. If done right, a good candidate will become a part of the company who adds value to it. If done wrong, candidates can waste the interviewer’s valuable time as well as their own time. Moreover, a bad candidate can also end up being an employee of the company adding little or even negative productivity – the team gets less work done with the new member onboard.

The truth is that (un)fortunately, everything starts from outside the CV process. If possible, candidates that the business know already and whose background has been proven in other environments are in better situation for both the company and for themselves. A person that knows someone who works in the organisation already gets a feeling of the working environment which leads him to take more thoughtful decisions. The company on the other hand which knows a person – say the person has contributed to the company’s open source project – does not rely entirely on the risky interview process for a holistic assessment.

With that said, the world is far from perfect and the interview process still remains the norm. It usually starts with a CV filtering.

CV filtering

The company should look for problem solving skills, culture, team fit and programming ability – not for specific skill sets. If something, the company should rank a person higher if they have a skill set different than the team’s one in order to benefit from the diversity the new candidates will bring to the environment and help the existing team learn better.

As a side project, the CV filtering should be accompanied by a short online research about the candidate and / or a phone screening. Does the candidate have an online presence with links that demonstrate their ability? Are there links to examples they have built in the past and that can be useful to the company?

Project at home

Filtering out good/bad candidates without bringing candidates on site is extremely valuable. On one hand, it gives the company an idea of the engineer’s coding style, software architecture ability and problem solving skills and on the other hand it highlights any red flags without having to spend too much time on a face-to-face interview.

Among the qualities a candidate should focus on are the following:

• Naming
• Good software architecture
• Testing
• Extensibility
• Clean code
• Justification of any assumptions

The home project has this other benefit – it focuses on something the candidate can extend on site, further demonstrating their ability to code by pair programming.

Some companies make use of 30-60 min online coding tests (e.g. Codility). The reason I dislike this solution is that they focus on solving complex algorithmic problems, usually in one function rather than focusing on problems they face in their daily routine. Unless you are Google or Microsoft, solving TSP is not something you will ever tackle. The majority of companies will spend thousands of hours on building and refactoring CRUD code, writing tests, re-architecting, documenting and improving the release pipeline. Businesses move forward and succeed by hiring work horses, not rockstar programmers.

Interview(s)

The company should have a clear interview structure when it comes to it. It should not be just a technical discussions but a timed structured process with clear goal: to assess the candidates ability to meet predefined metrics. It is important for the company to define what the desirable traits are and reflect back from time to time. Interviewers questions can differ from person to person as long as the difficulty and relevance remain consistent.

It is critical to have a variety of interviewers per candidate. The reason is twofold. The interviewer can cover as far as his knowledge goes. Having a discussion with as many people as possible ensures that biased views are diminished. On the other hand, it is beneficial for the candidate to meet the team and form a better opinion before joining.

I always find technical architecture discussions really useful. The ability to design and explain how system A is architected (or could have been), things you would change and why, elements of caching, consistency, fault-tolerance etc. offers a breadth of topics to the table. They can be covered with a deeper dive on elements that are critical for that specific company.

Pair-programming is another way to ensure the candidate can code effectively and demonstrate good qualities / practices. We all know how difficult it is to code with one watching over your shoulder, even more when we are judged by an unknown person. I however find it an easy win and something that you would probably do in your real everyday tasks.

Whiteboard live coding is something I find less useful. The candidate works without any tools that make them productive, writes code that gets hardly rewritten once they understand the problem domain better, has no testing and adds extra pressure to what is an already stressful situation. As a matter of fact, you can get out of a whiteboard session as much as you get out of a pairing session.

Summary

Hiring will always be a hard process. To avoid depending solely on interviews, meet-ups, networking with other employees, experience on open-source projects (or even choosing companies that contribute to such) can make it less biased & less painful.

The reason I am writing the above is that I want to become a better interviewer myself and improve the process. Judging from personal experience, we have a long way to go. Please do comment and let me know your thoughts.

Follow @mvogiatzis