I have found success by doing the following (when hiring for an engineering role):
1) Doing a relatively shallow but wide survey of the technology I'll expect them to be responsible for. Because we use k8s, I steal the old "type google.com into your browser" question and make it, "I type 'kubectl get pods' and hit enter. What happens to make the list of pods show up on my screen?". From there, you can dive into basically any part of the stack you want.
I'll often ask them to explain to me what the difference between a container and a VM is, as though I were an intern, and then I'll ask probing questions about things they get wrong or things they leave out that I think are relevant.
This isn't to pass/fail them, necessarily (though some people have done so badly that they essentially failed themselves), but it's to see where their familiarity and comfort level is with the tech at hand.
2) talking through their resume with them, and doing a deep-dive into a couple aspects of their recent history - why did they do a thing? What alternatives did they explore? What was the reason they went with what they did? How did they implement it? What problems happened? Who did they collaborate with and what was the precise scope of their involvement? How did they measure success, and what was the follow-up?
I don't expect anyone coming in to have a deep knowledge of the tech stack we have. I do expect someone to have deep knowledge of the technology that they put on their resume, though.
My hit / miss rate is pretty decent. There have been a couple of times that I said no when I should have said yes, but I'm okay with that ratio.
1) Doing a relatively shallow but wide survey of the technology I'll expect them to be responsible for. Because we use k8s, I steal the old "type google.com into your browser" question and make it, "I type 'kubectl get pods' and hit enter. What happens to make the list of pods show up on my screen?". From there, you can dive into basically any part of the stack you want.
I'll often ask them to explain to me what the difference between a container and a VM is, as though I were an intern, and then I'll ask probing questions about things they get wrong or things they leave out that I think are relevant.
This isn't to pass/fail them, necessarily (though some people have done so badly that they essentially failed themselves), but it's to see where their familiarity and comfort level is with the tech at hand.
2) talking through their resume with them, and doing a deep-dive into a couple aspects of their recent history - why did they do a thing? What alternatives did they explore? What was the reason they went with what they did? How did they implement it? What problems happened? Who did they collaborate with and what was the precise scope of their involvement? How did they measure success, and what was the follow-up?
I don't expect anyone coming in to have a deep knowledge of the tech stack we have. I do expect someone to have deep knowledge of the technology that they put on their resume, though.
My hit / miss rate is pretty decent. There have been a couple of times that I said no when I should have said yes, but I'm okay with that ratio.