I think the best insight you can get into a potential hire is by asking deep questions about their experience. This takes IMO a really smart interviewer. I try to think about their past projects as if I had to take them on myself and ask them questions based on what I’d expect to be the difficult parts of the implementation. Especially things that sound like data hot spots or might benefit from parallelization.
I’m actually most interested in finding out what abstractions they were able to apply, and not necessarily the end result but
more their problem solving process, because I’m going to have to live with this person’s design choices.
In my experience the above is just really hard for someone to fake. If they try to steer me away from talking about their experience or gloss over too much then the BS alarms start to go off…
Really the above is also IMO the real value in asking folks to solve coding challenges. It’s not so I can see you struggle to write code on the spot. I want you to talk to me. I want to know how it’s going to feel to collaborate with you. Are you going to go off on your own and do a bunch of stupid garbage I’ll have to fix later? Or do you design in the open?
I’m actually most interested in finding out what abstractions they were able to apply, and not necessarily the end result but more their problem solving process, because I’m going to have to live with this person’s design choices.
In my experience the above is just really hard for someone to fake. If they try to steer me away from talking about their experience or gloss over too much then the BS alarms start to go off…
Really the above is also IMO the real value in asking folks to solve coding challenges. It’s not so I can see you struggle to write code on the spot. I want you to talk to me. I want to know how it’s going to feel to collaborate with you. Are you going to go off on your own and do a bunch of stupid garbage I’ll have to fix later? Or do you design in the open?