DEV Community

loading...

Demystifying the Frontend Technical Interview

lasertuskey profile image Alexa Tuskey ・3 min read

I’m going to state the obvious here: technical interviews are hard. It’s an unnatural thing, having a near-stranger (or several) watch as you face off with a problem you may or may not have encountered before, in an unfamiliar environment, with a time limit. For the majority of us, we are used to doing most of our work alone, in the comfort of our own setup, free from judging eyes and time constraints (outside of deadlines, of course). So how is one supposed to ace something that seems designed to make you fail?

Disclaimer: I’m not claiming to know how every technical interview is handled. Different companies have different processes, so do your homework beforehand via Glassdoor, or better yet, networking with people who currently work there. I wanted to write this article because I’ve seen so many talented developers let nerves/imposter syndrome/stress freeze them up when I know they know what they’re doing. I hope this perspective from other side will give you a confidence boost to let your hard work and talent shine.

You don’t need to finish.

I want to see how you work. I could care less how quickly you do it. You aren’t going to be working like this if we hire you, so why would I expect you to hackertype like your life depended on it? Take a deep breath, and take your time. If you want talk through what you’re doing and use me as your rubber duck, great. If you’d prefer to concentrate in silence, no problem. I want to see how you approach the problem, if you write pseudocode, what methods you try and if something doesn’t work as expected, how you get around it. I’ve seen really good developers get choked up and freeze because they’re watching the clock. While it’s much easier said than done to relax, just know that speed does not necessarily equate understanding in my eyes, so take your time.

It’s okay to ask to look something up.

You’ve probably heard the phrase, that good developers are good Googlers. It’s true! The more experience you get as a developer, the better questions you know to ask. Plus, we are expected to know a lot of information! Different languages, different syntaxes, different tools. Why would I expect you to memorize everything you’ve ever learned if I use search engines daily in my own workflow? If you need a refresher on the syntax of the Fetch API, don’t be afraid to ask to look it up really quick. I can see the difference between someone who understands what they’re doing, and someone who is just trying to look up answers to quickly copy and paste.

Be careful with frameworks/libraries.

Unless you are very comfortable using a framework or a library in a sandbox environment, skip it for Vanilla JS/plain CSS. You may be used to working with one in a pre-setup environment, whether it was set up by someone else or by a meta-framework like Nuxt, but trying to set one up in a sandbox while you’re against the clock can lead to stress and disaster. Depending on the seniority of the role, if you don’t have much experience with frameworks but are strong with Vanilla and plain CSS, that’s going to look a lot better than fumbling with the set up and syntax of a framework.

Be open to advice.

If I see you getting stuck and the right questions just aren’t coming, I’ll try my best to drop some helpful tidbits to point you in the right direction because I want you to succeed. Not everyone likes taking advice though, especially if it isn’t their preferred way of doing things. You are free to solve your problem however you want, but if you don’t even consider a different way (without explaining why), I might question how you’ll work within our team and with other developers.

One more little secret: I get nervous interviewing people too. Am I coming off as welcoming and friendly? Do I sound like I know what I’m doing? Will I know the answer if I’m asked a question? Remember: you are interviewing your interviewer too (as weird as that sounds). Would you like working with/for this person? Does the team you will be working with seem supportive and inclusive? Does the challenge you are being given seem fair to the role and skill level that you are interviewing for? Practicing these questions internally beforehand helps humanize your interviewer and generally makes the process a little less scary. Remember, a good company/interviewer/human should be rooting for you too.

Discussion (0)

pic
Editor guide