7 ms·

Ask HN: Why are hiring processes flawed and testing random standards?

• codingdave 7y ago
  The process is aimed at fulfilling a business need that they are experiencing. Unless you know everything going on internally, it is difficult to judge whether the hiring process is bad, or simply not matched to your expectations. As to why it seems fearful, there is a huge price to pay if you make a bad hire in any company, but it is exaggerated when you make a bad remote hire, even more so if they have never worked remote before, and you need to bring them up to speed on how it works. There may be fear, but again, it is business-driven.
  • maxaf 7y ago
    Your comment is chock full of flawed and patently false ideas. Firstly, I have yet to encounter a company with a hiring process that is actually, provably, repeatedly tied to any of that company’s business needs. Designing a working hiring process is harder than the software work that the hiring is for. It’s no surprise that results usually seem arbitrary and ineffective. Secondly, and following up on my first critique, an ineffective hiring process usually leads to the hiring of candidates who are good at interviewing, not at the actual work. These are the literal “bad hires” that should have been sifted out by the hiring process.
    • isugimpy 7y ago
      Having just gone through the interview process with a very well known tech company, as someone who is honestly pretty terrible at interviewing, I think some companies actually get it. It's really a matter of the interviewer at play. Two of the phases I went through really aligned with the company's needs. I was interviewing for a SRE position, and in one phase they gave me a broken EC2 instance that had been manually configured and asked me to get it back up and running. That's a legit task that I've had to do in daily work for years, because there's ALWAYS going to be someone that does a quick hack to get something working and forgets to productionize it. It was a completely contrived box that didn't actually serve customers, but still a good exercise. In another phase, they had me completely blind fire design some infrastructure (without a complete picture of what the current state of the application is) to lead toward a scalable solution for a real problem they're facing. While, yes, that's basically them getting me to do unpaid work, since I didn't put hands on a keyboard during it and really just talked it through with them, I feel like that was a great exercise in seeing how I thought and could work with a member of the team. There's no truly bulletproof solution to interviewing, because the needs of every org are different, and the skills of interviewers are rarely nurtured to the point of usefulness. Sometimes you just have to luck out and get a good interview.
    • dahart 7y ago
      > Your comment is chock full of flawed and patently false ideas. Whoa, what triggered and justified that response? I don’t know if the parent was edited, but it seems pretty reasonable to me. > Firstly, I have yet to encounter a company with a hiring process that is actually, provably, repeatedly tied to any of that company’s business needs. What do you mean? Why do companies hire then? > an ineffective hiring process usually leads to the hiring of candidates who are good at interviewing, not at the actual work. These are the literal “bad hires” This hasn’t been true in my experience. Why would someone who’s good at the work not tend to be good at interviews? I’ve interviewed hundreds of people and hired dozens. The number one reason for a candidate not getting a position is that there was another better candidate. More often than not, it has nothing to do with how good the candidate is, nor does it have anything to do with how good the company’s interview process is. After that, there is usually a large number of candidates that are young and shooting above their weight, hoping to get in somewhere with almost enough qualification. Occasionally, that works. I haven’t bumped into anyone yet that was great at interviewing but not good at the work, but like many companies, I’m using the interviews to try and find out if they’ll fit it, and if they’re truly interested, and if they’re good at work.
• mastry 7y ago
  I have no answer to your question, but I can at least offer some sympathy and confirmation. I've been looking for a remote position for months and have been eliminated from consideration many times because I didn't have "X" months experience with specific technology "Y" - which could be easily learned by _any_ experienced developer. It's baffling ... and deflating.
  • mharroun 7y ago
    To defend some of this: 1) Why pay someone to learn? In both terms of money and other devs time being sunk into helping you learn. 2) If you do know "tool X" and its a primary tool then its a lot easier to quickly evaluate whether or not standards will align. Personally I don't mind hiring Jr Developers that cost less, are mold-able, and are willing to put in extra effort. Could any experienced dev lean it? Sure... but its more costly and often ends up in a "I have now studied X for Y weeks, we do X wrong I refuse to do X your way."
    • thestepafter 7y ago
      I have had great success hiring junior developers and molding them as described above. This turns the interview process into learning about the person and their goals and what drives them instead of what do you already know. Because let’s be honest, most development work can be learned fairly quickly for 95% of the work out there that needs to be done. For the other 5%, hirer a senior person who has that specific experience. Not necessarily experience in that tech, just experience solving the need you have. Performance, scaling, complex math, etc.
    • reallydontask 7y ago
      Do you work with such an extremely static stack that it requires no further learning? I would say that one of the most important qualities a developer can have is the ability to learn. Perhaps, you expect all the learning to be done outside of work?
      • mharroun 7y ago
• kentrado 7y ago
  They only get as picky as their options. Remote companies get exponentially more candidates so they can make them jump like monkeys with impunity. https://www.youtube.com/watch?v=v1WiCGq-PcY https://www.youtube.com/watch?v=v1WiCGq-PcY
• dlphn___xyz 7y ago
  why would you choose to work remote - are you retired? no jobs available in your immediate area?
  • kaoD 7y ago
    Why do you ask that? I work partial remote and every day I go to the office I wish I was fully remote... not because I hate the office (I love it, and really enjoy my co-workers) but because I hate commuting.
    • dlphn___xyz 7y ago
      Partial remote or designated telework days make more sense than being fully remote. However, it seems like you're exchanging any future/potential at a company for the convenience of working remote which why i was asking if he was retired.
  • wolco 7y ago
    There are lots of jobs in the area. I've worked remotely a few different times in my life and prefer to reduce commute mostly. I set out attempting to get a remote position and if that failed I would look locally. It took almost two months where locally I usually could land a position in a month or less. Locally is a lot easier for sure.
• jchallis 7y ago
  Two thoughts. First, most companies will look for a remote person only after exhausting their local labor pool. If someone remote has to devote their initial months to learning with no advantage over someone local learning the same content, why not go with the added benefit of hiring someone local. Second, many companies have a fallback person in place who can almost meet the need - maybe they have x amount of years in a language, right attitude, etc. This process is only to see if you are better than their fallback option. The distressing answer sounds to be rarely.
• leerob 7y ago
  My opinion - Why is the process so bad? Hiring technical talent is flat out difficult. Even for the best companies. Thus, attempt after attempt has been made to figure out "the right way" to screen candidates to prevent bad hires. It started with algorithmic interviews. Then, we tried take home assignments. Now, lots of companies are doing pair programming type scenarios including a code review for a more accurate representation of a day on the job. Still, there hasn't been this silver bullet companies are looking for to solve their hiring woes. I don't know the solve. There's also a large problem with those doing the interviewing being either untrained or unempathetic to the candidates.
• lazyant 7y ago
  Hiring process in our industry has lots of problems and discussing them is one of HN's favourite topics. For remote the bar is higher, simply because not everybody is able to be effective working remotely, so companies are more weary about remote workers. For ex my company does hire remote but only senior and more exceptional candidates.
• jarsin 7y ago
  I have come to see trying to find a job is a lot like dating. You see the company for the first time "oh look how pretty. We would be perfect together!" Then you start talking and they ask you a bunch of really stupid questions. The voice in your head starts telling you something is off. Then they start testing you and giving you the run around. In dating this is known as playing games. Just like in dating it's time to wake up and realize they are showing you who they truly are. Ignore at your own peril!
• hsuresh 7y ago
  I am building a product/startup [1] to address some of the problems you mention, and as a result, I've been talking to hiring teams at several companies, so I can give you some reasons why the processes are bad. * Hiring is a marketplace, and supply/demand is not always balanced, so most issues related to job search/hiring is due to this. * When a company posts an ad for a job, they usually receive about 150-200 applicants within 2 weeks, thanks to job boards, LinkedIn etc. Unless it is for specific high-skilled jobs, in which case, they receive hardly any applicants at all. * Most of the applicants are usually not a match for the job, but given the number of applicants, recruiters rely on resumes, social profiles etc to shortlist about 20 applicants. * Tests and assignments are quick means to filter, hence their popularity. * Not much of an incentive to keep applicants posted at every step, plus, managing communication with a few hundred applicants for multiple positions is hard - so you're most likely to receive only automated communication from the hiring team. I believe that having a clear specification of the job, that can be checked/validated with applicants is critical to ensuring a smooth, fast interviewing process. [1] - Shameless plug to my startup (in beta) - https://www.interviewpass.co https://www.interviewpass.co. If any of you are interested in using InterviewPass in your hiring, drop me an email at suresh@interviewpass.co - happy to help set it up for you.
  • marcinzm 7y ago
    The problem as I see it is that good applicants don't bother with job boards. When you have recruiters banging on your door and begging to handle all the details for you (and provide proper communication) it's no wonder candidates don't bother applying. That, however, means the expectation is that job board candidates are bad and desperate. So companies will filter them more aggressively than recruiter candidates. So candidates now have even more incentive to go with recruiters since it actually gives them a better chance to get hired.
    • hsuresh 7y ago
      That's true. Recruiters provide the initial screening, which is lacking in a job board. But the hiring process is broken beyond the initial screening as well, biggest reason being lack of incentives for the involved parties to close a position quickly.
• mattdeboard 7y ago
  People giving remote-specific response as if that is the only problem. It is probably a contributor as well but frankly I have had very similar experiences interviewing for non-remote jobs.
• davtbaum 7y ago
  Most were looking for exactly one type with one set of experiences. Anything outside of that and you are filtered out. In my experience this rings true for senior roles and less so for new college grads. Companies seem afraid to hire thinking there is a slightly better/cheaper option around the corner. I can see why perhaps a candidate receiving a rejection may think this, but in the companies I’ve worked at this has never been the case. It’s always been “it’s really tough finding talent, not paying talent”. The take home assignments with random marking standards. Tests can matter, ui could matter, api structure could matter, documentation/choice of framework, speed, style all could matter but you rarely know which matters to whom and rarely have time to do it all and even if you did everything perfectly a lot of the time no one even looks or the reviewer expects the code to look like how they might write it. A fair reviewer recognizes the limitations of these take home exercises. While there are many ways to perform a take-home successfully, there are more ways to show that you aren’t qualified for the role. Not all that pass will be right for the job, but most who fail aren’t.
  • wolco 7y ago
    I would say many who fail are probably right for the job. Not having clear goals for the test that the applicant understands leads to this disconnect plus th time involved.
  • hysan 7y ago
    > Most were looking for exactly one type with one set of experiences. Anything outside of that and you are filtered out. > In my experience this rings true for senior roles and less so for new college grads. I agree that I've seen this to be true for senior roles, but what I've noticed on many job descriptions is the reluctance to say they are looking for a senior engineer. I've gone through quite a few phone screens where it becomes immediately apparent that the company is looking only for a senior but the job title and sometimes description looks like it was written for a mid or even junior position. So I can completely understand where OP's view of the hiring process comes from - you go through the initial test round, get to speak to them, then find out that they have extremely specific requirements. If you happen to be unlucky enough to go through many of these, it can really mess with your perspective on the hiring process.
• steventhedev 7y ago
  In a nutshell: they aren't. The economics of it are that in many places in the world, it is extremely difficult to fire an employee. Getting rid of an underperformer can take time, effort, and exposes the company to liability if the termination can be construed as relating to the employee being in a protected class (e.g. can't fire someone because she's a woman). Let's assume that it's a SF startup willing to play a little fast and loose and they aren't concerned with severance packages or the legal issues. They still put time and effort into training a new engineer. That's months of work that is potentially wasted. All of that means that companies are incredibly risk-averse when it comes to hiring, and will pass on someone who looks even slightly wrong to them. It also means that the process is inherently random as a company will pass on someone they aren't sure of _even if they would have been a good hire_ just because they aren't certain. However, this also means that a lot of companies rely on self-selection in their hiring pool. Look for people they already know, from the same backgrounds, or are willing to pass through a series of arbitrary tests. In short, it's like democracy. It's the worst form of government, except for all the others we've tried.
  • ChuckNorris89 7y ago
    Don't know where you live but in most of Europe firing someone is pretty trivial. For a newly hired, you have a probation period, before your contract becomes permanent, usually between a month and a year, where you can be fired on the spot. After that, your contract becomes permanent and you can get fired, no questions asked, with a notice period of usually between one and 3 months. In theory, before letting you go, the company has to set up a performance improvement plan for you but companies never bother as it's considered wasted effort to invest in under performers so they just warn you at your performance review that your performance is lacking and that this is strike one. After 3 months of performance monitoring you are let go because your performance hasn't improved so that was strike two and you're out. Sure, you can sue them if you know you've been wronged, and win a few thousand euros, but nobody's gonna hire you knowing you're in a lawsuit with your ex-employer so nobody bothers to sue and prefers to just find another job instead. So unless you're a protected category, usually over 50 years old, woman or not, doesn't matter or part of some big-corp with strong unions, the hard-to-fire is not an argument that holds water here.
• thow_leet 7y ago
  I asked an HR rep about this and she told me there is a massive influx of new grads demanding very high salaries. You and I might be from a generation where a CS degree was not an obvious choice and the supply was not as high for organizations. Unfortunately years of experience don’t count for much in this industry, especially with how fast technologies change.
  • thow_leet 7y ago
    Also, startup hiring usually means joining an already close knit team. If you have to interview with 5 people, have a fifty-fifty chance with each and anyone can veto your hire that gives you a 3% chance of getting an offer. Competency will get your foot in the door, but ultimately it comes down to the social psychology of social comparison and propinquity. If you are a senior/staff with some success at previous startups, you are likely to get vetoed by developers who see you as a threat in the promotions tournament.
• lr4444lr 7y ago
  Let's first establish: how are you measuring hiring success?
• tathagatadg 7y ago
  What I find funny is how little time and effort is put in writing the job description. The interview process is mostly very generic and the questions hardly in alignment to the role. As a profession we try hard to be correct about creating clear specs that can be translated to unambiguous steps for a machine to execute, but when it comes to hiring - we write ambiguous specs, toss it over to recruiters who are poorly equipped. Here are some thoughts: - When the new position opens, the team (say the scrum team) collaboratively writes a job description based on the current backlog. Let's not leave it to a manager or recruiter who is writing the job description. Use the company/team's mission and values as guidance to see who an ideal candidate would be. This is like writing your stories. - Then write the filtering criteria based on the typical day to day skills - what are must haves, what are good to have, what is ok to not have. This is like write your test cases. - What are the areas where the team is lacking. Try to get skills/qualities that will, for lack of a better expression, raise the bar of the team. This is like your retrospectives - and if you have notes from your recent retrospectives, they should help you identify what you are looking for. - This better spec should help the recruiters, and also give the candidates an honest look into the team. - For the interview, go back to your previous sprints etc. and build questions that are simplified models of what a typical story would look like. Instead of asking to invert a tree, may be it would be better to talk about how a particular problem you solved and see the approach the candidate would take. Give the candidate all the tools - their favorite editor/ide or whiteboard, whatever they prefer.
  • RicStrong 7y ago
    I'm actually assisting with a startup in building a solution for things like this, so your comment really struck home! And as somebody with a past in technical recruiting, I really like your thinking. Indeed you're right: many recruiters are poorly equipped to actually understand the roles. We have non-coders as the first or second tier gatekeepers for development roles, which does not seem ideal. Sometimes I'd get different signals from the job descriptions than the senior recruiters or hiring managers, which was frustrating. Other times, the requirements in descriptions were way too broad: like the team had an idea of what they wanted, but couldn't get it down on paper in a concise way. Resumes can be a challenge, too: many engineers don't always give full details of their work. Perhaps because they're tired of getting recruiters reaching out for irrelevant roles (that happen to have a keyword match somewhere). Perhaps they don't have the time to always be updating and polishing. A two-front solution could be really great. We need developers to write their best resumes, and we need employers to write their best job descriptions. Having them 'speak the same language' on concise accomplishments, metrics, technologies will make more automated matching a lot (a lot) easier. And then, of course - build the interview process around the shared skills / technologies / etc. Hopefully I'll have something to share here soon, or perhaps do an ask HN to chat more about making hiring developers easier for everyone
• lrem 7y ago
  Hiring is an inherently hard problem. I imagine the additional hard to test requirements of remote work (autonomy, discipline, ability to do your own it, ...) doesn't make it easier.
• specialist 7y ago
  Hiring processes are terrible for lack of accountability, transparency, feedback. I ran for political office. Endorsement interviews can be either awesome or brutal. One key difference is whether the interview is recorded, and then shared publicly. It will surprise no one that my worst interviews (in both politics and tech) were behind closed doors. Worst of all are the 1:1 interviews with inexperienced interviewers. Zero accountability, zero transparency, no feedback loops. They just report whatever they want, are not even expected to explain themselves. I've since decided that any future job interviews will be recorded and posted. I will definitely embarrass myself. But until someone starts, no improvement can occur.
• gtsteve 7y ago
  My company is 100% remote so I have quite a bit of experience with being on the recruitment side. I think if there was a standard for recruiting that the industry followed, then people would just be thinking of ways to "hack" the standard, so I don't think that would be helpful. Remote working is desirable and rare but also a lot of companies that recruit for remote workers are very new ones and they often have no clue what they're doing. I think they feel that so long as they make it really hard and unpleasant, they'll be like the other massive internet companies. To be honest, I also have no real clue what I'm doing but I am trying. Perhaps you could give me some feedback on our process while we're here: 1. A written test where we ask a few questions around the candidate's experience - what's the most interesting thing they've worked on, what recent tech are they most interested in, and we ask them to do a code review of a poorly written method. We have a strong culture of documentation so if the candidate can't write well then it's not going to be a good fit. 2. An online interview where we talk about the company, discuss the test, answer questions and write some code together via screen sharing. This latter part takes the longest part - firstly we write a simple string reverse method, write some unit tests for it, debug another method and design a history API for a browser (which has more edge cases than you'd think). What we're looking for: confidence in programming, code, design and communication. 3. An online or in-person (depending on where the candidate lives) interview with me and our CEO. This part has about a 95% success rate for the candidate, our CEO's just a people person and likes to get to know people. 4. The candidate is hired, and we start assigning work in increasing levels of difficulty. This is a probation period of 3 months. Stage 4 is still part of the interview, we're able to take advantage of UK labour laws that allow us to let someone go inside 2 years without having too much trouble. This way we can see them working for real and even if they aren't that good, get some sort of benefit from it. Of course, we might waste some money but it's an opportunity to learn what we need to do better during the interview phase. For better or worse, capitalism rewards those who take risks. I think the companies with their multi-month long recruitment cycles are putting too much effort into risk minimisation. I'm happy when I hear about my competitors' "brutal" interview processes. It means they're moving slower than me.
  • wolco 7y ago
    As long as there are clear expectations at each step I think that goes a long way.
• exabrial 7y ago
  Unpopular answer: Interviewer Ego
• jamestimmins 7y ago
  A few (incomplete) thoughts: 1. We haven't yet figured out a way to get enough signal from two hours or so of work. 2. There are multiple ways to be a good programmer, but companies need a standardized way to assess skill. There's an inherent mismatch. 3. Most teams don't even know how to gauge their own employees' skill/value. 4. Teams rarely have their own employees retake their hiring tests to calibrate effectively. 5. Unpopular opinion: they aren't. Skills like algorithms are vital, and people who argue that they don't matter simply don't want to do the work.
  • ravenstine 7y ago
    > 4. Teams rarely have their own employees retake their hiring tests to calibrate effectively I can't imagine that would end well in most cases.
• jcadam 7y ago
  All of my previous job searches started with me seeking remote work and ended with me giving up and taking a local job. There clearly is a surplus of great engineers looking for remote gigs. I've recently landed an on-site job (I had to relocate) that pays pretty well in an R&D type environment that's actually all right -- in fact, this is one of the few jobs I've had that I've not hated -- so I may stay here more than my usual 1-2 years :)
  • RicStrong 7y ago
    I really hope there's a big push for remote roles. If that's where the talent wants to be, companies should be able to stay competitive. Plus, it's much better for the environment. If you can do you work from home, why not?
  • anotheryou 7y ago
    My biggest problem was that companies can't compete with a good European unlimited contract. Most want to hire you as a contractor. Contracting I'd have to at least double my salary to take home the same amount of salary and insurances and out of germany it's basically illegal to be a full-time contractor for just one company.
• anotheryou 7y ago
  At least I can weed out companies with bad hiring practices. They team can't be much better than how they hire. Having a remote interview with really bad audio, no word on their product, no small talk, just questions without discourse or feedback on my answers? - No thanks. I'm a bit torn on assignments and trial days. I think they should simply be paid.
  • mooreds 7y ago
    At the company for which I work, we definitely pay something for the take home assignment. Not a ton. It's less a "this is what you'd get paid as a contractor" and more "this is a recognition that you are spending some free time on this and we appreciate it".
• shmooth 7y ago
  I'm currently doing the interviewing process. Fun. I just finished a take-home assignment that I considered roughly "not completely sadistic", and it took me about 10 hours. And there is some level of trust I have for the hiring company, etc., so I was comfortable doing the 10+ hours. Not happy, necessarily, but decided I wasn't going to try to change the hiring process while I was trying to be busy getting hired. I could easily see someone spending 20-40+ hours on it, and still not completing it successfully. I was offered proactive help by the existing staff, which was super-nice of them, and it probably helped. I'm not sure how long it was supposed to take. I would generally guess that hiring companies think their take-home tests/assignments take about one-fifth/tenth of the actual time they take. They often are simple if you're an expert in the company's proprietary software platform. I don't know what the difference is for remote vs. local hiring -- I'd guess the hiring is generally more tedious for remote positions -- they require more trust. I'm generally in the sales engineer/tech acct mgr/tech support/other-type space. If I don't love the company, and I get a homework assignment that is 20+ hours, I usually bail. I had another position I was working on that required a codility (?) test. I took the sample test and 'passed' it, or thought i did, but then the eval said i got a zero. So, not sure what that was about. I ended up bailing on that position, or telling the company i'd do any other type of tech screen, including live coding, whiteboarding, etc., but they weren't for it. I said I'm not down with that tool, but it was over. Fine. I know better than to try to justifying my objection to these types of tests. Lots of companies have been asking for recorded video interviews. I try not to voluntarily talk to robots. Again, I try not to object on 'dignity' or any other grounds -- it's not a language that 'we' commonly understand yet -- it's too sci-fi. So "let the robots do it" is one strategy for hiring. I think there are lots of sane things we can do to improve the hiring process, but one thing I'd generally like to see is an easier try/buy process (like traveling nurses seem to have). In theory, contracting or contract-to-hire can make everyone's experience better, but...it just doesn't seem widespread in my experience. For example, I would love the opportunity to work for some company for 2 or 3 months, at some percentage of my normal rate, and then if we both like, we agree to the full-time hire. But it seems everyone is deathly afraid of having to pay unemployment. That's the best guess I have for as to why this is not a more common practice. This arrangement or something like it would seem to offer a good mix of risk/reward for everyone involved.