Keith Watanabe * NET 2.0

This article exactly mirrors my  thoughts when it comes to hiring developers.  Working with a bunch of junior people really has hurt my project recently so I can completely relate to what's being said here.  There are two additional lines of thought that I thought the article missed:

1) Creating a team
2) When to hire junior level people

1) Creating a team

The importance of this is generating the chemistry between members so that they understand their role and can function well. In other words, they should at least be able to get along with each other since they'll probably be working closely with each other for the next few months or years on a project.  Don't throw people together at the last second on a project. Make sure a team has been pre-assembled before starting a project or else you'll find yourself scrambling desperately for a contingency plan.

On my project, our HR was late (and cheap) in trying to get people.  By the time the project started, we lacked resources so I was the only person really  handling the code.  As a result, my manager (along with others) decided to add a vender's staff for the project.  HUGE MISTAKE.  Why?  These guys were inexperienced and incapable of handling a project of this level.  Worse yet, there was one guy in particular who attempted at every turn to take the project for his company and push the rest of us out.  Now, I got burned out and my manager ended up favoring the vender.  But in reality, what my manager's poor decision making had cost the company was alienating his key team members for the sake of the project, rather than ensuring the morale of his team was good to move on.

Not to mention that the vender continued to bring in low quality developers that ended up costing the company a heavy amount and expanded the project deadlines.

2) When to hire junior level people

We can't always say that the ONLY thing to hire are extreme senior programmers.  Otherwise, there would be no room for the next generation of developers and all a company would receive in turn are these aging guys at Country Kitchen Buffet.  So obviously, there needs to be a strategy for hiring kids out of school.  So the question is when and how?

- Hire junior level people when your system is stable and you need some maintenance done.  I've seen people transition from areas like QA into development or other minor coding (like templating) to development since they are more familiar with the problems of the system.
- Hire junior level people when your company business is considered relatively stable.  Meaning that you don't need monstrous levels of hardcore programming where you're facing issues like downtime, etc.  These issues are well known and should be handled by more experienced people.  Junior level people excel more in using their enthusiasm and eagerness to appear and learn through doing more mundane problems.
- Use junior level people to solve non-critical problems.  Get them familiar with how things ought to be done.  Make sure you have seniors who are able to mentor these people.  Getting them to work on production issues, simple bugs and related tasks are needed at first.  Once you get their trust that they are capable of handling their work, you can move them towards more difficult problems.
- Never use junior level people to do architectural things.  Architectual elements are the role of architects.  Decision making should be kept far from junior level people.  They are around to execute, not really think about company decisions, just focus on the problem before them.