diff --git a/content/posts/2022.07.10.my-experience-applying-interviewing-software-engineering.md b/content/posts/2022.07.10.my-experience-applying-interviewing-software-engineering.md new file mode 100644 index 0000000..b69fdf9 --- /dev/null +++ b/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. + +