Roughly half of every cohort is expected to come from outside computing — accounting, nursing, logistics, teaching, the military. The difference between advice that actually works for that transition and advice that merely circulates is worth being precise about, because most of what circulates is written for people who are already halfway there.
What follows is what we tell people in the admissions conversation, including the parts that are less encouraging than they would like.
Your portfolio is probably working against you
Almost every career changer arrives with the same portfolio: a to-do app, a weather dashboard, and a clone of a well-known product. These are what tutorials produce, and every hiring manager reviewing junior applications has seen several hundred of them.
The problem is not that the projects are simple. It is that they demonstrate you can follow instructions, which is not the question being asked. The question is whether you can make engineering decisions when nobody has told you the answer.
One project that shows judgement outperforms five that show completion. Judgement is visible in specific, unglamorous places:
- A README that explains why you chose an approach, and what you rejected
- Tests that cover the cases you thought were risky — and a note on why those
- Commit history showing the work progressing, not one commit called "initial commit"
- Error handling for the failure you actually hit while building it
- An honest limitations section describing what it does not do
The most effective portfolio project we see repeatedly is something built for a real person with a real problem — often from the applicant’s previous industry. A scheduling tool for the clinic you used to work at. A reconciliation script for the finance team you left. It is domain knowledge nobody else applying has, and it demonstrates you can work from an ambiguous requirement rather than a specification.
The experience paradox is real, and mostly navigable
Junior postings asking for three years of experience are a genuine phenomenon and a genuine obstacle. They are also less binding than they appear. Those requirements are frequently written by copying a previous posting, and hiring managers routinely interview people who meet perhaps two-thirds of the listed criteria.
What actually filters applications at that stage is not years. It is whether the résumé provides evidence for anything it claims.
Compare two ways of writing the same line:
Proficient in Python, SQL, and data analysis with strong problem-solving skills.
Built a Python pipeline that replaced a weekly four-hour manual reconciliation at my previous employer; ran in production for eight months and processed about 12,000 records a week.
The second is not a more impressive project. It is the same class of work, described in a way that can be verified and asked about. The first is unfalsifiable, which makes it worthless as a signal — and experienced reviewers read it as noise.
Choose depth over coverage, and choose by job posting
Career changers consistently over-index on breadth. It feels like progress to add another language, and it is the wrong optimisation. Employers hiring juniors are not looking for range; they are looking for evidence that you can go deep enough on one thing to be genuinely useful in it.
A concrete method: find fifteen job postings you would actually accept, in your actual geography, and tabulate what they require. You will typically find one dominant stack, one or two common secondaries, and a long tail of things mentioned once. Learn the dominant stack properly. Ignore the tail entirely.
This is unglamorous and works better than following what is being discussed online, which is optimised for engagement rather than for what regional employers are hiring.
The parts that transfer between stacks
Some skills survive every framework cycle and are worth disproportionate investment:
- SQL — used in nearly every technical role and rarely taught properly
- Version control beyond commit and push — branching, rebasing, resolving conflicts, reading history
- Testing as a design activity, not a compliance step performed afterwards
- Reading unfamiliar code — the actual daily activity of professional engineering
- Debugging methodically rather than by changing things until symptoms move
Of these, reading unfamiliar code is the most underrated. New engineers are consistently surprised by how little time is spent writing code from scratch and how much is spent understanding what already exists.
Interview preparation, in priority order
Candidates over-prepare for algorithm puzzles and under-prepare for everything else. Outside a handful of large technology employers, the failure modes we see in mock interviews are rarely algorithmic.
- Talking through your own projects under questioning — by far the most common failure, and entirely preventable
- Explaining a technical decision to someone non-technical, which most roles require weekly
- Basic system design at a realistic level — how would you structure this, where would it break
- Debugging live in front of someone without freezing
- Algorithm questions, which matter mainly at large technology companies
Record yourself answering "walk me through this project" and watch it back. Nearly everyone discovers they describe what the project does and never mention a single decision, trade-off, or thing that went wrong. Interviewers are listening specifically for those.
A realistic timeline
Programmes advertising a job in twelve weeks are describing the best case as though it were the median. For someone studying part-time around existing work, the realistic shape is six to nine months from starting seriously to accepting an offer, with the last two to three months spent entirely on applications and interviews.
That number varies with the market, your location, your work authorisation and how much time you can genuinely commit each week. But planning for nine months and finishing in six is a considerably better position than the reverse — and the people who plan for twelve weeks are the ones most likely to stop at month four.
The part most programmes leave out
This transition is difficult, the market moves, and effort does not guarantee an outcome. Anyone guaranteeing you a job is either not counting honestly or is transferring the risk to you through an income-share agreement.
What is reliably true is that the people who succeed are rarely the ones who started with the strongest technical aptitude. They are the ones who kept a consistent schedule for months, sought out feedback that was uncomfortable, and treated rejection as information rather than as verdict. That is a less exciting message than most marketing in this industry, and it matches what we observe.