If you hire a new software engineer you should do whatever you can to make a good impression on their first day. This will have all sorts of benefits you may not have ever have considered. It will lead to increased retention rates so you will spend less money looking for a replacement in the future.

That person is likely to tell his peers which will market your company as a great place to work and let you spend less time on searching for candidates in the future. It will raise morale and make them excited to work hard for you. The benefits go on and on.

Before I start, I want to let you know this is mostly intended for employees. But, as a consultant, I would be even more impressed than them if these things occurred to me. Also, if your company doesn’t have a technical team, many of the things on this list may not apply to you.

Here’s what you can do:

Have their computer ready to go before they get there

When you show up to your desk and your computer is already set up, it gives the impression that the company is organized and caring. When your computer is missing, you feel forgotten. You’re an after thought. “Oh yeah, I forgot that guy is starting today.” It’s an awkward experience to ask a stranger what to do next. Your company seems unprepared.

Go the extra mile and plug in their speakers, mouse, keyboard, etc. for them. Yes, everyone is busy and it takes a little time to do this, but going the extra mile will make them feel at home.

Provide useful documentation

There should be some useful documentation about the software you expect the new hire to work on. This should give them at least a high level overview of why the product exists and its architecture. This documentation benefits everyone because the new developer will be up to speed faster, an old developer will take responsibility for documenting the software s/he works on daily, and you can increase the bus factor.

On the other hand, do not provide a 400 page document to read. This just screams “bureaucracy”. Besides, it would be expensive to keep it up to date and pointless because nobody’s going to read it anyway.

The software they will develop should already be installed and working on their computer

To be honest, I have never started a job and had this happen to me but it would be amazing. I would definitely brag about it to my peers. Normally I spend at least half the day following 30+ step directions to set up what I’ll be working on.

That’s assuming there is documentation on how to install it in the first place. If there isn’t, nothing makes you feel stupid faster than having to pester a stranger about what to do next every 5 minutes.

This is a waste of time for your new employee and a waste of money for you. When you think about it, every one of your programmers has already done this at least once. Automate the process and let your new employee work on what you hired them for.

Alternatively, setting up the project should be as simple as this:

1. get the source
2. build the source
3. deploy the result

If the installation process isn’t dead simple, then at least do this next rule:

Make an old employee responsible for bringing the new employee up to speed

A manager should tell an old employee that they are responsible for on-boarding the new employee. It should come directly from the manager and be prioritized appropriately. Better yet, tell them both at the same time so the new employee can be aware if the old employee is working on something higher priority.

Don’t tell the new employee that the old employee is responsible and expect them to pass the message along. Doing this puts the new employee in an uncomfortable position. S/He has to bug a stranger with seniority and let them know that they need to do them a favor because the boss said so. The new employee feels like s/he will look bad if s/he isn’t on-boarded soon. But at the same time, s/he doesn’t want to make an enemy by pestering the old employee. You can avoid that whole awkward situation by making it clear and explicit to both of them.

Give them a clear idea of what they’ll be working on

I don’t think I’m alone in this: I absorb information better when I know why it’s relevant to me. Tell me what feature I’ll be working on before you give me a deep dive into all of your products. Otherwise, I will become overwhelmed with information and be unable to discern the “important” from the “nice to know”s.

Don’t just give them a staging/QA environment of a product to fool around with without any further direction. That’s not a very efficient use of their time. It’s like handing someone a complex board game without any instructions and then walking away. They’ll get bored quickly, they won’t know what they’re doing, they won’t get a sense of how to really use it, and it’s not fun. Give them a concrete goal to think about and it will orient their entire thought process towards a worthwhile direction. Better yet, have someone pair with them.

Have them fix something on their first day

When your developer goes home at the end of his first day, someone will invariably ask them how it went. Don’t let them say that s/he just sat through orientation meetings all day. Let them be proud that they actually accomplished something. This doesn’t have to be much. It could just be fixing a typo in a label somewhere. But, if your company can get to the point where someone can do something on their first day, that really says something about it. You need a certain level of efficiency for this to be possible.

Having the developer poking around in the code will get his wheels turning. S/He may have a better idea of what he’ll work on when s/he comes in the next day.

Tell them about your culture before the first day

What’s the dress code? Are you flexible with start times? When they walk through the door, who should they talk to? Where can they find that person?

A lot of programmers won’t think to ask of these questions in advance. There are many more important things to think about during the interview process like the programming language they’ll be using or the processes they’ll be using.

Ask if you can pay for an important tool / IDE for them

If a developer wants a $500 tool to make themselves more productive, pay for it. It’s a drop in the bucket compared to how much time they’ll waste learning a new tool they’re unfamiliar with. To put it in perspective, if you add up the hourly rate of the people involved in the interview and hiring process, it probably cost you the same amount as this tool.

Your new hire doesn’t want to seem ungrateful or whiny for asking for you to pay for something on their first day. At the same time they don’t want to seem unproductive if they’re missing the right tools for the job. From their perspective, it’s a catch-22. Taking the initiative to ask the software engineer first will avoid an awkward conversation for her/him later.

Personally introduce them to their coworkers

Take the new hire and walk them over to every single person’s desk to introduce them to their new colleagues.

A lot of people are shy and don’t know how to break the ice on their own. This may be useful to them in the future. For example, if their mouse runs out of batteries, they won’t have to interrupt a programmer to ask who to ask, they can go directly to the office manager who they’ve already met.

Invite them to lunch

Even if you normally brown bag it, you should make an exception and invite the new hire to lunch on their first day. They probably haven’t made any friends yet and may be too shy to ask strangers to lunch. This will let them get to know you and their peers better and make them feel at home.

You might want to consider inviting people from different departments. This shows that your company isn’t cliquey and there’s inter-office communication.

If you don’t do this, the worst case scenario is they have to eat alone and their takeaway is that nobody at the company is friendly. This is bad for their morale, and it could end up giving your company a poor reputation.

I’ve never seen or heard of this, but it’s an interesting idea: Invite as many people as you can to lunch in advance and pay for everyone. Make it something of a party. If you make this an expected thing, watch how quickly your employees warm up to your new hire. They’ll associate them with a free lunch.

---

What’s implied here is that you should treat a new hire as a guest in your home, not a roommate you already live with. Be a good host. You want them to feel welcomed. If you give them a great first impression, they are going to brag about it to their friends and peers and they will want to work for you for a very long time.

Join the email list for bonus content.

Email address: First Name: Last Name:

Leave this field empty if you're human: