Musings from my desk

Blog Homepage

Job Search Retrospective

2023-08-07 10:05:40 -0500 CDT

TLDR

Job searching still sucks, so buckle up. I recently accepted an offer and I wanted to share some highlights from my recent job search.

Recap

Not too long ago, I wrote about my experience in my first month of job searching after a layoff. I am very lucky that my search didn’t extend much beyond a month!

Hot tip: if you’re at any phase of a job search (including ideation/pre-application), watch this first. It includes really useful information to think about before starting a job search which can help you maximize your offers. I wish I had watched it a month ago!

Stats

The numbers everyone has been waiting for: statistics about my job search!

  1. Total time from layoff to accepted job offer: 42 days (exactly 6 weeks 😮)
  2. Total applications submitted: 42 (weird coincidence 🧐)
  3. Total response rate1: 47.6%
  4. Total number of offers: 1

Here’s my Sankey diagram of my job application experience:

Job search retrospective Applications → No reply yet: 22 Applications → Rejected: 12 Applications → Phone screen: 8 Phone screen → First round: 6 First round → Second round: 2 Phone screen → No reply yet: 1 Phone screen → I withdrew: 1 First round → I withdrew: 1 First round → No reply yet: 1 First round → Position closed: 1 First round → Rejected: 1 Second round → Third round: 1 Second round → No reply yet: 1 Third round → Fourth round: 1 Fourth round → Offered + Accepted: 1 Rejected: 13 No reply yet: 25 Applications: 42 Phone screen: 8 First round: 6 I withdrew: 2 Second round: 2 Position closed: 1 Third round: 1 Fourth round: 1 Offered + Accepted: 1 Made with SankeyMATIC Rejected: 13 No reply yet: 25 Applications: 42 Phone screen: 8 First round: 6 I withdrew: 2 Second round: 2 Position closed: 1 Third round: 1 Fourth round: 1 Offered + Accepted: 1

1Response rate includes: rejections and phone screens that resulted from an application. Response rate excludes: phone screens with unaffiliated recruiters who said they would submit my application for a position and then ghosted me.

What my interviews were like

I didn’t have a bunch of interviews beyond phone screens, but most of my interviews were technical in nature. They fell into three broad categories:

1. Live coding

I had 3 interviews that involved live coding. One was a purely algorithmic question, whereas the other two were in the style of pair programming on a “real” task. Here’s a summary of what I was asked:

  1. Write a function to shuffle an array. The solution was very simple compared to the types of questions I expected, but it got interesting when the interviewer started asking about how to test in a deterministic way for probabilistic outcomes, e.g. by measuing the entropy of the system and the probability of obtaining certain results. The probability discussion is far outside my expertise but made for an interesting discussion.
  2. Given a file that represents three routes on a REST API, write tests and refactor to fix bugs and make the code more maintainable. The primary task here was simple, but I made two fundamental mistakes:
    1. I didn’t read the instructions before I dove in (I took the interviewer’s preface at face value, which burned a couple minutes).
    2. I got stuck going down rabbit holes of debugging instead of focusing on the high level objective. I felt OK about what I presented but I didn’t really “finish” the assignment by the end which probably counted against me.
  3. Given an HTTP service that serves 3 different entities (parent → children → grandchildren relationship), write a program that lists all grandchildren given a specific parent ID. The core program was quite simple and I spent way too much time talking about irrelevant factors during this interview. It turned out that after I completed the main program, there were follow-up questions that were more interesting and more nuanced. My biggest take-aways were:
    1. Take a moment to think about a production-grade approach to the problem before you dive in. I wrote a loose collection of functions that accomplished the goal but lacked coherent structure, and they rejected me a couple days later. I wish I would have written it like I would in my actual job: wrap relevant functionality in a class, add abstractions to handle authorized vs unauthorized requests, etc. The only reason I didn’t do this was because I didn’t prepare for it, but in the future I would take a breath and think about the proper way to write the code before I actually wrote it.
    2. Do not prematurely optimize the code before you’ve completed the full problem. Note where things can be better and then move on. Trust that the interviewer will ask you for more detail if they want it. I spent too much time fiddling with irrelevant error handling and ended up burning time and energy that could have been better spent elsewhere.

2. Technical knowledge

I had 2 interviews that tested my technical knowledge by asking questions like

  1. How would you write a mock of an MQTT service for the purpose of unit tests?
  2. What is the difference between a Promise and a timeout function with respect to the event loop in Node.js?
  3. If you had a large amount of video data buffered into a client-side application, how would you efficiently scan to the data that corresponds to a specific timestamp?
  4. What are the spread and rest operators in JavaScript and how can you use them?
  5. What are some design patterns you’ve used?
  6. What are some examples of when you’ve used inheritance and composition?

I like this style of interview because it presents the opportunity for a dialogue. I felt out of my element with the design patterns question even though I should have known it was coming. I think my biggest area for growth here is being more concise - I tend to ramble.

3. System design

I have never done a system design interview before. I was extremely lucky that early in my interview process at one company, they told me I’d be doing system design in a later interview. That gave me time to figure out WTF is a system design interview.

There are a lot of resources out there for system design interviews. My brother swears by this system design guide, but personally I found the Interviewing.io guide on system design interviews to be exactly what I needed. The writing is absolutely top-notch, and the course is extremely focused on topics that provide a high ROI for job applicants. In my opinion, the biggest bang for the (free) buck came from their two YouTube videos showing experienced engineers performing a mock system design interview. (Link to the lesson with the two embedded videos, direct link to first video, direct link to second video.) This course was crucial for me because it gave me a structure to organize all the knowledge I have in my head. Most of the concepts they teach are things I’ve read about, heard about, or used directly, but without working through the course, I never would have been able to accurately articulate my thoughts in an interview setting.

In addition to helping me prepare for the system design interview specifically, I felt that studying system design helped me feel more confident as an interviewer overall. I noticed a significant boost in my general interviewing confidence after studying system design because I felt like I had been given a key of useful terms to discuss during interviews.

Helpful resources

In no particular order, I found some of these resources to be highly useful

Learning experiences / take-aways

  1. Be prepared for a large number of no-replies!
  2. Keep a pulse on the market - just as the housing market has “buyers markets” and “sellers markets”, the job market has “employers markets” and “applicants markets”. (Hint: it is currently an “employers market”.)
  3. Do not underestimate the value of interview practice! I would have been absolutely hosed in a couple of my interviews if I hadn’t spent time practicing some algorithmic questions (à la LeetCode) and studying system design interviews in particular.
  4. Interviewing.io has some absolutely 🔥 fire content 🔥 - keep it going y’all!

Conclusion

Job searching still sucks. Don’t forget to be kind to yourself, and others.

If you’re a hiring manager or recruiter, please do not underestimate the value of a response, even if it is a rejection! Silence is devastating for job applicants. If you can spare a moment, please give a sentence of feedback as to why you declined (I realize that discrimination laws can make this challenging for prospective employers).

If you’re a job applicant, consider checking out my other post for some tips and tricks I used to keep my sanity while job searching. Also: give yourself permission to avoid LinkedIn! It’s a useful tool, but it can be exceptionally morale-draining to read posts all day about either A. layoffs, or B. someone getting the job you wanted.

And no matter what your role in the process: Be sure to get enough sleep, eat as well as you can, and practice empathy for those around you. We’re all just humans doing our best in a difficult world.