views:

204

answers:

9

What are some practical ideas that you have found useful for bringing graduates on to your team in their first job?

Some of the things that are working well for us include:

  • Assigning a mentor to assist the learning process
  • Written coding standards/guidelines
  • Spending a period of time with the test team to learn the product
  • Where possible, a broad range of experiences in the first few months

Anything else that works well for you?

A related question can be found here.


Summary

In summary, I guess from the close votes and comments there may be more appropriate forums to ask questions like this on the interweb :)

Thanks to the folks who took the time out to answer. Here are some of the ones I like in a haphazard order that appeals to me:

  • Providing feedback
  • Bug fixing/Modifying existing code
  • Code reviews
  • Measurable goals
  • Team programming

My favorite answer was Pandiya's answer about domain knowledge, especially the quote. I'm not sure this is a direct answer to the question asked though :)

+4  A: 

Real work, something concrete to deliver.

Reviews and feedback, code reviews can really help

djna
+3  A: 

We find team programming and constant code reviews to be very helpful for all new developers, especially in the beginning.

Sam
+2  A: 

Domain Knowledge is really a key...

I have read in one of a previous question on stackoverflow

I think a lot of companies have wasted a lot of money by not ensuring that their developers understood the domain. Not only should you understand the domain, you should be an authentic user of the domain. Some people say "but we have analysts for that" and the result is disconnected, obfuscated, backwards software imperfectly written to spec.

To put it another way: how can you begin to abstract a domain in code, and to solve problems around that domain effectively, without understanding the underlying domain?

So to me it's not a question of whether you're going to be a programmer or a domain expert. You're always a programmer, and fully half of your job is understanding the domain.

Pandiya Chendur
I disagree that this should come first. They should fix bugs to gain a certain level of comfort with the system before they delve into the details.
ChaosPandion
I think this is definitely the goal. What I am looking for was to make this happen :)
spong
+3  A: 

Assign them work on fixing bugs first (i.e. sustaining engineering) before working on new feature development.

William Leara
A: 

Assuming your organization includes a support department that interacts with customers (i.e. tech support) have the graduates get experience there before working with product development. Great way to learn the products and how the customers actually use them, and the issues customers typically have.

William Leara
I'm not sure that will make lots of happy faces.
Martinho Fernandes
Personally, I started out in tech support and I learned a tremendous amount. It gives you a better perspective on the software engineering job and teaches humility.
William Leara
A: 

I will think about

  1. instant help to the team
  2. career development for the folk
  3. how to keep him/her if he/she is good

For 1

I will give him real project with measurable performance, e.g. an actual project which demonstrate whether he/she has the skill set

For 2

It should be start during group interview phase. See how he/she fits the team, culture, etc. Then let him/her work with different teams (system analysis, support, infrastructure, etc) to check his/her career goal and capability

For 3

$ + fun. (Fun is a big topic which can't be covered in one SO answer ;-)

ohho
+2  A: 

An idea I like is to "throw someone into deep water" so that he "has to learn how to swim, or drown". The drowning here is figuratively meaning "be helped a lot by colleagues".

I believe that working with the testing department could suck the fun and enthusiasm out of anyone.

I think a concrete feature (a small one preferable) will be more useful for a new developer. The task is very concrete, and as long as you make it clear that the other members of the team are available for questions, it will become an intensive crash-course into the product/system/team. In that way you get something to deliver, as well as a great positive sense of achievement when the feature is done.

After the feature is finished, code reviews are very useful to introduce the practices and policies used in the company/team.

Lars Andren
+3  A: 

Make sure you have some old developer around to spout anecdotes about the old days. That's a great way to keep the young whipper snappers engaged.

uncle brad
Ha! Good news everyone! We have some of those.
spong
@spong - Thanks, you've made my day.
uncle brad
A: 

In my personnel Experience I have taken many graduates right from the college to the team and had in my team Now they have become well versed with the Programming techniques, Below are the things that I have followed

1) I will assign some testing work on my piece of project work 2) I will assign them a modification of code, so they can understand what they are doing and what is expected out of them 3) Ask them to implement a small feature which has all the project activities, during coding style, bug fixing ...etc

With this they get the confidence and work independently

harigm