Not one of them: a weighted mix that changes with your stage. Early on, lean on projects and fundamentals; closer to applying, shift time towards problem solving and networking. Open source is valuable but optional. Decide the split weekly and review it monthly against what is actually blocking you.
What people tell me
I am a student with limited free time. Some people say projects matter most, others say DSA is everything for getting hired, others say open source contributions stand out, and others say networking is how people actually get jobs. I keep switching between them and end up doing a little of each without making real progress in any.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Each activity solves a different problem. Pick based on what is blocking you now, not on who said it loudest.
- Projects show you can build; problem solving gets you through technical rounds; networking gets you seen.
- Open source is a strong bonus, not a requirement. Start with small, real contributions.
- Use a weekly split that shifts with your stage, and protect it from constant switching.
- Review monthly: if nobody sees your applications, network more; if you fail technical rounds, practise more.
Each one solves a different problem
The reason you hear conflicting advice is that each person is describing what worked for their particular bottleneck. These four activities do not compete for the same job. They each fix something different:
| Activity | What it proves or unlocks | Most useful when |
|---|---|---|
| Projects | You can build real things end to end | Your CV has little to show, or you are early in learning |
| Problem solving and DSA | You can think through problems under time pressure | You are getting technical rounds and struggling in them, or about to |
| Open source | You can work in someone else's codebase and collaborate | You already build confidently and want to stand out |
| Networking | People know you exist and can refer you | Applications are not getting replies |
Once you see it this way, the question becomes: what is my bottleneck right now?
A split that shifts with your stage
Here is a rough weekly split for someone with ten to twelve free hours a week. Adjust for your own time, but keep the proportions.
| Stage | Projects | Problem solving | Networking | Open source |
|---|---|---|---|---|
| Early (first year or two, still learning basics) | 60% | 30% | 10% | 0% |
| Middle (can build, preparing for internships) | 45% | 35% | 15% | 5% |
| Applying (final year or job hunting) | 30% | 40% | 25% | 5% |
Notice that networking grows as you get closer to applying, and projects shrink but never disappear.
Projects: depth over count
Two solid projects that work, with clean code and a clear README, are worth more than ten half-built tutorial clones. Build things that solve real problems, add them to your CV with live links, and keep improving one at a time rather than starting new ones constantly.
Problem solving: consistent, not heroic
A few problems a day, several days a week, beats a weekend binge. Focus on recognising patterns rather than memorising solutions. Learning the common problem shapes and the approach each one calls for is far more useful than your total count.
Open source: optional, but valuable done properly
Open source contributions stand out because they show you can read unfamiliar code, follow a project's conventions and work with maintainers. But they are not required, and trying them too early can be demoralising.
Start small:
- Use a library you already know.
- Fix a documentation error or improve an example.
- Pick a small issue marked for beginners.
- Read the contribution guidelines before starting.
One real, merged contribution is a good story. A dozen trivial ones are not worth much.
Networking: not what most people think
Networking is not collecting connections or sending "please refer me" to strangers. It is being visible and helpful to people in your field. For students, that usually looks like:
- Sharing what you are building and learning, briefly and honestly.
- Commenting thoughtfully on engineers' posts.
- Attending local meetups, university events or online communities.
- Keeping in touch with seniors, alumni and people you met at internships.
When you do eventually ask for a referral, it lands much better if the person has seen your work before.
Stop switching every few days
The biggest waste is not choosing the wrong activity. It is switching every two days because someone posted a strong opinion. Decide your split on Sunday, follow it for the week, and only change it at a monthly review.
Review monthly with evidence
Once a month, ask:
- Am I finishing projects, or just starting them?
- Are my problem-solving sessions getting easier?
- When I apply, am I getting replies? Am I passing technical rounds?
If nobody replies to your applications, shift time to networking and your CV. If you get rounds but fail them, shift time to problem solving. Let the evidence decide, not the loudest advice online.
An example of a week, done properly
For a student in the middle stage with about ten hours a week, a realistic week might look like this:
| Day | Time | Activity |
|---|---|---|
| Monday | 1.5 hours | Project: finish the search feature |
| Tuesday | 1 hour | Problem solving: two array problems, focusing on the pattern |
| Wednesday | 1.5 hours | Project: write tests for the search feature |
| Thursday | 1 hour | Problem solving: one hashing problem, review a solved one |
| Friday | 45 minutes | Networking: short post about what you built, comment on two engineers' posts |
| Saturday | 2.5 hours | Project: deploy and write the README |
| Sunday | 1 hour | Problem solving review, plan next week |
Nothing heroic. It is repeatable, and after three months it adds up to a finished project, steady problem-solving progress and a small but real presence online.
A message that turns networking into a real connection
Instead of a cold referral request, start with something genuine:
Hi, I read your post about moving your team's jobs to a queue. I am building a small booking system as a student project and ran into a similar issue with slow email sending. I ended up using a simple background worker. Would you have done it differently? No pressure to reply, I just found your post useful.
It is specific, it shows your work, and it asks for nothing big. A few of these over a term build more goodwill than a hundred connection requests.
If you are still stuck
Read Fifteen Problem Shapes and the Move That Solves Each, LinkedIn for Engineers: What Actually Works and GitHub Repositories Worth More Than a Star.
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
- Fifteen Problem Shapes and the Move That Solves EachThe usual way to learn algorithms is to work through a long list of problems and hope something generalises, which leaves most people with a hundred solutions memorised and no idea what to do with the hundred and first. There are perhaps a dozen shapes of problem, each with a move that usually works. Fifteen of those shapes and how to recognise them.
- LinkedIn for Engineers: What Actually Works, and What Is FolkloreLists of LinkedIn cheat codes mix sound advice with statistics nobody can source. This is one of those lists, checked against what LinkedIn has said about its rebuilt feed and what large studies found: how to set up a profile that works, write posts people stop for, pick formats and timing, and which popular tips are simply wrong.
- GitHub Repositories Worth More Than a StarEveryone has forty starred repositories and has opened three of them. Twenty three worth keeping, grouped by what each is actually for: system design, things to build from, things to practise against, computer science foundations and things to look up, each with a note on how to use it properly and the three habits that decide whether any of it turns into learning.
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.