Thoughts on running a job search in 2021
I recently wrapped up a job search. My new job starts as I'm in the process of leaving the Recurse Center, so I thought this would be a good time to summarize my impressions of the job market for software developers in 2021.
I've encountered a fair amount of advice for software developers who are just getting out of university, but less advice for developers on their second or third job. This post is my attempt to fill that gap a bit and write down some advice to my earlier self. Hopefully it contains useful suggestions for other job seekers, especially other Recursers.
Background
Like many software engineers, I have mixed feelings about how our industry (specifically, software companies in the US) conduct interviews. My first few interviews out of university (circa 2010) were pretty difficult. These consisted of solving "leetcode" style problems in a panel interview format, where 5-6 older engineers scowl at you while you work at a whiteboard. Having been both an interviewer and an interviewee, my impression is that the process is pretty ad-hoc and varies a lot between companies. As an industry, we just aren't that scientific about crafting interviews and reviewing the results.
After talking to a number of experienced developers and reading comments on Hacker News, I think many software engineers find the interview process frustratingly artificial, like a sort of "hazing" ritual. In this viewpoint, the difficulty of interviewing forces candidates into a "scarcity" mindset where interviews are hard to get, job offers are even harder to obtain, and unemployment is to be constantly feared.
My mission this Summer has been to change my perspective on that. I don't think that finding a job will ever be "fun" per se. It's always a bit stressful. But, I didn't want to operate from the basis that interviewing is to be feared, especially when that feeling is amplified by sentiments on social media (e.g. Hacker News).
General Strategy
Talking to people about their job searches, I observed two main strategies:
- Develop one strong resume and send it out to many companies.
- Target a handful of specific companies that fit your interests.
I lean heavily toward the second strategy and applied to 6-10 positions this time. The following criteria narrowed my search quite a bit:
- I wanted to continue working on analytics/data engineering problems.
- The role needed to allow for remote work.
- I wasn't interested in working for a FAANG type company this time out; as far as I can tell, interviewing for these roles is quite different from interviewing with a startup.
- I wouldn't take a position that I felt had serious negative externalities (i.e. cryptocurrency/NFTs, fossil fuels).
- The role would ideally involve some amount of functional programming.
In general, I didn't apply to positions unless I met the majority of the requirements in the job spec. For most positions I prepared a custom cover letter. I primarily applied to most companies directly through their website. The main exception to this rule was companies affiliated with the Recurse Center; for these I applied via RC's career services program.
Before I started my search, I overhauled my personal website, LinkedIn page, and resume. My previous job at a smaller, sales-focused company had a significant advantage: It was much easier to frame my past work in terms of a benefit to the company's business. Instead of saying "I set up server X and built technology Y", I could write: "I built X which serves Y percent of all customers and saved Z dollars." This was more difficult when I was working in a research role, separated from users by several degrees. I think my resume was stronger on this job search than on previous ones, largely because I kept an up to date "achievement list" in my previous role.
Companies with an Open Source Presence
This time I applied to more companies that list their source code on github. For these I followed a somewhat different strategy.
I started by making a list of public repos the company was actively developing. This can typically be worked out by examining github activity and (in some cases) presentations from recent conferences. I downloaded some of these projects to get a sense of how they worked; this was a helpful test to determine whether I would want to do this type of work long term. If I found a project with a smallish issue that I could solve, I prepared a pull request.
This process had a few benefits:
- It helped me learn a little more about the company's code review practices.
- A merged PR gave me something to mention in my cover letter, to help me stand out from other applicants.
- It allowed me to expand my portfolio of open source work.
This was a more labor-intensive strategy, but I considered it worth the effort. In some cases, this technique allowed me to skip over technical assessments or other "take home" assignments, because the hiring manager was happy to use the PR I had prepared as a substitute. In general, this technique seemed to "fast track" my application when it worked.
Contracting
During my job search I also explored the possibility of working as a contractor. This came about because one of the companies I applied to wanted to hire me full time but didn't have the funds to do so; instead they offered me part time work until they could afford bring me on full time.
Setting up an LLC isn't terribly difficult (perhaps a day worth of work and $100-600, all in) and gives you the ability to do some part-time work while looking for a permanent position. This took some of the pressure off of my job search and helped me feel more confident that I could support myself while looking for work. My general impression is that it's easier to get hired as a contractor than as a full time employee, because neither side is committed for the long term.
It's probably worth noting that this strategy might not work as well if you haven't already built up a broad professional network or are earlier in your career.
Things I could have improved
Although I'm happy with the outcome of my job search, there are some things I could have done better.
Most of my mistakes were errors in "timing" my applications. I applied to a French company in late July and failed to realize many European companies are completely shut down in August due to vacations. This meant that even though they were interested in talking to me in September, any other offers I received would arrive well before I could start their interview process.
I decided to stagger my job applications such that the applications I felt least confident about went out first and the ones I considered "safe fallbacks" went out last. I thought this was reasonable because I was writing custom cover letters, at a rate of 1-2 per day. In retrospect, this approach was suboptimal. It had the effect of making my job search longer than it needed to be. One of the "safe fallback" jobs I had applied to had already been filled earlier in the month; it couldn't have helped me, even though I was a good fit! It would've been better to just learn that first thing.
I augmented my main job search by using two jobs boards, AngelList and FunctionalWorks. I didn't get useful leads from either service, despite having had success with AngelList in the past. I suspect that because these tools make it easy to apply to lots of jobs at once, it's very hard to make your resume stand out when you use these channels.
I spent a lot of time working on leetcode problems. To my surprise, this didn't actually come up much during my interviews. The firms I was really interested in asked me for a sample of my open source work (i.e. links to github) and/or gave me a take-home exercise that was quite reasonable. There were no tricky algorithm/puzzle questions. I'm not sure if I will bother with "grinding leetcode" in the future; I'd much rather just focus on consistently growing my open source portfolio and let that speak for itself.
Things that went well
I found that my professional network was very useful this Summer. My experience has been that networking effects take time to build up, but they yield information that would be difficult to obtain any other way. People I met at the Recurse Center offered to connect me with managers they knew. Conferences I had attended some years ago produced useful leads on new jobs. Friends from grad school who had startup experience and other scientific expertise gave me valuable advice about whether certain jobs would be a good fit.
Previously, I was uncertain about whether having a blog was especially useful. My website was very helpful on this job search. Multiple interviewers mentioned reading through my posts and asked me questions about past projects I had documented. If I had one recommendation for new software developers, it would be to start keeping a blog early. Add a technical post every month or two. Github pages makes this really easy (and it's free). I now feel pretty confident that a blog is a good way to "make a name for yourself" especially if you're interested in somewhat niche topics.
Due to the pandemic, the chances of an onsite interview were basically zero. I knew that I would need to come across well on video so I set up my home office such that I would be in front of a plain white wall with a whiteboard. This ensured I could easily talk through a design if I needed. I wore a dress shirt for all of my interviews; essentially the same outfit I wore when I worked in an office in Boston. I'm not sure that this was strictly necessary, but I think it gave me a small psychological boost and communicated that I was a reliable professional with a quality home office.
I spent a fair amount of time preparing questions for interviewers, especially longer on-site interviews. I found that it can be very helpful to frame questions in a way that's quantitative and does not contain a value judgement. For example, instead of asking "How stable is your production environment?" (value judgement, qualitative) I instead asked "How many times have you been paged in the last 6 months?" (quantitative). This approach yielded more quantitative and qualitative data about a company's technology, so that I was better informed about the day to day experience of working in a particular role.
The final thing that I did well was to end some interview processes early, when I identified that the company or manager wasn't a good fit for me. Some hiring managers were very pushy about knowing my "three greatest weaknesses" or my past salary. I decided not to deal with them further after a first interview, which saved everyone time and effort. I also terminated some interview processes because managers described business goals that didn't make sense to me. I used the following test: "How would my former tech leads react if I presented this proposal to them?" If the answer was "very negatively", I often reconsidered whether to continue with an interview.
Feedback
Interviewing is always somewhat stressful. If you're in the midst of a job search, my main advice is: Hang in there, you'll find a job if you're persistent and ask the right questions.
If you found this post useful (or conversely, think that this advice is bad), send me an email. My contact information is listed on the About page.