|
Typical interviews that I've had in the past frequently say either "tell me about yourself" or "show my some code" but rarely seem to bring out the good technical qualities that I would look for myself. What approach can I take that is more suitable for technical candidates for programming positions? Having them write code in front of you has frequently not been as useful as expected due to nerves, new environment, different computers, etc. |
||||
|
|
First of all, never interview alone. In fact, if you're the primary decision-maker, don't be the primary interviewer. You can learn more by letting one or two of their potential teammates interview them while you observe, and you get to see how good a team-fit they are if you can do that with different people over two interviews. (ie. meeting up to four of their potential colleagues.) I do have themes for the two interviews though. The first is generally very soft-skills-based. Let's talk about your current job, how the process works, what works well for you, what works badly. The second is very technical. Send me some code ahead of time that you're happy with, proud enough to say "Yes, this is how I code." Then be ready to talk through it for an hour with technical people I already have. I know all the arguments about their possibly sending code that isn't really theirs, but I maintain that if they can take a rigourous review from developers I know to be quality, they may as well have written it. But, honestly, if anyone is that much of a cheat and liar, I'm likely to catch it in the first interview. It's something I deliberately try to find out. This technique hasn't failed me yet. When it does (as whiteboarding did -- I hired someone who was very good at a whiteboard, but a useless developer), I'll rethink. I don't believe there's a perfectly flawless system. |
|||||||||
|
|
I go for low tech - often I'm hiring outside of my own comfort zone, so going into the weeds with someone on a particular technology isn't going to tell me much because I expect that if they are worth hiring, they know more than me. My general strategy is to get them talking about a recent hard problem or big learning experience. If they say "I haven't had one" it's almost always a 'do not hire' because I can't imagine a technical worker working up to their potential who didn't have a hard problem or learning experience. I get them talking about why it was hard, and inevitably all the passionate frustration comes pouring out. In the midst of that, I sneak in the technical questions. Eventually we round out with "what eventually fixed the problem?" and "what would you do differently this time?" It's not usual for this to be interpersonal rather than technical... but I usually drive us along until we get to a technical problem if I don't get there the first time. I generally watch for problem solving skills, passion, and how they mix knowledge and learning with asking for help and working as a team. A technical team is special, and I always want to know that the guy will be able to communicate technically with his peers. As a backup, in case I got a problem, but just couldn't get to the technical meat - I'll get them talking about a recent technology, the tradeoffs with competitive technologys, patterns or methodologies, and how they've maximized the potential of these things. Not my favorite, as it is easy to talk bit and know little in this way, but I can usually detect hype vs. content. If all I get is hype, it's a no-go for me. |
|||||||||
|
|
When I am interviewing technical candidates, there are a few specific things that I'm looking for: Personality-- How will they fit in with the team? Is their personality compatible? Communication Skills--How are their communication skills? Can they convey a technical concept to a technical person, a technical concept to a non-technical person, etc? General Attitude--How likely are they to be a poisonous or negative influence? How do they handle criticism? Problem solving skills--Can you take a business problem and develop a technical solution to it? Passion--Can you be passionate about something you're working on? Conceptual Knowledge--Do you actually know stuff and can you admit it when you don't? After I get through all of these things (not necessarily in this order (except Personality, which is always first)), I feel like I can make an informed decision about the quality of the candidate. |
||||
|
|
|
I would make them sit in front of a computer with a dev environnement .tell them they have a software (explain them what it does and how to run through the application) and a list of Jira issues. Now let them handle the whole thing. Usually good people are people who knows where to look for information and that can say, "I don't understand this, I'm stuck, please could you explain it to me?". Plus you can see how fast he can comprehend someone else's code and debug. The demonstration software and issues should be near what you would expect him to do if hired. Also debate over an ongoing conception and ask them their opinions. They should be able to say yes or no and even change their minds after a debate. Every one can get wrong but good assets can say "I was wrong" or "this is why you are wrong" early in development cycle. Last thing, if you expect them to be part a team and to evolve inside it, someday they will end leading a part of it. Try letting them delegate some issue solving to a junior or intern and see how it goes. If the junior is pissed off they are doing it wrong. If the intern ends alone or without something to do he lacks leadership. I'm not someone that know everything, I'm more a google nerd type but I'm a really good developer no matter what. Paper pen tests are just useless in my case. This is my opinion and experience I hope I'm near what you expected. It's just every day situations applied to recruitment which I think really lacks during interviews. |
|||||
|
|
Sit with them as they use the IDE or other tools of the job and give them something to do at a computer. It's not just purely can they get the code right, but: 1. do they know their way around? 2. diplay basic keyboarding skills 3. can they tell you why they do what they do? 4. coding style - at least have one 5. Do they ask necessary questions? 6. Look at some existing code: ask if they can tell you the good, the bad and the ugly (At least find out if they've seen the movie.). I've heard all the arguements about being nervous and making minor mistakes, but any question you can ask sitting at a table, you can ask at the keyboard. If it's more of a conceptual question, go to the white board. Why is this a last resort or never considered at all? |
|||
|
|
|
Normally I do not just paste links but there have been some very good posts in relation to your exact question. The 1st one is quite inclusive of what is required when interviewing an engineer and was written by Jeff Atwood: The next blog post was written by Scott Hansleman and has some specific question you can draw from (and I have as the list and additional ones in the comments) are very good on the OO front: |
|||
|
|
