bgenc.net/content/posts/2022.07.10.my-experience-applying-interviewing-software-engineering.md

---
title: "My Experience Applying & Interviewing for Software Engineering Positions"
date: 2022-07-10T15:49:51-04:00
draft: false
toc: false
images:
tags: []
---

I've recently been interviewing for jobs, and decided it might be interesting to
write about how the process went. Hopefully this will be useful for other
developers in my position, or hiring folks who are looking for a candidate's
viewpoint.

#### By the numbers:

- 67 applications
- 5 companies interviewed with
- 1 offer

## Applications

Overall, I made around 67 applications. I'm counting that by the number of
confirmation emails I got, so the actual number may be slightly higher because
a few companies didn't send a confirmation email.

Out of these, I got interviews with 5 companies. That's around a 7.5% response
rate. Keep in mind however that I did apply to a lot of positions that required
more years of experience or experience in specific technologies that I didn't
have. I do think these applications are still useful, because I did get
interviews with some of these. I think it's pretty well known that companies
will sometimes over-exaggerate the requirements so it can be worth applying to
these jobs even when you don't perfectly match them.

The application process was very exhausting. The good news is that there's no
shortage of positions on LinkedIn or other sites that you can apply to. The bad
news is that repetitively filling out applications is extremely boring. I could
have sworn that I applied to hundereds of jobs until I counted them.
My recommendation for applicants is to break it up and try to apply to a few
places every day. Don't get discouraged if you are not getting a lot of
responses: looking at what LinkedIn reports, most job listings get tens if not
hundereds of applications so sometimes your application might just get lost in
the flood.

## Interview Process

The interviewing process varies from company to company, but there's often a
general flow they all follow:

- You'll first get an interview with a recruiter from the HR department. Their
  questions are typically surface-level questions like "do you have experience
  with AWS?" or "how many years of experience do you have with javascript?".
  Keep in mind that this person most often will have no technical knowledge, so
  for example they wouldn't know that listing "Next.js" on your resume implies
  you know React.
  
  They will also typically ask you what range of salary you are looking for. It
  can be hard to come up with a number especially for your first job, but you
  should look up average salaries and figure out a range you think is good. If
  you can't come up with anything, I don't think it hurts to ask what range they
  are looking for. I did this once and figured out that the pay range they were
  offering was just far lower than what I would accept.

- The next step is usually a technical challenge. In most cases for me this was
  a pair-programming exercise, although I've also had a take-home programming
  challenge. What sort of challenge you get here depends heavily on the company
  and the interviewer. Usually it is an opportunity to just chat with you and
  see how you think about problems, but sometimes it can be a "can you solve
  this puzzle".

- What happens after the technical challenge is a lot more varied: some places
  go with the typical "tell us what your strengths are" kind of interviews, some
  do whiteboard high-level design, and some just want to chat with you.

The biggest thing to remember is that the interview process isn't just for the
company to vet you, but for you to vet the company as well. If the interviewer
is being harsh towards you, or the process demands too much of your time (I had
one company who wanted to do an 8-hour "virtual on-site" followed by more
technical interviews!), or if you just get a bad vibe from the people you are
talking to; don't be afraid to say no. Luckily software jobs, even heading into
a recession, are plentiful so you don't have to be stuck with a place you hate.

### Remember to ask questions!

Talking about you vetting the company, you should make sure to prepare some
questions to ask. Make sure you ask about anything you are curious about or
anything that's a dealbreaker for you.

If you're not sure what to ask, there are [a lot of resources
online](https://hackernoon.com/what-to-ask-an-interviewer-during-a-tech-interview-865a293e548c)
for examples. I like to ask a mix of "people questions" (e.g. how big is the
team, is it a new team or an existing one that you are expanding etc.), technical
questions (how do you do code reviews, are there any standard tools you use etc.),
and company culture questions (do you work overtime and how often, is the design
process collaborative etc.).

### Take notes

Maybe you have a great memory and can remember every little detail, but I can't.
I always take notes during my interviews. I'll write down the names and roles of
the people I'm meeting, and any important points discussed. I'd strongly
recommend doing this because you might need to go back and reference things
later when you need to make a decision.

## Interviewers: what not to do

I'm not going to shame any companies or recruiters here, but a few bad
experiences stand out:

- One job listing I applied to was extremely vague about what I might work on:
  this was a big Fortune 500 company that's not a "software company" so it
  wasn't clear what I might even work on. When I asked the recruiter for
  details, they only knew what was written on the job listing.
    - I think job listings should be clear about what the role entails, and
      recruiters should have some knowledge of what the role is.

- At a technical interview, the interviewer seemed to be unhappy with my
  solution and wanted me to explore a different way of solving the problem.
  That's totally fine, but the interviewer would not tell me what was wrong with
  my solution or what sorts of issues I should consider. Instead, they just kept
  repeating "but how else would you do it".
    - Remember that the interviewee can't read your mind. Treat the interview
      like a code review: you wouldn't tell a coworker "this is bad, fix it",
      you would tell them what's wrong. See if the interviewee can handle
      constructive criticism and change their design to solve the issue.