Daniel Doubrovkine bio photo

Daniel Doubrovkine

aka dB., @awscloud, former CTO @artsy, +@vestris, NYC

Email Twitter LinkedIn Github Strava
Creative Commons License

You have recently graduated and looked for work. You put together a good resume and e-mailed it around. You got some interest from a few tech companies and maybe programming homework, followed by a technical phone screen. You did well and got invited to an interview! After several hours of whiteboard torture inspired conversations, lunch and references you were offered your first Engineering job and you have accepted. You’re starting in two weeks. Congratulations!

Now what?

First, do nothing. Take those two weeks to relax and catch up on your non-technical reading. Lie on the beach. Have a drink. Some managers will offer you a few possible things to do (usually reading or to brush up on some particular language), accept these suggestions eagerly, but don’t ask for them. Don’t feel obligated to do anything. Personally, I expect my new hires to arrive rested and refreshed on their first day of work - if I wanted them to start earlier, I would have asked.

Your First Day

When you arrive at work you’re a lone passenger facing an entire organization that’s moving forward like a high speed train. You can’t possibly jump onboard at full speed, you need to gain some momentum of your own. On your first day you want to figure out who your mentor is - a technical, default goto person. You may also want to find a spirit guide - a non-technical, friendly individual on, maybe, a business team. You can always reach out to those that have interviewed you and it’s great if both of these people have been with the company for a long time.

Engineering First Steps

It’s likely that you are now parachuted into a giant mess of a large software project that has been worked on for the last 5 years by 20 different people. Your first task is almost always to setup a working development environment, to run the project locally and to modify some trivial code that is very hard to locate. The setup part is not a huge accomplishment by itself, so do it quickly and don’t mention it. Look for an opportunity to make it easier for the next developer, maybe contribute to the documentation that you were given or create such documentation.

You are usually assigned a small semi-trivial issue, do your best effort, even for a completely trivial task. See it all the way to production.

Non-Engineering First Steps

When meeting other individuals on the team, always ask them what they do and how what they do fits into the big picture. Eventually you want to understand who is who in an organization, how the organization is structured and what the business does. Obtain an org chart. Find out what your team’s goals are and what the company’s objectives and goals are. Understand the roadmap and locate yourself in it.

Make a Contributing Impact

In your first 60 days you want to make a contributing impact. This often means shipping a feature that has real effect on customers. In order to accomplish that you must always make progress and never get stuck in something trivial. When you need to, don’t hesitate to ask questions.

Beyond that, one very good reason for hiring junior engineers is that they come unspoiled by years of Dilbertesque grind or may be of a whole new generation of humans, with new, fresh ideas. Always challenge assumptions and speak up. That said, think about it as earning a credit, then spending a credit - first accomplish something and then challenge the status quo.

Remember that it’s easier to get into something than to get out of it. If you take on an initiative you will be stuck with it until its bitter end. Do one thing at-a-time.

If your work is not criticized, if your pull requests are merged without comments, if it seems too easy, you’re doing something wrong. More experienced engineers will always find something bad in your code and you want their feedback. If they aren’t giving it to you, they either no longer care, or they are afraid to hurt your feelings. Ask them for it and remember that writing bad code doesn’t make you a bad person, their criticisms are about your work, and work only and their goal is to help you improve as an engineer.

Always look for what’s missing. No tests in this project? Add some. No documentation for how to get set up? Write it.

How to Behave

As a new employee you have no idea what the culture or environment is, but there’re things that are universally applicable. Be modest and respectful, be concise, brief and clear in your communication and make accurate statements. Check out Unwritten Laws of Engineering, a good read that is still relevant today.

Don’t forget that you work for someone. You will be praised for your accomplishments, but your team lead will take the responsibility of your failures. Work with them and pay attention to what they are saying or want you to do more than from others.

Avoid complaining about people other than to them directly and privately. If you have something bad to say about someone, say it to them, not to your boss or, worse, their boss. Also, consider the old Russian saying that criticizing management is often akin to peeing against the wind - it always falls back at you.


I recently presented this at the Flatiron school, slides below.