What I Learned from Developer Interviews
Once I felt I was ready to shift from teaching to become a front end developer, I went out on a few interviews and really loved the experience.
I made sure to use each one as a learning experience that will make me a better developer and interviewee. Hopefully this can be useful to you, whether you’re coming from another industry, or you’re an industry veteran looking to move to the next opportunity.
It’s more than programming experience
Yeah, this one definitely reads as a no brainer, but it’s important to understand exactly how they’re different than interviewing for other jobs.
If you’re changing career paths like I was, you might already have plenty of experience interviewing. This experience is still incredibly valuable, so don’t think you’re starting from zero. You’ve got a definite leg up.
Soft skills are just as important in programming as any other job. The people who are interviewing you are the people you’ll probably be working with. They don’t want to work with a jerk. They don’t want to work with someone who can’t communicate or doesn’t seem to take feedback well.
I don’t know if it’s true, but people seem to generally think that a lot of programmers lack soft skills, so if you’ve got them you’re in good shape. If you don’t the good news is that soft skills aren’t genetic. It’s something you can read from books like the classic How to Win Friends and Influence People.
Get your story straight
The thing is, interviews often start on the subject of You.
They want to know about the path you took to wind up in that interview chair. If you’ve got that CS degree, what got you into computer science? If you’re changing careers, what made you do so?
Practice your story, as it’s usually one of the first things they’ll ask, just to get the interview going and warmed up. You know what they say about first impressions.
Know your resume
Having your resume in front of you for reference is an absolute must. Being able to reference the details of projects or dates is super helpful when it’s time to talk specifics.
They’re going to ask you about your work experience, your education, and your projects. Don’t just have them on your resume, but practice talking about every single thing you put on that piece of paper. They won’t hit everything, but you’ll often be surprised by which things on your resume they decide to talk about.
If it’s a past job, be prepared to talk it up and explain how it was a great experience and helped you develop a certain skill. Steer clear of complaining about past employers or the job in general. If there were issues, how did you solve them? For me, I worked at a school that had an overwhelming amount of data, so in my free time I made an app to solve that problem.
For projects you need to be able to succinctly describe the challenge or problem, your solutions and results. Demos are key here. No matter what the project is, you’ve gotta have some kind of demo up that they can see or interact with. Screenshots are okay. Videos are better. Live sites/programs are best.
I’ve tossed all my projects up on Netlify, as it’s free and takes about 2 minutes to get them live. Now they’re all hosted at
https://projectname.atrost.com which also looks good.
Quick tip: If you don’t have something positive to say about an item on your resume, get it off your resume. You don’t get extra points for resume length.
It’s as much about you as it is about them
While you’re in there to show them the value that you can bring to the table, you need to get the sense if it’s a company that you’d like to work for, and if it’ll be a healthy environment for you. Try to get a feel for the culture, and even come out and ask them what the culture is like.
If they immediately talk about how hard they work, this might be a sign that you’ll be expected to do overtime or work weekends to get in under a deadline.
If they have trouble describing the culture, that might be a sign that they’re new and haven’t put that much thought into it yet. Depending on who you are, you might see this as a red flag or an opportunity to help shape something.
Whatever they say, you need to remember that you also have power in the hiring process. Many companies are trying to hire developers right now and if they think you’re a fit, they probably want you as much as you want them. This means that the same way they would say “Thanks but no thanks” to a toxic potential hire, you need to say “Thanks but no thanks” if you don’t think an offer is going to be good for you.
Research the company
Within reason, research the company and think about problems they might be facing. Think about ways they’re different from their competition, and if they’re behind, brainstorm ideas that might make them the better company.
As you research, you’ll find you don’t fully know how the company works, or where they’re headed or how they make money. Try your best to answer those questions on your own, but as you dig deeper you’ll get to questions only people inside the company can answer, and those start to become good interview questions for you to bring up.
If their service is public, where you can sign up for an account and use it, absolutely do so. Poke around their site, use something like Wappalyzer - Identify technologies on websites to see if you can figure out some of the different frameworks and libraries they’re using. These can make for good conversation points, too.
The person you talk with on the phone to set up the interview might give you a certain format that the interview will have. For example, “We’ll ask you some technical questions about React and then have you do 1 white boarding problem.”
If that’s all you prepare for, you’re setting yourself up for disappointment.
Give extra attention to the things they tell you are coming, but don’t get caught like a deer in headlights when they go off-script. I had to white board in an interview that I was told would include no white boarding. It happens, and you roll with it.
Take feedback well
After working through a problem, one of my interviewers told me that I lacked an understanding of certain data structures. Honestly, this was some of the best feedback I’ve gotten on my path to becoming a developer.
He poked at my knowledge, found a weak point and kindly let me know about it. I genuinely thanked him for the feedback and made a note to turn that weakness into a strength.
You need to be okay with not knowing things. Not just when you’re starting out, but from now on and forever.
Turn weaknesses into strengths
There was a point in one of my interviews when I felt the gears in my brain come grinding to a halt. I stuttered, stammered, and said “um” more than I said real words.
An interviewer had asked me to describe React’s Virtual DOM. I learned about the virtual DOM about 10 months ago. My brain stored it in a box, put that box in the back, and then put lots of junk on top of that box. It took a minute to dig it out and the search process wasn’t pretty to watch.
So I had identified another gap in my knowledge. What an opportunity.
I went home and dug into the material about the Virtual DOM. I developed my own understanding of it, wrote about it and made a tutorial video and blog post teaching others about React’s Virtual DOM.
I specifically messaged the interviewer who asked that question on LinkedIn, thanked him again for his time and specifically that question. I let him know that it inspired me to go get a deeper understanding of the virtual DOM and shared the video with him.
I know the interview process is stressful and a bit insane, but it becomes a lot less stressful if you greet it all with a smile. Mistakes and errors will happen, you’ll get stumped, you’ll feel like you did a bad job. Always smile, thank them for their time, and be grateful that you got practice interviewing.
At the end of the day, you’re better because you took that interview. You’ll be better in the next one, because you’ll learn from your mistakes.