4 ms·
I've had folks who just jump into the code without any planning. It usually bites them about 20-30 minutes in. On the other hand, I remember one guy who spent
by RKoutnik 11y ago
I've had folks who just jump into the code without any planning. It usually bites them about 20-30 minutes in. On the other hand, I remember one guy who spent the first 20 minutes planning and only 40 coding and ended up doing better than most.
The point here is not "Write as many lines of code as you can". I want the candidate to plan - it's a crucial part of the job. FizzBuzz, sorts and the like don't require much planning. Minesweeper does.
- infraruby 11y ago> I want the candidate to plan Then ask for that, and assess the plan, otherwise you're expecting Carnac the Magnificent: http://raganwald.com/2015/05/08/carnac-the-magnificent.html http://raganwald.com/2015/05/08/carnac-the-magnificent.html
- tzs 11y agoI decided to have a go at this, even though I am at best a JavaScript dabbler. I did plan...but if you were watching me you would not have seen me planning. I decided right away that my display was going to be a table with one table cell per Minesweeper cell, with the table cell's ID of the form "X_Y" where X and Y are the coordinates of the corresponding Minesweeper cell. I did the rest of my planning while getting that HTML written (first in vim, and then when that was going too slow even with macro assistance by writing a little Perl script to generate the HTML). I was not able to do it in an hour. At the end of one hour, I had everything for a rudimentary Minesweeper coded, but had a bug in the code that reveals the cells around a clicked empty cell, and it took another 20 minutes to find and fix that. Here is what I came up with: https://github.com/tzs/interview_minesweeper https://github.com/tzs/interview_minesweeper The initial commit was made at the one hour point, so that would have been what I would have turned in during an interview.