33 ms·

What's Wrong with Tech Hiring

159 points by luu 5y ago

cgearhart 5y ago
Referenced research paper: https://chrisparnin.me/pdf/interviews-HN.pdf https://chrisparnin.me/pdf/interviews-HN.pdf Only read it partially so far, but it seems interesting.
- cjg 5y ago
  It also refers to https://chrisparnin.me/pdf/Debugging-Hiring.pdf https://chrisparnin.me/pdf/Debugging-Hiring.pdf
- renewiltord 5y ago
  These are both great!
lifeisstillgood 5y ago
They reference Automattic's hiring process, which is an interview (90mins), take home coding (6hrs) and a paid project (40hrs). That essentially makes hiring a serial process for the candidate. All you are selecting for is people who really really want to work for you. I see software as a form of literacy. How do people hire writers?
- yosito 5y ago
  I think it's the 6 hour take home coding that's a problem. I would suspect that when hiring writers, they look at a sample of the writer's past work and don't require the writer to spend 6 hours writing a sample children's book.
  - raxxorrax 5y ago
    Would be nice to have an example. 6h/40h software development doesn't really say much about scope and is highly dependent on your experience with the tools necessary to perform the task.
  - thinkharderdev 5y ago
    The 40h paid project also seems kind of crazy to me. It is nice that is is paid but almost every software engineer I have ever interviewed already had a full-time job and was looking to switch. Where are they supposed to find 40h to work on a side-project even if it is paid? Is the idea that you are supposed to quit your current job first before interviewing?
    - aix1 5y ago
      > Where are they supposed to find 40h to work on a side-project even if it is paid? On top of that, taking on paid outside work in the same field could also be contrary to the candidate's contract with their existing employer[*]. [*] This no doubt depends on the employer and the jurisdiction.
      - lifeisstillgood 5y ago
        Of course !
  - yawaworht1978 5y ago
    I had both a full day on site JS programming(css optional) and a 20hr take home reactJS exercise besides all the precious onboarding stuff, pretty crazy effort, for both parties, time is money. For one I had to take a day off, the other i did over a weekend. Another thing I have realized, all the jobs valued php and bit SQL more as basic knowledge for web dev than any nodeJS/MongoDB even if it's just front end, they want some back end understanding. Had some nodeJS things that generated all the front end via express , including chat module and sign up/log in flow, but either it was overlooked or not valued, any 5 minute to do list or crud with anything front end JS seemed more important. I suppose few dare to touch the node ecosystem and nosql databases. And the most recent one asked me if I can do their front end in react(really overkill, no need), told them I'll do it in vanilla JS, but nope, he insisted on react and that was the end of the story. Was for a MVP and would be the sole dev for a while. I have found in general that speaking to hr is not useful, if you get past that and a senior dev (not a manager or product owner) interviews me, it would be a good experience.
- raverbashing 5y ago
  As much as it is good they're paying you to take on a longer project, most people that are currently employed can't take this project without being in conflict with their current job. (Or even having time for it) I think tech companies are forgetting that firing people is an option.
  - Nursie 5y ago
    Particularly in the contract market - I often see the process for taking on a contractor or consultant play out the exact same way as for an employee, forgetting that the interview process is very flawed and you can send the consultant home at any point you feel like with zero comeback. That said I’ve also seen companies pay contractors a month’s severance for no reason whatsoever too. A lot of places don’t seem to understand what they’re doing.
    - bryanrasmussen 5y ago
      my contracting contracts - in Denmark - often have a notice period but it is around 1 week to 1 month. I pretty much refuse coding exercises for contract work since it's so easy to get rid of me if you don't like it, and anyway as a contractor you get paid per hour so they should pay me for it. But sometimes there comes a place you really want to work for and they happen to have the coding exercise...
  - FooBarWidget 5y ago
    No time? Can't people take vacation leave? Yeah it sucks that the time isn't spent on vacation, but you can't have everything in life without some cost.
    - Okkef 5y ago
      You are either a troll or don't have a family. If you do have a family i feel sorry for them. Life is not just about work.
      - FooBarWidget 5y ago
- nxpnsv 5y ago
  If you do one challenge, 6h is ok - I've even enjoyed these at times. But I'm sure it gets old real fast if you are on your 10th one...
  - Grustaf 5y ago
    10 challenges is like two weeks of work. You probably studied for 3 to 5 years, and hopefully you'll work there for at least 2 years. Two weeks is not much, even if it is tedious.
    - isbvhodnvemrwvn 5y ago
      You assume that there is no alternative which is a better match and doesn't have this sort of hoops to jump through.
      - Grustaf 5y ago
        I don't assume anything, I'm only saying that even if you had to spend 2 weeks to get a job, that's not really anything to complain about. The vast majority of people spend way more than that.
        zqna 5y ago
        Free advice: don't do "homeworks". It's an indication of poorly run and dishonest company, with incompetents at the helm. That's if you get the contract. Most likely you won't (because your are competing with desperate people who lie about their actual effort). Best is to stay out of it.
        Grustaf 5y ago
        I got my FAANG job through whiteboard interviews, but I definitely prefer homework, and I think that's a better method. But thanks for the advice.
- Grustaf 5y ago
  > All you are selecting for is people who really really want to work for you. Really really wanting to work there is a good start. If they can also finish the tasks in a competent way it would seem they are perfect candidates. What is the problem?
  - isbvhodnvemrwvn 5y ago
    How many competent candidates are willing to jump through hoops like this?
    - Grustaf 5y ago
      I don't know, 23?
  - lifeisstillgood 5y ago
    It seems Automattic is part of a select group of tech companies who are desirable as places to work, and have more high quality applicants than they can hire, and need to whittle down. That's great. And if I apply to one of those I really need to expect that. Now the company can be in this great position by being a world leading engineering organisation that is growing exponentially. Google, Facebook et al a few years back perhaps. But alternatively, any $RANDOMCOMPANY can think it is in this position not by attracting the best applicants globally, but by only hiring 3 people a year. The company still will get more high quality applicants than it can hire, so it needs to whittle down. But from the applicant side, applying to Google looks very different than applying to $RANDOMCOMPANY and they will drop in preference order. Taken to its logical extreme, each candidate will choose one company only to apply to based on the existing job pool and their expectations of getting the job. That seems silly.
- fsociety 5y ago
  46.5h to interview at a company? I’m not sure why cream of the crop developers would tolerate that over 5h of interviews. That sounds nearly predatory.
  - andrew_ 5y ago
    I surely wouldn't do 6 hours of unpaid work. Not unless very desperate.
yellow_lead 5y ago
This article is very light and based roughly on the qualitative study linked in another comment. The study reads like a summary of Hacker News thoughts on tech hiring, which isn't much news to me.
- zeckalpha 5y ago
  The site is an aggregator of paper reviews, this review combined two papers and added relevant anecdotes not in either. > Short summaries of recent results in empirical software engineering research
bronlund 5y ago
I think the problem with tech hiring is the same as with a lot of problems in technology. The guys making the decisions just don't understand technology.
rcarmo 5y ago
I think most of what is wrong with technical hiring is bias and expectations: - There is always an age bias. Younger==cheaper in every single HR department in the world, but tech experience (and output) often increments faster than age. - Someone who’s spent a couple of years not coding because they decided to try management or consulting will get passed over because interviewers don’t really expect them to want to code anymore. Never mind if they actually consulted for and designed systems that are currently running in the Fortune 500. - Timezones and “meeting quorums” are very tightly aligned in some hiring manager’s minds. If someone can’t make half the meetings because they’re offset four hours, managers get antsy. - US/non-US is still a massive chasm. The first question I got from every FAANG interviewer was “when do you think you can relocate?”. And the pay differential is atrocious. Remote helps a bit, but the age bias will get to us all.
- mettamage 5y ago
  > And the pay differential is atrocious. I'm quite simple with this. I simply work less and lie about it. Unless I feel passionate, but then I don't view it as work. With that said, I do tell them upfront that I kind of work this way (I always say in interviews: pay me fairly and I'll treat you fairly, here's what I consider to be a fair wage. If they then lowball me and I accept because I happen to need the money, mayhem ensues. So far, 25% of the companies have met my salary requirements easily, all non-FAANG and local). Remote work helps with getting away with this. You get what you pay for one way or another. If I happen to get fired, so be it. I might want to consider switching careers then.
  - WalterBright 5y ago
    > pay me fairly and I'll treat you fairly This might work for you, but I wouldn't hire someone who said that. It translates to "I'll only be honest if you are honest." I like to think that peoples' honor is not contingent on their estimation of the honor of their colleagues. My dad told me that the difference between men and animals is men have honor. We each get to choose which we are.
    - 5y ago
tester34 5y ago
Different approaches work for different people e.g People with family/kids would rather not do home-work tasks Some people would prefer to be asked about heavy job-related stuff e.g frameworks, kubernetes, real-life problems Some people would rather challenge themselves against foundational knowledge e.g because for them it may be faster to do 1-2 algo tasks or it being technology agnostic Some people would rather try designing systems, operate at higher abstractions levels instead of typing code ... I personally believe that I'd rather see security questions than algo/ds questions cuz poorly performing algo can always be rewritten, meanwhile leak cannot be reverted, but I'm aware that shitton of people would hate that How to match "interview kind" to candidate? maybe ask them which they prefer, I guess? but it assumes that you have people capable of performing this kinds of interview and you want to "enable" this person to peak
- fredrb 5y ago
  > How to match "interview kind" to candidate? maybe ask them which they prefer, I guess? I don't think it's a matter of candidate preference but rather position need. Some companies need Computer Science / Engineer mindset to solve complex problems. Some companies need XYZ framework developers to deliver customer projects. FAANG companies usually need the Engineering role and developed an interview model to select those. The problem is when companies that need developers apply the same interview mindset that Google does.
zivkovicp 5y ago
I insist on discussing salary range up front to avoid wasting everyone's time over the next couple of calls... also coding tests are a pain in the ass and as a general rule I don't do them. If I can walk someone through a project I've worked on and discuss it, or do a collaborative code review, that works, otherwise I thank them for the opportunity and move on. I don't get a lot of callbacks anymore since taking this stance, but that's fine. There's a reason why probation periods exist, and after a few years in the field, most engineers are able to adapt to a new code base just fine, it's the soft skills that interviews should filter for anyhow. my2c edit: typo
- andrew_ 5y ago
  I take exactly the same stance. I find that, while I'm not contacted for followups from places like LinkedIn and cold-contact recruiter emails, the approach does resonate with smaller companies that look to places like AngelList and Moonlight for their recruiting efforts. Tech recruiting has become a massive numbers, volume grift.
epicureanideal 5y ago
What’s wrong is the people in charge of most companies. They have money and connections but not much talent for actually managing the building of working things. And then they want to pay relatively little to the people who actually can build the things… while not knowing how to distinguish those people from the rest of the crowd. And of course, among the skills they lack is the ability to measure results and design effective compensation systems.
koevet 5y ago
I'm a freelancer based in Germany, been a freelancer for a long time (20+ years). Worked on a LOT of different projects in several (European) countries, as developer/architect/tech lead - whatever the client need was. Since my relocation to Germany, I decided to try the "no-tech-interview approach": does a client wants to work with me? Let's talk, for hours if needed, let's meet in person, whatever is required to make both parties confortable with each other. I'm more than happy to answer questions about my previous projects, how did I work on a specific solution or technology, which mistakes I made. But no technical interviews (as in whiteboard coding, riddles, take-home assignements). I have 25 years experience, I have references, I have code on github in several programming languages, I wrote a technical book. This approach has been working so far. Some clients still insist on doing a coding challenge or a classical technical interview: I politely decline and move on. There is no shortage of contracts, so I have always some lead in the pipeline. I would say that 50% of the leads are from me being recommended by people I worked in the past: this is obviously the value added of having lots of contracts under the belt. If I feel that my experience would not be a good fit for the project, and there is not enough time for a ramp-up, I would also decline. I do realize that this no-tech-interview approach would probably never work for permanent positions, especially when it comes to hire junior developers. Having said that, I strongly believe that the most valuable asset for a team is a decent person. Very few teams work on hard-problems, requiring super-specialized knowlege (say, AI for self-driving vehicles). The majority of technical skills can be learned, if one has the passion, willingness and humbleness to learn (and the employer wants to invest in the team - which, sadly, is often not the case).
- wirrbel 5y ago
  Someone I hire as an employee I want to have a good understanding of their capabilities, because - let's face it - letting someone go is not a good option esp. culturally in Germany (it would still be possible within first half year "Probezeit"). But I do prefer to hire someone that I am certain can contribute to the team for the next years. As someone who interviews, I can say that while there is a correlation between CV and coding skills, you do find regularly that really simple coding problems cannot be solved by applicants (slightly above FizzBuzz complexity). And for most applicants, there is no Github-Account. So I think its only fair to have some coding problems that don't overdo it of course for permanent positions. When you are consulting the situation is of course a bit different. The situation is temporary. Getting and verifying references is actually legal and possible. So I can definitely see that you get gigs this way (you'd also get hired without solving a coding challenge because many companies don'T do it actually). I just personally would feel much safer joining a company as an employee where I can be certain that my colleagues can at least code and have been selected with appropriate care.
wonnage 5y ago
I wonder if tech is unique in having an implicit mistrust for everything on the resume. I've worked at several large companies where people don't even bother looking at them before interviews. I blame the FizzBuzz blogpost (https://blog.codinghorror.com/why-cant-programmers-program/ https://blog.codinghorror.com/why-cant-programmers-program/) for making everyone deathly afraid of imposters. It's a masterpiece in ego-stroking - of course you can write FizzBuzz, look at all these sorry suckers who can't. Resumes are lies, only a 45 minute brainteaser on CoderPad can reveal the truth (ignore existence of Leetcode). In reality if I'm considering a senior candidate from FAANG (like, actually senior, not 4 years out of school), simply talking about past experience is perfectly fine. The work is the fucking same, everyone is migrating from legacy system X to a distributed system with zookeeper and kafka, they'll fit right in. It would take a truly psychopathic liar to fake their way through all the mundane details you could ask about a project like this. And if one slips through the cracks, they'd probably make a great PM anyway. (As long as they're on your side.)
- Ekaros 5y ago
  If they can't code just make them manage and bullshit everyone else in process. And hope they are smart enough to let people they manage to make important decisions.
- rootsofallevil 5y ago
  >I wonder if tech is unique in having an implicit mistrust for everything on the resume. I've worked at several large companies where people don't even bother looking at them before interviews. I blame the FizzBuzz blogpost (https://blog.codinghorror.com/why-cant-programmers-program/ https://blog.codinghorror.com/why-cant-programmers-program/) for making everyone deathly afraid of imposters. It's a masterpiece in ego-stroking - of course you can write FizzBuzz, look at all these sorry suckers who can't. Resumes are lies, only a 45 minute brainteaser on CoderPad can reveal the truth (ignore existence of Leetcode). While I agree with you on the whole, I have had interviewed candidates who couldn't code. One of them basically said that they would learn (CS degree but 4 years as a PM), which was fine but not what we were looking for. Another simply refused help and proceeded to bat their head against the brick wall of simply syntax. Didn't show signs of nervousness, panic, etc ... just seemed not to be able to code. In short, I think they exist (programmers that can't program) but they are the exception not the rule. >In reality if I'm considering a senior candidate from FAANG (like, actually senior, not 4 years out of school), simply talking about past experience is perfectly fine. The work is the fucking same, everyone is migrating from legacy system X to a distributed system with zookeeper and kafka, they'll fit right in. It would take a truly psychopathic liar to fake their way through all the mundane details you could ask about a project like this. And if one slips through the cracks, they'd probably make a great PM anyway. (As long as they're on your side.) I agree with you that an interview probing the experience of the candidate by getting them to talk about what they've done seems like a far better proposition. You will get a better idea of what the candidate knows, doesn't know.
willvarfar 5y ago
Young whippersnappers are going to downvote me for sharing, but I'm on the other side of the divide and have had to interview and be interviewed a lot over the years. The normal tech interview questions about sorting or recursion or whatever are not supposed to be business-relevant questions, they are to filter out people who simply can't program. The industry is awash with candidates with ok-seeming resumes, that get through HR screening, but then fail miserably at the tech interview to solve something like fizzbuzz. My anecdotal experience is that you never want people who can't write a for-loop or whatever in your team, whatever you are doing! The tech interview with the ludicrously simple questions are all about finding people who 'get it', and are actually effective at it. Which is why it persists. The good news is there are interviewers like me who have been lucky enough to be in the position to hire people on the strength of them being able to work through things in pseudo code even though they are not familiar with any programming languages. I keep interviewing and hiring physics grads on the strength of their excellent problem solving skills, and they all learn to express that in programming languages in short order once they are hired and they have found employment as a programmer...
- jahller 5y ago
  on top of that you will also filter out applicants who show some red flags when they not immediately know the answer to a problem. it's absolutely okay to not know everything. but there is a huge difference in how people communicate their lack of knowledge.
- raverbashing 5y ago
  If you're incapable of finding out who "gets it" without asking about fizzbuzz (which I'll point blank refuse to answer) or recursion/sorting, you're failing at interviewing. By the way feel free to try to write a sorting algo (preferably not bubblesort) by memory in your favourite language. It will be a good reality check. > My anecdotal experience is that you never want people who can't write a for-loop or whatever in your team Yes, you don't. But you don't need to ask them that directly, or have them code live.
  - attil-io 5y ago
fredrb 5y ago
I recently switched jobs and got interviews in 5 big companies for mid/senior Software Engineering positions. All their processes were fairly similar: Two coding interviews, one system design interview and a conversation with the hiring manager. I might be biased because this process was beneficial for me, but here are my 2 cents on it: It's easier to get a position in a stack you don't have professional experience with. You're tested for your ability to learn CS concepts, not stack specific knowledge. All 5 positions I interviewed to had different technologies. If I had to learn the specifics of each before applying, I would likely not get offered any positions.
shahbaby 5y ago
I don't think there's anything "wrong" with tech hiring. It may not be ideal but every approach has its trade offs.
amir734jj 5y ago
My recent interview experience with Twitter: https://news.ycombinator.com/item?id=28466586 https://news.ycombinator.com/item?id=28466586
cwp 5y ago
Meh. There's nothing wrong with tech hiring. Ok, sure, there are some companies out there that don't know what they are doing, and the very most prestigious companies have to do some very tedious stuff to deal with the fact that their process gets leaked and people are willing to put a ton of effort into preparation. But mostly, it's pretty reasonable: - Little reliance on credentials, because there are many solid candidates that didn't go to top schools or don't have CS degrees or maybe didn't go to post-secondary school at all. - There's some sort of technical interview that asks the candidate to show they can do the work by doing a small amount of work. They usually let candidates choose the language and tools they'll use for this, offer help if the candidate gets stuck, let them look things up on the web, etc. This can take a few different forms, but it's inevitable given that credentials aren't reliable. - There's some sort of "behavioural" interview that asks about how a candidate collaborates and communicates with coworkers. Tech companies aren't looking for the anti-social genius anymore; software requires teamwork. - Recruiters are typically very accommodating of a candidates' circumstances. They'll tailor the pace and scheduling of interviews to the candidates' needs, fly them in from other cities, reserve time in interviews to answer candidate questions, and generally put significant and explicit effort into making the "candidate experience" as positive and low-stress as possible. - There's a lot effort put into eliminating biases, and interviewers will often do things like not reading a candidate's resume until after the interview, or writing up their report before talking with other interviewers about the candidate. Most tech companies really want to do this right. I think that what tech companies ask of candidates is quite fair. These are high-paying (sometimes very high-paying), high-prestige, comfortable jobs with lots of perks. The company puts a lot of time and money into training new hires before they're productive, and it'll be even more time before they can tell if the new employee was a good hire or not. In other words, the cost of hiring the wrong person is very high.
sinstein 5y ago
Counter take: After having worked for startups a lot, my CV did not really look very impressive. A couple of short-medium stints would not really instil a vast confidence to someone screening. Algorithm and "Trick" Coding Questions allow me to prepare for companies I would normally never qualify for just based on my past experience. If Google only hired people who have touched Google scale systems, they might not have a lot of people to choose from. Thanks to the current interview structure, I can spend some time and prepare for any large company regardless of the kind of work I have been exposed to so far. Its definitely not a great process, and requires a lot of time investment to prepare but allows people from not so impressive backgrounds to get a fair(ish) shot.
WalterBright 5y ago
Ah, the perennial HN topic. The trouble is, it is simply not possible to objectively evaluate people without having false positives and false negatives. Not accepting this leads to endless debate, grief, lawsuits, and miscarriages of justice.
- isbvhodnvemrwvn 5y ago
  Not to mention that different candidates have different preferences, and different companies have different needs.
skc 5y ago
I've never understood why techie interviews aren't simply replaced with the sort of discussions programmer co-workers have amongst themselves daily. I've taken to honing on a candidates CV that might say for example, experience with Vue and React and simply ask them to compare the two, what do you like about one over the other etc. Or have a look at the projects they've worked on and ask them how they solved problem X and why that particular approach rather than Y etc. Being this casual I feel that you get a really good feel for how someone works, how they think, how they approach problems and most importantly how well you might get along with them day to day as you work together. They end up being much more relaxed and honest. I have a hard time believing that someone incompetent can slip through the cracks this way. Hasn't happened yet.
- alfiedotwtf 5y ago
  Studying for 100+ hours and doing 3 full-day interviews in groups and one-on-ones must be a Silicon Valley thing. Which is understandable given how many potentials would do the pilgrimage each year to join a pre-IPO. It's the 2021 version of the gold rush. Compare that to Melbourne (Australia). Every interview has been how you've described. I've had interviews in cafes, restaurants, pubs, and food courts. All informal chats, and only remember one white-board interview that went for about 3 hours. Thinking about this more now as I type this reply, clearly, the interview over lunch doesn't scale so making candidates run gauntlets for Valley jobs actually sounds logical.
- azangru 5y ago
  > I've never understood why techie interviews aren't simply replaced with the sort of discussions programmer co-workers have amongst themselves daily. Because of an attempt to standardize the questions so as to rank candidates based on their answers? Notice how many times the word bias pops up in articles complaining about the interview process? Bias this and bias that? Well, having a freeform chat with a candidate is just inviting bias.
- watwut 5y ago
  > I've taken to honing on a candidates CV that might say for example, experience with Vue and React and simply ask them to compare the two, what do you like about one over the other etc. Or have a look at the projects they've worked on and ask them how they solved problem X and why that particular approach rather than Y etc. The most lazy programmer I ever seen, to the point where he rarely finished anything and where everything took absurd amount of time excelled in these. There is sort of person who is smart, reads blogs/hacker news/journals a lot, have all the right opinions and can theorize about this or that solution easily. Everyone, especially developers, who was not on his team thought how genius he was. (Imo, largely because he is also completely immersed in tech-culture projecting all the correct work not related social signs of genius developer. )
stiray 5y ago
I am developer for 30 years with experience from whole stack, from kernel modules/windows drivers to the js (which I must say, I avoid as much as possible, currently experimenting with webasm). One startup, had three interviews, once I have started to describe the project I have worked and some background has issued a personal memo to hire me immediately, second one gave me to implement filesystem traversing recursion, the third guy... ... now the fun begins. Described me a case of huge volume of http data and how would I load balance them. "hm, ok, huge amount of data, lets propose the DNS based load balancing, you can still do proxy based load balancing on entrypoints". The counter answer was that do I really think this is server side solution, once I have described it to him, he said that he doesn't agree and that DNS load balancing is client side based solution. And I was out. Got new job in two weeks. With one hiring interview, no stupid programming tasks, just some talking what I was working before. And they raised my sallary twice in 6 months. I think that this nonsense with tech hiring must stop. It is damaging the companies that are looking for good engineers as they only get engineers that are worse that their existing engineers. The classic old story A people hire B people, B people hire C people,...
archydeb 5y ago
The links in this piece are broken for me, DOI not found (in case the author is lurking)
MontyCarloHall 5y ago
One big issue with tech hiring is that the vast majority of the interview pool consists of terrible candidates. Good candidates get callbacks for (almost) every job they apply for, choose to interview at a few select companies, and get offers from most of the places they interview at. Thus, they’re only briefly in the interview pool. On the other hand, terrible candidates are constantly getting rejected at every step of the process, and must continually re-insert themselves into the interview pool, and thus comprise the vast majority of interviewees. Because of this, the interview process is not designed to efficiently handle the minority of qualified candidates, but rather efficiently weed out the majority of horrible candidates. It is therefore a terrible process for the people actually qualified to pass it. (Note that the majority of the interview pool being terrible does not mean the majority of programmers are terrible. Assume 80% of developers are great, and 20% are bad. If the great 80% of developers only need to interview at one company to get an offer, while the bad 20% need to interview at 10 companies before either getting an offer or giving up, then only 0.8/(0.2*10+0.8)=28% of actual interviews will be with qualified candidates.)
- tomp 5y ago
  Interesting, my experience is the opposite. I find various leetcode and "software architecture" questions extremely hit-or-miss, and my experience interviewing is, either I fail at the very beginning stages (CV review or first 2 interviews), or get to the end (offer stage). The very bimodal distribution is inconsistent with both options in your hypothesis (i.e. either the "terrible" or the "good" candidate).
  - trhway 5y ago
    >The very bimodal distribution is inconsistent with both options in your hypothesis (i.e. either the "terrible" or the "good" candidate). it is completely consistent. When you fail at the very beginning you're a "terrible" and when you get offer you're a "good" one. The "terrible"/"good" isn't innate characteristic, it is in the eyes of beholder ... err ... interviewer. Most places pride themselves on taking only top 1|2%, and thus most candidates at any given place are "terrible" by definition, and thus the interview is built as the filter described by GP. Of course everybody hiring top 1% means that pretty much anybody would get to be a "good" at some place.
darthcloud 5y ago
Another anecdote: I'm mostly doing embedded C and I always fail leetcode tests and get my jobs when the interviewers endup valuing more the conversation where I can easily talk about past experience about real world problem I solved or the many time I went to a factory floor debugging embedded system live. I was working for startup company a few year ago that didn't had yet their leetcode process setup. This startup had an algorithm team working on signal processing and the embed team that pretty much took their python algo and translated them in either C or ASM for some special accelerator + the typical board bringup. Before using leetcode with new candidate they asked for some volunteer in the team to try it out. I did the test and failed miserably as always. My boss called me to his office and told me, your one of my best guy but you did the worst in the test. I told him this test is probably good for hiring someone for the algo team but for embed it's not relevant at all to the kind of problem we work on. My boss did some research and found a test targeted at embedded programming. I did the test and got best score in the team (equal with one teammate). Test are good but you need the right one for the right position. Most of the time for embed job it's the wrong test.
- Traster 5y ago
  One of the problems with going primarily on past experience (and I've seen this happen a few times) is that there are some people who have a skill of just sort of hanging around whilst other people do the work. They can talk your ear off about the work and all the things involved, but they just don't do anything and when really pushed to do things they come up with just terrible solutions. I know one guy whose sole contribution to the codebase was to run an auto-formatter on every single repository. Those type of people can be very disruptive.
deleted 5y ago
[deleted]
commandlinefan 5y ago
> cause a lot of anxiety (which means the results aren't representative of on-job performance) Not that I disagree with the author in general, but surely he can't be suggesting that work doesn't cause anxiety itself?
lbriner 5y ago
A good top-tip from David Hansson was if you are not sure, pay them to produce something useful for the company, perhaps about a week's worth. Then you are seeing what they are really like to work with and what they can produce without expecting them just to do it for free. Much cheaper than losing your Recruiter's fee when they don't last 3 months.
- Taylor_OD 5y ago
  This is great and easy for companies that have great brand recognition and interested candidates like automattic and basecamp. This doesnt really work when people don't give a shit about your company and you're asking them to work for you part time on a contract when other companies are doing 1 or 2 and done interview processes. It also selects for a certain type of individual who has enough free time outside of their day job to do extra part time work for a week to a month.
mikelevins 5y ago
Laszlo Bock studied the predictive value of technical interviews when he was in charge of people operations at Google. He reported finding that they had zero predictive power. To put it another way, we should expect that picking names out of a hat would do just as well as Google's infamously rigorous interview process. If I recall correctly, this result is generally consistent with other attempts to study hiring with technical requirements. So if technical interviews have no predictive power, is there anything else that does? Yes: standardized testing. So why doesn't everyone use standardized testing? Well, it's a lot of work. You have to accurately identify personal attributes that are relevant to success in your business. They have to be things you can objectively measure. You have to encode them in a standardized test, or, failing that, find an existing test that measures something sufficiently similar to be relevant. You have to administer it in a way that preserves a reliable signal. You probably need to engage professional specialists if you really want it to work. At the very least, you need to get someone in who can ask the right questions about your business and your goals to identify some existing standardized test that will match your needs reasonably well. Maybe you don't think you can afford to do that. I mean, that basically means you can't afford to do better than random chance in hiring, but if you can't, you can't. So what do you do instead? Well, hiring is risky. A bad hire can cost your business a lot. Uncontrolled risk makes people anxious. Anxiety is bad for productivity. Anxious people want to increase their control--or, failing that, their feeling of control. So how can you feel more in control than by pulling names out of a hat? How about technical interviews? Maybe they don't have any predictive power, but they give you a very strong feeling of control. You control the candidate-selection process. You control the interview format and procedures. You decide the criteria, and who gets an offer and who doesn't. Sure, the end result may be the same as pulling names out of a hat, but the process is much more soothing. So technical interviews it is.
- handrous 5y ago
  > To put it another way, we should expect that picking names out of a hat would do just as well as Google's infamously rigorous interview process. If I recall correctly, this result is generally consistent with other attempts to study hiring with technical requirements. The notoriously-drawn-out-and-draining interviews that practically require at least some study in advance, and probably quite a bit, strongly affect which names are in the hat though, no? I'd assumed that was about half the reason they did them in the first place (the other half is that hazing actually is pretty good at creating "team spirit" out of nothing)
nixpulvis 5y ago
Issue 7/N: Don't make me code in a fucking <textarea> box, or Google sheet, or otherwise. It's bad enough on the job, only even worse under the pressure of an interview.
clipradiowallet 5y ago
A tale of 2 technical interviews.. Interviewer: There is a file of 500,000 words. Some of the words are duplicated. I would like you to produce a report of the duplicated words, and the report should be sorted most-duplicated to least-duplicated. You can use any programming language you like. Candidate 1 spent half an hour writing a program in Java that accomplished the task. He passed, but was ultimately not offered a job. Candidate 2 spent approximately 10 seconds and typed `cat words.txt | sort | uniq -c | sort -gr`. He passed, and was hired. The moral is...sometimes a technical task in an interview is not to assess only your coding ability, it's also to assess your problem solving methodology. The person who used common user-space unix/linux tools didn't already have his mind locked into "writing a program to accomplish the interviewer's objectives" - he just used the lowest common denominator(the shell) that could accomplish the task he was given. It's not all algorithm memorization that counts.
- xenocratus 5y ago
  That's.... a really poor comparison, maybe you missed some background on what exactly the interviewer was looking for. Sure, maybe CLI knowledge is going to be useful, but if you're looking for experience with Java because you're going to implement some complex string filtering in it, then the 2nd candidate's solution is literally useless as a comparison point. Also, if you're comparing them directly you're essentially punishing the 1st developer for maybe not having experience with some technology that was particularly well suited for that question. Would you also have accepted a solution like "I send the file to someone on Mechanical Turk to find the words"? Or "I ask my daughter to look through them and find them"? Or "I ask someone in an interview to write a program to find it out"? Or "I paste it into this online tool that produces statistics of the most common words in some text"?
- dml2135 5y ago
  Isn't this also a case of just... having bash skills? I feel like your two cases are just programmers that have different toolboxes under their belts -- the second candidate does not necessarily demonstrate more problem-solving skills than the first.
- bgro 5y ago
cmollis 5y ago
it's all been said before here, but after working in IT for 30 years, I've literally forgotten more things that I've done than they could ever ask me. I've written threaded C++ code , built numerous IOS (objective C, Swift) apps for clients, written A LOT of java (many different app servers, most not supported anymore), Node, scala, spark, SQL (multiple dialects).. but I honestly can't remember most of the time how I did any of it (certainly not enough to regurgitate on a programming test). Headhunters are always amazed at the varied work that I've done.. but I've forgotten most of the low-level details which sucks because some of it was like 20 years ago. I've never been let go from any client, and I've been consulting continuously for big companies for over 25 years. But this is clearly not a sufficient for knowing answers to their specific question. I can't tell you offhand how to build depth-first-search, and I can't remember big O for most of the data structures that they would test me on). With three kids, I really have no time hack leetcode problems all day.. I completely understand that they need to filter, but I'm at such an odd place that it's hard for them to quantify my value because it may not line up to their identification process (which is also fair, I suppose). I somehow doubt that it's age bias, it's almost that I've done way too much and they can't rely on trusting that I'm not lying about any of it. I would have to interviewed by someone who puts the same value on my specific accomplishments with specific discussion around design, implementation challenges, etc. Not specific syntactical bullshit questions.. Most of the shit I look up anyway based on what the specific problem is. As someone else said, smaller companies tend to trust a little more in this area.. I basically learn what I need so I can solve their problem in the most performant way. I know I'm not an 'expert' in anything, but I've been able to quickly learn things and apply them so it accomplishes their goal. This isn't really 'testable' per se.. other than perhaps hiring on a trial basis and throwing some difficult problem at me. None of that is really scalable though. It's really a difficult problem.. the best guys I've worked with really didn't look good on paper. However, they always achieved the goals and worked well in chaotic, mostly unstructured scenarios where the goal wasn't well defined, and the technology choices suspect or basically untested. They figured it out.. 'figuring it out' under pressure is hard to quantify in an interview.
chrisweekly 5y ago
"Hire for strengths, not to avoid weaknesses." is the best advice most often ignored in tech hiring.
johngalt 5y ago
The problem with tech hiring is that a significant fraction of tech people are basically unskilled. Despite education and experience in some cases. Odds are either the interviewee is unskilled or the interviewer is. In the best case where you have a technically skilled interviewer and interviewee, there is still the problem of: 'the correct answer is my answer. Even if yours also works, it is not my answer.' Tech hiring is not difficult, but it requires the following traits in the interviewer: 1. Broad technical skills and the ability to recognize skills in others. 2. Ego is not driving them. No need to be smarter than everyone. 3. Conversational/interpersonal skills to get the interviewee to talk, and to recognize someone who will be a jerk. The common assumption is that skilled tech people lack interpersonal skills, but in my experience 1&2 is the rare combination.
- yks 5y ago
  > the correct answer is my answer. Even if yours also works, it is not my answer. That right there is probably what's actually wrong with the tech hiring. And that's why Leetcode, despite the disconnect of it from the real job, is actually better in my experience than free-flowing conversations "to gauge experience". There are only so many working answers to a leetcode challenge (p99 is less than 3) and yet there is an infinite space of things you can say in a conversation that will instantly bar you from passing the interview. And what's even worse, you can say the opposite things to 2 different interviewers at the same company and they will both disqualify you.
deleted 5y ago
[deleted]
seahawks78 5y ago
For me personally, I am still mystified by how subjective interviews like System Design/Behavioral are graded. E.g. if asked to design a large scale distributed system like Uber what would be the pass/fail criteria when calibration of responses is done w.r.t. YOE (5/10/15)? What would indicate that such and such is a good response for someone at Principal level but not so for someone who is at Senior level or vice versa.
rickeydidio 5y ago
I love it when I apply for a lot of jobs in one day, get a lot of rejections, then check the traffic on my GitHub and there’s minimal traffic. I guess at some point it pays off but it sure seems like climbing a mountain to get there.
rednerrus 5y ago
I ask potential candidates what the best project they ever worked on was. I explain that I'm going to use it as a way of gauging technical aptitude so please answer appropriately. Once they get started, I ask questions that make sense based on what the candidate says. In most cases you can glean enough of what a candidate can do by the depth and breadth of their answers. You can get a sense of how passionate they are, how detail oriented. You can ask about the problems they encountered, how they handled them, what they would do differently. What kind of notes did you take? What kind of documentation did you leave, etc.
geebee 5y ago
BTW, to whoever posted this, looks like a great article, but the DOI link is broken?

159 points by luu 5y ago

Referenced research paper: https://chrisparnin.me/pdf/interviews-HN.pdf https://chrisparnin.me/pdf/interviews-HN.pdf Only read it partially so far, but it seems interesting.

cjg 5y ago
It also refers to https://chrisparnin.me/pdf/Debugging-Hiring.pdf https://chrisparnin.me/pdf/Debugging-Hiring.pdf
renewiltord 5y ago
These are both great!

lifeisstillgood 5y ago

They reference Automattic's hiring process, which is an interview (90mins), take home coding (6hrs) and a paid project (40hrs). That essentially makes hiring a serial process for the candidate. All you are selecting for is people who really really want to work for you. I see software as a form of literacy. How do people hire writers?

yosito 5y ago
I think it's the 6 hour take home coding that's a problem. I would suspect that when hiring writers, they look at a sample of the writer's past work and don't require the writer to spend 6 hours writing a sample children's book.
- raxxorrax 5y ago
  Would be nice to have an example. 6h/40h software development doesn't really say much about scope and is highly dependent on your experience with the tools necessary to perform the task.
- thinkharderdev 5y ago
  The 40h paid project also seems kind of crazy to me. It is nice that is is paid but almost every software engineer I have ever interviewed already had a full-time job and was looking to switch. Where are they supposed to find 40h to work on a side-project even if it is paid? Is the idea that you are supposed to quit your current job first before interviewing?
  - aix1 5y ago
    > Where are they supposed to find 40h to work on a side-project even if it is paid? On top of that, taking on paid outside work in the same field could also be contrary to the candidate's contract with their existing employer[*]. [*] This no doubt depends on the employer and the jurisdiction.
    - lifeisstillgood 5y ago
      Of course !
- yawaworht1978 5y ago
  I had both a full day on site JS programming(css optional) and a 20hr take home reactJS exercise besides all the precious onboarding stuff, pretty crazy effort, for both parties, time is money. For one I had to take a day off, the other i did over a weekend. Another thing I have realized, all the jobs valued php and bit SQL more as basic knowledge for web dev than any nodeJS/MongoDB even if it's just front end, they want some back end understanding. Had some nodeJS things that generated all the front end via express , including chat module and sign up/log in flow, but either it was overlooked or not valued, any 5 minute to do list or crud with anything front end JS seemed more important. I suppose few dare to touch the node ecosystem and nosql databases. And the most recent one asked me if I can do their front end in react(really overkill, no need), told them I'll do it in vanilla JS, but nope, he insisted on react and that was the end of the story. Was for a MVP and would be the sole dev for a while. I have found in general that speaking to hr is not useful, if you get past that and a senior dev (not a manager or product owner) interviews me, it would be a good experience.
raverbashing 5y ago
As much as it is good they're paying you to take on a longer project, most people that are currently employed can't take this project without being in conflict with their current job. (Or even having time for it) I think tech companies are forgetting that firing people is an option.
- Nursie 5y ago
  Particularly in the contract market - I often see the process for taking on a contractor or consultant play out the exact same way as for an employee, forgetting that the interview process is very flawed and you can send the consultant home at any point you feel like with zero comeback. That said I’ve also seen companies pay contractors a month’s severance for no reason whatsoever too. A lot of places don’t seem to understand what they’re doing.
  - bryanrasmussen 5y ago
    my contracting contracts - in Denmark - often have a notice period but it is around 1 week to 1 month. I pretty much refuse coding exercises for contract work since it's so easy to get rid of me if you don't like it, and anyway as a contractor you get paid per hour so they should pay me for it. But sometimes there comes a place you really want to work for and they happen to have the coding exercise...
- FooBarWidget 5y ago
  No time? Can't people take vacation leave? Yeah it sucks that the time isn't spent on vacation, but you can't have everything in life without some cost.
  - Okkef 5y ago
    You are either a troll or don't have a family. If you do have a family i feel sorry for them. Life is not just about work.
    - FooBarWidget 5y ago
nxpnsv 5y ago
If you do one challenge, 6h is ok - I've even enjoyed these at times. But I'm sure it gets old real fast if you are on your 10th one...
- Grustaf 5y ago
  10 challenges is like two weeks of work. You probably studied for 3 to 5 years, and hopefully you'll work there for at least 2 years. Two weeks is not much, even if it is tedious.
  - isbvhodnvemrwvn 5y ago
    You assume that there is no alternative which is a better match and doesn't have this sort of hoops to jump through.
    - Grustaf 5y ago
      I don't assume anything, I'm only saying that even if you had to spend 2 weeks to get a job, that's not really anything to complain about. The vast majority of people spend way more than that.
      - zqna 5y ago
        Free advice: don't do "homeworks". It's an indication of poorly run and dishonest company, with incompetents at the helm. That's if you get the contract. Most likely you won't (because your are competing with desperate people who lie about their actual effort). Best is to stay out of it.
        Grustaf 5y ago
        I got my FAANG job through whiteboard interviews, but I definitely prefer homework, and I think that's a better method. But thanks for the advice.
Grustaf 5y ago
> All you are selecting for is people who really really want to work for you. Really really wanting to work there is a good start. If they can also finish the tasks in a competent way it would seem they are perfect candidates. What is the problem?
- isbvhodnvemrwvn 5y ago
  How many competent candidates are willing to jump through hoops like this?
  - Grustaf 5y ago
    I don't know, 23?
- lifeisstillgood 5y ago
  It seems Automattic is part of a select group of tech companies who are desirable as places to work, and have more high quality applicants than they can hire, and need to whittle down. That's great. And if I apply to one of those I really need to expect that. Now the company can be in this great position by being a world leading engineering organisation that is growing exponentially. Google, Facebook et al a few years back perhaps. But alternatively, any $RANDOMCOMPANY can think it is in this position not by attracting the best applicants globally, but by only hiring 3 people a year. The company still will get more high quality applicants than it can hire, so it needs to whittle down. But from the applicant side, applying to Google looks very different than applying to $RANDOMCOMPANY and they will drop in preference order. Taken to its logical extreme, each candidate will choose one company only to apply to based on the existing job pool and their expectations of getting the job. That seems silly.
fsociety 5y ago
46.5h to interview at a company? I’m not sure why cream of the crop developers would tolerate that over 5h of interviews. That sounds nearly predatory.
- andrew_ 5y ago
  I surely wouldn't do 6 hours of unpaid work. Not unless very desperate.

yellow_lead 5y ago

This article is very light and based roughly on the qualitative study linked in another comment. The study reads like a summary of Hacker News thoughts on tech hiring, which isn't much news to me.

zeckalpha 5y ago
The site is an aggregator of paper reviews, this review combined two papers and added relevant anecdotes not in either. > Short summaries of recent results in empirical software engineering research

bronlund 5y ago

I think the problem with tech hiring is the same as with a lot of problems in technology. The guys making the decisions just don't understand technology.

rcarmo 5y ago

I think most of what is wrong with technical hiring is bias and expectations: - There is always an age bias. Younger==cheaper in every single HR department in the world, but tech experience (and output) often increments faster than age. - Someone who’s spent a couple of years not coding because they decided to try management or consulting will get passed over because interviewers don’t really expect them to want to code anymore. Never mind if they actually consulted for and designed systems that are currently running in the Fortune 500. - Timezones and “meeting quorums” are very tightly aligned in some hiring manager’s minds. If someone can’t make half the meetings because they’re offset four hours, managers get antsy. - US/non-US is still a massive chasm. The first question I got from every FAANG interviewer was “when do you think you can relocate?”. And the pay differential is atrocious. Remote helps a bit, but the age bias will get to us all.

mettamage 5y ago
> And the pay differential is atrocious. I'm quite simple with this. I simply work less and lie about it. Unless I feel passionate, but then I don't view it as work. With that said, I do tell them upfront that I kind of work this way (I always say in interviews: pay me fairly and I'll treat you fairly, here's what I consider to be a fair wage. If they then lowball me and I accept because I happen to need the money, mayhem ensues. So far, 25% of the companies have met my salary requirements easily, all non-FAANG and local). Remote work helps with getting away with this. You get what you pay for one way or another. If I happen to get fired, so be it. I might want to consider switching careers then.
- WalterBright 5y ago
  > pay me fairly and I'll treat you fairly This might work for you, but I wouldn't hire someone who said that. It translates to "I'll only be honest if you are honest." I like to think that peoples' honor is not contingent on their estimation of the honor of their colleagues. My dad told me that the difference between men and animals is men have honor. We each get to choose which we are.
  - 5y ago

tester34 5y ago

Different approaches work for different people e.g People with family/kids would rather not do home-work tasks Some people would prefer to be asked about heavy job-related stuff e.g frameworks, kubernetes, real-life problems Some people would rather challenge themselves against foundational knowledge e.g because for them it may be faster to do 1-2 algo tasks or it being technology agnostic Some people would rather try designing systems, operate at higher abstractions levels instead of typing code ... I personally believe that I'd rather see security questions than algo/ds questions cuz poorly performing algo can always be rewritten, meanwhile leak cannot be reverted, but I'm aware that shitton of people would hate that How to match "interview kind" to candidate? maybe ask them which they prefer, I guess? but it assumes that you have people capable of performing this kinds of interview and you want to "enable" this person to peak

fredrb 5y ago
> How to match "interview kind" to candidate? maybe ask them which they prefer, I guess? I don't think it's a matter of candidate preference but rather position need. Some companies need Computer Science / Engineer mindset to solve complex problems. Some companies need XYZ framework developers to deliver customer projects. FAANG companies usually need the Engineering role and developed an interview model to select those. The problem is when companies that need developers apply the same interview mindset that Google does.

zivkovicp 5y ago

I insist on discussing salary range up front to avoid wasting everyone's time over the next couple of calls... also coding tests are a pain in the ass and as a general rule I don't do them. If I can walk someone through a project I've worked on and discuss it, or do a collaborative code review, that works, otherwise I thank them for the opportunity and move on. I don't get a lot of callbacks anymore since taking this stance, but that's fine. There's a reason why probation periods exist, and after a few years in the field, most engineers are able to adapt to a new code base just fine, it's the soft skills that interviews should filter for anyhow. my2c edit: typo

andrew_ 5y ago
I take exactly the same stance. I find that, while I'm not contacted for followups from places like LinkedIn and cold-contact recruiter emails, the approach does resonate with smaller companies that look to places like AngelList and Moonlight for their recruiting efforts. Tech recruiting has become a massive numbers, volume grift.

epicureanideal 5y ago

What’s wrong is the people in charge of most companies. They have money and connections but not much talent for actually managing the building of working things. And then they want to pay relatively little to the people who actually can build the things… while not knowing how to distinguish those people from the rest of the crowd. And of course, among the skills they lack is the ability to measure results and design effective compensation systems.

koevet 5y ago

I'm a freelancer based in Germany, been a freelancer for a long time (20+ years). Worked on a LOT of different projects in several (European) countries, as developer/architect/tech lead - whatever the client need was. Since my relocation to Germany, I decided to try the "no-tech-interview approach": does a client wants to work with me? Let's talk, for hours if needed, let's meet in person, whatever is required to make both parties confortable with each other. I'm more than happy to answer questions about my previous projects, how did I work on a specific solution or technology, which mistakes I made. But no technical interviews (as in whiteboard coding, riddles, take-home assignements). I have 25 years experience, I have references, I have code on github in several programming languages, I wrote a technical book. This approach has been working so far. Some clients still insist on doing a coding challenge or a classical technical interview: I politely decline and move on. There is no shortage of contracts, so I have always some lead in the pipeline. I would say that 50% of the leads are from me being recommended by people I worked in the past: this is obviously the value added of having lots of contracts under the belt. If I feel that my experience would not be a good fit for the project, and there is not enough time for a ramp-up, I would also decline. I do realize that this no-tech-interview approach would probably never work for permanent positions, especially when it comes to hire junior developers. Having said that, I strongly believe that the most valuable asset for a team is a decent person. Very few teams work on hard-problems, requiring super-specialized knowlege (say, AI for self-driving vehicles). The majority of technical skills can be learned, if one has the passion, willingness and humbleness to learn (and the employer wants to invest in the team - which, sadly, is often not the case).

wirrbel 5y ago
Someone I hire as an employee I want to have a good understanding of their capabilities, because - let's face it - letting someone go is not a good option esp. culturally in Germany (it would still be possible within first half year "Probezeit"). But I do prefer to hire someone that I am certain can contribute to the team for the next years. As someone who interviews, I can say that while there is a correlation between CV and coding skills, you do find regularly that really simple coding problems cannot be solved by applicants (slightly above FizzBuzz complexity). And for most applicants, there is no Github-Account. So I think its only fair to have some coding problems that don't overdo it of course for permanent positions. When you are consulting the situation is of course a bit different. The situation is temporary. Getting and verifying references is actually legal and possible. So I can definitely see that you get gigs this way (you'd also get hired without solving a coding challenge because many companies don'T do it actually). I just personally would feel much safer joining a company as an employee where I can be certain that my colleagues can at least code and have been selected with appropriate care.

wonnage 5y ago

I wonder if tech is unique in having an implicit mistrust for everything on the resume. I've worked at several large companies where people don't even bother looking at them before interviews. I blame the FizzBuzz blogpost (https://blog.codinghorror.com/why-cant-programmers-program/ https://blog.codinghorror.com/why-cant-programmers-program/) for making everyone deathly afraid of imposters. It's a masterpiece in ego-stroking - of course you can write FizzBuzz, look at all these sorry suckers who can't. Resumes are lies, only a 45 minute brainteaser on CoderPad can reveal the truth (ignore existence of Leetcode). In reality if I'm considering a senior candidate from FAANG (like, actually senior, not 4 years out of school), simply talking about past experience is perfectly fine. The work is the fucking same, everyone is migrating from legacy system X to a distributed system with zookeeper and kafka, they'll fit right in. It would take a truly psychopathic liar to fake their way through all the mundane details you could ask about a project like this. And if one slips through the cracks, they'd probably make a great PM anyway. (As long as they're on your side.)

Ekaros 5y ago
If they can't code just make them manage and bullshit everyone else in process. And hope they are smart enough to let people they manage to make important decisions.
rootsofallevil 5y ago
>I wonder if tech is unique in having an implicit mistrust for everything on the resume. I've worked at several large companies where people don't even bother looking at them before interviews. I blame the FizzBuzz blogpost (https://blog.codinghorror.com/why-cant-programmers-program/ https://blog.codinghorror.com/why-cant-programmers-program/) for making everyone deathly afraid of imposters. It's a masterpiece in ego-stroking - of course you can write FizzBuzz, look at all these sorry suckers who can't. Resumes are lies, only a 45 minute brainteaser on CoderPad can reveal the truth (ignore existence of Leetcode). While I agree with you on the whole, I have had interviewed candidates who couldn't code. One of them basically said that they would learn (CS degree but 4 years as a PM), which was fine but not what we were looking for. Another simply refused help and proceeded to bat their head against the brick wall of simply syntax. Didn't show signs of nervousness, panic, etc ... just seemed not to be able to code. In short, I think they exist (programmers that can't program) but they are the exception not the rule. >In reality if I'm considering a senior candidate from FAANG (like, actually senior, not 4 years out of school), simply talking about past experience is perfectly fine. The work is the fucking same, everyone is migrating from legacy system X to a distributed system with zookeeper and kafka, they'll fit right in. It would take a truly psychopathic liar to fake their way through all the mundane details you could ask about a project like this. And if one slips through the cracks, they'd probably make a great PM anyway. (As long as they're on your side.) I agree with you that an interview probing the experience of the candidate by getting them to talk about what they've done seems like a far better proposition. You will get a better idea of what the candidate knows, doesn't know.

willvarfar 5y ago

Young whippersnappers are going to downvote me for sharing, but I'm on the other side of the divide and have had to interview and be interviewed a lot over the years. The normal tech interview questions about sorting or recursion or whatever are not supposed to be business-relevant questions, they are to filter out people who simply can't program. The industry is awash with candidates with ok-seeming resumes, that get through HR screening, but then fail miserably at the tech interview to solve something like fizzbuzz. My anecdotal experience is that you never want people who can't write a for-loop or whatever in your team, whatever you are doing! The tech interview with the ludicrously simple questions are all about finding people who 'get it', and are actually effective at it. Which is why it persists. The good news is there are interviewers like me who have been lucky enough to be in the position to hire people on the strength of them being able to work through things in pseudo code even though they are not familiar with any programming languages. I keep interviewing and hiring physics grads on the strength of their excellent problem solving skills, and they all learn to express that in programming languages in short order once they are hired and they have found employment as a programmer...

jahller 5y ago
on top of that you will also filter out applicants who show some red flags when they not immediately know the answer to a problem. it's absolutely okay to not know everything. but there is a huge difference in how people communicate their lack of knowledge.
raverbashing 5y ago
If you're incapable of finding out who "gets it" without asking about fizzbuzz (which I'll point blank refuse to answer) or recursion/sorting, you're failing at interviewing. By the way feel free to try to write a sorting algo (preferably not bubblesort) by memory in your favourite language. It will be a good reality check. > My anecdotal experience is that you never want people who can't write a for-loop or whatever in your team Yes, you don't. But you don't need to ask them that directly, or have them code live.
- attil-io 5y ago

fredrb 5y ago

I recently switched jobs and got interviews in 5 big companies for mid/senior Software Engineering positions. All their processes were fairly similar: Two coding interviews, one system design interview and a conversation with the hiring manager. I might be biased because this process was beneficial for me, but here are my 2 cents on it: It's easier to get a position in a stack you don't have professional experience with. You're tested for your ability to learn CS concepts, not stack specific knowledge. All 5 positions I interviewed to had different technologies. If I had to learn the specifics of each before applying, I would likely not get offered any positions.

shahbaby 5y ago

I don't think there's anything "wrong" with tech hiring. It may not be ideal but every approach has its trade offs.

amir734jj 5y ago

My recent interview experience with Twitter: https://news.ycombinator.com/item?id=28466586 https://news.ycombinator.com/item?id=28466586

cwp 5y ago

Meh. There's nothing wrong with tech hiring. Ok, sure, there are some companies out there that don't know what they are doing, and the very most prestigious companies have to do some very tedious stuff to deal with the fact that their process gets leaked and people are willing to put a ton of effort into preparation. But mostly, it's pretty reasonable: - Little reliance on credentials, because there are many solid candidates that didn't go to top schools or don't have CS degrees or maybe didn't go to post-secondary school at all. - There's some sort of technical interview that asks the candidate to show they can do the work by doing a small amount of work. They usually let candidates choose the language and tools they'll use for this, offer help if the candidate gets stuck, let them look things up on the web, etc. This can take a few different forms, but it's inevitable given that credentials aren't reliable. - There's some sort of "behavioural" interview that asks about how a candidate collaborates and communicates with coworkers. Tech companies aren't looking for the anti-social genius anymore; software requires teamwork. - Recruiters are typically very accommodating of a candidates' circumstances. They'll tailor the pace and scheduling of interviews to the candidates' needs, fly them in from other cities, reserve time in interviews to answer candidate questions, and generally put significant and explicit effort into making the "candidate experience" as positive and low-stress as possible. - There's a lot effort put into eliminating biases, and interviewers will often do things like not reading a candidate's resume until after the interview, or writing up their report before talking with other interviewers about the candidate. Most tech companies really want to do this right. I think that what tech companies ask of candidates is quite fair. These are high-paying (sometimes very high-paying), high-prestige, comfortable jobs with lots of perks. The company puts a lot of time and money into training new hires before they're productive, and it'll be even more time before they can tell if the new employee was a good hire or not. In other words, the cost of hiring the wrong person is very high.

sinstein 5y ago

Counter take: After having worked for startups a lot, my CV did not really look very impressive. A couple of short-medium stints would not really instil a vast confidence to someone screening. Algorithm and "Trick" Coding Questions allow me to prepare for companies I would normally never qualify for just based on my past experience. If Google only hired people who have touched Google scale systems, they might not have a lot of people to choose from. Thanks to the current interview structure, I can spend some time and prepare for any large company regardless of the kind of work I have been exposed to so far. Its definitely not a great process, and requires a lot of time investment to prepare but allows people from not so impressive backgrounds to get a fair(ish) shot.

WalterBright 5y ago

Ah, the perennial HN topic. The trouble is, it is simply not possible to objectively evaluate people without having false positives and false negatives. Not accepting this leads to endless debate, grief, lawsuits, and miscarriages of justice.

isbvhodnvemrwvn 5y ago
Not to mention that different candidates have different preferences, and different companies have different needs.

skc 5y ago

I've never understood why techie interviews aren't simply replaced with the sort of discussions programmer co-workers have amongst themselves daily. I've taken to honing on a candidates CV that might say for example, experience with Vue and React and simply ask them to compare the two, what do you like about one over the other etc. Or have a look at the projects they've worked on and ask them how they solved problem X and why that particular approach rather than Y etc. Being this casual I feel that you get a really good feel for how someone works, how they think, how they approach problems and most importantly how well you might get along with them day to day as you work together. They end up being much more relaxed and honest. I have a hard time believing that someone incompetent can slip through the cracks this way. Hasn't happened yet.

alfiedotwtf 5y ago
Studying for 100+ hours and doing 3 full-day interviews in groups and one-on-ones must be a Silicon Valley thing. Which is understandable given how many potentials would do the pilgrimage each year to join a pre-IPO. It's the 2021 version of the gold rush. Compare that to Melbourne (Australia). Every interview has been how you've described. I've had interviews in cafes, restaurants, pubs, and food courts. All informal chats, and only remember one white-board interview that went for about 3 hours. Thinking about this more now as I type this reply, clearly, the interview over lunch doesn't scale so making candidates run gauntlets for Valley jobs actually sounds logical.
azangru 5y ago
> I've never understood why techie interviews aren't simply replaced with the sort of discussions programmer co-workers have amongst themselves daily. Because of an attempt to standardize the questions so as to rank candidates based on their answers? Notice how many times the word bias pops up in articles complaining about the interview process? Bias this and bias that? Well, having a freeform chat with a candidate is just inviting bias.
watwut 5y ago
> I've taken to honing on a candidates CV that might say for example, experience with Vue and React and simply ask them to compare the two, what do you like about one over the other etc. Or have a look at the projects they've worked on and ask them how they solved problem X and why that particular approach rather than Y etc. The most lazy programmer I ever seen, to the point where he rarely finished anything and where everything took absurd amount of time excelled in these. There is sort of person who is smart, reads blogs/hacker news/journals a lot, have all the right opinions and can theorize about this or that solution easily. Everyone, especially developers, who was not on his team thought how genius he was. (Imo, largely because he is also completely immersed in tech-culture projecting all the correct work not related social signs of genius developer. )

stiray 5y ago

I am developer for 30 years with experience from whole stack, from kernel modules/windows drivers to the js (which I must say, I avoid as much as possible, currently experimenting with webasm). One startup, had three interviews, once I have started to describe the project I have worked and some background has issued a personal memo to hire me immediately, second one gave me to implement filesystem traversing recursion, the third guy... ... now the fun begins. Described me a case of huge volume of http data and how would I load balance them. "hm, ok, huge amount of data, lets propose the DNS based load balancing, you can still do proxy based load balancing on entrypoints". The counter answer was that do I really think this is server side solution, once I have described it to him, he said that he doesn't agree and that DNS load balancing is client side based solution. And I was out. Got new job in two weeks. With one hiring interview, no stupid programming tasks, just some talking what I was working before. And they raised my sallary twice in 6 months. I think that this nonsense with tech hiring must stop. It is damaging the companies that are looking for good engineers as they only get engineers that are worse that their existing engineers. The classic old story A people hire B people, B people hire C people,...

archydeb 5y ago

The links in this piece are broken for me, DOI not found (in case the author is lurking)

MontyCarloHall 5y ago

One big issue with tech hiring is that the vast majority of the interview pool consists of terrible candidates. Good candidates get callbacks for (almost) every job they apply for, choose to interview at a few select companies, and get offers from most of the places they interview at. Thus, they’re only briefly in the interview pool. On the other hand, terrible candidates are constantly getting rejected at every step of the process, and must continually re-insert themselves into the interview pool, and thus comprise the vast majority of interviewees. Because of this, the interview process is not designed to efficiently handle the minority of qualified candidates, but rather efficiently weed out the majority of horrible candidates. It is therefore a terrible process for the people actually qualified to pass it. (Note that the majority of the interview pool being terrible does not mean the majority of programmers are terrible. Assume 80% of developers are great, and 20% are bad. If the great 80% of developers only need to interview at one company to get an offer, while the bad 20% need to interview at 10 companies before either getting an offer or giving up, then only 0.8/(0.2*10+0.8)=28% of actual interviews will be with qualified candidates.)

tomp 5y ago
Interesting, my experience is the opposite. I find various leetcode and "software architecture" questions extremely hit-or-miss, and my experience interviewing is, either I fail at the very beginning stages (CV review or first 2 interviews), or get to the end (offer stage). The very bimodal distribution is inconsistent with both options in your hypothesis (i.e. either the "terrible" or the "good" candidate).
- trhway 5y ago
  >The very bimodal distribution is inconsistent with both options in your hypothesis (i.e. either the "terrible" or the "good" candidate). it is completely consistent. When you fail at the very beginning you're a "terrible" and when you get offer you're a "good" one. The "terrible"/"good" isn't innate characteristic, it is in the eyes of beholder ... err ... interviewer. Most places pride themselves on taking only top 1|2%, and thus most candidates at any given place are "terrible" by definition, and thus the interview is built as the filter described by GP. Of course everybody hiring top 1% means that pretty much anybody would get to be a "good" at some place.

darthcloud 5y ago

Another anecdote: I'm mostly doing embedded C and I always fail leetcode tests and get my jobs when the interviewers endup valuing more the conversation where I can easily talk about past experience about real world problem I solved or the many time I went to a factory floor debugging embedded system live. I was working for startup company a few year ago that didn't had yet their leetcode process setup. This startup had an algorithm team working on signal processing and the embed team that pretty much took their python algo and translated them in either C or ASM for some special accelerator + the typical board bringup. Before using leetcode with new candidate they asked for some volunteer in the team to try it out. I did the test and failed miserably as always. My boss called me to his office and told me, your one of my best guy but you did the worst in the test. I told him this test is probably good for hiring someone for the algo team but for embed it's not relevant at all to the kind of problem we work on. My boss did some research and found a test targeted at embedded programming. I did the test and got best score in the team (equal with one teammate). Test are good but you need the right one for the right position. Most of the time for embed job it's the wrong test.

Traster 5y ago
One of the problems with going primarily on past experience (and I've seen this happen a few times) is that there are some people who have a skill of just sort of hanging around whilst other people do the work. They can talk your ear off about the work and all the things involved, but they just don't do anything and when really pushed to do things they come up with just terrible solutions. I know one guy whose sole contribution to the codebase was to run an auto-formatter on every single repository. Those type of people can be very disruptive.

deleted 5y ago

[deleted]

commandlinefan 5y ago

> cause a lot of anxiety (which means the results aren't representative of on-job performance) Not that I disagree with the author in general, but surely he can't be suggesting that work doesn't cause anxiety itself?

lbriner 5y ago

A good top-tip from David Hansson was if you are not sure, pay them to produce something useful for the company, perhaps about a week's worth. Then you are seeing what they are really like to work with and what they can produce without expecting them just to do it for free. Much cheaper than losing your Recruiter's fee when they don't last 3 months.

Taylor_OD 5y ago
This is great and easy for companies that have great brand recognition and interested candidates like automattic and basecamp. This doesnt really work when people don't give a shit about your company and you're asking them to work for you part time on a contract when other companies are doing 1 or 2 and done interview processes. It also selects for a certain type of individual who has enough free time outside of their day job to do extra part time work for a week to a month.

mikelevins 5y ago

Laszlo Bock studied the predictive value of technical interviews when he was in charge of people operations at Google. He reported finding that they had zero predictive power. To put it another way, we should expect that picking names out of a hat would do just as well as Google's infamously rigorous interview process. If I recall correctly, this result is generally consistent with other attempts to study hiring with technical requirements. So if technical interviews have no predictive power, is there anything else that does? Yes: standardized testing. So why doesn't everyone use standardized testing? Well, it's a lot of work. You have to accurately identify personal attributes that are relevant to success in your business. They have to be things you can objectively measure. You have to encode them in a standardized test, or, failing that, find an existing test that measures something sufficiently similar to be relevant. You have to administer it in a way that preserves a reliable signal. You probably need to engage professional specialists if you really want it to work. At the very least, you need to get someone in who can ask the right questions about your business and your goals to identify some existing standardized test that will match your needs reasonably well. Maybe you don't think you can afford to do that. I mean, that basically means you can't afford to do better than random chance in hiring, but if you can't, you can't. So what do you do instead? Well, hiring is risky. A bad hire can cost your business a lot. Uncontrolled risk makes people anxious. Anxiety is bad for productivity. Anxious people want to increase their control--or, failing that, their feeling of control. So how can you feel more in control than by pulling names out of a hat? How about technical interviews? Maybe they don't have any predictive power, but they give you a very strong feeling of control. You control the candidate-selection process. You control the interview format and procedures. You decide the criteria, and who gets an offer and who doesn't. Sure, the end result may be the same as pulling names out of a hat, but the process is much more soothing. So technical interviews it is.

handrous 5y ago
> To put it another way, we should expect that picking names out of a hat would do just as well as Google's infamously rigorous interview process. If I recall correctly, this result is generally consistent with other attempts to study hiring with technical requirements. The notoriously-drawn-out-and-draining interviews that practically require at least some study in advance, and probably quite a bit, strongly affect which names are in the hat though, no? I'd assumed that was about half the reason they did them in the first place (the other half is that hazing actually is pretty good at creating "team spirit" out of nothing)

nixpulvis 5y ago

Issue 7/N: Don't make me code in a fucking <textarea> box, or Google sheet, or otherwise. It's bad enough on the job, only even worse under the pressure of an interview.

clipradiowallet 5y ago

A tale of 2 technical interviews.. Interviewer: There is a file of 500,000 words. Some of the words are duplicated. I would like you to produce a report of the duplicated words, and the report should be sorted most-duplicated to least-duplicated. You can use any programming language you like. Candidate 1 spent half an hour writing a program in Java that accomplished the task. He passed, but was ultimately not offered a job. Candidate 2 spent approximately 10 seconds and typed `cat words.txt | sort | uniq -c | sort -gr`. He passed, and was hired. The moral is...sometimes a technical task in an interview is not to assess only your coding ability, it's also to assess your problem solving methodology. The person who used common user-space unix/linux tools didn't already have his mind locked into "writing a program to accomplish the interviewer's objectives" - he just used the lowest common denominator(the shell) that could accomplish the task he was given. It's not all algorithm memorization that counts.

xenocratus 5y ago
That's.... a really poor comparison, maybe you missed some background on what exactly the interviewer was looking for. Sure, maybe CLI knowledge is going to be useful, but if you're looking for experience with Java because you're going to implement some complex string filtering in it, then the 2nd candidate's solution is literally useless as a comparison point. Also, if you're comparing them directly you're essentially punishing the 1st developer for maybe not having experience with some technology that was particularly well suited for that question. Would you also have accepted a solution like "I send the file to someone on Mechanical Turk to find the words"? Or "I ask my daughter to look through them and find them"? Or "I ask someone in an interview to write a program to find it out"? Or "I paste it into this online tool that produces statistics of the most common words in some text"?
dml2135 5y ago
Isn't this also a case of just... having bash skills? I feel like your two cases are just programmers that have different toolboxes under their belts -- the second candidate does not necessarily demonstrate more problem-solving skills than the first.
bgro 5y ago

cmollis 5y ago

it's all been said before here, but after working in IT for 30 years, I've literally forgotten more things that I've done than they could ever ask me. I've written threaded C++ code , built numerous IOS (objective C, Swift) apps for clients, written A LOT of java (many different app servers, most not supported anymore), Node, scala, spark, SQL (multiple dialects).. but I honestly can't remember most of the time how I did any of it (certainly not enough to regurgitate on a programming test). Headhunters are always amazed at the varied work that I've done.. but I've forgotten most of the low-level details which sucks because some of it was like 20 years ago. I've never been let go from any client, and I've been consulting continuously for big companies for over 25 years. But this is clearly not a sufficient for knowing answers to their specific question. I can't tell you offhand how to build depth-first-search, and I can't remember big O for most of the data structures that they would test me on). With three kids, I really have no time hack leetcode problems all day.. I completely understand that they need to filter, but I'm at such an odd place that it's hard for them to quantify my value because it may not line up to their identification process (which is also fair, I suppose). I somehow doubt that it's age bias, it's almost that I've done way too much and they can't rely on trusting that I'm not lying about any of it. I would have to interviewed by someone who puts the same value on my specific accomplishments with specific discussion around design, implementation challenges, etc. Not specific syntactical bullshit questions.. Most of the shit I look up anyway based on what the specific problem is. As someone else said, smaller companies tend to trust a little more in this area.. I basically learn what I need so I can solve their problem in the most performant way. I know I'm not an 'expert' in anything, but I've been able to quickly learn things and apply them so it accomplishes their goal. This isn't really 'testable' per se.. other than perhaps hiring on a trial basis and throwing some difficult problem at me. None of that is really scalable though. It's really a difficult problem.. the best guys I've worked with really didn't look good on paper. However, they always achieved the goals and worked well in chaotic, mostly unstructured scenarios where the goal wasn't well defined, and the technology choices suspect or basically untested. They figured it out.. 'figuring it out' under pressure is hard to quantify in an interview.

chrisweekly 5y ago

"Hire for strengths, not to avoid weaknesses." is the best advice most often ignored in tech hiring.

johngalt 5y ago

The problem with tech hiring is that a significant fraction of tech people are basically unskilled. Despite education and experience in some cases. Odds are either the interviewee is unskilled or the interviewer is. In the best case where you have a technically skilled interviewer and interviewee, there is still the problem of: 'the correct answer is my answer. Even if yours also works, it is not my answer.' Tech hiring is not difficult, but it requires the following traits in the interviewer: 1. Broad technical skills and the ability to recognize skills in others. 2. Ego is not driving them. No need to be smarter than everyone. 3. Conversational/interpersonal skills to get the interviewee to talk, and to recognize someone who will be a jerk. The common assumption is that skilled tech people lack interpersonal skills, but in my experience 1&2 is the rare combination.

yks 5y ago
> the correct answer is my answer. Even if yours also works, it is not my answer. That right there is probably what's actually wrong with the tech hiring. And that's why Leetcode, despite the disconnect of it from the real job, is actually better in my experience than free-flowing conversations "to gauge experience". There are only so many working answers to a leetcode challenge (p99 is less than 3) and yet there is an infinite space of things you can say in a conversation that will instantly bar you from passing the interview. And what's even worse, you can say the opposite things to 2 different interviewers at the same company and they will both disqualify you.

deleted 5y ago

[deleted]

seahawks78 5y ago

For me personally, I am still mystified by how subjective interviews like System Design/Behavioral are graded. E.g. if asked to design a large scale distributed system like Uber what would be the pass/fail criteria when calibration of responses is done w.r.t. YOE (5/10/15)? What would indicate that such and such is a good response for someone at Principal level but not so for someone who is at Senior level or vice versa.

rickeydidio 5y ago

I love it when I apply for a lot of jobs in one day, get a lot of rejections, then check the traffic on my GitHub and there’s minimal traffic. I guess at some point it pays off but it sure seems like climbing a mountain to get there.

rednerrus 5y ago

I ask potential candidates what the best project they ever worked on was. I explain that I'm going to use it as a way of gauging technical aptitude so please answer appropriately. Once they get started, I ask questions that make sense based on what the candidate says. In most cases you can glean enough of what a candidate can do by the depth and breadth of their answers. You can get a sense of how passionate they are, how detail oriented. You can ask about the problems they encountered, how they handled them, what they would do differently. What kind of notes did you take? What kind of documentation did you leave, etc.

geebee 5y ago

BTW, to whoever posted this, looks like a great article, but the DOI link is broken?