Fog Creek Software
Discussion Board

new grads

Have a new grad in our small startup who has started work recently.Rest of us are intermediate 3-4 years experience dev guys.
We are a startup, and being pretty small everybody has well defined roles.
But since the new grad has started he is creating more negative work, and has yet to produce anything in 3 months.
Should we start some kind of mentorship for him?
as it's his first job how do we know if he has "potential"
and can turn into a good developer?
Right now he is a drain on our resources and can't afford that.
But I am also sympathetic to him, and we are willing to give him a bit more time, but where do you draw a line?

Going crazy
Friday, June 11, 2004

> Should we start some kind of mentorship for him?

I think you should have started some kind of mentorship for him from the first day he arrived.

> As it's his first job how do we know if he has "potential"
and can turn into a good developer?

Perhaps by knowing him better (for example, by having had experience at being his mentor).

Christopher Wells
Friday, June 11, 2004


This kills me.  He's completely green and nobody's mentoring him.  What's wrong with your management?

Can he be a good developer?  How good a developer were any of us when we got out of school?

Friday, June 11, 2004

zero tolerance

burn him at the stake


fire him first, then burn him at the stake

bonus points for roasting marshmallows

muppet is now from
Friday, June 11, 2004

Identify why exactly he is not producing.  Is he lazy?  Is he working hard but coming up with crap?  Is he lost - willing and able to work but confused on how to go about it?

If it's lazy, explain to him he is real danger of losing his job if he doesn't start producing.  If that motivates him to work but it's still crap, move to the next step.

If it's working hard but coming up with crap, you need to identify if it's lack of talent or lack of experience.  If it's lack of talent, get rid of him and explain that he needs to find a place he's suited better for.  Be nice but firm.  If it's lack of experience but he has real talent, mentor him.

If he's lost but willing and able, mentor him.

Friday, June 11, 2004

You have to mentor him or lay him off with severance because you can't afford him.

Having junior employees is always challenging, especiaqlly in small shops. I am often so swamped with work at all times that I barely can offer mentorship to my junior person, and it's disappointing to me.

What I have found is that it's easy for the new grads to become unproductive because they simply aren't aware how to contribute.

What we've found works is a combination of things:
* Closely monitored, specific tasks
* Allowing them to do online training during downtime
* send them to non-critical meetings in my place and tell them to "write everything down" and "ask questions about everything"

Good luck!

Friday, June 11, 2004

I have always enjoyed working with new grads.  They're idealistic and energetic.  Unfortunately, I'm guessing your guy has a hard time  LISTENING.

You'll probably have to fire him.  Too much relational damage to fix.  B-bye.  No more idealism for you.

Friday, June 11, 2004

> he is creating more negative work

My ambition when mentoring juniors is that they should create "zero work": i.e., I am willing to spend as much time telling them what to do (and how to do it) as it might have taken me to do by myself, alone.

If their net contribution is negative, that's disappointing; if it's positive, that's a pleasure; and if it's zero, that's normal.

The reason for doing it isn't for short-term benefit (immediate net positive), but so that their contribution may become positive over the course of several months as they 'learn the ropes' and earn their independence (and interdependence).

Christopher Wells
Friday, June 11, 2004

You find new grads idealistic and energetic?  Wow.. I haven't met any of those.  Usually they're arrogant, self-important, and opinionated.

oh yeah and I forgot incompetent, since a computer science degree more or less teaches you how not to drool on yourself =-)

muppet is now from
Friday, June 11, 2004

Wow. Someone recruited a grad as a developer without making any kind of assessment of their potential for the job. I bet that never happened before.

Management error. Pure and simple.

But then, here is the news: he isn't the drain on productivity, you are dude. You've had someone who could have been an extra pair of hands sitting around consuming salary and being a drain for three months. Were you expecting the brain-dump fairy to come and install some competence ? If you take a grad in your team and don't assign a mentor, then what the **** do you expect them to do with their time ? Pick their toes ? Make coffee ?

Friday, June 11, 2004


care to comment on why a small firm like yours went for a new grad? Was it a PHB thinking this would be cheaper than luring someone already trained?

Just me (Sir to you)
Friday, June 11, 2004

I am a firm believer in the three month rule.  New people are unproductive for three months.  It doesn't matter whether he is straight from college or another job.  It takes that long to understand what is expected and how it is expected to be done. 

During that three month period, you should expect to lose 1/3 of a person.  It may come from several people, but it will be consumed.  Also, it will be from people doing the job today.  You cannot expect a manager or the last "newbie" to train the person.  The only exception is a coding monkey.  Someone who's only purpose is to code, head down, directly from specs. 

As you are a small shop, you can admit you screwed up and fix it, or take the cowardly way out and terminate the person.  No one but you will ever know and you can clear you conscience by blaming him. 

If you really want to fix it, get everyone into a room, and lay it on the line.  The company blew it and we are going to fix it.  His first day of work starts again on Monday.  "Bob will be his mentor.  He will be Sally's backup and he is working in this area.  If he asks anyone a question, and they don't know the answer, let him follow them around until they find the answer." 

Good people are created, not hired.  That is why we see so many postings, even to this forum about someone with 10 years experience who "can't catch on."  Sometimes it is the person, but I see more cases of it being the employer, somehow believing that the corporate culture, understanding, and even politics, will somehow come through by osmosis.

Friday, June 11, 2004

the new grad was recruited by a manager, maybe he's cheaper, don't know.
We have a deliverable due in 1 month, and everybody is swamped with work.Who will mentor him?
I feel really sorry for the dude, but my manager does not understand.
He just wants the guy to churn code from specs, which he is incapable of presently.
Also he does not understand basic data structures like hashes and trees and stuff. He has got extremely good recommendations from his profs, as well as on his co-op terms, he tries, but his basics are just screwed up.
It's frustrating for all in the group.

Going crazy
Friday, June 11, 2004

Is he really a CS graduate? If he doesn't know about basic data structures (which are taught in the freshman or sophomore years) then he's probably not worthy of carrying on with your team.

Green Pajamas
Friday, June 11, 2004

> Who will mentor him?

Ideally, I think, that would be your senior developer or team leader.

> We have a deliverable due in 1 month, and everybody is swamped with work.

The desire for someone who will be productive within their first month is one of the reasons people have for choosing to hire more experienced developers instead of recent grads.

Still, your team leader 'should' be able to parcel out work assignments according to the abilities of each of his team members.

Christopher Wells
Friday, June 11, 2004

"Also he does not understand basic data structures like hashes and trees and stuff. He has got extremely good recommendations from his profs, as well as on his co-op terms, he tries, but his basics are just screwed up."

He got somebody else to do his programming work for him in college. He is too far behind to gain any net positive return from mentoring.

Friday, June 11, 2004

MSHack is correct, new hires will only contribute minimally at first.  He gave them at least 3 months; I would qualify this further and say that that amount depends greatly upon many factors, and in some cases, may be as much as a year before Joe Newgrad has enough domain knowledge and expertise to be let off the leash.

Whowever's managing your team needs to get Newgrad into place by doing close work with another developer.  Manager should also expect a drop in productivity for some time from that developer.  Ideally, you should put Newgrad on one-to-two week work units and rotate him through working with several developers.  After this, Newgrad will have some relationship with several people, and some foundation of domain knowledge he can build on.

Finally, manager and developers should all be forced to read the Mythical Man Month.

van pelt
Friday, June 11, 2004

> He got somebody else to do his programming work for him in college. He is too far behind to gain any net positive return from mentoring.

I learned about data structures after college (I took Maths/Physics, not CS); a mentor could say "Gee ... you don't know the STL? well, I recommend you use a hash_map<> for this ... and, in your spare time, for background information, read chapter X of book Y".

It sounds though like, with a one-month deadline, you might be doing damage-control with him ("sorry, I'm kind of busy, I can't think of many tasks that I can afford to give you right now: keep out of my way...") and resume your more hands-on training of him when you can better afford to.

Christopher Wells
Friday, June 11, 2004

Christopher - he is a cs grad, if he was some other subject, I would understand!
What are universities doing nowadays?
He's from University of Maryland cs does it rate?

Going crazy
Friday, June 11, 2004

You didn't do a CS degree.  That he actually did a CS degree and doesn't know those things, and didn't have the interest or initiative to learn them in his first 3 months of employment, means he won't learn them without lots and lots more time, if ever.

Friday, June 11, 2004

I could add that, at one ISV where I worked for 10 years, where I was the first developer and we ended up with a team of 20 developers, we hired only experienced developers, based on their resumes, interviews, and personal recommendations from existing developers: but without any coding tests at the interview stage; and, of these hires, I estimate that about 50% were "successful" from my point of view (where successful means "stayed for longer than a year, without being fired, or quitting, or being transfered to QA or tech support").

And, whenever we hired someone new, I saw it as my business to be willing to mentor them (though not all of them wanted or even needed mentoring), whether or not that was my "well defined role" (no point in hiring someone if you don't give them whatever they need to become productive), in addition to continuing to work as a developer myself.

Christopher Wells
Friday, June 11, 2004

So assign him to something that he _can_ do.

Sitting in code review sessions, or pair programming, or testing, or bug fixing (First he repros the bug, fixes the defect, can't repro it anymore, writes down what lines of code he modified in what file, checks it in, email sr. developer for REVIEW ...)

He can organize the code review sessions.  Get the coffee and donoughts.  Facilitiate.  Schedule stuff in MS Outlook.  Answer phones.  Go to bogus meetings so you can get code written.

If you don't really have anything ready to test yet, if you don't do code review, if you won't invest in pair programming, and if you don't have a bug database ... you've got other problems.

Does that help?

Friday, June 11, 2004

How to mentor somebody who does not know basic data structures?
Any suggestions?
Hand them one of the classics?

Going crazy
Friday, June 11, 2004

I think that any newhire, even a more experienced one, probably needs to go through a certian adjustment period.  I'd say that most folks need around a year, plus or minus 6 months, before they are truly on-their-feet.  So you have to fault this.  If I were your manager, I'd be really hesitant to put a new person in main-line vital production responsibilities from day one.

Really, it's not far to fire somebody without a certain amount of clear feedback about their performance.  Remember, folks are poorly self-calibrated into believing that they are always above-average.  So there's a distinct possibility that the newhire thinks he's doing just fine and therefore isn't motivated to change.

Flamebait Sr.
Friday, June 11, 2004

Yes.  "Joe, here's BOOK X.  Your job for the next week is to read and do all the sample problems from chapter 1-8.  Do it during working hours.  Try not to spend much time out of work doing this or you'll probably get burnt out.

If you don't get a concept after reading and doing the exercizes, come to me and we'll review the samples you've done.  This is so you can become an effective programmer and can really get involved in our product."

"Also, here's all the code I produced in the last three weeks.  That should give you some sense of how we code, our general practices and naming conventions/style conventions/etc.  Please review it all.  And I've marked sections which have code dealing with some concepts you seem to have some problems with."

"I know this seems like school again, but you really need to grok these concepts before we can really use you to your fullest extent.  Don't worry, we expected this, we just didn't handle it properly until now."

Friday, June 11, 2004

If you've shown this person what he needs to do and given him tasks to accomplish and he still doesn't have the skills to do the job then you need to fire him.

If, OTOH, you simply say "do something" then it is obviously your problem.  Give him specific tasks to accomplish.

Every place I have worked, excluding the military, has made this mistake.  They hire someone and then expect them to do work.  The question is what work do you want them to do.  Tell them.  It amazes me that people think one can get by without knowing what to do.

Also, it does take some time to adjust and learn the in's and out's of each business.  It's not just an instanaeous thing.  Even McDonalds has to tell their folks what they want done to begin with, before the workers know what has to be done by gaining knowledge of the business.

Disclaimer: I have never worked in the software industry, but i'm sure the same applies.  (No, I have never and hopefully never will work for McDonalds.)

Friday, June 11, 2004

> How to mentor somebody who does not know basic data structures? Any suggestions? Hand them one of the classics?

If data structures are their weakness, then tell them which structure[s] to use, and how to use the structure[s], and give them reference material.

I could argue that selecting a data structure is part of the (detailed) "design" (so, if the manager "just wants the guy to churn code from specs", then the problem is that the specs (i.e. the design ... or were you expecting to code from requirements, with no design?) were insufficiently detailed for this programmer).

That's why I'm suggesting that the mentor should be a senior developer (a traditional "manager" couldn't do the job: because he doesn't know enough about development).

I do it by walking through the task in detail (discussing the task with the new hire: detail what you're expecting him to do, to whatever level of detail you judge necessary). You may do this orally instead of in writing, iff you can both remember what you're asking him to do without it's being written. He's ready to work without you when he confesses that he knows, understands, agrees with, and is able to do what you're asking him to do.

Before he goes away to begin coding alone (I take it that you're *not* doing pair programming), emphasise that you want him to be productive, and that therefore you want him to come and interrupt you (and/or interrupt other team members), if ever he discovers a problem that would take him longer than a few minutes to solve alone: that it's about team-work: that it's better (for overall productivity and for his productivity) that you both spend some minutes on whatever his problem is than that you spend no time while he spends hours.

For example, my most recent job was my first exposure to Linux ... in the course of 3 months I must have spent at least an hour or two of other programmer's time, asking them about Linux command-line things ... while, at the same time, I saved them 3 months of time by completing the programming project that they gave me.

Yes, and part of mentoring them would be reviewing their output (e.g. reviewing their code): do that more than once per week.

Christopher Wells
Friday, June 11, 2004

The University of Maryland (College Park I assume) has a highly rated Computer Science department.  He certainly should have learned about hash tables and trees (I did).

Friday, June 11, 2004

Speaking of which, a reason for hiring people with degrees (graduates) is that they (supposedly) have a proven ability to learn; but you might be failing to exploit that ability if you're unable or unwilling to teach them.

Christopher Wells
Friday, June 11, 2004

" most folks need around a year, plus or minus 6 months, before they are truly on-their-feet."

In general I agree.

However, in my current job, the work I did in my first 6 months is far better and more widely (re)used than anything I've done since. I was promoted on the strength of it, but since then haven't been able to get in the same "zone".

I like to think I've adjusted too well to the company culture, but maybe I'm fooling myself, and the Peter Principle is a better explanation!

As for new CS grads lacking "basic" knowledge, I read CS in a "top" European university. Our Data Structures and Algorithms courses didn't cover hash tables. The Formal Methods course didn't include the lambda calculus. The AI courses never mentioned Hofstadter. I was shocked at the time, but have since realised it didn't matter.

Schools with good reputations attract good students, who then educate their peers, regardless of what the courses are like (to be fair the institution in question suffered a major "brain drain" during the .com boom which impacted heavily on lecturer quality.).

Now your grad may have been unlucky enough not to have good peers (or not to mix with them :)  Give him a chance.

Friday, June 11, 2004

Actually, the code review thing is a good point.

Generally, it seems to work well with new folks if they:
1) Are given initial projects that encourage them to become familiar with other people's code, so that they can become accustomed to reading it.
2) Have their checkins reviewed by a peer for a while to make sure that they are programming properly and are given feedback.
3) Are given some sort of formal training about "how we do things here"

Flamebait Sr.
Friday, June 11, 2004

> ...emphasise that you want him to be productive, and
> that therefore you want him to come and interrupt you...

Gotta keep that in check though.  Maybe set a time limit of 15-20 minutes or so trying to figure out a problem on his own, and then come ask for help.

If you encourage him to lean on others *too* much, you end up with a developer who comes running for help rather than looking up basic documentation.  I hate having to say "did you try pressing F1?" 10 times a day.  Plus, you don't want him to deprive himself of the chance to get something on his own and have that rewarding "ah-ha!" light-bulb moment.

Friday, June 11, 2004

That brings us back to the last of the original questions (which hasn't been answered yet): "where do you draw a line?"

I draw several lines; one is that I'll answer (almost) any question, but I disapprove of being asked the same question more than once.

Christopher Wells
Friday, June 11, 2004

Hmmmm...I wonder if the employee in question also happens to be a JoS reader? :)

Friday, June 11, 2004

Actually, Christopher Wells, a CS degree demonstrates someone who might * not * be able to learn, compared to a developer who has learnt the material on his or her own.

This could be the situation at work here. The PHB has presumed the CS grad is all he needs to see. Whereas hiring someone who's spent three years developing useful apps is actually far better proof of the capability that's required, and ability to learn.

As to the three month rule, when I was a contractor, I would have a complete project *finished* in that time. Smart people ramp up really quickly and know how to engage with the rest of the organisation.

Must be a Manager
Friday, June 11, 2004

The management made a mistake by directly throwing the newbie on to a real project.  But this particular newbie seems so bad that the cost of bringing him up to speed will way exceed the benefits.

There are other new grads and experienced people out there looking for jobs who will be productive quickly.  Stop letting this guy take up space for so long and hire somebody who has the ability.

After 3 months a CS grad should have passed beyond the "negative work" phase.  At the end of 1 month in my first programming job, I started doing real work that got incorporated into the system, in a language I had never done before.  Other new grads after me also were productive within less than 2 months.  One guy got fired after 3 months, but he actually had a few years of prior experience!

In that first month, they slapped some books on my desk and told me the important chapters to read.  After about 2 weeks of reading and experimenting, they gave me a spec to write a program that was already developed by somebody else (without giving me access to the source code of the original).  The output of that program would then get compared to the original to verify that I did it right.  Once satisfied with that, they gave me a real assignment.

T. Norman
Friday, June 11, 2004

Going crazy,

I can't believe your manager allowed the newbie to sit in his/her cubicle for 3 months without producing anything of value!  Seems like the new grad isn't the only person who isn't doing their job properly.  Imo, you really need to sit down with your boss and map out a plan on how to help the newbie improve and how to deal with him/her if his/her performance doesn't improve.

If your team doesn't have weekly status meetings or code reviews then you really need to suggest to your boss that these no-brainer tasks get implemented ASAP.

One Programmer's Opinion
Saturday, June 12, 2004

I remember my first day of work for a guy who turned out to be a fantastic boss.  On my first day, I have a meeting with my manager, and his boss, the director of engineering strolls in.

The director says to my manager "So, when do we get some useful work out of him?"

My manager says "well, he starts today."

Director replies "I know that.  I said, when do we get some useful work out of him?"

Sunday, June 13, 2004

*  Recent Topics

*  Fog Creek Home