I got fired after 2 weeks of being hired. Please help me understand something

> Or are those type of companies just unrealistic?

In Silicon Valley? There may be employment, but there are any number of people applying, and some of them are more productive than others.

Look on the bright side -- either they were wrong to fire you, in which case you're better off, or they were right to fire you, in which case you're better off.

> How do you guys deliver code/value fast on the first days without knowing their codebase at all?

Two weeks isn't the "first days," two days is. But don't agonize over this, just acquire more experience and be optimistic about your future.

It was probably just a bad fit. That happens, a lot. This goes both ways also. A good independent developer with a lot of demand will say no to clients more often than saying yes. Knowing which clients to say yes | no to is a gut feeling which comes with experience. Sometimes you make mistakes and still go with a bad client, and that goes both ways also. Sometimes the person doing the hiring makes a mistake. We are all learning, don't take it personally, just learn and move on.

I don't know your situation and if you were hired as an actual employee or as a contractor. Either way, one way to check for good fit is to freelance with the company for a trial period. If it works out, go full employee. If not, keep looking.

If you were a little lost, then maybe you need to beef up your skills a bit. For example, if the project is a big platform_x code base and you know platform_x really well, then it's easier to jump in and be productive right away. Or maybe it's a platform you know but in a domain you don't know well.

There is a lot which goes into productivity aside from just code. Communication is important. Adapting to the existing work-flow is important. Make sure that you adapt to everything rather than resisting things you might not agree with or don't think is important. It's easy to slack on something you feel isn't important when in fact that thing might be really important for your manager. As you get more comfortable and start knocking stuff out, you can suggest changes.

I'm sorry this happened, but we don't have a lot to go on. What other feedback did you get?

That's a shame. Probably, the problem is that they are idiots. Rule 1: never ever fire a person without speaking with the person first an let him know what is wrong, give them a chance to explain themselves or to change the way they behave.

Two weeks is a very small period to train a person unless they were expecting (or your mislead them without intent) you to be an expert in the technology or similar and work from day one.

Or maybe they have found "a friend" and they prefer to hire another people and they have simply told you a lie. You will never know so don't let this affect you.

Unrealistic company. Consider it experience and move on.

If they fired you within two weeks, they're most likely the problem, rather than you. I mean - if they expect you to be 100% productive within your first few weeks, they're in cloud-cuckoo-land. We allow a three month probationary period at 80% of full salary for us to mutually get to know each other and for the new starter to get up to speed - and then, and only then, do we assess performance. If it's bad - you're out, if it's good, you're in - but two weeks isn't a fair sample.

Out of interest, did you get the job through a recruiter? This is quite common for companies that hire through recruiters. I've worked in a few places where people have been sacked a week or two into the job because things aren't working out, because most recruitment contracts allow a get-out clause where the employer can claim back the fee they paid to the recruiter.

Unlike what everybody here is saying, it's entirely possible that you are the problem and not them. It's possible that they really meant you weren't getting up to speed quickly enough, not that they were expecting a significant positive output. It's possible that they gave you some beginner starter project that you ought to be able to finish in a day or two, to get you up to speed with the code base, but you took... 2 weeks. And maybe you didn't communicate enough with them to overcome your travails. Or maybe you did and they realized they shouldn't have hired you. You haven't given us enough information to really know, and since there isn't specific information about what happened, it's hard to recommend how to improve, other than, "get better at programming (in a sustained effort over the course of a week or two)."

I mean, clearly they don't fire everybody that they hire, so there's something other people are doing that you aren't. If you hire somebody and soon you realize that they're a complete FNG, it's annoying to keep them around for months just to achieve 99.99999% certainty.

That has to suck. The most healthy question at this point is "What makes the company's expectations seem reasonable to the company?"

A project manager in a small shop engaged in consulting where all programmer time is assigned to projects is unlikely to want a high overhead ratio staff member on their books. A company maintaining a big ball of mud doesn't gain much value from attempts to understand the codebase generally because the codebase is inherently incomprehensible. A manager in a giant corporation with keystroke monitoring wants to keep their boss off their back.

The second question is. "How could you have uncovered the explicit expectations earlier in your interactions with the company?"

Good luck.

  The second question is. "How could you have uncovered the explicit
  expectations earlier in your interactions with the company?"

> How do you guys deliver code/value fast on the first day

I haven't been a FTE in a while but here are some of the things I do as a consultant:

1. Ask for a simpler feature. On the first day you may be given a feature to work on. As you look at the code you'll get a sense of whether it's doable in the first day versus two weeks. If its too big ask for lower hanging fruit. This shows you really care about adding value from day one.

2. If 1 doesn't work ask someone to pair with you. It can be super awkward if you're not used to it and you'll probably have to fight some impostor syndrome but the ability to be humble and ask for help is something a lot of companies/team appreciate. Just try to limit the sessions to 30 minutes to no more than an hour. You don't want your head to explode. This also provides value to a team member because it allows them to work through explaining the code as well as seeing the existing code from someone else's eyes.

3. Communicate, communicate, communicate. 1 and 2 already imply this but when people are let go because they're "not the right fit" its often because they didn't build relationships with the rest of the team. Communicate what your confused about. Communicate what your excited about. If you've already been hired, then you should already be in an environment where people are receptive to you.

4. Ask a ton of questions. What tools are everyone using? How do they feel about TDD? How does this thing work? Through your questions the rest of the team may find bugs or things that need to be refactored.

5. Document everything you were confused about. If you were confused about something in the code then most likely the next person coming onboard will be too.

Most of the time its not a cultural fit. Sometimes its because the company hired a senior dev and instead got a junior dev who has trouble following logic.

They're not expecting you to be 100% up to speed but they do expect you to make progress in understanding the code base.

When you're an At Will employer, they can fire you for any reason that's not discriminatory. They gave you some BS reason because the real reason either made them look bad (can't afford you, or someone better came along after you accepted) or was illegal (they don't like your ethnicity) or was just stupid (they don't like how you dress).

In any event, you're best to just move on, and be glad that you're done with them.

If they hired you and determined in 2 weeks you were a bad fit that proves they are shitty at selecting employees.

If I were you I would do a couple of things before I beat myself up - if you experience this kind of thing at your next job then perhaps I'd worry, but 2 weeks at one company? (1) - Do a little research on the company (glassdoor tends to be negative but still worth looking into, google the company and see what other people's experience has been). (2) - Do some freelance work and see what the feedback is from who you do work for.

What feedback did you get in the 2 weeks you were there?

I'll paraphrase a quote a friend attributed to Deming: "When a company fires someone, you have to ask whether their hiring process is broken or did they make them that way?"

That is, either they didn't properly assess you or they changed the situation into one where you were setup to fail.

Is this a high turnover place? I was working at a shop with 25 employees. After I left (I quit after a short time), seven other people left in the space of three months. For that year, sixteen people left. Abuse takes its toll.

If they didn't give you some kind of negative feedback after the first week, I'd say it's their fault. Sounds like you dodged a bullet honestly. That said as consultant if I'm not making commits by day two on a moderately sized app something is wrong either on their end or mine. By the end of the week one you should be in a good position to do some solid commits and bug fixes. It might be their process is broken, no tests or off migrations, or their code is not document or honestly maybe you were just working too slow for them.

The good news is there are tons of openings for rails and django developers right now. There are also some amazing and friendly clients out there. If I was you, I'd layout a set of goals with the employer/client for the first week at your next job and see if you can get them done. Same thing with the second week. If you are hitting the agreed to goals to customer satisfaction then you know you're productivity is not the problem. If productivity is good it might be time to debug personality, communication, etc.