+972 52-548-6969
Interviewing developers
My post about two (PHP) code samples that I got from people that I interviewed got a lot of comments, so instead of answering them one by one, I am going to answer them here. The post had a two code samples, one from a coder with 8 years experience, the second from a sysadmin that wants to move to development. Suffice to say that the sample from the coder with 8 years under his belt is atrocious.
Mostly, the comments tended to be:
- Why am I interviewing PHP programmers?
My company is also doing head hunting / recruitment, interviewing people is part of the job. - The sysadmin code looks good on the surface, but it is has problems. (and then listing the problems, in many detailed and interesting ways).
The sysadmin code is not perfect by any means, but it is structured, it shows basic understanding of how things work, and the rest can be handled. That guy can learn to write good code. That isn't code that I would write, or would accept in my projects, but that is a very good start for the first steps.
But a lot of people said that the first code sample is a quick & dirty solution to the problem at hand, some actually took offence at the idea.
If I interview someone for a position that include working with code (in fact, if the CV include any programming language whatsoever), you write code, period. The reasoning is that there are plenty that can talk the talk, but literally can't code. And looking at your code means that you get a lot of insight on how that person write code and how they think.
Now, here is an observation, you tend to write code in the same way no matter in what scenarios you are. Writing sloppy code in an interview is something that is a strong indication for a sloppy coder. That is not the only indication that I use, but it is certainly a significant one.
Given a choice between an experienced sloppy coder and an inexperienced one, I know who I would rather hire.
Now, to those who claimed that such questions are insulting, I am usually trying to fit the question to the person that I am interviewing (so a team lead would get something more interesting), but the key thing to remember is that I am not looking at the solution itself, I am looking at everything that they have around that.
I want to say that code style isn't something that I considering, but that would be a lie. I expect that the candidate would have some sort of a code style, and that it would be internally consistent. Beyond that, I don't really care if it spaces vs. tabs and where the curly go. But if there isn't a coding style that the candidate adheres to, that is something quite alarming.
Oh, and here is a secret that would make the argument more interesting, I don't program in PHP. The last time that I had to use that was when I tried to modify a bug tracker in PHP, and that was about two and a half years ago (the dot operator for string concat drives me crazy).
Just to remind people, my purpose in posting that was to talk a bit the difference between "experience" and quality.
Comments
"Given a choice between an experienced sloppy coder and an inexperienced one, I know who I would rather hire."
No one. Adding bad people has no value for a team, just cost (communication overhead; thwarts the co-workers etc.). The period between inplacement and being productive is too long but the developer wants his money from day one... and so on...
Instead of a coding style testing interview I rather like to see a broader picture from an project (also code artifacts) the interviewee did before in a more realistic situation: Concentrated, calmed, creative, where he iterated and refactored code, looked for missing stuff etc. without the interviewer in the back, unfree feeling, 5 minutes time, nervouseness, annoyance due this way of testing him and no context (existing code, quality constraints, ...).... Interview-tests test passing interview-tests.
I better see if a developer is sloppy looking a the project than looking at 5 minutes high-discipline action ("uh, now i have to"). I get a broader picture and i don't play Kindergarden with him. If he has no project (even not one done in sparetime) and you want him nevertheless, a coding style test would be an option for me too ...for an educational inplacement. And it is ok if you don't overrate your test.
So far :-)
"Given a choice between an experienced sloppy coder and an inexperienced one, I know who I would rather hire."
No one. Adding bad people has no value for a team, just cost (communication overhead; thwarts the co-workers etc.). The period between inplacement and being productive is too long but the developer wants his money from day one... and so on...
Instead of a coding style testing interview I rather like to see a broader picture from an project (also code artifacts) the interviewee did before in a more realistic situation: Concentrated, calmed, creative, where he iterated and refactored code, looked for missing stuff etc. without the interviewer in the back, unfree feeling, 5 minutes time, nervouseness, annoyance due this way of testing him and no context (existing code, quality constraints, ...).... Interview-tests test passing interview-tests.
I better see if a developer is sloppy looking a the project than looking at 5 minutes high-discipline action ("uh, now i have to"). I get a broader picture and i don't play Kindergarden with him. If he has no project (even not one done in sparetime) and you want him nevertheless, a coding style test would be an option for me too ...for an educational inplacement. And it is ok if you don't overrate your test.
So far :-)
Andre,
Inexperienced doesn't mean bad.
I think you have missed the point, that is not a code style test.
well, I am an inexperienced coder who also switched from beeing sysadmin to a coder.
I have to admit that writing code which is considered "good" (from my point of view the holy coding grail is code which is: maintable, extendable , well structured, tested, readable, commented, in accordance with fxcop...) is really (!) difficult for me and it often takes some time until I figured it out. BUT: the difference between me, an inexperienced coder and a programer doing that stuff for years is that the later won't put his code into question. See: I really try to keep up with quality etc. and I am trying to evolve into a good coder while others are doing what they did for the last couple of years and often they do it in the same way (and therefor with the same bugs and issues).
And even if I understand just half of the freaking code samples swaping around this and other blogs - at least I am trying to improve my skill.
"inexperienced doesn't mean bad"
well, I am an inexperienced coder who also switched from beeing sysadmin to a coder.
I have to admit that writing code which is considered "good" (from my point of view the holy coding grail is code which is: maintable, extendable , well structured, tested, readable, commented, in accordance with fxcop...) is really (!) difficult for me and it often takes some time until I figured it out. BUT: the difference between me, an inexperienced coder and a programer doing that stuff for years is that the later won't put his code into question. See: I really try to keep up with quality etc. and I am trying to evolve into a good coder while others are doing what they did for the last couple of years and often they do it in the same way (and therefor with the same bugs and issues).
And even if I understand just half of the freaking code samples swaping around this and other blogs - at least I am trying to improve my skill.
Exactly!
Polemic.
noCodingXp,
I always put my code into question and write programs for a long time... The more i'm aware of traps/mistakes/missing stuff, optimization, errors, necessity of readability, understandability etc. the more i'm looking for it... The inexperienced doesn't know what to look for and looks for what he knows... Even if he tries to learn new things he starts from his existing knowledge. He doesn't know what he doesn't know and makes small progress (without an experienced quality-coder G) Just trying is not enough...
The sysadmins tried to do the things you expected but doesnt really understand it. (You saw comments ... but they were crap... you saw a function and error handling.... but they were crap....)... How do you know the experienced developer does not write good code? On the basis of his 6 lines? You get an impression of their coding approaches but how do you know the impression is not inaccurate due to inaccurate expectations?
I do not contradict the fact that there were people doing things a long time and doing them wrong or bad or not good enough. I always learn new things too. This is not the point.
But such coding tests suck. It's a little bit like motivating people: I assume these people are not motivated, do not give their best and could do better.... Extrinsic motivation means mistrusting people: lazy folk...
Asking "Can you write a function" (in a way i aspect you to do it) is a little bit insulting to someone who develope software for years. A good start.... And as the interviewee i get an idea of what people i will met... those who passed the "code a function" test.....
The test is very low level. It is like asking a good cook if he can hold a knife... But as i already mentioned, if you looking for cheap inexperienced code monkeys the test might be sufficient/necessary.... If someone says 8 years experience does it mean nothing to me without telling me something about his experience. If he is experienced in using computers, playing, writing little scripts whatever... Ok....do the test... If he wrote apps for 8 years (what apps, how, ...) your example might be bogus and "write a function" offending...
On the basis of the interview and doing code review with him on this code, trying to find out why he wrote that. You can trust that the code is truly demonstrative of his abilities.
I do not make this test in vacum, and there are levels of what can be expected in a 5 minutes task. That is not code that I would consider viable for any reason, and I am fighting hard against it, so I feel that I should know.
Yes, exactly! The problem is that I don't know if he is a good cook or not, and I get many applicants who would do serious damage to me and themselves if they were allowed to wield a knife.
I think that you missed the point of the test, it is not about finding out if he is good or not, it is finding out if I can rule him out as soon as possible. There is a high cost of interviewing, and I want to cut the time spent of candidates that I am not going to hire as short as possible.
maybe I missed the point. But why did you present us two Code Snippets with the intent to impress us with two different styles? And in opposite to your statement above you have not seen them writing their code:
"I opened my mail, and that was a good way to start the day.
I don't think that I need to say who will get the job, right? And remember, the first one was written by someone with 8 years experience..."
And like you we should judge these two code snippets on the basis of their -appealing- and as i figured out: both were crap but you have prefered the one that -looked- good on its surface... So well, maybe I missed the point...
Comment preview