When hiring...
I suck at coding tests when it comes to job interviews. I for one hate them. I can code, I can write code from scratch and I can modify complicated and complex methods/functions. I have more than once bludgeoned the compiler into submission with the keyboard to do my bidding. But when asked to write simple and almost irrelevant pieces of code to be judged, my performance will always be less than stellar. Only because I personally hate them.
So when hiring I won't like your workplace if you ask me to write irrelevant code. I'll much rather show you code I've written. Or ask me to do a task I can complete in a few hours or even a day. The reason is simple, I always read back my code and see if there is something wrong with it and test it at least once before I ship anything.
But if you feel that you must put people under the gun with code. I don't mind pressure, give me code samples with problems or errors. I much rather give an analysis quickly of code than write problem code myself that is never going to ship or run even a single time.
But this is only my opinion.
posted by paracelsus at
10:57 AM
1 Comments:
Twice or thrice I had the chance to sit in on a job interview of someone who was supposed to be put on my team afterward.
In both cases what I did was to type up two or three snippets of code respectively (usually with the problem taken from real-life code, but "abstracted" ;)) and then asked the interviewees what they thought or pointed out the problem and asked them for their take on a solution.
Worked quite well, I think.
I mean would you hire a circus clown that isn't funny, a baker allergic to flour or a teacher "allergic" to kids? ;)
But I share your point that it's quite pointless to write code that won't run.
IMO some generic problem such as a simple "buffer class" or so lends itself to the purpose. Even if the code itself won't be reused unchanged, it's much more likely that it will be reused overall.
By
Miðgardsormr, at 12:21 PM
Post a Comment
<< Home