I recently started at a company x months ago. A colleague and I, both agree t0hat the interview process is not one we would willingly tackle again. I raised this with my manager and they have delegated complete responsibility to myself, which I am pleased about, however I don't have a huge amount of experience as an interviewer, although I have done government training to be an interviewer (anti-bais, score cards).
The type of role is a Data Engineer favouring the profile of a Software Engineers in the data space.
What advice can you offer? If you have interviewed for a similar role what good/bad experiences have you had?
If you’re going to give a code challenge, make it simple, representative of a real-world problem, and allow them to use resources like stack overflow/blogs/manuals/GitHub issues. Code challenges where you implement an algorithm from memory select only one type of candidate: people who study for interviews.
It's pretty simple - find people who are smart and get things done.<p>Do test their technical ability, the ability to actually do the job. Fizzbuzz filters a remarkable number of people, so you don't actually have to make it too tough. One of my favourite tests is seeing if someone can reverse a linked list, or do stuff like a FIFO queue with a filter.<p>You often want to filter overly clever people. So you might play with time. Give them too much time to do a simple implementation, but too little to do a full one.<p>And then you want to filter for people who just dumbly copy paste answers. This is most fun as a conversation around certain topics. It doesn't have to be a technical challenge. I've had a lot of fun just discussing architecture and tech stacks with applicants. How would you solve this problem? What stack? What's the drawbacks?
I think easy level coding challenges are a good filter, but <i>not</i> a good way to assess technical skill.<p>At my previous bigco, I did a collaborative linkedlist problems to understand if they could handle null checks, recursion, checking bounds, etc.<p>Some people clearly had been practicing LL coding stuff so they flew through it in ten minutes, so I'd just change it a little to make sure they understood what they were doing.<p>Other folks were deathly nervous and would bumble through it but they'd eventually pass, but they got the same 'score' as the people who did it in five minutes.<p>Some people couldn't pass it no matter how many hints I gave them, they didn't even really understand loops/recursion. So the filter worked there, and that was the point.<p>It's other rounds that you can assess the depth of their knowledge moreso than coding challenges.