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.

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.

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.

R.E.L.A.X.

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.

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

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.

I'm currently in the exact same boat as you, except I'm in a different field now, requalifying from software/game development to system engineering (devops etc). Same as you, long commutes (1h30m times 2), teamlead a few meters away, etc.

However, I've been in the more "manager" position before and I have experience handling such situation, as I know what both sides want and both sides need to do to achieve their goals.

The best advice I can give: be as communicable as you can. Ask everything (to an extent), talk to everyone a lot, don't say dumb things or jokes, communicate almost exclusively about work. Try to make everyone around you get to know you a bit. And especially your management (PM and whoever mentors you).

This is it. Lots of communication will give you a huge boost in performance as people will be hinting you what to do and you won't feel lost and hopeless constantly. Also it will present you as an approachable employee. Even if your performance will not satisfy them, they'll much more likely to discuss it with you directly, and if that happens you may ask for a different position within their company.

Presenting yourself as an approachable and highly communicable person is key.

As for commutes and what not, I'd stick with your current position for at least a year. If you quit after a year it won't look too bad in your CV and you'll be able to justify it with environmental variables such as long commute time, bad work/life balance, etc. While at the same time having enough experience to jump into a new workplace.

Good luck.

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!

You asked a few questions,

Are there any indications or warning signs of junior developers being let go after 2-4 weeks?

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.