It's a bit tricky for me. Suggestions like "fly them to the office" is great if you have lots of people in an office, we don't. I also don't agree with "give th

It's a bit tricky for me. Suggestions like "fly them to the office" is great if you have lots of people in an office, we don't. I also don't agree with "give them the power to fix things" since one person's broken is another's "don't waste time fixing that, it's flaky". I think it depends a lot on the person you hired and at what level. I can trust an experienced Dev more to know how to look at the more important parts of the system whereas someone with less experience won't necessarily know this and we don't want their first week being keen but everyone else hating them for breaking stuff! Definitely agree with the Dev buddy and I think the pair-programming thing is probably the best way for them to learn quickly and for both them and us to get feedback e.g. are they not the right person for our culture? Are they too strongly opinionated etc.