Developer Job Interviews
-
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.
-
That is an amazing story! hahahaha that is so funny, I take it they did not get the Job?
It was 100% the other way round, I was the candidate. My interviewer couldn't believe my code compiled using readonly, I tried to show him the MSDN link, he accused me of installing something and got a bit irate. I had to commandeer the mouse to show him the link.
-
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!
This impress me a lot Interviews Can Be a Terrible Way to Identify Good Programmers also other articles from same author worth reading too The Codist: All Articles Tagged 'jobs' From my personal experience: my favorite technical question was 'how much searchers are necessary to find a given element in sorted array with (1000, 2000, ... choose anything you want) elements?' if candidate answer immediately i hire him without more questions. Why? 1) he can analyze the requirements from free text and choose best algorithm - binary search 2) he understands how this algorithm really works 3) he knows powers of 2 - this means experience
www.codigi.net .NET touch screen GUI components suite
-
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!
My own situation is a little off the axis of the bell curve. I'm typically allowed to hire only very recent graduates: i.e., no employment experience. And in my experience, anyone I hire will need to be completely retrained. Hard real-time software engineering is its own unique domain, in which most of the techniques a recent Computer Science graduate will have absorbed are not only irrelevant, but actually destructive.
So I ask no technical questions. Not one. Instead, I probe for two things:
- Strong general intelligence;
- Aggressiveness about new knowledge and new challenges.
It's worked out best when I've succeeded in getting the candidate to talk about himself, his particular interests -- inside and outside software -- and the things he does with his spare time. I've had a few misfires, but on average the results have been good.
However, an interviewer who takes this approach must be ready for this question from the candidate:
"Aren't you going to ask me any technical questions?"
The last time this happened, I'd been chatting with the candidate for a solid hour. We'd gotten quite a nice little fire going, but he was puzzled that I'd shown so little interest in probing the specifics of his skills. So I asked him a question I've saved up for such occasions:
"Assume there are Plutonians. Assume there are Elves. If the Elves were to attack Pluto without warning at 5 AM tomorrow, which side would you be on?"
The candidate's eyes went momentarily wide. Then he grinned and said, "Why would I need to choose a side? I don't see that it's any of my business at all!"
To which I replied, "How soon can you start?"
(This message is programming you in ways you cannot detect. Be afraid.)
-
Have them code something that is exactly what they would be doing in the position, screw fizz buzz bop, whatever. My advice, once you determine someone to meet the competence level you expect, go on their personality, since you will probably spend more waking hours with them than your wife. Choose them like you are choosing a mate. Here's an analogy: Skills are like good looks and writing great code is the equivalent of being sexy, but a bad personality can make a mate, or in this case candidate, ugly. Do you want to spend 50 hours a week with a bitch/asshole just because they look good? Also, try to gauge if they are creepy. Is their outlook on life shitty? Can they at least hide that during the interview? Do they seem like they want the job? Or do are they only looking because they need a salary?
wizardzz wrote:
Do they seem like they want the job? Or do are they only looking because they need a salary?
I think that is the ticket right there. If a person has a good attitude, and is willing to learn, then even a basic level of competency is ok to start with. In an environment that is happy and engaging that person will grow and flourish. However we've all been in the position at one point or another where money becomes an issue. I know I have. I would have taken anything to get some money rolling in just to buy some more time to find the job I actually wanted. That will just lead to another job hunt later, with less than impressive results while at this one. Find a person that fits in and actually wants the job.
If it moves, compile it
-
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 had to interview college interns for a previous job. My general policy was to only hire those with GPA's over 3.0, but one kid with a 2.7 wanted the job so bad (did his research, asked if he might get a chance to work with this and that technology) that I gave him a shot. One of the best interns we ever had. (The one kid with a 3.9 was the *worst*!!!) Bottom line - attitude is everything.
-
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!