loading...
Cover image for Technical Interview Teardown

Technical Interview Teardown

renascent479 profile image Serena ・4 min read

Opinions expressed here are my own and do not necessarily reflect that of my employer

The technical interview. The bane of a candidate's existence. Are they going to ask me to program something? Recite obscure Javascript prototype methods? Oh god, what if there's... whiteboard questions?

There's already many guides available elsewhere that'll go over questions and answers. Instead, I'll be going over the types of questions I ask, what I'm looking for, and how a candidate's skill is gauged.

So lets get started.

Lets see you get past this


If you get invited to an onsite, congratulations. This means you've made it past a recruiter screen, got our interest, and passed a phone screen. This is no small feat, so keep that momentum going.

Many teams use a standard set of questions that they ask everyone. I've seen Fizzbuzz, Javascript string manipulations, Big O complexity, server architecture, and this weird one about simulating a weighted dice roll.

I eschew a structured set of questions for flexibility. If the candidate performs better or worse than the baseline, I don't want to be locked into a set of questions geared towards the wrong skill level.

Whiteboarding


Sorry to say, but I'm one of the interviewers that use whiteboards. First off, I'm not judging you on your code quality or handwriting skills. I want to see your ability to convey your thoughts on the board. Because, surprise, this is something that happens a lot in our team when we collaborate.

My questions are also multi-part, so writing everything down tends to be helpful. Otherwise it'll be more challenging for you when I make a reference to a few questions back.

I've encountered numerous candidates who were very resistant to writing anything on the board. Telling them the reasons above usually works. If not, then you'll be tested on memorization skills as well :)

I'm going to have to science the heck out of this


The first technical question is an open ended, simple question:

I have several content items that I want laid out horizontally, side by side. What are the different ways can you accomplish this with HTML and CSS?

I use this as a gauge to see what's on the table to ask. Do you name a half dozen options, do you struggle after naming two, or do you wash out immediately?

This may seem like a very easy question, but I've had more candidates fall into the latter two buckets than the first.

After a few follow up questions, I move onto the next stage:

You have a site nav menu. I want to trigger an analytics method before opening each nav link. How would you accomplish this?

At this point, I'm throwing a feeler on your Javascript skills. Do you immediately reach for jQuery or Angular?

Unless specified, go with vanilla Javascript. We like to see developers with a good foundation instead of those that only learn the framework of the week.

What type of selectors are you using? Are you asking how that analytics method works? How are you triggering the event?

These are some of the routes the follow-up questions can take. Rarely will I have one off questions. I'll always have a follow up that'll ask a different aspect.

The Presumption Reflex 1


Take a moment to read the above article. Ok, finished? This is something that's not regularly tested for in technical interviews but is important in our day to day work when working with stakeholders.

In the first example question, I only said several content items. Did you assume it'd be images, paragraphs, or tabular information? It's important to know because there's an answer that's semantically correct for each.

I'm always keeping an eye out for if a candidate observes that I was vague with my questions. It's best to ask for clarification. You'll never be docked points for asking questions - sometimes that's the goal of the exercise - unless we get the impression you're asking questions because you have no clue on how to answer it.

A-Mei-ze Me

Ultimately, what am I looking for? A good handle of all the basics and original solutions. I always prod for additional answers for the same problem, because as engineers, that's what we do. We solve the problems that arise when the previous solution no longer works.

Unfortunately I'm limited to what else I can show so good luck!

If you are still looking for actual frontend developer questions, here is a decent page.

Posted on by:

renascent479 profile

Serena

@renascent479

Software Engineer for Web and Mobile at Blizzard Entertainment | All views expressed are my own | Now 47% fueled by donuts 🍩

Discussion

markdown guide
 

If you use Agile methods, how about putting these into user story form? For example...

"As a marketing analyst in charge of a website I want content items laid out horizontally, side by side, because my research has shown this increases user engagement."

"As a marketing analyst I want to record analytics before website users open nav links because this allows us to track user engagement."

I've found doing this will stimulate a better discussion as the candidate asks questions, breaks the story down into tasks and describes the possible solution. Basically, it's kind of like a product backlog refinement meeting.

 

This is great. I appreciate the notion that whiteboarding as part of the interview process is to elucidate how the interviewer thinks and approaches a problem. In my team we use our whiteboards when we are strategizing with another colleague as a place to map out the problem. I think seeing how an interviewer uses the whiteboard as a tool of team collaborative communication would be most helpful, much more than their handwriting or ability to write a piece of code without a code editor, as you mentioned.

 

Great article! Immediately realized I've read your articles before on here when I saw the Overwatch gifs/references. Overwatch is the only game I reach for at the moment 🎮 💯