It’s my third day at this job as a full stack engineer. I graduated five years ago, but I never took programming that serious until after the first year when I decided to start looking for a job.

It was hard getting this job. I had previously been on six in person interviews which all ended in rejection and countless other rejections for job applications and through phone screenings.

Every time I would get a rejection, I might spend 2-3 months studying looking to build up courage to apply again. While I was getting better, this would inevitably lead to me getting burned out over and over again.

Eventually I landed a job as a full stack developer, despite having never worked with many of their tools or their current backend framework.

They have a very large code base and everyone else has at least five plus years of professional experience. While I am excited, every day feels like a struggle. It’s a small team so I'm literally a few feet away from my PM and the three other seniors, so everything is noticed.

In addition, my commute is very long. I would try to study at home, but I’m on edge by the end of the first two days. I’m worried if I don’t get up to speed fast that I will be let go.

Are there any indications or warning signs of junior developers being let go after 2-4 weeks? And is this common practice?

  • 61
    Your question is exclusively focusing on your point of view, and nearly exclusively focused on what happened before you go this job. What are your employer's expectations? What work are you being given, and what are you expected to do with it? What feedback channels do you have, to tell how they think you're doing? What feedback are you receiving? – dwizum Jan 23 at 14:12
  • 21
    Not really relevant to the actual question, but are you saying you were waiting two or three months in between job applications?! Being rejected from 6-ish face to face interviews isn't unreasonable for someone without much work experience, but waiting that long between applications is unimaginable, to me. In the unfortunate event that you do find yourself looking for something new, try not to take the "no"s so seriously. Just because a company rejects you doesn't mean they think you're a bad choice - it just means they found someone else they liked better. Nothing personal, yeah? – Steve-O Jan 23 at 14:47
  • 83
    This is not a workplace question. You're asking us to assuage your fears, and we can't possibly do that. Not to mention that you've only been on the job for 3 days. Show up on time, work hard, ask for help when you don't know something, and carry on. Good luck. – AndreiROM Jan 23 at 15:56
  • 5
    @JoeStrazzere A 2 hour commute isn't much? When I hear "commute", I typically think "one-way", as in a 2 hour commute would actually be 4 hours (There and back) - Do people really do that? x.x - I can't imagine my total commuting time to be half of my work day – GrumpyCrouton Jan 23 at 19:59
  • 2
    @Kevin: Surely that is impostor syndrome? The OP has been hired as a junior dev and doesn't think that they are actually good enough to be in that role. The entire question seems to be about the OP fearing that their employer shouldn't have hired them and will rectify that mistake. The fact they were hired for the roles suggests they in fact are good enough to be in that role. The fact that they are a beginner and thus probably not as competent and skilled as somebody with more experience doesn't mean that its not imposter syndrome. – Chris Jan 24 at 11:05

11 Answers 11


I think it would be extremely rare (e.g. almost never) to let anyone go after 2-4 weeks (for performance related things), and rarer still for that to happen to a junior developer, so take a deep breath and relax. Now let's figure out how to "get up to speed" and begin to feel a bit better about your position.

They hired you after looking at your resume and interviewing you, so they are aware of exactly what you know, exactly how much experience you have. They don't expect you to know everything, they don't expect your work to be mistake free, and they don't expect you to be as productive as their senior developers.

What they did hire you for is your potential, for what you will eventually be able to produce for them. So you should start thinking about how to develop and execute a plan so you can start achieving your potential.

The first and most important thing to realize is that it is your manager's job to do his/her best to give you the opportunities to succeed - this can only happen if you two have regular and frequent conversations, and if during those conversations you are open and honest about where you are having difficulties, where you need support, where you are getting stuck, and where you learn what he/she is expecting from you.

I'd start by approaching your manager today and ask to schedule a weekly, half-hour meeting (assuming you don't already have something similar set up). Say something like "I believe the best way I can be successful working for you is if we can sync up on a regular basis, can we schedule a weekly meeting?".

At the first meeting, you should be very enthusiastic about working there and express how excited you are to begin making an impact. At that same meeting, it is important, though, that you ask (and get answers to) the following questions "what is expected of me (goals) over the next few months?", "what (tools/techniques/systems, etc.) do I need to learn to start accomplishing those goals?", "is there any formal training for learning those things?", "who are the resource at the firm who will help me learn those things?".

It is your manager's job to answer those questions, and to make sure you know what you need to do, how you are going to learn what you need to learn, who is there to help you, etc.

The most important thing to remember is that you shouldn't be afraid to ask your manager, or anyone formally or informally tasked to help you, or most other people as well, for guidance, advise or help. Remember, no one is born knowing how to program, or how source control works, or anything. So after spending a reasonable amount of time trying to figure something out, do not be embarrassed to ask for help.

  • 30
    Good point - If you fire someone after a year, it looks like they made a mistake. If you fire someone after a few weeks, it looks like you made a mistake. – ItWasLikeThatWhenIGotHere Jan 23 at 16:59
  • 2
    I think this is a good answer but I'd advise against a one hour meeting, it's a really long time to talk about this. – IEatBagels Jan 23 at 21:01
  • 2
    Not to feed into the OPs fears but at least where I am from (midwest US) the first 90 days of a professional job is almost always considered a "performance period". This means that you will have regular performance check-ins with the manager, your benefits usually don't fully kick in yet and you can be let go much more easily than any other time during your tenure. In my experience, that beginning period is when you are most likely to be shown the door. I've seen it happen to underperformers more than a few times. – DanK Jan 23 at 21:11
  • 3
    @DanK Over the last 35 years I have had eight (I think) jobs in England, Germany, and Switzerland. All of them have had an initial probation period where I could be fired much more easily. It is really, really rare for that to be made use of; in fact I think I have only seen it happen twice - and in both cases it was social issues rather than technical ability (a PA who didn't get on with her boss and a developer who couldn't cooperate with others). – Martin Bonner Jan 24 at 13:07
  • 5
    @Fattie, Bad advice. The OP needs to be able to ask for help. Work is not like stackoverflow and he should not be discouraged from getting help when he needs it. Professional software engineers that are competent, well-rounded human beings in organizations that are not dysfunctional are excellent at helping new people get up to speed and give their time generously. – teego1967 Jan 24 at 18:50

Are there any indications or warning signs of junior developers being let go after 2-4 weeks. And is this common practice.

There's nothing in your story which makes me think so. Of course, what happened before you landed this job, or how long your commute is is irrelevant for letting you go. If they let people go after such a period, it usually because such a person is either completely different than expected (claims to be an expert in language X with Y years of experience, but can't even code "hello world"), or shows unacceptable behaviour (harasses coworkers, doesn't show up, steals office supplies, etc).

As for struggling, trust me, many people have that. And sometimes, it never passes. 15 years ago, I joined a company where most of my direct coworkers had worked for that company 30+ years. After 2.5 years, when I left, I was still the most junior person. And at my current company, there's code I've been working on for more than 10 years, and while I'm wildly regarded as "the expert" on it, there are pieces of it which are still magical to me, and I struggle when I have to work on those pieces.

And treasure the "being noticed" part. Ask for help if you are struggling. You are part of a team. I have people seen let go (but not after 2-4 weeks, after a much longer period, typically a year or longer) who keep struggling, but keep quiet.

  • 5
    I just want to emphasize that last paragraph. Constitutionally, I'm the sort of person who works things out myself. It's how I learned to code. But learning to be part of a team and ask questions is a critical part of a technologist's toolset. There are no prizes for figuring out by yourself in a year, what would have taken 5 minutes to ask someone about. – rob Jan 23 at 19:47
  • 6
    When my former mentor—the most senior developer—was quitting his job after having mentored me when I started, he told me that what set me apart from many other juniors was my willingness to ask questions—often and early. He told me to keep that up, and while I no longer work for that company, and I tend to be considered a senior developer directly upon hire now, I still ask questions of my colleagues—often and early—when there's something I don't understand or can't figure out. And I've received nothing but praise for doing so. – Alex Jan 24 at 4:07
  • claims to be an expert in language X with Y years of experience, but can't even code "hello world" - I would hope that something like that would be found as part of the interview process. If they hired a programmer who can't even do that, clearly they weren't too thorough in their technical assessment process to say the least. I guess that kind of thing has been known to happen, though. – EJoshuaS Jan 24 at 20:31

If you were a consultant, then yes, it happens, as you're expected to know your stuff coming in the door.

If you're an employee, they just invested a boatload of money hiring you with the HR paperwork alone. Add to this the entire onboarding process, meeting with coworkers, and learning the systems, there is a good deal of leeway.

It always feels like a struggle when you encounter new things, but that doesn't mean you don't have what it takes. If you can build good relationships with your coworkers, you have even less to worry about.

We hired someone who was less skilled than we thought. We upskilled him. I had no problem doing this because he was eager, and showed progress, and continued to improve.

You sound eager to learn, express that eagerness, and they will in all likelihood take the same approach when you're having difficulties.

Get into a cycle of asking questions, working on things on your own, and following up.

I think I've got this, but would you mind checking if for me, I could use a second pair of eyes

Show a combination of eagerness, collaborative attitude, and deference, and you'll do fine.

The one thing that most people care about is not where you start, but that you learn and grow. If you can demonstrate this, you don't need to worry.

  • 2
    To add to that on the flipside, I've worked with people who've been fired or were the top picks for redundancy. The reason wasn't that they were inherently less smart - one had a PhD! It was because in spite of all the mentoring, they kept making the same mistakes and never seemed to learn. And more than that, they didn't seem to care that they weren't improving. Simply starting out a little green though - we expect that when we hire junior people, and we plan for training and mentoring. – Graham Jan 24 at 9:07
  • @Graham Thanks, I'll edit to reflect that. Good points! – Retired Codger Jan 24 at 14:19
  • It;'s an outstanding point to separate the demands of being a real programmer (a contractor :) ) from the far lesser demands made on employees and other intern-like positions. :) Joking aside, it's an excellent point – Fattie Jan 24 at 14:26
  • "Show a combination of eagerness, collaborative attitude, and deference" Really this is hugely correct and probably the most actually useful thing here for the OP. Those three things are EXACTLY how you can put over having to ask a question. – Fattie Jan 24 at 14:27
  • 1
    @RichardU Hell yes - attitude is key. Another person I turned down at interview, she sounded keen and was a lovely person, but she'd only recently retrained and had no experience in industry. I told her to find herself a project, some Linux thing or Arduino or RasPi or whatever, go away and work on it for 6 months, and then come back and show us. Basically, demonstrate enthusiasm for the kind of job she wanted. Sadly she never did, but if she had, I would certainly have hired her. – Graham Jan 24 at 15:00


You were just hired for your first development job. There will be a huge learning curve. Companies that hire for these positions understand that you will need time to get up to speed on their code-base and the tools they use. You were hired so they believe you have what it takes to learn the job.

Successful people in software know that they need to keep advancing their skills. They depend on other more experienced developers to further their own career. In my new position (started right before Christmas) I have some development & architecture tasks. This new company has several your developers who sound a lot like you. Another part of my job is to act as a mentor for the younger developers. One of the goals on my development plan is for the progress of the youngsters.

If you don't know something then ask. Ask to have your code reviewed and sit on on others code reviews.

Good luck.


There are great answers here already.

All I want to say is that I have seven years experience in the same field and every time I change jobs, I feel similarly to what you're feeling. In my experience, it takes me 1-2 years on the job to feel confident and comfortable. So here's what I think to myself to reduce stress:

1) I keep in mind that it's REALLY expensive to hire someone. They likely just paid 20-50k just to hire you. Unless you've done something terrible (for example, dropped a production database, exhibited behavior that can be interpreted as corporate espionage, etc.), no one wants to part with money like that, not right away at least. It makes everyone who just hired you look very bad.

2) To interview someone else, busy people would have to fit that into their schedule. People have deadlines, families, hobbies, so no one is looking to fire anyone who just started.

3) Keep these tips in mind and you'll be fine:

  1. Don't ask someone stuff that shows up in the first page of Google results. All tools, languages, etc. will have some documentation online. Make bookmarks and search Stack Overflow. Do not ask until you gather enough lingo/understanding to sound intelligent when asking, and show that you tried to resolve yourself. It's OK to ask for help; just make sure you do your homework FIRST. I find that if after 20 minutes of Googling I still have no leads and no ideas, it's time to ask - unless you're supposed to be the expert which is a different story. Obviously, things that are specific to the company are OK to ask (once).

  2. Learn who is who right away. I like to create a doc with names + seating location + what they do as I meet people. This makes it easier to know whom to ask which questions, and what to expect from people in general.

  3. If in doubt, ask. A great line is: "Hey, I was thinking to do X because Y and Z. What do you think?". This will save you and team time. Reference the document you made to find the right person.

  4. Do not violate spoken and unspoken office/team rules in the beginning. Is everyone showing up at 9:30, but no one told you you had to? Start showing up at 9:30 until you get the lay of the land, then re-assess. Did you just get shot with a nerf gun by the CEO? Grab one and shoot back, even if you feel like a deer in car lights.

  5. Is someone wearing headphones? Message/email them and wait for an answer, even if they are sitting next to you. Being in the zone is a real thing - learn to respect it. This doesn't hold for emergencies.

  6. Project confidence. It's the hardest thing when you don't know everything. If you can master projecting confidence while NOT getting caught being wrong in a highly technical field, the world is your oyster. My trick here is saying as little as possible, being as vague as possible, then looking it up if I don't know something I think I am expected to know. It's also OK to say you don't know something; just don't make it a habit.

  7. Know when to leave: did your CTO/CEO/Founder just quit after the company released some stats and you're observing the best talent bail? Food for thought. But consider that if you've been there enough, and your higherups are leaving, you might want to stick around in case of a promotion. Titles look good in the resume.

If you follow those rules above, you are very unlikely to be first on any list to fire anyone.

  • 4
    Do not expect this experience (of taking a year or two to get up to speed) to change anytime soon. I have been working in the field five times longer than you, and it still applies. – Martin Bonner Jan 24 at 13:11
  • 1
    This should go into a Wiki somewhere. This is good advice for anyone entering a new work environment – Retired Codger Jan 24 at 14:42


I think you're too focused on what you don't know. It sounds like you were hired under the assumption you are a junior level developer. As such, just take it easy. Do each assignment as best as you can and if you get stuck, don't be afraid to ask. Definitely try to do it on your own and show that you tried.

As far as getting fired, I would say 2-4 weeks quite low. You'd have to be blatantly incompetent to get canned so soon. I'd expect someone should work completely on their own after 6 months or a year.


I'm an experienced developer and I get this too from time to time. New technology, know very little about it, thrown in at the deep end. I've learned to trust that with a bit of work I can figure it out and get on top of it.

Try to remember that none of this tech is magic, it's all stuff anyone can learn and master. Also don't be afraid to say to your PM that you think it might take you a bit of time to really learn the technology. As a junior developer they won't expect you to pick it up instantly or have all those skills already - if they wanted that they would have hired another senior dev.

This is a great opportunity for you to learn and get paid at the same time. Just remember that everyone feels this way and learning to not worry about it is a useful skill.


It's totally common to feel lost in your first couple of days on the job and to wonder how you'll ever get "up to speed" - even for senior developers. Don't feel bad about feeling that way.

The best advice I can offer is not to feel bad about asking for help when you need it. It's expected that new people on the project will have questions. It's not like you can just glance at the code base and figure it out.

Also keep in mind that if they were looking for a senior developer they presumably would've hired a senior developer. As others have pointed out, assuming that they read your resume and interviewed you well, they should have a pretty good idea of your current knowledge and experience level.


I've been worried about being fired at every new job that I had. (Much to my amazement, I never was. ;-)

In retrospect, I now realize that that worry resulted in trying very hard, and the management always noticed that. I understand now that was reassuring to them.

I was never afraid to ask for help, especially when I couldn't proceed without it. In most places, the best place to get that help was to ask other employees but never the management; in others, both were useful and so I split my questions between them as appropriate. (You have likely figured out by now whether your boss is a good person to ask.)

I also did research on my own time when necessary, if I didn't need to relax in order to be fresh, alert, and productive the next day.

You seem like a fellow that'll do just fine!


Here are your typical "warning signs":

  • Lack of communication. There are days when you don't have a meaningful work-related conversation with your colleagues for at least 5-10 minutes. You don't go (or are not invited) to meetings where everyone else in your role goes. It may be OK for a skilled developer to be autonomous and work several days in quasi-isolation, but it's certainly worrying for a junior.

  • You have to be micro-managed. The normal work process consists in your manager giving you a task, then you report on the progress, you ask questions when you are stuck with something, and you tell your manager when you're done and need a new assignment to work on. This often happens in a regular meeting, but can also be done informally. If your manager has to query you to realize that you have a problem, or have nothing to do at the moment, that's not good.

  • You don't understand what you're doing. It's OK not to know how to do something new, as long as you know where to learn about it, or have ideas you will try out. It's OK not to understand your assignment and clarify it right away. But if you routinely find yourself in a situation where you have an assignment and don't even know where to start, that's a warning sign.

  • Repeated negative feedback. It's usually normal to do something wrong for the first time. What is not OK is when you do the same mistake again and again and don't seem to learn. Even if the point itself is not extremely important, people may take your behaviour as a hint that you lack learning abilities, which is bad in itself, especially for a junior.


You asked a few questions,


You need to understand what feedback channels are in place in order to know what "warning signs" to look for. Some employers have regular one-on-one reviews, other times they might emphasize tracking defects, or they may only care about deadlines. Before you can look out for warning signs, you need to understand what methods your employer uses for feedback. If it hasn't been explained to you yet, it's perfectly reasonable to ask:

Hi Boss, I was wondering - what methods will you use to give me feedback on my work? How will I know if I'm on track according to your expectations?

And is this common practice?

No, generally, it is not common to let professional workers go so quickly after hiring them - this is what the hiring process is for - to weed out the people you wouldn't want working for you. Employers put effort into screening and interviewing candidates specifically to avoid the kind of hiring mistake that would lead to a termination after two weeks. All the cases I've personally been aware of where someone was let go this quickly were for extremely egregious offences (blatant violations of safety or security standards, criminal activities, etc.) Employers invest a lot in the hiring process, it's expensive and disruptive. If someone was just a little off track they'd usually prefer to guide and correct that person's behavior first, prior to letting them go.

Besides your questions, you also expressed some concerns:

I have never worked with many of their tools or their current backend framework.

Presumably, they knew this when they hired you, and they're accounting for a learning curve. If you're not sure, again - it's appropriate to ask.

They have a very large code base and everyone else has at least 5 years or more experience professionally.

This is great news - you have lots of experienced people around you to learn from! Again, they hired you with the understanding that you're less experienced. No one expects a junior dev (or junior anything) to walk in the door with a perfect understanding of their environment, already equipped with every possible skill required.

protected by mcknz Jan 24 at 20:35


Would you like to answer one of these unanswered questions instead?
