Developer Job Interviews
-
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.
-
- 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!
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
-
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.
-
Nice :) did you get the Job or not? if not I would urge you to consider that winning can sometimes be loosing
They offered me the job, but I didn't take it. One of my pet hates as a developer are people who think they know better than the manufacturer's documentation. Unfortunately my current employers have a few of these too, except they're not in any position of power.
-
They offered me the job, but I didn't take it. One of my pet hates as a developer are people who think they know better than the manufacturer's documentation. Unfortunately my current employers have a few of these too, except they're not in any position of power.