DEV Community

loading...

Finding a better way to conduct technical interviews

G.L Solaria
Windows by day, Linux by night
・1 min read

I have been asked to assess the technical ability of a small group of graduate software engineers.

We have typically asked a lot of open ended questions to assess their level of enthusiasm for software engineering. We have then followed that up by giving the grads some code to review and asked them to find issues with the code. Human resources wants to use a screening tool like HackerRank.

I feel that such approaches do not adequately evaluate all the qualities we need for the grad to be successful in our organisation. A lot of grads tank in the technical code review and we may be missing out on some talent because of the way we conduct the interview.

I was thinking it might be better to start with a simplistic one sentence requirement. The grad then collaborates with a senior software engineer through a single iteration working through the process from requirements analysis, design, implementation, testing, deployment, and defect management. I think this will give us a better picture of how well they can communicate, collaborate, and code. It will also enable the senior software engineer to assess their level of understanding of each stage of the software development life-cycle.

What process have you used to find good grads?

If you are a new or recent grad, what could we do to help you shine in a technical interview?

Discussion (2)

Collapse
jmickey profile image
Josh Michielsen

I recently wrote a (fairly large) post on the technical interview process here:

For grads specifically, I think it's important to keep in mind that their ability to learn and adapt is much more important than their ability to hit the ground running like an experienced developer. Grads will always spend the first 3-6 months or so as a burden on the team they join, but this can often result in a huge return once they've found their feet.

I've interviewed quite a few grads at a previous company, and I think our biggest mistake was asking them to write code. It's often very stressful, and not a good indication of their ability.

Some thoughts I have:

  • Talk about their university projects, ask them questions that prompt them to explain why they made certain choices.
  • Avoid the boilerplate algorithm and data structures brainteasers.
  • Avoid putting them in front of an editor and asking them to debug. Again, I don't think this will have the desired result.

It might be worth trying to sit down with them in front of a PR, give them some context, and then ask them to explain what the PR is achieving.

Also a very short (1-2 hour) take home task might be good. For example - implement a basic web API in their language of choice.

Collapse
peledzohar profile image
Zohar Peled