17 ms·

Hiring Is Broken?

• nafeydev 7y ago
  Whats the general consensus on take home projects? How helpful are they?
  • shados 7y ago
    Anecdotal survey in my city's community across a couple of companies say 30-50% of people never turn them back in, so while its a powerful tool that gets rid of a lot of issues with typical screens, it introduces friction a lot of people don't want to deal with. They'd be more useful in a buyer's market.
    • jethro_tell 7y ago
      Also, I can set aside an hour or two during the day to chat with you. If you ask me to spend hours implementing something on my own time, I will assume you also ask your employees to do that and will completely blow that off. What you'll end up with is people who are desperate for your job, which may or may not be a great sign.
  • sys_64738 7y ago
    I'd bill the company asking for them a minimum of eight hours at contracting rates. My time isn't free.
  • gravypod 7y ago
    I haven't been able to find a better screening method than take home projects. A major issue that I find when watching hiring take place is people don't separate learnable/domain specific skills from the "inherent" skills you need as an engineer. Hiring someone who has a 10 year track record as a software engineer in systems software for a web-stack backend role should be an easy "Yes" if they are a skilled software engineer. Because of this I usually encourage people to make take home problems that are limited in scope and follow the restrictions: - Should not take longer than 3 hours for an inexperienced developer. - No learnable skills tested like tooling, language, and domain experience. - Simple to understand problem - Problem should be obviously mappable to a solution - Provide sample input and sample output data (only 1 case). I then score using the following questions - Did the code work on the sample I provided? - Were edge cases in the spec accounted for? - Has the engineer followed a language standard (PEP/PSR)? - Were docs (install, compile, comments) provided? - Were unit tests provided? - Were sample cases the engineer ran manually provided? - Was the code "elegant"? Could another engineer at the company look at the code and maintain it in a year. I think the actual project should have low bearing on completion and the state and cleanliness of the code has a higher mapping to quality.
    • hysan 7y ago
      Would you be able to give an example of how limited in scope you're talking about? Is it just a single "write a method that does this" type problem? I ask because I did a take home very recently which I know I could knock out quickly, but it took much long because everything you listed ballooned the amount of time it took me to complete it. Specifically: - Has the engineer followed a language standard (PEP/PSR)? For JavaScript, it takes some time to setup a new project from scratch with linting and formatting configurations. Then documenting it in your README. - Were unit tests provided? - Were sample cases the engineer ran manually provided? Once you go beyond a few "features" to write, this balloons in time due to both writing it with good descriptions and documenting it for the reviewer. - Was the code "elegant"? Could another engineer at the company look at the code and maintain it in a year. If what you ask is of sufficient complexity, it would just be normal to take time to think about what the interviewer is expecting here. Like what future features could there be? How might this be used in a larger codebase? etc. Then once you've decided on this, you'll want to spend time commenting and/or writing up an explanation in your README about your design choices. Lastly, this isn't mentioned but I did this on the take home I recently completed - using version control and properly branching & merging on each deliverable. Doesn't take time, but if you are making atomic commits with good comments, that's just another way for you to lose time. Of course, I don't think the fact that I did this is going to be noticed as it wasn't written out as a requirement. If you notice what I'm nitpicking, it's all the setup and writing that becomes a time sink for most. In isolation, it wouldn't break the bank, but with all those requirements combined, you've lost much more than 3 hrs. When I'm given take homes for interviews, this is where I've burnt the most time - taking the time to document well.
      • mburger 7y ago
        What about having a discussion on how the candidate would solve a given take home? You could check if she would think of the required parts. For instance, would she think of unit tests? If she wouldn’t mention tests, you could ask „How would you ensure that your program works as expected?“ Thus, solving the take home theoretically.
        • 7y ago
  • scruffyherder 7y ago
    If you like to roleplay as a tenured professor, sure it's great. Otherwise it's a total waste of everyone's time. Extra points if you have a tweed vest and a smoking pipe.
  • n_ary 7y ago
    Take home has two sides to it. Group A: People who excel at face to face interviews(extroverted) will complain that it is waste of time and disrespectful, because it demands significant time commitment compared to a 1 hour in-person interview. Group B: People with interview anxiety(introverted) will excel at this type of test because they have the freedom to set aside their own time, do things at their own pace and environment. However, people from Group-A has a point, because certain take-home assingment are notoriously complex and will take multiple days of effort if you want to meet all requirements, which are not an option for people with family & existing job.
    • djhworld 7y ago
      > significant time commitment compared to a 1 hour in-person interview. I don't think I've ever been in a software engineer interview where the face to face portion is less than 3 hours (at minimum!)
      • lubesGordi 7y ago
        I think they're talking about the initial 'phone screen' portion of the interview.
    • AnimalMuppet 7y ago
      I don't know that I'm extroverted. I'm still in group A, though, because I don't have interview anxiety. My problem with take home stuff is that it's asymmetrical. That is, if we're doing a phone interview, it takes my time, and it takes your time. Ditto an in-person interview. You're serious enough to commit some of your time to it, so I'm willing to also do so. I know you're looking at other candidates, but if you call me in for an in-person interview, I figure I've got at least a 30% chance of landing the job. That's enough for me to be willing to invest the time. But with a take-home assignment, it costs me much more time than it costs you. So you could be giving it out to tons of people. How many? I have no way of knowing. So you're asking me for 6 hours (which may turn into 12), but what are my odds on getting the job? Are they still 30%? Or are they now 1%, because you just gave this assignment to 100 people? I'm not going to plow 12 hours of my time into a 1% chance at a job. Just no. And the problem is, if you tell me "oh, we're only looking at a couple of people", I have no reason to believe you. But if you're actually interviewing me, I believe you, because it's too expensive for you to interview 100 people to hire only one.
  • mjfisher 7y ago
    Really helpful, as long as they're done well and respect the candidate as much as possible. In my experience, they provide a great way of understanding a candidate's skills. It also lets them work in a low-pressure environment with their own tools, which tends to let people achieve their best. I actually recently launched a service to help make managing take home tests through git more efficient: https://candidatecode.com https://candidatecode.com It's still early stage, so any feedback is appreciated
• esotericn 7y ago
  This article appears to be an extremely long-winded way of stating that you don't have to pick from the top-end. Which is true. Companies know this. Most of the stuff I read here is basically made up of people who aren't quite the best moaning that they couldn't get a job at Google or whatever. Life goes on. It is impractical and not a good thing for every software developer, even the very good ones, to pile into the same companies. Not everything is set up as a perfect procedure for you. And even if it was - OK, so you get the job and the Stanford grad doesn't. You swap places. Does that make a better world? I encourage new developers reading these sort of posts to just ignore the fluff and plug on. You'll get there. And if not? In five years you might want something else entirely. I wanted desperately to work at an investment bank as a new grad. I'm very happy with the path my life has taken instead.
  • o10449366 7y ago
    Could the system be better? Yes. But there's also a ridiculous amount of entitlement in the tech industry. There are very few other industries where someone with a bachelors degree or no college degree at all can obtain a low to mid six figure job with no prior work experience + benefits. Even for the average experienced hire, who's compensation can easily exceed that of the average doctor, it isn't like things get worse as your career progresses. Many of these "hiring is broken in tech" posts are like you said: moaning or a remarkable lack of self-awareness.
    • esotericn 7y ago
      I don't think of it as entitlement so much as a refusal to see the world as it is. There are a trillion arbitrary signals that will help or hinder your success in various ways. Physical attractiveness, gender, race, parental background, your nationality, where you can work, your accent, language... the list is honestly almost endless. You can wish for a world in which none of this were true, or do your best to find a place within it. Sure, don't lose sight of justice, but recognise that you can't change the world alone.
      • Apocryphon 7y ago
• otras 7y ago
  One thing I’d add is that live coding exercises can vary widely in quality. > If you solve the problem, you’re scored highly. If you don’t, you’re scored poorly. In my own opinion, this is a terrible way to look at these problems, though many people do use this metric. This is further emphasized by HackerRank-style exercises where you have to pass all test cases. This is robotic and not empathic at all. A more fluid and dynamic approach that focuses on the candidate’s approach, ability to clarify, and problem solving, even if the correct answer isn’t reached, can still give valuable signals Disclaimer: I work and give interviews at a large tech co that uses exercises.
  • watwut 7y ago
    What is wrong approach and is good approach? I agree that ability to explain and clarify matter in many positions and are real thing. But I never understood what is meant by "approach".
  • jcims 7y ago
    I wonder if there is any value in having a few candidates do a group project. Would probably be a mess but might be informative, you could at least identify the bullies and dickheads pretty quickly.
    • kvonhorn 7y ago
      I could imagine that this would be the worst way to evaluate candidates I've ever heard, especially if not everyone got hired. I think this would only be an appropriate evaluation metric if your end product were actually a reality TV show focusing on this process. Maybe do it Survivor style, have 12 candidates/new grads start, give them the goal of producing an MVP CRUD app, and start voting people out of the scrum after a couple of days. Winner gets a 6 month contract to hire, 3 people have their careers ruined, and the rest bump around the valley for a few years before moving back to wherever the hell they came from. The memes that come out of this alone could make this show a valuable cultural contribution.
      • jcims 7y ago
• bentona 7y ago
  I wonder if people describing hiring as "broken" have only experienced the process from one side. Hiring is a one of my favorite things to work on at my software engineering jobs, because it's a super-hard problem that is always available. It hasn't been "solved" and lots of people do it in ways that are obviously sub-optimal, but I don't think anyone knows how to do it optimally. I think this is what TFA is getting at.
  • projektir 7y ago
    Being on the other side of the process has only convinced me more of how broken it is. There are lots of baseline errors, biases, and insufficient attention given to the process that are quite obvious but a lot of people either fail to see them or refuse to see them because they don't want to admit that their hiring process is not better than rolling dice. As a basic example, in a lot of places you get very little advance warning that you're going to interview someone. Test problems or assignments are often not tested or even looked at by existing employees, so often you don't even know that your current team would do well on them. Sometimes interviews happen without any intention at all to hire the candidate (wtf).
• drchewbacca 7y ago
  Another related question is how would you evaluate the quality of hires? So you hire for a team of 5 people who complete 83% of the tasks you set for them that year. How do you know if you hired well? Is this an excellent result or a terrible one? How do you know how well each of those 5 did and how well the team would have done with other people in the roles?
  • okaram 7y ago
    What makes this even worse is that you have no info on false negatives ... How would the people you didn't hire would have done?
• PaulHoule 7y ago
  Wasn't that headline written by content marketers working for triplebyte? It is popular for medium articles and if you use it on the programming section of Reddit you will get downvoted into oblivion.
• ddebernardy 7y ago
  The biggest issue isn't one mentioned in the article. No amount of hiring tricks and hacks will work around the fact that hardly anyone (including most managers and HR pros) gets trained on how to review a resume, conduct an interview, and evaluate a candidate.
  • humanrebar 7y ago
    That presumes there is teachable wisdom and technique in that domain.
  • codingdave 7y ago
    This does not ring true based on my experience. Where have you worked where you found this to be the case?
    • ddebernardy 7y ago
      Maybe you got luckier in your career than I have been or you've only ever worked for very large businesses. Once you've learned the types of questions that tend to work better you immediately notice when whoever is interviewing you isn't asking them. Interviewers who mostly ask these types of questions and go on to dig deep enough to understand your contributions and the rational behind them are few and far in between.
    • tidepod12 7y ago
      I worked at one of the largest global consulting companies (and I have enough friends in the other major consulting companies to know it's the same in most of them). I was a relatively junior person working there in my early-to-mid 20s. It was common practice for me and my peers to be asked to review resumes and filter them, as well as be an interviewer every few months. I never once received any kind of training on interviewing or resume review. Not even the 10-minute-cheesy-corporate-video kind of training. Hell, not even a quick 1-pager or chat on tips or things to look for. It was literally just "hey here's a stack of resumes, please filter them".
  • neogodless 7y ago
    I've never been trained on how to write, test or debug code. But I've gotten pretty good at it - you can self-train and learn from experience. Of course, the difference is that the feedback loop is at least two to three orders of magnitude faster for writing code than for figuring out if you did a good job hiring.
• maxyazhbin 7y ago
  awesome, right on!!!
• deleted 7y ago
  [deleted]
• graycat 7y ago
  It's easy for a person in good health, never arrested, never bankrupt, good credit score, native born US citizen, world class Ph.D. with one of the very best backgrounds for analytics and machine learning, with peer-reviewed publications in applied math, mathematical statistics, and artificial intelligence, having recently written .NET code in 100,000 lines of typing for an ambitious Web site, code that appears to run as intended and be ready for production, and who has shipped very high quality code to high end customers to be 100% completely, utterly, totally, permanently unemployable for anything beyond minimum wage, literally. That's just the way it is.
  • strikelaserclaw 7y ago
    and you've met such a person?
    • lubesGordi 7y ago
      If they're 50+ and live in rural America, yeah good luck.
      • opportune 7y ago
        Good luck finding a job creating artisanal fruit preserves at a research station in Antarctica
  • GoToRO 7y ago
    The simple truth is companies value loyalty above all else. If you are the best or not doesn't really matter. It matters that you can pass some simple tests but nothing else. In the gig economy it's important to be able to show to your client how the final product looks like. I.e. a portfolio. They have money just for one run, one try. Risk aversion is high. Companies that truly want the best and have a process to filter for the best are exceptions. Maybe less than one in a thousand.
  • m0zg 7y ago
    Yep, it's easy. All you have to do is stop applying for jobs. Although .NET and machine learning typically don't go hand in hand, as does ML and "ambitious web site" experience. I'd have someone review your resume and make sure you're not trying to be all things to all people. That's a major red flag.
• eternal_intern 7y ago
  Why not list the pros/cons of each method and let the candidates choose their poison. Whichever metric they think they would be best at given their constraints. Still requires work and a subjective estimation of candidate skill because you have to make a judgment across metrics instead of within one, but I mean, everybody wins in this case, right?
  • borramakot 7y ago
    I like the idea of multiple tracks a lot, but I think you need to be hiring at sufficient scale that each track has a fairly high rate of interviews, which makes it hard to support tracks that aren't commonly chosen. If you don't had that scale, uncommon tracks will be full of interviewers who are out of practice for your question, and poorly calibrated to evaluate the candidate. Also, some companies might not want to allow any of these methods, since they each have their own tradeoffs/blind spots.
• alexandercrohde 7y ago
  For those of you not reading this article (appears to be most) - this is a META article: 1. Main thrust is that all the HN posts on this topic are stupid and formulaic 2. Argues that numerous the OTHER posts merely list the negatives for one method of interviewing A, and the positives for another method B. 3. Lists every method of interviewing, showing glaring problems and advantages in each of them. Obviating the need for the discussion ever happening again. 4. Asks for something akin to evidence if we are going to drive the discussion forward.
  • necovek 7y ago
    I've read it, and while it starts with a request for a double-blind study, it immediatelly moves on to listing a subset of interviewing techniques. It is by no means exhaustive. If the focus was to be on evidence, it would provide a framework for such a study. It generally sounds pretty hard to do anything of the sort.
    • alexandercrohde 7y ago
      >> I've read it, and while it starts with a request for a double-blind study, it immediately moves on to listing a subset of interviewing techniques. Uh, what? It start by saying "I can’t keep track of the number of articles I’ve read about hiring in the past few years. Inevitably, they all follow the exact same format" That point is true. The question then becomes "Why does the community generate spammy articles without making any sincere attempt at intellectual progress toward a better system?" And the answer is probably that it's not in any individual's self-interest. HN members want to whine about not getting hired by google, companies want to promote themselves, people like me want validation. The only people who have any incentive/interest in objective hiring are companies that specialize in that purpose (e.g. hired, interviewing.io). But there's really no reason for them to divulge their secret sauce, and even if they did, people would probably only upvote it if it let them feel less insecure about getting rejected by google.
• oneepic 7y ago
  This debate will keep happening for years to come, but everyone's just repeating the same talking points over and over. I have to sum up my thoughts like this: I really don't think we're ever going to find a perfect hiring method. You will always have a nonzero chance of false positives and false negatives, and there will always be downsides that piss people off. So, pick a reliable hiring method(s) (talk about experience, solve whiteboard q's, do take-home projects, or whatever) and try to make it better over time. If you don't like it, you can switch to another method and start improving on that. Etc. But your method will always fail some good hires and pass some bad ones. It sucks, but we are still able to hire mostly good/trainable people, so we should stop worrying and move on. I hypothesize that there are a lot more interviewees than interviewers getting involved in the debate. I only have to tell the former group to keep trying and stop complaining. If you're not sure why you're failing interviews, that's a solved problem -- just do mock interviews with your friends or on interviewing.io. But stop blaming the process for your own failures.
  • deleted 7y ago
    [deleted]
  • ChuckNorris89 7y ago
    > but we are still able to hire mostly good/trainable people Wow, you're actually training people? Kudos to you, I haven't seen that in a looong time. In my current area, everyone only looks for seniors or experienced devs. New grads without connections can suck it basically.
    • oneepic 7y ago
      At this point my team mostly hires juniors. We train them on whatever they don't know that they need to know here. We hired a mostly self-taught engineer out of college a year ago (I started ~2mos ago). Had almost no idea about webdev, or C#/.Net, or web APIs, but we taught her on the job. I'm similar, since I had no experience with web APIs before joining but I had experience with C#.Net, Asp, etc.
  • AJ007 7y ago
    We will see the debate go on as long as humans are working. The problem is hiring is reflexive. Hiring is a marketplace, not a static measurement. Human behavior changes in reaction to other human behavior. If someone found a foolproof method of hiring once it become widely known, it would no longer foolproof. Either employers would all try to hire the same employees or employees would find out which signals mattered and tried to game them. This already occurs to some extent with the Ivy League hiring approach. The general “college degree” part has already been over-gamed to the extent it is meaningless. What employers should be doing is measuring the long term success and failures from interviews and seeing if the interviewer even has an above random chance of selecting good employees. If it’s worse than random than the interviewer is probably just terrible at what they are doing. This would also require the employer to agree on what makes a long term successful employee, something I’m not sure many people even agree on. At minimum, I’m presuming you couldn’t make a judgement on a hire in less than 5 years.
• GoToRO 7y ago
  Well, none of the above. Anytime you try to gauge someone by counting, it's not going to work well. You need the best developer at your company, to do the hiring. Filtered by HR for personality and so on.
  • gridlockd 7y ago
    Your "best developer" probably doesn't want someone better than them on the job.
    • neogodless 7y ago
      I consider myself an above average developer. In the right situation, I'd even strongly suggest that I can be a 10x developer. But there are so many things I either don't know or could massively improve upon. I joined a team where I feel like the majority of developers around me are at least as good as me or better, maybe much better. I LOVE IT!
    • dymk 7y ago
      What a weirdly insulting straw man of a developer you set up. Many engineers including myself would be thrilled to have somebody else highly skilled around, and "selfish/vain" isn't the default in our industry.
      • gridlockd 7y ago
        > Many engineers including myself would be thrilled to have somebody else highly skilled around, and "selfish/vain" isn't the default in our industry. What else are you supposed to say about yourself or anyone else? I'm not talking about the best developers in general, I'm talking about "the best developer in the team". The "golden child". Do you sincerely believe they're thrilled about giving up that special status to the new hire? Yes, people are that petty, they're not necessarily that self-aware though.
        • dymk 7y ago
          You can construct any number of hypothetical evils that might plague your team; I don't really see why you'd let that shape your perception of engineers when you hardly ever run across people like that though. Most people are fine, and if you run into a toxicity then go take care of it like an adult and talk to your manager/HR/whatever.
• deleted 7y ago
  [deleted]
• ebiester 7y ago
  This goes back to the idea that there is a "fungible" programmer that is universally substitutable between companies. In some companies, I am a highly valuable addition. In others, I am mediocre at best. I think of this like a sports team - a highly performing sports team both needs people of the highest skill and complementary role players that are the best at a valuable skill even if they aren't the best at every skill. It would be great if every team member was excellent at code craft, debugging, collaborating between teams, researching new third party solutions, and whipping up prototypes, but your team may not need all of those. I don't like the term "culture fit" because it is a proxy for people who are already on the team, and often gets confused for "white, male, and likes to drink with coworkers." That said, I highly value "work style fit" and "team need." Are you running into code quality problems? Find someone who thinks about code quality. Do you need someone who can get a prototype to sales quickly to close a deal? That's a skill, and it's not a generalized skill. All of the cases above can be valuable, but only contextually. Figure out what your team needs first, then craft your interview process around that. (As for me? I have been in management for a while, but I am at my best in developing high functioning teams, collaborating between teams to solve larger problems, and crafting high quality solutions. I am not at my best in deep debugging sessions and quick prototyping. If it isn't my own startup, I might not be the ideal choice for employee 1-5. I may be the person you bring in when your team is expanding rapidly and you're running into scaling issues.)
  • streetcat1 7y ago
    So if you are not good at coding/recent tech, how do you know if a given solution is high quality or not?
    • ebiester 7y ago
      I am good at coding. I am a good enough debugger to get through most cases. I am good enough at getting a prototype out. However, if you are looking for someone to sort out some deep and ugly multithreading issues, there are people who are better at it than me. If you are running an agency trying to drum up work, there are people better than me. If you have a codebase with no tests and everyone is afraid to touch it, you want me. If you have three teams that are trying to sort out a problem but nobody will dig in, talk with everyone, and sort out the technical issue, you want me. That’s the difference. Now, as for determining high quality code without having that basis, I would start with Robert Martin’s book “clean code.” At the very least, it can teach the basics of understanding a code sample. However, it can be a difficult problem. I might think about a consultant to judge those and use behavioral interviews to judge the rest.
• track_me_now 7y ago
  What about focus on direct referrals who have worked with a current employee? The highest signaling characteristic I've ever found is someone who was recommended by a former coworker; there's a transitive relationship that seems to capture both the technical skills and a comfortable fit. I realize this doesn't scale to the rapid growth of some companies, but most of us need a more modest supply of talent vs. giant pools of people.
• CalChris 7y ago
  The article has a lot of good advice. However, hiring doesn't end with the offer letter. There's also on-boarding which is largely left to the manager and varies considerably. Perhaps the writer could do a sequel on on-boarding.
• dahart 7y ago
  > Anyone can glamorize and exaggerate the work they have done, and make it sound a lot more impressive than it actually was My personal experience interviewing is that people cannot easily glamorize their past projects when pressed for details. It might be easy to make it look good on a resume, but hard in person during a discussion with follow up questions. I think asking about past projects is a fantastic interview question, and it’s very easy to get a good sense of what they did, what they were trying to do, how much was their leadership versus others, how successful it was, how much effort it took. All you have to do is ask questions about it, and not take the resume item at face value. Personally, I find the open ended nature of the past projects question to be a better predictor of future performance than almost everything else on that list.
  • username90 7y ago
    Or they could just lie and tell you from the perspective of another dev on their team, or even combining the achievements from several of them at once. Of course most people wont lie a lot but this style heavily favors those who do so you will get a disproportionate amount of liars on your team.
    • dahart 7y ago
      I think your assumption is incorrect, based on my own experience. I’ve never hired a liar, and I’ve hired a lot of people. I have, however, declined to hire people who failed to answer follow up questions honestly or appeared to not be able to explain their success. Anyone who wants a job knows it’s a bad idea to lie because you find out immediately once you hire someone whether they are lying, and it would be grounds for immediate firing. Also follow-up questions weed out lies & half-truths very quickly. You should try it, see how long you can answer probing questions about someone else’s experience. I agree that most people won’t lie, and what does happen is almost always not lying but just spin, trying to glamorize rather than outright fabricate. My experience is that people get honest about their glamorizing very quickly if I keep asking more questions.
      • username90 7y ago
• coding123 7y ago
  At one (large) company I worked at we hired the guy that basically invented one of the technologies at Sun behind one of the larger JSRs - like an entire standard API for one of the Java EE products (not going to say which) for an architect role. I have no idea why we hired him. He basically sat idle all the time asking what he was supposed to do. He randomly would make charts and show people. He was older, out of touch with most of the team, and just kinda present at every meeting with no specific task or role. He had advice here and there that most of the people at the table were already thinking through. I left before I found out what happened to him. Nice guy though. Hiring might be broken for keeping out the best of the best, but as long as you work at a company that isn't afraid of firing/laying off, hiring isn't fully broken.
  • eropple 7y ago
    > as long as you work at a company that isn't afraid of firing/laying off, hiring isn't fully broken. Yes, it is--it is just broken in a way that privileges the company over its employees. Firing somebody (absent flagrant abuse and the like) is a failure of management and leadership.
• adamredwoods 7y ago
  I'm actively interviewing. I don't think hiring is broken, but I think some companies get lazy or even abuse it. If we get the abuses down, and require less of a time commitment (no 8 hour take-homes), I think there'd be less complaints. The key takeaway is that rejection hurts emotionally. Programmers who care about coding, take the rejection personally. Less time commitment, less hurt.
• jimbob45 7y ago
  While hiring is broken, let's certainly not pretend it was in a workable state in the past. Let's further appreciate things we have now that we didn't in the past. Previously, if you wanted a job in another state, you'd have to move there and hope you got a job before your bank account ran dry. Now, you can safely apply for jobs while at your current job until you get something.
• cbanek 7y ago
  While hiring is inefficient and biased (some would say broken, which I won't disagree with), I think performance reviews are equally so. Companies don't really know how to evaluate performance well, and without bias. Many of these same problems exist in performance reviews: > Ask them for references, Do back-channel references Asking people for feedback, peer review, 360 review, etc. This is somewhat effective, but if people can choose their own reviewers, they will of course get only the good info, same as for interviews. If anyone can submit feedback, you're likely to get people who don't like an employee to write stuff about how terrible that employee is, which might be exaggerated. > Take home projects, Audition for the role as a contractor, Ask them to describe their past projects, Ask for source code from significant projects, Pair programming on a “real” problem, Live Coding Exercises All of these are meant to try to get real signal on how the person would perform their job. But even when people are employed on a team and you can observe them at any time, it's hard to quantify their performance. Do you look at their commit count? Bug count? Lines of code? Any metric has its weakness, and people game them. Interviewing is a game of making a decision with incomplete information. I would say we aren't much better having a whole lot more information about how someone works, when trying to give an accurate performance review. If we can't accurately judge performance of the people we should know, I think that proves we can't accurately judge performance of people we don't know.
• clairity 7y ago
  hiring is really simple: you can straightforwardly filter out the obvious no's, but beyond that, it's a crapshoot. basketball analogy time! (my favorite =) the NBA employs 450 of the best basketball players on the planet, and at any given time, the league is evaluating a few thousand more (out of hundreds of millions of basketball players, out of ~7.5 billion people worldwide). all the easy filtering is done. every year, the 60 most promising players are drafted. and because they're among the most promising, most of these 60 players should become regular NBA players. in practice, only 5-10 will do so in any given year, and you have no idea which ones it will be as they all look promising (e.g., laker kyle kuzma drafted 27th in 2017). in short, once you get down to the 10-20 candidates you think will fit a given job, you might as well just draw a name out of a hat, work with them for 3-6 months, and re-evaluate. there really is no shortcut to this (not even for google).
  • smsm42 7y ago
    Fortunately, for smaller companies there's another option - use personal networks to find candidates, the chances would be much better. For googles, they can just afford some misses, it costs but not something they couldn't stomach.
    • clairity 7y ago
      yes, that can improve the odds, but i've hired people through my network (as a founder and an employee), and good hires (those who add productivity & efficiency to the team) still often boils down to the idiosyncracies of the individual human relationships involved. going back to basketball, no team has yet to sign 10x nba all-star carmelo anthony this year, and 8x all-star dwight howard only just signed with the lakers (on an unguaranteed minimum contract) because of a season-ending injury to demarcus cousins. both players are individually very talented, but are reputed to be hard to play with (thus lowering team productivity & efficiency).
  • dredmorbius 7y ago
    Pro sports is an interesting comparison, in that it has a very long-chain training and recruiting system, starting as young as age 5-10, and including sport leagues and/or school teams to refine talent. Though professional recruiters may not be looking at younger players, sports leagues and schools are quite conscious of talent. Professional lifetimes are also frequently quite short. For gymnasts, competing life is virtually over by age of majority, for Americna football, a few years in pros is typical, though some careers last longer. Baseball, cricket, tennis, and golf are longer-lived exceptions. I'm not saying this as a rabid sport ethusiast, and the transfers to technical recruiting may be limited, but it's at least an interesting system to consider. Other uneven talent/fame domains are theatrical performance (acting, music), and, possibly, writing.
• hackbinary 7y ago
  Probably. Everything else seems to broken as well, housing, education, healthcare, justice, and politics. So it seems perfectly rational to think that hiring is broken as well.
• tylerFowler 7y ago
  As most of those bullets point out, nearly all of these are good indicators for some people and bad for others based on what kind of person they are or what their environment might be. It seems like the ideal would be to allow candidates to choose what format they think would best showcase how they work? Choose-your-own-adventure style? Assuming you had some way of making comparisons across these different formats (easier said than done, I'm sure) it seems like you would end up with "truer" signals. It also seems like you would get an extra signal based on what the interviewee chooses. For example someone who prefers live coding/pair programming sessions might be someone who leans on and thrives more in ultra-collaborative/brainstorm-ish settings. Whereas someone who prefers take home assignments maybe is more productive being able to sit on a problem and iterate, then collaborating after being able to articulate the specifics in a code review type setting. Neither are wrong, nor are they mutually exclusive within an organization but in terms of team placement or general "culture fit" (whatever that means) it seems like something that's useful to know ahead of time. Of course you might also allow people to choose which route they think they can hack more but I think that problem is more of an implementation detail of any given method. Asking for a solution to find the perimeter of a group of pixels at a video streaming company is better than asking someone to invert a binary tree at virtually any company. Asking someone to build something real-ish with a hundred valid solutions is better than asking someone to implement a trie with a thin search interface on top. And so on.
• bartread 7y ago
  I thought I was going to be completely infuriated by this as I've seen just far too many articles about hiring recently. However, it's worth a read because it does a good job of summarising the trade-offs inherent in most of the techniques I've seen used to hire engineers. I might have missed it, but it didn't talk about any kind of software design assessment, which I have used and seen used reasonably successfully. There was, however, one observation that ticked me off under cons in the "Live Coding Exercises" section: > Very stressful. Many programmers can’t handle the stress of coding under the clock, with someone watching them If this is you I'm going to give you some advice that, if you can swallow it, will prove very helpful... Grow up. Seriously: grow up. You are (or will be) highly paid, and are supposedly a professional. So learn to toughen up and handle the pressure. Because I guarantee you this: you will grow in any job that is worth having. Sometimes that growth will be forced. Even when it's not, it can still be uncomfortable and stressful. Why? Because you're doing things you haven't had the chance to become comfortable with, or there's some external pressure: deadlines loom; a teammate is off sick; a horrific security flaw is discovered in your code, or in a library you use; some terrible bug makes it into production (this happens at even the best companies) and you need to hustle to fix it; politics happens, and you have to navigate through it. In this line of work you cannot avoid stress. You can certainly make every effort to run an orderly software development process with great teams, regular releases, great feedback mechanisms, interesting work, and all the rest, to minimise chaos, but that doesn't get rid of the stress. We're software developers. Our stock in trade is dealing with really hard problems. Sometimes those problems are technical, sometimes organisational, sometimes commercial, more often a blend of all three (along with other factors). Guess what? Dealing with hard problems is stressful. Easy problems aren't stressful (although boredom is for many), but if you wanted easy you chose the wrong profession. So buckle up. Because if you cannot handle an hour sitting down and working either with an interviewer or under their observation/guidance on a problem, how are you going to handle it on the job when it all kicks off (whatever "it all" happens to be on the occasion in question)?[1] [1] This presupposes the interviewer isn't an asshole, and can be depended upon to behave like a grown-up. I have borne direct witness to, or heard report of, far too many interviews where the interviewer appears to be on a mission to prove they're smarter than the candidate. If you are unlucky enough to be interviewed by somebody who behaves like this you may be better off looking for a position elsewhere even if you're offered the job.
• dkhenry 7y ago
  Whenever I see anything about hiring I always think back to this article https://techcrunch.com/2015/03/08/on-secretly-terrible-engineers/ https://techcrunch.com/2015/03/08/on-secretly-terrible-engin...
• yellowapple 7y ago
  I recently got thrown into interviewing a bunch of NetSuite developers (so lots of JS programming), and so far my strategy has boiled down to: 1. A verbal pop quiz about some reasonably-complex NetSuite-related programming topic/task (i.e. "on a high level, how would you go about implementing $FOO, given the constraints $BAR and $BAZ?") 2. Digging into past projects/experience and gleaning info on how involved the candidate was with those projects 3. If available, look at an existing programming portfolio / GitHub account / etc. I feel like these three things tend to cover my bases, knowing full well that they're flawed assessments (but flawed in ways I can control and adjust/tweak as necessary).
• beeblebr0x 7y ago
  I've interviewed many candidates for cloud native architect positions. None could tell me what important tools/patterns like TLA+ or CQRS and none could discuss the concepts once explained. Instead of recreating the binary tree from an array of in-order, depth-first-traversed nodes, which is an extremely narrow minded test of someone's skills, I want them to describe how they build reliable distributed systems. LeetCode, HackerRank and the companies whose interview process gave rise to these sorts of services misunderstand the idea of software engineering.
  • 9nGQluzmnq3M 7y ago
    If you want somebody to describe how they build reliable distributed systems, then ask them to describe in detail how they would build one for a specific use case, instead of quizzing them on alphabet soup.
• ltbarcly3 7y ago
  The older I get and the longer I do stuff the more I realize that everything is broken and there's nothing you can do about it but try to do the things you are doing well, learn from people that you think are doing something well, and teach people where you have figured out how to do something well. None of these things are blanket rules you can read in a blog and then follow.
• awesome_dude 7y ago
  The problem isn't limited to engineering hires, ever bought a house and had to go look for a builder to check the house is in good nick? What about the lawyer you use for the conveyancing? How about an accountant to do your taxes? Further, how do you define who is the best? Someone who does a so-so job in a short amount of time? Someone who checks every possible decision branch, explicit or implicit? Someone who writes code in a clever way. You're only ever going to see the skills you understand. Anything that you do not understand you will miss.
• brooklyn_ashey 7y ago
  Why is it that no one questions the system in which these —at best, ridiculously obtuse—at worst, totally corrupt, often nepotistic— “interviews” reside? The whole “interview/audition” culture comes out of a kind of gladiator/Olympic ethos that pits "commoners" against one another for the amusement of the powerful, while solidifying the collective deception that keeps them in power. It’s a lever workers hand over willingly because the other mythology—the one in which their genius and hard work “earned” them their position—is an identity narrative they can’t survive the despair of corporate culture without. But haven’t the critical thinkers among us agreed that when the starting bootstraps are of different lengths, we can’t trust our notions of “merit-based” reward? Celebrities bribing their kids into college is but one of the more languid manifestations of the bankruptcy of this belief system. When we play along in this gerrymandered Miss America pagent—what now passes for job interviews in tech—we legitimize and endorse these so-called “measurements". We need to collectively refuse to participate, with some vehemence and volume. We must stop trying to make fairer versions of this fundamentally dishonest bullshit. There is no fair Three Card Monty; it’s a trick! Back in the day, the only folks who would play that game around 42nd St. were tourists or kids who’d just moved to the city. This interview process is the same; you can only pull it on the green, which is why it selects for the young and desperate. Hey! Young and Desperate! You are way smarter and better than this. For those looking for actual data, like the post’s author who says as much, one could turn to the classical music “industry”. This audition process where “the best man wins” was exactly that for many, many years, until someone thought to put up a screen and down a carpeted walkway, and well, what do you know?...when the candidates were truly anonymous, women started winning. Here’s an article http://gap.hks.harvard.edu/orchestrating-impartiality-impact-%E2%80%9Cblind%E2%80%9D-auditions-female-musicians http://gap.hks.harvard.edu/orchestrating-impartiality-impact..., one of many on this study. So that trick was revealed, but ultimately, the idea that they would select the “best” players of orchestral excerpts resulted in them looking for players who rivaled computers in accuracy. Unfortunately, that isn’t really what one wants in an art. Anyone there has the accuracy required in spades. Accuracy beyond that is just meat compiling. It turns out that classical orchestras populated by this kind of person lack morale, creativity and vitality and don’t evolve with the culture, so these organizations have become culturally dead and are going bankrupt all over the country—this after their members were forced to let go of any real compensation and all dignity. The problem is that most organizations like these and tech companies are top-down. They are run like the military; their basic training programs are even called “boot camps”, and like boot camps, they won’t get you much. We need to take a look at the whole system, I’m afraid, or it will suffer a fate similar to music in this country, because that’s what happens here, eventually.
• nabdab 7y ago
  With all the focus on broken hirering, I never quite head the employing side being like: “we thought this person was the perfect candidate but (s)he turned out to be rubbish.” So on that side of things it seems ok. Mostly the people who seem to think the system is broken are people who don’t get the positions they believe they are perfect fits for. But they have an extreme bias and don’t actually know the state of the competition that end up getting the position.
• devxpy 7y ago
  The "cons" part of this list is filled with how a practise doesn't work for X class of devs. So, why not randomly pick 5 of these practices and simply tailor your process so it works well for a majority of candidates? Something like pick your poison?
• erikpukinskis 7y ago
  I don’t get how “Look at what University they went to” becomes “Check if they went to Stanford”. There are lots of good schools. If you got a BS in Computer Science from UIUC, that means something to me. That’s a good school and you got through it. Same with jobs, why does “Look at their job history” mean “Check if they went to any big name tech companies”? You look at the companies, look at what the company does, what the applicant said they did for them, and ask them questions about what that was like. It doesn’t really matter if it’s Google or it’s Pet Food Express, the important questions are the role and the work.