10 great ways to impress a software engineer on their first day

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.

12 thoughts on “10 great ways to impress a software engineer on their first day

  1. As a software engineer, I definitely appreciate my hardware being in my office when I arrive. But please leave it boxed. Besides enjoying the process of unboxing what my employer bought for me, I want to personally go through the process of setting up my office, so that it’s just the way I like it.

    I absolutely agree there should be documentation on the software installation process (OS, tools, code), but again, let me go through it on my own so I can learn the setup of my environment. Nothing is more irking than being forced to use a foreign environment.

    I really don’t want to be bothered with fixing a bug my first day, there is way more than enough to do anyway (setting up payroll and benefits and transportation, in addition to my office).

    The other points I agree on. Peer mentor, culture and expectations briefing, and lunch with coworkers are all absolutely necessary.

  2. Louis Wasserman says:

    Rubs me the wrong way: “his first day” in the first sentence makes unnecessary assumptions about gender.

    • Daniel Kaplan says:

      Completely agree. I did my best to change this issue wherever I noticed it. Let me know if I missed anything. Thanks a lot for the comment.

        • Daniel Kaplan says:

          Thanks for the tip! I’ll try to remember this in the future. I appreciate the critique to my writing.

      • Anonymous Coward says:

        There are still plenty of occurrences of “his” in the text. But I honestly don’t think a simple search/replace is enough. It doesn’t address the underlying issue – that assumption that only males are employed in our industry. (Not the way you really want to impress people, surely? :/)

        There was an excellent NPR story recently on how diversity in the workplace benefits *everybody*. Definitely worth a listen.

        And we wonder why we aren’t attracting more females to the tech industry?

        • Nick says:

          I think it’s great to bring things such as this to light in media, I always try my hardest when giving examples to go with a gender neutral description rather than “when he” for example.
          Here though I think Daniel has been pretty open to the fact that it just slipped his mind in this case and has happily updated his article to match. I really don’t think it’s appropriate or fair here to start giving him stick on the gender gap in tech.
          I wholeheartedly agree that the gap is a problem we all together in the industry need to work hard towards fixing (For those who don’t I’d personally recommend watching ‘Debugging the gender gap’). I think being militaristic about it to people however is completely the wrong way to go. Simple reminders when we (both men and women) slip up or miss the mark is fantastic and exactly what we need to hit the nail on the head and keep the problem always in our minds (Until the day it’s finally not a thing). A fear of our articles and presentations being undermined is not.

          Totally enjoyed this article by the way Daniel, would be great to see all of these done for new engineers and on the whole new employees one day!

          • Daniel Kaplan says:

            Thanks a lot for your reply, Nick. I really appreciate it. There’s a saying, “never attribute to malice that which is adequately explained by stupidity”. That’s me in this case. I didn’t use male pronouns out of malice, it was a stupid mistake.

            Glad you enjoyed the content of the article! Thanks again.

  3. Great ideas. If a company did all of those things, I’m SURE the new developer would sing high praises for weeks. Unfortunately, in most companies you’re lucky if they take you to lunch on your first day.

Leave a Reply

Your email address will not be published. Required fields are marked *