I like the fact that this tests understanding of certain trade-offs. It can be improved in 2 ways though: 1. It doesn't allow the candidate to map out the avai

I like the fact that this tests understanding of certain trade-offs. It can be improved in 2 ways though: 1. It doesn't allow the candidate to map out the available options for themselves, which is an equally important skill in software dev. When I'm working, I often have to spend a good chunk of time exploring the space of solutions, and only then can I move on to assess the trade-offs involved. 2. Another important skill is being able to question assumptions. You could (for example) intentionally under-specify the problem and let the candidate ask follow-up questions to root out assumptions/constraints. Example problem: You have an array of integers, how would you decide on an algorithm to sort it? Expected clarifying questions: (a) is there any relation/pattern in the integers stored? If they're all from a small set (say, 1-1000) then a simple counting sort works best, (b) how large is the array? If it doesn't fit in memory, a disk-based merge sort could be the best option.