4 ms·
You make a good point about the way a code test can change the "atmosphere" of an interview. Showing what you've built and explaining how you did it is also pr
by Timothee 15y ago
You make a good point about the way a code test can change the "atmosphere" of an interview.
Showing what you've built and explaining how you did it is also probably much closer to how you would collaborate if you were hired. Some might say that it would be too easy for someone to discuss code they haven't actually written, but it's also easy (as demonstrated recently on HN) to just practice common coding tests and pass.
I haven't done many interviews for development jobs, so I don't know how common (if at all) it is to get "please bring with you something you've built to discuss it".
- kls 15y agoI always bring my laptop with me and try to steer the interview in that direction. The first thing I do is ask them if they would like to see something that I have built and offer to walk them through the code and the architecture. If someone does this on an interview, they would be hard pressed to BS their way through an entire application. There is just a level of detail that they will go into that, someone that is faking it cannot, generally you will get storied about the code, stuff like oh yeah, this routine was a pain because in IE when you add and remove an element from the DOM it destroys it in memory. That kind of battlefield cometary shows that they lived through the code and it comes out organically when you talk to someone about something that they have been part of.
- Timothee 15y agoI totally agree. I'm just imagining that one easy argument against that would be "well, we want to see them code, otherwise, how can we be sure?". To this, I answer that it may be true, but coding tests are no better in that regard, because they can be gamed very easily too. And, as you're saying, I would expect that showing and explaining what you've built would actually be much more useful and a much better proof of competence and culture fit.