0% found this document useful (0 votes)
12 views

SEEN Developer Interviewing Guide

Uploaded by

keshavvyas
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
12 views

SEEN Developer Interviewing Guide

Uploaded by

keshavvyas
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 38

From phone screen

to thank you
THE COM PL ET E G U ID E TO S OF T W A R E E N G I N E E R I N G I N T E RV I E W S
Contents

Intro

Phone screen
What they’re looking for
How to prepare
What you should be looking for

Take-home coding assignment

In-person interview
Dress code
Preparing for common interview questions
What you should look for

Onsite coding challenge


Pair programming
How to prepare
During the pair programming interview
Whiteboarding
How to prepare
During the whiteboard interview

Panel interviews
What different stakeholders look for
How to prepare

After the interview


Evaluate yourself
Follow up
Waiting to hear back
Getting interview feedback

Summary
Whether you’re a new computer science grad,
self-taught coder or seasoned professional with
years of development experience, the tech
interview process can be a tad intimidating.

You might be asked to solve complex coding problems in front of a


team of engineers, navigate through thought-provoking questions
and elaborate on CS roles from years ago—all while remaining
calm, cool and articulate to put yourself in the best light.

But when you know what to expect and how to prepare for
the interview process, you’ll find new confidence on your
journey to landing your dream developer role.

Through Seen’s work with hiring managers, tech


recruiters and our own engineers, along with
thousands of candidates through our technical career
coaches (many of whom are former tech recruiters
themselves), we’ve compiled the ultimate list of
tech interview best practices and tips to help you
go from applicant to top candidate.
Phone screen
Your first step

After polishing your resume, writing the perfect cover letter, updating your online profiles
and sending out applications, you’ve secured a phone screen. Welcome to the first stage
of your developer interview journey!

Even though you’re not meeting your interviewer in person, the phone screen can
still be stressful. After all, your skill level, experience and even personality are being
critiqued. And because you can’t rely on body language or cues to carry you through the
conversation, it’s important to be mindful about your tone and language.

Don’t fret too much—the initial phone screen is typically casual and relaxed, and helps
the interviewer learn about your background and motivations. It’s usually a 30-minute
chat with a recruiter, but could also involve an engineer or manager depending on the
size of the company.
What they’re looking for

Employers use the phone screen to get to know you beyond your resume. They’ll ask
high-level questions to learn more about your qualifications, work experience and
career goals. During the conversation, they’ll also gauge your interest in the role and
company, plus how well you’d fit on the team.

Specifically, they’ll be looking at whether you...

Have a basic understanding of what the company does.

Uphold the company’s core values.

Have a genuine interest in working at the company.

Seem like a personality/cultural fit.

Actually have the skills listed on your resume.

Meet the base-level requirements in the job description.

More than your voice


55% of a conversation is body language, 38% is tone
of voice and only 7% is what you’re actually saying.
How to prepare
K NO W YO U R R E S U ME

Though the phone screen is like an open note exam, it’s still important to know your
resume inside and out. The interviewer likely has it in front of them, so elaborate on your
bullets and achievements versus reading them line by line.

Familiarize yourself with your resume and rehearse quick summaries for each of your
roles that highlight specific achievements, projects and/or awards. Be prepared to
explain any gaps in your resume or why you’re leaving your current role.

And of course, the inevitable “tell me about yourself” question. This should be a short
1-minute “elevator pitch” tailored to each company that highlights your best qualities,
experiences and goals, and how they match the job description.

R ES EAR CH T H E CO MPAN Y

Going into an interview without knowing anything about the company can signal to the
interviewer that you’re not genuinely interested.

The website, reviews and social accounts all give you a feel for the culture. Any
information you gather about mission and values can help you tailor your interview
answers to highlight what’s most in line with the company’s ideal candidate. Plus, if they
ask, you’ll have a solid answer to questions like: “What attracted you to our company?”
Remember, employers favor candidates who care about shaping the company’s future.
FA MI L I AR I Z E YO U RS E LF WI T H THE JOB DESC RIPTION

Look for keywords in the job description that clue you into the company’s ideal
candidate. Use these to brainstorm answers to potential interview questions.

For example, if a company values “self-directed” candidates, think of how you’ve worked
autonomously on a project and reached deadlines with minimal direction. If the listing
mentions “4+ years of Java development experience,” prepare an anecdote about a Java
project you worked on recently.

If some things don’t line up with your skill set, don’t worry—it’s nearly impossible to
be a perfect fit. Be prepared to say something like “I don’t have experience with that yet,
but I’d love to learn more about it,” and show an interest in growth.

PR EPAR E AN S WE RS TO COMMON QUESTIONS

Steady your nerves and boost your confidence by preparing short anecdotes and answers
to common questions. This will ensure that you highlight your best qualities and won’t
have to worry about crafting well thought-out answers on the spot.

Q U EST I O N S TO P R E PAR E FO R

Why do you want to work for us?


Why should I hire you?
What are your greatest strengths and weaknesses?
What skills on your resume are you most comfortable in? Least?
What’s one problem you wish you had handled differently at your last job?
What traits do you like most and least in a supervisor?
What salary do you expect in this position?
What makes you unique?
What is your ideal company culture?
Do you code outside of work?
What new skills have you learned recently?
AN EC D OT E S TO H AV E U P YOUR SLEEVE A BOUT WHEN YOU...

Showed leadership or ownership.


Overcame a difficult technical problem.
Should have done something differently.
Overcame interpersonal conflict.
Learned something new.
Worked on a project outside of work.

What you should be looking for


Leading up to the phone screen, ask yourself important questions to determine what kind
of role you want. What are you passionate about? What projects do you want to work
on? What’s your ideal work culture? For example, if you like working alongside people
who love routine, you might not get along with a team that relies on instinct, rather than
formal guidelines.

Go in open-minded. Is the position what you expected? If not, try not to rule out the
opportunity until you learn more about the role and offer.

A few things to look for…

Mission and values: How the team upholds core values day-to-day and how
your role feeds into that.

Work-life balance: If the role will give you the flexibility you need and how
that reflects on the company culture (e.g., will you be working long nights?).

Why they’re hiring: Is it a new position or are you filling someone’s shoes?
While expanding the team is a good sign of company growth, a high
turnover rate can be a sign of unhappy employees.
Smart tips

1 Have important info handy.


Grab your resume and cover letter, the job description, notes on what
you want to highlight and questions you want to ask. Use these reference
materials as prompts, not a script and remember to take notes.

2 Be professional.
Answer your phone with your first name and a friendly tone, and set up a
professional voicemail in case you miss a call.

3 Stand up and smile.


Confidence isn’t the easiest to convey on the phone, so smile and adopt good
posture to sound confident and friendly.

4 Stay on target.
Reference your notes to weave keywords into the conversation.

Collect your thoughts.


5 Pause, breathe and take your time when answering questions.

The next step in the interview process is often the take-home coding assignment. While
a coding assignment can come up at any stage, we many times see them after a phone
screen and before meeting the hiring manager in person.

Posture as a confidence booster


Adopting an open, strong posture can decrease your
levels of the stress hormone cortisol by about 25%.
Take-home coding assignment
The coding assignment: What employers look for

There can be a lot to like in take-home coding challenges: you’ll most likely get to
approach the problem at your own pace, on your preferred IDE and using all the
searches you want. But all that wide open space can be a bit overwhelming.

After all, it’s not only about completing your assignment with functional code—there’s a
large spectrum of “it works.” While every employer will vary in exactly how they grade
their challenges, expect that the following will play a role in whether you advance or not
to the next stage.

Making the grade


It’s not just pass-fail. Slack, for example, uses 30
factors to grade coding challenges.
1 YO U R Q U E ST I O N S

Don’t be afraid to ask qualifying questions—part of what you’re measured


on may be your ability to suss out gaps in the requirements or gauge how
many assumptions you make.

If you have a challenge that includes time and date fields, for instance,
asking about time zones, when the week starts or holidays isn’t obnoxious
(though asking about time distortions in a black hole might be)—it could be
relevant to the solution and lets your interviewer know that you don’t jump
into a coding project without knowing which direction you’re headed.

The same goes for anything you find confusing or vague in the instructions. If
you’ve been provided with seemingly conflicting objectives, ask. This might
again be intentional or a holdover from a previous challenge.

2 YO U R AP P R OACH TO THE A SSIGNMENT

Next, how do you tackle the problem at hand? Part of that is the language
you use. There isn’t necessarily a right or wrong, unless a coding challenge
specifically asks you to use Ruby and you use Java. Weigh the languages you
know the team uses (either based on your initial discussion, open source
code or from the role’s description) with what you’re most comfortable in.

Beyond language, companies will review your overall strategy. Have you
made complex design choices that contain more than a few bugs? Or do you
opt for the simple route and nail it? Do you go for every bonus task or stick to
the basics? Make sure how you tackle the assignment reflects the work you’ll
do if you get the position.
3 YO U R T E ST I N G APPROAC H

Your challenge requirements may explicitly ask for tests, but tests might
be expected without a specific request from the interviewer—particularly if
you’re interviewing for a smaller company without a dedicated QA function.

How many tests should you run? Sometimes the exercise will provide some
tests, but it won’t hurt to add a few of your own. Test the golden path (your
default scenario), but look at a few edge cases, too. Unless it’s a tester
role, you don’t need to dedicate the majority of your time to find exceptions,
but show the reviewer that you’ve thought through major scenarios.

4 H O W YO U S P E AK TO—A ND DEBUG—YOUR CODE

Once you’ve hit send on your assignment, don’t totally put it out of mind. Sosh,
a restaurant app, used their coding assignments to inform their next interview:

If the code submission had a bug in it (spoiler warning:


they usually did!), the candidate’s in-person technical test
was to debug it with me. I’d point out a case that failed and
we’d spend time fixing it together. The ability to debug
code you wrote a week ago and haven’t thought about
since is a vital skill for an engineer!
The company may also want to explore the rationale behind why you took a
certain route. Be prepared to justify your decisions or explain code. Did you
have to head to Stack Overflow for help with a component of the assignment?
Nobody’s going to ding you for “cheating” unless you paste code without a full
understanding of it.

Think through your approach before you get started, mark up any complex
code and add references to any necessary additional documentation. Not
only will this help the code reviewer, but it will help you refresh yourself on
the assignment before a follow-up interview or even debug on site.

5 E N GAGE ME N T WI TH THE PROBLEM

Lastly, how much you enjoyed the task is just as much for you as it is for
employers. A well-designed challenge is made to be as close to what
you’ll be expected to do in your day-to-day. Too easy? Discuss that with the
interviewer. Too tedious? Ask yourself whether this is really the role for you.

Your take-home coding challenge shouldn’t be another hoop to jump


through—it should help you and the employer uncover not only whether
you’re a good technical fit, but whether you’re right for the role (and
the role is right for you). Keep these tips in mind and both you and the
interviewer will get more out of your take-home assignment.

Congrats!
You’ve passed the phone screen (and maybe a take-home coding assignment), and
have now been invited to an in-person interview with the hiring manager—or other
members of the team. During this stage, you’ll visit the office and get a better idea if this
is the right fit for you.
In-person interview: Rising to the top
Your first step inside the office! An in-person interview usually involves a senior
developer, software team members, the engineering manager and/or CTO—if you’ve got
a panel interview at this stage, skip down to our section dedicated to those. Brush up on
the role and the company if you haven’t done extensive research for the phone screen.

How to prepare
F I ND O UT E XACT LY WH O WI LL BE IN THE ROOM

It’s important to learn as much as possible about your interviewers via your recruiter,
social media, the company website or a quick Google search. You might be able to find
commonalities that will help create interview chemistry (e.g., similar backgrounds,
same alma mater, shared interests) or at the very least eliminate the mystery behind the
process, soothe your anxieties and boost your confidence going in. You can also learn
what they’re passionate about and their potential interviewing style.

B RA I NSTO R M T H E QU E ST I O NS YOU MIGHT FAC E—


AN D COME U P WI T H YOU R O WN

Your interviewers might come have different backgrounds, including fellow engineers,
product managers, directors, the hiring manager, etc. Each person will view you through
a different lens, which means they’ll ask you questions that are specific to their role at the
company.

To prepare, brainstorm a list of questions each panelist might ask you. For instance, a
fellow engineer might ask questions about your work as a software engineer. A director
of engineering, on the other hand, might ask high-level questions that reveal how you fit
into the department and company as a whole.

Gather you own questions to show you’ve done your research and figure out if you
connect to the work you’ll be doing and who you’ll be working with. Use the website,
check out any press releases or any blog posts to help you dig deep.
DR ESS CO DE

Knowing what to wear to an interview is one of the most stressful parts of the preparation
process—especially in a tech workplace where the dress code is often a hoodie and
sneakers. Should you dress up in your best suit and tie, or high heels and pantsuit, and
feel overdressed and out of touch? Or dress down in jeans and a t-shirt and worry about
coming across as sloppy and unprofessional?

First impressions matter


Dressing “too casually” turns off 62% of recruiters.

A good rule of thumb for any interview is to dress one level above the company’s dress
code. It shows that you have a good idea of the company’s culture, but you put in effort to
look your best.

Some tech companies will list “casual dress code” as a perk on their career page, or
mention the dress code in an interview prep email they send you. If you’re still second-
guessing what you should wear, don’t be afraid to ask the recruiter or HR staff you’re
working with.

AC I NG CO MMO N DE V E LO P E R INTERVIEW QUESTIONS

There’s no way to tell exactly which tech interview questions you’ll be asked—which
is part of the reason why the process can feel so terrifying. However, you can prepare
yourself by being aware of the types of questions you may face (and what the asker’s
looking for).

What are your weaknesses?

Why they ask: The interviewer is hoping to gain insight into your level of
self-awareness and professional development goals—your drive to grow as a
person and team member. Are you proactively taking steps to improve? What
results have you seen so far?
What not to say: Naming a weakness that’s really a strength, like how you’re
a perfectionist to a fault, is the fastest way to come off as inauthentic. Avoid
short, vague answers and naming a weakness that might disqualify you
from the position or show you don’t work well with others.

What to say: Show self-awareness and honesty by sharing a real


weakness, and how you solve for it: “Sometimes I lose drive in the middle
of a project after the launch excitement has worn off. I combat that by
breaking up the project into mini-milestones and celebrating them with
my team. The original buzz gets recreated and it becomes obvious how
crucial our work is.”

How familiar are you with [specific programming language]?

Why they ask: The interviewer is gauging your comfort level, and if your
familiarity with a particular language is lacking, they’re looking for how you
approach learning in general. Do you pull away from the chance to expand
your skill set? Or are you a continuous learner?

What not to say: If you’re asked about your Java expertise, but haven’t
coded in Java before, stay away from saying something like, “I prefer Ruby
and don’t really know Java.” An answer like this gives the impression you’re
not interested in stepping out beyond your comfort zone.

What to say: Be confident and don’t get hung up on your skill level per
language. Rather, emphasize how well-versed you are in coding as a skill
and how you might pick up the new one. For example: “I’m really familiar
with Ruby and am happy to dive into learning more Java. I write mostly
object-oriented Ruby so don’t think transitioning would be difficult.”

More than a skill


Tech companies are up against a tech talent shortage.
They’re not looking for perfection, but competency,
drive and willingness to learn.
The brainteaser or story problem

Why they ask: On the surface, questions like how many windows there are in
New York appear random. But by asking questions you most likely couldn’t
prepare for, they’re testing your sense of logic, your coolness under pressure
and your ability to openly think through problems while asking questions.

What not to say: Avoid saying nothing at all. Getting a “right” answer is far
less important than coming across in real-time as open and analytical.

What to say: Talk your way through it. Ask clarifying questions. Be curious.
Say you’re thinking it through and figuring it out. Logically analyze—out
loud—the different ways to approach it. Talk through why you’d lean a
certain way, and eventually give your answer. Remember, it’s about the
process of problem-solving versus answering correctly.

Have you interviewed anywhere else?

Why they ask: Interviewers ask this questions to gauge where you’re at in your
job search (for example, are you close to accepting a job offer somewhere
else?), as well as how popular you are, if you’re serious about the industry and
what you’re looking for in a new role.

What not to say: Refrain from being too specific. For instance, don’t reveal
the names of the companies you’ve interviewed with or mention how many
companies you’ve interviewed with.

What to say: Play it safe and keep your response laid-back and general.
“Yes, I’m actively looking for other great roles like this.” Or, “I’m moving
quickly with other companies with competitive offers.”
Do you work best alone or on a team?

Why they ask: Interviewers want to see if you’re the right fit for the
team, which includes the ability to work effectively with others (e.g., pair
programming) and dive deep into independent coding.

What not to say: This question is pushing you to take a side, but don’t. Why?
The ideal tech candidate is a master of both solo, unsupervised work and
agile collaboration.

What to say: A great response: “I love the speed and energy of teamwork,
and I also like concentrated time to work alone and execute on projects.”

Why are you leaving your company?

Why they ask: Tread lightly. Hiring managers are looking for honesty, but not
baggage. Plus, the reasons why you’re leaving your current company can say a
lot about your values, work ethic, loyalty and overall positive attitude.

What not to say: Negative answers, like “I’m cut off from collaborating and
feel isolated” or “I’m unchallenged and need more to do.”

What to say: Be real, and emphasize positivity and your hopes for the
future. Consider saying something like “I’m looking to be a key player on a
driven, talented team,” or “I’m really excited to grow and develop my skills
and tackle new opportunities.”
What do you do for fun?

Why they ask: This question seems out of the blue, but there’s a reason
behind it: Your interviewer needs to see your personality. More and more tech
companies are oriented around culture—this means they’re looking to hire
people who will contribute to a positive, open work culture.

What not to say: There isn’t really a wrong answer for this question, apart
from hobbies that are illegal or not safe for work, or saying that you have no
hobbies at all.

What to say: Smile and share what you enjoy doing. Playing video games,
exploring new restaurants, seeing live music, watching sports, taking trips
with your friends—all great answers. Your eyes will naturally light up,
letting the interviewer know that you’re fun and friendly. Sounds silly, but
interviewers need to feel that they can vouch for your likability.

What are your strengths?

Why they ask: By asking this question, the interviewer is evaluating your self-
awareness, if your strengths align with the role and if your talents and skills
will allow you to excel in the position.

What not to say: Clichéd or overly confident answers, such as “I’m a team
player” or “I’m so awesome at everything I do,” or strengths that don’t apply
to the job you’re interviewing for.

What to say: Good news! The answer to this has been spelled out for you.
Where? The job description. Look at the “Ideal Qualifications” section. Find
two items that describe you, and brainstorm specific examples of how
you’ve demonstrated those characteristics on the job.
W HAT YOU S H OU LD LO O K FOR

Companies aren’t just interviewing you—you’re interviewing them, too. Here are a few
things you should look for (and ask about) during the in-person interview to make sure
the company is a good fit for you.

How (and when) they interact with you

The behavior of the people interviewing you can be very telling of the culture. Are they
responsive to you in a way that seems human? How do they talk about the culture?

It’s also important to pay attention to emails you receive from HR and the hiring manager
during the hiring process. What kind of language do they use? For example, emojis can
signal a laid-back culture, while highly professional language might mean a more formal
workplace.

Do you get emails later in the day or on the weekend? This can reveal a lot about the
company’s work-life balance. (Keep in mind that this isn’t always reflective of the culture
since recruiters can have a different schedule than engineering and a hiring manager can
work late without expecting you to.)

Career growth opportunities

When you go in for an interview, you’ll typically have the opportunity to talk to a few of
your future coworkers, along with the hiring manager. During this process, it’s important
to take note of a few things:

What have past employees gone on to do, and does it match your
personal goals?

How long have current employees been in this role, and is it longer
than you’d expect without some sort of promotion?

Do employees feel that the company supports career growth, or do


they encourage people to stick around rather than moving on when
the time is right?

If the answers you get to these questions suggest that this role won’t actually help you
meet your career goals, you might want to consider going another way.
Language cues and buzzwords

Start by asking the hiring manager about the company’s values. Buzzwords like “we’re all
a big family” and “work hard, play hard” are often red flags. That’s because they don’t say
anything about daily interactions at the company and blur the boundaries between work
and personal life.

Instead, look for words that describe real, day-to-day interactions, such as
“collaboration,” “compassion,” “low ego” and other values that ideally match your own.

Comfort level talking about diversity

If diversity matters to you, you should ask the company why diversity matters to them.
Look for authentic responses that are specific to the company and show that they’ve
thought carefully about diversity and inclusivity. It’s a good sign if they can articulate
their approach to building a more diverse culture—but it’s usually a major red flag if their
answer seems canned or if they’re uncomfortable with the topic.

Ask if the company facilitates the creation of employee diversity groups (ERGs) and if
there’s a budget for creating new ones. This will show you if diversity and inclusion is truly
part of the company’s DNA, or if it’s just a small (or even nonexistent) part of life there.

So far so good?
After your in-person interview, you’ll often face onsite coding challenges—pair
programming and/or whiteboarding—that test your coding prowess and reveal the inner-
workings of how you solve problems.
Onsite coding challenge: Show off your skills
Onsite coding interviews are often the most daunting part of the tech interview
process, since they can last anywhere from 30 minutes to the entire day, and often
involve pair programming and whiteboarding sessions. But even though the process
may be intimidating, this is your chance to show your interviewers that you have the
programming chops and problem-solving skills needed to succeed in the role.

Pair programming
Pair programming is what it sounds like—two programmers work together at one
computer: the driver and the navigator. The driver actually writes the code. The
navigator helps edit as you go, and serves as a source of ideas. The navigator is
there to bounce ideas off of and guide the driver through the coding process.

During the interview, you swap back and forth between the role of
driver and navigator, working together with your interviewer to solve a
problem. This interview is a test in collaboration as much as it is a test
in coding—and a chance to demonstrate your communication skills.

How to prepare
GAT H ER I N FO R MAT I ON B E FOREHA ND

A pair programming interview has more to do with how you


work in a real coding environment than if you simply can
or cannot solve a problem. The good news is, you don’t
have to worry so much about brushing up on skills
you haven’t used in a long time (like you would for a
whiteboarding interview, for example). Instead, you
can use this as an opportunity to show how well
you fit into the company culture.
For a pair programming interview, try to learn what you can about your interviewer.
They’ll be your partner in this process, so anything you can discover about how they work
will help you work as a team.

Know the limitations of the test beforehand. Ask what you are and aren’t allowed to look
up during the test. Can you quickly search for the syntax of something you haven’t used
in a while? What resources will you have access to during the test that you would have in
a typical work day? The more you know about what you will have during the interview,
the more you can focus on studying what you won’t.

Prep for success


One of the best ways to prepare for any interview is to
arm yourself with as much info as possible going in.

AS K FO R A DE TAI LE D B R E AKDOWN OF THE INTERVIEW

Pair programming interviews can last anywhere from an hour to half a day, so ask your
interviewer for a detailed breakdown of the interview itself. You can then start to plan
how you’ll prioritize your time when it comes to testing and debugging your code. Even
if you don’t know the actual problem you’ll be facing yet, simply having an idea of the
scope will make you feel more prepared and relaxed.

ST U DY AGI LE ME T H O DO LO GIES

Pair programming is an agile technique, so study up on agile methodologies before your


interview. If you aren’t familiar with techniques like TDD, use this interview as a learning
experience. You’ll have to learn on the job anyway, so asking relevant questions can
demonstrate your enthusiasm to do so.
During the pair programming interview
B ALAN CE COLLAB ORAT I ON AND PROBLEM- SOLVING

The pair programming interview is as much a test of your communication ability as it


is programming. It’s a real example of how you work every day, and an interviewer is
going to be much more eager to hire someone they have good rapport with. While you’ll
still need to produce working code, keep in mind that you’re developing a working
relationship with your interviewer at the same time.

On your side
A pair programming interview is designed to set you
up for success. Your partner is there to help.

You don’t just have to talk about code—small talk about something else when you first sit
down will both ease your nerves and show the interviewer that you’re a friendly person.
Once you feel comfortable with your partner, it’ll be easier to ask more complex questions
about coding and your approaches during the actual exercise.

Use every tool you have available. Think about edge cases. Test your code as you go, if
you can. Pair programming usually allows you access to the same resources you have on
the job, so use those to your advantage.
In the end, your partner is your most useful tool. Think out loud and explain the steps
that you’re taking. Why did you break down your problem into these pieces? Outline the
solution you plan to take to problems before you start. Everything you discuss out loud is
an opportunity for your navigator to give you feedback and agree or disagree.

Explain any shortcuts you take—be sure to explain why you took that shortcut and what
you would do differently with more time. It’s important that the interviewer knows how
you actually work.

Once again, this test is supposed to emulate a normal workday, so if you can’t act the
way you would during a normal day, explain why and how you would approach the
problem in a more natural environment. This not only shows your problem-solving
skills, but is an excellent demonstration of anticipating your interviewer’s concerns and
communicating effectively.

Embracing errors
Mistakes happen in day-to-day life at work, so simply
show how well you can handle making a mistake and
how you find a solution.

Remember, silence is natural. As much as you try to think aloud, there will inevitably
come a time when you get in the zone and just work. And your partner might not have
any advice to give at that particular moment, which isn’t necessarily a bad sign. As long
as you’re demonstrating that you can collaborate and communicate, don’t feel obligated
to fill every second with noise.
Whiteboarding
The whiteboarding interview is a way for you to demonstrate your coding and problem-
solving skills to a group of interviewers, managers and software engineering team
members. You’ll solve complex problems with handwritten code, while talking through
your thought process and fielding questions from the panel.

How to prepare
C H O O S E A LAN GUAGE

Most companies let you choose whatever language you want for the coding interview.
Pick your language from the very beginning and use it to study with. Generally, Java,
C++, C, C#, Ruby and JavaScript are safe bets, but be careful not to choose a language
just because it’s trendy or you think the interviewers will be impressed. Remember,
employers are more concerned about how you solve problems with your chosen
language—not if you know the coolest language.

Places to practice your skills


Try Codementor, Gainlo or interviewing.io to schedule
a mock whiteboarding interview with a real tech
expert or even a hiring manager.

PRACT I CE O N A R E AL WH I T EBOA RD

If you’ve never gone through a coding interview before, you’ve probably never coded
with just a marker and whiteboard, or even a pencil and paper. It’s surprisingly difficult
without the crutch of an IDE and the editor’s autocomplete and syntax highlighting
features.

That’s why you should prepare for the whiteboarding exercise by buying a mini
whiteboard and dry-erase markers to simulate the interviewing environment. This will
help you learn whiteboard space management skills and give you a taste for what it’s like
to physically write out code, instead of relying on a keyboard and code editor.
For the whiteboarding session you can expect to see problems like:

Implement a well-known algorithm.


Implement a trivial algorithm.
Find if a binary tree is balanced.
Reverse words in a string.
Check if a linked list is circular.

R EV I EW COMP U T E R S CI E N CE FUNDA MENTA LS

The coding interview is like a traditional job interview and a rigorous CS exam all
rolled into one, which means you have to study for it—regardless of your educational
background and level of experience.

And while you could buy a book detailing every algorithm, data structure and
programming paradigm in the CS universe, you probably don’t have time to read it front
to back, and the information probably wouldn’t stick, either. So, instead of spending your
prep time scanning books and mindlessly watching online tutorials, laser-focus on the
topics that are most likely to come up in the coding interview:

For a back-end developer… For a front-end developer…

Trees JavaScript design patterns


Big O notation Nuances of HTML and CSS
Sorting algorithms CSS preprocessors
Hash tables CSS naming conventions
Graphs Intricacies of JavaScript
Heap Basic computer
Arrays architecture concepts
Recursion
Linked lists
Stacks and queues
Bit manipulation
Well-known library functions
Know how to study
Knowing what to study is the easy part. Actually sitting down and studying those topics
can be tricky. The best way to really understand concepts is with hands-on practice.

Start studying by solving two or three coding questions per day. Breaking it up like this
keeps you motivated and doesn’t force you to sacrifice too much of your free time.

Study smarter
“Spaced learning” can boost knowledge by 50% and improve retention.

So, follow this 10-15-minute process two or three times per day to get interview-ready:

Read the problem carefully a few times.


Take time to think about your solution.
Write out the pseudocode.
Write out the actual code using correct syntax.
Consider the edge cases. Do you pass them all?
Try improving your code by making it more elegant.
Review your solution again.
Check your solution against the solution in the book or online resource.
Think about other ways you could have solved the problem.

You can find coding questions that mimic what you might encounter during your
interview at:

Codewars
HackerRank
Interview Cake
CareerCup

If you prefer books, try the coveted Cracking the Coding Interview: 150 Programming
Questions and Solutions, written by a woman who passed coding interviews and received
offers from Microsoft, Apple, IBM, Goldman Sachs and other big-name companies.
During the whiteboarding interview
AS K C LAR I FYI N G Q U E ST I O N S

Don’t just jump in and start coding—even if you think you already know a possible
solution. Asking questions not only gives you time to collect your thoughts and the best
shot at answering correctly, but it also shows the interviewer that you think carefully
about all sides of a problem before diving in. It can even help you understand the
interviewer’s priorities and what they’re looking for in a solution.

?
?

T HI NK OU T LO U D

Interviewers are mostly curious about your thought process, not necessarily if you get the
right answer. In fact, if you know the answer right away and silently write out the code,
the interviewer may think you’ve heard the question before or already knew the answer
from a study cheat sheet. And if the interviewer only cared about whether or not you can
write good code, they would just look at your GitHub profile.

Keep your interviewers engaged every step of the way, and allow them to follow along.
They may even throw out hints or steer you away from a certain solution. Think of them
as your support system during the whiteboarding interview.
K N O W WH AT TO DO WH E N YOU GET STUC K

Whiteboard interviews are designed so that you don’t know the answer right away. As a
result, you may get stuck and feel like there’s no way out. If this happens, realize that it’s
supposed to happen.

The interviewer is looking at how you react to a difficult problem. Do you stare at the
whiteboard in a cold sweat and remain uncomfortably silent? Do you say “Sorry, but I
have no idea how to do this,” and leave it at that?

When you get stuck, think about the problem for a few seconds and be honest with your
interviewer. Say something like “I’m not quite sure how to do this, but I’m going to try and
figure it out.” In most cases, the interviewer will work with you to arrive at a solution.

Think out loud so your interviewer can give you hints and guide you in the right direction.
Talk about what you think could be a solution, and talk about why it won’t work. Ask for
help if needed and bounce ideas around with the interviewer. After all, collaboration is a
key characteristic for a software developer.

Try breaking the problem down into smaller, bite-sized pieces. Start by writing an
inefficient, brute force solution, and work on optimizing it if you can. Remember: Coming
up with something is better than nothing.
Panel interviews: Near the finish line
You’ve almost made it! Not all tech interviews include a panel interview, but if yours does,
it’ll likely take place after you’ve met the hiring manager in-person and passed any onsite
coding challenges.

During a panel or group interview, several decision-makers from the company come
together to interview you in the same room (or via video chat), at the same time. Panels
typically include three to five employees representing different job functions—or even
different departments—at the company. The purpose? Get perspective from a range of
stakeholders, help eliminate bias in the hiring process and see how well you perform
under pressure.

What different stakeholders look for


PR O D U CT MAN AGE ME N T

Rather than necessarily honing in on your technical abilities, product managers will
feel out how well you adapt to changing requirements and respond to challenges. How
comfortable are you tending to the smallest product details while keeping the big picture
in mind? What’s your process for dealing with conflict? Do you deliver on time? The
questions product managers ask aim to reveal your level of passion for the products you
work on as well as the contributions you’ll make.
DI R ECTOR AN D V P

As drivers of overall engineering success while staying true to the company’s mission and
values, directors and VPs will ask questions that dig deeper into what motivates you on
a day-to-day basis. Expect to detail how you’ve both made an impact in previous roles
and how you plan on growing with the company. How do your career goals align with the
role? What leadership qualities do you bring to the table that will help you mentor future
new hires and/or grow into a leadership position yourself?

H I R I N G MAN AGE R

Beyond your technical skill set, hiring managers want to know how you align with
engineering and product principles as well as overall company culture and values. So
in addition to focusing on traditional hiring criteria, like education and programming
language requirements, they want to see how you interact with different groups and
personalities.

F EL LO W E N GI N E E R

You’ve made it this far in the hiring process and shown you have the right mix of skills.
Now, fellow engineers want to know that you have the technical know-how to go above
and beyond—and that you’re willing to learn along the way. Depending on the role you’re
applying for, they’ll test your knowledge on any number of related topics, like distributed
systems and design patterns, algorithms and data structures. Each question they ask
helps them assess your tech skills (and if you’re willing to learn what you don’t yet know)
as well as how you’ll fit in with the overall team.

N O N- PRODU CT AN D E N GI N E ERING

Non-technical panel members like marketers, salespeople and designers hope to learn if
you’re a strong fit, tech skills aside. They might ask questions related to your soft skills,
like your ability to communicate effectively and solve problems, and will pick up on clues
that reveal valuable insights about you. For example, do you accept feedback positively
and use that insight to shape your processes? Can they bring you in for a customer call?
How do you learn and grow from mistakes?
How to prepare
R ES EAR CH AN D B RAI N STO R M

Again, find out who you’ll be talking to. Make it a point to remember names so you can
address each panelist directly during the interview. Have questions ready, and make sure
you come up with questions for each panelist, even though you won’t get to them all.

PRACT I CE T H E ART O F GR O UP EYE CONTACT

Interacting with a group of people is very different than engaging with someone one-
on-one. Making eye contact, for example, is often trickier when speaking to a group. And
when you’re nervous, it can be even harder.

All about the eyes


67% of interviewers say failing to make eye contact is
one of the biggest interview mistakes.

You might be tempted to focus on one interviewer (often the most senior-level panelist
or the one you connect with the most). Or, you might have a tendency to avert your gaze
and avoid looking anyone in the eye. But it’s important to give equal attention to each
panelist since they all likely have a vote.

Practice confident body language whenever you’re in a group prior to the interview.
When one person asks you a question, maintain eye contact with them at the beginning
of your answer and then shift your gaze to others as you continue to elaborate. This will
help you establish rapport and create a conversational atmosphere.

Now that your interviews are over and you should be proud of yourself, you’re not
entirely done yet! Keep your competitive edge—and take proactive steps to learn from
your experience—by following through with a few key after-interview steps.
After the interview
Now comes the hardest part—waiting. After a job interview, sometimes it can take a hiring
manager two days to get back to you. Sometimes it can take two months. The uncertainty
that comes after your interview for that dream role can be anxiety-inducing.

Instead of sitting around waiting to hear back, there are a couple of things you can do to
make the most of the waiting period—just make sure you walk the fine line of expressing
interest without putting anyone off.

Evaluate yourself
Jot down your thoughts while each portion of the interview is still fresh in your mind.
What did you do well? What could you have done better?

Write out how you feel about the company overall as well as the technologies and duties
the job requires. It’s also a good idea to jot down the questions you were asked to better
prepare for future interviews.

Follow up
Always send a thank you email to the people who interviewed you, preferably no later
than the day after your interview. There are a couple of reasons why this is important,
mainly because it’s good manners, but also because it helps keep your name fresh in the
interviewer’s mind.

In your email, thank the interviewers for their time and sum up one or two things you
discussed in the interview. Keep in mind, this isn’t the time to bring up next steps or their
hiring timeline. Wait at least one week before you ask about the status of your candidacy.

Should you send a handwritten note?


Snail mail takes longer to get to the recipient—email
is immediate. We recommend using (at least) email
for all job correspondence.
If the role isn’t a good match for you
Remember, the interview also gives you the chance to interview the company. So, if you
feel the role isn’t the right fit for you, let your interviewer know as soon as possible. Not
sure? Make a pros and cons list, and figure out what’s holding you back.

If you no longer want to be considered, thank the employer for their time and let them
know you’ve decided to move in another direction. Be professional and polite—a more
relevant opportunity with the company might present itself in the future.

Waiting to hear back


A few days after your interview, you might be tempted to reach out to your interviewer to
check if you’re still being considered for the position. This isn’t necessarily a bad thing,
but there are a couple of ways you should go about this process.

Don’t keep the hiring manager waiting


Don’t let the company feel like it’s been ghosted since
they might have a close second choice. Check your
email several times a day and reply in a timely manner.

For starters, we recommend you wait at least one week before reaching out after your
thank yous, and unless you’ve been communicating by phone primarily, stick to emails.
DO N’ T B E AFRAI D TO AS K Q UESTIONS

In your follow-up email, ask about the timeframe in which you can expect to hear
a decision. You can also ask if they need additional information from you, which
could include reference or more insight on projects you discussed. You could send it
proactively—any supplemental information certainly couldn’t hurt.

Stick to sending only one strong post-interview email. If they respond promptly, great.
But if you don’t hear back, it might be best to move on and continue your job search
elsewhere.

Getting interview feedback


You thought the job interview went well, but no call back. And because job hunting is
stressful enough, if you feel like you’re making the same mistakes without knowing
how to fix them, it can seem like you’re running in circles. How do you get constructive
feedback?

Number one: Make sure your interviewer knows how appreciative you are of their time.
Being on their good side, especially if your interview itself wasn’t as successful, is key to
getting them to provide valuable feedback.

If they offer feedback (which they might not), thank them for sharing their thoughts
and encourage them on their search for the ideal candidate. While receiving feedback
might feel like you’re reliving the initial job rejection, use the advice to grow. The hiring
manager might not have a position for you now, but they certainly may know someone
who does (or keep you in mind for a future, more relevant opening).

...

...
Summary
When the day of your interview finally comes, know that you’ve
fully optimized your interview prep so you can walk into your next
tech interview feeling prepared and confident.

From the initial phone screen to the take-home coding assignment


to the in-person interview, onsite coding challenges and panel
interview, you’re now well equipped to ace every stage of your tech
interview journey and land your dream role.

Want more advice specific to your next career move?


Sign up for Seen to get free technical career coaching—and get
matched to your next role.

Join For Free


Go further in your
tech career
1 Join Seen.

2 Match to in-demand roles.

3 Get free career coaching.

4 Take the next step in your tech career.

Sign Up Now

You might also like