16 ms·
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 oft
by gexla 13y ago
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 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.