by Carol Smith and Heidi Waterhouse
There are so many variables to interviewing that it can feel overwhelming. Your mind is filled with everything from coding tests to directions to the interview site, and the process encourages the kind of reflection that sometimes gives even confident people cold sweats.
This article gives you a way to structure your thinking about past work experiences and how they can be helpful to you when you answer interview questions. Working through them gives you a way to prepare your answers to common types of questions so you can respond naturally and easily when you are asked.
One of the useful things to remember about practicing for interviews is that you’ll do better if you actually answer out loud, in sentences, when you’re practicing. Just nodding to yourself under the assumption that you could answer that does not provide the same value. In the same way that an Olympic diver goes through exact visualizations of each twist and revolution, you’ll go through your answers. Even better is if you can do a test-run with a friend. Make sure your clothes work the way you expect and practice saying the answers out loud. The more you practice, the less scary this will seem in reality.
Collect your jobs
Look through your resume for jobs that are relevant to the position you’ll be interviewing for, that or highlight your work in general. The goal is not to provide great details, but to figure out which of the jobs had projects that are particularly meaningful to your personal growth and thinking.
Inventory projects and deliverables
Note the names of projects or deliverables that you learned a lot from. This is a great time to make a document for your own reference. You want to choose projects that you had some degree of influence on—not just following orders, but executing and innovating. They may not even be something you got paid for. You may have a giant side project you run yourself, or a zine that you have produced with friends, or even a reorganization of how the lines worked at your Santa booth. They key is that you want to pick something where you were involved and got results.
Don’t avoid the bad stuff
It’s tempting to skip projects that went badly, upgrades that ended in rollbacks, or times that everything went wrong, but you should keep those on your list if you’ve learned from them. Sometimes our lessons come from failure, and many interviewers will ask you about times that something went wrong. You want to be able to tell them what you’ve learned and taken away. Everyone fails – what they are actually asking is whether you can avoid failing in the same way over and over again, so talk about how you’re engineering things to avoid that problem in the future.
Notice themes and systems
As you start collecting these moments, you may notice that there are themes to your successes and failures. For example, you could have a persistent problem with maintenance tasks, even if you’re really good at creation tasks. This is not always information you’re going to want to share, but it is something you’ll want to notice yourself, to either make a plan for improvement or avoid jobs that put you in that position.
You may also notice that you end up in the same kinds of roles over and over, even if the titles are different. Those are places that you’re probably most comfortable, and you may gravitate to roles like that, or you may be looking to break out of your own typecasting.
Use a template
Here’s a template for structuring your review of your projects:
|Position and title||This could be the same, or not.|
|Biggest project||Consider length and complexity|
|Best part||Successes and challenges overcome, your personal achievements|
|Worst part||Failures, and what you learned (just one or two!)|
|Best accomplishment||What did you accomplish as part of a team?|
|Worst failure||This can be systemic or personal|
|Team player story||How have you worked with someone difficult, busy, or otherwise challenging?|
|Why you left||Don’t be surprised by this question, many people ask it. Think a bit about your spin.
“I outgrew the position / my management changed course / our ethics didn’t align”
At the interview
Now that you’ve done all that review and practice, you may feel more prepared. All interviews have varied questions about your technical fit for the job and how well you would be able to perform the functions, but they also tend to have what some people call “soft questions”. These are the questions about how you work in a team, how you are to manage, what your philosophy of work is around co-workers.
These are the “fit” questions. Frequently they are phrased to encourage story-telling — the interviewer is hoping to hear a narrative of how you put this skill into action. For example, they might say, “Tell me about a time when you disagreed with your manager.” or “Explain how you would solve a problem that had more than one possible answer.” or “What’s an example of a time you used your editing skills at work?”. Structure your answer to put the question at the beginning. This gives you a minute to think and reinforces what they just asked you. For example, “Once, I disagreed with my manager about whether we’d be able to launch in the time window she requested. Once I realized we disagreed, I wrote down all the dependencies I knew about, and asked her to compare her list to mine to see why we were coming up with different numbers.”
Why do you want THIS job?
People interviewing you want to know two things:
1) Can you solve their problem?
2) Can you be an asset to the company going forward?
The reason they ask you about this particular job is because they want to know if you have thought about their particular problems, and because they want to know you have thought about staying with the company in the future.
After the interview
Send your thank-you note, then take some time to review your template and mark which answers you felt comfortable answering and which ones felt like they needed more practice. You’ll probably remember the questions you struggled with and be able to improve those. If you’d like a template for how to write a thank-you note after an interview, The Muse has a nice, simple example thank-you.
Remember that you are a product of all your experiences, and the interview is not about judging that, but how you react to them and learn from them. We’re sure you’ll do great!
Carol works as an Open Source Program Manager at Microsoft. She previously handled education outreach at Github and worked at Google for 10.5 years, most recently managing Google Summer of Code. She is a horseback riding, armchair TV critic, and has a degree in photojournalism from California State University, Northridge.
Heidi is a Developer Advocate with LaunchDarkly. Her years of contracting and jobsearching have given her a vast experience of interviewing and the variety of questions people can ask.