You are here: Home / Archives for Interviewing

Kissing Frogs Part 3: Frog Dos and Don’ts

December 11, 2012 by Leave a Comment

The first two posts in this series were from the point of view of the interviewer.  But suppose you are on the other side of the table?

Do’s

Do your research.  It’s really disappointing for an interviewer when a candidate doesn’t have the first notion of what the company or the team does, and it’s great when they have intelligent questions.  “I tried out your product, and it seems like one of your big challenges is integration with systems that customers are already using.  Is that right?  How are you handling that?”  So much better than somebody who doesn’t have a clue.  These days you can learn staggering amounts about almost anything on the Internet.  So check out the company, the project, and the people.

Do practice.  Interviewing is unnatural for most people.  You won’t have concise soundbites ready to roll out about the work you did in previous jobs.  You may be rusty or misremember the details.  It’s very, very useful to have some mock interviews before you go into the real thing, especially if you can do it with experienced interviewers who will be honest enough to give you candid feedback.

Do interview them.  You are preparing to commit huge amounts of your time to this team and this project.  It’s probably the biggest investment decision you are going to make – your time is your biggest asset.  So learn as much as you can while you are there.  Are these people you actually like?  Is the work inspiring?  Will you learn something and stay engaged for the long haul?

Do prepare.  Be ready for hard questions.  “Why didn’t you finish school?”  “Why do you jump from job to job?”  “Why have you been unemployed for the last two years?”  “Why did the product you worked on get panned by every review?”  Look over your resume through the eyes of a stranger (or ask another person), and think up the most difficult questions you can.  Answer them honestly, be open about mistakes (if appropriate), and tell people what you learned.  Don’t be bitter, don’t whine about your past co-workers .. be constructive.

Do be concrete.   I think the best questions are not open-ended and general.  But lots of interviewers use them, anyway.  Don’t meet vague questions with vague answers – ground your answer in detail.  Tell stories.  Not “I think I’m very results-oriented.”  Ugh.  Instead, “in my last job, I drove the marketing campaign for Jumble.  It was a tough push, but we delivered on time into five different channels, driving a positive awareness of 44% – the best result of any campaign our company had done.”

Do be passionate.  It’s deeply dull to listen to somebody drone on in a monotone listing facts and figures about their career.  Boorrrrinnngg.  It’s very interesting when somebody’s eyes light up as they share personal stories about things they’ve done that inspired them.  Find things to talk about that you are excited about, that you loved doing in previous jobs or educational experiences.  You’re a human being, not a resume – let people get to know you.  Share yourself and what you love.

Don’ts

Don’t assume!  If you aren’t sure you understand the question that you are supposed to answer, don’t launch off and answer it anyway.  You can ask, or you can explain.  Start by asking: “when you asked me to design an operating system, did you mean something like Linux, or something else like an embedded system?”  Some interviewers want you to dive in and don’t want to be interrogated, however.  You can usually tell immediately based on their reaction to your first question.  In that case, I’d stop asking and make some assumptions, but I’d be explicit about them.  “Ok, I’m going to assume unless you stop me that you want an operating system like Linux.  That means a general purpose server OS that …”  Then you are diving in and moving forward but are clear about the assumptions you have made.  In any case, don’t ask too many questions – the purpose of the interview is not to collaborate with your interviewer on defining an extremely precise question, it’s to show that you are good at answering them.  So make sure you spend most of your time on the answer.

Don’t be prickly.  Interviews are inherently awkward, and some people like to put you under pressure to see how you perform.  I don’t like that approach as an interviewer, and don’t use it, but many swear by it.  That means they are going to push you.  They’ll ask tough questions or brain teasers and watch you sweat.  They’ll push back on your answers, with varying amounts of respect, to see how you handle it.  Don’t freak out .. just stay calm, and focus on the answer, not how you feel about the situation.  That doesn’t mean that you should allow yourself to be abused or mistreated, but keep your cool even if the other person is pretty hard on you.  If you think of it as a test, and letting yourself get emotional is failing the test, that might help.  Don’t let them throw you.

Don’t be desperate.  This is easier said than done, especially if you ARE kind of desperate to get the job.  But realize that the odds may well be against you in any particular interview.  They may have a favored candidate lined up and are just checking to make sure they aren’t missing a bet.  You may be a bad fit for what they think they need in the role.  The more you build up the job in your mind and get wound up about how you absolutely have to get it, the worse you are likely to perform.  So be hungry, give it your best shot, but don’t think it all rides on that one interview, because life is mostly not like that.

Don’t lie.  This should go without saying, but a lot of people seem to think it’s ok to fudge on a resume.  Who is going to find out, right?  Wrong.  In the age of Facebook and blogging and LinkedIn, it’s crazy to be confident that you can get away with it.  If the employer finds out that you have been deceptive, that’s probably game over.  And the world is a small place, so there is every chance that they might tell the next company you talk to.  So in addition to it being immoral, it’s also dumb.  Just don’t go there.

I hope that these ideas help you prepare for your next interview .. good luck!

Filed Under: 1000x, 100x, 10x Tagged With: ,

Kissing Frogs Part 2: Conducting the Interview

December 3, 2012 by Leave a Comment

You’ve done all your prep, and now the candidate is sitting there looking at you.  You have an hour, at the end of which you are supposed to have a smart and insightful analysis on whether to hire them or not.  How do you spend your time?

Have Them DO Something – Don’t Ask General Questions

One of the most common mistakes is to ask open-ended softball questions.  “What are your strengths and weaknesses?”  The candidate then babbles on about how disciplined and passionate they are, and how their big weakness in life is that they just work so hard, and take things so seriously – they struggle under the burden of an extreme work ethic that was just the despair of their former managers.  And now several precious minutes of your interview are gone, and you haven’t learned a darned thing.

I think it’s infinitely better to ask them to create something.  Write code on the board for a multi-threaded lock implementation.  Write the Javascript code to update the notification count when a new message arrives.  Design a UI for managing notifications.  Design a set of metrics to monitor the state of the business.  Create a plan to track and land a milestone.  Whatever is appropriate for the job you need them to do.

If the design involves a skill they need to have, you will quickly see whether they really have it.  Many people can do a lovely job describing a design they know but are lousy at creating one.  Confronting a blank white board and having to invent something on the spot cuts through a lot of blather.  If it’s a skill they are still learning, you will also discover a lot in watching them try to tackle a real problem.

What To Look For

When I pose a design problem, whether the result is an algorithm or a visual design or a report or anything else, beyond the quality of the work, I’m assessing a number of other things:

  • Do they like solving this kind of problem?  Of course there is some added stress because it is an interview, but you can usually tell if they are enjoying the opportunity to dig into the problem or not.  I try hard to make an interview feel as much as I can like the real job – sometimes I will pose a problem that I’m actually trying to figure out at the time.  If they hate doing it in the interview, they probably aren’t going to love doing it all day long.
  • Do we make each other smart?  If we’re going to be working together in the future, hopefully we have a good working rapport.  Did the design conversation zip along efficiently and cover ground well, or were there constant misunderstandings and false starts?
  • Do they handle pushback well?  I always question some of their decisions (politely, of course).  How they handle that will tell you a lot.  The worst reaction is if they get mad, or they dogmatically insist that theirs is the best approach without explaining why.  Almost as bad is if they cave immediately and ask what you think they should do instead.  A great reaction is to explain the rationale for the original design, and to list a couple of alternative approaches and why they seemed less effective.  I hope they welcome new data, if I share something useful that would influence the design in a better direction.  In general, I want to know if they are passionate about finding the best answer, or about moving forward with their answer.
  • How do they handle underspecified problems?  I like to ask design questions without providing enough information, to see what happens.  The two most common failure modes are to flail around and to make wild sweeping assumptions.  If I ask you to design an airport, do you just freeze up, do you assume that it is LAX (rather than, say, an oilfield airport in Alaska), or do you ask?  In general, I’ve found that people who fall into either of those traps often have trouble if they get hired.  The freezers aren’t good at taking on hard new problems without having their hand held, and the assumers bull off in wrong directions and get themselves (and their teams) into a mess.

Other Questions I Like

 Once you have figured out whether they can do the work that is most important for your role, there are other questions that I’ve found effective:

  • Teach me about X.  Pick something that looks interesting in their resume – a skill they say they have, a project they worked on.  Have them teach it to you.  If it involves a design they did, ask them why they made certain decisions, and what they would have done differently in retrospect.  At the end of the discussion, do you feel well informed about the topic?  Any job I hire somebody to do will almost certainly involve explanations of complex topics, so it’s an important skill in its own right.  And, it will help you figure out how well they actually understood what they were working on.  If a very attentive listener can’t get a decent grasp of it quickly, they probably didn’t.
  • How would YOU interview somebody for this job?  This is a fun question, and I’ve found it is really useful.  It helps me understand what they think is important about the role and how thoughtful they are about testing for those characteristics.  It also reveals whether they have insight into other people and how to work with/manage them.
  • Share a great success and a disappointing failure in managing other people.  What did you do, how did it come out, and what did you learn?  If the person is interviewing for a management role, I want to know how they think about other people.  Are they insightful?  Do they passionately identify with the success of the people whom they managed?  If you are an experienced manager, you are pretty much guaranteed to have succeeded with somebody and failed with somebody, so you should have some interesting stories to talk about.  I also often pose a scenario – “Margaret is a superstar but runs roughshod over others, and you are going to give her a tough review calling her on it.  How do you prepare, what do you say, how do you handle it when she attacks you …”

Making the Call

At the end of the interview, you have to make a decision – “hire” or “no hire”.  Often, it’s obvious.  But if there is any doubt in my mind, I find it really useful to write down the reasons and talk them through with somebody else who has made a lot of hiring decisions.  By the time I finish explaining the analysis, I almost always realize that I’ve made up my mind, and can ground the answer in solid reasons.

The people you hire will largely determine how successful your team is, so choose wisely.  Good luck!

Filed Under: 1000x, 100x, 10x, 1x, Managing People Tagged With: ,

Kissing Frogs: Preparing for an Interview

November 12, 2012 by Leave a Comment

One of the most important things you ever do is to interview people for a job on your team, and it’s hard to do it right – people don’t come neatly labeled.  But somehow, you need to figure out if this person is that great ingredient you can mix into the stew of your team and make it better.  I’m going to spend the next three posts on interviewing, and we’ll start with getting ready.

What Kind of Prince Do We Need?

We work at FriskyCo, a small technology startup, and we need to hire a great database engineer to design, build, and run our back end storage systems.  Let’s start out by making a very short list of hard requirements.  And really, these supposedly “hard” requirements are just “highly desirable” – somebody who has some other amazing strength might be a good bet even if they look very different from the person we thought we were looking for.

We’ll start with skills they need to have.  Ideally, our new hire would already be an expert in building, using, and maintaining highly scalable storage engines.  In fact, they’d have already done the job, with the same technology we want to use, for some other company.  Unfortunately, if we insist on that, there are a tiny number of people in the world who would qualify (the so-called “albino unicorn”).  We can hold out for that miracle, or we can accept more ramp and risk to get a broader candidate pool.

On the flip side, setting up a system like this is not for amateurs, so we aren’t willing to hire just any competent developer.  After a bunch of debate, we’ve decided we should look for these “hard” requirements:

  • Has built and deployed some kind of highly scalable system.
  • Is an expert at some industrial strength database system.
  • Is a skilled systems programmer.

But skills are not enough; it’s vitally important to assess team fit – whether the candidate will flourish in our team’s culture.  FriskyCo is a startup, which means we move fast and change our minds as we evolve the product.  They have to be able to handle uncertainty and not freeze or freak out.  They have to be inspired and passionate about the mission we’ve undertaken – we’re too small to have people who aren’t bought into the adventure.  We have a standard set of things we always look for as well around their nature – they are smart, not too arrogant, can handle pushback, and are driven to get things done.

Now we have a bottom line on what we need in a candidate (or at least what we think we need).  Note that we don’t have any requirements around education or “years of experience” – those can be useful indicators that somebody has what you actually need, but I think it’s a big mistake to focus on them rather than on your true requirements.

Architecting the Interviews

This is a crucial hire for us and we’re going to have a set of people talk to the candidate.  We’ve done a number of interviews together, so I have a pretty good sense of what each person does well.

  • John, the head of engineering, is a good all-around interviewer and does a great system design assessment.
  • Mary, the front end dev, has a good set of questions around designing a well factored database schema and a solid API.
  • Rajiv is good at straight coding questions.
  • I’ll test to see if they can handle our environment, if they have passion for the product, and if they have design insight.

By thinking about what each person should focus on, we are much more likely to get decent coverage.  Otherwise, everybody may ask coding questions and we won’t know if we have a good fit for the team.  Or, even worse, most people spend their time on team questions, and we don’t know if the candidate can actually build anything.  Also, the team is crazy busy, so giving each interviewer a concrete set of things to probe is much appreciated.  It isn’t a straight-jacket – if an interesting digression comes up during the discussion, everyone knows they can and should pursue it.  But each interviewer should really try to nail those one or two things that we’re counting on them to test, and have a firm opinion at the end as to whether the person is a hire from that perspective.

One tricky situation is that you are hiring for a skill that the team doesn’t have yet.  Suppose in our FriskyCo example, we don’t have anyone who knows databases well.  What to do?  Sometimes you can wriggle around this (maybe one of the folks can assess a schema, even if nobody knows how to design one).  But that’s pretty risky – it’s often possible for a glib person with weak knowledge to snow somebody who has even less.  So I always try to draft somebody from outside the team to participate in the interviews.  Maybe somebody from elsewhere in the company, if you are part of a larger organization.  A contractor you’ve worked with.  A friend who will pitch in as a favor.  There just isn’t any true substitute for somebody who is an expert at the thing you need to evaluate.

Interview Etiquette

Every candidate is interviewing us as much as we are interviewing them.  How they are treated will strongly affect whether they accept an offer, if we extend one.  So:

  • Don’t be clueless.  It’s really irritating when the interviewer isn’t sure what position you are interviewing for.  They haven’t looked at your resume.  They putz around, trying to figure out what to talk about.
  • Don’t be a jerk.  Enough said.
  • Don’t dither.  One of the most annoying things you can do is not to make a decision.  Interviewing at some places is like dropping a rock into a bottomless pit .. you wait, and you wait, and nothing seems to happen.  Get all the information you are going to get, and then make the damn decision.

Next, we’ll look at what to actually do during the interview.

Photo credit: Nickodemo

Filed Under: 1000x, 100x, 10x Tagged With: , ,
%d bloggers like this: