By no means should this article serve as a guide for how one should go about the engineering interview cycles, but I just wanted to document my thoughts as I went through this time around.
For the first time in a while, I deliberately left work in order to be able to focus on looking for my next career step and prepare for the software engineering interview loops. At this point in time, I’ve come to understand the type of preparation and mental exhaustion that comes from going through these processes.
After spending two months in a sabbatical of sorts, I was ready to start the next chapter.
Sending Out Resumes
I was lucky in a sense that during the pandemic, there was no shortage of software engineering jobs. As the world went online, the need for digital improvement increased and with that, some companies had increased demand. It was slow in the beginning of the pandemic, but by 2021, most companies had a better handle on their growth and trajectory.
I struggled initially to get my foot in the door. While there are many different ways to get the attention of companies, I started off by focusing on cold applying through LinkedIn or BuiltInNYC. It’s funny that I started off this way. After months of preparing myself, it turns out I didn’t really know what companies I wanted to apply for. It turns out this led me to job boards because I could just scour what companies were looking and apply if anything looked interesting.
The response rate of that was low. It’s not really that surprising, as recruiters get inundated with applications, probably tens to hundreds of applications per available recruiter for a company. I hadn’t quite optimized my resume in the beginning, which probably led to my resume getting filtered. At least that’s what I assume.
At the same time, I turned on LinkedIn’s option to let recruiters to know you’re looking for a job. This led to a lot of third-party recruiters reaching out. I spoke with a few, but nothing really ever came from this. I’m even more surprised that after initially speaking, many never followed up afterwards. I’m not sure what the reason for this is but I didn’t fret too much.
I also started to reach out to my network for references, starting with close friends. In the end, I only reached out to close friends due to my own personal awkwardness. This often led to better results in terms of initial outreach, though not with 100% success. Though I haven’t fully crunched the numbers, at least 75% of the time I got to actually talking with the company itself.
I also found jobs through interviewing.io. The site and service launched a new system where you can take interviews the same as if it was a peer-to-peer interview, except that it is with an employee of a certain company that is hiring. In this case, I was able to use interviewing.io to find one company in which I ended up going through the process with. Definitely can see some potential here.
Lastly, I turned on TripleByte. I’ve had good experiences with these platforms in the past. I had gotten my previous job from Hired. My experience is this is a little skewed because I turned this on towards the end of the interview phase, but the companies here were a bit smaller than I would have liked. The majority was in a very early stage startup and with roles that didn’t quite fit what I was looking for. It’s very possible if I tailored and researched a bit more within the platform, the experience would have been different. However, I was in the midst of onsite interviews when I turned this live, so I didn’t prioritize.
Tech Screens
The next logical step in the interview circuit are the basic tech screens. While the phone screen algorithm question is still pretty common in the picture, I’ve been seeing an increase in using Byteboard (https://byteboard.dev/) as a new way to screen candidates. It is designed to try to get insight on a candidate’s aptitude for more “real work” scenarios.
The first part is a 40 minute design document review in which the candidate should comment and answer questions as well as recommend an overall choice. The second is a 75 minute coding exercise in which the candidate navigates a code base that is related to the topic in the first section. There are a number of methods to fill out and test cases to generally pass.
Overall, I would say it generally is a bit strange to do in a timed format. I’m definitely used to doing algorithm / coding interviews under timed pressure, but doing system design review is very new to me. This format definitely favors native english speakers and people with fast reading comprehension. I personally would have favored having a bit more time to be able to read carefully. Someone’s reading speed shouldn’t have a wild affect on their performance.
At this time, I haven’t found any resources to practice Byteboard but it is gaining traction, with Lyft, Coinbase, Robinhood joining its growing list of users. I’m sure with increased popularity, there will be sites that include this as practice.
On-site
Remote on-sites are somehow even more tiring than in person ones. I assumed part of the reason is the same as how staring at a screen for a long time can bother your eyes. I think the other aspect is just how unnatural it feels. We’re used to trying to gauge each other on a human level. However, through Zoom calls and remote on-sites, the information we receive is limited and as such, feels a lot more impersonal. To me, this creates some discomfort because it makes it harder to be confident that you can work and get along with your future place of employment.
It seems this is just something we all have to get used to as companies are moving towards remote only policies. Dropbox and Twitter, to name a few, are paving the way for that transition and in due time, when companies see how successful they can be with that setup, they may do the same.
Overall, on-sites that I had were pretty standard and comparable to each other. Usually, they consisted of a couple algorithms, system architecture, deep-dive and cultures. They were generally long and I appreciate companies that were willing to break them into multiple days. This would have been particularly useful if I was still employed while searching for a new job. I wonder if this is the norm and candidates should be asking for these more often.
I mostly applied to smaller companies, so it’s possible that my experience was different because of the flexibility. I had one larger company that I interviewed for and it’s possible they’re less likely to offer that kind of flexibility, although I could be wrong.
The part about all the on-sites being crammed together that I really despised was the exhaustion of it all. If I were to do this all over again, I would probably like to space them out a little bit more so that I could have time to mentally recover before embarking on the next one. It’s a fine balancing act though — I also wouldn’t want to leave companies hanging for too long while I complete interview circuits. Decisions have to be made in due time and sometimes incomplete information is all that one has to work with.
Final Thoughts
Overall, this process is grueling and tiring, but I also feel more confident in myself and learned a lot. Through studying algorithms and interview questions, I felt that I was able to gain some technical knowledge that I wouldn’t normally get in a position. Now that I’m out of the process and going back into the working world, I wonder if I’ll retain this knowledge.
I sure hope so.
