Blog For .NET

For the last three years I’ve been involved in our company’s development team hiring process.  We’ve defined it, refined it, reworked it, and reworked it again.  We’ve made mistakes and made great hires.  I thought I’d share a few thoughts on the subject which you may find useful. 

For every job posting online, we get 100+ applications.  For every diamond in the rough, there are many more applications we wish we didn’t spend time on.  We only want to hire great developers and have a rule: “no false positives”.  Although we may miss a “diamond in the rough” application, we try to make the time we spend hiring as effective as possible.  Usually we “ding” anyone who:

1. Doesn’t have a cover letter.
2. Has numerous spelling errors on their resume or cover letter.
3. Submitted an application that takes us more than 30 seconds to determine what position you’re applying for and where you’re coming from (e.g. current job is “help desk”, but applying for a programmer position; went to school for art history).  For a better explanation check Rand In Repose’s posting.

So how do you avoid these “dings”?

1. Have someone proof read your resume
2. Check out other peoples resumes, e.g.  Resumes That Knock ‘Em Dead and see formats that appear appropriate for the field you work in.
3. Use a cover letter customized to the position.  Cover Letters That Knock ‘Em Dead has a number of samples to get an idea of the tone and content of what your cover letter should contain.  Make sure to have someone proof read your cover letter before you apply.
4. Put things on your resume that HR people, recruiters, and automated systems can find.  I don’t mean highlight or boldface all your references to technologies (who started that trend anyways?), use certifications, associations, conferences, and trainings.  HR people aren’t developers.  They don’t know the difference between C# and VB.net or smalltalk and Ruby.  They know keywords they’ve been asked to look for, so make their job easier. By getting certifications, you may not be advancing your education so much as easing the first barrier to entry at any organization - survive the resume screening process.  Certs, conferences, and user groups indicate you’re serious about what you do for a career and advancing yourself professionally. HR people like this.

You’ve submitted your cover letter and resume, and you get a call back.  The usual process is something like this:

1. HR person/recruiter calls to qualify the application.  They want to sell you on the job - the company, the job itself, the benefits and also determine if this is a good fit for both parties.  They’ll ask the standard personnel questions and more specific questions they’re told to ask. for example
   1. Why are you looking for a job?
   2. When can you start?
   3. What salary are you looking for?
   4. What kind of job are you looking for?
   5. What are your professional goals? -this one is very important. I can’t tell you how many people have applied for developer positions and told me “I want to get into business analysis/project management/developer management” - the job posting was specifically for a software engineer. Why did you apply?
   6. Suppose you and someone have similar resumes. What makes you different?
   7. What books have you read recently?
   8. What blogs do you subscribe to?

   Be prepared for all of these.  The last three are really where we begin to distinguish ambition/character from professional qualifications. They’re good indicators (like education and certification) about what it is you want to do, how motivated you are, and a rough guide to your technical skills.

2. The technical phone screen.  This person is usually the hiring manager.  His goal is to further qualify you as a potential hire and to help sell you on the job with more details. Expect more technical questions and questions on your experience with certain technologies. 
3. In person interview.

Hopefully you made it through the screening process and are asked for a personal interview.   Get there early - “if you’re on time, you’re late”.  Once there, relax, use the bathroom, and review your information again- who the company is, what they do, the job description, and what information you’ve given them (resume, cover letter, references etc.).

Steve Yegge has a good description of the general onsite interview process and a whole lot more at “get that job at google.” From his posting:

Every “experienced” interviewer has a set of pet subjects and possibly specific questions that he or she feels is an accurate gauge of a candidate’s abilities. The question sets for any two interviewers can be widely different and even entirely non-overlapping.

 A classic example found everywhere is: Interviewer A always asks about C++ trivia, filesystems, network protocols and discrete math. Interviewer B always asks about Java trivia, design patterns, unit testing, web frameworks, and software project management. For any given candidate with both A and B on the interview loop, A and B are likely to give very different votes. A and B would probably not even hire each other, given a chance, but they both happened to go through interviewer C, who asked them both about data structures, unix utilities, and processes versus threads, and A and B both happened to squeak by.

 That’s almost always what happens when you get an offer from a tech company. You just happened to squeak by. Because of the inherently flawed nature of the interviewing process, it’s highly likely that someone on the loop will be unimpressed with you, even if you are Alan Turing. Especially if you’re Alan Turing, in fact, since it means you obviously don’t know C++.

 The bottom line is, if you go to an interview at any software company, you should plan for the contingency that you might get genuinely unlucky, and wind up with one or more people from your Interview Anti-Loop on your interview loop. If this happens, you will struggle, then be told that you were not a fit at this time, and then you will feel bad. Just as long as you don’t feel meta-bad, everything is OK. You should feel good that you feel bad after this happens, because hey, it means you’re human.

It helps to understand the perspective of the employer on the interview process. Joel Spolsky is an excellent resource on hiring developers.  His book entitled “Smart And Gets Things done“ and blog posting The Guerrilla Guide to Interviewing are essential resources for companies trying to find great talent. From his posting:

You should always try to have at least six people interview each candidate that gets hired, including at least five who would be peers of that candidate (that is, other programmers, not managers). You know the kind of company that just has some salty old manager interview each candidate, and that decision is the only one that matters? These companies don’t have very good people working there. It’s too easy to fake out one interview, especially when a non-programmer interviews a programmer.
 
 If even two of the six interviewers thinks that a person is not worth hiring, don’t hire them. That means you can technically end the “day” of interviews after the first two if the candidate is not going to be hired, which is not a bad idea, but to avoid cruelty you may not want to tell the candidate in advance how many people will be interviewing them. I have heard of companies that allow any interviewer to reject a candidate. This strikes me as a little bit too aggressive; I would probably allow any senior person to reject a candidate but would not reject someone just because one junior person didn’t like them.

Look for passion. Smart people are passionate about the projects they work on. They get very excited talking about the subject. They talk quickly, and get animated. Being passionately negative can be just as good a sign. “My last boss wanted to do everything on VAX computers because it was all he understood. What a dope!” There are far too many people around that can work on something and not really care one way or the other. It’s hard to get people like this motivated about anything.

Bad candidates just don’t care and will not get enthusiastic at all during the interview. A really good sign that a candidate is passionate about something is that when they are talking about it, they will forget for a moment that they are in an interview.

When interviewing we want to give the best impression possible. This is both easier and harder than it may seem.  According to Dave Munger in this post and Malcolm Gladwell in his book Blink(well worth reading), you’ll have about six seconds to make that first impression.  Presenting yourself with confidence and a humble smile will go a very long way to set the right tone for your interview.

Each individual interview will have several distinct sections.

1. You’ll meet and shake hands.
   A recruiter once told me that at this moment, I should lean forward a little and stand on my toes.  He said it would make me stand up straighter and more importantly it would make me feel a little silly. This would in turn make me smile and relax. When I relaxed, the interviewer would relax.  After interviewing with 4 companies and 20 different people I will tell you, he was exactly right.  As the interviewer of 50+ people for two different companies, I can tell you the opposite is true- the candidates who don’t present themselves well usually have a harder interview as I try to draw them out.
2. The interviewer will tell you who they are and what they do. 
3. They’ll ask you some questions. 
   Be polite, be eager, and be positive during all of this. 
4. Finally they’ll ask you if you have any questions.
   You should always have questions. Questions show you care about the position. It helps draw the interviewer into the conversation.  It’s also one of the only places during the interview process where you’ll get an idea what the job would actually be like.  Questions like: 
   • Who would I be working with? (Are they of your caliber? Are they as motivated as you are?)
   • What would be the first project/team I’d work on here?
   • What would I need to do to meet or exceed expectations after 6 months? (OK this one is a little cheesy, but sometimes effective)
   • Who would be my manager?
   • What feedback loop do you have for my performance?
   • What is the primary focus of the position (you may get a different answer depending on who you ask) - technical? interfacing with users? project management?

So you’re interview is done, and you’re on your way out.  Don’t forget to thank everyone you met, including their “staff”.  Take a moment when you finally get out of there and write down some notes of your impressions (you’ll forget things by the time you get home) what people said, the specifics of the actual job, etc. 

A few final notes:

• 2 weeks notice to your current employer is standard - if they expect you to leave without notice, it says something about how much they care about people.
• Always get time to think about the offer- “I have to speak with my family” is a valid answer.  Anyone who goes for the hard sell is sketchy.
• If things don’t pan out, it’s probably because someone (and it only takes one) thought you weren’t the best fit.  That may be true, it may not, but better no fit than a bad one. 
• Big companies can afford a longer ramp up time and better training.  Smaller ones are generally looking for you to hit the ground running.  Don’t be upset if someone thought you’d require a little too much training to be useful to them- it’s them, not you :)

No Comments yet »