What should engineers do in their first 90 days?

There is plenty of advice to help managers figure out what they should be doing in their first few days at a new company (entire books have been written on this topic) but not a whole lot for engineers. I am going to try to share some of the things that I proved to be useful. The advice here isn’t all about picking up the technical skills to succeed at the job which may be a surprise to some :)

1. Get to know the people you will be working with closely: Usually when you start at a new place, this maybe one of the things your manager will include as part of your onboarding tasks. But in case that doesn’t happen , it is well worth taking the time to do this on your own. This can feel not all that urgent given that there would be a lot of technical stuff to ramp up on. At the very least, I’d recommend having a 1:1 chat with everyone on your immediate team. So, how can one best leverage these introductory chats? Here’s my strategy — make a list of questions that can be answered by this person uniquely prior to the meeting and get them answered (could be specific to their function or about the business etc), (ii) ask about any challenges they faced when they started (answers would be more useful if they joined recently), (iii) ask for any advice that they may have for you (people are usually very generous and want you to succeed!). By the way, it may not be clear how much of the information you are getting is useful at that time since you may not have sufficient context to understand some of the details but it will make sense at a later time (also totally reasonable to space these meetings out so you have time to learn more about the company and ask more specific/thoughtful questions). The information you gather after all these chats can help you in a lot of ways — (i) you can see what common themes emerge about the team/company (this is probably the ground-truth), (ii) you can infer what someone cares about (an engineer may complain about code quality whereas another engineer may complain about lack of fun projects) (iii) what success looks like in your role (sooner you learn this the better) (iv) who you can lean on when you need help with specific things.
2. Be curious: When you are starting out at a new place, you have the license to ask a lot of questions. This is the most effective way to accelerate your learning! When you are asked to run a command to push your code, try to understand what happens under the hood. When you are in an oncall incident review meeting, try to understand what the different tools do (You can also do this offline when you have some time for yourself. I find it useful to maintain a running list of questions, trying to find answers as I go and checking them off as I do. Sometimes the questions get answered automatically through doing other tasks / having other discussions) Some companies have this great practice of public Slack channels where new hires can ask questions and get answers without any fear or judgement (I find it helpful to use this even as a non new-hire!). Overall, you should try to leverage your curiosity to your advantage early on since over time you will likely get comfortable with what you know and will stop being as curious.
3. Optimize how you work: A common pattern I have seen in a lot of engineers at a new place is that they learn how to do something (say the workflow for committing and pushing code) and stick to that method forever. They probably learned how to do that from their mentor and never tried to find out if there is a better way to do it. Of course, there is no need to optimize that’s working well for you but there maybe simple things that further improve your productivity and reduce effort which you may not be aware of. One practice that’s helpful for me is to keep track of my pain points and addressing them through better tools/optimizing my use of existing tools. A couple of simple examples — (i) I started using a new IDE for Python and I realized that I was spending a lot of time switching tabs between different files. So I spent some time learning the shortcuts (and even creating new ones for combining some common actions specific to how I like to work). (ii) I created a lot of useful bash aliases to save time typing long commands, especially ones that I use often. Small improvements like these have a compounding value in the long term!

Recruiting is a very expensive activity for companies. So it is in the company’s best interest to make sure every new engineer succeeds. It means we have a lot more time to show our skills and make a mark. So relax, pace yourself and do your best. Good luck :)