- Determining What Kind of Programmer to Hire
- Writing the Job Description
- Selling the Hire
- Recruiting Full-Time Employees (FTEs)
- Recruiting Contractors
- Reviewing Resumes
- Narrowing the Field
- Preparing to Interview
- Interviewing
- Making the Decision to Hire a Programmer
- Making the Right Offer to a Programmer
- Follow Up until the Programmer Accepts
- Summary
- Tools
This chapter is from the book
This chapter is from the book
This chapter is from the book
Interviewing
Take notes! Walk into interviews prepared to take notes on what candidates say. It’s amazing how a series of candidates will blur together without notes to tell them apart.
Make time before the interview to prepare your questions. Write them down. Carry them into the room with you.
Make eye contact (and make sure the candidate can make eye contact with you). Make note of what candidates communicate nonverbally; how they comport themselves; whether they’re on time, early, or late; and afterward whether they send a thank-you. And make notes about what your team members, colleagues, and boss have to say about the candidates.
At the same time, don’t be so busy writing down what candidates say that you don’t notice who they are.
Ron makes it a practice never to interview a programmer in a room that doesn’t have a whiteboard; he looks for candidates’ willingness, even eagerness, to get up and explain to him how they approached a problem they faced in a previous company, to explain the architecture and design of one or another of their previous projects, or how they would face one of his team’s problems now. It can help differentiate the talkers from the doers.
You’re going to want to know the answers to questions like these:
What aspects of your last job did you most like?
What were your colleagues and your management like?
Tell me about some of the things you and your supervisor disagreed about.
What led you to leave the companies you previously worked for?
What attracts you to our company?
Why are you looking for another job now?
What do you want to get out of your job?
Learn to ask questions that are open-ended—that candidates can’t answer with a yes or no—like these:
Tell me about. . .
How were you able to accomplish . . . ?
What was your role in . . . ?
If you had led the development effort on that project, what would you have done differently?
What best practices are you most fond of?
What are your strongest technical strengths?
What are your strongest nontechnical strengths?
If you think of the fabric of programming as triangular, with the points representing design, coding, and debugging, tell me about the part of the fabric on which you would most like to spend your time.
Where would you place yourself on a continuum where one end is developing gnarly algorithms and the other is developing customerfocused UI?
Imagine a line. One end is leadership. On the other is teamwork that’s so fully collaborative that leadership is totally shared and no one on the team would be able to identify a leader. Where on that line would you place yourself?
How would your manager describe you?
Tell me about your comfort level with asking for assistance from others.
Where do you fall on a continuum that ranges from highly structured, where your tasks are spelled out completely, to one that is entirely freeform and you have to make decisions, often without having all the information you’d like?
How do you like to be managed?
Ask for examples:
Think of a time when you knew you could not make a deadline. What did you do?
What was the most interesting problem you faced in a former project? How did you solve it?
Tell me about a time when you. . .
Give me an example that illustrates your leadership style.
Think for a minute about the most stressful situations you’ve been in at work and tell me about the one you think was most stressful of all. What did you do to deal with it?
Have there been times when you needed to formulate a new solution? Tell me about that time, and about what you devised.
Tell me about a best practice you played a role in getting your team to adopt.
Describe a time when you displayed extraordinary initiative.
Have you worked with a UI designer [product manager, business analyst . . .] to translate customer needs into technical requirements? Tell me about that collaboration.
Tell me about a time when your manager was annoyed with you or with your role on the team. How did you respond?
Think about the teams you’ve been part of and tell me about a peak teamwork experience. What contributed to making that memorable?
What have you done when you’ve had far too many tasks assigned to you than you can handle? When that’s been the situation and you could see yet another task coming your way, what did you do?
Tell me about a time when you successfully persuaded your manager or your team to adopt your position.
How have you handled making formal presentations in front of large and small groups? Tell me what that was like.
Have you had to present technical solutions to highly nontechnical audiences? How did that go?
Describe a time when you advocated creating a better customer experience.
Describe a situation in which you had to tear down code and redesign and recode from the ground up.
Get candidates to give you details. What role did they play in the projects they cite on their résumés? Get them to tell you how they accomplished the achievements they claim. Ask them about the most difficult problems they had to solve in accomplishing them, and ask them to walk you through their solutions.
Think of a problem situation that vexed a team you’ve managed (and would be appropriate for candidates to solve) and ask them to suggest how to solve it.
But don’t ask leading questions. Do truly make your questions openended; give candidates room to answer as they think appropriate.
Ron writes questions with the intent not only to understand what candidates know and how they think, but to learn something from each and every candidate that he has the opportunity to interview, no matter for what job. “We’re interviewing these candidates because we think they can bring something to our company. My attitude is to figure out what they know that I don’t (yet), and to start learning from them. Sometimes it’s technical; other times it’s how other companies or managers have handled challenges or, from college hires, how the computer science curriculum is being taught these days.”
There are also key logistical questions you’ll want to ask:
What will commuting to our offices from where you live be like for you?
How much travel do you like (and how does that fit with the amount of travel I foresee in the job)?
What are your compensation expectations?
One final note on preparing questions: Keep them legal. Your questions should never in any way suggest or encourage candidates to tell you about their
Marital status
Parental status
Age (particularly whether 40 or over, but don’t go there with anyone)
Current salary or compensation (at least in some parts of the United States and the world)
Ethnicity or nationality
Disability or perceived disability
Religion
Sexual orientation