5 ms·
I got fired after 2 weeks of being hired. Please help me understand something
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?
- lutusp 13y ago> 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 13y agoTwo 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 13y ago> 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.
- gexla 13y agoIt 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 13y ago> 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 13y agoI was hired as an employee with a 3 month trial. Not as a freelancer.
- dviola 13y agoI 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.
- ylou 13y agoI'm sorry this happened, but we don't have a lot to go on. What other feedback did you get?
- professorTuring 13y agoThat'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.
- blueskin_ 13y agoUnrealistic company. Consider it experience and move on.
- madaxe_again 13y agoIf 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 13y agoWhy 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 13y agoYeah, 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 13y agoWe do. It a) offsets our risk and b) gives them a tangible goal to shoot for.
- EnderMB 13y agoOut 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 13y agoNo. 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.
- SamReidHughes 13y agoUnlike 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 13y agoSince 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.
- deleted 13y ago[deleted]
- 13y ago
- brudgers 13y agoThat 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 13y agoThat'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 13y ago"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
- rmcastil 13y ago> 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.
- twunde 13y agoMost 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.
- mathattack 13y agoWhen 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.
- padseeker 13y agoIf 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 13y agoWhat 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.
- jbgreer 13y agoI'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 13y agoOr he wasn't a good fit for a multitude of reasons that could only be known after the work has begun.
- ChristianMarks 13y agoIs 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 13y agoI 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.
- greendata 13y agoIf 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.