Starting a new job – What can I do to avoid getting fired?
I just accepted an offer at a company I'm super excited about. The interview process was a mix of the traditional whiteboard interviews and watching me write code, so I suspect they got a good impression of my skill. The company seems like they know what they are doing in terms of mentorship and development processes. However, I am still worried that in a few months they will realize that I am incompetent or unproductive and I will be fired. What are the most time-effective things I can do to rapidly become competent and productive and thereby avoid this? I have a few weeks before I start that I can use to prepare.
My current ideas are:
1) Enforce a rigorous sleep schedule on myself, getting the same 8.5hrs every night.
2) Make a list of the technologies they are currently using (RoR and react.js), then pay for the best tutorials I can find and run through them repeatedly to drill myself to work fluently in them. In particular, look for tutorials that also involve testing and debugging.
3) Build app using the above technologies as an open source project and find someone I can pay to do code reviews of it.
4) Make flashcards and rote-memorize things that will help me look things up and navigate the codebase more quickly.
5) Aggregate a list of 100 webpages and build imitations of them in html and css and thereby finally teach myself by rote how CSS layout works.
6) Find someone outside the company (so they don't have any input on performance reviews) I can trust to talk to about things like project management or recognizing when I'm miscommunicating or taking the wrong approach.
7) Find someone inside the company that I exchange help on their tickets with in exchange for letting me watch how they work to see if I can borrow habits to become more efficient.
Does this seem like a good list? Do you have any things you might add? Any tips for any of these?
40 comments
[ 3.0 ms ] story [ 110 ms ] threadOf course, doing extracurricular professional development is fine and a lot of people love their side projects, but I'm worried that your attitude will lead you to burnout.
Your best bet is actually to trust that this company hires competently and that you'll be able to perform the job to their satisfaction after being onboarded. I know it's impossible to "just relax", but I wish you could do that <3
Be yourself. Ask your manager for feedback every other week. Have fun.
Does the advice "be yourself" mean "do what you would tend by habit to do"? If so, I think that would probably have the same result it's had in 2/3 dev jobs I've held: me getting fired.
I originally thought I had impostor syndrome too, since it was constantly talked about at school. I should have mentioned that I've been fired from 2 dev jobs I've held before this, so apologies for that.
Explicitly asking for feedback is a good idea, though I worry that 2 weeks is too infrequent. Would every 1 week be annoying?
* When I'm confused about what a task really entails or what tools I can use and I try to get people to resolve that ambiguity, I sometimes cannot persuade them to do so.
* Sometimes I don't recognize that I lack the knowledge/documentation to do something and instead approach it with an "I'm smart and resourceful; I'll figure it out" attitude. By the time I convince myself that I need to ask for help, I'm embarrassed about not having made progress.
* I've gotten feedback that I "try to understand the universe" when debugging an unfamiliar system. That I should be more focused in my search. The difficulty here is that, when I'm working with an unfamiliar system, I don't know the lay of the land and so I end up spending a long time trying to get a sketch of a mental model of it because, well...how else could I solve problems?
* As my username suggests, I get distracted easily and sometimes find myself losing 5+ hours to distraction. I've been able to fight this to some degree using SelfControl.app and by making sure I get good sleep.
* I don't know how to come up with task estimates that have any relationship with reality. I've said "I don't know how to give software timeline estimates", but often get pushed to give a number anyway. I really really hate lying to a coworker/supervisor's face and wish I could find a way avoid it. I've tried to learn how to do estimation and bought a book on it, but all of the advice seems to focus on projects on a months-long scale rather than things that should take a couple hours.
As an example: The reason why I focus on studying rails is that all of the debugging techniques I know about involve getting a better idea of the system at some layer of abstraction. I suspect that my best shot at getting better at debugging is to know the framework the code is written in very well and thereby be able to understand the codebase more easily.
For a problem like "I can't get clarity around what we are trying to do here.", it seems like there aren't any books on the topic. Thats why I figured that finding a mentor would be good.
- How to Win Friends and Influence People
- Difficult Conversations
- 5 Dysfunctions of a Team
I also bought Miscommunication by C. David Mortensen, but I haven't been able to get through more than a few pages because of how dry it is.
I suspect I need something more specifically focused on how to build mentorship relationships. Anything come to mind?
Whoa, where is this coming from?! Jeez, is this your first job?
> Do you have any things you might add?
The note about sleep is good, you probably don't need the others. Let any of the above be driven only by your passions and interests. At work, communicate well and as clearly as possible. Show up, be positive, get your work done.
It is that last bit, "get your work done" that I'm worried about. I'm concerned that I'm going to not move fast enough. Since this has happened before, I figure that I need to do something significantly different than before.
* Show up with a good attitude, every day.
* Under-promise, over-deliver.
* Be consistent 100% of the time, not great 10% of the time and crappy the other 90%.
What do I do when I'm asked how long a feature will take and the honest answer is "I don't know"? I have tried to teach myself how to create software timeline estimates; I've still not figured it out, and it seems like nobody knows how to do it.
When I tell someone that I don't know and they still press me for an answer, I usually cave and give a random guess, followed by "but I would not rely on that." I feel so dishonest lying to people's faces like that but in the moment it feels like it is the only way to get the situation to end. Should I just get a friend and practice staing steadfast in refusing to answer? Is there something I can say that isn't going to sound like I am incompetent?
Other than that every task/spec is different. I would review the task/spec then get back with them with an estimated range of time. 4 to 6 hours/4 to 6 days and tell them you'll update them on your progress as it's completed.
Once you're working on if things are going faster complete it/test it/review the spec/double check it and then present it as things went better than my estimate.
If things are taking longer, go to them early with what is completed and an outline of items that are taking longer than your estimate and have a new estimate ready for the time to overcome these challenges and complete it.
I would say relax, be a good listener and communicator, re-read specs/requirements and make sure you're complete/thorough in your work keep them informed and you should do fine.
Since you're new try to find someone you can trust, to be your mentor, show you the ropes, help you out, bounce ideas off of, give you the lay of the office/land.
In the meantime, try to break things down if you can't even start on an estimate - what are the steps involved in making Task X happen? Keep breaking those tasks down until you get to something you can estimate. That's what the estimation time you ask for is used for.
Is this your first job out of school?
Showing up, being openminded, and putting forth full effort will help you shine.
Relax a little :)
My advice at this stage is just work harder than everyone else. Be the first to arrive and the last to leave and the company will find it very hard to fire you because of the signal it sends.
* When I'm confused about what a task really entails or what tools I can use and I try to get people to resolve that ambiguity, I sometimes cannot persuade them to do so.
* Sometimes I don't recognize that I lack the knowledge/documentation to do something and instead approach it with an "I'm smart and resourceful; I'll figure it out" attitude. By the time I convince myself that I need to ask for help, I'm embarrassed about not having made progress.
* I've gotten feedback that I "try to understand the universe" when debugging an unfamiliar system. That I should be more focused in my search. The difficulty here is that, when I'm working with an unfamiliar system, I don't know the lay of the land and so I end up spending a long time trying to get a sketch of a mental model of it because, well...how else could I solve problems?
* As my username suggests, I get distracted easily and sometimes find myself losing 5+ hours to distraction. I've been able to fight this to some degree using SelfControl.app and by making sure I get good sleep.
* I don't know how to come up with task estimates that have any relationship with reality. I've said "I don't know how to give software timeline estimates", but often get pushed to give a number anyway. I really really hate lying to a coworker/supervisor's face and wish I could find a way avoid it. I've tried to learn how to do estimation and bought a book on it, but all of the advice seems to focus on projects on a months-long scale rather than things that should take a couple hours.
> the company will find it very hard to fire you because of the signal it sends.
I'm skeptical of this for a few reasons: I've done this at the previous jobs but to not much avail. Also, it isn't sustainable. Also, that sort of signal doesn't cut costs or add revenue, so why would it convince them to keep me on. It might make it more emotionally difficult to fire me, but firing someone is already emotionally difficult.
At my old job, we used the "15 minute rule" which worked pretty well for us. When you are coming to the realization that you're stuck, and don't know how to do something, you give it 15 more minutes to figure it out. If you haven't made progress in that 15 minutes, you must go get help.
It works both ways - for people that tend to ask for help too soon, without actually trying to figure it out for themselves, and for people that tend to try to figure it out themselves for too long, when asking another person may get it figured out quickly.
> I don't know how to come up with task estimates that have any relationship with reality. I've said "I don't know how to give software timeline estimates", but often get pushed to give a number anyway.
This is often difficult in that it seems like what we do as software developers is always novel and new. But, the techniques for estimation are the same, whether the project is months long, or hours long.
Break the task down into smaller and smaller bits until you hit bits that you CAN estimate the time of - then add them up.. and then probably double it...
In the beginning, you won't be able to do this off the cuff in a meeting, but the correct answer should be, "I don't know right now, but I'll have that estimate for you by Xpm today"
One problem here is that if I don't really know everything the task entails, then I end up asking myself "am I going to really need to do this?" and can't think of a way to answer that question without writing code. Maybe the right approach here is to accept this and to write a few automated tests for external APIs.
Another is that I just need to be disciplined enough to do this consistently.
Surely you can do a first level breakdown of what needs to happen.
"First I receive data, then I process the data, then I send the data over there.
Ok, to receive the data, I'll be getting an HTTPS post, so I'll need to have an endpoint set up.
I don't know how endpoints are set up here, I'll need to ask, but I do know that it will be a POST, and the data will need to look like this...
After I get the data, I'll need to process it. It starts out looking like this, and I want it to end up looking like that. I do know that I will need to save the data in the database. I don't know what libraries/ORMs, whatever, I'll need to ask."
and so on.
I think you're still thinking from the bottom up - what are the all the details, from the beginning. But, think from the top down, making the task into smaller and smaller bits until you have reached an understanding of each bit.
The reason why firing the person who comes in first and leaves last is so hard is because of the signal it sends to other employees. If the employee everyone sees working the hardest gets fired what does this mean for everyone else - are they about to get fired too? The only way you can get fired with this strategy is if you goof off at work. Keep your head down and work like crazy (or at least appear to work like crazy) and you will be fine.
While you are right that spending the most time in the office sends the signal that you're working harder, it feels like veneer around the real issue.
The best advice is to stay upwind.
Cramming is a bad habit. My suggestion is to set aside 1-2 hours a day in the morning or evening to build things, do research and improve your skills. Continue this habit once you start your job. This will be plenty of time to keep up.
Of all the things you listed, building real apps is the only thing that will see you really making progress. Everything else is too shallow and it's also hard to stay engaged in it.
Keep in mind that your new job wants you to apply yourself daily using their bread-and-butter technologies more than they want you to understand new technologies. For example, they probably want you to bang out React components or Rails views more than they want you to understand the more esoteric bits of those. As a web developer, consistent work > insight, every time.
Strongly suggest retreating even further from idle Internet use if possible. It is not good for you.
I've been lucky enough to "fake my way" through it so far but I am anxious about future roles.
Anyways, I hope it works out for you.
So you're probably up to the task as long as you apply yourself.
Apply yourself - especially for the first 6 months.
Incidentally, you can drive your own onboarding plan-- George Bradt is an excellent place to start > http://www.amazon.com/The-Leaders-100-Day-Action-Plan/dp/111...
Honestly all that time outside of work might be better spent just being happy and using other parts of your brain, so that you can devote 6 hours during your work day to focusing on improving. Sure, you can exercise for 8 hours a day and get better progress than exercising for 3 hours a day, but for how long?
Edit: Read more comments. If you got fired for underperformance in the past, it might just be due to mis-alignment between yourself and the manager in charge. I had this at my last job. Sometimes it's tough for managers to properly assess work quality and production speed.