Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Training freshers has become my responsibility. I work in a good small company and they want me to train freshers (MCA/BCA students). But I am not an expert in training field. So can anyone please help me in this?

Few hints/tips and something that is new/different to train them. What care should be taken while communicating them?

How to clear their mind covered with college environment?

Please help me.

share|improve this question
2  
Some MBA's can be trained by putting chocolates on their noses and making them wait to eat it. It takes patience and most can't manage it –  Martin Beckett Dec 27 '11 at 4:39

2 Answers 2

up vote 11 down vote accepted

Short answer:

Teach them basic things: how to use version control (and especially why), when to ask for a help and when to search for a solution on their own, etc. Once you've done this, if they have enough technical knowledge (i.e. if they know the programming language enough), they can start to practice, and you just have to make code reviews. Those code reviews must be deeper and more strict compared to the code reviews you do with your colleagues.


Long answer:

1. Teach them how to work

This is, IMO, the very first point that must be learnt by a person who have no professional experience in software development. In most cases, they don't know what a version control is. They never used bug tracking system. They ignore most of those things which makes the difference between the person who just knows the theory and the person who is productive in his daily work.

For example, if you don't explain them why the code they write must follow the predefined set of coding style rules, nobody will. But telling: "Those are the rules. If your code doesn't match them, you will not be able to commit it." is not enough: explain why there is such a thing as coding style rules, why does it matter in a large codebase, etc.

If you have time, taking one rule and explaining precisely why this style was chosen over another and what can be the valid reasons to chose an alternative style can be a good idea.

2. Teach them how to work in a team

Working in a team is hard. In colleges, most students are learning how to work in small teams of friends, but it doesn't mean that they will not be lost when it comes to a work in a large (or even not so large) company on a huge ten-years old codebase, where people who participated in the past left the company, other people will rejoin the team later, etc.

When they do a work at college in a team of friends, they are more or less equal, with same responsibilities, with same technical level, etc. In a company, they have to work with:

  • designers, who don't have to understand how their design is implemented technically,
  • developers who have more than 15 years of professional experience in software development,
  • developers who are not doing the same stuff (for example a team can have a JavaScript developer and several C# developers),
  • database administrators: when you just finished your college, you write an SQL query which seems perfect to you, and the next day, the query is completely rewritten by the DBA, because "it sucks", you have to deal with it and understand that for websites of some scale, there is actually a good reason to ask the experienced DBA to write queries, instead of letting this work to the developers,
  • project manager,
  • customers and other project stakeholders, given that some of them, totally ignorant of what software development is about and how is it done, will still ask to do stuff which makes no sense,
  • human resources and other administrative staff.

The sole fact that the fresher is working in an environment full of much more experienced people is difficult to deal with. For example, in what cases you should ask for help, and in what cases you should deal with the problem alone?

3. See how they work

This point is already in the answer of Tom Squires: review their code, making a deeper review than you do with your colleagues, and being also stricter: it's only once a person understands a rule and the reason behind the rule that this person can violate it.

share|improve this answer
    
lol, I can tel this is a MainMa answer by just looking at the headers. Most importantly teach them how to work on their own. Don't show them solutions. Make them find solutiond and train them in good practices. –  Falcon Dec 26 '11 at 12:54
    
+1 a more comprehensive answe than mine –  Tom Squires Dec 27 '11 at 0:32

Code reviews. Give them real small projects then make sure all the code is reviewed by a more senior developer before it is set live.

Code reviews are a great way of transferring information. Make sure they conduct reviews as well as getting reviewed, you learn just as much from conducting as being reviewed.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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