Tips for Technical Interviews

This content originally appeared on CSS Wizardry and was authored by CSS Wizardry

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:

1. 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;
2. it tells them that you’re keen to know even more if it’s available;
3. 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!

This content originally appeared on CSS Wizardry and was authored by CSS Wizardry