How to Talk About Yourself in an Interview

When people ask me what they should know first about going into technical interviews, they get the same answer: be prepared to talk.

Interviews are stressful situations, and that stress can impact how well you communicate. You don’t think things through entirely. You don’t always make complete sentences. You laugh at really inappropriate times.  You get lost in tangents so far removed from the topic you can’t even remember what the topic is. And sometimes you just drop all your cards on the table in a show of desperation.

Preparing to talk isn’t about filling up time; it’s about prioritizing what they need to know about you. Flip the problem around and imagine you are hiring someone; what would you want to know about them? Here’s my list:

  • What have you built?
  • What is the hardest technical problem you have run into?
  • How did you solve it?

That’s it; those are the only types of questions that matter. Notice that all these questions are about the person being interviewed, specifically what they have done and how they did it. If you’ve been through interviews at some companies that are not as good at interviewing, then you probably had some questions on your list such as

  • Where do you see yourself in 5 years?
  • Why do you want to work here?
  • How do you handle disagreements with coworkers?

These are all worthless questions from the company’s perspective because predicting things is hard, especially when it’s the future. In all likelihood, the interviewer doesn’t know what they are looking for with these questions, and they are just being used to fill time. There is a caveat here however; I work for a company with an HR department that is responsible for taking care of some of the “would you actually work here if given an offer” questions (e.g. “are our benefits sufficient for you?”). If you’re applying for a very small company, you’re probably going to get asked these types of questions during the main interview.

How to Prepare

Get a stack of notecards.  On each notecard, write a title for a feature you worked on or a project you managed. Under the title you want a one sentence description of your main objective. Under that you want to list the most important tools that enabled the solution. Think of this as tags you’d put under a question on Stack Overflow. Under this, write down as many things you can think of that you tried and that failed; you can limit the list to 5 but don’t stop before you reach that number unless you actually tried fewer things (and that’s okay).  Underneath that, write down the thing that ended up working.

Now flip the card over. On the top, write down the single most valuable thing you learned from this project in a single phrase. You should list only the most critical insight to finding the solution to the problem. If you haven’t solved this problem yet, it should be the most recent insight you’ve had from it. Underneath this, write down one line about where this idea came from. Underneath that, repeat this process until the card is full.

I often hear people tell me they don’t know which features and projects their interviewers are going to want to hear about. They are going to want to hear about something in the materials that you gave them.  If you give them a resume, expect questions about stuff you worked on at your past jobs. If you gave them a link to your Github profile, expect questions about your projects.  If you gave them a link to your Stack Overflow account, expect questions about some of your answers. Make sure you have at least one card for each job experience you have listed, and ideally one for each bullet point you have listed for each job experience. Make sure you have one for each Github project that you have worked on in the last year. For Stack Overflow questions, just make sure you’re familiar with your most popular questions and answers (no need to write whole cards for them). That about covers everything you might be asked about.

Here’s an example card for a project from my Developer Story.

The Anatomy of a Good Developer Tale

Now that you have the Spark Notes for everything you might talk about, it’s time to practice actually saying what you’re going to say in the interview. Even with all the knowledge you have on these cards, it’s crucial that you can channel that knowledge into an engaging story. Luckily, there’s a recipe for that too.

Be Specific

Good developer tales are conversation-based. It’s about transferring knowledge from me to you that you might find interesting or useful in your own work. Conversations tend to die when there are no more holes to plug, so preventing that is extremely important. While broad insights sound intriguing and might make you sound really intelligent, it’s important to remember the goal that we should be encouraging the interviewer to ask us more questions at every step along the way. The best way to do this is to be specific.

Wayne's World

^This scene from Wayne’s World sums up exactly why you don’t want to say generic things. The person doesn’t know how to respond because you’ve given them no holes to try to plug.  If instead of saying “I love you, man,” he had said “I love your shirt, man!” then Garth could have easily continued the conversation knowing exactly what to talk about next. “Ohh yeah I got this at the concert in Reno where the drummer was on this crazy…” —you get the idea. Focus on specific insights, not general insights. Especially say what set of circumstances led you to that insight.

Start with a Punchline

Good developer tales start off with a punch line.  The point of the first sentence is to get the other person interested and hopefully guessing what’s coming next.

“I built a web interface for running developer insights reports,” is a bad punch line. There are basically two directions the interviewer can go here: “What’s developer insights?” or “What technologies did you use to build the interface?” Neither of those questions lead to interesting things that you have done. Developer insights is a whole group of people and now we’re not talking about you, and tons of people have used the front end web framework you built it with, but the interesting parts about the project are probably not related to the framework you used.

“I put 7 data sets on a Google Maps interface that allows a team of salespeople to get real-time reports about developer populations around the globe.” Now you’re probably wondering to yourself a lot of things, and they are all about the project work I did. We’re about to have a conversation because I used specific information that clearly identifies 3 to 4 interesting aspects of the project. That’s the difference between a punchline and any old way to talk about yourself.

Talk Backwards

In general, real stories are told chronologically backwards. This is why we start off with a punchline.  In contrast, practiced stories are told chronologically forwards.  It’s a solid indication as the interviewer that the person is reciting something they have committed to memory if they tell the story forwards, and in turn it’s significantly more likely that the story isn’t entirely true. Good interviewers will force you to tell the story backwards because they will constantly ask you to expand on the parts they are interested in. If you actually know what happened and why it happened, this is not a problem for you because you are intimately familiar with the problem you are talking about. All you have to remember is where you left off in the main story so you can come back to it later.

If, however, the interviewer asks you to expand on something you have just said and you try to continue moving the story forwards, it’s a dead giveaway that you’re not being truthful with them. You might be talking about a decision someone else made in a manner that sounds like you made it, or you may have given the impression you know more about the inner workings of the tools you use than you actually do. These are not necessarily lies, but miscommunication isn’t fully truthful either. Not being truthful in an interview is not a good idea and it is extremely likely you will be caught if the company is any good at interviewing at all. I also want to point out that if you do get caught in this situation, it’s not a guaranteed failure of the interview. When you’re caught, the point is that you should feel encouraged to spend a little more time on your answers from then on out making sure you only talk about the stuff you have done. If you get caught twice that’s pretty much it.

So you’ve already given away the punchline, what do you say next? Your interviewer should lead you to the next thing, and they should lead you to expand on one of the 2-4 interesting things you packed into your punchline. Once they ask about some particular part, you refer back to your card and you only talk about the stuff that you tried that didn’t work. In large part, no one cares what the actual solution is; the journey matters so much more as a job skill than knowing the answer. It’s the difference between you being able to work through a problem vs. you just knowing the answer. In the case that you just knew the answer, the best thing to talk about is the components of the solution and how they all work together. But in large part, you’re being hired to work through problems, and that’s why you have to talk about the stuff you tried that didn’t work.

There is another side benefit of talking about the things you tried.  As soon as you say the punchline, the interviewer is going to start guessing how you solved this problem. You might have taken a different path than what the interviewer is thinking and because you talked about the path, now you get that all important knowledge transfer happening right there. Talk about their ideas, especially if you tried them. Make sure you focus on the key insights that led you to each next option. As the interviewer and as a developer, I genuinely enjoy learning a couple things in the interviews which leads to the next point…

Don’t Guess What the Interviewer Knows

In most cases you will have no idea what the interviewer knows. You have no idea what languages they are familiar with, what kinds of problems they are accustomed to solving, or what tools they have in their toolbox. There is a bit of a balancing act here. In order to use your time wisely, you have to assume they know some things. Assume they know what developers do for a living and that they know how to solve problems. Very regularly stop in the middle of your tale to make sure the interviewer is still following along. This can be done via body language, listening for sounds of agreement (the typical “yep” every so often from them while you are talking), or blatantly stopping to ask them if it all makes sense or if they would like you to expand on something.

If you get too far into a story without making sure they are still with you, it comes off to the interviewer that you cannot explain things well. Show an active interest in making sure the interviewer is understanding what you are talking about, and you will likely feel a lot more comfortable, and the interviewer will feel like they learned something.

A similar point here is not to make assumptions about what the interviewer finds interesting. Don’t talk negatively about any of the stuff that you have done because it might be the thing they think is interesting. Just because you think it’s simple or naive or whatever, you can still have a great conversation about it. Developers have hundreds of specializations these days and just because you’re applying to work at web dev position doesn’t mean the interviewer knows CSS or some javascript feature as well as you do. If the interviewer ever gets excited about something when talking to you, talk more about that in a very inviting manner.

Force It to be a Conversation

If it’s not obvious yet, force the interview to be a conversation. The reality is that you don’t actually know what your interviewer is going to find interesting in the materials you gave them or anything you might say, and I can’t tell you either. Do your best to make them excited about something you have done, and if they don’t bite, turn it around and ask them what they would like you to talk about. This is another case where being specific helps. “What do you want me to talk about?” is bad here;  “Is there something from my resume you thought was interesting?” is much better. It forces them to show their hand about their preparation for the interview as well. And if their answer is along the lines of “I didn’t see anything interesting,” then your immediate follow up question should be “then why I am in this interview to begin with?” Constantly trying to guess what the interviewer finds interesting is a waste of your time; it’s much more effective to just ask. If they don’t want to talk to you about specific things, they probably didn’t prepare for the interview themselves.

Practicing

Practicing for interviews is my favorite part. Just go talk to other developers about the stuff that you’ve done. Start with the punchline. Be specific, and when they ask you questions, talk about the things you tried in reverse chronological order.

Some things to remember: When you are talking to people, make sure you talk about 5-10 different note cards; one is not enough! You will have to go through 3-5 interviews for most companies; make sure you are not repeating the same stuff to different people because they will compare notes. Listen to the questions people ask you when you’re practicing. The questions you get during real interviews will be much the same and you basically train yourself to respond naturally by answering them a few different times. You should also pick up on the emotions of the people you’re talking to when you say things. Train your conversational muscle memory to say the things that make people excited and most eager to hear more.

Interest in the company hiring you is directly proportional to the interest the interviewers have in what you say. Telling stories is a very compelling way to build an interesting conversation with people you’ve just met. Hopefully you’ll find this recipe an effective way to practice telling stories and get a better response from your interview experiences.

Ready to put your interview skills to the test? Browse open positions at Stack Overflow Jobs.

Author

Nick Larsen
Developer

dad, data team member at stack overflow, GA Tech grad student, high power rocketry enthusiast, connoisseur of head rubs

Related Articles

Comments

  • >How do you handle disagreements with coworkers?
    IMHO, this can be asked to interviewees who will be working more with people than with technology. However, there’s a high chance that you might get a cooked up answer. So, instead of asking a straight question, you present them with a situation.

    • Martin Konicek

      I agree. Note than almost any programmer will be working with people (team members). You should try to find out how well they can work in a team before hiring them.

  • Anonymous Coward

    I wonder: is this advice based on any data, or simply your own personal experiences? Most of the things you say here do not match my experience at all.

    “…imagine you are hiring someone; what would you want to know about them? Here’s my list: What have you built? What is the hardest technical problem you have run into? How did you solve it?”

    I don’t want to know these things, because everybody and their dog can bullshit through “I built XYZ” for an hour, and besides, I have no way to verify they actually built it. (Everybody is the hero of their own story.) There’s so many different languages and frameworks these days I probably have never touched any of the systems they used, so I can’t even tell if what they’re saying makes sense. Unless their job will be to bullshit about technical issues, I learn precisely nothing about a candidate this way.

    In the past 20 years, I’ve worked on projects that succeeded, and projects that failed, and teams with great programmers, and teams with terrible programmers, and in no case was it ever a technical problem that sank any project. It’s always social ones, or business ones. Your manager tells you to do X, and your team agrees that you really should do Y, and the CEO drops by and says you need to do Z. Your top salesperson stops by every 2 hours with a feature request that has to be done, today, and refuses to even look at the issue tracking system or release schedule. You’re being picked to lead a new project the CTO loves, but which everybody agrees is pointless, and has no future. What do you do? These issues can reduce a top performer to zero, if not handled well.

    “Where do you see yourself in 5 years? Why do you want to work here? How do you handle disagreements with coworkers? These are all worthless questions from the company’s perspective because predicting things is hard, especially when it’s the future.”

    I agree the “5 years” question is dumb, but the others are what I really want to know. I’ve had many coworkers who didn’t want to work at the company at all, or whose idea of handling disagreements was “I’m the boss, so what I say goes (even if everybody on the team thinks it’s a terrible idea and all of the customers hate it)”. It’s infinitely preferable to hire reasonably good people who are easy to work with and love the project, than to hire the best technical people who will act like total jerks half the time and don’t give a shit. Predicting the future is hard, but you can predict “handling disagreements” just as well as you can predict “technical solutions”: based on past behavior.

    ““I built a web interface for running developer insights reports,” is a bad punch line. There are basically two directions the interviewer can go here”

    I can think of dozens of interesting questions to ask from here. I find it baffling that when a “developer” hears about a web interface, the only possible things he can think to ask are what it is, and what technology was used. As an interviewee, either one of these questions would be red flags that tell me I probably don’t want to work here: all they care about is the technology stack and the specification.

    ““I put 7 data sets on a Google Maps interface that allows a team of salespeople to get real-time reports about developer populations around the globe.” Now you’re probably wondering to yourself a lot of things, and they are all about the project work I did.”

    Nope, now I’m falling asleep. This is the kind of meaningless drivel you see on marketing pages. Why would I care that the people using it are salespeople? Why does it matter that there are 7 datasets, and why are you not telling me anything about the size of these datasets? Why do you think dropping a few datasets on Google Maps is an interesting task? If I heard this, my first assumption would be that you haven’t done any significant work, and your previous team only trusted you to hook up Google Maps. Yawn.

    “Don’t talk negatively about any of the stuff that you have done because it might be the thing they think is interesting.”

    This is the opposite of Joel’s advice, and I happen to agree with Joel here. I love people who hate things passionately. That’s how progress is made. If it happens to be something I like, great, tell me why you think it sucks. (At least this time I’ll have the background to evaluate your claims.) Maybe you had different requirements, or just different priorities. Worst case, I’ll learn about some limitations of a system I happen to like.

    On the flip side, if you can’t talk negatively about anything you’ve ever done or worked with, then I can only assume you have no taste. What’s going to happen next month when we need to evaluate whether to go with X, or Y, or Z? Are you going to say “Well, they’re all good”? Useless.

  • ben w

    “In general, real stories are told chronologically backwards. This is why we start off with a punchline. In contrast, practiced stories are told chronologically forwards.”

    Since no intelligent person could believe this, or the idea that a well-told story is apt to be false, or any of the remainder of the section, and since no intelligent person could fail to note that the advice is self-contradictory (“since practiced stories are told in X fashion, practice telling stories in a non-X fashion”), one really has to wonder about the rest of the document, hiring practices at the rest of the company, and what one’s coworkers would be like assuming one got the job. (My guess: convinced of their intelligence, yet actually stupid.)

  • AKA if you want a job at stack, do what Nick likes. I hire people based on what I like as well. I think that each team has their own flavor and style and it is good to know what you want as a boss and be able to spot it and pick it right away and on the flip side, know when to fold em.

  • Martin Konicek

    It’s not enough to know someone can solve hard problems. You should also ask questions that show how good that person is at working with others in a team. At Facebook and we do ask such questions.

  • I really love to read your blog as well as the examples that you’ve mention. Thank you so much for this helpful contents. I am looking forward to see more example contents like this. If you have time you can also visit this site that I managed to surf in business startups.Go Helper

  • alok

    Really helpful, thanks for jotting this down.
    Further, in my experience, I have been asked quite a few questions which were common during most of the times ( specially the behavioral ones ) . I would really appreciate if you / anyone can provide more insights/examples on answering such questions impressively .
    e.g . Give an example of a situation where you had a conflict with your manager ? ( what is the interviewer expecting in the reply? ) .

    • “Give an example”
      Well I can give an example if having a conflict a manager ever happened. What if it never happened?
      Just say: “I’ve never had a conflict with my manager”

  • adnan abdollah zaki

    thanks , it’s usefull