3 Months of Job Search Prep: Only What Actually Worked
I'm a backend developer with 4 years of experience. I prepared for 3 months, got offers from two companies, and changed jobs last month. Here are only the things that were definitely worth the time during preparation.
- Use 'numbers,' not 'contributions,' on your resume
Instead of 'performance improvement,' say 'response time 400ms → 120ms.' After changing just this one thing, my resume screening pass rate went up noticeably.
- For company research, only look at the last year's news
Tech blog, job posting keywords, recent service changes. Just looking at these three gives you a rough sense of why they're hiring for this position.
- For coding tests, types matter more than quantity
For me, mastering 20 problem types completely worked out better than doing 200 problems.
- Prepare a list of questions to ask the interviewer in advance
Questions like 'What's the biggest technical debt on the team right now?' apparently stick with interviewers even after the interview ends.
On the flip side, what didn't work was rushing to contribute to open source or suddenly starting a blog. Explaining the experience you already have well is much faster.
4 answers
Quantification, facts. Seriously, just this one thing changes the whole feel of the document.
Well, I often see people saying "quantify it," but many who have only worked on SI or internal tools don't even keep response-time logs. That makes me wonder whether they can't write their resume. If there are no numbers, the right approach is to at least frame it as "we established a comparable baseline"—I don't think numbers should be an absolute requirement.
There are mixed opinions on whether rushed open-source contributions are useless... For me, that one contribution became the catalyst for learning code review culture, and in the end it was the experience I talked about the longest in interviews. Of course, if you hastily cobble something together within a 3-month sprint, it does show, lol. But there are cases where just 'explaining your existing experience well' isn't enough, so if you have time, I recommend doing it consistently, even if just a little at a time. Anyway, I really agree with the part about perfectly mastering 20 coding test patterns. I solved 200 problems but didn't organize the patterns, so I got wrecked.
I agree with the list of questions to ask the interviewer. As an interviewer, when a question like "tech debt" comes up, it makes me think the candidate has done some research on the company, so it sticks with me. That said, instead of just throwing out the question and leaving it at that, it would come across much better if you added a line about how you dealt with it in your own experience.