Are there reasons other than budget for hiring "entry-level" programmers?
closed as primarily opinion-based by user40980, gnat, durron597, ratchet freak, Ampt Apr 24 '15 at 17:53
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
Great developers once had no experience, too.
Great developers are not only expensive but also hard to find. So, if you have a high-quality screening and hiring process, hiring entry-level developers can be a great way to find those up-and-comers and turn them into great developers.
There are plenty of other reasons:
- Growing your own talent. Sometimes it's easier to hire an entry level person and train them in the technologies and tasks you require.
- It takes less time to find an entry level person than a Sr. person.
- Replenish your work force. As many developers move up in a company, they often times don't write as much code. Someone needs to be available to fill this gap.
- Time savers. Even if a Sr. dev is still writing code, chances are they don't have time to do everything. They need to delegate, thus they need someone to delegate to.
Train the next set of developers the way you and your methods allow.
Assuming "entry-level" roughly means "fresh grads", there can be sinister motives.
A fresh grad most likely WILL NOT know a lot about his rights by virtue of the fact that he hasn't worked anywhere yet. Unless his uncle is a lawyer or a HR person, he definitely won't.
An experienced programmer might know about his rights simply because of the fact that he has gone through ups and downs in other companies.
It is easy to find loopholes, trick, manipulate and cheat fresh grads when it comes to complicated legal and HR issues and laws. You cannot do it easily with an experienced programmer who has worked in a few companies. Because, even if he hasn't memorized all the laws, he will know from experience about what is happening in other companies and will immediately catch if something is fishy.
In short: An experienced programmer has already fallen into the pit (made by previous employers) and knows better than to walk into one again. A fresh grad hasn't and won't.
Some things cunning employers want to cheat fresh grads on:
- Unpaid internship crap
- Anything related to hiring or firing
- Compensation and bonuses
- Working overtime
- Stupid NDAs and service contracts
- Enforcing the stupid NDAs and service contracts
Fresh grads just assume things are supposed to be that way because they don't know any better. So he/she is a jackpot to the employer.
DISCLAIMER: I know these things not because I do them, but because people have done it to me.
Why would you hire a senior programmer if you only needed someone to do grunt-work tasks?
Personally if I were a senior programmer that was asked to do nothing but simple tasks all day I'd quit.
Sometimes you have tasks that require doing but don't require the breadth of experience a more seasoned programmer will have. These tasks are often repetitive and not very meaningful as a programmer but are good for new hires cutting their baby teeth.
There are also considerations regarding people who can be taught. Often an experienced programmer who is not quite senior yet clearly not a new hire will have gained some experience yet has not managed to shed the "I already know everything", "Why should I change", "I don't like learning new ways" attitudes that you won't find prevalent in a new hire.
Fresh ideas? the stuff they teach at university is constantly changing, it could well be that the recent graduate that you jsut hired has some ideas that your seasoned programmers wouldn't consider because they are stuck in a certain way of thinking.
Altruism, I think any company has to appreciate that we all start somewhere, and if we don't get a start then we don't carry on being developers.
Cheap labor, not only does having a graduate recruitment get your cheap labour it can also foster relationships with local universities and lead to even cheaper if not free labor in the form of summer internships (I don't agree with not paying them though).
Not paying for a digger when all you need is a shovel, if you need a latrine dug why pay thousands for a digger, when you can get a pleb with a shovel. Sure the pleb with the shovel might advance to the point of being a digger, but until that point why pay for it.
Also experienced devs might get bored with stuff that they consider menial where a recent grad can learn an awful lot form it.
I don't know if it's true anymore (but was around 10 years ago) in the government contracting world (probably other industries also) the companies get tax write offs for hiring new grads.
- We need someone to do the boilerplate stuff, they need experience.
- We can teach them good habits, and with some tries get a good programmer in a few years.
The company I work for hires "entry-level" for specifically one reason. Its most mature and profitable products were developed on a 3rd-party framework that nobody has heard of or would spend the time learning otherwise. The position is advertised as no experience or degree required, as all the training will be provided in-house to people with the desire to learn. It's also an excuse to pay pathetically low salaries, and it works since there is practically no risk of these new programmers taking their newly acquired skills somewhere else.
A lot of companies want someone whose mold-able who they can train to do things the way they want, not the way some other company did things. Also these positions tend to acknowledge that theres going to be a learning curve due to lack of experience and that the company is ok with that. The company is essentially trusting that that individual will eventually become a really good asset to their company over time.
Many times it is easier to draw on a blank piece of paper than to update an existing sketch.
In software this is generally called greenfield vs brownfield development.
If done right you can end up with someone in the end that understands your business better and is enthusiastic.
You actually need to ensure that you have a professional resource that can take the newcomer under their wing. As long as you find yourself someone that is enthusiastic and proactive about their own development they will shine. If you find them tinkering around with some idea, push and encourage it, they will feel they can contribute something.
You need to treat them like an apprentice in a body shop, get them doing shitty jobs, but at the same time give them their own time to experiment, it's the best way I've found. You end up finding they come to work the next day with something they did at home and are excited about telling you what they've done.
In addition to the reasons already mentioned, we should note that this is a pattern intrinsic to human nature. Throughout history we can see skilled labor organized a certain way, with masters leading a group of apprentices and a smaller group of journeymen (intermediate-level craftsmen) to build things together.
It pops up again and again, with different names and details, but generally the same basic pattern, because it works well with the way our brains are wired. So we shouldn't be surprised to see similar organization in computer programming, which is another form of skilled labor. We may call the masters Architects, the journeymen Senior Developers and the apprentices Junior Developers, but the pattern is the same.
You may want inexperience programmers so you can train them to do it your way. This assumes:
- You will train them; and
- You have a better than average way of doing things.
You might also want an inexperienced programmer, because you don't require programs that would challenge or interest an experienced programmer. Also if you have have experience programmers, you may be able to challenge them by having them mentor the inexperienced programmer.
An inexperience programmer may have a perspective you need. NIH (not invented here) and WADITW (we alway do it that way) are not always best. Choose someone who will ask probing questions. Be prepared to change your ways.
You may be better off with an experienced programmer, as the may have higher productivity per dollar. Documented productivity ratios are something like 26 to 1. You may be lucky and get a highly productive inexperienced programmer.
If your employee turnover rate is high, you may only be able to hire inexperienced programmers.
If your budget is per head, inexperienced programmers may be all you can afford. This does not mean your project will cost less. It is far more likely cost more. Fewer experienced programmers may be more cost effective.
Experienced programmers bring baggage from prior projects. Some of this will be good, and some of it will be bad. If you don't have the resources to minimize the bad and maximize the good, you may want an inexperienced programmer. They will have different baggage.
You may require skills or knowledge that your experienced programmers don't have, but that an inexperience programmer has. Hire them and do some cross training with your experienced programmers.
It is good to grow talent. Find at least one inexperience programmer for your team. Train them and mentor them. Challenge and support them. Learn from their fresh perspective as they learn from your seasoned perspective.
Many businesses in the US today want someone to come in, do a task and leave. They don't want someone who will take time to figure out something, nor do they want someone who needs things explained. Consequently, most ads for developers request/require umteen years of experience with everything.
What I think should change is to change to a different corporate culture. The Daily WTF had one essay called "Up Or Out". While the model mentioned in that essay is one used in the legal profession (as well as some consulting companies), that model does not map well to existing corporate culture.
Budget should almost never be the reason why you should hire fresher.
The primary reason why you recruit freshers is when :
you need fresh energy and talent that makes organization more vibrant
You need to work in cutting edge or disruptive innovation where you don't want to hire people from old school of thought
You are yourself a young company wanting to explore the world and want to set it's own ideology and style.
All these answers with great and noble reasons for hiring entry level people are nice and all.
The real answer is: a company gets the best resource it can get for the amount of money it's willing to spend. That's business. If it's not willing to spend much, it advertises for someone who won't cost much. "Entry level" is a job posting signal phrase intended to result in that outcome. HR won't waste time interviewing rock god developers who they can't afford.
If they're lucky, they find someone underselling their value, underpricing themselves as "entry level" when in fact they're more senior than that. Can you imagine a company not snapping up such a tempting offer? Of course not. All the "we can develop them in our image" "fresh energy makes us more vibrant" stuff goes out the window at that moment.
So. Browse most of these answers to see the nice, happy-world justifications for it. The real answer is: yes, that decision is almost always budgetary.
My guess the other reason is the lack of available/willing better programmers.