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.
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.
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?
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 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.
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.
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 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.
I'm disappointed.
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?"
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 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
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.
Not in modern times, and apparently not for this employer. As I said, the OP is probably better off without this experience.
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'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.
That guy was also the same guy fired me.
That is, either they didn't properly assess you or they changed the situation into one where you were setup to fail.
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.
In any event, you're best to just move on, and be glad that you're done with them.
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.
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.
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.
They're not expecting you to be 100% up to speed but they do expect you to make progress in understanding the code base.