128 lines
6.2 KiB
Markdown
128 lines
6.2 KiB
Markdown
---
|
|
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.
|
|
|
|
|