6.2 KiB
| title | date | draft | toc | images | tags |
|---|---|---|---|---|---|
| My Experience Applying & Interviewing for Software Engineering Positions | 2022-07-10T15:49:51-04:00 | false | false |
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 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.