﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Andre commented on Interviewing developers</title><description>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...
</description><link>http://ayende.com/2726/interviewing-developers#comment10</link><guid>http://ayende.com/2726/interviewing-developers#comment10</guid><pubDate>Wed, 29 Aug 2007 16:31:13 GMT</pubDate></item><item><title>Ayende Rahien commented on Interviewing developers</title><description>&gt; How do you know the experienced developer does not write good code? On the basis of his 6 lines?
  
  
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.
  
  
&gt; how do you know the impression is not inaccurate due to inaccurate expectations? 
  
  
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.
  
  
&gt; It is like asking a good cook if he can hold a knife... 
  
  
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.
</description><link>http://ayende.com/2726/interviewing-developers#comment9</link><guid>http://ayende.com/2726/interviewing-developers#comment9</guid><pubDate>Thu, 23 Aug 2007 06:51:54 GMT</pubDate></item><item><title>Andre commented on Interviewing developers</title><description>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...
</description><link>http://ayende.com/2726/interviewing-developers#comment8</link><guid>http://ayende.com/2726/interviewing-developers#comment8</guid><pubDate>Thu, 23 Aug 2007 06:42:56 GMT</pubDate></item><item><title>Andre commented on Interviewing developers</title><description>&gt;&gt; Instead of a coding style testing interview
  
&gt; I think you have missed the point, that is not a code style test.
  
  
Polemic.
  
  
noCodingXp,
  
&gt; a programer doing that stuff for years [...] won't put his code into question
  
  
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...
  
  
&gt; Exactly!
  
  
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.....
</description><link>http://ayende.com/2726/interviewing-developers#comment7</link><guid>http://ayende.com/2726/interviewing-developers#comment7</guid><pubDate>Thu, 23 Aug 2007 06:23:51 GMT</pubDate></item><item><title>Ayende Rahien commented on Interviewing developers</title><description>Exactly!
</description><link>http://ayende.com/2726/interviewing-developers#comment6</link><guid>http://ayende.com/2726/interviewing-developers#comment6</guid><pubDate>Wed, 22 Aug 2007 21:01:55 GMT</pubDate></item><item><title>noCodingXp commented on Interviewing developers</title><description>"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.
</description><link>http://ayende.com/2726/interviewing-developers#comment5</link><guid>http://ayende.com/2726/interviewing-developers#comment5</guid><pubDate>Wed, 22 Aug 2007 20:49:37 GMT</pubDate></item><item><title>noCodingXp commented on Interviewing developers</title><description>&gt;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.
</description><link>http://ayende.com/2726/interviewing-developers#comment4</link><guid>http://ayende.com/2726/interviewing-developers#comment4</guid><pubDate>Wed, 22 Aug 2007 20:48:47 GMT</pubDate></item><item><title>Ayende Rahien commented on Interviewing developers</title><description>Andre,
  
&gt; Adding bad people has no value for a team
  
  
Inexperienced doesn't mean bad.
  
  
&gt; Instead of a coding style testing interview
  
  
I think you have missed the point, that is not a code style test.
  
  
  
</description><link>http://ayende.com/2726/interviewing-developers#comment3</link><guid>http://ayende.com/2726/interviewing-developers#comment3</guid><pubDate>Wed, 22 Aug 2007 03:50:16 GMT</pubDate></item><item><title>Andre commented on Interviewing developers</title><description>"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 :-)
</description><link>http://ayende.com/2726/interviewing-developers#comment2</link><guid>http://ayende.com/2726/interviewing-developers#comment2</guid><pubDate>Wed, 22 Aug 2007 02:22:04 GMT</pubDate></item><item><title>Andre commented on Interviewing developers</title><description>"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 :-)
</description><link>http://ayende.com/2726/interviewing-developers#comment1</link><guid>http://ayende.com/2726/interviewing-developers#comment1</guid><pubDate>Wed, 22 Aug 2007 02:22:04 GMT</pubDate></item></channel></rss>