The situation is this - we took an intern for a summer with a mind that if he will catch up during summer, we will keep him as a part time junior developer.
We took him after his first year in university, so his knowledge was way too low to be involved into real projects(actually he programmed only in university), so my task was to push as much stuff as I can to have him ready for joining real projects in September. As long as we are remote developing team, we gave him possibility to have its internship remotely, with flexible hours.

So two months passed and I'm not impressed with his progress. I gave several tasks to implement, access to learning resources, recommended start paths and so on, agreed that he will report every couple days, we had pair sessions from time to time, reviewed his code together and etc.

Anyway, it looks like he spent less time writing code than I expected and before I would say that he didn't performed well enough to join our team, I was thinking may be that is my fault, may be I was pushing too much stuff, that is important in real life projects (like unit testing, structuring code, database stuff, etc.) and not enough fun stuff, that would hook up him on programming and that is the reason he spent less time than I hoped.

So I have ~20 days left and I can use them to inspire him with programming, question is with what and how?

  • 4
    Sounds more like a distant boss than a close mentor. Perhaps you should reconsider how you teach?
    – user1249
    Aug 9 '12 at 9:41
  • 3
    @ThorbjørnRavnAndersen - I understand that I'm not perfect at this and I'm trying to get better, that is why I ask questions like this. Had no good mentor when I was junior, have nobody to learn this stuff from today, so it is trial and error.
    – Giedrius
    Aug 9 '12 at 10:48
  • You need to be actively engaged with him. If you are not you can't gauge his/her progress and guide them as an experienced professional. Sounds like it took a long time until you started really getting active with the interactions.
    – Rig
    Aug 9 '12 at 11:28
  • 1
    i think the problem is having him remotely. it works well for some people but not for others. especially not for people who are interns :) first and foremost you need to teach him good work habits before pushing programming on him. think "karate kid". giving someone in their first year of college is a baaaad idea, just remember yourself in your first year of college :O and if he only coded in college, i don't see him being the type of person, who'd rather sit home on a friday night to code than go out with his friends
    – user60812
    Aug 9 '12 at 23:17

How about working in mini day-long sprints.

Start the day (9am) by getting him/her to state what he/she intends to do over the day (and manage his expectations) and then talk over what he/she's completed (5pm) - including how problems were dealt with. Slowly, over time, extend the sprints once you are happier with the behaviour.

Other than that, let him/her get on with it. If they don't feel the motivation to get the work done, then that's why you take an intern on - both for them to get experience, but for you to learn how they work too. C'est la vie.


It sounds like you pushed too hard and he might be a bit overwhelmed, I've known seasoned developers that couldn't really grasp unit testing and I imagine it was too much to handle for someone with only a year of formal education. And you can't really force inspiration.

The first thing I would do would be to talk to him and find out what he found enjoyable so far, and concentrate on that for the rest of his internship. We can propose a thousand fun programming related activities, but what's fun for me will probably not be fun for your intern.

If there's at least one aspect of the job he found enjoyable I'd suggest the two of you build a mini project around it, even something unrelated with the job. If for example he enjoyed working with databases (doubt it ;), you could build a basic CRUD application, and then expand on stored procedures and other database related black magic stuff.

At the end of the day though, you should be prepared for the possibility that he's just not what you are looking for.

  • Well, it is kind of point of my question - CRUD applications isn't that interesting, I need to think of some small simple application that has more fun than CRUD :)
    – Giedrius
    Aug 9 '12 at 8:17
  • @Giedrius CRUD was just an (admittedly bad) example, my main point was finding out what he enjoyed most. Another example would be some Project Euler problems.
    – Roc Martí
    Aug 9 '12 at 8:18
  • 1
    I was thinking may be something working on appharbor.com - something simple enough, but useful for others - like decoding base64 string, because personally for me the best motivator is knowing that somebody is using my app
    – Giedrius
    Aug 9 '12 at 8:26

You might be pushing too hard with unit testing and real-world database staff. However, his skill level should be in a good shape to fix bugs by now.

My understanding of internship is a bit different. Mostly interns are in their last year of Computer Science study, who have good potential for re-search as well as know basics of writing code, building their own small applications. However, being in a first year of university and not having code experience before starting university makes intern candidate very low skilled.

I do belief that most important skill in intern/junior programmer is his analytically reasoning skills. It might be better to have him in the office and guide him face-to-face while tracking his progress and approach in implementation of assigned tasks. Because, you may also observe about his soft skills (like communication, attitude, overall fit to your company environment).

In terms of motivation: you may inspire him by guiding to the right resources (to improve his skills or provide chance to learn) and assigning small, doable tasks every day. He might be feeling more satisfied if he would be accomplishing some low level tasks everyday and get more interested in the process of learning and contributing to the real code. However, i would strongly recommend to review his code before checking to the main trunk.

  • 1
    Well, I agree with you, thing is that this time it was not my decision to take him as intern.
    – Giedrius
    Aug 9 '12 at 8:09

I think the best way to inspire him is to give him some real tasks, it doesn't mean that you should involve him in the development of the product, but usually there are always processes that need improvement inside the development process, giving him some tasks developing some utilities that will later be used by the team(s) could be a great way to make him gain interest and at the same time know how the internal processes work.



If you want to inspire him with programming you may have to go out of business context. Interns are lucky to land internships and typically take what they can get, so don't be offended if your core work doesn't blow his skirt up. Interns still have some fairy dust in their blood, most young programmers become programmers because of the power to create and the exhilaration of creating something awesome.

Find out what his hobbies are and what his dream programming job would be. Have him make something that he thinks is awesome, be it a 2D video game or a database to track pokemon cards.

If he does something in his interest area, he'll be excited. You might help reign in the scope so that what he does is realistic for the time period. You can also highlight topics along the way that are relevant in business scope where you can provide education i.e.

You chose to structure your db like so, what was your thought process behind this? What would happen if xyz?


Separate the two parts of your problem.

1) To inspire.

2) To teach.

He's a post graduate with coding experience, so it may be too late to inspire him, or make him "see" the majesty of code. It isn't your responsibility to inspire him, but I understand why you would want to.

Teaching on the other hand, from your description it sounds like you've dumped a lot of stuff on him and expected him to sort it out. As you have a limited amount of time, set smaller projects, dish them out one at a time and get daily feedback. Make sure you follow up on him during the day and make it clear that if they have a problem, to ask rather than spend all day struggling and achieving nothing.

  • 3
    The question says that the intern just finished his first year in university, he's not a postgraduate.
    – Roc Martí
    Aug 9 '12 at 8:10
  • To further add to Roc marti's comment, the question also says he has no coding experience beside his first year of university.
    – Gilles
    Aug 9 '12 at 12:20

it looks like he spent less time writing code than I expected

Find out why - is he trying to write code, but has problems to get it working? Or is he not even spending enough time in trying? If the former is the case, you should help him more, if it is the latter, then better let him go.


I think there are a few problems on both ends. It may be either of the scenarios you presented.

Scenario 1: Intern is underperforming

Working remote is the flag here. It takes a very disciplined individual to actually work remotely. With little experience, the intern may not have the combination of motivation and knowledge required to perform well remotely. If you need a remote position, this intern is not for you.

Further, you mention the fun aspect. I know it's more rare, but why not look for someone who thoroughly enjoys the tasks you're assigning them. Honestly, SCRUM and TDD can be very fun, it just takes the right mindset. Yes, they are few and far between, but there are people out there who actually enjoy learning new CS technologies and methodologies (= Perhaps you need to continue your search.

Scenario 2: You are not mentoring close enough

I believe if this was the case, you'd know. If the intern was motivated, he'd come to you with questions. He would ask you when he doesn't understand something. However, if he's writing bad code and you never said anything, then you might need to speak up more. The deal is, with his experience, he's not going to know all the time if he's writing bad code. So if you never spoke up when you saw issues, you only have yourself to blame.

Whatever the case, there is nothing wrong with deciding the intern is not right for the job or is not ready yet. They are young and have much to learn. They may need a few more years to just be a student before being really motivated to do professional work. If you feel the problem is fixable, give it a shot over the next few weeks and try to keep the intern. If not, you both had a summer of learning and that's that.

My personal opinion: If I lay down guidelines and requirements and someone isn't meeting them, I'm not going to want to work with them further because I know and work with people who love what they do, even the CRUD, and who are noticeably motivated to make a great product. Anyone like this is bound to succeed (= In the end though, the one way to get to the bottom of the issue is to talk with the intern. Try to have a progress meeting (or something) where you get to talk to the intern before making any decisions.


I would recommend to start by letting him look over your shoulder as you code (more difficult to do remotely but with a good screen sharing program and voice software, it's possible). Take a feature from requirement to done all the while explaining to him what you're doing.

Repeat this a few times and on the next task, after you've broken ground on the code, give him the helm for a while. Be sure to provide hints when he gets stuck so he's not frustrated, but resist the temptation to take over right away. Pick a very specific step that you've probably repeated a few times prior so that you can reinforce the training.

Continue to let him take control with more frequency until he's finishing entire features on his own.

Just giving him a bunch of books and tasks to work on will cause overload.

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