Be a generalist in fundamentals and a specialist in one direction. Spend most of your time going deep enough in one area to be hireable for it, while keeping the fundamentals broad. You can change direction later; you cannot get hired for being shallow at everything.
What people tell me
I am a computer science student. Some people tell me to pick one thing, like backend or machine learning, and go deep. Others say a student should try everything and stay flexible because the industry keeps changing. I have dabbled in web, a bit of Python for data and some Android, but I am not strong at any of them. I do not want to lock myself into the wrong thing.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- The useful shape is a T: broad fundamentals across the bar, one area deep enough to be hired for.
- Employers hire juniors for a specific role. "I know a bit of everything" rarely matches a listing.
- Specialising is not permanent. Your first specialisation is a starting point, not a life sentence.
- Pick a direction for six to nine months, go deep, then review with evidence rather than feelings.
- Fundamentals (data structures, networking, databases, Git, debugging) transfer to every path.
The question is slightly the wrong shape
Specialise or generalise sounds like a choice between two things. In practice, the engineers who do well early in their careers do both, just in different layers. People often call it a T shape: a broad horizontal bar of fundamentals, and one vertical bar where you go properly deep.
For a student, that looks like this:
| Layer | Breadth or depth | What it includes |
|---|---|---|
| Fundamentals | Broad | Data structures, algorithms basics, how the web works, databases, Git, Linux basics, debugging |
| One direction | Deep | For example backend with one language and framework, or Android, or data engineering |
| Everything else | Awareness | Enough to talk about it and know when it matters |
Why "a bit of everything" does not get you hired
When a company hires a junior engineer, it is almost always for a specific role: frontend developer, backend developer, mobile developer, data analyst. The person reading your application is asking one question: can this person be useful in this role within a few months?
Three half-finished tutorials in three areas does not answer that question well for any of them. One area with two solid projects, clear skills and working demos answers it clearly for one. That one is enough to start.
Specialising is not permanent
The fear underneath this question is usually that choosing wrongly will trap you. It will not. Most engineers I know are working in a different area from the one they started in. Someone who went deep on backend moves to cloud or data. Someone who started in mobile ends up in frontend or product engineering.
What transfers is not the framework. It is the experience of going deep: learning how to debug properly, how to read documentation, how to structure a real project, how a system behaves under load. Having done that once, the second area is much faster.
How to choose a direction without agonising
You do not need the perfect choice. You need a reasonable one you can commit to for a while. Try this:
- List the areas you have tried, even briefly.
- For each, answer honestly: did I enjoy the problems, or just the idea of them? Would I be happy debugging this at 6pm?
- Look at twenty real junior job listings where you want to work. Which areas appear most?
- Pick the area where your enjoyment and the market overlap best.
If two options are close, pick either. The difference between two reasonable choices is much smaller than the cost of not choosing.
Commit for a fixed period, then review
Give the direction six to nine months. During that time:
- Build two projects in it that you would be proud to show.
- Learn the fundamentals of that area properly, not just the framework.
- Keep your broad fundamentals going with a few hours a week.
At the end, review with evidence. Did you finish things? Did you enjoy the hard parts? Are you getting any interest when you apply? If yes, keep going. If not, you now have much better information to choose the next direction, and much of what you learned carries over.
When breadth genuinely helps
There are times when trying several things is the right move: in your first year, when you have no idea what you enjoy, a few short experiments are valuable. The mistake is staying in that exploring mode into your final year. By then, you want one area deep enough to put at the top of your CV.
A useful rule of thumb
Explore broadly in your first year or so. Choose a direction by the middle of your degree. Go deep until graduation. Keep your fundamentals broad throughout. It is not the only path, but it works for most people I talk to.
An example of how this plays out
Take two students with the same time and ability. The first spends two years sampling: a React course, a machine learning course, some Flutter, a little cloud. By final year, they have four certificates and no project that goes beyond a tutorial. On their CV, every section is thin.
The second explores for the first few months, then picks backend. They build an API with authentication, a database, tests and a deployment, then a second project that uses queues and caching. They keep their fundamentals up and do some frontend where their projects need it. By final year, they apply for backend roles with a clear story, and they can talk in depth about decisions they made.
The second student is not locked in. If they later move to cloud or data, much of what they learned about databases, deployments and debugging comes with them. The first student has to start almost from zero wherever they go.
A self-check for "am I deep enough?"
In your chosen area, can you honestly answer yes to these?
- I have built something beyond a tutorial and deployed it.
- I can explain why I chose my database, framework and structure.
- I have debugged a real problem where the answer was not on the first search result.
- I can read the official documentation instead of only video tutorials.
- I could hold a thirty-minute conversation with an engineer in this area without bluffing.
Three or more yeses means you are building real depth. Fewer means stay put and go deeper before adding anything new.
If you are still stuck
Read The Fundamentals Worth Learning as a Software Engineer and How to Start Your Career as a Software Engineer.
If you want someone to look at your specific situation, join Sefism and, as a member, book a 1:1 session. You can also browse the other career questions people have asked.
Was this answer helpful?
Read next
- How to Start Your Career as a Software EngineerA practical route into the first software engineering job: pick one language and stop shopping, build things too big for a tutorial, learn the five fundamentals you cannot skip, get your code in front of a human, and apply earlier than you feel ready. Includes a twelve month shape to work to and an honest read on what the current entry level market has changed.
- The Fundamentals Worth Learning as a Software EngineerFrameworks are the fastest moving and least valuable part of what you know. This is the layer underneath: how a computer runs your code, data structures as trade offs, complexity at conversational depth, storage, networks, concurrency, version control, testing as a design tool, and the two skills engineers skip that decide how far they get.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open to X and Instagram followers and university students. Prefer to talk? A free call works too.