Yup, this is what I’ve always done for interviews.
Technical questions are purely to see what background someone has and how they explain or reason their way to some sort of answer. Its also nice to see if someone will say they don’t know something but offer their best guess, which is always a good indicator. I’ll usually provide the answer right away after they’ve answered, both to boost confidence for correct answers and because a quick explanation has a tendency to ease tension, especially if they then relate it to some other knowledge they have or suddenly recall the info with a little help.
The other thing I do is ask questions about disagreements with previous coworkers or managers. If someone starts explaining themselves into being superior to others, it’s a red flag. Its nice to get an idea for how someone resolves conflict or what kinds of complications they’ve run into, but I mostly just want to see how they view themselves compared to others.
I know my approach is sometimes strange to others doing hiring with me, but it’s all pulled from my time as an education major (I switched out after 3 years to another degree) and real world teaching experience. Good teachers ask questions to understand how a student learns and what they know broadly, not to get an exact percentage of points. (State/district testing requirements aside)
A new thing I’ve been trying instead of live coding is having people map out a loose architecture for some sort of API data process or frontend data process, then walking us through it. Its more or less a pseudo coding excercise, but it takes the stress of actual language knowledge away. I’m not sure if it’ll stick long run, but it’s been an interesting experience.
The other thing I do is ask questions about disagreements with previous coworkers or managers
I like these kinds of questions as well, but I keep it to technical disagreements (i.e. best idea wins) since we have another round where we cover soft skills specifically.
map out a loose architecture for some sort of API data process or frontend data process
I think this is pretty easy to BS through though.
We usually cover this as a follow up to a live coding exercise, where we ask them, without any code, how they’d adjust the project if the requirements change. How can they optimize for storage size? Lookup performance? As it gets more complex, what can we do to keep it maintainable? If we add feature X, is it better to put that on the FE or BE? Why?
For sure. So far I’ve only used it for one batch of interviews so I’m not 100% set on it, but we used it as our last round to narrow down between a few finalists and we were already confident they were not people who would BS the excercise.
Yup, this is what I’ve always done for interviews.
Technical questions are purely to see what background someone has and how they explain or reason their way to some sort of answer. Its also nice to see if someone will say they don’t know something but offer their best guess, which is always a good indicator. I’ll usually provide the answer right away after they’ve answered, both to boost confidence for correct answers and because a quick explanation has a tendency to ease tension, especially if they then relate it to some other knowledge they have or suddenly recall the info with a little help.
The other thing I do is ask questions about disagreements with previous coworkers or managers. If someone starts explaining themselves into being superior to others, it’s a red flag. Its nice to get an idea for how someone resolves conflict or what kinds of complications they’ve run into, but I mostly just want to see how they view themselves compared to others.
I know my approach is sometimes strange to others doing hiring with me, but it’s all pulled from my time as an education major (I switched out after 3 years to another degree) and real world teaching experience. Good teachers ask questions to understand how a student learns and what they know broadly, not to get an exact percentage of points. (State/district testing requirements aside)
A new thing I’ve been trying instead of live coding is having people map out a loose architecture for some sort of API data process or frontend data process, then walking us through it. Its more or less a pseudo coding excercise, but it takes the stress of actual language knowledge away. I’m not sure if it’ll stick long run, but it’s been an interesting experience.
I like these kinds of questions as well, but I keep it to technical disagreements (i.e. best idea wins) since we have another round where we cover soft skills specifically.
I think this is pretty easy to BS through though.
We usually cover this as a follow up to a live coding exercise, where we ask them, without any code, how they’d adjust the project if the requirements change. How can they optimize for storage size? Lookup performance? As it gets more complex, what can we do to keep it maintainable? If we add feature X, is it better to put that on the FE or BE? Why?
For sure. So far I’ve only used it for one batch of interviews so I’m not 100% set on it, but we used it as our last round to narrow down between a few finalists and we were already confident they were not people who would BS the excercise.