What has and hasn't changed in tech job hunting over the last 5 years

At the beginning of April 2021, I suddenly and unexpectedly lost my job. A job I had held for almost five years, and had become a normal staple of my life. It was a shock to the system, mentally and physically. I’d never been let go before and was completely out of my element on how to process and understand what was happening. COVID burnout had fully taken ahold of me, and though I felt like I was working hard and trying my best, it clearly didn’t translate that way for my superiors. More importantly, despite communicating as best I could about my current mental status, it was a harsh reminder that a company can cut anyone they deem unfit for the job at any time, even after five loyal years.

After the initial shock had passed, I realized how much I actually needed to take a break, and have since embraced my new freedom to the fullest. It also meant that I had to find a new job in a semi-urgent matter, something that I haven’t had to do in a long time. Some parts of the tech job hunt are depressingly the same as they were before, but I also learned some new things along the way. I had about twenty interviews for mid-senior level JavaScript positions, I hope this can be helpful for anyone who is currently looking!

Whiteboarding, CS algorithms and take-home challenges

Just about all of my interviews had a live coding exercise of some sort, sometimes multiple. By “live coding” I mean either by a timed online challenge (hackerrank/coderbyte) or with an interviewer on a call as a pair programmer. This is absolutely something that gets better with practice, both in doing practice problems online and just by sheer number of interviews. A couple key takeaways from coding assessments:

• Grinding Leetcode problems will help. I know, it sucks and not every interview is for Google. However, as someone who started this process with little to no CS fundamentals, it will help. Even if you can force yourself to just open Leetcode once a day, you will start to absorb some knowledge, and if anything start to understand what kinds of problems you might run into. During a session of the final round with Citadel, I was asked to implement a linked-list and some operations on it (with interviewer on the call). I ACED that part of the interview. At the end of the day I didn’t get the job, but what mattered was that my studying payed off, and in the interview marathon that is what counts. It’s a huge boost of confidence to nail a problem you couldn’t do two months ago.
• Use YouTube to quickly understand CS concepts at a high level. The amount of great resources on YouTube for CS is incredible, and you can easily find a five minute video on just about anything. If you’re having trouble grinding problems on graph traversal or binary search, just watch some videos. At least you will have a base of what the concept is used for and the basics of how to create it.
• Take-home tests are more common now. It seems like some companies are warming up to the idea that whiteboarding doesn’t give an accurate picture of an engineer’s true talent, so I also saw a good amount of take home tests. For take home tests there are just a couple guidelines: comment on EVERYTHING, focus on clear and concise code, and add some notes for your reviewers after you’re finished. This step is far from the end; I noticed many interview processes would include a whiteboarding step after the take-home. However, I passed 100% of my take-home tests, and I think my over-commenting and communication played a big part.
• Don’t forget the basics. In a late-stage round with Flexport, I was asked to make a simple timer in React/JavaScript that would count up the number of milliseconds you have hovered over an element. I was increasingly confident in my ability to solve React challenges, however this relied mostly on native time functions with JavaScript, and some intricacies with setInterval(). Every single JS dev Googles the Date() object at least once while working with it, and I was the same. I struggled to get through grabbing the exact time relative to the last time we hovered, and how to remove a previously declared interval (now I know its clearInterval(interval)). Not only that, but there were some small details with how React.setState() works in regard to the event loop, and that tripped me up as well. I didn’t get the job, and I was really upset at myself for not performing better with native JS operations. Don’t forget to brush up on these.
• System design is also important. I had at least five instances of system design interviews, ranging from explaining past design choices, to theoretical design of a new product. Do you know how your past projects were deployed/hosted/compiled? Do you have an idea of how X and Y systems communicate with each other? What if you could start from scratch and re-do everything? It will be very helpful to prepare with some past projects and brush up on how common systems are implemented. For example: “We set up everything from our build and test pipeline, to how the app was deployed. We used X CI and deployed to Y servers, all brought together with Z”

Behavioral interviews

With each company, I had numerous behavioral interviews with various people amongst the organization. This included project managers, product managers, designers, engineering managers, engineers and CTOs. It’s easy to feel like these steps don’t matter as much as coding assessments, but they’re extremely important and (for me) take the most energy. Talking with five straight interviewers about career experience after doing a one-hour whiteboard can leave you completely exhausted. A couple key takeaways from behavioral interviews:

• It still helps to have prepared answers for “tell me about a time…” questions. It seems cheesy and outdated, but companies are still asking these kind of questions. If you have a good amount of experience under your belt you can usually come up with something for any question, but there were a couple questions that, looking back, I could have done better on. Some common ones I saw over the course of my search:

  • Tell me about a really bad bug or mistake you had to fix.
  • Tell me some detailed examples of working with other non-technical people in the company.
  • Tell me in detail about a project you worked on and how you designed it.
  • Tell me how you prioritize requests when you have multiple things on your plate.

  Details are very important and go a long way during these. For example: “This was a time when we had a request from the business to change X but we had been really wanting to refactor Y on our GraphQL server, and this is how we handled it and got everything done, blah blah”

• Asking good questions matter more than ever. Over the course of my search, it became very clear to me that companies are basing a lot of your general interest in the role/product on the questions you ask. There were a handful of instances where I had run out of questions to ask and the interviewer seemed surprised/disappointed. Take the time to write down a BUNCH of questions, more than you think they need. Go in depth about the design/structure of an application with engineers, ask about process and policies with project managers, and ask about team structure/task assignment with managers. It really helps.
• Every answer is important. This is extremely anxiety inducing, but I learned it the hard way. I was interviewing with Starburst, a remote company working on big data and how to help companies centralize all of their data. I was really interested in the job, and during the interview with the engineering manager, she asked me “What do you like to work on and what do you want to do in your next role?” I answered that I enjoy front-end work, and I also really enjoy working on infrastructure since I had a lot of experience from DRW. The call went well after that and I left feeling good. I got an email the next day saying they’re sorry, but they don’t feel like there’s a good role for me based on my interests. Looking back, I think I might have come across as not being interested in working on just front-end (which would have been perfectly fine). Sometimes a small mention of something like that will end your chances right there. At the same time I was being honest about what I like, so there’s a judgement call to be made there.
• Always convey excitement about the role/company. No matter the interviewer or the topic, always tie it back to why you’re excited about the role and how <ANSWERTOQUESTION> relates to this particular opportunity. For example: “…and that’s how I prevented an entire production outage, a lesson I will certainly bring to your team as a site reliability engineer”.

Navigating multiple offers and negotiation

For the first time in my life I received multiple offers. I was thrilled but also stressed out about it. I kind-of just winged the negotiation and it ended up working out pretty well. This well known guide helped a lot, and I would add a few things to it:

• Be super responsive. This should go without saying, but monitor your email like a hawk and respond right away if you can. Nothing says “not interested” more than taking forever to respond to an email.
• ALWAYS NEGOTIATE. Haseeb explains this well in his blog linked above, but it bears reiterating. In my case both offers were a bit below the salary range I shared, but once the company has given an offer you might as well go for it. My second choice company ended up offering a LOT more than their original numbers, as well as taking on a signing bonus and paid relocation. While the company I ended up ultimately going with wouldn’t budge too much (they were essentially at the max of their allotted salary bands), I tried anyway. As long as you stay positive and leave your options open, everyone will entertain some form of negotiating.
• Take equity with a grain of salt. It’s common to get some form of equity included in the offer, but unless the company is already publicly traded, its usually not worth anything at the current moment. One company told me “Don’t worry, if we 10x, your options will be worth five million dollars!!” This is a bunch of crap and never let it sway your decision. The important thing to think about is whether or not the equity will be worth anything at all in the future. Do you believe in the company/product? Are they growing? Does their money-making make sense?
• It’s never in the bag until the offer is in hand. There’s nothing more heartbreaking than getting past a five-hour final round just to get rejected. It’s hard, but it’s best to resist getting your hopes up and getting comfortable with the idea of having that job. It’s just another one!

You can do it!

It’s a lot, and it takes time, but the whole thing is one big learning process. I hope that some of these things can help you navigate through a flawed and frustrating system that we have no choice but to abide by.