I agree that the cliché whiteboard interview is just awful – I've had my share of terrible ones. However, there is one form of whiteboard interview that I really like – it's where the interview is about system design and architecture rather than coding problem nonsense.
I think the first time I saw this was at Google, where the question was pretty much "We are going to design Google Maps from scratch – what does it look like?". The interview is about evaluating the candidate's ability to ask sensible questions when designing a system, checking that they know how to analyse tradeoffs, and understand where they need to think about issues like performance or scaling.
I liked it so much that I've built it into our own recruitment process for our most recent role – it's a process that we go through a lot, even when making changes to existing systems. We do it as a one-hour long collaborative system design process with a short specification for a system that we want to build. We let the candidate lead the design, and help by providing feedback, discussing any ambiguities, and asking questions about specific areas of concern. It's been really interesting to see how different candidates have approached the process.
(Anecdotally, the biggest indicator of a good candidate so far has been the use of abstraction rather than concrete technologies - i.e. "I would have a queueing system here and an object store there" rather than "I would have Kafka here and push to S3 there").
I think the first time I saw this was at Google, where the question was pretty much "We are going to design Google Maps from scratch – what does it look like?". The interview is about evaluating the candidate's ability to ask sensible questions when designing a system, checking that they know how to analyse tradeoffs, and understand where they need to think about issues like performance or scaling.
I liked it so much that I've built it into our own recruitment process for our most recent role – it's a process that we go through a lot, even when making changes to existing systems. We do it as a one-hour long collaborative system design process with a short specification for a system that we want to build. We let the candidate lead the design, and help by providing feedback, discussing any ambiguities, and asking questions about specific areas of concern. It's been really interesting to see how different candidates have approached the process.
(Anecdotally, the biggest indicator of a good candidate so far has been the use of abstraction rather than concrete technologies - i.e. "I would have a queueing system here and an object store there" rather than "I would have Kafka here and push to S3 there").