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 whining about it. Presumably, with tools that are 40+ years better that making it "easier" to program, such a system of the past would be reasonably replicable today, no? I've seen a few things pop up here and there - hungryacademy and such, but, by and large, this is the exception far more than the rule. Once upon a time, companies would hire and develop talent, investing years to develop the talent with years of rewards on the end for both sides of the deal. Now? Companies expect hires to come fully trained, ready to deliver from day one, at their own expense (and much debt to the banks). Employees have no loyalty (and for good reason).
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.
Funny that I see companies complaining about the lack of skilled workers here in Brazil, but they are not startups... they just don't want to pay the price.
They want engineers, programers, etc. with huge experience and paying a little. Just yesterday I saw a news article talking about the lack of car mechanics... and they say (like it is a great thing) that salaries go high as $450 bucks a month (40h per week)... they don't understand why nobody wants to be a mechanic :P
Total compensation or salary? I'm pretty sure mechanics are paid a base + commission of the sale. The less time they spend fixing the car the more commission they can make (as they move on to the next car). It's an incentive to work. If the labor takes more than the estimate, then the shop and the employee are losing money.
It seems this sum is all they get, as they said most mechanics prefer to work on their own (informally) as they get more money. Besides, comissions don't contribute for their final retirement salary and stuff like that.
> (...) 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.
Death march is often the norm, and when more effort is needed the only option is a super death march or just giving up.
And yes, it's not a good way to work. Nor is it even a fast way to work. It's a an equilibrium point that is reached when certain initial conditions in regard to the value that is placed on the appearance of work and dedication are higher than craftsmanship et al is valued.
For people who are immersed in that world view it seems perfectly logical that adding more hours worked will make everything better. But the paradox is that it doesn't, it often makes things worse, for a whole laundry list of reasons. People become physically and emotionally exhausted by the pace, there's no room for higher level improvements which are often the only way to achieve orders of magnitude gains in efficiency, productivity, and quality.
There are a handful of companies that do things right and at those companies employees tend to stick around for not just a few years but decades and the products they make tend to have an outsized impact on the industry (valve, blizzard, 37signals, pixar, etc.) But it's still so hard to fight against the conventional wisdom.
All it takes is unrealistic deadlines and you end up with a death march. Unfortunately, some people game the system and assume burning people out is worth it.
Very succinct. If a company can afford to let a position go empty for six months because they "need someone who can hit the ground running," then they don't really need someone who can hit the ground running.
Yes, this. In the analysis that I'm building up (start here: http://michaelochurch.wordpress.com/2013/02/19/gervais-princ...) it's the tough culture. It gets people to work hard but not smart. Long-term strategic considerations are ignored, it's all about now, now, now. That mentality can be good for short bursts of superhuman productivity, but after a few months, it taps out.
The apprenticeship makes sense in the lawful-good guild culture; tough culture is chaotic evil. (Typical corporate rank cultures, where subordination is key but you can get away with pretty much anything-- even doing nothing for years-- so long as your boss likes you, are lawful evil; Valve's bossless, self-executive mode is chaotic good.) So the tough culture of startups is the exact opposite of the progressive (but usually incapable of immediate scaling) guild culture.
Typical corporate rank cultures are short-sighted because they've lost vision and short-term P&L is the only thing that matters. Risk-reductive management means that no one gets to do anything long-term because no one is trusted to bet that much time on anything.
VC-istan is based on a get-big-or-die mentality. These companies end up with tight deadlines because they're forced to hire so fast. That makes them panicky and stupid when it comes to operational concerns... and it's bad for culture, but no one cares about "culture" in something that exists to be bought by Yahoo in 3 years.
The future isn't going to be built by VC-istan, but by a fleet of ~50,000 small-to-medium businesses formerly called "lifestyle" companies, and the whole ecosystem that grows up to support these "yeoman capitalists". It's going to be built by people that, right now, no one will fund.
The problem is that no one will fund these companies now. Bank loans are good for dry cleaners and restaurants that are unlikely to go to total failure. (Half will be closed in 5 years, but most because their owner-managers could do better elsewhere-- opportunity cost.) VC works for a 5% shot at being a billion-dollar concern. Who funds the 30% chance at becoming a 20-person lifestyle company that, while it never makes a billion, pushes technology forward in a major way? No one, yet. There are "moral hazard"/principal-agent problems to be solved, but they aren't that hard.
I'm actually addressing that in my 17th part of the Gervais / MacLeod series. I'm between jobs (I have offers, but I'm not working right now) and I've had time to really attack this problem. It'll probably be out around 3:00 today.
The future isn't going to be built by VC-istan, but by a fleet of ~50,000 small-to-medium businesses formerly called "lifestyle" companies,
The problem is that many technology companies have natural economies of scale. It is not realistic to have a world where you have 1,000 mom and pop search engines instead of 1 Google. One search engine becomes a little better, so more people start to use it, it can make more money, invest in more technology, become even better, get even more users, and eventually the top dog becomes a run away success. Since the entire idea of technology is that you research the novel technique once, and then can use the technology over an entire user base at a low marginal cost, there is a natural economy of scale.
There is of course already a very large economy of "lifestyle" businesses. But these businesses are either b) not in the technology business (restaurants, retail, services, etc.) or b) in an extreme niche of technology where there are so few customers the company never grows that big.
I really do not see how you can break a Microsoft or Apple, much less a Google or Facebook, into 50,000 smaller businesses.
Google was still an excellent search engine when it had 1/100 of its current codebase. Fifty programmers could deliver something of nearly comparable quality (excluding in-house knowledge that gives it that extra 0.01%). Google's obviously doing a lot more than Web Search, now.
Web Search is a Big Problem and, as you said, it's a winner-take-all, red-ocean business. Google managed to come in when the state of the art was horrendous (few considered search to be an interesting problem; it was "solved" but shitty). Now Bing is almost as good as Google, and certainly far better than Google was when it established dominance of Search.
You say: I really do not see how you can break a Microsoft or Apple, much less a Google or Facebook, into 50,000 smaller businesses.
You don't. Big companies are not going to die out overnight. They'll still be there, they'll still be strong and important, they'll still provide utility and commodity services, but the Big Companies of the mid-21st century might have 3000 employees instead of 25,000. So where will those other 22,000 go? Smaller companies. They'll be more independent.
There are a lot of problems that can be solved by technology but require some "niche" competence. Take the emerging field of data science. Machine learning is very powerful, but domain knowledge is still key. There are thousands of domains that are going to be needing what's currently a very high level of data competence (not big data, but smart data for sure) in people who also understand their problems. That makes room for thousands of lifestyle businesses.
There are a lot of problems that can be solved by technology but require some "niche" competence. Take the emerging field of data science.
It's possible that market dynamics will change in a way that favors small businesses over large corporations. Is it likely? You have not convinced me.
Google needs thousands employees in order to run the infrastructure that maintains its current scale, and in order to develop the features needed to keep its competitive edge. Fifty employees is not going to cut it.
It is conceivable that it could be run with, say, 5000 employees instead of 50000. It is possible that the additional 45,000 employees are basically unprofitable, executing vanity projects to give shareholders the impression that Google is innovating in new directions. If that is the case, as programmers we should probably be thankful, because that money is going to bid up our salaries, rather than being paid back as dividends to wealthy shareholders.
In other words - even if businesses could be run much more efficiently - the beneficiaries would be the shareholders, not engineers. Only if the shareholders used their extra dividends to buy more software would it balance out to engineers. If Google suddenly became far more efficient, fired 90% of its workforce, and paid dividends to shareholders, that would not magically create a market opportunity for 1,000 new small businesses to pop up. The new jobs would be in whatever the shareholders getting the dividends choose to spend their money on.
...because no one is trusted to bet that much time on anything.
Right and, maybe, this partly why a growing number of people do not stay at a company for too long. (I think you mentioned this idea (that, basically, human labor is an easily trade-able commodity) in one of your Gervais / MacLeod posts.)
>> . The positive-sum “win-win” outcomes that Technocrats seek exist, and they’re all over the place, but they never come without risk. Once the company decides that creative risks are intolerable, what’s left is zero-sum social-status-driven squabbling.
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 generation of CS majors is going to do in the long term.
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.
It comes back around though. Currently there is a severe shortage of COBOL developers, and they are commanding very good salaries. Many major corporations and banks still use it. Today's cutting-edge is tomorrow's underdocumented legacy codebase mess to clean up.
They tend to recruit a lot of youngsters because coding-jobs are typically low on the CS ladder and don't forcibly attract people with more experience (that's a general statement, I perfectly know that specialized coding can get extremely lucrative).
"not sure how my generation of CS majors is going to do in the long term"
The way to bet is "very badly", and if you're a conventional salaried employee have your exit strategy well in place by the time you hit 35. Expect to be conventionally unemployable at 40, unless you can hide your age.
The way to bet is "very badly", and if you're a conventional salaried employee have your exit strategy well in place by the time you hit 35. Expect to be conventionally unemployable at 40, unless you can hide your age.
29. I don't expect "conventional employment", as defined by VC-istan or the corporate megaliths, in 11 years. Those will exist, but I don't think they'll be where the exciting action is.
But yes, if you're applying for subordinate positions that any idiot can fill, and you're 40+, you did something wrong. You don't need to be a manager by 40, but you need to be at a level of skill where it's obvious that you don't need traditional "here's work, go do it" management.
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.
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.
I was there "back in the day". There were lots of people who stayed with a company for decades as well as lots who jumped ship after a couple of years when their employers couldnt keep up with the salary escalation. One or the big differences was that there were many more layers of management. Engineers were reasonably well paid, but the salary range was fairly compressed. In general the highest paid engineer could not make more than his manager. When a man got a family and needed more money, he was promoted to a manager. There was the HP Way where nobody was fired and engineers were taken care of.
While there were startups, there was not the froth of new ventures that there is today. Finding a job was very much word of mouth, newspaper classifieds, and head hunters, not the easy searching of Craigslist of today.
>but instead, given a shortage of engineers, they are simply whining about it.
I don't like this phrase "shortage of engineers". What there is a shortage of is engineers who will work for the shit salaries these companies want to pay. Labor is a market like anything else. If there is more demand than supply....
I agree that companies need spend more time developing talent than chasing a dwindling pool of people who already have it. My mom had a similar career path to your father - she was hired out of college in the late 60s with zero programming experience by one of the railways to work on scheduling systems.
There is one difference, though - the opportunity to learn programming (actually, to learn most things) has exploded in the past few decades. In 1969, I think you needed access to expensive technology (like a mainframe) to have the opportunity to learn. Now, a few hundred bucks and a web connection gets you started. So if someone wants to be hired into a programming position with no experience in 2013, that does say something about the candidate that it didn't say in 1969.
They can also just hire H1B workers who have the exact skills they're looking for while paying them level one wages. Obviously this only applies to America considering H1B, but other countries have similar programs.
I don't blame the foreign workers, I blame the employers who undermine the value of our engineers to benefit their own bottom line.
From what I've read, IBM was hiring crossword players, chess players, anything that seemed to indicate intelligence.
I agree it's better to hire for talent (or aptitude or intelligence) over experience, but sadly in the United States these days that is pretty much illegal. So how much of "hiring for experience" is HR departments not knowing any better, and how much is it their better knowledge of employment law and not wanting to be sued?
Reminds me of one section of the Stripe article on hiring: "Hire People instead of roles". I couldn't agree more with both authors (Stripe and OP).
"One thing that's worked well for Stripe is bringing on people who didn’t have an immediately obvious role in the organization. If you can think of one thing this person can do, then there’s probably ten more you're not thinking of that he/she can do two months from now. Focusing on hiring to fill a role could make you more likely to sacrifice quality just to get someone with the right skill set."
I think the most interesting bit of the Stripe article was that they did most of their hiring via referrals. That's really one of the very few ways you're going to be able to hire "people" rather than specifically to certain job descriptions. Their recruiting method matches their strategy. All too often companies will say "we hire people, not roles" but then post all their jobs on job boards where the specific role is well defined. :-/
Who is the target audience for this sort of advice?
The people who will understand this figured it out long before they were in a position to hire other people. It's just obvious and is repeated so much (don't hire for specific experience) that it is a cliche.
The people who don't get this will never get it, even if you paste stickers that say it on the windshield of their car and whisper it in their ear as they fall asleep each night.
So it's all great to repeat this for the 3 newbs who joined our community in the last 5 minutes and haven't heard this 80 times already this week, but it shouldn't be on HN's homepage.
There are also people who get it but don't care. Not all companies need, want, or can keep the most talented developers. For them, it is fine to have someone who just has "5 years programming with java". This advice is too general and doesn't apply to everyone.
Here is another active discussion of company hiring procedures here on HN. Most of us have been hired for at least one job in our lives, and all of us who have built up an organization have had occasion to hire someone else before, so we all think about this. I searched the comment thread to see if anyone has linked to the Hacker News FAQ on this subject. The last full posting of that FAQ was a while ago,
and the tl;dr of the FAQ is "If you are hiring for any kind of job in the United States, prefer a work-sample test as your hiring procedure. If you are hiring in most other parts of the world, use a work-sample test in combination with a general mental ability test."
"Reasons for being selective when choosing personnel selection procedures" (2010) by Cornelius J. König, Ute-Christine Klehe, Matthias Berchtold, and Martin Kleinmann backs up this advice:
"Choosing personnel selection procedures could be so simple: Grab your copy of Schmidt and Hunter (1998) and read their Table 1 (again). This should remind you to use a general mental ability (GMA) test in combination with an integrity test, a structured interview, a work sample test, and/or a conscientiousness measure."
Some of the best developers I have worked with weren't Computer Science or Software Engineering graduates, but had Engineering or Electronics degrees. However, some companies wouldn't hire them because their degrees didn't fit their definition of correct.
All the points made about years of service not equaling ability are absolutely proven, yet ignored by many - I'd rather work with someone who can break problems down, ask the right questions and think logically - as opposed to someone who can force a program to work because they know the syntax. Some of this is how candidates are interviewed too - technical screenings alone rarely find someone who is good at software development.
Writing a syntactically correct program quickly, is the not the same as writing a good piece of software.
In general, this article belongs among the best articles nobody will read.
It looks like I might finally get a job as a Django/Python developer after 3 years of unemployment. Encouraged by my local course for unemployed, I visited the company personally and handed them a dead tree CV and cover letter. I was mildly amused to find they seem to be just 3 guys in small dusty room. I ended up on a job interview of sorts I wasn't prepared for. It ended with a talk about games, Fallout and Counterstrike were mentioned. The best part for me, I got a homework assignment to test my skill.
It is embarrassing that in this day and age a dead tree copy of a CV, handed in in person is what gets peoples attention, but it does.
Also maybe print it in an unusual size -- that way they can't file them away for "maybe later" as they won't fit and they are forced to have the CV on their mind. An unusual color might also prevent it from getting lost in the stack of resumes.
Poland. 90% of job offers seems to be PHP, Java, C#, C++. Python appears from time to time on a Django offer, but otherwise is seen as a scripting language for automating software tests.
I used to complain to the HR department at my last company about this kind of stuff all the time.
Even after working at the company for almost three years, I wasn't technically qualified for any of the job postings on the site. I had friends who didn't apply just because they didn't have all the skills in the "required" section of the job posting.
Luckily, the developers in charge of interviewing and hiring people seemed to understand that hiring someone smart was better than hiring someone with "experience" in random technologies.
The issue is that "tallent" is nebulous, and difficult for companies to both define and measure. How does a company determine one's capacity to adopt new technologies? How do they adequately determine who is "smart" and who is not? The reason companies resort to hiring based off of experience is that experience is a reasonable if imperfect proxy for skill, and because someone who has worked with a technology for some given amount of time can be reasonably expected to have attained competency in it. Experience is quantifiable and the link to ability is solid, making it an efficient metric for use in hiring.
Obviously, the best case scenario would be for companies to deduce who will have an affinity for certain technologies before they actually use them, but that's too complex and involves the type of decision-making to which HR departments are averse.
Let's also clarify why experience is misleading in general. The candidate might have no experience but could have been an early programming enthusiast with tons of projects under his belt. Current recruiting systems reject such talent or offer them very poor packages.
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 charge of hiring.
I spent some time about a year-and-a-half ago building up and managing a small internal development department at a mid-size corporation. I was involved in finding talent to fill development roles in the company twice. The first time, I sat in on an existing search and interviews for a role in a different department. The process could not have been more broken--the position had been open for roughly one year, and the interviews yielded no hirable candidate (as judged by the individuals making the hiring decision). The second time, I led a search for positions freshly opened for my department. The process could not have been more smooth--three strong candidates were hired within three weeks. The only significant difference between the two hiring pushes was the approach--the first was focused entirely on a candidate who had n years of experience on platform X; the second focused on candidates who showed the greatest talent and aptitude in previous professional and personal projects, and gave the greatest indications they were a great fit for the personality of the team.
After we completed our hirings, the VP of HR pulled me aside to mention she'd never seen anyone conduct interviews like we did (she sat in on a couple after hearing about how we'd done the first candidate interview), and was impressed by the way the candidates responded in the interviews. She could "feel" which candidates were going to be hired, even though she had no knowledge of software development. We discussed the differing approaches between hiring for talent and hiring for n years of X experience. She intuitively understood the difference, but had not ever seen it in practice as intentionally as we pulled off.
Programmers understand this. Small businesses who are predominantly programmer-driven or -dependent understand this, too. Even big businesses who are primarily technology-focused show signs of getting this as well (a recent round of interviewing with an Oracle company surprised me with how much they were focused on the right things).
The proverbial dragon to slay here is the HR departments, managers, students, and training programs lacking this advice as fundamental practice. Perhaps we need to see more process-oriented and manager-level technologists joining up with HR professionals to advance the point. Maybe HR departments and educational efforts could start creating Developer Advocates to assist in crafting better approaches and more finely tailored practices to support development/engineering talent. These might be the vanguard of producing better job descriptions and interview processes to hire talent that is more competent, productive, dependable, and retainable.
The most important lesson I learned when I worked with a formal HR department to hire new people is that they care. They really do. They don't want to hire terrible candidates who are going to be miserable, hate their jobs, and drag down a team. They want to empower people to improve professionally while taking care of a company's needs. We need to start working with and spreading this advice among the HR professionals who will increase their value to both companies and personnel by including it in their standard procedures.
> 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 the second array".
Most people come up with the standard O(n*m) "two loops" solution the first time (for x in first, for y in second, if x == y ...). The company might let that slide as interview nervousness and ask if there's a way they can do it faster. They completely understand if your programming background is different and asking "trivia" questions about a given language or requiring you to check some tech boxes is silly. You just have to be competent.
Sadly, most programmers aren't competent. If they tell me they're comfortable with OO programming, I'll ask them to define OO programming for me and then I squirm as I listen to them. But then gems show up and I have a lively conversation with someone who really knows their stuff and we offer them a relocation package to Amsterdam.
Helping people live their dreams like that is really awesome, but I couldn't do it if I was forced to demand that programmers check off boxes on a form.
(Relevant side note: I've routinely worked for companies for which a knowledge of UML was "required". I've never used this in my professional life)
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:)
Glad you like it! I've lived in five countries so far and were it not for a two-year-old daughter, I'd keep country-hopping (though my wife and I have considered moving to Malta).
I don't think you're wrong. But could you define talent? That's something that bugs me endlessly. Talent gets thrown around recklessly everywhere. Is talent smart and gets stuff done? Is it more than that? I feel pretty confident I can identify "talent" but the blog post you are responding to isn't written for me or you, it's written for people who are already doing things the wrong way and content with it.
We say hire for talent as though talent is self explanatory. I don't think it is. Maybe we generally feel like we know talent when we see it but that's not satisfactory advice if what we aim for is to give advice to people who struggle to hire good people. If you are the kind of person who hires for X years of experience you probably aren't the kind of person who feels confident identifying talent outside of a solid definition.
"Hire for talent, train for skill" means to screen for more general intelligence and problem-solving aptitude rather than specific buzzwords. You want smart people who will pick up anything you throw at them quickly, not just people who have hit all the keywords in their resume.
It may sound squishy, but it's really not. You can tell smart people pretty quickly from talking through logical problems with them. Dumb people will ask irrelevant questions and want you to hold their hand and walk them through it. Smart people will ask smart questions and deduce a path to the solution.
> We say hire for talent as though talent is self explanatory. I don't think it is.
Absolutely true. A sibling comment[1] mentions an approach that is a bit closer to what I'm getting at. I personally hate trivia-ish questions when I've been interviewed and have attempted to eschew them when I've interviewed/hired. I try to focus more on questions that give me an insight into how a person thinks. So, I tend to refrain from asking definitional questions, and instead, opt for questions that can't be answered with a parroted statement of "X is like Y for Z."
> But could you define talent?
Heh. That's so subjective, isn't it?
I try to gauge talent in programmers by listening to how people reason through problems. Generally speaking, I look for the ability to confidently walk through how they'd approach identifying and resolving a bug in a software package they know nothing about (say, because they've just been brought into a product team with a 2-yr-old codebase), or how they'd tackle architecting a complicated data-heavy backend, or what kind of pitfalls they'd be mindful of in defining UI/X for a mobile application, etc.
I am wary of developers who start talking about programming languages and frameworks as solutions to higher-level, abstract concerns. That is, given the problem of integrating systems X and Y, hearing Ruby, Python, Django, or Lift as part of the solution before it's appropriate to discuss a stack. I'm also very circumspect when new developers join a team and advocate for technology/language/framework X to solve problem Y, when X is the thing they used for n years before joining the team.
I also try to tease out a person's decision-making abilities. This has been a much more difficult talent to assess. I've seen a lot of inability to assess a problem and summarily decide how to appropriately move forward--that is, the kind of person who gets too bogged down in talking through a problem, and is unable to make a decision on how to actually get started solving it. I've found a team is highly unproductive when there isn't at least one person who is able to codify the team's thoughts on a problem into a pragmatic approach to get work done--especially when they lack management figures who know enough to help make informed decisions.
> If you are the kind of person who hires for X years of experience you probably aren't the kind of person who feels confident identifying talent outside of a solid definition.
Certainly. Which is why I suggested a better approach is to focus efforts on those who are in hiring positions (be they HR professionals or otherwise) who could use the help and input of someone who is able to confidently identify talent.
If this were true, then you would never see a problem with startups too small to have HR departments. But you do. It might differ subtly from the big companies, but it's absolutely there.
Everyone doing hiring thinks they are the smart exception and everyone else is stupid.
> Everyone doing hiring thinks they are the smart exception and everyone else is stupid.
I apologize if I came off sounding like this. It certainly wasn't my intention. I just wanted to suggest partnering with and moving these types of discussion into the forums where they'd be helpful--those sources used by persons involved in and responsible for hiring decisions.
I didn't mean to imply this was HR-dept-specific, or that small startups did not have the problem. I was just using that as shorthand for 'professionals who are responsible for hiring'. Maybe there are enough of them reading HN, but I'd also bet they rely on mgmt/hiring advice from other channels, as well.
Talent is a function of experience. It's not that you shouldn't hire for experience - you should. The problem is that the model most people have for quantifying experience is flawed.
As it says in the article, 5 years of experience for one person might be the same as 1 year for another.
To solve the problem, we need to borrow an idea from RPGs: experience points.
Funny, I think it's the other way around. Experience is a function of talent. Talented people gain xp points faster and therefore level up faster. Or rather, they have lower xp requirements for new levels.
It could be that way... I doubt it though. I don't believe anyone is that innately talented. Try picking up a few musical instruments that you don't know how to play. Genius is learned, not inborn. You need to be lucky enough to win a certain IQ and have all your fingers and toes, but after that it's perspiration.
Find me a child prodigy genius who didn't come from a well to-do family who paid for tons of tutoring. Find me one from a slum. (hint: you probably won't find one)
> Without a degree, he left college and continued to pursue independent research in mathematics. At this point in his life, he lived in extreme poverty and was often on the brink of starvation.
>Born at Erode, Madras Presidency (now Tamil Nadu) in a Tamil Brahmin family of Thenkalai Iyengar sect[2][3][4] Ramanujan's introduction to formal mathematics began at age 10.
"Brahmin" are the elite hindu upper class.
I would credit you with contradicting me but you haven't.
However, that's a pretty interesting link. Thanks for sharing.
>> was an Indian mathematician and autodidact who, with almost no formal training in pure mathematics, made extraordinary contributions to mathematical analysis, number theory, infinite series, and continued fractions. Living in India with no access to the larger mathematical community, which was centred in Europe at the time, Ramanujan developed his own mathematical research in isolation. As a result, he sometimes rediscovered known theorems in addition to producing new work. Ramanujan was said to be a natural genius by the English mathematician G. H. Hardy, in the same league as mathematicians such as Euler and Gauss.[1] He died at the age of 32.
-- no formal training
-- developed his own mathematical research in isolation.
We're talking talent here, upper class or no. Talent is talent ,even when it is not discovered. In this case ,it was
The analogy above was more akin to, you'll never reach level 70 if you just keep grinding the tutorial. It really doesn't matter how fast you learn. If you are not getting new experiences and being challenged, you will still be on a slow growth trajectory.
Sadly I think it only just occurred to me that I might be one of those 1 yr / 5 times people. Only because my job was mainly CRUD work. I did get to do some other stuff but it was not often. That place closed down and I've been looking for work since. Feeling like I must not have learned enough (or the right stuff) since I have had many interviews and not gotten any offers.
How much of an average developers time isn't CRUD?
How do you get the experience to do other things[1] unless you needed them for that one off project?
1. Unless you are talking along the lines of specializing in something idk what these things might be.
You have my sympathies. One thing that might help it to pay attention to your attitude and demeanor. One problem is thinking that you are humbly begging for a job and that they are in control of the process. A bit more of a chip on your shoulder may help. Sure some my be put off by an "attitude", but if you arent having any success, why not? It may make you look like a can-do person.
So if I'm reading this right:
Act like I'm a pro and can solve all their problems.
My biggest issue is with confidence. It probably shows in interviews.
I know that given the chance I can do just about any work (some might take more time but I am willing to put the effort in).
One of the other threads recently was about questions during interviews. I learned that there are a lot more things I should be asking about that I wasn't.
I have 6+ years experience now and am going for senior dev roles.
4 of those years are PHP and I feel company's and recruiters pidgin hole me as a "senior php dev".
I feel like I have to continue down the php stack + web dev path or take a pay cut even though I have non professional experience in mobile for example.
I understand where they are coming from but a little less narrow mindedness would be nice.
-gets ready for the 'no one other than a php shop wants to hire a dev with most their experience in php' jokes-
Yes. I increasingly get the feeling that I'm stuck in .NET-land because that's the only thing that recruiters feeding off of LinkedIn seem to care about when they "network" at me.
The key issue is probably time investment for companies. Using years of experience is the easiest way to judge 'ability', and it can be judged by someone non-technical that can ask simple questions about experience - so every applicant is not wasting the time of a tech team member. Pay a fresh grad 30K to review resumes and waste their time instead of your 120K tech lead.
A trend these days is using interests as a predictor of talent. Most of my clients (recruiter of engineers) could see two identical levels of professional experience, but if one of those candidates is writing Haskell at night that is the one getting the interview. The intellectual curiosity and interest in complex subjects seems to be an indicator of ability and/or talent. This could be something easy to teach HR and recruiters, and I always ask candidates about tech hobbies or "What do you run at home?" to get some insight.
Most below average engineers are probably not assumed to be researching complex concepts in their spare time.
To think that companies or individuals will not continue to use experience numbers in evaluating talent is overly-optimistic, but I think judging based on interests is becoming a useful means.
I would agree with OP, until when I has become a hiring manager myself. I do understand years of experience may not equal to competency in certain skill sets. But if you are going to run a hiring post, what kind of metrics could you use, on top of years of experience?
Putting something too generic (e.g. intermediate programmer, mid-level, etc.), you tend to attract a lot of non-relevant, hello-world sort of people.
Putting a laundry list of language features? You are afraid you could unwittingly weed out people you want, let alone the first person to complain would be the recruiter in HR.
Most hiring managers, myself included, just use years of experience as a guidance so that the candidate can get a feel of the expectations. I did hire candidates with lesser experience but with good technical competencies. Therefore there is no harm to try if you are confident you are a good fit. In fact, I will be really impressed if someone can sell and market oneself intelligently. Surprise me!
When I read resumes, and I don't mind personally sifting through hundreds a week, I look for a narrative. If there's a cover letter, that helps create the narrative. I want to see personal, professional growth on a resume. I wonder about time gaps and seeming to do the same job repeatedly but they're not deal-killers at the resume screen stage. I look for increased depth of knowledge and increased scope of influence. Both of those things make someone more senior, rather than having just repeated the same year x-many times.
If someone can sell me his/her story in the cover letter and resume, I follow up on that in a phone screen. I'm still looking for more proof of someone being "passionate" (overused term but often part of HR doctrine) and showing that they grow and grow and grow.
This has never made any sense to any recruiters I've worked with and has sometimes been a hard sell to others when I wasn't the hiring manager but I honestly don't know how else to screen for "has a lot of potential but maybe doesn't know our stack yet".
I'd love to hear how other people do this. I'd especially like to hear from someone who doesn't focus solely on what's in someone's Github repos.
That's interesting, and I suppose my resume shows that, although there are ups and downs, i.e. a very demanding job followed by one not so demanding.
What I do is to express a narrative in each job, showing how I did stuff that made a difference. I'm most proud of this ending to a sentence in my resume: "[my work] provided half of company revenues and enabled
another quarter (out of $5 million for FY92)" (it did go along with some demanding work, technically, and human factor for GUI/workflow).
The problem with that kind of requirements is that a lot of non-agressive people take it as a "meet this minimum requirement or the CV goes in the bin". I did this initially but then wen't fuck that and applied no matter what, as long as I thought I might be able to do the job.
Bingo. I myself would put them into a separate bin, and more thoroughly investigate the company to see if I wanted to work there, if I could perhaps weasel around the official requirements in my cover letter, etc. If you're more aggressive, bypass HR and find the hiring manager.
I wonder about this -- what would people like to see on the vacancy page instead, that would attract the right talent (instead of the right experience that happens to be relevant)?
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 level of experience with both a scripting and systems language, we send them a small coding project. The coding project is very easy. Any experienced programmer would be able to solve it in about an hour. We tell the candidates to solve the problem in any programming language and that the goal is to show off problem solving, testing and design skills.
Once we've received the code, we review it for the above stated qualities with an emphasis on clean, readable and well-tested code. We're not too hard on these code reviews, we just want to try to eliminate obviously poor fits. People who write no tests are immediately eliminated. Hugely over-architected solution? Eliminated. Code is bad enough the person might not actual be able to program? You get the idea.
Once the person has passed this stage, they come in for an in-person interview. They are asked to bring their laptop. When they arrive, the dev manager will show the candidate to the room where they will be interviewed, talk a bit and then come get two developers for a coding interview.
The coding interview is somewhat on a per-candidate basis, but fundamentally the two interviewers will review the code beforehand and find places for improvement. Improvements might be refactorings to make the code cleaner or new features if the code is particularly well-written. We first have the candidate give us a code walk-through and explain what's happening, thought processes, etc. Then one of the interviewers will pair with the candidate for a while and switch out with the other interviewer after a while.
The whole process thus far is an attempt to, as closely as possible, simulate what it would be like to work with this person on a real task. No writing quick sort on the white board. Writing code, at a computer, with an IDE as a pair. Google stuff, whatever your normal workflow is. We just want to know what it's like to work with you.
After the pairing part of the interview, we do a more informal group interview with the rest of the team. We're currently 7 people counting the development manager, a scrummaster/QA and a PM/QA. So the group isn't too big. This is an opportunity for more high-level and philosophical questions. "Why do you want to work here?", "Anything in particular you dislike about Java?". Maybe if they're more senior, I'll have them explain OOP to our designer to see how well they can mentor. At the end of this section, we open it up for questions from the candidate.
So far we've had particularly good success with 1) not wasting our time with people who can't code, can't test their code or are poor at designing the structure of their code; 2) finding good cultural fits - if someone doesn't like pair programming or TDD, we'll be able to figure that out as part of the interview; 3) not arbitrarily eliminating people because they didn't study their CS textbook ahead of time or aren't comfortable writing syntactically correct code on a whiteboard.
> People who write no tests are immediately eliminated.
Why would you need dedicated test code for a project that can be completed in an hour? This is definitely TDD-specific and most programmers would not do it.
However the candidates know up front that we are a TDD shop, so for us, a big part of knowing that a program is behaving correctly is having passing unit tests.
For a code interview I can see myself over-engineering a solution even though my day-to-day coding style is all about flexibility and readability. In my mind being able to over-engineer shows an ability to code.
This is good feedback. We've only gotten one submission that we thought was grossly over-architected, but it's worth revisiting what we tell candidates to lead them in the direction of not trying to show off and to just write the code as they would normally.
> In my mind being able to over-engineer shows an ability to code
Huh, very mixed feelings here. My gut reaction is to reply that "it also shows poor judgement", but there is some truth to what you are saying. The middle ground would be where you can actually explain what you are trying to achieve with the over-engineered bits.
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.
Well, honestly it was curiosity. At the time I was teaching myself both C and Java, and I thought the coding test a good chance to apply both languages in a new context.
However, yes, the C code was more performant than its ruby counterpart - though within the context of the coding challenge it was fairly negligible.
Our dev team is even smaller than yours, and we also spend a lot of time getting to know developer candidates, of course. We've found it helpful to assign a programming project, but usually one that takes around 20-30 hours to complete. We like to pay them market rate for this work because we are busy with our work and personal lives and know they probably are too, plus we often try to give them a module we've been meaning to get started on, so we actually plan to incorporate their work into our codebase. It seems to be a very unique experience for developers applying to our company, and so far it's been very successful.
The problem with this question is that many people won't answer it honestly. A lot people just want to get, say, a better salary, but instead will answer stuff like "I want to solve difficult problems" etc.
It is nice to have interesting problems to solve, and I wouldn't discount that as I motivator. But while I might code in my spare time for free, I sure as heck don't want to trudge into an office and deal with a company for free. It is indeed too bad that people aren't upfront about how money motivates them, or if they feel that they can't do it, as if it is a taboo.
Would you discount someone who didn't write tests, but wrote the solution in a language that had a strong, static type system (like Haskell, OCaml, etc)?
This resonates a lot with some experiences I have had, and the reluctance to take a very small risk on whether someone with talent will be able to pick up a new technology is something I do feel a lot of companies are losing out from as a result. However at the same time I'm quite sure recruiting is a very hard thing to do, as there does seem to be a big shortage of both skills and talent in our industry. I suppose you have to always consider the context of what you are recruiting for. But personally if I was given the choice I would go for someone that clearly has talent and ability to learn, as long as there is some evidence available to show for it.
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.
Perhaps even going back to agriculture. You typically only get one growing season per year, which means it takes many years to see different variables you may encounter play out.
Age and maturity. Most people didn't even finish high school and started work at about 15. "5 years of experience" meant you were getting a 20-year-old-- likely, for a working-class male before 1960, to have settled down and gotten married, and to either have a child or be planning to have one.
If you are not hiring developers based solely on their portfolio of previous projects they authored. You are doing it wrong. Every prerequisite requirement for developers is inherently flawed.
1. A degree. While degrees are nice and prove somebody is considerably "intelligent" and not a "complete waste of time", many talented programmers, especially the ones you want to hire; are fully capable of teaching themselves without a lecturer.
There are some developers who have already studied the dragon book and have a sophisticated understanding of how operating systems work because they hack on Linux.
A developer may make a very reasonable and logical decision not to go to college because they dont want to accumulate debt, for an education they already possess, and ultimately waste time not working on their software projects.
A degree doesnt mean they are a good programmer, and a lack of one doesnt mean they are a bad one either.
Im not saying college is a bad investment, rather recruiters should not turn away an applicant just because he passed on that, as they see it, inherently flawed "life experience".
2. Years of experience.
Assuming the project is well documented...
If it takes a developer longer than 2 weeks to figure out how to use a project's api, even if they have no prior understanding of the technology.
They are not a good programmer.
If you are looking for a developer to actually understand the internals of a project well enough to be able to commit, even linux shouldnt take 5 years of studying before a talented developer is able to visualize whats going on.
Real developers spend almost all of their time reading code and studying something they havent learned yet.
if they cant adapt quickly to your projects, while perhaps even teaching themselves the new technology along the way unbeknownst to you. (new programming language, library dependency api's, network protocol, etc)
They are not a good programmer.
3. Previous Work Experience [as {insert stupid job title here}]:
First, there is nothing sillier than job titles for programming positions.
The only valid titles that should ever exist for a programmer's job are
Hacker,
Bit Composer,
Code Poet,
Git Wizard (seriously, this is the only valid specialized hacker position)
Second,
Just because Bob has 30 years of work experience as "Lead Programmer" at "FooBarly inc.", that doesnt mean he is a better engineer than 21 year old, no work experience, Alice.
While Dino Bob may be able to write optimized, neat, software. And although he might able to debug rather complicated bugs, and ultimately lead a team to write a program that does what its supposed to.
Alice may have been an exceptional, innovative, and disruptive programmer who could have not only written the software but innovated the concept into something beyond the scope of the original concept design.
There are some hackers out there who can see data structures and algorithms like a painter can see the scene painted on the canvas before they make the first stroke. Innovation requires an exceptional level of creativity and the ability to abstract an opaque idea into a deep, detailed conceptual model.
People cant be taught to think this way. Much like a professional musician, whom despite practicing each day for hours to perfect their art; will always lack the skill of a virtuoso mind like Mozart. Many people are great engineers, but could still lack in talent against someon who was just born with an exceptionally creative and brilliant analytic mind.
These are the kind of programmers that you cant afford to let your competition snatch up. Yet you just foolishly tossed Alice's resume in the trash because Grandpa Bob has credentials and she doesnt.
Interview Quiz:
When given questions like,
"given two arrays, find all the elements in one array that are also in the second array". in attempt to talent scout.
A good programmer will claim the real right answer is either the obviously simple choice or the theoretically most efficient, and well tested sort algorithm that can be found using google.
If comparing two arrays is seriously a performance bottleneck that requires optimization, you might as well skip the bs and go with the best. We arent solving problems if they no longer exist, and a programmer not solving problems is a programmer wasting time.
4. Portfolio
A portfolio is the only valid option to consider when you want to be absolutely sure you hire the best developers.
If the person hiring cant identify what good code is, then your startup is screwed anyways. You dont need a degree to build a portfolio, and if somebody does choose to college they get to build their portfolio as part of the class projects.
If a developer doesnt have a portfolio or if the software in their portfolio doesnt actually do anything useful then you know they arent a real hacker.
Hiring a programmer should only ever be based on the quality of software they have authored.
Like Linus said, "Talk is cheap, show me the code".
Often the majority of a programmer's portfolio is code that is intellectual property of former employers and they can't show it around. In fact, most times they're not supposed to have that code in their personal laptops.
Indeed. Some of my portfolio is from dead companies where I got permission from the rights holder, some is where I got permission to use a few foundational files that showed e.g. how I do things to improve error reporting and debugging but none of the company's secret sauce. But neither would have been possible without my having been in the field for a long time.
In my experience, companies are more interested in the code you wrote for fun as hobby than professionally anyway. As long as you have not been encumbered by a "all code you write is owned by us" clause for your entire life, there should still be lots to show.
Good idea but I think part of the point of the article is that the job will change. So to "Outline exactly what you need the developer to do, and have them send in proof that they can actually do it" is, again, to attract people with 'experience' that happens to fit that particular job description, rather than talent.
It's not that novel and it seems like there are quite a few companies that do something like this. The main problem with this approach is that you have probably screened out good software engineers that don't have a portfolio of public code they can share.
40+ years later, companies are in a similar situation, but instead, given a shortage of engineers, they are simply whining about it. Presumably, with tools that are 40+ years better that making it "easier" to program, such a system of the past would be reasonably replicable today, no? I've seen a few things pop up here and there - hungryacademy and such, but, by and large, this is the exception far more than the rule. Once upon a time, companies would hire and develop talent, investing years to develop the talent with years of rewards on the end for both sides of the deal. Now? Companies expect hires to come fully trained, ready to deliver from day one, at their own expense (and much debt to the banks). Employees have no loyalty (and for good reason).