More On Interviewing Front End Engineers- If You Ask About Something, Really KNOW It (With an Example Based on the W3C Box Model)

I’m going to be writing a bit more about practical development topics here over the next few weeks. Code is fun to write about but code takes time. Sharing my experience and opinions on the day-to-day life of a front end engineer I can do with a little less effort. Also, since I’ve been doing it forever and have experience all over the place I feel like I just might have something to share.

Anyway, today I’m going to continue to talk about the technical interview process. This time with an anecdote culled from my time on the other side of the desk.

I was interviewed a while ago by someone who was significantly junior to me. I think he had maybe 3 years of experience. I was supposed to have been interviewed by someone who would have been a peer at the company, but that fell apart and it fell down to a junior resource. He asked me two questions over a span of ten minutes. Both were worth commenting on, but I’m going to focus on the first one as it illustrates something pretty important about who you have interviewing people and what they should be expected to be able to figure out about a candidate.

We get on the phone, trade pleasantries and then he gets started. He asks me the following question:

“You have a div with a width of 300 pixels. It’s got a margin of 10 pixels. How big is the box?”

Do you see a problem with that question?

If you’re trying to test someone on knowledge of the W3C box model, margin is meaningless.

The way to ask that question is to use padding. Margin sits outside the (visible) box. It’s part of the element’s total offset width, but it’s not part of the visible width. More importantly, that’s true no matter what box-model you’re dealing with. So, if you’re asking about the box, without borders or padding, 300px is going to be 300px no matter what the margin is.

Here’s a jsfiddle which illustrates that using the CSS3 box-sizing property. Inspect away.

So, faced with knowledge of all the above, I asked a follow-up question:

“Okay, you’re trying to see if I understand the box model. Cool. So, do you want the size of the div visually (the width of the box) or do you want its offset width? Margin is outside the box so it’s meaningless for the width of the box.”

At this point things broke down. I won’t go into details (especially since .it’s been over a year,) but the thing I walked away from the conversation with was the plain fact that he wasn’t prepared for anything other than a number to come back as an answer. I was going to be judged solely on the calculation I did. Things fell apart because his question was poorly worded, focused on the wrong property and he wasn’t confident enough on the topic to clarify so that I could provide the correct answer. We talked about it for about five minutes and I still don’t know what the “right” answer was.

As a note, I actually mentioned box-sizing:border-box. I’m pretty sure that ended up making things worse.


When I do quizzes like this (and I don’t- I prefer whiteboard/coding sessions), I’m looking for questions. A lot of times the questions and comments are going to tell me more about a candidate than a quick answer. Questions and comments expose depth. Depth of knowledge = good.

The thing is, to be able to do that I need to absolutely know the subject I’m asking about. Otherwise… you get what I experienced, five minutes of frustration and embarrassing gaps in the conversation.

The takeaway?

In a technical interview, only have people cover topics that they really know. If you want junior people to interview, coach the hell out of them on the subjects they’ll be asking about so that they don’t end up wasting anyone’s time.


Oh yeah… You’re wondering about the other question. It was:

“What’s your favorite JavaScript library and why?”

At which point, I think I fell asleep.

Leave a Reply

Your email address will not be published. Required fields are marked *