Ask HN: Engineering managers, how do you onboard new hires?
I think this is a special case of what the OP was asking, but if you&#x27;re a really big company, this is one way to do it.<p>Way back in the 90s I worked supporting IBM AIX compilers.  IBM had an interesting technique for onboarding engineers that started with them being interns.  If they liked you, they would hire you as an intern for the summer after your first year and plonk you down in the call center.  Part of my job was training &#x2F; orienting the young kids who were the first line of support for compiler issues.  We spent a week with cultural indoctrination (the right answer is ALWAYS better than a fast answer) and basic training (AIX, vi, how your phone works, how the issue tracking system works, etc.)  Compiler support interns got another week where I showed them how I put together test cases to find corner cases.  I also trained the networking tools interns and showed them how to use tcpdump &amp; perl (this was before ethereal.)<p>But the key here is they spent three months learning about AIX, TCP&#x2F;IP and&#x2F;or C&#x2F;C++, FORTRAN and COBOL compilers.<p>In year two they could return to the support trenches if they really liked it, but we encouraged them to take a role in the QA department.  There was a similar deal there... a week of indoctrination (a correct answer is PROBABLY better than a fast answer) and training (intro to <i>shudder</i> PROFS, IBM&#x27;s tool for doing everything, custom QA tools people had built, etc.)  We also gave them a bunch of example tests to improve &#x2F; modify.<p>So after summer number two, they were trained up on what AIX + Compilers did and a little bit about the internals of several products; advanced interns got to look into the executive... er... kernel.<p>Summer #3, if they came back, they got do do a few coding tasks as junior developers.  This is back before the web when we did <i>REAL</i> software: text editors that directly opened &#x2F;dev&#x2F;kmem and read&#x2F;wrote data structures to various kernel queues (system calls? never heard of them), used IOCTLs to write data-structures into the networking subsystem that were only documented on bar napkins, and ksh scripts that emitted LISP compilers written in ksh that compiled to ksh scripts, etc.<p>In summer #3 they were given the secret manual that told them a FAST answer is many times better than a CORRECT answer, but don&#x27;t be afraid to tell other people when you learn the fast answer you gave them was not entirely correct.  Also, be aware other people are going to be updating their answers to you.<p>So... IBM tried to get their hooks in young developers early.  Started with a summer where they learned what the product did,  then a summer where they looked at how the sausage was made and then a summer doing basic coding tasks (almost exclusively in C, sometimes C++.)  This was back when IBM had a LOT of job openings, so if they evaluated well in their internship, they would be given a job offer just before graduation, and there were PLENTY of jobs for them to choose from.<p>Usually their first three months was quite structured, but mostly focused on how to use various internal IBM tools.<p>So to recap... if you&#x27;re a REALLY BIG COMPANY... onboarding begins before you hire people.  It starts by engaging candidates early so they get an idea for what your company is like and what typical tasks look like.<p>IBM &quot;invested&quot; 9 months of intern pay (which was pretty good for interns in the 90s) to indoctrinate and evaluate potential long-term employees.  Its unlikely any business would do that today, but I think there are some good lessons here for every company:<p>a. It&#x27;s a good idea that your engineers know what your product is supposed to do.  You might want to give them a little time with the manuals (oh.  I&#x27;m sorry.  I forgot, your code is self documenting so we don&#x27;t do documentation anymore.) or your test code so they at least know how the API is supposed to be called. (related: if you can&#x27;t explain what your product does to an engineer, in a way that an engineer can understand, you have problems.)<p>b. It&#x27;s at least as important to immerse the new-hire in work culture as it is for the new-hire to demonstrate their technical chops. (if, as you&#x27;re explaining your culture to a new hire, you use the word &quot;meritocracy&quot; or &quot;wholistic,&quot; you probably have problems. consider reading anything by Isaiah Berlin.)<p>c. Nowhere in this comment did I say IBM ever listened to anything the interns said.  Don&#x27;t do this.  Schedule a meeting about 3 weeks out and go over the new-hire&#x27;s questions &#x2F; concerns about process &#x2F; culture.  Make sure you tell them you&#x27;re going to do this so they can be prepared.  (You should do this at least every quarter (I mean a 1-on-1 where you talk about process) but the OP asked specifically about onboarding...)<p>d. Your on-boarding process may be different for junior engineers as experienced engineers.  IBM invested time&#x2F;money to teach kids &quot;the IBM Way&quot; so they wouldn&#x27;t have to un-train them later.  Experienced engineers always need to be &quot;un-trained&quot; to a certain degree, but you&#x27;ll need to have a good idea for what you want to un-train them on.  So for experienced engineers, include a week or two in there where you slowly explain: 1. there&#x27;s a reason we have at least one branch that can be deployed, that&#x27;s part of why we do testing, 2. pair-programming is actually useful, but it&#x27;s hard to explain when you should do it, you just have to learn it along with your team, 3. no. software developers write tests and documentation. 4. it&#x27;s okay to use expletives in the office as long as you&#x27;re cursing at JIRA or Confluence. 5. Markdown is a pox upon humanity, but it&#x27;s a useful pox upon humanity so revel in the sickness until something better comes along. 6. no. we won&#x27;t start using TLA+ until AFTER the whole team understands point-free and functional styles. 7. no. there are good reasons you can&#x27;t use co-pilot. 8. ask questions. but the person you need to talk to might be in the middle of something else so you may have to wait a bit. have a backup task handy. 9. (related to 8) - asking questions about why things were implemented a particular way is not admitting defeat as a senior engineer.<p>Okay... now I&#x27;m ranting...