Add my experience applying...

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

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