I graduated from IIT Jodhpur in 2023 and joined the industry with reasonable confidence. I’d done competitive programming, built some side projects, knew my data structures. I thought I was prepared.
I was not prepared.
Here are the seven things that actually got me — not hypothetically, not “things I read about” — things I personally got wrong in my first year.
1. Pretending to understand when I didn’t
The worst habit I developed early: nodding along in meetings when I had no idea what was being discussed. I thought asking questions signaled weakness. I thought looking confused was a career risk.
What actually happened: I’d leave meetings with vague action items, misunderstand them, and deliver the wrong thing. That’s the actual career risk — silent confusion that surfaces as bad output two weeks later.
The fix was embarrassingly simple: “Can you explain that again? I want to make sure I’m getting it right.” Senior engineers don’t find this annoying. They find the alternative — confidently building the wrong thing — much more annoying.
2. Disappearing when stuck
When I got blocked, I’d disappear into my laptop for hours trying to figure it out alone. Independent problem-solving felt virtuous. Asking for help felt like admitting failure.
What I didn’t understand: your time is not just your resource. When you’re blocked on a task, you’re also blocking everyone downstream. A 10-minute conversation that unsticks you is worth 6 hours of solo spinning.
If you’re stuck for more than 45 minutes and not making progress, ask. Not for someone to solve it for you — for a nudge in the right direction.
3. Over-engineering my first real tasks
Early on, I was given a small feature: add a new filter to an existing API endpoint. I built a generic filtering framework that could handle arbitrary filter combinations, was configurable via JSON, and “could scale to any future requirements.”
It took three times as long as expected. The reviewer asked me to replace it with a simpler implementation. I learned: the right solution for a small, specific problem is a small, specific solution. Generality you don’t need is complexity you do have to maintain.
4. Not writing things down
I had a good memory. I thought that was enough. It was not.
Requirements discussed in a Slack thread, clarifications from a standup, architectural decisions from a whiteboard session — all of this lived only in my head. Then I’d misremember a detail. Or the context would change. Or I’d be asked to document a decision I’d made three months ago and had to reconstruct from code.
Write down decisions, their context, and their alternatives. Even a one-paragraph comment in the code is worth more than relying on memory.
5. Treating code review as a verdict
I’d send a PR and wait anxiously for a “looks good” or a list of changes. Comments felt like criticism of me, not my code. This made me defensive, which made the review process awkward, which made my reviewers less thorough over time.
Code review is a conversation. Comments are questions. “Why did you do this?” is not an accusation — it’s someone trying to understand your reasoning, and often an invitation to explain why your approach was correct.
6. Measuring myself by output, not by learning
In my first year I was obsessed with shipping. How many tickets did I close this sprint? How many PRs did I merge? I’d feel good on high-output weeks and anxious on low-output weeks.
What I was missing: the weeks I spent understanding a complex part of the codebase, debugging something confusing, or pairing with a senior engineer weren’t “low output” weeks — they were the weeks that made all future output faster.
Measure yourself by what you understand at the end of each month, not just what you shipped.
7. Waiting for someone to hand me direction
The biggest one. I expected someone to always tell me what to work on next, what I should be learning, where I should focus. When that didn’t happen, I’d feel adrift.
Nobody is managing your career for you. Identify the gaps in your knowledge. Find the problems in your codebase that nobody owns. Ask your tech lead what the team struggles with. Go find the work.
The engineers who grow fastest aren’t the ones who execute assigned tasks well. They’re the ones who notice what’s missing and go fix it — even when nobody asked.
Three years in, most of these are now habits that run in the background. Not perfectly — I still disappear into a problem for too long sometimes, still catch myself nodding when I should be asking. But I catch it faster.
If you’re in your first job right now: you’re going to make all of these mistakes regardless. The goal is to shorten the feedback loop.