Category Archives: work

navigating the job search and interview process

I started a new job today.  I’d been working on two developer platforms centered on the XAML language (the Windows Presentation Foundation and Silverlight) for the past nine years.

Change like this is healthy.  I’ll be working with some people I know, on something pretty different and also exciting, focusing on some technology I’ve worked on in the past (browser and graphics) – on the Windows Phone.  Right now I’m ramping up on my new team, so the next several weeks are bound to be fun and a bit chaotic (at least in my own brain).

One of the interesting angles on this for me has been that this was the first job change I’d actively sought in about sixteen years.  Prior to this, all of the desired change had come to me.  This time around, I was simply ready for something new.

My job search criteria were annoying vague.  Earlier in my career, I’d pursued specific types of technology.  This time, the technology focus was very secondary.  I simply wanted to work on a product that mattered, and to work with good people.  From the standpoint of a hiring manager criteria like this can be maddening, or it can be golden.  Managers who might be reading this will know how they would feel hearing it from a candidate.

I started my search with my current employer by perusing the internal job listings, but found that frustrating.  I found myself looking up the hiring manager, to see whether I knew them or knew anyone working in their organization.  I wanted to have some sense of what to expect in terms of job satisfaction, team culture, and opportunity.

After a short while, I simply began to look up people I’d worked with in the past, and checked to see whether they had openings.  If they did, I’d pop by for what we call an “informational interview”, where the candidate and hiring manager get to know each other a bit, assess whether there’s a potential fit, and decide whether or not to take a next step (setting up a formal interview loop).  This was an interesting process – I’d just to a drive-by informational, and get some sense of what was going on, and we’d discuss whether or not it might make sense.

One of the advantages of doing this with a network of people you know, is that there’s a level of trust and honesty to the conversation.  We’d get to talk about whether or not the type of opportunities would really work, and also talk about potential issues.  A couple of times my colleague would let me know that they themselves weren’t completely happy where they were.  Having been in the same place myself, I’d also feel obliged to be open about this with a friend.

It’s fair to say that heading into the interview process was a bit nerve-wracking.  The funny thing is that I do lots of technical interviewing of candidates myself.  Being on the other side of the table for the first time in about sixteen years was interesting.  I know enough about interviewing to know that even good candidates have bad interviews.  Also in some situations, one bad answer to a technical question can tip the scales irreparably against you.

Some years back while preparing some technical interviewer training, I ran across the following anecdote in William Poundstone’s book How Would You Move Mount Fuji?, an interesting look at the technology industry’s “cult of the puzzle" approach to technical interviewing :

A more recent experiment attempts to treat the hiring situation more directly. Another of Rosenthal’s students, Frank Bernieri (now at the University of Toledo), collabrated with graduate-student Neha Gada-Jain on a study in which they trained two interviewers for six weeks in accepted employment interviewing techniques. Then the two people interviewed ninety-eight volunteers of various backgrounds. Each interview was fifteen to twenty minutes, and all the interviews were captured on tape. After the interview, the trained interviewers rated the subjects.

Another student, Tricia Prickett, then edited the interview tapes down to fifteen seconds. Each fifteen-second clip showed the applicant entering the room, shaking hands with the interviewer, and sitting down. There was nothing more substantial than that. You guessed it – when another group rated the applicants just on the handshake clip, their opinions correlated strongly with those of the two trained interviewers who had the full interview to work from.

While not completely conclusive, this indicates many people form their opinions about someone even before the person has said anything, let alone answered any interview questions.  Please go ahead and check out this excerpt of the book (including this anecdote), it’s worth it.  My hope is that you’ll challenge yourself never to fall into this pattern, whether you’re interviewing people or not.

The fact of the matter is you can’t control whether or not your interviewer does this.  You can do you best to create a favorable first impression of yourself, and then do your best to prepare for the interview.

In my case, this meant sharpening up on the technical question front.  I’ve been a manager for the past several years.  That means primarily talking with people about their coding, rather than doing much myself.  And since one of the key measures of capability in our field is one’s coding ability, I needed to do some homework. 

There are definitely other types of questions that come up during interviews.  In my case, since I was interviewing for development manager and lead positions, as you’d expect interviewers would ask me about managing – how I grow people, how to deal with various tradeoffs, and with potentially interesting management situations.  And there were also a fair number of questions about engineering decisions (as opposed to problem solving and coding).  Since I’ve been more focused on these things in my previous role, the problem-solving and coding areas seemed like a good place to concentrate my preparation on.

I approached it much as I do distance running.  I set aside a certain amount of time each day to do two types of coding – problem-solving on some potential interview questions, and then some coding projects of my own.  I felt this combination was important, because solving the interview types of questions can be fun, but it’s less satisfying engineering than taking a bigger problem on.  I did this for several weeks, while doing the informational interviews, and hoped that this prepared me for the technical interview grind.

When it came time for the formal interview loops, I forced myself to try to get adequate sleep, and do what it took to go on an even keel.  This meant going out for a good run before the interviews, as running helps to equalize me emotionally.  And usually I’d spend 30-60 minutes before the loop “warming up” with some technical problems.  In other words, I tried my best to remove as many of the variables as possible, so that the interview process stood a reasonable chance of reflecting what I could actually do.  Again – similar to the way I like to approach running a distance event.

The other lesson I tried to draw into this is that there would be good days, and less-good days.  I tried to take the longer view that the bad days would help me to improve the next time around.  And while it didn’t always feel good, this turned out to be the case.

In the end, I felt pretty happy with the way things turned out.  It’s a stressful process, because it feels like you’ve got some important things at stake.  It’s not something I’d choose to do every day.  But I had a manager who chose to do this each time we finished work on a product.  Four times out of five, he’d choose to stay put – but you’d always know he was there by choice.  Funny thing is, I mentioned this to one hiring manager during an informational, and he’d worked with the same guy.  Small world.

Now that this bit of adventure is over, it’s time to get to work, isn’t it ?