3 ms·
How about not doing quick tests? Throw some code up on a screen and ask a candidate to tell you what it does, what they think about it, what they might do diff
by matt_s 5y ago
How about not doing quick tests?
Throw some code up on a screen and ask a candidate to tell you what it does, what they think about it, what they might do different. We all have that piece of code that is the skeleton in the proverbial closet.
- tkiolp4 5y agoNot sure why he’s been downvoted. It does sound quite reasonable. Writing code from scratch is easier than reading other people’s code. Explaining (in a correct and understandable way) what a snippet of code does is, imho, way more valuable than writing code. We all know how to write code that works (whether the code is good or not is another topic), but to read code and understand it? That’s rare to find. Just take a look at all the bootcamps, “cracking the code interview” books, YouTube tutorials: they all focus on the easy part (to write code from scratch); almost none of them focus on the hard part (to be able to understand other people’s code without giving up and say “to the hell with it, I’ll rewrite it from scratch and this will be done in no time”)
- matt_s 5y agoSparking a conversation about a specific piece of code is going to likely reveal if someone doesn’t know what they’re doing. If you narrow candidates down to a handful and talk about the same piece of code with each you will have some different things to think about. Depending on candidate experience it can lead to tougher concepts to discuss. The purpose of quick tests seems to be only to eliminate people. At the end you have (amongst other criteria I hope) “Yup, can do fizzbuzz” or “Nope, can’t do fizzbuzz”. A coding test without a conversation is as good as filtering resumes based on schooling level or degree or any other quantitative piece of data.