Interviewing / Team Building

I’ve talked about interviews and team building a bit before in my “team” post.  I suppose you could view this as the other side of the coin for team building. The dark, dirty underside…  It ain’t pretty and I can admit that I am part of the problem but…  By perceiving my role in the status quo, I have an opportunity to change.


So…?   Basically it’s another WTF moment.  And we just offered contract positions to 3 new people.  They all start today and tomorrow.

Oh and we use FizzBuzz as the absolute minimum requirement for working on our team.

Argh / Sigh /  W… T…  F…

At the moment, I don’t have a clue.  We’ve tweated our hiring process at Intel.  First off, let me say it’s REALLY hard to get a job on my team.  Head count restrictions and a lack of turn-over make it damn near impossible.  My manager tried 5 different ways over a 3 year period to get me converted from a contract worker to a permanent employee.  I was in a place where I could wait and deal with the on-again off-again rules for contracting for Intel.  In the end it worked out.

After I converted, we picked up a recent college grad (RCG) with zero work experience as a contingent worker (aka contractor).  He was hungry and actually listened to what I was trying to teach him.  Because he was an RCG, we could play the game and got him converted before his 18 month contract ended.  To this day, I have no regrets about that decision.  In fact, he has done so well that we rarely work together any more.  He runs his own projects and I only show up in my “expert” role to help him solve some strange production issue.

How do we do it?

First, we have a list of questions on various topics that we ask in a phone screen.

  • How and why would you use recursion?
  • Which is better agile or waterfall and why?
  • How do I get multiple values out of a C# method?
  • What’s the difference between an attached property and a dependency property in WPF?
  • What’s your proudest professional moment?
  • Why do you do this kind of work?
  • Etc.

We’re trying to get a baseline understanding of you and your coding skills.  We ask technical and non-technical questions.  Some of the questions we ask I couldn’t answer correctly when we wrote them.  I know them forwards and backwards now.  We try to ask more open ended questions so that we can understand how you think, how you communicate, and glean insights into your personality.  Failing to answer any one question isn’t an automatic exclusion.   Failing to answer ALL of the technical questions is.  <shrug />  If you can’t answer even one of these questions correctly, then you aren’t going to survive this place.  After we’ve asked our questions, we open things up for you to ask questions.  If the interview went poorly, you’ll get this about 15 minutes into the 25-30 minute phone screen.  If things went well, we’re at 20 minutes.  That gives the candidate time to ask questions.  But really, the candidate is just along for the ride.

The next step is a programming interview.  We provide a list of programming/thought exercises.  Ideally, we all gather in a room.  The candidate whiteboards their ideas while I type the code into Visual Studio.  A projector shows the code on the wall, so they have access to intellisense.  We debug their code and once the solution works, we move on to the next exercise.  Some of the problems are purely mental/discussion topics.  “How would you do this?”  Again, we’re trying to figure out how you problem solve, interact with your peers, and handle stress.  That last one might sound a bit shitty, but we do production support.  Things can get very tense when something blew up in production and billions of dollars are on the line.  (Remember Intel made 58 billion last year.  Yeah that was with a ‘b.’  My apps help drive that effort.)  So there is always a degree of stress in our work.  We want to know up front if you can handle that kind of stress.  Do you roll with it or do you freak?  I need to know.

Typically, after an interview, we get together and decide what we want to do next.   If the interview went really bad, we’ve already decided through chats that this is a non-starter.

After reading the above articles, I can see how we are playing into the game just like everyone else.  We do take steps to separate coding skills from drive and personality.  I know we push a candidate and turn up the stress factor.  We are cognizant of our actions and the reasoning behind them.  Upon reflection, I can see that we’re not doing our best to find the right talent.  I suppose that is something…

Does this process work for us?


I’ve seen candidates that slammed through everything then fell flat once they got in the office.  Lack of drive.

I had one contractor get mad at me because I rejected 80% of his “designs.”  He always wanted to create something new as opposed to following established patterns and assimilating into the code base we created.  He said I was destroying his creativity.  Really?  How about I fire you and you be creative somewhere else?  Yes, it got that bad.  One day, I told him to go home.  I didn’t have time to deal with his drama.  If he refused, I’d have security escort him out.  Obviously, the conversation didn’t go well.  In the end, it’s my ass…  my career…  my income…  my life… if the code blows up or can’t be maintained.  I take that responsibility very seriously.

Really, I need mercenaries, not artists.

The filtering out part seems to be working reasonably well.

I had a candidate storm out of a face-to-face meeting aka Rage Quit during the interview because he didn’t like my tone.  The other guys said I was being extremely nice.  It was the candidate that refused to read the problem and follow the instruction clearly listed in the first sentence.  I had asked him three times to read the first line of the problem so that he could fix what was missing in his code.  We still joke about that guy.  “Only Ivan could get someone to rage quit 10 minutes into an hour long interview.”  We joke in good fun, but we all learned a very valuable lesson about temperament and being able to code to a written spec.  (We work off TFS work items 95% of the time.)

I had one guy yell at us to stop talking so he could think during a phone screen.  We had axed him from the candidate pool before the phone call ended.

I had one woman show up for about 40 hours in her first 3 weeks of work.  We found out later she had head trauma from a car crash during her couple days of employment.  The crash effectively rattled her brain pan.  The unfortunate part is that without a doctor’s note, we still couldn’t bring her back on because she was black listed by HR for not showing up.  Too many others used the excuse with out proof for HR to take the risk of letting her come back.  <sigh />

So what are we to do?

How can we improve the process?

I’m not sure.  I think the suggestions from SockPuppet are fair and reasonable.  I know we can do better.  I have the RA to improve the process.

  • Repeatable.
  • Quantifiable.
  • Consistent.
  • Fair.

Hopefully, our latest up-take of contractors will go well and I can go another 18 months before I have to go through the hiring process again.    Maybe by then, I’ll have a better system in place.