Ask HN: What is the best way to test a software developer

[nazka]

It’s no news that many people hate leetcode exercices and many people think that beyond screening it’s not that useful. So then what are the best ways or processes you know to test a candidate and his skills/code/modeling/knowledge…?

[PaulHoule]

Usually a person is going to be interviewed by a few individuals and groups and it's fair for the candidate to face different interview styles.

I like to get people to talk about a project that they are proud of that that they felt particularly engaged with. If it's a hobby or a side project that's great, but if it something they did at work that's great too. If they're not proud or passionate about anything that's a bad sign. This kind of question is good for rapport building and will often put the candidate at ease so it's good to ask this question early in the interviewing process.

[genezeta]

Do an interview with 2 or 3 people from the team with the open position. Include in the interview a discussion about some recent piece of work the team has done. Ideally choose something not too big nor too small. Do not choose an absurdly obscure bug you fixed or an overly weird or complex feature.

Once in the room, don't go too hard on it. Present the task and whatever limitations and then ask for approaches, concerns, potential solutions, cost... Do ask for details but not necessarily written code (unless they want to write something to explain some idea and it is simple, scribbled code). Let them explain their idea, the approach, the tools, the solutions, the difficulties they see. Discuss potential problems with those solutions, if any. Think how they match -or not- what you actually did. If it doesn't match, compare and evaluate why. Discuss your solution with them.

BUT: Do not take shortcuts. Don't use a generic task or exercise but something you've actually done in the last 2 months. Don't just ask a bunch of fixed questions but do strike an open conversation and discussion as if it was closer to a planning meeting or a brainstorming with a colleague instead of an interview. Don't just present your solution and discuss that but leave room for their own ideas. And don't just scoff and brush off any ideas you already discarded or know that don't work, though you can, obviously, point out any problems with those solutions. Finally don't simply evaluate how close they get to how you actually did it but focus more on the thinking process, how the way they approach the process matches your own.

Try to do this "gently". The candidate may be nervous. Make an effort to explain that there isn't a single right answer and do make it feel like a conversation not just a bunch of questions. Use the fact that there is more than one person from the team to your advantage in making it conversational and casual.

[mike_3141]

I've had success with creating coding tasks that assess skills required for the job.

Provide some sample code, perhaps with bugs, perhaps without, and ask the candidate to add features, etc.

[prithvishdoshi]

Interviews that mimic the work a potential hire is going to do, if selected by the company.

[marssaxman]

"Testing" is the wrong attitude. This is not a university exam. You're not trying to determine whether someone has studied the material - that would be a waste of everyone's time.

The point of a useful interview is to learn what it would be like to work with someone. The point of a coding problem is that it gives the candidate a chance to show you how they work. How do they break down a problem and start devising a solution? How do they communicate about their thinking? How do they resolve uncertainty?