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

@@ -1,127 +0,0 @@
----
-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.
-
-