Developer Job Interviews
-
So, I've conducted job interviews in the past while I worked in the restaurant industry. I quite liked it, and I feel like I was very successful at finding good team members. Now, I have the opportunity to interview people for developer positions on my team. I've been reading a little about what makes a good interview for computer programmers, and I am wondering if anyone here in the lounge has any good advice for quickly and effectively determining whether or not a developer is 'worth his/her salt'. What works for you? Are there any pitfalls that you experienced that I should avoid? Thanks!
-
So, I've conducted job interviews in the past while I worked in the restaurant industry. I quite liked it, and I feel like I was very successful at finding good team members. Now, I have the opportunity to interview people for developer positions on my team. I've been reading a little about what makes a good interview for computer programmers, and I am wondering if anyone here in the lounge has any good advice for quickly and effectively determining whether or not a developer is 'worth his/her salt'. What works for you? Are there any pitfalls that you experienced that I should avoid? Thanks!
Remember (I assume) you are hiring people that you will be working with. Technical abilities are one thing, but if you can't work with them, or if they do not fit the company profile, they will be miserable and you will be miserable, and probably will have to let them go quite early and you will need to do the hiring process again. If asking "trick" questions, do not look for the exact answers, but on the manner they answer the question. Be certain to "calibrate" whatever technical question to the level of the interviewee; and always check the way they answer the question instead of the actual answer. (edit) If you ask programming question on paper, try to make them so that they do not need "auto-complete"; limit the need to know specific API ( which are sometimes hard to remmeber!)
Nihil obstat
-
So, I've conducted job interviews in the past while I worked in the restaurant industry. I quite liked it, and I feel like I was very successful at finding good team members. Now, I have the opportunity to interview people for developer positions on my team. I've been reading a little about what makes a good interview for computer programmers, and I am wondering if anyone here in the lounge has any good advice for quickly and effectively determining whether or not a developer is 'worth his/her salt'. What works for you? Are there any pitfalls that you experienced that I should avoid? Thanks!
There is no way of telling who will be productive, getting work done to meet deadlines with sufficient quality, and who will be a lazy bustard who talks the talk but then causes all manner of political problems about "things not being done right", in order to avoid having to do any actual work (and who is usually later found to be incompetent). You can only hope that you get them from column A, not column B. You may have guessed that I've found a few from column B.
I wanna be a eunuchs developer! Pass me a bread knife!
-
So, I've conducted job interviews in the past while I worked in the restaurant industry. I quite liked it, and I feel like I was very successful at finding good team members. Now, I have the opportunity to interview people for developer positions on my team. I've been reading a little about what makes a good interview for computer programmers, and I am wondering if anyone here in the lounge has any good advice for quickly and effectively determining whether or not a developer is 'worth his/her salt'. What works for you? Are there any pitfalls that you experienced that I should avoid? Thanks!
I've had the opportunity over the past year to interview about 20 candidates for .NET development positions. First up take somebody else in with you, preferably with some overlapping, and some complementary skills. Between you, you should be able to test the candidate on a range of things, and two opinions are better than one when discussing the candidate's merits afterwards. Have a bank of technical questions on hand but *don't rely exclusively on them*. Candidates can spot when you're just reading off a list - it's probably the same list as they might have researched before coming to the interview. That said, we do like this list: Scott Hanselman's blog: What Great .NET Developers Ought To Know We generally try to structure an hour as follows: 5-10 mins talk to the candidate about the business, the role etc. 15-20 mins general chat about their previous roles, throwing technical questions of relevance from both from the bank, and from your own thoughts/experiences of the areas under discussion. Personalise some of the questions e.g. "ah, we had a similar problem with XYZ - how would you have gotten around that? 15-20 mins a larger question i.e. a system design, technical problem to discuss. Watch the candidate think their way around something larger. Provide paper + pens for ad-hoc diagrams. 5-10 mins any questions from the candidate - let them ask you about the work environment, projects ongoing (in particular their future) Let H.R. schedule their own extra 30 minutes before or after, get your full hour's worth! You'll find as you conduct more interviews, your ability to shoot a relevant technical question at the candidate in context of an ongoing conversation improves and you'll need the bank less and less. If it's going like an informal chat but with lots of opportunity to throw a question, then it's going okay. Don't let the candidate suffer in silence. If they don't know an answer, it may be nerves or it may be lack of knowledge, either way drop to a simpler question on the same topic - you're testing whether the candidate has oversold him/herself on that topic, but you want to find the level to decide on whether you would choose to bring the candidate on in that skill area once they're onboard (training, mentoring or pair programming etc). p.s. the above are only my opinions! You may work for/with someone who wants to give strict time limits, hard questions, lots of formality,
-
Let them do a simple practical test. Like writing a web form with one text filed and one button that will update one field in some data table. You will be surprised how many of them cannot actually code AT ALL.
This can also help the candidate in the same way. I had to do something very similar in a job interview about 18 months ago. I could tell we weren't made for each other when his doubt about the C#
readonlykeyword actually existing threatened to boil over into a full blown row. He didn't believe me, didn't believe the VS compiler (claimed I'd installed something that extended the language) until I showed him: http://msdn.microsoft.com/en-us/library/acdd6hb7%28v=vs.100%29.aspx[^] Then he came out with "oh, must be new then." -
So, I've conducted job interviews in the past while I worked in the restaurant industry. I quite liked it, and I feel like I was very successful at finding good team members. Now, I have the opportunity to interview people for developer positions on my team. I've been reading a little about what makes a good interview for computer programmers, and I am wondering if anyone here in the lounge has any good advice for quickly and effectively determining whether or not a developer is 'worth his/her salt'. What works for you? Are there any pitfalls that you experienced that I should avoid? Thanks!
-
I have read that before, but its been a few months at least. Joel is an awesome resource on this topic, so thanks for calling this one out.
-
- Determine your requirements accurately 2) Ask Interview questions related to your requirements 3) Don't get bent out of shape if someone is an expert in 1) and 2) but doesn't have secret sub requirement 86 4) Set your standards appropriately. Do you want a peon, a critical thinker, a team lead, etc. If you want a team lead and you want to micromanage that person, expect trouble. If you want a peon and task them with leading 6 people, expect trouble. 5) You get what you pay for 6) If you are not an expert don't expect to be able to identify experts 7) Extroverts interview a lot better than introverts but there is a 50/50 population split between the two. Also, there is a much higher percentage of programmers that are introverts than extroverts. If you find that all of your "candidates" are extroverts you may have a bias. 8) Be willing to fire whoever you hire in two weeks.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
Awesome list! Especially 4, and 7 are very helpful. I'm used to hiring extroverts (they seem to do better with face-to-face customer service), so that is a great thing to be aware of. I like to think of myself as an introvert, so I hope that there won't be much bias. As far as being "expert", I am very lenient on that. I am more concerned with someone's ability to learn quickly than whether or not they are familiar with my entire technology stack, and so on.
-
I've had the opportunity over the past year to interview about 20 candidates for .NET development positions. First up take somebody else in with you, preferably with some overlapping, and some complementary skills. Between you, you should be able to test the candidate on a range of things, and two opinions are better than one when discussing the candidate's merits afterwards. Have a bank of technical questions on hand but *don't rely exclusively on them*. Candidates can spot when you're just reading off a list - it's probably the same list as they might have researched before coming to the interview. That said, we do like this list: Scott Hanselman's blog: What Great .NET Developers Ought To Know We generally try to structure an hour as follows: 5-10 mins talk to the candidate about the business, the role etc. 15-20 mins general chat about their previous roles, throwing technical questions of relevance from both from the bank, and from your own thoughts/experiences of the areas under discussion. Personalise some of the questions e.g. "ah, we had a similar problem with XYZ - how would you have gotten around that? 15-20 mins a larger question i.e. a system design, technical problem to discuss. Watch the candidate think their way around something larger. Provide paper + pens for ad-hoc diagrams. 5-10 mins any questions from the candidate - let them ask you about the work environment, projects ongoing (in particular their future) Let H.R. schedule their own extra 30 minutes before or after, get your full hour's worth! You'll find as you conduct more interviews, your ability to shoot a relevant technical question at the candidate in context of an ongoing conversation improves and you'll need the bank less and less. If it's going like an informal chat but with lots of opportunity to throw a question, then it's going okay. Don't let the candidate suffer in silence. If they don't know an answer, it may be nerves or it may be lack of knowledge, either way drop to a simpler question on the same topic - you're testing whether the candidate has oversold him/herself on that topic, but you want to find the level to decide on whether you would choose to bring the candidate on in that skill area once they're onboard (training, mentoring or pair programming etc). p.s. the above are only my opinions! You may work for/with someone who wants to give strict time limits, hard questions, lots of formality,
Good points, I think testing is a waste of time. I do think that some problem solving and maybe even some pseudo-code is in order to help assess critical thinking skills.
-
Indeed, yes! I knew I had seen something like that recently. Thank you for calling it out on this thread.
-
- Determine your requirements accurately 2) Ask Interview questions related to your requirements 3) Don't get bent out of shape if someone is an expert in 1) and 2) but doesn't have secret sub requirement 86 4) Set your standards appropriately. Do you want a peon, a critical thinker, a team lead, etc. If you want a team lead and you want to micromanage that person, expect trouble. If you want a peon and task them with leading 6 people, expect trouble. 5) You get what you pay for 6) If you are not an expert don't expect to be able to identify experts 7) Extroverts interview a lot better than introverts but there is a 50/50 population split between the two. Also, there is a much higher percentage of programmers that are introverts than extroverts. If you find that all of your "candidates" are extroverts you may have a bias. 8) Be willing to fire whoever you hire in two weeks.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
So, I've conducted job interviews in the past while I worked in the restaurant industry. I quite liked it, and I feel like I was very successful at finding good team members. Now, I have the opportunity to interview people for developer positions on my team. I've been reading a little about what makes a good interview for computer programmers, and I am wondering if anyone here in the lounge has any good advice for quickly and effectively determining whether or not a developer is 'worth his/her salt'. What works for you? Are there any pitfalls that you experienced that I should avoid? Thanks!
One method to figuring this out is to have them do the work. While you probably don't want to hire them on a conditional basis, you might be able to contract out to them. Hire the best candidates as consultants for your company. This might be just a small job (10 hours or so) or it might be a 3 month gig, depending on your situation and what the interviewees can/will do. The longer you work with a person, the better you will know whether they are worth their salt or not. By hiring them as a consultant, it is a win-win. The candidate gets paid for their work and the best one(s) get offered a position. This doesn't work everywhere or with every situation/candidate but it is an effective method when you can employ it.
-
- Determine your requirements accurately 2) Ask Interview questions related to your requirements 3) Don't get bent out of shape if someone is an expert in 1) and 2) but doesn't have secret sub requirement 86 4) Set your standards appropriately. Do you want a peon, a critical thinker, a team lead, etc. If you want a team lead and you want to micromanage that person, expect trouble. If you want a peon and task them with leading 6 people, expect trouble. 5) You get what you pay for 6) If you are not an expert don't expect to be able to identify experts 7) Extroverts interview a lot better than introverts but there is a 50/50 population split between the two. Also, there is a much higher percentage of programmers that are introverts than extroverts. If you find that all of your "candidates" are extroverts you may have a bias. 8) Be willing to fire whoever you hire in two weeks.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
I really like #8 (although it may seem harsh)... for a number of reasons but generally speaking, it's hard to really gauge a person from a brief interview, the best way to really know how effective someone can be is to work with them.
-
So, I've conducted job interviews in the past while I worked in the restaurant industry. I quite liked it, and I feel like I was very successful at finding good team members. Now, I have the opportunity to interview people for developer positions on my team. I've been reading a little about what makes a good interview for computer programmers, and I am wondering if anyone here in the lounge has any good advice for quickly and effectively determining whether or not a developer is 'worth his/her salt'. What works for you? Are there any pitfalls that you experienced that I should avoid? Thanks!
I usually wait until the applicant is comfortable, and after a predetermined amount of time, have a co-worker open the door, and I shout, "NO DON'T SHOOT!" If the applicant jumps up and positions him/herself between me and the door in order to take the bullet in my stead, I hire them on the spot. You can't buy loyalty like that. :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
- Determine your requirements accurately 2) Ask Interview questions related to your requirements 3) Don't get bent out of shape if someone is an expert in 1) and 2) but doesn't have secret sub requirement 86 4) Set your standards appropriately. Do you want a peon, a critical thinker, a team lead, etc. If you want a team lead and you want to micromanage that person, expect trouble. If you want a peon and task them with leading 6 people, expect trouble. 5) You get what you pay for 6) If you are not an expert don't expect to be able to identify experts 7) Extroverts interview a lot better than introverts but there is a 50/50 population split between the two. Also, there is a much higher percentage of programmers that are introverts than extroverts. If you find that all of your "candidates" are extroverts you may have a bias. 8) Be willing to fire whoever you hire in two weeks.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
#6 is very good point.
-
I usually wait until the applicant is comfortable, and after a predetermined amount of time, have a co-worker open the door, and I shout, "NO DON'T SHOOT!" If the applicant jumps up and positions him/herself between me and the door in order to take the bullet in my stead, I hire them on the spot. You can't buy loyalty like that. :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997That seems like a really good idea! :laugh:
-
I hadn't read it before. Now I'm cleaning the keyboard and monitor of coffee spittle after reading:
I want my ER doctor to understand anatomy, even if all she has to do is put the computerized defibrillator nodes on my chest and push the big red button, and I want programmers to know programming down to the CPU level, even if Ruby on Rails does read your mind and build a complete Web 2.0 social collaborative networking site for you with three clicks of the mouse.MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
So, I've conducted job interviews in the past while I worked in the restaurant industry. I quite liked it, and I feel like I was very successful at finding good team members. Now, I have the opportunity to interview people for developer positions on my team. I've been reading a little about what makes a good interview for computer programmers, and I am wondering if anyone here in the lounge has any good advice for quickly and effectively determining whether or not a developer is 'worth his/her salt'. What works for you? Are there any pitfalls that you experienced that I should avoid? Thanks!
For me it is a tick-list * Do they have code samples * Do they have / can they send me examples of "Hobby" projects (often these are more technically proficient than client projects, or at least they will / should always be passionate about them) * Do they have examples of finished work (even if they were part of a team) * If they have worked in a team, what were their responsibilities (avoid floaters that "do a bit of everything") * Do they understand / could they quickly adopt the coding style I need them to * What experience do they have (years for language(s) & project size, it's no good hiring a 10-year PHP veteran to build you an OS) * Are their any specialties they posses (relating to programming) * Are they willing to learn * Are they a roll their-own (Can they name some popular libraries) * Are they dependent on a library (Likewise they should be able to code without putting XYZ dependency into every project, the term wordpress or drupal developer really incenses me!) * What do the existing group think of them * What are their goal and aspirations (again you need to be careful as some just want to make senior dev quickly and will meander through many businesses to do so) Pitfalls I have experienced * Jack of all trades (Recently I sat with a dev that told me his experience was in hardware design, software design, programming for any device and that he was better known in Japan than UK. Needless to say he fell down upon scrutiny of any one area by being vague and general or jargon-throwing, some words that did not even belong together) * Academically perfect, Business disaster (This basically relates to anyone that would suggest re-visiting client code (regardless of who wrote it) and perform months of work adjusting the architecture (NOTE: without functional reason) of code so that it better fit a text-book description or what they learned in college. If someone does this, but they seem an otherwise good candidate, just ask them for some research before making changes and double check with clients (NOTE: not benchmarks alone but solid, business focused research with a case study) ) I think that should cover it :)
-
This can also help the candidate in the same way. I had to do something very similar in a job interview about 18 months ago. I could tell we weren't made for each other when his doubt about the C#
readonlykeyword actually existing threatened to boil over into a full blown row. He didn't believe me, didn't believe the VS compiler (claimed I'd installed something that extended the language) until I showed him: http://msdn.microsoft.com/en-us/library/acdd6hb7%28v=vs.100%29.aspx[^] Then he came out with "oh, must be new then." -
So, I've conducted job interviews in the past while I worked in the restaurant industry. I quite liked it, and I feel like I was very successful at finding good team members. Now, I have the opportunity to interview people for developer positions on my team. I've been reading a little about what makes a good interview for computer programmers, and I am wondering if anyone here in the lounge has any good advice for quickly and effectively determining whether or not a developer is 'worth his/her salt'. What works for you? Are there any pitfalls that you experienced that I should avoid? Thanks!
Also try pre-screening to weed out the liars. You can do online tests where the applicant has to write code in a web page, and the entire process is recorded for your viewing pleasure. http://www.interviewzen.com/[^]
I too dabbled in pacifism once.