First Tech Job,completely Overwhelmed

So I just started my first job and I feel overwhelmed over how to go about the business arquitecture and There{s a lot of stuff I’ve never seen before,So I’m typing too many questions to ask my Tech Lead, but the thing is, I work hard, but sometimes I don’t know what questions to ask which ones are the ones that I’m supposed to look up and which ones SHOULD be asked, It’s taking me quite a while to understand some topics, and it’s overwhelming the fact that they are A LOT, like a lot.

the company trained me in Java/Spring and tbh the training went really fast so fast that I couldn’t have the time to practice enough, only through the code alongs, is this normal? I mean have done several “code-alongs” and can understand the main topics about IoC /Dependency Injection but I’ve never been in an Production environment/real world environment.

What is the regular expectation from a Junior dev once he’s starting?

2 Likes

Keep talking to your tech lead. Keep communicating.

But yeah, that first job is rough. There is A LOT of stuff to learn, stuff that we don’t normally learn in our studies.

What is the regular expectation from a Junior dev once he’s starting?

That depends. Some places will expect them to hit the ground running. Some places will know that it will take months to get up to speed.

I wouldn’t worry about what is “normal” - there is a wide range of experiences. I would focus on where you are. I would talk to the tech lead, your manager, etc. There are the best gauge if you are meeting their expectations. Don’t be afraid to ask your tech lead for advice on the things on which you need to work. Communicate. The only things worse than a team member that is struggling is one that is struggling but not reaching out for help when they need it.

Keep in mind that it is the companies job to determine if you are a good fit. Assuming that you didn’t outright lie in the interview (other than the typical puffery) then it is their responsibility.

But I do know people that got hired into terrible places, places that hired them for a job for which they weren’t qualified and they had a miserable time. Some of them quit and find another job. Some of them tough it out to gain the experience. Some of them get let go and go on to get another job - some experience is better than none.

Communicate, work hard, keep learning.

6 Likes

I would like to congratulate you on your first job! That’s a great achievement. Don’t get too worried on things that are not making sense at the moment. Ask questions and show your tech lead the approaches you have taken to resolve the problems. Just make sure you keep working hard because at some point all your hard work will pay off. Also, avoid focusing on too many things but rather break your bigger problems into smaller set of problems and deal with them one at a time. Also, always be optimistic and believe in the little value that you are adding. Wishing you all the best!

3 Likes

Congratulations on your first development job!

Starting a new software job is extremely difficult and overwhelming. This is true for any job change as a developer, but especially stressful and frightening when you’re new to the experience. I like to tell people that they should expect to feel completely useless for at least the first 100 days. I’ve been told that most companies don’t expect the investment of hiring, training, and paying a new developer to start paying off for 6-12 months. You’ve been dropped in the middle of a fairly alien environment and it’s going to take a while to even start feeling like you know what’s going on. Be kind to yourself.

One of the difficult things about being on a development team is being able to judge when you’ve spent enough work figuring something out yourself and when you should ask for help. Effectively asking for help is another skill that a lot of developers struggle with. Your team/mentor isn’t going to be upset that you ask too many questions, but they may occasionally push back for you to spend some more time investigating the problem and getting to know it. Struggling is where a lot of learning happens. Even if you do get stuck, having fought with the problem for a while usually means that you can ask better questions and that you are more likely to understand the answer. On the other hand, some questions can save you tons of time to ask quickly. “Can you tell me where to look for ____?”, “Is there internal documentation for this?”, “What is the ____ that I see referenced all over the code?” Talk to your coworkers. You’ll get to know their style, how much they mind being interrupted, and what their areas of expertise are.

That you’re learning. That you have core language competency but don’t know the codebase yet. That you’ll figure some stuff out on your own but also let people know when you get stuck. That you ask good questions. That you keep learning.

2 Likes

@dryo, just to be clear, how long have you been on this job at this point?

This is my third week, and my first sprint.

Yeah it took months on my first job before I even began to feel like I knew what was going on.

3 Likes

If it’s business specific just ask, if it’s general programming where you can find the answer on stack overflow or in the documentation then spend some time trying to figure it out yourself, but if you’re spending inordinate amounts of time trying to figure it out and getting nowhere then ask - be as specific as possible in the question and communicate what you did to try to solve it and what the result was compared to what you expected - that helps to troubleshoot the problem and shows you’ve already made the effort to solve the problem yourself before asking

1 Like

I don’t even have an specific task to work on,tbh I have no clue, still, what is expected of me, the way that my collegue is working, is completely alien to me, yet they keep asking me what am I gonna be working through the day, this is bananas to me, coming from manufacturing, not having an specific task and delivery date or being asked one thing when there is no clarification on what is is expected or delivered is just a big red flag.

“just help this guy…” I mean, the guy that I work with has 9 years of experience,he’s cool don’t get me wrong, but I’m in the dark right now, I can’t even help him in any way because I don’t really understand how to find certain stuff or even some methods I have no Idea how are they being declared what dependencies work with what,yet this guy, somehow managed to understand and run a sample program with a couple of examples from internal builds in a matter of days,flying through internal repos and documentation like friggin skynet, while I’m drooling in 20 question hell, feel like it would take me a month to even start removing or adding pre existing code(there’re proprietary dependencies that need to be used).

The system that we’re working in on is so complex and has soooo many ambiguities that even the most senior engineers find it hard grasp on certain acronyms, I feel like if this keeps going on, my tech lead is gonna be like “well this guy’s a dead weight” and expect being back at the bench by the end of november, this has absolutely zero ROI on me being in this project.

That’s different to how I work, I have a schedule of work, set tasks for the day for which estimates have been previously written…

If they’re not assigning you anything specific or you’re confused by the workflow then definitely communicate that… You need to properly pin down what the expectations / tasks are

1 Like

Step back from the ledge. It sounds like you’re freaking yourself out.

It sounds like you need to have a conversation with your manager or mentor and talk about how you don’t understand the expectations. That’s the sort of conversation that is intimidating AF to start, but usually goes pretty well. Your teammates want you to feel comfortable as a fully integrated part of the team. They do not expect you to have the same knowledge or experience that they do. Stop worrying about comparing yourself to them and focus on how best to work with them.

That’s fine. If this senior person is happy to work with you, then just sit with them as they work and ask questions. This should serve to help you get more comfortable with the code base, but it is also helpful to the senior dev. Some of those questions will be good questions that they forgot to consider.

That’s, unfortunately, very common. Codebases get weird and twisty and some parts were built by someone who left the company and took all their context with them.

This rarely happens. The fact of the matter is that hiring someone is difficult and expensive, and it’s expected that a new entry-level developer will need a lot of hand-holding for several months.

If you shut down, give up on the process, and don’t engage… that’s where you’re going to find yourself in trouble with your team.


I understand that you're feeling overwhelmed and intimidated. That's just sort of... how this goes. It's fine. You're fine. Keep learning. Stay interested. Stay engaged.
4 Likes

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.