By Harry Roberts
Harry Roberts is an independent consultant web performance engineer. He helps companies of all shapes and sizes find and fix site speed issues.
Written by Harry Roberts on CSS Wizardry.
N.B. All code can now be licensed under the permissive MIT license. Read more about licensing CSS Wizardry code samples…
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’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.
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.
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.
This question does a few neat things:
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.
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.
You’re all prepared, you’ve done your homework, and now it’s the big day!
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.
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.
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:
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.
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?
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.
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.
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.
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?
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.
I guess, in summary,
N.B. All code can now be licensed under the permissive MIT license. Read more about licensing CSS Wizardry code samples…
Harry Roberts is an independent consultant web performance engineer. He helps companies of all shapes and sizes find and fix site speed issues.
Hi there, I’m Harry Roberts. I am an award-winning Consultant Web Performance Engineer, designer, developer, writer, and speaker from the UK. I write, Tweet, speak, and share code about measuring and improving site-speed. You should hire me.
You can now find me on Mastodon.
I help teams achieve class-leading web performance, providing consultancy, guidance, and hands-on expertise.
I specialise in tackling complex, large-scale projects where speed, scalability, and reliability are critical to success.