
I got fired after 2 weeks of being hired. Please help me understand something - dviola
I was fired from a company after 2 weeks of being hired. Their reason for firing me is that I wasn&#x27;t productive enough. How do you guys deliver code&#x2F;value fast on the first days without knowing their codebase at all? Or are those type of companies just unrealistic?
======
gexla
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.

~~~
rmcastil
> freelance with the company for a trial period

Agreed. The risk here though is that with freelancing the expectations are
higher, your impact needs to be felt in week one (or even day one in some
situations) or else you'll loose the contract.

Regarding delivering value, you're right its very tough if you don't know the
codebase. Although, if the codebase takes two weeks to learn before you can
deliver a feature that means there's a problem with their onbarding. Maybe
their documentation was horrible. Maybe their project setup could have been
better automated. Often times addressing these issues are ways to instantly
provide value to the team. Just make sure everyone knows what your working on.

~~~
dviola
I was hired as an employee with a 3 month trial. Not as a freelancer.

------
SamReidHughes
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.

~~~
brudgers
Since employment involves at least two parties, absent fraud a radically poor
fit cannot legitimately be laid entirely at the feet of a single party. Then
again neither party gets to claim matters were entirely out of their hands,
either.

Of course the only part of the equation under the OP's control is their
knowledge and actions, and the healthy way of taking the situation is not to
invent a calculus of blame but to figure out how to learn from one's mistakes.
It could well be that the OP will never fit with the company's culture or
expectations and the key skill for better outcomes is not technical but better
reading workplace signals that indicate a deadline driven environment.

It is also possible for an organization to eliminate positions or reorganize
in the period immediately following a hire, or for priorities to change
between interview and start date. This is to say that is entirely possible
that this was simply a LIFO staffing change.

It's not that I disagree with your reasoning, it's rather that I don't see the
certainty with which it is presented as justified.

~~~
SamReidHughes
Certainty about what?

------
brudgers
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.

~~~
egor83
That's a great answer, thanks!

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

Having been in a similar situation, I started asking myself same question. Any
advice on that one?

The first thing that comes to mind is a recommendation from someone I know,
but there's a lot of situations when getting it is not possible.

~~~
brudgers
"What are the expectations for the position?" might work.

"What can I expect on a typical day? Typical week?" is probably better.

But absolute realism probably goes a long way. It's unlikely the job
expectation is rewriting the Mumps to Cobol middleware in Lau and CouchDB. How
does the company produce profit, who are its customers, what kind of business
is it?

This above all else: [https://sivers.org/below-
average](https://sivers.org/below-average)

------
mathattack
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.

------
rmcastil
> 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.

------
padseeker
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?

~~~
dviola
What do you mean with what feedback I got from them? They were a couple of
guys working remotely over the internet. We were working with some rails apps
and communicating over Skype/teamspeak.

I've done pairing with some of them and things were going well, I wish I had
more time to learn more about their apps though. I've participated in all/most
meetings and was always communicative. I wasn't afraid to say I needed help
when I needed it but I also tried to do things on my own. Sure I might have
made some mistakes because I was new (who's perfect?) but then again I'm
disappointed I was fired in week 2.

Let me know if you have more questions.

------
madaxe_again
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.

~~~
BSousa
Why 80%? I've worked in various companies with 3 months probation (actually,
quite common in my country) and it was fine, but never for a % of the salary
(unless it included % less time at the office)

~~~
billynomates1
Yeah, paying at less than the advertised wage is insulting. Unless they give
you the 20% of the first three months back after the probationary period.

~~~
madaxe_again
We do. It a) offsets our risk and b) gives them a tangible goal to shoot for.

~~~
cryoshon
You forgot c) lets you take 3 months of work out of someone at %80 of the
price.

It's scummy.

~~~
madaxe_again
Right, but as I said, after the three months, we settle the difference - and
it's not 80% either, actually, more like 7%, but hey ho. We've never had
anyone object, and it's pretty common practice.

------
EnderMB
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.

~~~
dviola
No. I did not get the job through an recruiter, but through one of the
employees at the company, who also happen to be in a manager-like position
from what I've noticed.

That guy was also the same guy fired me.

------
lutusp
> 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.

~~~
brianmcc
Two weeks is still far, far too soon to be making any kind of decision like
this. Two weeks in you're still working out which way is up.

[http://randsinrepose.com/archives/ninety-
days/](http://randsinrepose.com/archives/ninety-days/)

~~~
lutusp
> Two weeks is still far, far too soon to be making any kind of decision like
> this.

Not in modern times, and apparently not for this employer. As I said, the OP
is probably better off without this experience.

------
professorTuring
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.

------
greendata
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.

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

------
jbgreer
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.

~~~
timmm
Or he wasn't a good fit for a multitude of reasons that could only be known
after the work has begun.

------
twunde
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.

------
ChristianMarks
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.

~~~
dviola
I suspect it's a high turnover place, yes. When I was working there for only 2
weeks, there were already 2 hires in that same week when I started working
them, and when I got fired, the manager/person who fired me said he had to
fire someone else.

There were people working there for a year, but all of them were working
remotely, so I suspect it's a high turnover place, yes.

------
blueskin_
Unrealistic company. Consider it experience and move on.

