Career strategy
Fifteen job applications in four minutes. What did you check?
The number of applications is easy to count. The decisions behind them are harder, and more useful.
By Mike Salari. Staff mobile engineer · 500+ technical interviews from the hiring side.
5 min read
Consider a familiar job search pattern. Someone receives a list of fifteen software engineering vacancies and applies to all of them in four minutes.
That speed, by itself, doesn't tell me whether the applications were good. Maybe the engineer had already evaluated every role and prepared a suitable CV. Maybe they used a saved profile to complete fifteen applications for positions that matched their experience.
Or maybe they opened each listing, pressed Apply, and moved on without checking the actual requirements.
Those are very different behaviours, and a dashboard showing fifteen submitted applications won't distinguish between them.
Before I suggest applying to another fifty jobs, I'd want to know what happened in those four minutes.
Could the engineer explain why each role fits? Is the seniority appropriate? Does the job require a location or work authorisation the candidate doesn't have? Is the CV describing the work that matters to this employer? Is the hiring process even at the stage they believe it is?
When applications get no response, job seekers often reach for the same fixes. Rewrite the CV. Apply more often. Buy another interview course. Post more on LinkedIn.
Any one of those might help. None should be the default without understanding where the search is losing traction.
That is why I use the Phoenix Method as a diagnostic framework. It separates five problems that are often treated as one.
Burn: are you reaching the right screens?
If your applications rarely become conversations, look at visibility and fit before changing your interview preparation.
Start with a sample of recent roles. Were they open when you applied? Did the location, employment type, sponsorship requirements and seniority align? Did the CV make the relevant platform and domain experience easy to find?
A first screen is often only a few seconds long, and how it happens varies. Some roles have filters, some have recruiters, and some have referrals or direct manager reviews.
You can still inspect the evidence you control. Compare the requirements to what the CV visibly demonstrates. Check whether the document parses correctly. Review whether the headline and recent work match the positions you are targeting.
This is what a Free ATS CV scan can help with. A scan is one check, not a prediction of a hiring outcome.
Ashes: can people see the work you've done?
Many CVs are full of technologies and tasks. Swift, Kotlin, REST, unit tests, feature delivery, bug fixing.
The missing part is often the evidence. What changed because of your work? Which decision did you own? Who depended on the result? How did you know the change was useful?
A recruiter cannot reconstruct that information from your Git history. Even a technical hiring manager may not know whether you designed the architecture or implemented part of someone else's plan.
You can improve that without inventing impact. Describe the problem and your real contribution, including trade-offs where they matter. A modest, defensible claim is more useful than a dramatic number you cannot explain.
Rise: are you being read at the level you want?
If you regularly get conversations but interviewers keep treating you as a lower level, the issue may be positioning.
You may be applying for staff roles while describing only individual ticket delivery. Or you may be applying for senior roles without making it clear which features you have owned end to end.
That does not mean you should add leadership claims you never earned. It means you should inspect whether your actual experience is visible at the scope you are targeting.
A target role isn't just a title. It is a set of responsibilities the company expects you to handle.
Fly: what happens after you enter the interview?
If you are receiving appropriate interviews and consistently losing technical rounds, sending more applications won't repair that part of the process.
Look at the specific failure. Are you struggling to explain trade-offs? Does live coding fall apart after a small change? Can you defend the architecture when a requirement changes? Do you have examples of disagreement, ownership and recovery after a mistake?
These are different preparation problems. Practising more algorithm questions may help one of them and do little for another.
Track the stage at which you lose the process, not only whether the answer was no.
Land: does the offer match the role you wanted?
Reaching an offer is not the same as reaching the right outcome.
An offer may come with a lower title, reduced scope, a different location requirement or compensation that doesn't support the move. Before accepting, establish which parts of the original role changed and what the next review or promotion process would require.
The aim isn't to maximise every number. It's to understand what you're agreeing to.
Stop optimising the click
If you apply to fifteen jobs in four minutes and none replies, you still don't know whether speed caused the result. You need a better record of the inputs and the stages that followed.
For your next ten applications, keep a small table: target level, fit against essential requirements, CV version, source of the role, date submitted, and last stage reached. Record the reasons you can verify and leave unknowns as unknowns.
Then review the pattern. No screens points you towards a different investigation from several final-round losses. A lower-level offer is another question again.
The Phoenix Method is my way of keeping those problems separate: Burn, Ashes, Rise, Fly and Land. It doesn't promise that every rejection has one clean explanation. It gives you a more useful starting point than sending the next batch without learning from the last one.
If you want to find your stage first, the free Phoenix Method guide has a 60-second check that tells you where to start. For a first check of how your CV is being read, use the Free ATS CV scan.
The Apply button is the fastest part of a job search. It shouldn't be the part you optimise first.
