What I Learned While Preparing to Change Jobs (Backend Engineer with 5 Years of Experience)
I’m finally writing up my experience preparing for a job change for three months the year before last. In the end, I got offers from two companies and joined my current company. I thought it would be good to share what helped and what was a waste of effort.
What was a waste of effort: just increasing the number of coding test problems (my problem-solving patterns didn’t expand, and I only drained my energy), listing features in my portfolio, and not lining up other company interviews before salary negotiation.
What helped: practicing describing my contributions in numbers, recording and listening to my own system design answers, and structurally organizing the problems in the work I do at my current company (this becomes the raw material for interview answers).
The conclusion was that improving the quality of preparation was far more efficient than simply spending more time. Good luck to everyone.
7 answers
Do you have a source? Using numbers is good, but isn't the key issue which metric was used?
Agreed—quantifying things is really important. I used to just say "I worked hard," and I only realized it after failing three times.
I highly recommend recording. I used the video conference recording feature to do a mock interview and review it, and I could immediately see on screen my habit of trailing off at the end of sentences and my filler words like 'um...'. It’s also less pressure than getting feedback from someone else.
Not being able to line up plans before a salary negotiation... For me it was the opposite—I had all my other plans set, but when I actually got to the negotiation table, I chickened out and barely said anything. The problem was my mindset, not my schedule lol
For a backend developer with five years of experience, isn’t it common knowledge by now that design and troubleshooting matter more than coding tests? I enjoyed reading your write-up.
I agree with the conclusion, but a three-month preparation period feels like a special case. When I was preparing while employed, even with six months, two hours a day was my limit—so wouldn’t people who can finish it in a short, intense burst have had a relatively relaxed situation at work? Of course, there’s nothing to argue against the point about raising the quality itself.
It’s a bit harsh to conclude that increasing the number of coding test problems is a waste of effort—for me, grinding through lots of problems without having organized the problem types actually made the patterns stand out more. Of course, as you said, there are probably many people who just burn energy. But you said “without expanding the types,” and I’m curious how you made that judgment. Did you set aside separate review time per problem?