|
|
|
|
|
by jefftk
2414 days ago
|
|
I've interviewed a lot of candidates (~200), and my interview generally looks like: * I describe the problem * They ask questions to figure out parts I didn't specify (which lets me evaluate how they handle resolving ambiguity) * They propose a brute force solution, and I ask them how quickly it runs and how much space it needs (talking in big-O is a fast way for me to tell if they understand their solution) * They propose a much more efficient solution (often with hints) and we again talk about time and space complexity (which again lets me see whether they understand how to compare solutions like this. I'm also happy to hear other tradeoffs like "this is optimal but too complicated to be worth maintaining") * They code their solution (which lets me see if they can actually code, and check how well their description of their algorithm matches their actual algorithm) This isn't a daily job sort of task, but it's not far off, much faster, and very information dense. I'm not testing "do you know the right algorithm" (and will hint that part). |
|