Feeling like a fraud in your first developer job is normal and usually a sign you have moved into a room where learning is expected. Separate feelings from evidence, keep a record of what you ship, ask better questions early, and give yourself a realistic ramp-up of three to six months before judging yourself.
What people tell me
I finally got my first software job after a long search, and instead of feeling happy I feel like I tricked everyone. The codebase is huge, people use words I do not know, and every task takes me much longer than I expected. I keep waiting for someone to realise they made a mistake hiring me. I stay late trying to catch up, I avoid asking questions so nobody notices how little I know, and every small piece of feedback feels like proof that I do not belong.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Imposter syndrome in a first job is common. It usually means the environment is new, not that you are unqualified.
- Nobody expects a new hire to be productive in week one. A realistic ramp-up is three to six months.
- Judge yourself on evidence you can write down, such as tasks shipped and questions answered, not on how you feel on a given afternoon.
- Hiding confusion makes it worse. Asking good questions early is what trusted juniors do.
- Compare yourself with your own first month, not with a senior who has spent years in this codebase.
Why the feeling shows up exactly now
You spent months proving you were good enough to be hired. Then you got hired, and the proof stopped. Now you are in a codebase that took other people years to build, surrounded by colleagues who know its history, and every day reminds you of what you do not know yet.
That gap is real. What is not real is the conclusion your brain draws from it. "I do not know this yet" quietly becomes "I should not be here". Those are different statements, and most of the work of getting past imposter syndrome is keeping them apart.
In my experience mentoring people through their first year, almost everyone describes some version of this. The ones who struggle most are not the weakest engineers. They are the ones who try to hide the gap instead of closing it.
What your team actually expects from a new hire
It helps to know what is normal. Roughly, this is how a healthy first six months looks for a junior engineer:
| Period | What is reasonable | What nobody expects |
|---|---|---|
| Weeks 1 to 2 | Set up the environment, read code, fix a tiny bug or copy change | Shipping a feature alone |
| Weeks 3 to 8 | Small tickets with help, first code reviews, learning the deploy process | Knowing why every past decision was made |
| Months 3 to 4 | Medium tickets, fewer questions about tooling, more about design | Owning a system end to end |
| Months 5 to 6 | Picking up work with light guidance, reviewing others' small changes | Being as fast as someone with years on the team |
If you are somewhere on this table, you are on track. If you feel behind it, that is a conversation to have with your manager, not a verdict to reach alone at midnight.
Separate feelings from evidence
Imposter syndrome runs on vague feelings. The cure is specific evidence. Start a simple file today called something like "work log" and add to it every day:
- What I worked on.
- What I got stuck on and how it got unstuck.
- One thing I understand now that I did not yesterday.
After two weeks you will have a record that argues back. On a bad day, when your brain says "you have done nothing", you can open the file and see twelve closed tickets, three things you learned about the deploy pipeline and a bug you found that someone else had missed.
This log also makes your one-to-ones with your manager much better, because you arrive with facts instead of a general sense of dread.
Stop hiding the gap
The instinct to stay quiet so nobody notices is the most expensive mistake a new engineer makes. When you hide confusion, three things happen: you take three times longer, your work arrives with surprises, and your team gets less signal about how you are doing. Ironically, that is what makes people worry.
Asking well is a skill, and it is learnable. A good question has a shape:
- What I am trying to do.
- What I have already tried, and what happened.
- My current guess, and the specific thing I am unsure about.
Julia Evans' guide to asking good questions is worth fifteen minutes. For the workplace version of this, see How do I ask for help at work without making people think I am incompetent?.
A practical rule: struggle alone for a fixed time, say 45 to 90 minutes depending on the task, then ask. Not before, and definitely not three days later.
Treat feedback as information, not a verdict
Code review comments on your first pull requests will feel personal. They are not. Seniors get review comments too; they just stopped reading them as judgements years ago. When you get feedback:
- Read it once and close it for ten minutes if it stings.
- Separate the comments into "style or convention", "bug" and "design".
- Fix them, and write the pattern into your log so you do not repeat it.
After a month you should see the same types of comment less often. That is progress you can measure.
A 30-day plan for the first month
| Week | Focus | Concrete actions |
|---|---|---|
| 1 | Orientation | Start the work log. Draw a rough diagram of the main services. List every term you do not know and look up five a day. |
| 2 | First contributions | Pick up the smallest tickets. Ask one well-shaped question a day. Read every review comment twice. |
| 3 | Patterns | Note which files you keep touching. Read the tests around them. Pair with someone for an hour if the team allows it. |
| 4 | Reflect | Review your log. Ask your manager: "What should I focus on next month?" Write down the answer. |
The free Your first tech job roadmap walks through these early months stage by stage, and the book The Missing README covers what nobody tells you in university about working on a real team.
Common mistakes that feed the feeling
- Working very late to catch up. Tired engineers make more mistakes, which feeds the story. Protect your sleep.
- Comparing yourself with the senior next to you. Compare with yourself four weeks ago.
- Refusing to say "I do not know". It is one of the most trusted sentences in engineering when followed by "I will find out".
- Treating every mistake as final. Most mistakes in a first job are cheap and expected. If you do break something, see what to do after a production mistake.
- Waiting for the feeling to disappear before acting. It fades after you act, not before.
A sentence to use when it gets loud
When the "fraud" thought appears, try saying this to yourself, and mean it: "I was hired to learn this codebase, not to already know it. What is the next small thing I can understand?" Then go and understand that one thing.
If you are still stuck
Two reads that help: Why do I feel stupid when I start working with engineers who are much better than me? and the blog post on what actually changes in your first two years as an engineer. If you would like someone to look at your specific team and situation, join Sefism. It is free to learn, you get credits when you join and your first roadmap is free. As a member you can ask your own question or book a 1:1 session with me.
Was this answer helpful?
Read next
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: sign up and your account is active shortly after. Prefer to talk? A free call works too.