The Infamous Tech Job Search


These past couple months, I conducted my first real software engineer job search in almost ten years. It was eye-opening and I want to get my thoughts down about the experience before I block it out of my memory.

In hindsight, it was maybe irresponsible for me to interview people when I hadn’t done much interviewing myself in so long. Now that I’m on the flip-side, I’ll have more empathy for the people I’m interviewing and do everything I can to make the process at my new company as nice as possible!

Long onsites

When I tell my friends in other industries that I have a full day of interviews, they’re shocked.

By the third interview in a row, I can’t think straight at all. I just focus on surviving and trying to say anything that would indicate that I usually know some things.

There’s something about it that’s particularly draining, much more than just “a day at work”. You’re burning through adrenaline and your creative juices rapidly. It’s the same feeling I’ve gotten from a first day on a new job. My brain just has too much to process — new people, new problems, and the pressure of being evaluated.

This is all to say, that I had no idea how physical interviewing would be, even though my interviews were all over video due to the virus. It was something that really surprised me.

One company I talked to still had five interviews, but kept them short: 30 minutes per interview, with a few minutes extra for questions. That was a bit better. I still experienced brain-melting, but to a lesser degree.

What I took from this experience is that it’s not great to have too many interviews in one day. Often I’ve felt that some are redundant, and could be cut out. If you need second opinions — have two engineers sit in on an interview. Alternately, what if the interviews were divided up, with a couple over video one day, and coming onsite for a couple more, but mainly to meet team members?

The questions

Most companies have moved on from brain teasers and clever problems. I’m happy most of the coding challenges are more straightforward questions involving arrays and dictionaries. You’re also often allowed to google API docs as you go. Questions now are related to the role, and are often fun in their own right.

These are all good things, but what remains is the fact that you’re solving a time-crunched problem while someone is staring you down. There’s nothing that can take away how that affects people’s problem solving abilities — much less their stamina.

It’s also a snapshot at the wrong time. You’re told that they “just want to see how you think”, but what I think is dumb.

I often cycling through completely wrong things while I’m problem solving. My brain will make up some false statement, only for me circle back later and be like “ah, so silly, X isn’t like that.” It’s only the end product that (usually?) ends up good.

Here are some good solutions I’ve seen to this: a well-timed take-home with an in-person walk-through of your solution. For system design: a walk-through of a project you’ve done before and the trade-offs there. A take-home code review works well too.

Long take-homes

I had a couple take-home assignments. One of them was drastically underestimated by the company. It was billed to take about 4 hours, but I spent about 12 hours on it, and I didn’t even polish it up as much as I wanted to. I’ve been coding for over a decade. I might be a slower coder than average, but even so, I felt there was no way it could fit into that time.

It was parasitic in a way. That company got much more of my time, and it ate into the time I had for the other take-homes and calls.

It’s ironic because the stated goal of take-homes is to see how good your code is. It’s supposed to be solid, well-structured and easy-to-read. When you are down to the wire with lots of other things to do in life, the last thing you have time for is that critical sweep of “how could I better structure this? Is there anything I’m missing?”.

By blowing out the logic and large pieces required in a take-home, the company is actually getting a worse glimpse of what it’s supposed to get a sense of.

It’s mixed, because the take-homes were often the more enjoyable moments of my search. Coding gives me agency, and I loved getting to use my new language (Python) more, and learn some things. For me, I much prefer coding on my own than in front of interviewers. Take-home exercises can also be anonymized — a huge benefit.

If you’re going have a take-home as part of your interview process, make sure to put in the effort to calibrating it well. Have your engineers complete the question themselves. Be specific in your expectations. And if you’re going to have a take-home, make the on-site much shorter.

“Name a time when”

Most of my interviews asked a few open-ended “Name a time when you did X”. Some questions were so common that you would soon come up with a good fit for the question, and could use it your subsequent interviews.

Often, there were several that were unique and required improvisation. It’s hard for me to scan through my work history to find a good fit for the question within 20 seconds, which I think is when things start getting awkward.

If you can’t come up with an answer to one of these on the spot, it can make you look like you didn’t do anything or learn anything at work.

I wonder if companies sent these open-ended questions ahead of time, and you could come up with a good example to talk through in person. I had one company let me know the general areas they would cover, like “mentorship” and “cross-team collaboration”, which helped.

The attitude

Some interviewers were warm and supportive. Some would even tell me the answer to a question if I told them I didn’t know what technology X did, or didn’t know how Y worked. It felt like a conversation.

Many other interviews were, figuratively, someone leaning back in their chair, arms crossed behind their head, casually saying “You think you could do this job? Prove it to me.” Those interviews felt really one-sided.

I’m not sure people realize they’re putting off that vibe. At a previous job, I had one interviewer come across particularly skeptical and aloof. I was worried about taking the job because I thought that’s what my interactions would be like at work. I ended up joining, only to find my interviewer to be a very warm, collaborative coworker in actuality.

An interviewer being welcoming and having humility makes a big difference. Just generally, it helps someone’s job search to not be as soul-crushing, but also it ensures you’re getting them at their best.


I got rejections at different stages, with little idea of why. There was one single place which offered feedback on interviews. It was extremely helpful. They broke it down by interview, saying things like “In talking with X, we felt like you didn’t go into enough depth”. Otherwise you’re left guessing about which interview you messed up.

If this were a normal occurrence, I think the social norm of not arguing with feedback might take hold as well — which I think is what companies are worried about when they’re tight-lipped.


There is much talk about how programmers have it easy finding a job. I have a CS degree from a “top” CS school, have worked at well-known companies for years and gotten praise at work for my programming abilities, but it wasn’t easy for me!

The process isn’t well-suited to me, and probably others. I’m not an on-the-spot thinker, and I get stressed under pressure. This is not to say that companies would have loved me if their process were suited to me, but it makes it hard to tell.

Hiring programmers has been famously hard due to the market imbalance, but just as much as hiring is hard, companies are risk-averse. I ended up getting one of the roles I was most excited about, but I’m lucky to have found a job during this crisis. I had one company shut down hiring before I could do their video onsite.

A larger pool of candidates is already starting to form due to the virus. I worry about these candidates having to go through even more full-day onsites, time-consuming take-homes, and demoralizing processes to find a position. For this reason, I wish that companies would invest in making their processes better, now.




Lover of all things computational

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

July 2021 Internship — Alchemy Group

NBA Top Shot NFT Monitor Tool

3 Simple Steps To Make Your Code Startlingly Better

10 AI Tools for Freelancers

Why we’ve ditched scrum sprints (and you should too)

Health checks for Kafka Streams application on Kubernetes

Using Prometheus to monitor apps on Oracle Application Container Cloud

Smart Contract Whitelist Mechanism

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Heather A

Heather A

Lover of all things computational

More from Medium

What is Big O?

Let’s Talk About the Big O

From a hobbyist to a professional: Lessons learned, an Educator’s perspective.

A programmer at his desk working.

The Beginnings of React.JS