7 ms·

> It's been obvious for over a decade after they built an interview process that is heavily biased towards those who recently took an algorithms class. What wo

• ken47 3y ago
  I've seen plenty of HN threads where good alternative processes were described. I'm not going to be exhaustive here: writing a program over a few hours that is reflective of the kind of work that the company actually does, coming up with and debating the architecture of a system, mock code reviews, etc. You might say these don't scale as well as standardized testing of university classical algorithms knowledge. The general response to that would be that if you're optimizing for scale, then you're not optimizing for quality, so stop the hype around Google only hiring "the best." It's telling that as Google has begun to regularly lay off engineers, they have also begun to deemphasize classical algorithms in their interview process.
  • deleted 3y ago
    [deleted]
  • okdood64 3y ago
    > they have also begun to deemphasize classical algorithms in their interview process Can you elaborate?
  • hn_throwaway_99 3y ago
    To your point, while I haven't interviewed with Google, don't they actually do a number of the things you're talking about (e.g. ask about system design or ask you to look at some existing code)? I'm guessing every interviewer isn't asking you some variation of "find a loop in a linked list".
  • trympet 3y ago
    At big tech companies, "writing a program over a few hours that is reflective of the kind of work that the company actually does" is not really a good, representative performance measure. Often times, you will be solving problems across multiple domains, outside of your area of expertise. You have to take on the role of PM, data scientist, SWE, researcher, etc. Internal restructuring of the company may even take you from working on backend web apis to distributed databases. It is expected that you re-acclimatize and learn quickly. Giving you a take-home test to write some CRUD app isn't necessarily sampling those same attributes. p.s.: also not a fan of classical algorithm style interviews. Clearly, they also have a bias.
    • ken47 3y ago
      > Internal restructuring of the company may even take you from working on backend web apis to distributed databases This is a stretch. It's unlikely that an interview process would test such disparate skills directly, and a competent company will avoid moving an engineer into a role that requires a drastically different skillset without separate verification that they can handle the new role.
    • stormbeard 3y ago
      > Internal restructuring of the company may even take you from working on backend web apis to distributed databases. This isn’t true. I’ve worked in multiple FAANG companies’ infrastructure orgs, including distributed kv stores, as a SWE. Anybody joining those kinds of teams are either specialists, very junior, or already had some kind of experience in the domain before joining. Recruiters that say stuff like “we want strong generalists… blah blah” are not the people who are sourcing candidates for these deep systems roles. It looks a lot like the ML roles.
• TheBigSalad 3y ago
  You really think this is the best interview process we can do?
• devjab 3y ago
  In Denmark we rarely perform tech interviews the way you Americans do. Part of this is because of how available education is, so virtually everyone who’s applying for a tech job comes with some sort of academic education, meaning that they’ve proven their worth to get it. I’ve worked a side gig as an external examiner for a decade now, I’ve got good confidence in anyone I haven’t failed. Another part is that tech interviews are often sort of useless. One of the most expensive mistakes you can make as a manager is to hire the wrong person. Even in Denmark where it’s relatively easy to let a new hire go within the first three months, you’ve still invested an enormous amount of resources into the process as well as the impact a wrong hire will have on team moral. So what we look for first and foremost is cultural and personal fit within the team you’re supposed to be working in. We’re far more likely to do some personality test on you than a technical interview, not because we believe those are a science or accurate in anyway but because they are great talking points to get to know you in a high stress situation. We do this because technical skills can also be taught, and regardless of your background, we’re going to have to “adjust” you into the way we work. We may ask you some technical questions, but they’ll typically be on a more theoretical level than practical because we want to know how you think about tech. Again to see if your “ideological” fit is good rather than to test your technical prowess. In my anecdotal experience this is a far better process than technical interviews. But it is made possibly by education, precious work experience and the fact that if you really turn out to be terrible then it’s “free” to let you go. It also requires direct managers and often team members to handle the process with HR on the sideline, rather than HR handling the entire hiring process… but I can’t imagine working for someone I’ve never met.
  • pb7 3y ago
    What are some noteworthy Danish companies that have created innovative products?
    • manuelabeledo 3y ago
      This has nothing to do with hiring processes.
      • 3y ago
• xtracto 3y ago
  I've been interviewing people for Software Eng jobs for more than 10 years an I haven't used leetcode style problems for like 8 of those years. Leetcode interviewing is lazy interviewing. It's for when you don't want to put an effort in your interviewing process to check if the candidates have the skills you need for the position you are filling. For example. My interview process nowadays is one web API interaction challenge: Https://challenge.bax-dev.com (in Spanish, so you may have to do a Google translate. Use with curl) In that untimed challenge the candidate submits their code and email. They arrive to my email and I check the code quality of submissions with my morning coffee. Then in the ONLY 90 minutes Interview with me, we talk 30 mins about experience in their resume, 30 mins about our company and the position, and we code the "server" side to the web client they created . We do it pair programming style. The questions I achieve to answer are: would I pair program with thus guy? (Like, is she cool to work with?) And does she know what she is doing? I've had very good results with this method. And, from the code exercises I am sure anyone can guess what skills am I looking for. There was a great circlejerk on reddit in one of the outages where people asked whither Google engineers have inverted enough binary trees to bring their systems online. Basically saying that the skills they hire for are for Algirithm competitions, not for building enterprise software. And I say this as a CompSci PhD who did his good share of data structure and algorithms during my time in academia.
  • htrp 3y ago
    stealing your interview method, this is an amazing idea.
  • mista2nith 3y ago
    .... if I use this will you sue me? This should be the standard wtf
    • xtracto 3y ago
      Lol not at all. I am actually part of a group of CTOs in my area and I know of a couple of people that have "copied" the method one way or another. For all I care I am happy for people to copy it. That's the type of process I would like to have. So who knows, maybe later I'll be applying for your company, and nothing better than following a process that I enjoy (or at least is not as asinine as the leetcode/whiteboard algorithm crap)
• CoastalCoder 3y ago
  (Sorry for the meta-question, but I'm not sure where better to post this.) There's a sibling comment by @xtracto that's marked "[dead]", but IMO shouldn't be. Is there any normal means of appealing that status without bothering the admins?
  • mh- 3y ago
    You can click into the comment and then hit vouch if that is available to you. It's near the flag link.
    • CoastalCoder 3y ago
      Ah, thank you. I assumed that if I was able to vouch for a comment, I could do so from the tree view.
• saiya-jin 3y ago
  Have you actually every talked about code and architecture to another peer? If levels are cca same it quickly becomes an effortless exercise where ideas flow quickly and topics are immediately picked up. Lets call it brainstorming. Why can't we repeat that in interview? I don't care if some dev can code some method names or detailed algorithms from his head, when it takes 3 seconds to find exact solution. In other words, there is little real added value from such a skill. You get much better peek into somebody's head with above - but it requires significantly more effort on interviewee's side, heck maybe even some preparation. You can to certain extent hack leetcode process by just doing leetcode. Its much harder to be verbally fluent about designs, concepts and libraries that you never used. And for the rest, there is a trial period, you can't skip that 3 months experience and cram it into interviews.
  • hiq 3y ago
    Are you referring to system design interviews, or are you describing something else? System design interviews are commonly used along with leetcode interviews, especially in senior roles.
• renewiltord 3y ago
  You are absolutely correct. This discussion is pointless. When you have a 10k org you cannot allow ad-hoc methods because there are unscrupulous actors: people will sell the job, there will be nepotism, and discrimination. Hiring at scale with some bar of quality needs industrial processes. That's a real constraint of the system. Any alpha gets ruthlessly optimized away. Referrals? Now sold for split. GitHub Open Source? Now produced for cash or undifferentiated slop. People who don't run large orgs don't get this. But also many people who run small orgs don't get this: you don't need to run large org machinery for small orgs. Part of the advantage is agility. Part of the advantage is that everyone is still on the same page and that it's obvious when they're not. So big orgs have no choice. Small orgs have no need.
  • HarHarVeryFunny 3y ago
    > Hiring at scale with some bar of quality needs industrial processes. Sounds kinda logical, but is it really? It's not like BigCorp only has one guy doing the interviewing for 100's of positions. You're interviewing for a job on a team regardless of company size, and presumably what matters to them is whether you are a good fit for the need they have on their team, not whether you pass some industrial scale screening test.
• yterdy 3y ago
  >What would you do instead? Encourage a competitive market environment where there aren't just a handful of polarized "make it" companies that everyone is applying to regardless of fit or career objective because landing a job there is a golden ticket?
  • hiq 3y ago
    That still doesn't mean the interview process would be any different in this different market environment you're describing.
    • yterdy 3y ago
      Maybe. More opportunities for job-seekers to get a Good Job might make any given selection process less cutthroat, though.
• manuelabeledo 3y ago
  > How would you assess them better than current common processes like leetcode interviews? OP said "just about every other skill that is needed to be a good software engineer", for which leetcode is useless. Communication skills, organizational skills, hell, even general knowledge isn't covered by leetcode-like interviews. Personally, speaking as someone who doesn't like but has to interview potential hires, I have found that there is zero overlap between people doing well in leetcode interviews, and hires doing well in their first year. > If one could do better hiring at the same cost or less, the whole industry would be interested I think this is a naive perspective. If there is any takeaway from the recent wave of layoffs, it would be that company wide decisions may be driven by factors that have no relation with actual financial performance. Google could have kept all these engineers and still make an absurd profit. The notion here is that some company, at some point in time, started putting their applicants through these kind of puzzles, and it became trendy.
  • hiq 3y ago
    AFAIK communication skills are routinely evaluated in those interviews: if you have the best code but can't explain how it works, you won't score highly on them. You should be able to discuss tradeoffs, how you reason, etc. They clearly don't help to evaluate organizational skills, but no one said you should only have these interviews. I'm guessing no company does only leetcode-style interviews, at least I don't know of any. > I have found that there is zero overlap between people doing well in leetcode interviews, and hires doing well in their first year. You could only evaluate this correlation among people who did pass your leetcode interviews and were thus beyond a certain bar, unless I'm missing something. The question is whether selecting according to this bar is useful, but it doesn't look like you evaluated this. Or did you do leetcode interviews and just hired anyone regardless of how they performed in them? I agree with you that beyond a certain bar, the signal becomes lesser. But being able to tell whether a candidate can write a for loop is a pretty strong (anti-)indicator for many SWE jobs. > The notion here is that some company, at some point in time, started putting their applicants through these kind of puzzles, and it became trendy. I agree that there's probably some of that. But companies are made of people, and if so many are still doing that decades now after they started and don't see a competitive advantage in switching, maybe it's the best they've been able to come up with, given their constraints. Again, there's real money to be made for those coming up with an alternative that'd scale and perform better.
• karaterobot 3y ago
  "Yeah, it sucks for everybody and it doesn't work very well, but it scales!" Not picking on you, this is a very common refrain. The apparent advantages of scalable processes seem to trump the demonstrable disadvantages, especially in hiring. The end result is a system most people acknowledge flat-out sucks, it just flat-out sucks in bulk. We say "hiring the right people is the most important thing we do, so let's mechanize it and spend as little time-per-unit as possible". I find it more sad than funny.
  • hiq 3y ago
    I think absolutes like "it sucks" are rather unhelpful when you need to choose something anyway, so it's not like doing nothing is an option. What would help is a clear alternative and how it does better one certain metrics while satisfying requirements. Yes scale does seem to be a constraint for big companies using this process, among other requirements making the whole leetcode process appealing. It's not only about costs.
• stolsvik 3y ago
  Code reviews. Some “interesting” code, which actually work, but which is inefficient in multiple ways. Dig deeper and deeper. Architecture suggestions for a relatively simple problem, discuss the suggestions.
• voidhorse 3y ago
  The heart of the problem is that people hiring for software engineering roles think hiring is all about "what you know". It isn't. To hire a good candidate, hire for "who you are" and "who you can become". You want to hire learners not "experts" (read: someone versed in the methods that are about to be obsolete). Hiring is always more about adaptability and soft skills, no matter what role you're hiring for except in very specific, usually time-bound circumstances. This is why true specialists are either on contract or are consultants. Most of the tech industry does hiring completely wrong because, as usual, most software engineers are hyper literal, narrow minded, and lack the social insight required to be effective on a fundamentally social problem.