6 ms·

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

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 13y ago
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.
- deleted 13y ago
  [deleted]
- SamReidHughes 13y ago
  Certainty about what?
dviola 13y ago
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?
- avenger123 13y ago
  "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.

brudgers 13y ago

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.

deleted 13y ago
[deleted]
SamReidHughes 13y ago
Certainty about what?

dviola 13y ago

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?

avenger123 13y ago
"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.