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 . 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 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 .

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.

^ 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. 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 . 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.