My first rejection from a full-time position was sent to me on August 30th, 2015, for a software engineering position at Uber. It was a form letter; they didn’t care for my resume.
My first full-time job offer arrived on August 9th, 2016, nearly a year later. It ended up being the only offer I could reasonably expect for the next few weeks afterwards, and so I accepted it after a bit of negotiation. As a result, I’m now working as a software engineer at PrepScholar.
A lot happened in between (not all of it was spent looking for a job), and here, I’ll reflect what went wrong (and right) in the job hunt. Much of this post is complaining about myself, so if you want to skip everything after the spreadsheet (which has all of the data), go ahead.
(I probably shouldn’t have this up when I’m actively looking for a job, huh?)
Table of Contents
- Facts and Figures
- A Primer on Interview Types
- What Went Wrong (or: I Complain About Myself)
- Lessons (or: What I Should Have Done)
- Parting Words (or: What Went Right)
Facts and Figures
To start us off, I’ve compiled a spreadsheet of all the companies for whom I completed an application process, whether by receiving a rejection or an offer: http://goo.gl/CmThcR. If you want a copy of my resume as it appeared in the last few months of the search (for context), here it is.
In my search, I was open to a wide variety of work that involved writing software at companies both small and large. Most of them were software engineering positions, many with a focus on web development (I mainly applied to backend or “full stack”—the trendy term for “generalist”—positions). The remaining ones were focused on data science in some form; at the Broad Institute, MIT, and Stanford, I applied to research roles that mainly featured data analysis.
A Primer on Interview Types
A lot of this will probably be redundant to anyone actively interviewing for software engineering roles, so feel free to skip it.
Nearly all of the interviews I participated in can be described fairly well by at least one of the following categories, and I’ll explain them here so that my spreadsheet makes sense. The boundaries are fuzzy, and I use the word “interview” loosely, as a shorthand for “stage of the recruiting process”, in order to include coding challenges. An onsite interview typically contains 3-5 in-person interviews, mostly technical, but often with 1-2 behavioral interviews.
Often done by a recruiter (but occasionally an engineer or PM), this features any or all of: an introduction to your background, your career goals, any projects you worked on, and behavioral/personality questions. On the other hand, the interviewer might introduce you to what the company does, especially if it’s a lesser known or smaller company, and give you some time to ask questions. This typically runs 15-30 minutes.
Technical Phone Interview
(Includes Hangouts or Skype calls.) The interviewer, an engineer, gives you technical problems and you work through them together (whether “together” is a truly accurate description depends on the interviewer). These problems are usually focused on data structures and algorithms, though the interviewer is often free to focus on other subjects, like web development or systems. Most of these involved coding online on a shared document with something like HackerRank or coderpad.io.
The usual expectation for a given problem is that you explain your reasoning while you come up with a solution, write it up, test your solution, and analyze it (e.g. for time/space complexity or code quality). Depending on the interviewer and problem(s), they may ask follow-up questions or ask you to improve your solution. This typically runs 45-60 minutes, including time to ask questions at the end.
This is usually a HackerRank (or similar) test with two or more coding problems, nearly always about data structures or algorithms, for which you’re given anywhere from 1-3 hours. You’re graded on how efficient/effective your solution is, and if the company chooses, on your coding style or how quickly you finished.
Occasionally, the company gives you their own coding project. It might be a short script or problem along the lines of a HackerRank test, or more rarely, an actual software project where you’re expected to build something.
Technical In-Person Interview
This is similar to the technical phone interview, but you usually use a whiteboard to code on rather than a text editor. This makes it harder to write (if you’re better at typing than writing on whiteboards like I am), check, and test your code. It also removes any distractions (…like Stack Overflow) the internet might provide. At this level, systems and design questions are more common; you might not write much code for those and instead describe how you would approach building a system or web application. Again, this usually runs 45-60 minutes per session, though for on-site interviews, you usually get 3-5 of these in a day.
Behavioral In-Person Interview
This is an amped-up version of the introduction call, extended to the length of a technical interview (45-60 minutes), giving the interviewer more time to go into the behavioral questions. Be prepared to offer your greatest weakness, what direction you want to take your career in, a favorite project along with a technical challenge that was particularly interesting, and a detailed description of how you handled a conflict while working in a team.
What Went Wrong (or: I Complain About Myself)
Of course, with 75 rejections, I had to mess up somewhere. But of those, only one or two gave useful, concrete reasons for the decision, while all the others gave only generic reasons, citing “fit”/”match” or “experience”. So from here, it’s mostly conjecture and talking about myself.
I’m quiet and awkward, and I dislike talking on the phone (and more generally, to people I don’t know). It’s hard for me to come up with positive things to say about myself or what I’ve done. This already puts me at a disadvantage. Oops.
I’ll be the first to admit that I’m not very good at theoretical algorithm/data structures problems. They don’t interest me that much, I’m bad at studying things I’m not interested in, I have a bad memory, I’m not clever, and I’m lazy. This is a rather bad combination, given that most technical interviews for software engineers (especially recent graduates) feature this type of problem.
A factor compounding this is that my problem-solving process is currently not very suited for interviews. It typically works like this:
- Process the problem statement.
- My brain does some stuff that’s hard to explain verbally or with drawings.
- It produces a solution. (Or just crashes.)
In short, it feels like my problem-solving module is just a black box. This is not what you want for a interview process focused on having you explain your reasoning. It’s often said that it doesn’t necessarily matter if you get the most efficient solution or even solve the problem, as long as your reasoning skills are solid. That’s completely unreassuring to me, considering that I often don’t have a good way to explain what I’m thinking. (If I’m thinking at all; there’s nothing for me to say if I don’t come up with any ways to make progress, and having nothing to say is game over.)
This is only catastrophically bad if I can’t come up with a satisfactory solution, which happens much more than I would like. Uh oh.
My real answer to “What are you looking for in a full-time position?” was something like “Anything related to my degree or experience that will pay me a reasonable salary for working 40ish hours a week in the Bay Area, Seattle, Vancouver, SoCal, NYC, or Boston.” Of course, that doesn’t really sound good in an interview, so I narrowed it down to something that matches the role and company.
The underlying problem was that I didn’t have any strong desire to focus on a subfield or work at a particular kind of company. Even if you don’t say it explicitly, interviewers can often sense apathy, and that does not bode well. (I occasionally failed to sound interested at all about a role or a product, despite indicating otherwise in my words.)
Late Stage Troubles
After early April or so (about a month before graduating), a few other factors made my mindset worse.
- Desperation: I basically threw my resume at any job listing that didn’t look like an horrible fit and that could conceivably result in an offer. This made my average apathy per position even higher.
- Exhaustion: Interviews are terribly draining. I absolutely despise doing interviews, and dreaded the thought of doing even more of them.
- Expected number of offers given my background: After getting rejected so many times, I really questioned whether I was at all fit for writing real-world software if I couldn’t get a job even as an Asian man with a computer science degree from UC Berkeley, decently high grades in CS classes, a couple of internships, and several extracurricular software projects. With that many advantages, the thinking goes, there’s no good reason for me to not have gotten a job before January (or at least before graduating).
I had two trips abroad scheduled, each 2-3 weeks, in July and August. This messed with my potential start dates and recruiting timelines by introducing a bunch of constraints, so I didn’t have as much time as I needed for a few of the interview processes adjacent to those trips.
One scenario I failed to think of—until it was too late—was that I could have cancelled (my participation in) the July trip, worked during that time, and taken time off to travel in August. This detail alone cost me an offer, since they didn’t want someone that could only start in late July as opposed to late June, and by the time I figured out how to remedy this, they had already sent and confirmed the offer for someone else. (This is what I consider to be my biggest single mistake in the job hunt.)
Lessons (or: What I Should Have Done)
These are mostly things that are easy to say, especially in hindsight, but hard to do.
Study Earlier and More Often
I didn’t put much energy into studying until about halfway through the job hunt, in terms of number of companies I interviewed with. (This uptick in effort was due to the Google onsite interview. Not that it helped enough with that, though.) This was a pretty simple mistake that likely resulted in more rejections (or at least ones earlier in the process) than I should have gotten. (If you’re looking for a resource, I liked Elements of Programming Interviews.)
Figure Out How to Explain Your Reasoning
Interviews are highly dependent on this skill. I’m still trying to figure out how to accomplish this when it feels like your brain’s reasoning processes are just opaque.
Write a Reusable Cover Letter
Take a couple days and write a cover letter that you can use for many of the positions you’re focusing on. I wrote one fairly late in the process and tweaked it a bit for each position I applied to, and I think it helped nontrivially. Some companies have forms where they require you to write something about yourself and/or submit a cover letter, and not having one unnecessarily closes these positions off to you.
Think About What You Want From Your Career
This would have helped a lot when interviewers asked me about it. It’s not that I needed to know everything, but I basically had (and have) no clear idea what I really want out of a career or job other than something that’ll pay the bills and that doesn’t involve physical labor or long hours.
Actually Learn What You’re Supposed To Know
There are a lot of things that I’m supposed to know from the work that I’ve done and classes I’ve taken, but none of them are actually actively in my memory. Despite having taken, for each of these topics, multiple classes that cover them, I can’t tell you much about the Poisson distribution, logistic regression, multithreading, or Djikstra’s algorithm without other resources. These are things that I really, really should know, and I’ve been asked about each of these in interviews with pretty terrible results.
(I guess this is what happens when you aim to maximize your grade with as little work as possible, rather than aiming to actually learn. If the topic isn’t sufficiently interesting, the incentive for me to focus on learning rather than the grade isn’t strong enough until I actually need it, and by then it’s too late.)
Get More Experience
Doesn’t hurt. One problem I ran into was that I didn’t really have much experience dealing with scalability issues or distributed computing, so backend and systems-focused interviews didn’t really go well.
(When would I have had to work on something really big anyway? Guess I did the wrong internships and projects.)
Figure Out Timing Logistics
It’s advantageous to be able to start earlier. Find ways to make your potential start date as early as possible. Of course, if you want to start later and the company is fine with that, go ahead.
Only Look in the Bay Area
(This is just for me.) I miss my friends, my family, the food, and the weather. It’s expensive to go back. The Boston area is only an improvement for me in that I have a job here and public transit is more accessible from where I live in Cambridge than where I lived in Hayward. I suspect that if I’d restricted my search to Bay Area companies, I still would have gotten an offer, though perhaps after a longer period of interviewing.
(Maybe the homesickness will wear off at some point. Who knows.)
Parting Words (or: What Went Right)
I didn’t give up, and got a decent job at a company that was a reasonable fit (location aside) not too long after I graduated. This isn’t the worst scenario I could have ended up in, so all things considered, the job hunt didn’t turn out so badly. Cool! (I’m not really looking forward to the next time I have to perform this ritual of horrors, though.)
If you’re about to graduate with a CS degree and don’t have an job offer yet: don’t give up. (When you need motivation, just think about what it’s like to be poor in a capitalist society, and then think about the comparatively pleasant experience of being a wage slave in a capitalist society!)