9 ms·

Ask HN: Strategies for mentoring junior developers?

• crdoconnor 9y ago
  Pairing. Ideally let the junior drive. This is also a good way of getting new seniors up to speed on a code base they're unfamiliar with.
• muzani 9y ago
  Pair programming for sure. Senior designs the code, junior writes it. Senior doesn't touch keyboard. It's real time code reviewing. The senior's time is rarely wasted. They can always do time consuming high level work like designing test cases, planning out the next part of the work, seeing if the API supports stuff.
  • nunez 9y ago
    Your company has to have the right culture for this. Companies like this are rare. Most just assign whatever's in the queue to whomever's going to take it, meaning that everyone has "something" to do at all times.
    • meuk 9y ago
      Ugh, yeah, this is horrible. Especially if you're at a company which doesn't have any documentation, and the rest of the team is in another country with 3 hours of time difference, so you're on your own after 3PM.
    • crdoconnor 9y ago
      Companies that permit pairing are not rare.
      • nunez 9y ago
        They are in my experience with several large corps.
    • a-priori 9y ago
      I think the critical aspect here is the management system. Pair programming makes total sense when tasks are owned by the team. In that case it's in everyone's interest to improve the team's overall velocity. That means time spent mentoring juniors or working together on tasks is well spent. When tasks are owned by individuals, it's in everyone's interest to increase their own velocity which means maximizing time spent working on their own tasks. People are disincentivized from helping other people complete their work or mentoring them, because that directly reduces your personal velocity.
  • ctvo 9y ago
    Pair programming works for specific people, for others it's an exercise in anxiety. Especially in the scenario you're suggesting with a senior watching a junior write code.
    • proverbialbunny 9y ago
      Yep. Pairing a senior with a junior has showed that it does not often help juniors beyond the rate they'd normally grow at on their own. It appears like pair programming is accelerating learning when in reality it can actually hinder progress. However, pair programming has shown to accelerate growth when both peers are roughly at the same level. For some companies this means hiring two juniors and having them work together, but this isn't as common of a practice as it could be. One solution I've found to this is to subtly pretend to be forgetful and or anxious when pair programming with a junior. This lowers my level down to their level giving them growth potential. If the junior is anxious, showing anxiety about myself in a subtle way will lighten their anxiety. This works during interviews too. Being non-judgemental and friendly work too to melt anxiety away. If I am randomly forgetful from time to time, it gives them an opportunity to shine and help out leaving them feeling good and accelerating growth. Studies show that optimal learning has roughly 75% failure and 25% success. Is your jr helping you 20-25% of the time? How I encourage this growth is I start with forgetting a bit of language syntax, then a language idiom or two, then library syntax, then parts of the framework, and so on. The key here is to not show any sort of judgement. It's 100% okay if they do not know. That's part of the point. They have to look it up and figure it out and help out and grow. By doing this their level increases. My back story usually is, "Oh Python? I don't know that language. We'll have to run through it together." works like a charm as long as I start low and find their level, instead of overwhelming them. When pair programming with a junior I find 30 minutes to 2 hours at a time works best. It's slow going at first, but by giving them something to grow on, the second you leave them to their own devices they will continue to grow in that area. You can leave them alone sometimes for a week at a time and watch the results from a 30 minute pair programming session.
      • muzani 9y ago
        Yeah I think it's the vulnerability that's important too. Anxiety applies to the senior as well as the junior. Senior programmers feel they need to look competent. But much of software engineering means not knowing things and how to deal with that.
  • donttrack 9y ago
    I would leave, if someone made me do pair programming.
    • ben509 9y ago
      It always seems to be something that's a great idea for somebody else to do.
    • crdoconnor 9y ago
      Why?
    • hawaiianbrah 9y ago
      Have you ever practiced it? What’d you dislike so much? I’ve had great experience with it, and less than stellar ones too. It isn’t easy but it can be quite fun.
    • razodactyl 9y ago
      This is silly, you shut down the idea without any reasoning. I've found this a great way to get integrated into a new team and occasionally when banging heads against a wall trying to figure out an issue. In reality, pair programming happens very rarely but when it does it's very useful.
      • donttrack 9y ago
        I also hate team building exercises, so there's that. Just let me go home.
• Dannymetconan 9y ago
  As a junior dev one aspect of mentoring which I have always valued is being given time to explain to a senior dev how I am about to go about implementing a solution. This coupled with feedback on how I should change my code and why is great.
• ccccccccccccc 9y ago
  As a junior dev, keep us on the edge of just enough work and too much work. Too little work seems to cause disdain of the company (questioning why we were even hired) among my other junior peers. On the other hand, too much work causes us to burn out too quickly since we are still solidifying our time management and prioritization skills.
• Hydraulix989 9y ago
  The best thing to do is teach them to dig into problems, learn on their own, and think for themselves. They will have to learn how to deal with missing documentation and unclear/messy code. They will have to learn how to unblock themselves when they are blocked, rather than just getting stuck. They will have to learn how to work around obstacles and think outside the box whenever the immediate initial solution that comes to mind turns out to not be a working one. Coworkers shouldn't be treated as StackOverflow unless absolutely last resort because it is incredibly distracting to answer mentees' easily-Googled questions about built-in language API calls every 15 minutes or so. A lot of programming is just professional Googling. Once they can function independently, they are no longer junior developers IMO, but this is a learned skill. When I started programming, I had enough people on IRC berating and insulting me for asking about standard C library calls that I learned how to research and solve my own problems the hard way (the acronym "RTFM" is toxic). It felt awful, and I can imagine a lot of people getting discouraged and just giving up. I was in high school trying to write my own malloc just for fun, and random strangers on the Internet kept calling me an "idiot" because I was still learning pointer arithmetic and needed help (and nobody IRL could help me).
• DougWebb 9y ago
  I've always been a fan of assigning maintenance tasks to junior devs (or anyone who's new to an existing codebase.) These are tasks that are often lower priority so there is less time pressure to get them done right, and they give the devs the opportunity to learn the codebase. Working on existing code you don't know yet is also a lot easier than new development on code you don't know (and coding standards you don't know), so that makes it a better introduction for the new devs too.
  • b3arlythere 9y ago
    As a Junior - Intermediate Dev, I'd say these are usually pretty good places to start. These usually give the codebase some easy wins and help the junior build up confidence. In addition, since they're not part of the main project, it's not very stressful on the junior's side (assuming they realize that their work isn't blocking or holding up someone else). Probably one of the most stressful things I remember is trying to get up to speed as quickly as possible since I felt like I was holding back the work.
  • stronglikedan 9y ago
    Not to mention the smaller chunks of code to be reviewed, which has it's own set of benefits.
  • chrisper 9y ago
    This works, but guidance is needed otherwise frustration and demotivation could occur. New developers need to be told that it is ok to not figure out everything right away and asking for the solution is not "failure" but rather part of the learning.
  • ManlyBread 9y ago
    I understand the rationale, but after getting the "maintenance" role a few times it feels me with dread. Usually when I get maintenance tasks it's for a system no one else wants / dares to touch. Evey time I feel like someone punched me in the face because it's always accompanied with the words like "we need someone else to know this system", "it's only for a little while" and the truth is that if you gain minimum competency in such a system you can say goodbye to more fun tasks - the maintenance of this old crap is your life now. No company will let someone with a knowledge of some obscure shit stop maintaining the obscure shit and move that person to a project that doesn't suck. Currently this is the 4th time I'm tied up in such a situation and while I was promised to be allowed to work on the "more fun" project "after 6 months so I can get my feet wet" the very last day of these six months I was told that one guy is leaving the company and that I can't work on the fun project because the obscure shit won't have enough manpower. The corporate machine works so slow that it will take at least another six months before someone gets hired. Hell, they're so incompetent that they don't even have a job posting yet.
• deleted 9y ago
  [deleted]
• detay 9y ago
  - Pair coding - Periodic code reviews on codebase as a team (on weekly diffs) - Providing team a development guideline and enforcing it.
• bpowell 9y ago
  One of the best ways I found is to hire in pairs. Don't just hire one junior (or entry level) at a time. Hire two or more at once so they can help each other learn your stack. At the university I work at, this is how we handle it. We hire a lot of students to help develop our application. These students are far from entry level when we hire them. Most have taken maybe one CS class at the university level. It takes a lot of time to mentor these students, so one of the ways we handle that is have some of the more "seasoned" student developers help train. This works out very well for us, in that we have two seasoned student developers that help train the four fresh students we have. The questions that the newly hired students have can generally be answered by another student, because they probably had the same problem. While these seasoned students help out a lot, I still have to spend time mentoring and training. Be prepared to spend more time than what you think, but the rewards pay off in the end. Also it helps if you find what the developer is passionate about and maybe find work that aligns well with that. We had a former student that once we found out they wanted to do iOS development, we put them on that task and they really shined. It does take some work to find out what they want to get into, but it has worked well for us. As for getting up to the "senior developer" skill level, that is not something that we have baked into our student program. Once a student graduates, they can no longer work with us. It takes more than the typical 4-5 years to graduate university to hit that level.
  • monocasa 9y ago
    As somone who started the same day as another junior developer in my first job, I second this. Just having someone who's also junior who you don't feel any shame about asking stupid questions to is killer. You shouldn't feel any shame either way, but that's sort of one of the things you learn transitioning out of a junior role.
    • fdafellow 9y ago
      Would you able to divulge the name of the company?
      • monocasa 9y ago
• eysquared 9y ago
  I think this largely depends on where in their career they are and how familiar they are with coding in the environment they just found themselves in (large org, small company, startup, tech stack, etc). In general I find pairing a new hire with a less senior but relatively new hire to be a good way to get them ramped up quickly. Ideally this person has recently gone through the same process and can help get the new person unstuck. It also very much helps in the first few weeks to have a single point of contact to ask all the basic questions to get them up to speed before they feel comfortable reaching out to the larger org. After this its all about knowledge transfer and task management. Helping them understand why things are the way they are, not just how. There is a tendency for new devs to come in and want to change everything to be "better" without understanding the reasons for the current state of the world. Once they are up and running, giving them larger and larger tasks with less and less guidance will get them out of their comfort zone and needing to get better integrated into the team. They will need to ask for help from an area expert, sync with PM, and be responsible for something end to end (though likely already pre-defined by someone more senior). If they've made it past that point they should start becoming more autonomous and a great candidate to be a mentor for new devs coming in. Once they hit this stage, I find giving them more responsibility and less guidance can help them grow, fail, and learn. I could write a lot more about this subject but thats a general idea of how I look at the ramp up process. Getting to Senior is a whole different topic, but for context I've only ever worked at large tech firms so thats the only definition of Senior I know.
• nerdy 9y ago
  How you mentor has a lot to do with the particular topic and the relative knowledge and skill levels of the people involved. For example, if you're trying to teach TDD strategy then pairing might be best because there's a lot of nuance to how things are done. Environment setup. Tests come first. Make sure all the tests pass before moving on. Refactor between. So for TDD it would be difficult to provide a big list of dos and don'ts and expect someone to navigate them. Some skills are contextually less rigid than TDD. Debugging a problem for example: if a developer is trying to use an internal API but they are getting a timeout response instead of any actual output. You could simply tell them to see if the HTTP server is running, but it's probably better to ask questions and explore the problem vicariously. "What do you think the problem could be?" Then you can arrive at gaps in their understanding about how the system or HTTP servers work. Asking questions when there's that too-familiar "we've gotta get this stuff done" atmosphere can be challenging. It's tempting as a senior developer to just provide the answer without slowing down and exploring the problem with your junior counterpart. There's also institutional teaching. Is the junior developer asking questions which should be addressed in documentation? If so, you should probably commit those answers to the documentation and have the developer act as a litmus test for the completeness of the information. So teaching can be showing, sometimes it's a matter of explaining, and other times it's more important to just ask the right questions. I think one of the most important parts of teaching is perspective-taking. You want to explore the areas just adjacent to the person's knowledge. Also, blameless postmortems. It's easy to point fingers when shit goes wrong. Don't. Developers junior to me ask questions which I find border on alarming sometimes but I suppress that reaction because I would rather fill those dangerous gaps than have a developer be too scared to ask.
• kodablah 9y ago
  Give em small projects and code review them big time (kindly of course). Accept a bit of argument (i.e. don't get hung up on requiring humility from the junior, mistakes bring that on their own). Do not be time constrained on these initial projects but keep on top to prevent interminable bike-shedding or pursuits-for-perfection juniors often have. If no improvement is shown over time, there is just not much you can do...sometimes mentoring means recognizing when it's fruitless.
• locopati 9y ago
  Encourage questions - there are no stupid questions (annoying questions, maybe, if it's something you've already answered a bunch of times - lazy questions, maybe, if it's something that could have been easily looked up - but even those have responses to help learning what questions to ask and how to ask them). The biggest gap I've seen between being junior and being senior is breadth of vision. So, my mentoring challenge has been to get junior devs to see the big picture. This means looking beyond just their specific chunk of code to understand how their decisions affect other parts of code and other developers. I often use the idea of 'future-me', as in, how will future-me think of now-me if I go ahead with this implementation, if I don't write good tests or comments (where future-me includes other devs, especially those who may not work for the company yet).
• therapeutic 9y ago
  As a junior dev, I've appreciated small signs that other people in the office are looking out for me and my progress. This can be anything from regular one on ones with my direct manager, to other engineers asking if I have any questions when working in a new codebase. I'm the only junior in my office, so at first it was kind of horrifying asking questions and looking for help. Since other people have been more proactive in making sure I'm set up properly I've felt a lot more confident in taking steps on my own to figure things out and I think it's helped a lot.
• scarface74 9y ago
  I very much struggled with training a junior developer that cane out of a boot camp. I couldn't teach him how to logically find an issue just by tracing the data flow. While I stagnated for years and became an "expert beginner" (https://www.daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/ https://www.daedtech.com/how-developers-stop-learning-rise-o...) at one company, I've never been a "junior developer". By the time I got my first job at a small company, I already had 10 years of experience as a hobbyist and knew how to program. It's easy to mentor someone who knows the fundamentals of how to logically break an issue down and throw out some ugly code to get them to a "clean code" stage or even teach them a language. But if they already know the fundamentals of development as a junior developer, it's pretty easy to get to the next step with time, lunch and learns and reading a lot.
  • proverbialbunny 9y ago
    It's rather easy to teach these basic skills. Breaking a problem up is as easy as that: your description of it teaches it. The trick with newer programmers is to take an abstract concept, such as that, and then bridge it to a concrete pattern that can be visibly seen and explored. You have to demonstrate, often out loud, your thought process while you're working through a problem, much like a job interview. Also, you'll want to go slow enough they're comfortable asking questions, taking notes, and doing google searches and what not, or only having very small talks at a time like 5 min at a time small slices. Usually you'll want them at the keyboard to learn debugging with you over their shoulder, but if their skill level is absolutely basic, then you might want to be at the keyboard, and just run over problem solving of a easy 5 minute problem. By watching you run through a debugger and watching you google search for help (bonus) will give them enough idea to start doing it themselves, then in a couple of days you can switch and have them at the keyboard.
• fdafellow 9y ago
  "Software development companies are often willing to hire developers who need a lot of guidance and direction." Is it in US? As a developer with 1 year of experience I find most of the companies are looking for only junior(3-5 years) or mid(5 - 7years) or senior(7+ years) of experience.
  • chrisper 9y ago
    Where are you located? I am in Europe as well and we consider Junior 0-2, Mid 2-5 and senior 5+.
• csnewb 9y ago
  Out of curiosity, how many years of experience categorize a developer as "junior"?
  • rkho 9y ago
    I don't think it's about years of experience -- someone who does the bare minimum for five years and never provides input could very well still be categorized as "junior"
    • chrisper 9y ago
      Would that also work the other way? Someone providing a lot of input within 2 years is to be considered senior?
      • troebr 9y ago
        It's all about what they bring to the table. Some people are clearly senior level after 2 years: they communicate well, they can mentor other engineers, they can criticize an existing design or plan the implementation of a new feature, have good organizational skills etc. After 2 years I wasn't able to provide constructive feedback without being a little too brash, I couldn't have designed anything distributed, I wouldn't have been able to break up a gigantic feature into smaller problems etc. I've worked with people who were technically competent and mature 2 years after school.
• songzme 9y ago
  Don't write code. Break down a feature into tasks that you would take 30 mins or less to accomplish. Have them build each task one by one. If they take longer than 1 hour, you know that they are stuck on something so you can go help them. While they are working on 1 task, you are figuring out the next 2 tasks. Your job becomes quick prototyping to make sure the tasks are feasible. Eventually, after many small merge requests, junior developers will be comfortable to take up entire features. After a few features, you teach them how to break down tasks for other junior devs, just like what you were doing before. We have been actively following this method for the past 2 years and have taught engineers with 0 coding background all the way to become tech leads in our org.
  • jbhouse 9y ago
    Sounds super interesting, though it's not something I've heard of before. Is this a common practice I haven't heard of or a process unique to your company?
    • songzme 9y ago
      It's not a practice we have read anywhere, it's something we experimented with and worked
• bensummers 9y ago
  My company has put a lot of effort into helping junior developers get a really good start to their careers. To a certain extent, you have to structure your work to enable this. I'd suggest seeing the support as a wider thing than just the activity of mentoring. I wrote some notes: https://www.haplo-services.com/blog/2017/working-with-early-stage-developers https://www.haplo-services.com/blog/2017/working-with-early-...
• d0paware 9y ago
  I think probably one of the most valuable things you can do with your junior developers is to set expectations around how to ask good questions. Your goal is to help juniors strike the right balance between spending time figuring something out on their own versus spending too much time and going way off track. You also don't want your juniors to ask too many questions that they should have first spent some time investigating on their own. There's a good link on this: How to Ask Good Questions (https://news.ycombinator.com/item?id=13293301 https://news.ycombinator.com/item?id=13293301) Other than that, I think having a junior shadow you while you debug a bug or help them debug one of theirs while explaining each step you are doing is also very helpful. Something else that's pretty good is to give juniors a shining example of a high quality SPIKE task on a new technology or design consideration. You want them to learn by example. And here are some other links that I've found personally helpful: https://softwareengineering.stackexchange.com/questions/138396/how-to-mentor-a-junior-developer https://softwareengineering.stackexchange.com/questions/1383... For you: Ask HN: How to manage developers who "aren't very good" (because let's be honest, we've all had this sentiment before whether or not the developers were actually bad or not) https://news.ycombinator.com/item?id=9008845 https://news.ycombinator.com/item?id=9008845 For your juniors, to give them something to aspire to: On Being a Mature Engineer https://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/ https://www.kitchensoap.com/2012/10/25/on-being-a-senior-eng... Ask HN: How to Be a Good Technical Lead? https://news.ycombinator.com/item?id=10395046 https://news.ycombinator.com/item?id=10395046
• bertil 9y ago
  Junior developers and newbie in general have one incredible quality: they don’t know and they are not supposed to. You absolutely want to tell them that their role is to criticise and occasionally write the documentation. Start from things that are obvious and leverage their question: anything they ask, tell them it’s now their role to document it. How the business makes money, what that metric means, what is TDD, what happens with this fails, whether the company actually ships bug-free code. One pattern that I use: - pair program initially; I would do that even for principal, just to be familiar with the code base, but for probably one or two days, after that, they should be autonomous; for very junior developers, a week make more sense, but rarely more; - gradually replace that with code review, but more than once a day for more junior people; ask them kindly to commit; make sure to point out one or two issues in each very small PR: linting, method naming convention, then testing patterns, structure, etc. - have scheduled 30 minutes 1:1 meetings, preferably thrice or twice a week; make sure there is something nice at some of those: ice cream, walk out if it’s sunny, and have that meeting have four very explicit parts: what they have done, what blocked them; what they have learned; what they have taught (or documented). The last one is often overlooked but it’s very important for them to realise that they start owning some code, that they should think not of they direct impact but how to empower people. React to blockages by offering solutions, both from them and from you: they need to learn to unblock and that’s how you do it. Move that meeting to once a week for senior developer, once a fortnight for principals.
  • humanrebar 9y ago
    > ...make sure to point out one or two issues in each very small PR... And try to bring up one or two improvements or good ideas. Being a proper critic involves praising things as well as panning them. If they weren't good at something, you wouldn't have hired them. If the entire review is straightforward an unsurprising, that's actually a good thing. Say it's very clear and easy to work with.
  • mdn0420 9y ago
    In my experience, pair program is especially valuable for learning workflow, tools, debugging tricks, etc. For instance, I remember learning how to efficiently navigate a project with an IDE through pair programming. For ramping up on codebase/architecture, I prefer a brain dump then go off on my own and ask questions as needed. Every person has their own method and preferences of course.
• rdsubhas 9y ago
  (assuming mentoring them with the objective of becoming "engineers" rather than staying developers) Many code pairing/reviewing strategies assume that the mentor is the one who has to teach everything on the job. Its not true, it slows everyone down and leads to "lots of talking" and less coding. Don't by shy of making them have a follow up learning checklist. When you are pairing or reviewing, leave them links that have helped you on the past, or give them concepts that they should learn in order to more effectively do the same task. The next day, ask them if they have had a chance. Not as a way of "control", its totally fine if they don't, and its also totally fine if they have "glanced through" theoretically. If they are eager to learn, they'll be asking you more questions back, and you can fill in the gaps (or point in more directions). Its as much an effort of the mentee as the mentor. Junior developers often just need "direction" because they don't know what they don't know. But they're quick to explore further only if pointed the way. Give them the resources they need to learn, not necessarily the learning itself and keep following up. Contrary to many opinions, juniors like having tough mentors (which is why mentor should not be a reporting figure). Communication and social skills are a large part of development. You should also be guiding them specific to the organization context, whom to reach for what, how to communicate better in different circumstances, how to reinforce basics (writing tests), make them present something they learned, help them build visibility by attending meetups, how to make decisions on technology, how everything has tradeoffs, how to negotiate their salary, how to talk product stuff with product (biz to biz, qa to qa, executive to executives), how to escalate from personal > IM > emails > calls > meetings, habits like task tracking and learning to estimate by slowly working on complexity points and matching up with their "self velocity", how to say no to more tasks and avoiding burnout, etc. The mentor only provides useful guidance, but in the end, the execution is up to the junior and the context of the problem they're working on. Ideally they should also not be having one mentor, but many with different styles and opinions.
• Insanity 9y ago
  You can ignore pretty much everything I wrote underneath, but if one thing, I feel like this video really helped me as a senior engineer: https://www.youtube.com/watch?v=m6G8f9pZZRM&t=1594s https://www.youtube.com/watch?v=m6G8f9pZZRM&t=1594s Don't see them as a 'nuisance' or something that's not "part of your job". As a senior developer, it is at least implicitly part of your job to mentor junior developers. It helps to really take out time to help them, I schedule some sessions in which they can ask anything about anything related to programming. The language we are working in, the program we work on, general computer science questions. This has received quite positive feedback overall. Often junior developers are scared to ask questions because they 'know' they are 'wasting' your time with their questions.
  • btbright 9y ago
    I was going to post a link to that video, too. Great talk!
• sixhobbits 9y ago
  I've seen several people mentioning pair programming, which I haven't found useful (too much time wasted while one person is coding the "easy" parts, and not enough time for the more experienced person to think about the difficult parts. YMMV.) In my experience, the most helpful way is 1) code review. Several iterations of all new code. Efficiency, style, correctness, smaller functions, don't repeat code. This takes time, and as the person doing the reviews, you might feel like you aren't getting anywhere, but a few months done the line it will be very rewarding when it finally "clicks". 2) Looking at code and theory in 1:1s. Normally I spend about 10-30 minutes on HR type stuff and the rest of the ~1h 1:1 is spent on training/mentorship. Sometimes looking at specific code reviews and explaining reasoning behind the comments in more details. Sometimes it's to fill in gaps in the person's theoretical knowledge about syntax, algorithms, style, unit tests, caching, whatever weaknesses were identified. 1:1 time and code-review should form the basis of all coding education at all levels IMO. Shameless plug for HyperionDev[0], the coding bootcamp provider I'm working with where we focus on 1:1 time and code review both for our customers and for our dev team. [0] https://www.hyperiondev.com https://www.hyperiondev.com
  • hawaiianbrah 9y ago
    one of the pair can tend to other things while the other is hammering out the “easy” parts... as for the “not enough time for more experienced person to work through the hard parts”, isn’t the point that it’s a partner activity? the idea being together, you’re going faster
• Jach 9y ago
  I think the lack of explicit programs is because the path is often "stick around long enough to have enough things you can point to that look similar in complexity / effort as other things people with the Senior title have done." If all those things require relatively little hand-holding then the solution is just progressively less and less hand-holding, often in the form of "toss them in the deep end and only go hold their hand once they ask for it". That has some negative incentive structure of course, but so do other suggestions proposed here... Maybe instead focus the mentoring on becoming a better dev. Have them join your book club (or paper club, talk club, blog club, whatever) that you in theory already have going on where engineers at whatever levels get together and discuss a topic and how it can be applied to make them better engineers or have better team dynamics etc. Maybe do some applying exercises / experiments too. The "junior" and "senior" distinction isn't very important beyond salary negotiation, and often the "needs guidance to excel" or "not fairly independent yet" criteria can be misleading too because it's somewhat sensitive to the work and work environment in question. If you really want to mentor a junior into a senior you just need to make them more like the what-does-this-company-mean-by-senior person, which might not correlate very well with good engineering at all and can differ quite dramatically from company to company.
• xsmasher 9y ago
  Make sure you foster a culture of asking dumb questions. It should be clear to all of your developers that they should ASK whenever they are stuck, or don't know something, or when they need a rubber duck. We have a "stupid questions" chat channel at work, and juniors and seniors alike are expected to use it when they need advice. If new developers see everyone putting their egos aside and asking for help, they are likely to follow suit.
• sheepmullet 9y ago
  The most important thing is to allocate enough time to help them - 20 hours a week for 2-3 months followed by 10 hours/week for the next 1-2 years is usually enough.