Tips for Developers Interviewing for a Job from a Recent Interviewee
After 10 years of working for the same tech company I decided to move on, the decision was a bit abrupt leaving me initially unprepared especially since so much has changed in the decade (as an interviewee, I was still interviewing but only a portion of the whole process). I spoke to 4 companies in the process and proceeded with formal interviews all the way to the end with 3 of them.
Since there’s already a ton of material out there for generic interviewing tips, I wanted to document some tips that are specific to interviewing for a development job and hopefully help all those devs seeking out there.
Interview the Interviewer
I know this one sounds obvious — we as developers are in high demand thus having the upper-hand in shopping around and such, but in details what is important is asking the brutally honest questions. This is your opportunity to get a glimpse into a company where you could potentially spend years at, do it right.
Are They Happy?
Some simple questions I like to start with are, “are they happy?” or “how long do they see themselves at the company?”. Usually this won’t uncover much but it gets the ball rolling then start digging:
- “What is it about the company that stresses you out?”,
- “What is a recent situation, that has left you unhappy?”,
- “What is the last company decision that you disagree with?”
- “Do you feel fairly compensate/recognized, what’s a feature that you’re proud of that nobody cares?”, or
- “What’s the last technical decision that you made that got turned down and why?”.
Really dig for the cultural, leadership, organization and/or team problems that may not be immediately obvious.
Do They Have the Same Problems You’re Trying to Avoid
It happened to many of my friends and honestly a bit in my situation too. Many of the problems I had with my previous company exists here today — same dish different table, but (big but) the difference is understanding why the problem exists for an organization and how have they attempted to solve those problems.
I look at it this way, my current company is a startup and these problems are relatively new to this organization (regardless if the people solved it at a different org before). We are a new composite of people and we have yet to tackle these problems. We are just formulating strategies on this rather than constantly failing and not addressing the actual problem. Another key difference is that these problems stem from a different place. This means that we have a potential of solving these problems rather than being stuck in a loop.
A good example came up today as I was interviewing a candidate. The candidate described the problems with their current company, forcing them to want to leave. It sounds exactly like what I’m dealing with, but the problem with their org stems from management’s stubborn dictatorship while ours stemmed from the many changes of hands on certain development. I believe in our leadership to help resolve our problems — for the candidate the leadership is the problem.
Present that to the interviewer and ask if these issues exist and how have they attempted to solve these problems.
Ask to See Some Code, Documentation, PR or Anything
This one is sometimes tough, but push for it. Oftentimes during interviews they’ll try to sell you that they’re doing amazing work there. Ask to see anything they’re working on, see if it’s actually as amazing under the hood.
Getting a live example of how they do things helps put words into perspective. It may not always help with the decision making process but it could help with expectations if you were to choose that company and start working there. The second choice company I wanted to work for actually had an amazing code base with a very modern approach to things, it definitely made it hard for me to turn down that opportunity.
Prepare to Spend a lot of Time
I feel stupid mentioning this one as most who has interviewed in the last few years probably knew this, but I did not! Most tech companies nowadays go through many rounds. I don’t know what the average is but I went through 5-8 rounds between the 3~4 companies.
These rounds vary from a minimum of 1 hour to a full work day with the dev team. You can imagine that this adds up when you’re speaking to multiple companies at the same time. I calculated that I spent somewhere between 35~40 hours. I was definitely overwhelmed and exhausted, especially because this was a month after our second child was born. Needless to say, I did not budget in a healthy amount of time and ended up burning myself out for a month.
Carve out time in your day for this, take the day after multiple interviews off to recover and just buffer time before and after your interviews to prepare and mentally debrief.
Exercise Your Brain for the Technical Interview
It’s hard to prepare for specific technical interviews because they don’t give hints as to what the tests will look like. I’ve received a variety of tests ranging from actually building something in React, writing my own library to logical puzzles.
Prior to leaving my last company I was working on some fun tasks but they’re heavily focused on CSS, design, and UI. I didn’t get to solve problems logically in code and even worse was I was 3 years out of practice in terms of meaningfully coding in JS and all these jobs are for JS developers. On top of everything, problems and tasks were a bit repetitive and my brain got really really mushy.
Do Puzzles, Play Games
I was really nervous knowing that I had to do multiple technical interviews. To re-engage my brain for this I started doing puzzles and code practices. Puzzles like sudoku and crosswords are perfect for casual exercises. I personally prefer sudoku since I was once addicted to them. There are plenty of other puzzles you can do that’s free online. Pick something that you can casually do when you’re on the toilet or just watching TV. Another one I played was 2048, but I’m mixed on this one as being a useful exercise.
Coding Practices
The other exercise I started doing a lot was coding puzzles. These are puzzles where you’re given a defined “problem” where you have to code a solution to and test those solutions. They’re honestly a ton of fun and I used to do them just for fun anyways. These practices really help me ramp up on my JS practice quickly. Honestly, a few of the technical interviews aren’t all that different from doing these puzzles.
The site I use is Codewars, they have a good set of exercises ranging from pretty easy to “I’m going to lose sleep over this”. There are definitely other ones such as LeetCode, HackerRank, and edabit (no need to sign up, just get started).
A good interviewer probably isn’t looking for you to solve the challenge but rather how you think logically and how that turns into code. These practices will help you with just that.
That’s It, Now Go Shine
I understand that some are moving on simply because they want more money or they just want a change for the sake of change, but I am a strong believer that we are all capable of amazing things. If we haven’t achieved that in our current workplace, we’re probably at the wrong place. Take this opportunity and take your time to discover different workplaces and understand what environment could drive you.
