How Do I Motivate a Junior Developer?

Question

Background

I'm a Team Lead for a software development department and about 4 months ago I began aggressively spearheading an internal program to hire and train up junior developers, specifically focusing on candidates with other real-world experience looking to make a career change into software development but with no experience in software development. We administer objective tests looking for characteristics we believe act as markers of high potential in software development (abstraction, symbolic math, etc.), do interviews, check references, etc.

I ended up hiring a junior (our second) who is acquainted/friends with some members of our department (myself included) who met all of our requirements, based on the idea that he'd integrate well; he passed through the tests very well and came with good references, shone in the interview with people who didn't know him, and everything was great. Since I'm in charge of the Junior Development program I tasked him to studying using Treehouse, Microsoft Virtual Academy, Pluralsight, etc. and gave him access to our corporate account for all of these resources - I never made any progress in these things formal parts of his job duties, but absorbing this information in a timely manner keeps him on the curve for our achieving our base functional level for promotion to associate within a year. Additionally, myself and the other members of the team regularly pair with him and generally make him "drive" while we navigate, in an effort to pass along information in a practical context and give him an opportunity to ask questions.

The Problem

Despite our best efforts to help him learn, giving him additional resources to come up to speed, and flat-out asking what he needs we're not seeing any significant improvement - to the extent that I'm skeptical if he is actually using the educational resources or not. He regularly neglects to use resources to look up problems and asks us about trivial things, or worse, head-butts the situation with brute force until he gets frustrated and quits paying attention; part of this may be that because he isn't learning the fundamentals he should be picking up from educational resources, we think he might not have the context-knowledge of how to search for what he needs.

To compound this, lately we've noticed he drops his attention much easier and starts messing around with his phone or otherwise getting distracted, either while we're "driving" during a pair to show something complex or when he's running a build (takes 15 seconds to complete the build, but he spends 5 minutes on his phone), and his phone goes off CONSTANTLY throughout the day, causing context switches. These seem minor, but 20-30 times a day between builds and phone buzzes ends up eating quite a bit of time; it's as though he thinks that being a developer gives him a free pass to mess around since it's not "real" work (my perception, not sure about the veracity).

I'm not sure how to get through to him that he needs to focus and put more effort into his learning, AND pay attention while at work. My goal is to be understanding and professional, so I want to find an intermediate step to show that I'm serious about him needing to shape up before going to an extreme like a PIP or a formal write-up.

Answer 1

I never made any progress in these things formal parts of his job duties

That may be part of the problem.

People (and particularly juniors) respond to incentives. It's possible this individual is focusing on whatever he views as the formal parts of his job duties and not so much on these other tasks.

it's as though he thinks that being a developer gives him a free pass to mess around since it's not "real" work

I'm not sure how to get through to him that he needs to focus and put more effort into his learning, AND pay attention while at work.

Has anyone mentored him so that he understands what his "real" work is? This is a person who hasn't been a developer before.

If you are this person's boss, you owe it to him to provide feedback about his work - both good and bad. This should preferably happen in a one-on-one meeting weekly.

You may need to make it clear what he is doing well and what he is failing at. Clearly you aren't happy with his behavior. Now you need to let him know that and show him how to do better.

If part of his job is studying using the resources you gave him, it should be part of his formal job duties. If developers are expected to avoid personal calls during work time, it should be made explicit.

Wouldn't you do the same for non-junior members of your team?

And at some point you may want to circle back on the criteria you use for choosing new junior developers. Although your sample size is currently small, perhaps this case indicates that you aren't quite using the right filters. You want to make sure your objective tests are actually measuring characteristics that predict success in your environment. As you are finding, there is more to a good developer than abilities for abstraction, symbolic math and such.

Answer 2

What you have done is failed as a manager. You have taken someone with no experience and let him flounder around on his own and not said anything when no progress was being made. You had no plan and thus he had no plan.

It's ok to want to hire smart people and they train them up as developers, but in no case should you expect that person to just learn on his own through videos and books. That is creating an unfair situation. If you want these types of hires, you need an actual in-house training program where they do the training in front of someone experienced who can provide the information in a structured manner, guide them and answer questions, and insist on doing exercises and taking tests so that you can evaluate if they are making enough progress to remain in the program.

You need a training course structured to the very things you need to get them up to speed on so they can work in your particular environment. So if you don't use functional programming for instance, don't let them spin their wheels for three weeks pretending to learn that when they don't yet know what they need to know in the language set you use and the techniques necessary to solve the kinds of problems you do have (a web dev will have a different set of problems than a database dev or an embedded systems dev or a mobile app dev).

Then you have a progression of the types of tasks you expect them to do. Make specific assignments and let them flounder for a couple of hours/days (or whatever is appropriate to the problem) and then sit with them and ask them specifically what they tried and didn't try and then, never touching the keyboard yourself, you lead them through how to solve the problem through the Socratic method of asking leading questions. Then give them another similar problem and see if they learned anything.

Frankly if you or someone working for you didn't spend at least 100 hours of prep time (probably more) developing a program for training before hiring this person, you failed them.

Then once they can solve some simple problems, you add in code review of 100% of all their work and if they need to fix something, they have to fix it, you never do. Once they are doing training tasks at a level that could go into production, start assigning real tasks. Again, 100% code review is the rule and no matter how close the deadline, they have to fix it themselves.

Even if you don't have a specific trainer (which you really should if this is your hiring plan), you should have had a specific plan for what you want them to learn in what order and question them about (or have them demonstrate) what they learned every single day. They will need to do something similar with daily SCRUM meetings, so get them use to showing daily progress from the beginning from the beginning. They need to know that their training is work and you expect daily progress and that they will put in the hours to make it so. Give them specific problems to solve in a training environment that you can refresh to the original state if they mess up (Old bugs you fixed is a great place to start for getting exercises.)

The phone thing you should have talked to him about the first day it happened. Now you need to tell him, that his phone use is inappropriate and then explain teh limits on it.

As far as incentivizing? At this point keeping his job and his paycheck is the incentive, you don't reward bad behavior with new incentives.

Frankly at this point, the guy sounds like he is clearly not interested. BUt to be fair (since you failed as a manager) you should have a heart to heart talk with him about what is expected as a dev and does he really want to put in the time to get up to speed. Then tell him what you expect and how you will measure his progress and that his job is at risk if he does not make progress. (It's amazing how many poor performers have no idea their jobs are at risk, a manager need to explicitly tell them when it is.) And if he has made no significant progress after two weeks, I would start the HR process to let him go.

Answer 3

You share the blame for this problem

• He needs to step up to the plate and show you he is serious about this career path.
• You need to be clear and upfront when discussing his performance.
• His problem is a combination of:
  • You didn't set clear expectations.
  • He hasn't put forth the required effort.

About the resources:

If he says he hasn't used the resources you provided, ask him why. Did he not think he needed them? Did he think they were too hard or too easy?

If he says he has used the resources you provided, ask him why it isn't showing in his work. Has he not put forth enough time to benefit from them? Has he been using them for topics other than the ones related to his job?

Let's pretend he is a Jr Java developer and your company's flagship product is an enterprise ERP. Has he been spending him time learning another language using those resources? Does he see this job as a stepping stone necessary for him to get experience and work in some other industry?

Talk to him about his career goals. Tell him about how he can reach those goals inside your organization.

Ask him how he feels about the work he's doing. Does he think it's not challenging enough? Does he have real expectations about what "being a software engineer" is all about? Does he think he is going to come in as a Jr dev and spend most of his time implementing new features as opposed to fixing small bugs and receiving honest feedback on the quality of his work/code?

Friends and business should be separate

Friends should be friends, but inside of a professional working environment you must always act in the company's best interest -- even if this strains friendships.

I ended up hiring a junior (our second) who is acquainted/friends with some members of our department (myself included) who met all of our requirements [...]

I suspect that you have been walking on eggshells and have not been clear enough when discussing his performance. Perhaps this is because you were already acquainted with him and you don't want to hurt his feels. Maybe you don't want to give him negative feedback and so you subtly try and encourage him. It doesn't seem like this is working very well for you or for him.

[...] he drops his attention much easier and starts messing around with his phone or otherwise getting distracted, either while we're "driving" during a pair to show something complex [...]

When this happens, you should advise him that he cannot play on his phone while you are pairing. Maybe he thinks that pair programming means "one person works, the other takes a break". To somebody who hasn't worked in software development before, he may share this misconception.

Explain to him that he is supposed to pay attention even when he is not driving, and that he needs to be listening to you as part of his job.

You need to outright ask him if he has been using the resources you gave him.

It sounds like you believe this hire isn't working out, and if he doesn't change he may be let go rather than "not promoted". Have a 1:1 with him and lay out all his performance issues. Be clear in your criticisms and offer ways that he can improve his performance.

Be careful when you give him this feedback to give him good feedback as well. When I give feedback, I try to avoid using the word "but". This word is almost always followed by a criticism and likewise negates the affirmation precedes it.

Replace the word "but" with "and" -- I affirms that you are being sincere regarding the criticism and the affirmation.

Consider this example:

but

[Name], I want you to know that I see great potential in you but you're not making the progress [company] expected of you when you were hired. We believe you are capable of coming up to speed but you need to focus on developing your skills. When we hired you, I recommended sites that provide tutorials but you haven't followed through with using these resources.

We really enjoy having you on the team but your performance has to improve. If we don't see those improvements, the next step will be a PIP. I wanted to talk to you in advance, in case you were unaware, so that a PIP won't be necessary.

We're willing to do as much as we can to support you, but you need to learn how to find answers on your own. If you're still struggling with a problem after researching possible solutions, come ask us for help. Explaining what you've done to find the answer yourself will make it much easier for us to help you learn how to tackle similar problems in the future.

Nobody picks these skills up overnight. Learning and developing these skills in your free time may seem difficult, but, you're expected to make the effort.

and

[Name], I want you to know that I see great potential in you and you're not making the progress [company] expected of you when you were hired. We believe you are capable of coming up to speed and you need to focus on developing your skills. When we hired you, I recommended sites that provide tutorials and you haven't followed through with using these resources.

We really enjoy having you on the team and your performance has to improve. If we don't see those improvements, the next step will be a PIP. I wanted to talk to you in advance, in case you were unaware, so that a PIP won't be necessary.

We're willing to do as much as we can to support you, and you need to learn how to find answers on your own. If you're still struggling with a problem after researching possible solutions, come ask us for help. Explaining what you've done to find the answer yourself will make it much easier for us to help you learn how to tackle similar problems in the future.

Nobody picks these skills up overnight. Learning and developing these skills in your free time may seem difficult, and, you're expected to make the effort.

Answer 4

I guess my question is this - what are you doing?

You ask how to incentivize this guy - but then effectively say "and i have to incentivize him to be a developer".

And now you're wondering what goodies to throw at him to make him excited. This is just poor form on your part. You don't - you cannot, really - incentivize someone to be good at something they dislike. You can throw money at it - and maybe even a lot of money (although, hahah, developer, so we're not talking a life-changing lot) at it.

But that just means you have someone with a lot of money doing something they don't want to do.

You say this person is smart - that means you should want to keep them. Smart people are worth more than well-trained or experienced people.

Now the trick is to find out what this person actually wants to do. Why not ask them? And ask them honestly - try and find something for them to do that matches what they want. Does this person want a leadership position, or a client-facing role? Offer that - offer it a day a week, anyway - on the condition that they have to learn whatever it is (because, you know, they will need it for the presentation or the leading).

Learning by teaching is also massively underused - I blame our school system - so why not ask him if he wants to make a presentation on something. And then help him make it, and then watch him flounder - but also learn.

There is more to a functional member of a software team than coding - there is leadership, planning, co-ordination. Or perhaps this person has some health issues or out-of-work issue that is causing all this?

You need to find out. Most people understand that the phone ringing all the time isn't cool, so this is either showing

1. something is wrong outside of work
2. the individual is struggling with work

From what you say it could be either.

Telling this person that they are underperforming is fair advice, but also useless. It's like having a subordinate tell you a problem - you generally want to hear "this is the problem, here are some proposed solutions". You are the leader here, so you need to come up with some leadership to help this person out. Because that is what leadership is, really.

Answer 5

I am a junior developer and I was in a situation where is that guy/kid. I have got a job as mobile developer to develop android and ios apps in xamarin(c#). Since I have been surrounded with people that are in open source world and use Java, Python, etc. I have accepted the job as the only way to become a developer. I hated C# because it has things that I couldn't overcome and sintax is different from Java's.

Soon after I was bored, burned out and stopped to think because of that. I couldn't google for an error message, I have chat all the time on work. Couldn't read simple text for 10 mins without loosing my attention.

Also I have to mention that my team leader wasn't there when I was really in problem. He put me in production to write featueres that will be announced in a 2 weeks. That was frustrating for me.

The conclusion: Joung people needs something interesting to work on, big corporatios are stopping them to find what they want to become. I was scared and after some time I realise that my team leader is not the leader but just figure.

The solution:

Try to talk to him and explain if a project is boring he needs to say that. Also he needs to learn how to use google :) Maybe this sounds stupid and silly but it is true. Especially if English is not his native language. Junior developers need good leader and leader needs to be patient. Imagine that you need to learn how to perform heart transplantation. And some guy who is specialist at that tells you that you need to know trivial opening and closig chests for that performance :) You got the point? Gl hf

Answer 6

Your question has tons of answers, the one that works for me the most is: challenge this person.

Now focusing on your situation, this is already a dead end, the guy has lost interest in the job so if you really want to bring your Jr. back into the game be clear to him and put the dots in the i's: "you catch up or you're gone".

After the scolding, the best you can do is to explain why all you try to explain is relevant and drop some challenges, even if he sucks at solving them, he will end up either learning or giving you a starting point for assessing his job.

Although, if the guy is just not willing to push himself then just move on. I know it sucks to fail as a lead, even when this is out of your control, but you both will end up learning.

Answer 7

Does your company use anything like Gallup's strengths finder? I don't believe any of it but if you matched tasks to his strengths, he may have an increased response- even if due to a placebo effect. For example, pair programming for someone who likes people, or a todo list for an achiever (he doesn't sound like an achiever).

I'd raise an eyebrow to anyone who claimed to have a motivation technique that worked acroas the board.

Answer 8

specifically focusing on candidates with other real-world experience looking to make a career change into software development but with no experience in software development

Well, sorry but that's what you get for hiring someone that wasn't formed to be developper. We don't do years of study (school or self taught) to be replaced that easily by some weeks of self formation.

Developping is not about only some training, it takes pratices to stop only to see brute force solution and seeing others alternatives. 90% of developping is thinking and learn technologies/method of coding (aka pattern), raw coding is 10%, and I'm very generous with that number.

If you want to persist : get them practices and review them.