13 ms·

Hire talent, not five years with Java

156 points by bleakcabal 14y ago

bobwaycott 14y ago
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. [1]: https://news.ycombinator.com/item?id=5441337 https://news.ycombinator.com/item?id=5441337 [edit: forgot link & punctuation error]
- Ovid 14y ago
  > 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)
  - mailshanx 14y ago
    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:)
    - Ovid 14y ago
      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).
- 14y ago
taude 14y ago
Phone interview with company developing Flex or Silverlight widgets?
- bleakcabal 14y ago
  Yeah Silverlight :)
yuhong 14y ago
I think "years of experience" dates back to the era of widget factories where it actually made sense.
- trhtrsh 14y ago
  Why did it make sense then?
  - michaelochurch 14y ago
    Why did it make sense then? 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.
    - jeremysmyth 14y ago
      In the days of guilded craftsmen, apprentices weren't allowed marry.
- jeremysmyth 14y ago
  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.
hkmurakami 14y ago
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." http://firstround.com/article/How-Stripe-built-one-of-Silicon-Valleys-best-engineering-teams http://firstround.com/article/How-Stripe-built-one-of-Silico...
- yuhong 14y ago
  Yea, michaelochurch have talked about open allocation before.
- cliftonmckinney 14y ago
  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. :-/
jared314 14y ago
This is similar to Joel Spolsky's Smart and Gets Things Done [0], but less comprehensive. [0] http://www.joelonsoftware.com/items/2007/06/05.html http://www.joelonsoftware.com/items/2007/06/05.html
prophetjohn 14y ago
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.
GoranM 14y ago
Here's a relatively novel idea (I guess): Outline exactly what you need the developer to do, and have them send in proof that they can actually do it. Previous projects, personal github experiments ... Most capable programmers will have something interesting to show. Right?
- blacktiger 14y ago
  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.
- namenotrequired 14y ago
  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.
readme 14y ago
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.
- b0rsuk 14y ago
  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.
  - nahname 14y ago
    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.
  - readme 14y ago
    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)
    - lccarrasco 14y ago
      http://en.wikipedia.org/wiki/Srinivasa_Ramanujan http://en.wikipedia.org/wiki/Srinivasa_Ramanujan > 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.
arocks 14y ago
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.
justin_vanw 14y ago
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.
- jbelanich 14y ago
  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.
b0rsuk 14y ago
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.
- eru 14y ago
  Where do you live and where did you look for jobs?
  - b0rsuk 14y ago
    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.
    - eru 14y ago
      I guess your best bet would have been moving to London or Cambridge (or perhaps Munich or so). A Polish co-worker from my former job in Cambridge went back to Poland, and now `tele-commutes' to Cambridge. He's doing Haskell.
- tomjen3 14y ago
  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.
  - March_Hare 14y ago
ruswick 14y ago
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.
jowiar 14y ago
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).
- wfunction 14y ago
  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.
  - Vlaix 14y ago
    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).
  - InclinedPlane 14y ago
    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.
happywolf 14y ago
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!
- drewcoo 14y ago
  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.
  - hga 14y ago
    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).
RandallBrown 14y ago
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.
warrenmar 14y ago
There's also the case of asking for N years of experience where the technology has been around for N-1 years.
jasey 14y ago
This 100%. 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-
- nollidge 14y ago
  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.
hfsktr 14y ago
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.
- russell 14y ago
  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.
  - hfsktr 14y ago
    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.
planetjones 14y ago
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.
fecak 14y ago
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.
ses 14y ago
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.
mortdeus 14y ago
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".
tokenadult 14y ago
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, https://news.ycombinator.com/item?id=5227923 https://news.ycombinator.com/item?id=5227923 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." http://geb.uni-giessen.de/geb/volltexte/2012/8532/pdf/preprint_j.1468_2389.2010.00485.x.pdf http://geb.uni-giessen.de/geb/volltexte/2012/8532/pdf/prepri...

156 points by bleakcabal 14y ago

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. [1]: https://news.ycombinator.com/item?id=5441337 https://news.ycombinator.com/item?id=5441337 [edit: forgot link & punctuation error]

Ovid 14y ago
> 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)
- mailshanx 14y ago
  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:)
  - Ovid 14y ago
    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).
14y ago

taude 14y ago

Phone interview with company developing Flex or Silverlight widgets?

bleakcabal 14y ago
Yeah Silverlight :)

yuhong 14y ago

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

trhtrsh 14y ago
Why did it make sense then?
- michaelochurch 14y ago
  Why did it make sense then? 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.
  - jeremysmyth 14y ago
    In the days of guilded craftsmen, apprentices weren't allowed marry.
jeremysmyth 14y ago
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.

hkmurakami 14y ago

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." http://firstround.com/article/How-Stripe-built-one-of-Silicon-Valleys-best-engineering-teams http://firstround.com/article/How-Stripe-built-one-of-Silico...

yuhong 14y ago
Yea, michaelochurch have talked about open allocation before.
cliftonmckinney 14y ago
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. :-/

jared314 14y ago

This is similar to Joel Spolsky's Smart and Gets Things Done [0], but less comprehensive. [0] http://www.joelonsoftware.com/items/2007/06/05.html http://www.joelonsoftware.com/items/2007/06/05.html

prophetjohn 14y ago

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.

GoranM 14y ago

Here's a relatively novel idea (I guess): Outline exactly what you need the developer to do, and have them send in proof that they can actually do it. Previous projects, personal github experiments ... Most capable programmers will have something interesting to show. Right?

blacktiger 14y ago
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.
namenotrequired 14y ago
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.

readme 14y ago

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.

b0rsuk 14y ago
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.
- nahname 14y ago
  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.
- readme 14y ago
  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)
  - lccarrasco 14y ago
    http://en.wikipedia.org/wiki/Srinivasa_Ramanujan http://en.wikipedia.org/wiki/Srinivasa_Ramanujan > 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.

arocks 14y ago

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.

justin_vanw 14y ago

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.

jbelanich 14y ago
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.

b0rsuk 14y ago

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.

eru 14y ago
Where do you live and where did you look for jobs?
- b0rsuk 14y ago
  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.
  - eru 14y ago
    I guess your best bet would have been moving to London or Cambridge (or perhaps Munich or so). A Polish co-worker from my former job in Cambridge went back to Poland, and now `tele-commutes' to Cambridge. He's doing Haskell.
tomjen3 14y ago
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.
- March_Hare 14y ago

ruswick 14y ago

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.

jowiar 14y ago

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).

wfunction 14y ago
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.
- Vlaix 14y ago
  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).
- InclinedPlane 14y ago
  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.

happywolf 14y ago

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!

drewcoo 14y ago
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.
- hga 14y ago
  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).

RandallBrown 14y ago

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.

warrenmar 14y ago

There's also the case of asking for N years of experience where the technology has been around for N-1 years.

jasey 14y ago

This 100%. 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-

nollidge 14y ago
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.

hfsktr 14y ago

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.

russell 14y ago
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.
- hfsktr 14y ago
  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.

planetjones 14y ago

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.

fecak 14y ago

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.

ses 14y ago

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.

mortdeus 14y ago

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".

tokenadult 14y ago

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, https://news.ycombinator.com/item?id=5227923 https://news.ycombinator.com/item?id=5227923 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." http://geb.uni-giessen.de/geb/volltexte/2012/8532/pdf/preprint_j.1468_2389.2010.00485.x.pdf http://geb.uni-giessen.de/geb/volltexte/2012/8532/pdf/prepri...