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!
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!
-
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 of my main questions is, "What have you done outside of class or previous work requirements?" Essentially, do they program recreationally? Why is that important to me? It shows immediately to me if they are interested in learning more. I've worked with too many drones who did only what they were told, even when it was obvious what they were told to do was wrong. I want programmers who are bothering to learn something new on their own time because you never know when that outside skill will become applicable to the job. I'm basing that on my own experience. I experimented with interrupts when my employer thought it a waste of time. Later I had a job that required extensive use of interrupt driven code. But more recently, I was playing with a program that did graphics at home, and it just so happened a requirement for graphics came up and I was able to apply that knowledge to develop a system that saved the company $42,000 in initial cost and millions in operations. I want to have people on my team that may just have that knowledge that is outside our current requirements that can come in and save the day. If I think a candidate is worthwhile, I'll drag them back to my office for a one on one where we discuss programming in general. I don't ask about specific syntax, that changes too fast. I'm not looking to ask them tricky questions, like some I've had to deal with. I want to know if they are BSing me and if not, can I dream with them of what we could accomplish. Again, I'm not looking for drones, but I don't want BS artists either. How grounded are they in what it takes to get a product out the door? So far I've been very happy with the people I've hired, it's the ones that weren't hired going through this process that I am less enamored with.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon 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!
Ask them how they would go about making M&M's. There is no correct answer, of course; the point is to confuse and fluster them. Don't accept their first or second or third answer. Keep berating them about it. This should comprise the bulk of the interview. (Is anyone besides me old enough to remember this one? Still irks me!!)
-
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
loctrice wrote:
That will just lead to another job hunt later
Or maybe I could already like my job and just want a higher salary. So I would look for the same job elsewhere, but just for the money.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
loctrice wrote:
That will just lead to another job hunt later
Or maybe I could already like my job and just want a higher salary. So I would look for the same job elsewhere, but just for the money.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
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.
I guess the interviewer fits point #6 made by Ennis Ray Lynch, Jr.[^] :laugh:
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
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, 1997I'd probably say: "Don't shoot me, shoot him!"
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
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.
Yes, rely heavily on sample tests to write some well known coding. If they can't handle that, they are nubs and will end up slowing you down getting them up to speed in the current project. I also give them a test to see if they understand the code and can pickup on a feature in a current project. I evaluate their creative contributions to a feature with some basic questions. Also I ask them to bring examples of programs they have written themselves. All worthwhile developers have their own little projects they are working on. I look for completeness in their work, idea's they have for improvement and how they would go about it. I also evaluate their eagerness to get started and ability to work with a team. I think these things are extremely important.
-
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 is a giant can of worms. I think the first thing to do is to read Joel Spolsky's blog posts and his book. Now before you even get to the job interview, start surfing the job boards and figure out how you stand out. Take a look at Glassdoor.com and see how your company is doing. Make sure that you know what you are looking for, check your salary ranges and benefits packages, know which trade-offs you are willing to make on a candidate and ensure that you're not just on a wild goose chase. Sometimes you're trying to hire experts and sometimes it's just "warm bodies", these interviews require different things. Recognize that the last year or two are possibly the most difficult times ever to hire an experienced developer. Demand is very high right now and salaries are very competitive. Now to the actual interview: - Whiteboard coding is acceptable, but actual coding is much better. Give them a laptop with tools and no net connection and let them build something. - Don't be afraid to throw people out. You will be doing lots of interviews, possibly 10 or more to fill a single position. If this person is a complete mismatch, save everyone's time and let them go early. - When asking questions about previous jobs, be very specific about what elements the candidate actually completed. The industry still has lots of deadweight and charlatans. You want to avoid people who were "part of a project" without actually "delivering the project". - Some of my favorite questions: -- What new languages or toolsets have you learned in the last 12 months? -- Tell me about your side projects. -- What are your favorite programming tools? (Experienced programmers should have some type of "toolbox") -- Do you contribute to any development community? (stackoverflow answers, google groups on FOSS products, etc.) - Some classic questions: -- Tell me about failure at a previous job, how did you recover or deal with the fallout? (this one should always have an answer, people fail, you need them to be able to recognize failure) - Ask them business questions, especially about their previous jobs. I try to get an idea for company size, team size, involvement with other stakeholders. Most software has multiple stakeholders and sometimes dealing with those stakeholders is just as important as programming competency. The key thing I look for is some type of continuous training and experimentation. Programming is a rapidly evolving field, there is always something to be le
-
- 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 think #8 is very important. Don't wait six months for the guy to "settle in" if it's obvious that he's a time-wasting moron. Here are some other rules #9. Coding tests are not effective at finding senior people. Coding tests are exactly like computer science homework problems; a trick question and 12 lines of code. They reward candidates with recent practice doing CS homework problems. Senior devs on real projects don't code that way. They nibble away at a big problem a little every day until it's done. #10. Don't wait for the "perfect" candidate. Pick the best candidate who's "pretty close" and apply rule #8 if needed. If the new hire works out, he starts working down your backlog soonest. If he doesn't work out, fire him and continue looking. #11. People who can think are rare. People whose resume says they can program in WhizBang 2013 are common. Concentrate on finding people who can think. They can *learn* WhizBang 2013. #12. Team fit is more important than skill set. See previous rule. A bad team fit can make your whole team unproductive and grouchy. The damage from a poor skill set is usually more localized.
-
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 think #8 is very important. Don't wait six months for the guy to "settle in" if it's obvious that he's a time-wasting moron. Here are some other rules #9. Coding tests are not effective at finding senior people. Coding tests are exactly like computer science homework problems; a trick question and 12 lines of code. They reward candidates with recent practice doing CS homework problems. Senior devs on real projects don't code that way. They nibble away at a big problem a little every day until it's done. #10. Don't wait for the "perfect" candidate. Pick the best candidate who's "pretty close" and apply rule #8 if needed. If the new hire works out, he starts working down your backlog soonest. If he doesn't work out, fire him and continue looking. #11. People who can think are rare. People whose resume says they can program in WhizBang 2013 are common. Concentrate on finding people who can think. They can *learn* WhizBang 2013. #12. Team fit is more important than skill set. See previous rule. A bad team fit can make your whole team unproductive and grouchy. The damage from a poor skill set is usually more localized.
Team fit is definitely more important than skill set, but less important than the ability to think, IMO.
-
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'm less concerned with someone's ability to learn quickly, as much as I'm concerned with his ability to learn thoroughly. I've seen people being able to write some hackish, working but ugly code in two days after meeting a new language, but unable to get their code straight after three more months, and people not being to produce anything for two weeks, but producing production-grade code right after that. It's just different learning patterns. Since you spend 90% of your time on code on maintenance, I'd say the first type is a liability, whereas the second one may incur a higher up-front cost for each new technology you introduce, but this cost is more than covered by the economies you do during maintenance. Of course, there are the extremes - slow learners which never produce usable code and fast learners which always produce usable code. But IME these are rare. Besides both categories being rare, the underperformers are quickly eliminated by the job market (they get so many bad references that you never call them to an interview, provided you check references), whereas the overperformers rarely look for a new job - when they do, they target a very specific position. IME, only experience gained after quite some interviews will allow you to tell the difference. OTOH, also IME, this is where coding tests make sense - not because the code alone allows you to gauge the interviewee, but because you can use the code the interviewee wrote as a pretext/base for a more hands-on discussion. You can even try pair programming during the coding test, to see how things work out.
-
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 thoughts http://www.darrollwalsh.com/post/2012/10/22/Developer-Technical-Screenings.aspx[^]
Darroll
-
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:
since you will probably spend more waking hours with them than your wife.
Why would you expect his wife to spend more time with them? :omg:
-
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.