|
|
|
|
|
|
by SnacksOnAPlane
4311 days ago
|
|
|
My go-to question for technical interviews is "how would you write Scrabble?". It's very open-ended. I expect them to ask me questions like "what do you mean, write Scrabble?", to draw out some class diagrams, and to implement some scoring. It shows how self-directed they are and how much they trust themselves to develop architecture. I hate questions about bit-twiddling and sorting algorithms. I wouldn't remember that stuff because I never do it. I do expect candidates to be able to analyze an algorithm for time and space requirements, because that's important for pretty much any coding job. |
|
|
This is a psychological test. You describe how you would imagine yourself solving it -- which may or may not be accurate -- and think that's how "good developers" would approach the problem.
The candidate doesn't know you. You might be the person who says "I'm looking for the candidate to tell me that is a stupid question" or "I expect the candidate to make a first simple iteration planning to throw it away instead of bothering with UML diagrams."
For the candidate, this is a game of rock-paper-scissors where they have to guess the state of the PRNG sitting across the table from them. There is a much better route: tell the candidate what you want[1] and see if they give it.
[1] Tell them directly; it shouldn't be buried in a post on your company's blog. I have encountered this pattern myself.