Are there reasons other than budget for hiring "entry-level" programmers?
-
7were not you an “entry-level” programmers one day?– AndreyCommented Mar 4, 2011 at 18:30
-
I see 2 alternatives, but there are possibly more: 1) Senior programmers suffer the syndrome that the senior-er they get the closer they're to death, so if when that day comes they don't get replaced by some entry level programmer (a.k.a. code monkey) the profession would be extinct. 2) According to scientist, for senior developers to update their knowledge and learn new technology is much harder than simply hiring someone who is less experienced; given that both alternatives achieve the desired effect of feeling superior, the latter easier alternative is usually preferred.– TrinidadCommented Mar 5, 2011 at 16:14
-
1I remember reading somewhere that Microsoft hires fresh grads because they are free from any one particular mindset - which experienced developers have. NOTE: I have neither hired for MS nor have been hired by MS. All I know is what read.– user19224Commented Mar 5, 2011 at 18:07
-
Because if no one hires them, you (I'm still at school) will run out of programmers quickly. So, before or late you have to– BlackBearCommented Mar 5, 2011 at 18:16
-
Where are the old ones going? Is there just a constantly-increasing number of developer jobs? Is Soylent Green programmers?– ArmandCommented Mar 6, 2011 at 10:32
19 Answers
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.
-
23+1 for a positive answer...it's not just about having someone do grunt work, it's an investment. Commented Mar 4, 2011 at 16:50
-
-
Some companies that i've worked for have 'junior dev' recruitment programmes that spend a couple of months training them all to ensure that they're all on the same page and then the padawans are placed into various teams around the business among more experienced colleagues so that they can absorb the wisdom of experience and best practices. Commented Mar 5, 2011 at 9:38
-
+1 that's what I decided to do. However it much more time consuming but it really worth it (social aspect)– user2567Commented Mar 5, 2011 at 11:05
-
1The place that hired me out of university did most of their recruitment from new grads because they wanted to train them up in that organization's own culture. They felt that hiring someone with experience meant you've got to beat the bad habits out of them. Commented Mar 2, 2012 at 13:20
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.
-
Why aren't the senior devs writing code? Are they managing the junior devs and reviewing their code?– ArmandCommented Mar 4, 2011 at 17:02
-
@Alison: Depends on the team structure. Sometimes the more senior developers are more involved in design, architecture, planning, and the more junior ones actually have to implement. Commented Mar 4, 2011 at 17:19
-
3@Alison, I've worked on teams where I had so much work to do designing technical features, estimating and communicating what was technically feasible to product managers that I had little time to code.– NicoleCommented Mar 4, 2011 at 17:28
-
1@Alison - Managing and designing, among other things. For example, I'm currently on 3 projects at my current company, but am only active coding for 1. The other 2 I'm managing the people doing the coding b/c I know the design and the requirements, but I don't have the time.– TyannaCommented Mar 4, 2011 at 17:37
-
@Renesis did you enjoy yourself? Do you think a non-developer could have sensibly filled these roles?– ArmandCommented Mar 4, 2011 at 17:40
Train the next set of developers the way you and your methods allow.
-
but you could hire a senior developer who already shares these values, couldn't you?– ArmandCommented Mar 4, 2011 at 16:48
-
@Alison, many answers have already stated that finding quality senior developers that are in the job market is difficult. Adding more minuscule constraints to that means you'll be looking to fill that position for a long long time.– Ben LCommented Mar 4, 2011 at 17:36
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.
-
5I haven't worked on a team where smart developers couldn't abstract away the "grunt work" to almost nothing.– NicoleCommented Mar 4, 2011 at 16:49
-
Couldn't you hire a senior developer, automate the grunt work and then lay him off?– ArmandCommented Mar 4, 2011 at 16:49
-
3@Alison: Normally you'd hire a short-term contractor to do that (if possible). Commented Mar 4, 2011 at 16:52
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.
-
Hmm I get your second point, but surely there is a constructive way of working through this phase rather than starting fresh? Otherwise the world would be full of mid-level programmers who can't work anywhere new...– ArmandCommented Mar 4, 2011 at 16:50
-
@Alison - As I've seen it work out, these tedious positions only hold people for about a year. Usually the person finds a new position with a little more flexibility within the same company or moves on to a new company using the last one as a spring board. Commented Mar 4, 2011 at 17:17
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.
-
So they're playing the long game, hoping eventually to have a senior dev who they can pay less?– ArmandCommented Mar 4, 2011 at 16:47
-
No... if they're a good company as the abilities of the employee increase so should their pay. If they're a sleazy company that may be exactly what they're doing...– KennethCommented Mar 4, 2011 at 17:00
-
I should also add, that they may be hoping that by getting them when their fresh in the industry they likely will be able to retain them for long periods of time and reduce the need to fork out additional costs for hiring and retraining of other employees later...– KennethCommented Mar 4, 2011 at 17:02
-
2+1 mold-able.. Yes.. its easier to teach someone doesn't know a lot than to argue with some experienced person and make them change.– user19224Commented Mar 5, 2011 at 18:04
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.
-
Haha good point. I guess I meant when advertising a role rather than filling it.– ArmandCommented Mar 4, 2011 at 16:46