💻 Software developer
Write, test and ship code professionally.
Employers hire on demonstrated ability, not certificates. Every stage below ends in something you can show: a repository, a deployed page, a passing test suite.
The path, in order
Where people lose months
- ⚠Collecting languages instead of depth. Three half-known languages interview far worse than one you can reason in fluently, because every follow-up question exposes the gap.
- ⚠Tutorial loops. Following along with a video feels like progress but builds recognition, not recall. Close the tutorial and rebuild the same thing from a blank file — that gap is the actual learning.
- ⚠Never deploying. A project that only runs on your laptop cannot be checked by a recruiter in thirty seconds, which is all the time it will get.
Common questions
Do I need a computer science degree?
No, and a large share of working developers do not have one. What a degree substitutes for is proof, so without one you need a portfolio that removes the doubt: two finished, deployed projects and a public commit history do that job well.
Which language should I start with?
Python if you lean towards data or backend, JavaScript if you want to see visual results early and target web roles. Both have deep job markets. The choice matters far less than sticking with one long enough to get fluent.
How long until I can apply?
Most career changers reach an interviewable level in four to eight months of consistent part-time study. Start applying around the two-thirds mark — interviews reveal your remaining gaps faster than more study will.
Put it to work
If the foundations are the gap rather than the job-specific skills, work through the coding lessons first — they assume no prior background.
Other paths: Accounting & CA · Data analyst · Commerce & economics · English & communication · All paths
The realistic progression from tutorial completion to interview readiness
Week one to four: you learn syntax. You finish courses on variables, loops, functions. You can write a program that runs. This feels like progress because it visibly is. The problem appears at week five: you can follow along with a video but cannot write code from a blank file. This gap between recognition and recall is where most people restart, because restarting lets them feel progress again. Push through instead. Spend week five through eight rebuilding projects from scratch. Close the tutorial, look at the output you are trying to match, and write the code. This is where actual learning happens.
Week nine to sixteen: data structures and algorithms. This stage has a mental wall. You read about linked lists and tree traversal and it seems pointless compared to the concrete satisfaction of a working website. But screening interviews for most roles are entirely this material. You cannot skip it. The standard approach is too aggressive: grinding fifty LeetCode problems is torture and teaches pattern-matching rather than understanding. Instead, understand the first four data structures (arrays, hash maps, strings, linked lists) deeply. Implement them yourself from scratch. Write operations on them until you can think through an algorithm without pseudocode.
Week seventeen and beyond: build two complete projects. One should have a database, user authentication, and a deployed URL. The second should be smaller but genuinely solve a problem you have. A note-taking app is overused; a personal expense tracker that integrates with a bank API, or a tool that scrapes a website you check weekly and alerts you to changes, carries more weight because it is specific to you. Finalize both. Deploy them. Write good commit messages. This is your primary evidence to an interviewer that you can deliver finished code, not just write syntax correctly.
The technical interview format and what it is actually testing
Most technical screens follow one of three patterns. The first is live coding: you are given a problem, you have forty-five minutes, you write a solution while the interviewer watches and asks questions. You cannot Google. You might not be able to run your code until the end. The interviewer is testing reasoning, not just correctness. They want to hear you think out loud, ask clarifying questions, and explain your approach before you code. Silence looks like you are stuck. Second is the take-home project: you are given a specification, you have a few hours or a day, you submit code and potentially explain it in a follow-up call. This tests finishing and production-quality code more than the live format does. Third is a system design conversation: you are asked to design a large system — a URL shortener, a chat app, a recommendation engine — and you discuss trade-offs. Preparation matters for this format because it is less about absolute knowledge and more about showing familiarity with common patterns.
Live coding is where the tutorial loop hurts you. You can follow along with code and understand what it does. You cannot write it from scratch under pressure. The preparation that works is rehearsing out loud. Write a solution, then delete it and write it again from memory, narrating as you go. Do this until you stop getting stuck. The second thing interviewers test is edge cases. If you write a solution that works for the happy path and the interviewer asks 'what if the input is empty,' a good answer is 'I did not think about that, let me add a check.' A bad answer is silence or 'I assume the input is valid.' The interviewer is testing whether you think about production code, not tutorial code.
The three most common mistakes. First: solving the problem correctly but in code that is hard to read. Naming variables clearly and breaking logic into functions is more important than clever optimizations. Second: committing to an approach without asking questions. If you hear 'given a list, find duplicates,' ask: how large is the list, does order matter, can there be more than two of the same value. The problem changes based on constraints. Third: not narrating your thinking. Typing in silence for thirty minutes then presenting a solution looks like you got stuck and caught up, even if you did not. Talk through your approach, ask the interviewer if it makes sense, ask for confirmation on tradeoffs.
Where a portfolio actually starts a conversation with interviewers
A completed project beats an incomplete one every time. A project that runs on your machine is worse than a project deployed to a public URL. A project with no documentation is worse than a project with a two-paragraph README explaining what it does and how to run it. A private GitHub repository says 'I do not want you to look at my work.' A public one says 'here is evidence.' The barrier to deployment is usually higher in candidates' minds than in reality. Deploying a React app is free on Vercel. A Python backend runs free on Replit or Render. A database takes minutes to set up. Do not use deployment as an excuse.
Interviewers look at your commit history. Fifty commits with messages like 'update,' 'bug fix,' 'more stuff' signal someone who does not think about communication. Ten commits with messages like 'add user authentication' and 'refactor database queries to reduce N+1 calls' signal someone who thinks about how other people will understand their code. Spend two minutes writing a decent commit message. The first line is what changed. The next paragraph is why. This is how production code is written.
The second thing interviewers ask is 'what would you do differently.' If you can credibly answer 'I would add error handling here, refactor this database call, and write tests for the authentication logic,' you are showing judgment. If you say 'it is fine as it is,' you are showing you do not evaluate your own work. The strongest portfolio pieces are ones you can criticize intelligently. This signals maturity.
Frequently asked questions
How much time should I spend on algorithms before I start building projects?
Six to eight weeks of consistent practice, then begin projects while continuing lighter algorithm work. You need to understand the foundational structures (arrays, hashes, strings, lists) thoroughly before you build because they are screenable and because you will hit them in production code. But you can learn more about algorithms while also building, rather than treating it as a prerequisite gate.
Is it better to learn one language deeply or two languages more broadly for interviews?
One language deeply, without question. Master one to the point where you think in it, then add a second if the role requires it. Interviewers probe depth with follow-up questions, and shallow knowledge on two languages is weaker than solid knowledge on one. All languages teach the same algorithmic patterns; the syntax differences matter far less than you think.
How should I prepare for questions about past projects in interviews?
Write a one-minute explanation of what each project does and why you built it. Write a three-minute walkthrough of the technical challenges you faced and how you solved them. Interviewers will ask about scaling decisions, error cases, and why you chose specific tools. Be ready to explain those choices, not just describe what you built.
What should I do if I get a live coding question and I do not know the optimal solution?
Start with a brute-force approach and narrate why it works but has tradeoffs. Ask the interviewer if you should optimize or if the tradeoff is acceptable for their use case. Write clean, readable code. Do not freeze. A suboptimal solution that works and is explained clearly scores better than silence followed by a rushed perfect answer.
How many projects is enough for a portfolio to apply for jobs?
Two solid projects — one with backend complexity and deployment, one that solves a real problem you have — are sufficient. Quality beats quantity. A portfolio of five abandoned projects signals starting skills. A portfolio of two projects you can walk through in detail signals hiring-ready judgment.