Dear _____,

Welcome to the team! We’re very excited that you’re finally here. Here’s your desk, your MacBook Pro, your Linux workstation, monitor, etc. etc. Of course, get whatever keyboard you want (this one is surprisingly popular), and let me know if you need any other equipment. Most people use Eclipse, but feel free to use whatever IDE you’re comfortable with (IntelliJ IDEA has something of a cult following, and we have a couple of people who insist on using vim or emacs). _____ will be your “buddy” – it’s her responsibility to help you get acclimatized, introduce you to people, and make sure you know where everything’s kept.

Set up

We use a locally-hosted twiki for most of our documentation – please refer to the “onboarding” pages for help with installation. We intentionally leave it to new hires to set up their own machines, both to reduce the load on the IT department, as well as to make sure that engineers are intimately familiar with their setup. If you find any mistakes or outdated instructions, please update the docs! When you’re done, you should be able to build and launch a copy of the trunk branch.

Setting up a development environment takes some new hires as little as a half day, others as long as a week. Consider the following two possibilities – which would you rather have said of you?

_____ got everything set up the first day, and was committing code by the end of the week!

_____ took a whole week to get a build up and running, and is only starting the first project now.

First impressions will inevitably be formed based on how quickly you can get productive. I highly recommend focusing in on this, and asking for whatever help you need, to get your dev environment set up as quickly as possible. This doesn’t mean that you should cut corners (which can have the opposite effect of setting you back significantly), rather that you should buckle down and just get it done.

Projects

Your first project will be a very small bug batch – a collection of P2 bugs that we honestly haven’t cared enough about to fix. The goal is to keep the stakes low while giving you a chance to get into the code base, learn how the code hierarchy is laid out, and go through the full project lifecycle. No one expects you to know everything on your first day – if you find yourself getting stuck, ask someone for help! One of the most common anti-patterns we see among new hires is that they feel too embarrassed or shy to ask questions, and end up banging their head against simple but obscure problems for hours at a time. The people around you want to help – we have a very supportive environment – but they need for you to take the first step.

As we discussed during the interview process, our projects are very short – usually three to seven days – and you’ll be responsible for all aspects of the coding. We don’t have architects – we hired you because we thought you were awesome, and we didn’t think you’d appreciate being told how to solve your projects (after all, that’s the fun part!). Your projects will each have a tech lead, but her job will just be to provide some oversight, and to ask the right questions when you’re working on something more complex.

Speaking of which, you probably don’t know all of the languages / technologies you’ll need for all of your projects. Depending on the project and the team, we use Java, Ruby, Rails, Bash, Perl, Python, Dust.js, AngularJS, Mootools, Postgres, MySQL, SQLServer, SQL, Memcached, Couchbase, Hadoop, Hive, Velocity, JSP, HTML, CSS, JavaScript, Objective C, and the Android libraries (I’m sure I’m forgetting a half dozen others). We use subversion as our code repository, but some teams also use git. Don’t panic! Of course, not every team uses everything, and it’s expected that you’ll sometimes need to learn a new technology to complete a project. In general, we don’t hire engineers because they have specific language skills – one of the reasons we thought you’d be a great fit was that you seemed like someone who could pick up new languages and technologies quickly.

How to succeed

Before we get started on this, you might want to go through some older posts on how to succeed, and how to avoid failure:

• How to be a Star
• How to Fail
• Opportunityspotting

There are a couple of points I’d like to emphasize:

• Bad news can’t wait

Seriously, the worst thing you can do when a project goes south is to keep it quiet. The sooner you let people know there’s a problem, the more time they’ll have to make adjustments on their end, look for ways to ameliorate the problem, and communicate the problem to their stakeholders. This doesn’t mean they’ll be happy about the situation, but it removes a major compounding factor – the cover up is always worse than the crime.

• To exceed expectations, you first have to meet expectations

Some people are always excitedly talking about new technologies, side projects, proposals for process changes, etc., etc. – everything except the actual projects they’ve been assigned. The thing is, no one’s counting on you for any of that other stuff, and if you’re always prioritizing fun side projects over your actual work, you’re going to have a very hard road.

• Don’t break the build

OK, this diverges a little from the “general advice” nature of the other points, but seriously, please don’t break the build. The worst is when you break the build, then leave (or go to sleep if you’re working from home). We have automated tests, and Jenkins servers doing continuous integration, so you should be able to get objective confirmation that your code is ok pretty quickly. If you aren’t going to be around 15 minutes after merging code, don’t.

What I expect of you

As mentioned above, the most important thing is to complete your assigned tasks well. This means:

• Start well

When you start a project, please sit down with the PM and tech lead and go through the details of the project. Make sure you understand everything that’s being requested. When you’re done, put together an estimate of how much time you think it will take. The more detailed, the better (please omit line items for trips to the little programmer’s room). Send this to the PM, the technical lead, and me. Make sure you fill in the relevant data in the project management software.

• Keep me in the loop

Let me know if any unexpected problems come up, or if there are significant change requests (we don’t want to hold the PMs to the spec if we discover that something just doesn’t work, but they also don’t have license to change anything for no reason). If it’s a longer project, keep a list of potential risks, along with mitigation plans. Send me status reports as appropriate (different teams have different guidelines, but twice a week is usually fine).

• Finish well

Of course, you’ll ideally finish the project on time. Before asking other people to do a code review, you should do one yourself – it’s really frustrating when people put up code that’s clearly not ready. Don’t let projects drag on, and remember to mark them as done after you merge.

Once you’re rocking it on your core responsibilities, think about ways that you can stand out. Here’s a short laundry list:

• Help other people when they have questions
• Give a tech talk on a topic you know well
• Organize a technical book group
• Set up a lunch for an interest group (fresh grads, senior software engineers, women in engineering, etc.)
• Keep your eye out for common annoyances, and fix them
• Get your friends to send in their resumes

In general, I don’t want you putting in crazy long hours. A lot of rules get thrown out the window when there’s a crisis – but that should be extremely rare, and short-lived. We don’t have deathmarches here.

What you should expect from me

So, there are a lot of things I expect from you – high quality code, speedy delivery, status reports, etc. But what should you be expecting from me? Quite a lot, actually…

First, a basic description of my responsibilities: What do technical managers do, anyway?

Now, a more specific answer:

• Project assignment

I keep a big spreadsheet of all team projects – from projects waiting for an engineer, to those already in flight, to projects already merged and waiting for release. When you’re getting close to needing something new, let me know. I try to make sure that everyone has a chance to do different types of projects, so don’t be surprised if you’re sent careening through the codebase with every new project. It might be more efficient in the short run to have everyone develop a single area of expertise and just focus on that, but it’s less fun, prevents people from developing, and creates a less flexible, more territorial engineering department. So expect lots of variety.

• Career mentoring

The nice thing about working at an incredible successful, highly profitable, fast-growing company is that you have to beat off opportunities with a stick. We do a lot of swapping between teams, even if you aren’t on our rotation program. Part of my responsibility is to find ways to expose your brilliance – to help you find opportunities to shine. Sometimes this means giving you a high profile project. Sometimes it means giving you the chance to work on another team. Sometimes it means giving you additional, non-engineering responsibilities. Sometimes it means giving you feedback on things that didn’t work out. I am absolutely on your side, and sometimes that means giving you opportunities, sometimes telling you about areas you need to improve.

• Crisis management

When there’s a personality conflict, or a misunderstanding with a PM, or a live site bug that needs a patch, or, well, whatever… I’m your first point of contact. My primary responsibility is to help find a solution – I don’t care so much about the cause, except insofar as I want to find ways to avoid it in the future. Remember – bad news can’t wait, and I can usually help when things get dark and scary.

• Baked goods

I bring in a lot of muffins, scones, croissants, donuts, and bagels. One more reason to get in on the early side…

I tend to end up in a lot of meetings and interviews, and career fair season is the worst. It can be hard to find me, I know. But I will always make time for you – I promise.

A final note

I know there’s a lot to digest at the beginning, and there is a certain aspect of “throw the new person into the deep end and hold her head under” when you first join a new company, but don’t panic! It can take a little while to get your sea legs, but you’re going to do great. Welcome to the team! I’m really looking forward to working with you.