I got fired after 2 weeks of being hired. Please help me understand something | Hacker News Reader

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

25 pointsdviola41 comments

I was fired from a company after 2 weeks of being hired. Their reason for firing me is that I wasn't productive enough. How do you guys deliver code/value fast on the first days without knowing their codebase at all? Or are those type of companies just unrealistic?

View on HN

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.

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

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

I was hired as an employee (Rails developer) with a 3 months trial. However, I was fired at week 2 with the excuse that I was having "problems". Not sure what he meant since I delivered features and I was working on a task at that time. I was even making progress and communicating with the team.

I was also trying to learn about the codebase. They were two apps so I had a lot to learn. I had done scrum and pairing too.

The person who fired mentioned problems with their budget and he said something like they wouldn't be able to afford me if I had to take time to learn their codebase/platform and what they've done, and while that sounds reasonable I don't think they should have hired me in their first place.

I don't think I'm being unreasonable here? I might have done mistakes too perhaps, but I don't think it's fair the way things ended.

I think he also said that he had to fire someone else and that he would like to keep an open door for further work but I don't think I'll join them anymore if they ever approach me again. After being fired at week 2 I don't want to get let down again.

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.

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.

Certainty about what?

What do you mean? I have delivered more than one feature in that timeframe. In fact one of them being a large one, and I got this one done in a day without knowing much of their codebase.

Sure, it took me a week to deliver a small feature because I got stuck with a failing test and I didn't know their codebase that well.

They also blamed me at the end for asking many questions. I think they thought I needed much help like it's a bad thing.

The manager who fired me at the end also mentioned he had to fire someone else.

Sure I could improve my knowledge too. I'm not claiming I have all the knowledge of the universe. Who does?

"They also blamed me at the end for asking many questions. I think they thought I needed much help like it's a bad thing."

I am going to go with this statement you made.

I've worked with a few people that are what I call "leeches" . I'll give you a quick story. I was on a project and this person comes by and asks how he can't figure something out. I walk through with him through the codebase and run through a debugger session and by the end he has his answer. Now, there was nothing that I did, that he couldn't do himself. He just wanted some kind of hand holding or didn't know how to dig to figure it out. It took about an hour and I charged the hour to another bucket. Not surprisingly, this person also didn't last too long and was let go from the project. He had other issues but this "leeching" definitely was a factor.

So, obviously, only you know your situation and this may not be your case at all, but in any new position there is a fine line between "figure it out yourself" and hey I need help. I would say the first month of any job is a real hustle. You might be putting in 8 hours "on the clock" but maybe another two to three on your own. The ask too many questions is an indicator that those questions should have/could have been answered by yourself and you didn't take the initiative to figure it out. This is a fine line but the question you should ask yourself is - "If I spend another 2-3 hours reading the code base, googling, whatever" can I figure this out for myself. If the answer is likely then go for it. Figure it out. Those 2-3 hours will give you more insight into the code base and make you more comfortable with it.

If you are hired as a junior there is a lot of leeway for that. If not, there isn't much. Once you've built your credibility this sometimes changes and you get more leeway but definitely not when you are starting out.

I get that for some this might be the opposite, since the notion is that you're a new hire and they should "get you up and going" but they are not hiring experienced developers for their ability to ask questions that they can figure out themselves if they put some effort into it.

I also wanted to say that I have worked with two Rails applications in that timeframe (2 weeks). One app being Rails 4 and the other Rails 3.

I delivered more than one feature, not sure how many, maybe 3 or 4 features, without knowing the codebase at all, and the applications were government related applications, so they were large applications.

I never worked with government applications before and that domain is new to me, I think I have a decent understanding of how Rails works so I'm not sure what the problem really was.

They blamed me for asking questions, I did a bit of pairing with some members of their team.

In the end, I was fired, and the excuse was that I wasn't productive, but how I'm going to be productive in a very short timeframe without them letting me learn about their application first?

It's tough.

Look, I don't think the parent was attacking you directly, just explaining what may have happen from their perspective.

Personally, unless you lied on the interview and were able to bullshit me into the job or you didn't shower, cursed every two minutes or made racists jokes/whatever, I would never fire anyone in the first 2 weeks. Having said that, no one here knows what happened except you and the company and Sam was providing some info of what may have happen from the employers perspective.

The best thing for you to do is to take some time and think hard to see if there was something that you could have done for this not to happen. If so, learn and next time act on it, if you truly think that there wasn't much you could have done to change how this went, and the company is at fault, then don't stress about it. Go out, have a beer and you will find another job soon.

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.

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.

"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

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.

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

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?

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.

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.

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)

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.

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

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

It's scummy.

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.

How is saving $6k at best doing anything other than making your new employee resentful?

"It a) offsets our risk"

You could simply hire better employees rather than disrespecting your candidates. I wouldn't bother pretending that it has anything to do with "risk management". At best, you sound extremely cheap. At worst, it makes you sound like you repeatedly make poor hiring decisions and scramble to adjust for this.

That was the original agreement. A full time job as a Rails developer with a three month probationary period, but they fired me at week 2.

I'm disappointed.

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.

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.

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

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/

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

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.

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.

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

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.

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

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.

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.

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.

Unrealistic company. Consider it experience and move on.

Reply on news.ycombinator.com