At what point should one give up?

I've tried helping them out by having them shadow me. We agree to break a minute, and then they go missing in action for a while...then just go back to their desk. Even when I know they've done this, part of me feels like I shouldn't have to go get them but that they should be showing interest in learning. Frankly, it's a bunch of time I don't have explaining things as I go when I could just do it. Am I expecting too much to expect that if they want to learn they'll make sure I know they're ready and willing?

They go to meetings that they were not told they had to attend...good, but then sit in the corner and sleep...bad. I don't even know what to do with that.

Sometimes I give them something small to do and they do it great, so I give them something just a touch harder and they totally fail, hard.

They check in things without testing them.

Part of me thinks that maybe I should be spending more time with them but at the same time I don't see a lot of interest and I really, honestly don't have time teaching the same things over and over. Sometimes I get asked questions that are really, really easy to answer if you just do a little bit of your own work trying to find out. Other times I'm not asked anything.

I'm sure I could be doing better but honestly...I don't really want to anymore.

  • 29
    Do NOT give check-in access to juniors/interns especially if they have joined recently as they may end up breaking stuff more than they build. Do patches/code-reviews for first few months and see the progress before giving them more responsibility.
    – Simon
    Commented Mar 8, 2011 at 4:01
  • 3
    Are these folks paid employees, or are they volunteers? Commented Mar 8, 2011 at 5:42
  • 1
    @Simon: As someone who broke the daily build with my very first commit as a new hire, I concur. Commented Mar 8, 2011 at 17:54
  • 6
    Is there a "rant" tag? I quite enjoy these questions sometimes.
    – Armand
    Commented Mar 8, 2011 at 18:14
  • 3
    A little effort is worth it with juniors, but if your arms get tired, or your knuckles start to bleed a lot, then they’ve probably had enough. Commented Mar 9, 2011 at 0:14

15 Answers 15


Wait, what? These people aren't gone already?

It sounds like a management problem to me. Why else would anyone like that still be there?

Assuming you have management support, what you need to do is give them specific, written expectations that are measurable. Calmly and politely (even cheerfully) tell them that these are the things you expect from them. Make your goals specific and realistic. Document everything.

When expectations are not met three times, terminations are in order.

I mean, c'mon. Sleeping in meetings? That demoralizes everyone.

One more thing: You may not be vetting your junior developers properly. You need to find junior developers that are eager to start their career, learn new things and become better people. Those are the keepers.

This is going to make me sound like an old fogey, but young people nowadays get their first job and wonder why they don't own the company in two years, and why they aren't changing the world writing the next Facebook.

Part of this process is managing expectations.

  • 1
    IMPORTANT NOTE: This question assumes that the junior developers are paid employees. If they are volunteers, you can't do this. Commented Mar 8, 2011 at 5:43
  • 15
    I think even with volunteers there are expectations. For instance, on SE sites, if you're a moderator that doesn't follow and meet the expectations, you can be removed, and volunteer moderators aren't paid. I think your points are equally valid for both employees as well as volunteers. +1
    – jmort253
    Commented Mar 8, 2011 at 6:05
  • 10
    Volunteers should not be wasting people's time either. They can go sleep somewhere else.
    – JeffO
    Commented Mar 8, 2011 at 9:12
  • 3
    @jmort: Agreed. I have seen places, however, that treat their volunteers exactly like they're employees, with the same expectations as employees, and that's not really realistic either. Commented Mar 8, 2011 at 15:13
  • I think it's a middle ground. There should be expectations, but those expectations would be different for volunteers than employees. I still think your point is valid for both classifications.
    – jmort253
    Commented Mar 9, 2011 at 6:18

I would have fired them at the part where they fell asleep in a meeting. Checking in code that isn't tested is not a mistake when they do it repeatedly, thats carelessness. I would confront them with exactly what you told us and ask them bluntly if they want to continue their career path.

  • 3
    If the meeting is at 9am, then I cannot blame these 21 year olds.
    – Job
    Commented Mar 8, 2011 at 15:09
  • 7
    @Job: Sure you can. Commented Mar 8, 2011 at 16:11
  • 1
    @Job: 9am? seriously? You show up when the hours of your meetings are, ready to listen, take notes, and make appropriate contributions. Commented Mar 8, 2011 at 20:26
  • 2
    @Paul Nathan, 9 AM meetings would be a deal breaker for me. In college I never got an A in a class that starts before 10:30 AM. At work I have been quite unhappy with the daily 9:30 AM ones, even though I have made then 98% of the time (there is always traffic). This is not because I party up after work; I am simply not a morning person. If I had kids, then perhaps I would probably gladly come in at 7 and leave at 3 PM. I know some people with kids who had to attend meetings at 5 AM with teams abroad. Most of them quit. I take it that sleeping preferences are a big deal. Flex time is nice.
    – Job
    Commented Mar 9, 2011 at 0:30
  • @Job I am a junior developer and I get to work almost everyday before 7:30 and stay until 4-4:30. Although I am a bit older and I have a human alarm clock(read: 2 year old) that gets up at 5:45 everyday! Commented Jan 21, 2012 at 9:09

Give your interns more freedom

As an intern myself I acted the exact same way when I was told what to do, how to do it, and when I had to have it done by. My internship felt more like a school assignment than like I had the opportunity to get a truly educational experience from it. To make a long story short I confronted my boss about this: He's an awesome guy and switched to giving me a general idea of what he wants done (Make a program that does X, Y, and Z) and lets me code it my own way. Ever since then, I've gladly put in sleepless nights for the internship and I now feel like I'm really learning instead of just imitating. My boss and I are both really happy with what I've accomplished so far.

Also, I think this video describes what motivates programmers pretty well.

  • 12
    This is a horrible idea. They are not performing to expectation, so give them more freedom? No responsible business person would do that! If you can't or won't perform at the low level why would I let you try to perform at a higher level without supervision?
    – HLGEM
    Commented Mar 8, 2011 at 6:21
  • 8
    If I wanted to learn to 'code my own way', I'd stay at home and not take an internship.
    – JeffO
    Commented Mar 8, 2011 at 9:10
  • 5
    @Rob S. If you think that the vast majority of OSS programmers aren't paid, or that most meaningful OSS projects that have stayed alive haven't been backed by a corporation, you might be surprised. OSS doesn't mean what it used to mean. Commented Mar 8, 2011 at 15:26
  • 5
    @Rob S.: When you "confronted" your boss with the treatment you were getting, you separated yourself with employees mentioned here. You showed eagerness, responsibility and confidence (confronting your boss!). And that is when things started to change. I would also appreciate if one of my Jr did that (given the fact that he would be capable enough to complete his work on his own :)). So, I would say, freedom is won, not given.
    – decyclone
    Commented Mar 8, 2011 at 19:16
  • 3
    +1 from me by the way. Only because you stood up for yourself and "confronted" your boss. :)
    – decyclone
    Commented Mar 8, 2011 at 19:43

It sounds like they are not very proactive or passionate about their work. But in any event, maybe you've helped them too much. Is it an option to just give them some difficult projects and let them struggle and possibly fail? It sounds like they need to learn some independence, and learn to take responsibility for their work.

  • 1
    This is the idea I'm kind of working with now. Just sent my super an email about it actually. It's not an option that I've had really until pretty much now. Commented Mar 8, 2011 at 4:12

Clearly some people forget being new to a job? Talking about firing someone!

I interned at Microsoft and there were times when I just lost interest but the beauty of it was we had a weekly one to one and discussed what I wanted to do and how things could be made more interesting, it may be that the work you give them just doesnt interest them and in that case you should sit down with them and target the areas they wish to be more involved in.

Set up a weekly one to one with them and talk about what they had done and what they want to do, explain to them that if something is too dificult dont be afraid to ask for help, the fact that they make an attempt shows they are trying, however if they are just pure lazy then this would demand firmer action.

Give them each a project to work on using tools of there own choice and say spend 1 afternoon per week working on it, and go over it with them and help them, this will help you identify the strengths and weakness in their skills and aim to improve them.

Being an intern is not easy, I remember the feeling of just not being good enough to be at Microsoft, but they made me feel very welcome and didnt laugh when I asked easy questions.

Put a proper plan for them in motion and make it fun get involved with them all the way, as I said having a proper sit down with them each week helps a lot, simply letting them shadow you is not enough, when they shadow you ask for feedback from them, how would they solve the problem? Helping interns can be a lot of fun, just try to expose their passion for technology and if they are working poorly aim to figure out why!

  • 1
    I've been new to several different types of jobs and in none of them would an attitude like the poster descibed have been remotely acceptable. If you won't do the work correctly, dissappear when you are supposed to be somewhere and fall asleep in meetings, you can expect to get fired. this isn't a game, this isn't school, this is business. We can't afford to keep useless slackers.
    – HLGEM
    Commented Mar 8, 2011 at 18:26
  • Interning is different, you should target an interns strong areas, as I said if they are just being pure lazy then sure get rid of them, but if they are making attempts and failing then maybe this isnt a strong area for them and maybe find them some different tasks they can do.
    – kyndigs
    Commented Mar 9, 2011 at 10:14
  • 1
    No sorry don't buy that Interning is different. Part of interning is learning how to work in the real world. If you can't work unless you are "motivated" I don't want you anywhere near my systems.
    – HLGEM
    Commented Mar 9, 2011 at 11:37

Some things in life should be earned. I don't care if you are a student, volunteer, intern, entry-level employee, whatever, you don't get to goof off, waste my time and sleep while I'm trying to get things done. The only people who get to watch me work are those paying my salary.

You want my attention and help you have to act accordingly. They aren't even willing to meet you half-way. What do they expect to get out of this experience?

There are people who want to learn AND work. Find them and treat them well. Show the door to the others.


You are probably paying these guys a minimum of 3k a month. The questions to ask are:

  • "Is the current output worth 3k per month?"
  • Since they may be just starting out and expecting instant positive productivity right away is a bit naive, suppose you bite the 3k/month bullet for a year..."Will their deliverables be worth 3k/month in one year?"
  • Those are the softballs though. You have to eventually ask..."Will they be worth 3k/month in a year, and make up for the year of 3k/month deficits that were created before they leave?"

Given this last question and that the average young programmer will spend about 2 years at the company, if they are worthless for the first year, then they need to output 6k worth of deliverables per month in their second year...just to avoid being worth less than nothing!

If you do not forsee them meeting this most basic benchmark, then you really do need to cut your losses and put them out to pasture. Judge for yourself, but it sounds like these guys could easily have a negative worth considering:

  • they fall asleep in meetings (so they add no business knowledge or innovative value)
  • They waste your time, meaning they are costing the company their pay + yours
  • They break software that would have worked if they had just stayed asleep in the conference room

I am sorry, but the majority of these have nothing to do with Jr. developers.

I have been in IT for over 15 years now and I have seen many people sleep in meetings (I tend to drop things near them when they doze off) and it is anyone from the oldest employees to the newest, but it is more often NOT the younger ones. They tend to spend more time ignoring the meeting on their phones, or iPads, but not sleeping.

Checking in untested code: I have worked with many more mid-level developers that do this then new ones. The kind of mid-level devs that just "know" their code works and when there is an issue it isn't with their code. Sure the lower levels can check in bad code, but I that why we do not allow new employee check in rights.

If you are giving a new programmer a small task and they do great on them, but fail on the bigger tasks, maybe they need more help and are afraid to ask for it. When I give the first few big tasks to a new programmer (new to us or new to programming) I make sure to stop in a few times a day and see where they are. We go over their code and do some review.

I find this leads to a much easier into to code reviews and lets the new employee get insight into how we as a company treat our code.


I'm assuming this is an intern, someone in college....

  • We agree to break a minute, and then they go missing in action for a while...then just go back to their desk.

Manage expectations of what a break means.

  • I shouldn't have to go get them but that they should be showing interest in learning.

It's a bit awkward standing around twiddling your hands.

  • Am I expecting too much to expect that if they want to learn they'll make sure I know they're ready and willing?

No. Sounds like a communication error - possibly!

  • They go to meetings that they were not told they had to attend...good, but then sit in the corner and sleep...bad. I don't even know what to do with that.

Sleep? really? Send them home if they literally doze off. Presumably they are hourly, so that docks their pay. That's just not acceptable to doze in meetings.

  • Sometimes I give them something small to do and they do it great, so I give them something just a touch harder and they totally fail, hard.

That sounds like an early college student, yep. :-/

  • They check in things without testing them.

Expectation management, again. Branch here depending on the response.

  • Part of me thinks that maybe I should be spending more time with them but at the same time I don't see a lot of interest and I really, honestly don't have time teaching the same things over and over. Sometimes I get asked questions that are really, really easy to answer if you just do a little bit of your own work trying to find out. Other times I'm not asked anything.

Classic college student behavior. Believe me, I've TA'd.

What I see here is a profound lack of communication. The student doesn't really grasp the company culture or expectations, and doesn't really understand how to develop larger projects. They may be amazingly bored, too, considering what drek people often shove off onto interns. What may also help is finding a different mentor to work under. Personality and mutual expectations can shape a dynamic fairly drastically. What I would consider practical and reasonable is to have a 'come to Jesus' meeting with HR + supervisor. The individual under question basically needs to be given the options: "shape up", "ship out". Shape up should be under a provisional clause: if they keep dozing off at meetings, well, that's unacceptable.

If you want to focus on a salvage effort, I would probe deeper into the individual's situation. Is this their first job? People who have never held a job before are, uh, not familiar with the rigors of having a job. >.< Is this their first professional job? Expectations between a taco stand and a office are, how do you say, just a little different. And so forth.

Obviously, if this is someone who got hired from college, therefore expectations are higher: they shouldn't need to be so closely mentored, and they should have some semblance of proper job behavior.


As long as the juniour employee is making progress of some sort, talk with him. Point out where he's failing and where he's succeeding. Make it clear where he needs to shape up to meet expectations. It may not be a pleasant talk, but it could be what's needed to push him to a productive level.

Also consider firing him. Sometimes, it's best to let the dead weight go. Yes, that is harsh, but if he's not making progress or progressing too slowly, then you need balance the needs of your employer, yourself and of the juniour developer. From what you described, you may be on the losing side of that balance.


At what point should one give up?

The best answer could be there is no best answer. You do your job best. the rest is up to them. You can take horse to the water but can't push him to drink it.
If they lack interest talk to them and check what interests them. As freshers they will not be much interested in process, and may not understand the importance of proper check in. When some of them make mistake, you need to make them understand that how this mistake wasted the time, and energy of others, and why it needed to be done carefully. If they don't seem to be interested then you need to talk to your superior about them.


The last thing you want to do is give these yoyos more freedom or responsibility. They will only mess up your code base more. You have tried to teach them, now pass the responsibility onto your manager to tell them what is wrong and put them on probation or fire them. I would not even consider keeping people who showed this level of irresponsibility. It is not fair to the other developers and bad for the company to keep people who are clearly incompetent and not willing to try to be competent. We had a guy like this once and he was bounced around from team to team for a solid year before they fired him which everyone agreed was really about 9 months too long. These developers need to go as soon as possible.

  • +1 - Agreed, when your greatest contribution to a company is not to show up, you have to go.
    – JeffO
    Commented Mar 8, 2011 at 9:19
  • @Jeff O, we had one guy who was within six months of being eligible for a miltary retirement whose attitude was so bad, my boss did send him home for six months. The guy actually had the gall to use my boss as a reference later!
    – HLGEM
    Commented Mar 8, 2011 at 18:28

There are enough people out there who have interest which shows up in their twitter, facebook, blogs etc who want to learn more and more. Other thing i suggest is make sure you are appreciating them, respecting them as sometimes these factors if not taken care of can be highly de-motivating. Make sure you hear them.

Apart from this I suggest you clarify that: are they incompetent (lack of skills) for the task, or are they de-motivated. This way you can zero-in on the problem.


Interesting question, I can see both sides of the story, there are some key pieces of information missing:

  • There seems to be a massive mismatch across the board between their expectations and yours of why they're there and what they're supposed to be doing. And you've never discussed this with them.
  • What are your, their, your company's and their college's expectations about this intern program? To what extent is this internship aligned/not aligned with their course of study, career goals etc? Do 50+% of the interns come back upon graduation? or go to your competitors? or flee the industry? Does your company have that much to teach them, frankly? What level and year are they: HS, community college, AA, BS, MS or PhD - that makes a world of difference? Do you have them working on (say) QA or sysadmin when they really want to work on (say) speech recognition or cloud? Did you have a brief to-the-point conversation with them to get to the bottom of this and why? (That's your responsibility to initiate, not theirs. This is overdue.) I would certainly phrase things like "Are you really interested in this work and dept, if not what can we change?" instead of "Do X,Y and Z or you're fired, because I say so". Do they want to be reassigned? Was your company and dept their last choice instead of flipping burgers? Maybe their college sucks AND your company sucks and they're just doing it for the $$ or resume bullet, in which case you're all trying to put lipstick on a plurality of pigs. Don't expect them to have a "junior developer" mentality if they don't see themselves as such, or have no interest. Invoking a disciplinary process on a lowly intern is pointless if none of this shared context is in place. Solicit their constructive suggestions too.

> "Part of me thinks that maybe I should be spending more time with them but at the same time I don't see a lot of interest"

Well does your company consider the interning arrangement to be a subsidy of your time to their college's research, or extra labor for your dept, or something in between? You could just let them sit and read Calvin and Hobbes and play ping-pong all day and not bother you.

> "they go missing in action for a while... Frankly, it's a bunch of time I don't have explaining things as I go when I could just do it."

  • Well if the intern arrangement isn't working for either of you, who foisted this intern program on your dept anyway, and who interviewed these people? Did you interview this intern? If no (why not?), who did and either way why did they get assigned to you? If they aren't contributing to your productivity, how do other people manage their interns? Are they at your company to do research or purely hourly-wage tasks or some reasonable mix? Do they have a meaningful project or deliverable in which they have a personal interest? Do they have milestones and are you monitoring them (sounds like no)? Do they make a presentation at the end of it? Does your company (not you personally) exit-interview your interns? What are their criticisms and suggestions? Are you paying them competitive $$, below-market $$ or free? Do they have any prior work experience, whether software or whatsoever? Maybe you should read resumes and interview more carefully, gauge their initiative and work style.

> "They go to meetings that they were not told they had to attend...good, but then sit in the corner and sleep...bad. I don't even know what to do with that."

Maybe they're trying to understand the wider organization/product/industry (are you or other people giving them that?), maybe they don't like shadowing you programming 8(?) hours a day, maybe they're totally demoralized by their lack of progress, or maybe they're just simply slacking off - can't tell based on what you said.

There's a well-known tactic to turn that unnecessary-meetings into something positive: tell them you may call on them at any point to stand up at your dept meeting and deliver a verbal summary of any of those meetings. Or, simply give them a list of meetings you think they don't need to attend, and ask if they're ok with that, and if not why. Maybe you or your HR or intern dept should set up some lunch or presentation schedule for them and other interns to meet a wide variety of people and job functions across the company. All the good intern programs do that, benchmark yourselves against them. If that doesn't exist, make it happen! It should benefit all of you. Take ownership of this intern program.

Come to think of it, set up a meeting for your own people managing interns on "Best Practises for Managing Interns" (absolutely don't invite the interns to that one. But probably give them a redacted summary). Have you talked to someone there who managed interns before about these issues?

That was the big-picture context you're not answering, then here's the specific detail stuff:

  • you want them to shadow you at your desk (how many hours a day? 2? 8?), maybe that's not for them. This sounds like micromanaging? If you solved the checkin breakage issue and held code reviews (suggestions below), should that really be necessary? I would say no. Why not have them decide when to shadow you? Better still, have them periodically show you on their machine how they are coding/testing/debugging, and you sit and watch and comment?

The general principle is: manage the expectations and review progress regularly (3x/week?); don't micromanage the behavior.

> They check in things without testing them.

  • ok that's a very simple one to fix: require all their checkins to attach a testcase file + passing logfile. Have the SCM system reject or flag changes without (/email the big boss/record checkin % success rate on a departmental leaderboard/whatever). Setting up the SCM system to enforce that is maybe a suitable intern task. And/or definitely have code reviews, even if it's over Skype, or (when you're busy), email comments. Probably also, limit the scope of which files they can checkin until they stop breaking stuff.

> Sometimes I give them something small to do and they do it great, so I give them something just a touch harder and they totally fail, hard.

Well sounds like the learning process or their thought process aren't working. Did you walk them through a logical set of steps they should have tried to solve it? Read the manuals, wikis, tutorials, user guides, books etc.?

  • another great practice is to have them start and own a wiki/(document) about methodology. Have them present that and review it. All of these problems are opportunities in disguise - assuming they have the basic ability, motivation and interest, which we don't know based on what you said.

> "Sometimes I get asked questions that are really, really easy to answer if you just do a little bit of your own work trying to find out.."

Tell them they could have answered it for themselves, have them start and own a wiki, and document/link to resources. Again, have them present it when they present on methodology. Also, I assume you mark your calendar with busy/available time ("red time/green time")?

> "Other times I'm not asked anything"

Uh that might either be a bad sign or a good sign - assuming they're not off sleeping in unnecessary meetings or reading Calvin and Hobbes or hiding from you. Assuming you stay in touch via email, IM and have automated emails of code checkins, maybe something deeper is not working.

Can you answer some of the above, then we can take it from there?

  • +1. And also @OP you say: "I'm sure I could be doing better but honestly...I don't really want to anymore". Have you ever thought that your interns may be saying exactly the same thing? In my experience, with a problem like this there is very seldom only one person to blaim. I'm not saying you are to blaim, but have you talked to/considerd how your interns are feeling? And if the answer is something like: "yes I asked them at a coffee break" (or similar), you are bound to revive a dishonest "oh, yes sir, everything is super fine! I really love to work here!"
    – Niclas
    Commented Jan 21, 2012 at 11:13
  • Right. If the OP does not have a task suitable for an intern, and if the intern assigned is not interested or capable of doing it, this arrangement does not make sense.
    – smci
    Commented Jan 21, 2012 at 11:19

You have a responsibility to educate your juniors and to nurture their skills so that they can become great and independent members of your team. However, your juniors have a responsibility to start their careers behaving as professionals. Sure, we all get tired, and we have days when the meetings are not interesting, but there is a difference between being disengaged and disrespectful.

As others have said, your vetting process sounds like it needs to be a little more rigorous. That may come down to how you acquire your juniors in the first place. The trick there is to go to your local university or college, and ask the CompSci teachers who they feel has not only the talent, but the dedication to make great software developers, then interview a bunch of kids and see where you want to go from there.

As for how much effort to put in, you need to give it your best shot, but at the same time you need to show these kids that you're not there to give them a free ride on the gravy train. If your company has specific criteria for disciplinary action, apply it. If the junior fails to meet the same standards of professionalism and doesn't take things seriously, you've got the options of either benching them, trading them, or simply letting them go, much the same as with any other employee who fails to perform. Obviously you can't expect the same level of expertise, so you work with your junior to improve that if they are showing the dedication you expect of them.

Bringing along your juniors to achieve higher levels of expertise and experience can be an enriching experience for you as well, but you shouldn't act as if they are babies who need to be coddled. When they are working for you, they are no longer strictly students, and need to be held to a higher standard of professionalism. Explain this all to them up front, and don't let them waste your time which could be better invested into someone else who would be willing to put the effort in.

Not the answer you're looking for? Browse other questions tagged or ask your own question.