What is the best way to on-board (train) a new junior employee?

  • Comments posted to this topic are about the item What is the best way to on-board (train) a new junior employee?

  • For all of those new to SQL in our DBA team, I recommend two books for them to practice on.

     The first is immediate and short-to-medium term. It is the SQL Cookbook from Safari [1]. It starts off very simply, sets a task to be solved, gives answers for 4 RDBMS and explains each solution. I found it to be the best way to learn SQL. It is especially good if you have, say, an hour's commute on a train each morning. A laptop is nice but not at all necessary.

     The second is the medium-to-long term. It is the book to prepare you for the base MCP exam (in this case 70-461) [2]. I tell the new new juniors to give the book a year and it will bring them up to a high level. There is a lot within that they don't really need to know, but they need to know that it exists and what it can do (XML, Full-Text search and so on). If they apply themselves, they should be able to get an MCP exam within a sitting or two. MCPs are good to have on CVs.

    We have the books in the office and they are useful when times are not so busy.

     Aside from that, there is the usual explaining of how things are done and the introduction of new techniques as the oportunity arises.

    [1] https://www.safaribooksonline.com/library/view/sql-cookbook/0596009763/
    [2] https://www.microsoft.com/en-gb/learning/exam-70-461.aspx

  • If you are going to take on a junior then as far as I am concerned you are duty bound to be that person's point of contact and mentor.

    The most important thing for a junior is NOT to be made to feel like their an inconvenience for asking questions.  It is also important to introduce them to key subject matter experts who also regard mentoring juniors as a holy duty.  Time invested in juniors pays dividends.  They get to be productive very quickly and they learn the care and share behaviour from you.  Corporate behaviour flows down hill.

    Teach once learn twice

  • Lead by example, set a good example get a good result, its like bringing up kids 🙂 

    Plus get them on this site

    ***The first step is always the hardest *******

  • Sharing knowledge is actually a "Charity" of our skills. It not only learn us how to get leadership skills but also help us to figure out some minor things which most of the time we ignore saying "Man! i know much about it.".

    Be human and save humanity.

    zulfiqar

  • 25 years ago a fresh young kid came to my office. I was leaving to join a consulting company, and this kid was my replacement. I taught him what I could, and showed him where to get help when he needed it.

    Years passed....

    Today, that "kid" and I again work for the same company. He has grown and become a well respected technical leader. It is a pleasure to work with him, and as I near the end of my career it gives me great satisfaction - and great memories - as I observe his continued development.

    As an aside, there is something in that article that brings back some less-than stellar memories. The comment that "they will just leave for a better job somewhere else" is the verbatim statement that one of my previous managers would make when denying employees time off to attend training.  In a way, that manager was right.  I no longer work for him...  😉

  • Don't inundate the employee. Give the new person small specific assignments that don't require broad knowledge (either SQL or company specific info), give them enough time without hovering  so they can figure things out by themselves, but be approachable if they have questions.

    We don't have formal mentoring, but any of the experienced workers are willing to help the new guy/gal.

    ...

    -- FORTRAN manual for Xerox Computers --

  • Very apropos topic for me. We've got a new, junior member whose joined within the last couple of weeks. I'll be working with her, handing off a project that I've worked on since coming to this job. At this point my boss and I met with her and her boss, to start the handoff. Later I gave a detailed description of the main players concerning the app that's involved (it's a line of business app) and some useful contacts. It is my personal habit to help a record of all of the projects I work on, in Microsoft OneNote. I've got 3 years worth of notes in there, which I've shared with her, by exporting the section in my OneNote notebook, for this project, then giving that to her. Next week we'll get together with the internal customer to learn more of what they do, etc. This should help her with picking it up.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Lots of positive happy stories so far. I do not disagree with them but want to offer another perspective for balance. 

    I think this is why having a good knowledge transfer process and documentation are helpful. You can ramp up someone relatively quick to be functional in some capacity this way. Bigger companies are better at this as they often have more established standard operating procedures, processes, and learning methods stored up. 

    Depending on just *how* junior the person is will tell what needs to be done. If they lack such basic skills to grow into being proficient then they should not have been hired and will likely be shown the door soon. That's what school is for. In my experience the problem I see is less about a senior engineer not holding their hand and walking them through everything but rather more a reluctance to learn, try, and persist. Depending on the industry or company culture you find yourself in - if you expect hand holding then you are in for a rude awakening.

    Ultimately I think it comes down to the junior person if they will be successful or not.

  • Jeff Mlakar - Thursday, September 6, 2018 8:27 AM

    ...
    Depending on just *how* junior the person is will tell what needs to be done. If they lack such basic skills to grow into being proficient then they should not have been hired and will likely be shown the door soon. That's what school is for. In my experience the problem I see is less about a senior engineer not holding their hand and walking them through everything but rather more a reluctance to learn, try, and persist. Depending on the industry or company culture you find yourself in - if you expect hand holding then you are in for a rude awakening.

    Ultimately I think it comes down to the junior person if they will be successful or not.

    Hi Jeff,

     In our case, we had a 20-year.old who'd been working with us for a few years as a junior sysadmin. He knew a little SQL, mostly MySQL, I think. He asked if he could join our team, we agreed and took him on with the blessing of upper management.

     He had some SQL, but not a lot. He knew the network better than all of us put together and he has the right attitude. He wants to learn. He is competent, patient, can accept criticism and can accept advice. As far as I am concerned, he is the perfect Junior DBA. He just needs experience. He has been told to ask if he doesn't understand or know anything, which he does. Better slow and correct than fast and wrong.

    Sean.

  • pwhoyt - Thursday, September 6, 2018 6:14 AM

    ...
    As an aside, there is something in that article that brings back some less-than stellar memories. The comment that "they will just leave for a better job somewhere else" is the verbatim statement that one of my previous managers would make when denying employees time off to attend training.  In a way, that manager was right.  I no longer work for him...  😉

    Denying a programmer access to training in an effort to prevent them from leaving; that's about as effective as keeping a cat on a leash to keep it from running off. It's a management anti-pattern that keeps repeating itself despite all the obvious evidence.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Sean Redmond - Thursday, September 6, 2018 8:52 AM

    Jeff Mlakar - Thursday, September 6, 2018 8:27 AM

    ...
    Depending on just *how* junior the person is will tell what needs to be done. If they lack such basic skills to grow into being proficient then they should not have been hired and will likely be shown the door soon. That's what school is for. In my experience the problem I see is less about a senior engineer not holding their hand and walking them through everything but rather more a reluctance to learn, try, and persist. Depending on the industry or company culture you find yourself in - if you expect hand holding then you are in for a rude awakening.

    Ultimately I think it comes down to the junior person if they will be successful or not.

    Hi Jeff,

     In our case, we had a 20-year.old who'd been working with us for a few years as a junior sysadmin. He knew a little SQL, mostly MySQL, I think. He asked if he could join our team, we agreed and took him on with the blessing of upper management.

     He had some SQL, but not a lot. He knew the network better than all of us put together and he has the right attitude. He wants to learn. He is competent, patient, can accept criticism and can accept advice. As far as I am concerned, he is the perfect Junior DBA. He just needs experience. He has been told to ask if he doesn't understand or know anything, which he does. Better slow and correct than fast and wrong.

    Sean.

    All of that sounds great! Also the SQL cookbook is a great resource for sure. I have had a recent success with someone we promoted to our team who lacked a good bit of the development part needed. I coached him and now he is pretty much as proficient as anyone else on the team. As much as I'd like to say my great management and leadership brought his game up that isn't the case here. I helped guide but he did the real work.

    I've also seen it not work out in the past. I love it when it works out.

  • Eric M Russell - Thursday, September 6, 2018 8:53 AM

    pwhoyt - Thursday, September 6, 2018 6:14 AM

    ...
    As an aside, there is something in that article that brings back some less-than stellar memories. The comment that "they will just leave for a better job somewhere else" is the verbatim statement that one of my previous managers would make when denying employees time off to attend training.  In a way, that manager was right.  I no longer work for him...  😉

    Denying a programmer access to training in an effort to prevent them from leaving; that's about as effective as keeping a cat on a leash to keep it from running off. It's a management anti-pattern that keeps repeating itself despite all the obvious evidence.

    +1 for the cat comment 🙂
    In our field I have always felt the biggest threat was becoming a dinosaur. Meaning having had skills at one point but not keeping up with current methods. These are the people I have seen hide away in large organizations trying not to be noticed and hording knowledge instead of sharing it. They think if they obscure their knowledge it will make them more valuable. All it does is set everyone involved back in the long run.

  • The one thing that I did myself that I learned a lot from was to create my own DBMS monitoring system. Make your own central repository of stats about the databases on your servers and just keep adding more and more detail to it. The point being to learn what the stats are, how they're collected, and how they're used/what they mean. For example, after collecting just the names of all the servers and all the dbs on the servers, I then started collecting space used, number of users, etc. Then I started collecting things like WAIT STATS. Getting to know the wait stats, what they all mean, etc has been one of the most important things I've learned in my early DBA career. Then I moved on to things found in the DMVs ... and just kept adding more things as I learned more. 

    I've been DBA for 10 years now, but still consider myself lower intermediate because I haven't been exposed to so many of the different facets of the DBA world. For example, I'm just now getting exposure to Report Services. I've never had to work with it or admin it before. Then there's AlwaysOn, SSAS Data Warehouses and Cubes, etc etc etc. One could go their whole career and not get exposed to a significant number of facets of the SQL Server DBA world. (But you'll still be expected to fix it within 10 minutes when it goes down !!)  

    You need a mentor to expose you to the things that are the most important. It can be overwhelming when you first start out. 

  • Jeff Mlakar - Thursday, September 6, 2018 9:02 AM

    +1 for the cat comment 🙂
    In our field I have always felt the biggest threat was becoming a dinosaur. Meaning having had skills at one point but not keeping up with current methods. These are the people I have seen hide away in large organizations trying not to be noticed and hording knowledge instead of sharing it. They think if they obscure their knowledge it will make them more valuable. All it does is set everyone involved back in the long run.

    oh yes. I'm definitely old enough (69) to be a dinosaur. But the trick to staying useful is to see what skills the department will need in the next year and try to quickly come up to speed on them.

    ...

    -- FORTRAN manual for Xerox Computers --

Viewing 15 posts - 1 through 15 (of 18 total)

You must be logged in to reply to this topic. Login to reply