What I’ve learned from 100 frontend developer interviews

Intro

It hasn’t been exactly 100. But I’ve done a ton of interviews. From preliminary screening calls to random recruiter net castings, Linkedin anonymous agency trolling, multi-stage challenges, all the way to final rounds and job offers — I’ve done enough to not want to do them anymore. I have a good idea of how they work, what to expect, common questions, and how best to play yourself up so at the very least you can get it done as fast as possible.

TL;DR

If there’s one takeaway from this article: ask what the salary range is AT THE START of any interview. Or better yet — ask at the very outset of initial contact.

I just did an interview where for the 103rd time I was asked every possible question about my CV, background, skillset, experience, the companies I worked at, coding languages I knew, projects I’d worked on, etc., only to find that my salary expectations greatly exceeded their range. Have a nice day. While you can’t really start an interview by asking how much the job pays, you can, at the appropriate juncture, politely say you’re interested in the position but don’t want to waste anyone’s time: can you share with me what the salary range is for this position. (See below for more).

Your backstory

After some some intro pleasantries, every interview I’ve had begins with “Tell me a little bit about yourself”. Having answered this question a shit ton I’ve gotten pretty good at spinning my historical yarn. Especially as my background is a long and winding road that isn’t easily described. It took me ages to be able to deliver a relatively entertaining nutshell that sounded full, experienced, and diverse without rambling on and on.

The more concise you can be about your experience and history, the more together you’ll sound. Focus on the relevant points, don’t go all the way back to High School, don’t hem and haw, don’t search, and be sure to include any juicy stuff that might ping a few ears. It’s also not just the content: they want to hear you talk, gauge your confidence, see if you stall, balk, stumble, how you think on your feet, and how you talk about and present yourself. Short and sweet is better than long and sour. Be smooth like Billy D. Williams.

Include some relevant left-field stuff In a few interviews I’ve been asked “What do you do for fun” or “What do you do outside of coding?” Once I was actually asked what the weirdest thing I’ve done is. A lot of employers like to know they’re hiring actual people, not just robots. And a developer with hobbies and a rounded personality is more likely to be cool and have a healthy work-life balance, which can translate into better work, more productivity, and less burnout. Always prepare to talk briefly about things you do outside of work so you can show you’re a human who does (semi) normal things.

Be positive This one can be tough. After sitting through piles of interviews, and having had enough dev jobs to crush all hope and joy, maintaining a positive attitude in an interview is pretty crucial. Nothing turns off a prospective employer than (overly) sarcastic cynicism or outright negativity. A healthy dose of sharp developer humour is always good for ice-breaking and bridge building, but be careful to not go overboard. Everyone wants to hire and work with someone who’s (mostly) positive. This goes too for what for lack of a better word I’ll call jadedness. Doing ANOTHER interview for ANOTHER random company that makes ANOTHER random app or product where you’ll have to take instruction and input from ANOTHER slew of low-experience designers or marketing folks who think they invented the internet isn’t exactly the stuff dreams are made of. But you can’t show this total disdain to someone who’s absolutely JACKED about the company they are hiring for: i.e. the hiring manager.

First off, as I mention below, do your best to only apply to positions and companies that actually interest you. This’ll help give you a positive edge right away. Then, before your interview, listen to some of your favourite tunes, play some bass, do a little workout, or whatever gives you energy. That’ll give you a bit of a positive boost so you can get through the drudgery of talking about your life story AGAIN!

Be confident in your strengths; don’t apologize for your weaknesses For years I would pray no one asked about my javascript experience. Well, get ready for EVERY interview to ask about your goddamn Javascript experience. After a pile of interviews where I’d make a face and say “Ahhhhh, well, I’d say my JS is intermediate” or “I’d like it to be stronger” or “It’s on my bucket list”, I finally started saying not what level I’m at, but what areas of the absolutely IMMENSE world of Javascript I have experience with and interest in.

For example, I got started with JS through animation and third party libraries. I love making things move and started learning about DOM manipulation having to find and animate elements. From there I got into fetch() and AJAX and rendering data from APIs, todo lists, components, frontend frameworks, arrays, etc., etc. So now I focus on answering Javascript ability questions through what I know, instead of what I don’t.

It doesn’t always work however, and often you get pinned down either with a coding challenge or a question about something you just don’t know. But it shows confidence and presents better to be positive and highlight areas you have experience with, over sulking and wishing you were better than you are.

Self taught isn’t just ok. It’s the norm. “Yes, both Google and Facebook, as well as most other successful companies do hire self-taught people with no degrees. What they care the most is hiring exceptional people so you need to convince them that you are one.”

More and more developers are self-taught these days. With the enormity of internet resources available to learn coding, and the increase in people wanting to switch jobs or do something different after going to University, the market is increasingly filling with people who are self-taught. Big companies have opened their hiring mandates to include self-taught devs, and this has given confidence to a generation of coders.

What’s more, is that the reality of coding lies in practice and self-teaching. And every job, regardless of your background, requires you to learn new things. The ability to learn by yourself, find answers on your own, and learn by exploring a variety of resources is a huge bonus when applying for jobs. It can also give you confidence when choosing what to apply for because you’ll be bold enough to feel like you can learn whatever new things a job post asks for that aren’t in your immediate toolbox.

So far being self taught has never held me back. If anything more places have been impressed that I switched from a career in music to being a frontend developer without going to school.

Don’t be afraid to say you don’t know One of the surest signs of experience and confidence is to admit you don’t know something. This insane world of code is so gargantuan that no one can possibly know everything. Socrates famously said “I am the wisest man alive, for I know one thing, and that is that I know nothing.” And while it’s obnoxious to quote Socrates, admitting you don’t know something shows you’re humble, willing to learn, and able to show an employer you can ask for help when you need it — which is a huge plus working on a dev team.

Adding honest, positive responses like “I’d look that up”, or “That’s something I’d look into further”, also highlights that every developer relies very VERY heavily (almost entirely) on the internet to help them make pretty much anything. Stack Overflow, CSS Tricks, W3, MDN, straight up googling — these skills are essential to being a real world developer, as is the ability to self-learn and be resourceful.

Highlight your openness and ability to learn The development world is constantly changing. You can barely keep up when you try. But the act of constantly learning and being open to new resources and technologies is a major attraction for employers. A candidate who is open to learning, learns well on their own, and practices new skills, can often be more attractive than one that has hard experience in an area but isn’t interested in new things. Half of any job is learning their stack, systems, and processes, so highlighting your ability and willingness to learn is always a plus to interviewers.

Stay current In nearly every interview I’ve had, I get asked “How do you stay current on trends and developments?”. As mentioned above, things move fast. Every summer I take 2–3 weeks off and come back feeling like I don’t know how to do anything anymore. But day to day it’s important to have a few ongoing resources that you don’t have to think about to help you stay up on the latest trends in the space.

CSS Tricks, TL;DR, Medium, DEV, etc., etc., there are hundreds, maybe thousands of resources you can sign up for that will land in your inbox (and mostly annoy you, and mostly get deleted) and occasionally give you some great ideas.

Read the Job Description I’ve done a number of interviews where I got a callback from a classic Linkedin “Easy apply”. These would be ones I had a fast flip through and thought whatever, let’s see. Then promptly forgot about. When those companies came back and took my application seriously, I had to scramble to review what the hell I’d applied to. When the interviewer starts with the “What interests you about this role” question, it’s pretty hard to fake if you can’t remember what the job title is.

Look at their website + product To wit: if you actually care about a job, it helps a lot if you spend a few minutes looking at the company’s website and/or social media. Get a sense for what the product is. Look at the website. Check out UI and design elements — this will tell you a lot about whether a company is modern and cool, or old and dated. Look for performance, load speed, errors, glitches, and a point I’ve impressed more than few interviewers with: knowing what technologies they use for a website or application. While using devtools to sift through a site’s HTML, CSS, JS, sources, errors, etc, is no big deal for developers, it shows a prospective employer you took the time to go look at what they’re using. And it helps even more if you’ve used that tech before. It can also help you weed out potential lemons by identifying sites with bad design and technologies you aren’t interested in using.

Don’t assume a place will hire you because you tick “some” of their boxes I’ve wasted a lot of hours sending applications to job posts that I only partially fit. Being a confident self-learner, I feel that within a range, most development skills are learnable. Especially if you have some previous experience with a similar technology or platform. Say you’ve used Wordpress. Well, Webflow isn’t that different. But applying to a Webflow developer job is a bit of a different story. And you need to consider the scope and number of things that the job is requesting. Learning one or two things you aren’t familiar with is different than expecting an employer to hire you to develop a completely new set of skills.

Don’t assume a place won’t hire you because you don’t tick “all” of their boxes A lot of job posts will actually encourage applicants to apply even if they don’t have all the skills in the description. While I’ve found this to be the exception to the rule, it never hurts (unless you’re just not a fit at all). I generally apply to jobs where at a quick glance I recognize and like about 60% of what they list for tech and skills. If you’re a good self learner and like the company or product, it’s worth firing off a few applications even if you don’t fully fit their bill. I’ve gotten jobs where the company didn’t care that I didn’t know their stack — I’d spend the first month or two getting up to speed then dive into projects. Most companies will also assume it takes 3 months for a new dev to learn their processes, so the ability to learn and be flexible is almost always a better quality than having every skill a job post lists.

Apply to jobs you would actually want Sounds like a no brainer. But I’ve wasted a lot of hours sending applications to job posts that I’m only partially interested in. Why? Of course it’s easy to say “only apply to things you’re interested in”. But at various points in my life, I needed job. Type and style didn’t matter so much pay and pay. But on balance, it makes WAY more sense to seek out jobs that seem cool. It’s hard to fake interest in an interview. And if you take a job only for the money, you won’t last long.

As mentioned above, I started a habit of trying to apply to jobs where I like 60+% of what they’re about — from product to tech — and started looking much more intently at companies and roles for products and services that I had interest in. End of the day if you’re going to work at a place, you’re going to have to embody whatever their thing is for as long as you work there. Take it from me: being full of contempt for a company’s product (people, processes, tech stack, etc.) will land you in a surprise dismissal meeting faster than you can say EI.

What’s the day to day? You don’t know shit about a job until you know what your day to day is. And the trick is you can’t know shit about the day to day until you’ve been there for a couple months. And no one will tell you what the real day to day is anyway. Ever. It’s all rainbows and sunbeams. So you have to subtly dig to find out what you’d actually be doing, with whom, and under what circumstances. Are you making maintenance updates to a single website as a sole developer? Are you part of a totally dysfunctional team, with a workflow that leaves you holding the sausage after three other departments have signed off on it? Best find out before going any further.

Is there a (legit) HR department? No joke in one job I had, the company started what turned out to be a massive downsizing. In the process, they fired the HR person and replaced them with, you guessed it, the CEO’s romantic partner (15–20 years his junior) who you guessed it, had no experience with HR, and you guessed it, made for an INSANE conflict of interest. Can you imagine having a complaint about the CEO? Or the new HR person themselves — who also happened to be the product manager (who was annoying and hopelessly overreaching with their skillset)? I also I worked at a company that did have an HR department, but they were still such slimy operators they might as well not have.

Try to find out discreetly if a company has a proper HR presence that is relatively unbiased and disconnected from conflicts of interest. Companies worth their salt will have proper pipelines for all types of work related processes and communications, and will work hard to advocate for and support employees. Things like conflict, combative work environment, differences between job description and actual day to day expectations, and manager relationships should all be things that get dealt with in a professional, step-by-step manner. If complaints or difficulties are brought up, they should be tracked, addressed, and supported in an effort to actually make the issue better. Proper channels should be used, meetings should be set up to discuss strategies, and follow ups should be booked to assess progress. If you go from no problem to a couple problems to fired with no explanation, something shady is afoot.

Live coding challenges Tests of skill are common for tech jobs. However the trend lately (or the trend in my interviews) has been more toward take-home tests, or projects that get a few days for completion. The idea that a developer should be tested, in the moment, in front of a panel of people, is inhumane and in truth, not effective. I started preparing for these types of situations by saying a) I don’t do these, b) I don’t perform well in this kind of environment, or c) I’d be happy to do some form of take home but am not comfortable doing a live challenge.

I’ve read that live coding tests don’t give you a accurate sense of a person’s skill, nor their breadth of ability, and they completely ignore so many traits that make a great person, developer, and employee. Especially as you almost never have a situation in a real job where you’re timed and other people are staring at you while you try to code a solution to a ridiculous and difficult Javascript math problem you’ve never seen that has no application to anything other than returning a value of null or undefined.

Take home projects/challenges After live challenges, the take home assignment is the most common form of developer assessment — and in my experience it’s becoming more of a standard for frontend development and designer type positions.

Update: Before doing any interview challenge or take home project, assume you won’t get the job. Why? In the majority of challenges I’ve done, employers just don’t respond. Or you get the polite let down with zero feedback. I’ve built what I thought were very cool and original projects, unique layouts, modern UIs, cool animations, working prototypes with live API data, interactivity, and for most of the ones I’ve done, I’ve gone above-and-beyond thinking “this will impress them”. In the one instance where the employer liked what I did (which was also the only one where they compensated me), they balked at my salary expectation (which was fair market range for my experience) and bid me adieu. Building projects is always good for your portfolio, but it’s hard when you do one after another and don’t land a job. Which prompts me to suggest you only do an audition project or challenge on the assumption that you’ll be building something for your own learning and portfolio. Or ask for compensation before you agree to do it.

Asking for compensation might be a tall ask when you’re just getting started or really need a job. But after you do enough of these for nothing, you’ll understand why. It’s a colossal time investment, I’ve had more rejections than job offers as a result, and you rarely if EVER get any useful or honest feedback if they don’t choose you.

As an example: I just completed a project as part of a second round of interviews. I had to build out a Figma landing page mockup with Next.js using Chakra UI (which I’ve barely heard of), in addition to building two responsive HTML email templates (which I’d only ever done one other time). They gave me 4 days.

Having worked as a Vue dev for the better part of 3 years, I had to go back and relearn the small amount of Next/React I’d once explored, and given time, also had to decide what to do about the Chakra UI piece. I’d never used it and would’ve spent at least 2 of the 4 days learning it. Oh, and if I didn’t mention, I have a toddler and an infant (read: zero time for a 4 day job audition).

So I decided to use Bootstrap instead, my go-to CSS framework (and arguably the most popular and well used), to save time and still show I could deliver a killer reproduction of their mockup. Which I did. I built it out in clean organized components, with a dark mode feature, used a little state and conditional logic/styling, simple fade animation, and of course it was responsive and deployed on Netlify. I had a link to my github repo, as I did for the HTML emails, which I built, tested, sent — and in my estimation — nailed. But oh no.

After not responding for close to 2 weeks, the hiring manager emailed me back only after I reached out for a follow up. He first said “Oh, I’m sorry you didn’t receive my email”. Un huh. Then he gives me the most stock HR let down of all time: “While your skills and background are impressive, we won’t be moving forward with your application at this time”. Uh huh.

Employers won’t give you feedback, won’t tell you why you didn’t get it, won’t tell you where your code fell short, and won’t offer any other helpful stuff. Which is why doing these project auditions is such a crap shoot. In the end, it never hurts to ask for compensation. If they say no, they don’t value you already. Or they might not have the cash to do it, which tells you they might not have the cash to pay you well. And if they say yes, then it might actually be worth your while.

Exit strategy Like Afghanistan, you have to consider your exit strategy. Interviews are brutal (I mean, relatively speaking). And while you have to sit through a lot of them to get comfortable and confident, you have to be able to know when to pull the plug. In the end, interviewing is VERY time consuming. For all parties. While it’s easy to sit here and write that you should find a way to ditch out of an interview if it isn’t looking like something you want — that’s exactly what you should do. It’s a waste of time to talk about yourself for 20 minutes only to find out they offer one week of vacation, make you work with video on all day, don’t have benefits, or are ready to offer a whopping $35k for salary.

Salary Expectations Here is the kicker. The question of questions.

First of all, hiring managers rarely (if ever) tell you what a job pays. They ask you how much you want. Right off the bat this puts you in a pickle. You’re the one that has to answer. And you have no clue what their range may be unless the posting says “senior” or “lead”, in which case you’re still guessing. If your number is too high, they sigh and say that’s beyond their limit (or if it’s in a form-style application and you’re too high, they just won’t respond altogether). If it’s too little, they either assume you’re too inexperienced to ask for more, or move you forward quickly so they can get as much as they can out of you for cheap.

A range is good but a number is better For a period of interviews, I gave HR people a +/- 10k salary range for what I wanted. While it sounds good on paper because you can have a high end that would be great if you got it, and a low end that might attract a wider range of offers, it’s a trick. If you’re in the ballpark, companies will always offer the lowest number you give them. It’s in their interest to pay as little as they can for the best deal. That why it’s better to have a single number closer to what you would actually be happy with.

Give them a target After reading some articles about this, I saw a trend toward asking for a single target salary number instead of a range. This number doesn’t have to be firm or unchanging. It can be a negotiable “area” you want to be at, or one you want to get to in the near future. You can research what devs of your experience or level are making and use that as a start.

When you give this target in an interview, you’re starting and finishing at a number you are happy with. And it puts the onus on the employer to make you an offer that is at least competitive with your target. It also weeds out the ones that aren’t in that ballpark and at least you can both save yourself time.

Ask at the start In nearly 100% of my interviews, HR people ask the salary question only at the end of the interview. And sometimes they don’t ask until a second or third round. Why is this a problem?

After talking about yourself for 20 or 30 minutes (or through multiple rounds) recounting every job you’ve had and coding language you know, it’s really, really, really not fun to learn that their ideal salary range is FAR less than you want.

Companies always have a salary range for a position. Always. They like to say that “for the right candidate we can be flexible”, but that’s really code for “we tap out at $78,000”.

For a number of interviews I tried deflecting the question back onto the interviewer. If they asked what my salary expectations were, I’d say, “well if you don’t mind could you share what the position pays”, or “what range is your company working within”. It only ever worked twice but I like how it puts them back in the hot seat for a second. And occasionally, they’ll actually tell you.

Other compensation Benefits, vacation, work life balance, paid sick days, flex time, personal development stipends: there are many elements to a good compensation package. I like to tell interviewers I value a lot of elements when it comes to compensation, not just money. In the end you’ll be working at this place every day, likely 9–5. So if you don’t like it, or at least like it enough, you’ll be wasting your time (and theirs).

But like the salary question, recruiters rarely outline what’s actually in a compensation package until there’s an offer — i.e. at the end of the interview process, which could be weeks. What this means is you could do 4 rounds, with 4 different interviewers, complete a challenge, get everything right, and only THEN have them tell you they don’t offer benefits. Or you only get 2 weeks vacation. Or have to work late a lot.

In the first interview ask what the standard compensation package looks like. While interviewers always sweat when you ask what the pay is, they will more happily talk about vacation, hours, benefits, etc. It’s another question that can save you a lot of time.

2 of 3 A developer friend of mine told me a system that one of his developer friends uses to gauge the value of a position or job offer: it has to have 2 out of 3 of the following:

Code, culture, money.

The code part is about the product or tech stack being cool. Maybe it’s interesting, new, flexible, you’ll learn a lot, the team is great, it’s cutting edge, etc.

The culture part is self explanatory: good people, good environment, good work-life balance.

The money part is even more self explanatory: good pay and compensation.

Interview THEM You’re not the only one being interviewed.

One thing no one EVER tells you: you are interviewing any potential company as much as they are interviewing you.

The job market fluctuates. And like anything there are times where jobs are scarce, and times where workforce is scarce — which means it’s easier or harder to get a job. But hiring a person is a two way street. To get good talent, you have to not only pay well, you need a complete package of culture and lifestyle perks to pitch that will not just attract good employees, but KEEP them long term.

Traditionally (and in fact always), unless you’re dealing with 6+ figure headhunting type positions, interview power dynamics favour the company. Interviews proceed with the candidate sitting through myriad personal and professional questions so the company can see if you fit them. While they’ll give you 30 seconds to a minute at the end of the interview to see “if you have any questions for us”, generally interviews are not structured to see if the candidate feels like the company is a fit for them.

While I have never tried this, it would be great (and also legitimate) to start an interview by saying “Tell me why I would want to work here?” Barring that, it’s important to have questions ready that reveal not only compensation, but what working at a company is actually like: the people, what their idea of teamwork is, if they value autonomy or are micromanagey, what a typical project workflow is like, if it’s collaborative or waterfall style top-down management, if they are open to change and improvement, if they value opinions and ideas, if there is the ability to learn and grow, etc.

Conclusion

Hopefully a few of these insights help you in your quest for a better, shorter, more confident, and easier interview. After all the interviews I’ve done, my background schtick and stock answers have gotten relatively natural and I can use my basic patter as a starting point for more extensive discussions. The real trick though is to learn to save yourself time, ask the right questions, and pick the winners faster. Interviews aren’t generally (or ever) fun and it helps having a strategy and some idea of what to expect.

Subscribe to get new stories about coding, frontend development, design and more: https://medium.com/subscribe/@andrewmasonmedia