Live data from Hacker News

Hire talent, not five years with Java

gillesleblanc.wordpress.com

41–50 of 121 posts

Re: Hire talent, not five years with Java

#41
post #22

Once upon a time (1969-ish), my father was hired as a programmer. He was an electrical engineer by training, but had zero programming experience at the time. Given a shortage of programmers, IBM placed an ad in the newspaper, hired smart people, and taught them how to program. Assembly. On mainframes. 40+ years later, companies are in a similar situation, but instead, given a shortage of engineers, they are simply wh…

Part of it is the difference in programming culture. With startup culture, which has many good aspects, also came the idea that the death march should be the norm. Meaning, 20-somethings should be working 80 hour weeks on a regular basis and projects should be shipped at the soonest possible moment it's even remotely feasible to do so.

This sort of working environment has no slack, no capability to operate effectively in apprenticeship mode, and little leeway to allow long ramp up times. And as a result it has become more difficult to positively advance the state of the industry or the average skill toolset of coders.

It's the classic problem, when you spend all your time in emergency mode fighting fires you don't have the cycles to be able to make improvements to systems or to other coders as well.

Re: Hire talent, not five years with Java

#42
post #22

Once upon a time (1969-ish), my father was hired as a programmer. He was an electrical engineer by training, but had zero programming experience at the time. Given a shortage of programmers, IBM placed an ad in the newspaper, hired smart people, and taught them how to program. Assembly. On mainframes. 40+ years later, companies are in a similar situation, but instead, given a shortage of engineers, they are simply wh…

The cool thing with EE is, in a lot of cases, the older you get, the more in demand you become (or at least, not any less wanted), since experience is so crucial in EE. With CS, it seems like every company's looking for young, energetic undergrads fresh out of college who know the latest technologies, in many cases to replace the older people. It's always seemed a little too short-sighted to me... not sure how my gen…

Don't overlook the fact that a lot of times the reason they want to hire younger folks is because they are much more likely to tolerate working insane hours and being on call 24/7. Due to their enthusiasm, lifestyle (often single with no kids), lack of experience, etc. And many companies still think that a coder who works 100 hours a week is obviously better than one who only works 40, or god forbid, 15.

Re: Hire talent, not five years with Java

#43

Here's the strategy we feel is working pretty well for us. First of all, our tech stack looks like this: Java/Spring(MVC)/MyBatis/Hibernate/etc Ruby/Sinatra/ActiveRecord/etc JavaScript/Angular/etc A bit of SQL (MS) We look for candidates of all skill levels who have experience with any "systems" programming language (Java/C/C++/C#) and any scripting language (Ruby/Python/JS). Once we've found a candidate that has any…

> Hugely over-architected solution? Eliminated.

I once made the mistake of over-engineering a coding test by , among other things, writing and invoking C code from a Java web application. While I thought it would communicate enthusiasm by going above and beyond, it in fact horrified them and I never even heard back.

Lesson learned.

Re: Hire talent, not five years with Java

#44
post #22

Once upon a time (1969-ish), my father was hired as a programmer. He was an electrical engineer by training, but had zero programming experience at the time. Given a shortage of programmers, IBM placed an ad in the newspaper, hired smart people, and taught them how to program. Assembly. On mainframes. 40+ years later, companies are in a similar situation, but instead, given a shortage of engineers, they are simply wh…

Part of it is the difference in programming culture. With startup culture, which has many good aspects, also came the idea that the death march should be the norm. Meaning, 20-somethings should be working 80 hour weeks on a regular basis and projects should be shipped at the soonest possible moment it's even remotely feasible to do so. This sort of working environment has no slack, no capability to operate effectivel…

While I agree with your overall message, the

> (...) death march should be the norm. Meaning, 20-somethings should be working 80 hour weeks on a regular basis and projects should be shipped at the soonest possible moment it's even remotely feasible to do so.

has got me puzzled: in my (limited) experience and from what I've read, a death march is exactly the opposite of shipping early. The usual story goes: a deadline looms, or a milestone slips, a middle manager decides to whip up his team instead of reporting it. Overworked team members can't meet another deadline, the client and/or upper management is kept in the dark about the problem, no extension of deadlines for sake of good metrics, rinse and repeat.

``It is done when it is done'' and shipping early is a panacea, not a cause of the problem.

Re: Hire talent, not five years with Java

#45
post #4

I think "years of experience" dates back to the era of widget factories where it actually made sense.

Not even slightly. Cranking out widgets is something you can pick up in less than a day. After a few cycles of retooling for another product, you've had all the experience you need.

A better analogy would be tradesmen. Apprentices worked under journeymen or masters for five or seven years before themselves becoming journeymen. A tradesman or craftsman works on projects or repairs, each one different from the last.

The years of experience aren't all about banging a hammer against a chisel, or tightening nuts onto bolts. Those years of experience are about problem solving; functional problems and non-functional. Not only do I have to deliver the product requested with quality and budget and timing, but I have to solve all of the problems that have nothing to do with the product but everything to do with its delivery: What if it's really cold on one day and someone doesn't turn up for an important presentation? What if one of my tools breaks and I have to improvise? what if the product specification changes halfway and I have to figure out how to implement that (or reject the changes) without causing a fight? What if local regulations change mid-project? What if technology changes a year or two after I start, and I have to learn something new to keep up?

These are the things an apprentice learns in seven years (for the last couple of thousand years), whether a plumber or a mason or carpenter. The best person to solve a series of such disconnected problems is someone who's been in the trenches and dug their way out. You don't get that from a book or from your bedroom.

Re: Hire talent, not five years with Java

#46
post #22

Once upon a time (1969-ish), my father was hired as a programmer. He was an electrical engineer by training, but had zero programming experience at the time. Given a shortage of programmers, IBM placed an ad in the newspaper, hired smart people, and taught them how to program. Assembly. On mainframes. 40+ years later, companies are in a similar situation, but instead, given a shortage of engineers, they are simply wh…

I'm not sure this is exclusive to the software/engineering industries. My impression in general is that people "back in the day" were much more content to stay with a single employer for their whole life–or at least long periods of time–than they are today. If that's the case, training new employees from the ground up made much more sense a few decades ago from an ROI standpoint.

I haven't got any statistics to back it up, though, it's just a general impression.

Re: Hire talent, not five years with Java

#47
post #22

Once upon a time (1969-ish), my father was hired as a programmer. He was an electrical engineer by training, but had zero programming experience at the time. Given a shortage of programmers, IBM placed an ad in the newspaper, hired smart people, and taught them how to program. Assembly. On mainframes. 40+ years later, companies are in a similar situation, but instead, given a shortage of engineers, they are simply wh…

Part of it is the difference in programming culture. With startup culture, which has many good aspects, also came the idea that the death march should be the norm. Meaning, 20-somethings should be working 80 hour weeks on a regular basis and projects should be shipped at the soonest possible moment it's even remotely feasible to do so. This sort of working environment has no slack, no capability to operate effectivel…

If there's no slack for training time, there's no slack for an empty position, which is what we have now.

Re: Hire talent, not five years with Java

#48
post #43

Here's the strategy we feel is working pretty well for us. First of all, our tech stack looks like this: Java/Spring(MVC)/MyBatis/Hibernate/etc Ruby/Sinatra/ActiveRecord/etc JavaScript/Angular/etc A bit of SQL (MS) We look for candidates of all skill levels who have experience with any "systems" programming language (Java/C/C++/C#) and any scripting language (Ruby/Python/JS). Once we've found a candidate that has any…

> Hugely over-architected solution? Eliminated. I once made the mistake of over-engineering a coding test by , among other things, writing and invoking C code from a Java web application. While I thought it would communicate enthusiasm by going above and beyond, it in fact horrified them and I never even heard back. Lesson learned.

Out of curiosity, why did you invoke C code from Java? Was it for speed or something else?

Re: Hire talent, not five years with Java

#49
post #26

Perhaps the better approach to solving this problem is to stop repeating it on tech blogs, and start moving to publishing and discussing it in HR blogs and similarly appropriate, targeted mediums. As stated elsewhere[1], this is undoubtedly the existing mentality of the audience to whom this article is written. Those who actually need this advice are the existing and future HR managers and departments who are in char…

> Perhaps the better approach to solving this problem is to stop repeating it on tech blogs, and start moving to publishing and discussing it in HR blogs and similarly appropriate, targeted mediums. I'm a computer programmer, but I also do recruiting for a company in Amsterdam and their approach is most definitely "talent". A typical question is "given two arrays, find all the elements in one array that are also in t…

Just saw the blog you write, and i must say: it is incredibly awesome indeed! I believe that travel expands one's mind greatly, and it would be a shame to not travel while you can.

I'm wrapping up my thesis here in Singapore now, and i'll buzz you when i'm done: it would be an awesome experience to interview with shops that emphasize on core CS concepts rather than some arbitrary piece of tech:)

Re: Hire talent, not five years with Java

#50
post #22

Once upon a time (1969-ish), my father was hired as a programmer. He was an electrical engineer by training, but had zero programming experience at the time. Given a shortage of programmers, IBM placed an ad in the newspaper, hired smart people, and taught them how to program. Assembly. On mainframes. 40+ years later, companies are in a similar situation, but instead, given a shortage of engineers, they are simply wh…

I'm not sure this is exclusive to the software/engineering industries. My impression in general is that people "back in the day" were much more content to stay with a single employer for their whole life–or at least long periods of time–than they are today. If that's the case, training new employees from the ground up made much more sense a few decades ago from an ROI standpoint. I haven't got any statistics to back…

My impression is that this is a problem of the companies own doing: In many cases they are unwilling to hold employees (because young employees are "better", so just fire them when they get "too old") and unwilling to give employees their fair share of the profits i.e. pay raises are almost always lower if you stay at a company than if you change. This two parts lead to people changing companies far more often than "back in the day" and now companies say "We cannot train people! Then our competition will just take them when they are trained!" - Yeah, because companies don't value their employees enough. And now we've come full circle.
Post reply on HN