Yesterday, I spoke at ITKonket in Kragujevac, Serbia.
During the Q&A after my talk, one great and non-technical question I got was for
general advice on interviewing at tech companies. I decided to write down (and
expand on) my answer in the hope that it might help someone else, too.
Disclaimer
- I don’t claim to be an authority on interviewing.
- I don’t think this article is definitive or gospel.
- I’ve been self-employed for over five years—I haven’t interviewed for
a full-time role for a long time.
- Your mileage will vary; apply your own context before disagreeing.
Preparation – Before the Interview
I’d say that solid preparation can carry you through the majority of an
interview. It helps to quell the nerves, shows that you’re proactive, and gives
you a head start. Dedicate a lot of time to preparing for interviews.
Most prep work will come in the form of asking questions: here are some of the
most effective ones I’ve used.
Who Will be Interviewing Me?
This is key, and can really, really help you out. If emails are between you and
a recruiter, there’s a strong chance that you will not be getting interviewed by
them. This means that you’ll be going into the interview cold, and your first
encounter with the interviewer will be live on the night.
If this is the case, ask the recruiter who will be interviewing you (you need
a name and their title). Depending on their answer, there are a few approaches
to take. Let’s have some example scenarios and how I would handle it.
- The Head of Technology, Sara Jensen: Right, it’s the big guns. The Head of
Tech likely reports into C-level staff, so they’ll sit pretty close to the
business, but might not have as much hands-on technical knowledge as
a day-to-day engineer. Focus less on technologies and syntax and think more
about strategic and business-facing case studies from your past.
- The Principal Engineer, David Bates: Okay, it’s someone pretty technical;
someone who writes code on a daily basis. They likely influence and guide
platform and technical decisions and also hold some seniority. Research the
team’s stack, and prepare to shoot the sh*t about coding from the trenches.
- Front-End Team Lead, Nic Reed; and Head of UX, Preethi Patel:
Cool, a nice mix. They’re relatively senior, but the fact that design gets
a representation means that it won’t be a full-on engineering onslaught.
Familiarise yourself with the product in question, and brush up as much as
possible or necessary on design fundamentals so as to be as least
semi-conversant (e.g. suggesting solicited improvements to their onboarding
flow).
Naturally, there could be any mix or cross section of the above, so prepare
accordingly.
Next, ask if it’s possible to get an email intro to the relevant people ahead of
time as you have some questions for them.
Conversely, if you are already emailing with the person who will ultimately
interview you, you’re pretty well set up—you won’t be going in cold. Use your
emails to get a sense of the person: are they formal or informal? Do they seem
hurried? Did they mention an aspect of their personal life (Apologies for the
delayed reply—I’ve been on holiday over the long weekend.
)?
You can use these hints to make conversation in the interview, and use them as
anchors to link back to when making smalltalk (How was your holiday? The
weather was perfect for it!
). Be as personable as possible so that you’re
already beginning to form a not-purely professional relationship with them. But
go easy on it. Don’t go Instagram-stalking them or sending them friend requests.
Make a good impression. Be interested; be interesting. They’re hiring a human
being, after all, so use this as an opportunity to differentiate.
I’ve Read Your About Page but Is There Anywhere Else I Can Look for a Good Company Overview?
This question does a few neat things:
- It tells them you’ve already read their about page (but you do actually need
to have read it), so they know you’re taking this seriously and researching
your prospects individually;
- it tells them that you’re keen to know even more if it’s available;
- and they spoon-feed your the exact most relevant information for you to get
a good feel for the organisation. The best info, direct from the source.
What Should I Prepare For?
Literally ask them how to best prepare for and pass their interview. Will you
need to bring a laptop? Will you be meeting at their office or an off-site
location? Do you need to buzz into a shared reception area? Who should you ask
for upon arrival? Will there be any whiteboarding tasks? What would they like to
hear from you? Should you prepare a portfolio of work? Do they want to see any
code you’ve written (if yes, tidy up your repos and check relevant permissions
for showing code you’ve written elsewhere).
Forewarned is forearmed, so ask ask ask. It will leave you better prepared, less
stressed, and make the interview run more seamlessly.
Prepare Your Questions Ahead of Time
There’s a real tendency to panic when the interviewer asks And do you have
any questions for us?
It’s all too easy—and common—to hurriedly answer
Err no yeah everything is great thanks so much!
Prepare your questions ahead of time, and ask them confidently. My advice here
is: buy a nice notepad and a nice pen, assign a fresh double-page specifically
for the interview, and reserve the left page for notes you take as you chat, and
on the right-hand side, list each of your questions as a heading under which you
will write down their answers. Interviews are two-sided, so you need to show
that you’re taking it seriously. Ask the important questions. Examples are
coming up later in the post.
At the Interview
You’re all prepared, you’ve done your homework, and now it’s the big day!
Be Personable
Arrive ten minutes early. Chat with the receptionist as you wait, make note of
your surroundings, use it to make small-talk (I love your offices! How long
have you been in this building?
). Make a good impression on everyone you
encounter—you want everyone to be fighting your corner. If they offer you
a drink, take them up on it confidently even if you don’t want one. (A black
coffee would be great, yeah! Thanks!
)
Use every opportunity to open a dialogue and have a reciprocal experience.
You’re probably nervous, but do everything in your powers to mask it. Be a good
person to be around, and make people see you as a potential workmate, not just
another interviewee.
Whiteboarding
I hate, hate, hate the performing-monkey, putting-someone-on-the-spot in an
already stressful situation, distinctly Silicon Valley practice of making
someone write needlessly complex, already-solved solutions to long-since
abstracted-away algorithms with a pen. They remind me of the primitive
hazing techniques that people are put
through in order to join fraternities: the previous generation watching the
current generation suffer and squirm because that’s just how it works
.
But. They’re probably going to happen.
To prepare for this, ask before the interview if there will be any whiteboarding
and what topics might be covered. Read up on a basic working knowledge of the
topics they list, but don’t devote too much time to memorising the syntax (more
on that in a second).
When the whiteboarding task starts, make a quip or light joke along the lines of
Oh, wow. I hope you provide full-time staff with computers—I don’t like the
idea of typing up my handwritten code at home on an evening!
. Something like
this should help to make the situation a little easier, while also gently
pressing home the sheer ridiculousness of the situation.
Honestly, I have such strong opinions about whiteboarding tasks. Oh,
you’re applying for a job as a chef? Please rear some cattle, invent fire, and
make us a steak. You may not use any kitchen equipment. We’ll just be stood over
here. Watching. Judging.
Next, before you begin, forewarn them that this is an uncomfortable environment
in which to ‘write code’; tell them that you intend to annotate any knowledge
gaps as you go, thus demonstrating that you know you need to look into something
a little further, but also that you have a vague idea of what that something
else is.
If they’ve refused to give you adequate tooling (i.e. a computer), then you have
every right to make your own compromises, too: Normally I’d have linting and
syntax highlighting, etc., so in order to save everyone’s time, I’m going to
write this out in pseudo-code.
Don’t ask if you can write pseudo code: tell
them that’s how you’re going to approach the task. Regain some of the power.
Once you’re done, make sure you’re very aware of any parts you struggled with,
and be sure to talk through what you would do to fill in those blanks. It’s
been a while since I implemented x, but I know that the documentation
covers the exact syntax in detail.
Your Questions for Them
You’re interviewing them as much as they’re interviewing you, so make sure you
use your time to get vital insights into the organisation and what you life
there might look like. As I mentioned earlier, be sure to have these questions
written down as headings ahead of time. In no particular order:
What Might My Average Day Look Like?
Honestly, as basic as this question might seem, it’s amazing just how little of
a role becomes apparent until you’ve started working there—that’s a little too
late for any surprises. Asking for a rough idea of what your typical day might
look like forces the interviewer to envisage you successfully in the role, and
to give deliberate thought to what exactly they will expect of you.
This is a good opportunity to catch any unexpected duties that were missing from
the job spec, and also helps with the first-day nerves of what do I even do
here?!
It makes the role feel a lot more concrete and tangible, and you can
spend the next few weeks looking forward to life as described to you, rather
than playing over scenarios in your head.
Why Is This Position Available?
A very simple but incredibly effective and eyeopening question. If the answer is
We’re showing really good growth and projections are even healthier, so now
is time to expand the team a little. We’re adding two new engineers, and
designer, and a dedicated product owner this quarter
then you’re onto good
news! The company is doing well and you’re about to become part of that journey.
Share their enthusiasm, congratulate them, and say you’d love to become a part
of it.
If, however, the answer is Our current front-end developer leaves in a month
and we’re looking to find a replacement.
then it’s, unfortunately, a little
more pessimistic.
If you can pluck up the courage, ask why they’re leaving. Answers like She’s
taking another role at another organisation
means that they’ve found
something that, for whatever reasons, they perceive to be better than the role
you’re about to adopt. Was it a pay dispute? Was it work-life balance? Was it
something much more innocuous such as they simply grew tired of a long commute?
Where Do I See Myself in Five Years?
If anyone asks you the age-old Where do you see yourself in five years?
question, reply that a large part of that will depend on where the company is in
four years. If they stay on track and their ethos continues to match your own,
then great! You’d love to see yourself doing whatever it is you want. But be
honest with the fact that you would keep a keen eye on the company’s plans and
form your decisions based a lot on that.
How Will My Progress Be Monitored and Fed Back to Me?
Once you’re in, who’s keeping an eye on you? How do you know you’re doing the
right thing? Who’s going to help you progress to the next steps? Will you have
regular 1:1 meetings at which you can raise any concerns? Will you have any key
targets against which you will be measured?
This is vital, and can raise red flags immediately. I’ve seen too many
developers fall between the cracks at larger organisations as their individual
progress is neither monitored or communicated back to them.
What Is the Worst Thing About Working Here?
If you’re feeling particularly brave—this can be a difficult one to ask—then
this question is a good way to get a more rounded view of an organisation.
As cliche as it may be, it’s not uncommon for interviewers to ask What would
you say is your greatest weakness?
This question is just a slight rewording
of that.
The person interviewing you, unless they’re a founder, is likely a member of
staff much like you hope to be. They will have their own gripes and annoyances
with the company, and they may well be comfortable sharing them with. You’re
unlikely to get brutal honesty, but maybe they’ll give you some insights such
as working long hours, lack of autonomy, legacy work, etc.
If I Have More Questions…
A question might spring to mind after the interview has passed, so leave with
something along the lines of: I appreciate that you’re busy, but if any
questions spring to mind over the coming days, would it be okay to drop you an
email with them?
Follow Up
An appropriate amount of time later (usually the next morning), fire them
a follow-up email simply thanking them for their time:
Hey <name>,
You don’t need to reply to this email if you don’t have time, but I just
wanted to say thanks.
I really appreciate your time yesterday—it was really nice to meet you and
hear more about the challenges at <organisation>. I felt the interview went
well, and I got a really great feel for the company and the team.
If I haven’t heard from you by next Friday, I’ll chase up. Until then, have
a great week, and I hope <reference to something personable from the
interview itself>.
Speak soon,
<name>
Polite, to the point, and sets expectations. It also prepares them to hear from
you, in case they’re the kind of company that is prone to ghosting its
interviewees.
Key Points
I guess, in summary,
- Prepare. It’s all in the preparation.
- Be confident, be human.
- Ask the right questions and carefully analyse the answers.
- Smash it!
Log in
