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.
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,
- 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.