13 ms·

We need to admit that the interview process isn't about determining the relative qualifications of the applications in the pool, because we all know that 3 hour

• deleted 7y ago
  [deleted]
• bsbechtel 7y ago
  It's not easy to see in the moment, and sometimes an individual's options are limited (though this seems rare for senior devs), but why would anyone want to continue to create value for someone who holds biases against them that are hidden as not being a 'cultural fit'?
• aserafini 7y ago
  ‘Culture fit’ (without clearly specifying what that means) is such an enormous backdoor for all manner of bias and personal prejudice I’m surprised the concept is even legal.
  • ixtli 7y ago
    Completely agree. I've been lucky to have been surrounded by pretty reasonable people in my 8-10 years in the startup world on the east coast but "culture fit" was one of the rare situations that I got in a really impassioned arguments with my superiors. It's code that allows you to avoid hiring a guy who wears Fubu or has a Kentucky drawl.
  • kaesar14 7y ago
    What’s wrong with evaluating whether you’d get along with someone as a coworker? In my experience, being friendly and getting along has aided cooperation far more than hiring the most qualified candidate at the detriment of group dynamic. Yes, there are potential biases, but at a smaller company I’d say that’s a huge factor.
    • ixtli 7y ago
      I edited my top level comment for just this reason. Interpersonal communication skills are extremely important to evaluate for any position. But the person you're replying to is saying, correctly, that this isn't what people mean in practice when they bandy about the term "culture fit."
      • kaesar14 7y ago
        I see, yes, stereotyping based on some perceived “flaw” like accent is absolutely wrong and needs anti-bias training to remedy. It is tough though. I want people I interview for my company and team to get along with everyone, and trying to make that evaluation in a short amount of time can often result in immense bias. In the end, interviewing is fucking hard.
        • ixtli 7y ago
          No question. Personally I think the first and most important step is getting everyone in our industry to admit that they have deeply internalized biases that they're not likely to be fully aware of and that they have a real effect on important decisions. Once you've acknowledged that you can start to check yourself.
• skybrian 7y ago
  Saying they "can't tell you anything" is one-bit thinking. Yes, there is a lot that interviews don't tell you, but they are still a useful signal.
  • ixtli 7y ago
    Yeah that's fair. Im just frustrated with how low-bandwidth those things are. I definitely get a bit of a sense of how a person thinks by watching them do those CS 201-style problems, which isn't nothing.
    • jerf 7y ago
      If the CS 201-style problems annoy you, then... stop doing them? I don't ask algorithm questions, and I wouldn't even dream of asking brain teasers. I ask questions like "Here's a pile of text that claims to be CSV, let's explore how you'd generate an HTML report out of it", and branch out from there depending on how the interview goes. I've got all sorts of directions I can go from there, from screwing up the input in various real-world ways, discussing HTML security and injection attacks, algorithmic complexity of the report, how to build a service out of this, how we're going to handle reporting errors, there's just an endless number of ways you can take the interview from there. CS 201 doesn't usually come up.
      • rurp 7y ago
        This specific question is new to me but I like it a lot. I have found that the most useful interview questions are technical but more conversational than a white board, more about how to approach and solve a realistic problem. I think your method is a good high-signal approach.
      • ixtli 7y ago
        A little late but I wanna be clear that I don't ask them! I ask questions similar to you. My comments here largely come from my experience doing the interview problems. But yeah, i've tried to "be the change," so to speak.
  • 7y ago
• raiflip 7y ago
  Eh I see where you're coming from, and most interviews are this way, but I've definitely seen and organized interviews that eschew leetcode problems for very simplified every day problems, and at least imo they can tell you a decent amount. Have 3 or 4 of those in varying skills and you can get a pretty decent idea.
  • leetcrew 7y ago
    coding portions of an interview should probably be considered as like a bloom filter. it doesn't tell you for sure whom to hire, but it can certainly expose whom not to hire.
• padseeker 7y ago
  THIS - my experience with interviewing with startups has been very poor. Generally startups are staffed by younger people. Sometimes those people conducting the interviews are on their first or second job, and generally those younger coders have a tendency to emphasize things like obscure syntax for whatever programming language and the latest programming paradigms. It is overly language centric rather than dealing with how to solve problems. That is a terrible metric for the issue at hand "will this person be an effective at their job".
• on_and_off 7y ago
  >First of all, I want engineers that are good at working with others Yes ! The worst engineers I have had to work with were sometimes pretty skilled technically, but their ego or shitty personality was preventing them from being somebody the team could benefit from. I would have thought that it is why we have cultural fit interviews though. Personally I would sooner drop whiteboards than cultural fit interviews, but the later probably need way more training for the interviewer than what I got.
• otabdeveloper1 7y ago
  Absolutely untrue. Whiteboard problems absolutely do work. The vast majority of applicants cannot code at all. And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list. Worse is that these guys can be employed as developers (even 'senior' ones!) for years and years in 'serious' enterprises. How, you ask? By using copy-paste and cleverly navigating their enterprise processes and dodging responsibility. Maybe this is what you mean by 'being good at working with others', but it's definitely not what I want in a software developer. Source: I've interviewed a great deal of people for lots of positions over the years.
  • maehwasu 7y ago
    +1. I’ve interviewed senior guys, with medium to high salaries, who couldn’t do fizzbuzz. What’s worse, a lot of them were fully confident in awful solutions, and didn’t even want to test them. Talented people frustrated at the process just don’t get how bad bad coders are. I would never have believed it myself until I experienced it.
    • aetherson 7y ago
      I used to give a whiteboard coding interview (for a QA engineer position) that started with "swap the values of two integer variables. Yes, you can use a temporary variable," then went on to find the highest element in an array, then implement any kind of sort for an array, then implement depth-first-search. People who would ace the entire interview would look at me funny when I asked the first question, and I just said, "I mean, look: about 25% of the candidates fail this first question." Lots of others got partway through it. It is very true that you need to qualify someone's ability to write code at all. I think there's usually a lot less utility in some of the "clever" coding challenges that require you to remember some difficult-to-derive-from-first-principles data-structure or algorithm. But on the other hand, if we literally just give fizzbuzz to everyone, we'll eventually see people who have memorized fizzbuzz but can not create any other program. There's a real challenge to creating a coding problem that hits the sweet spot between "doesn't just test that you had a particular intuition," "does actually test real coding skills" and "isn't so common that people have memorized the solution."
• kstenerud 7y ago
  When I do whiteboard questions, I write in pseudocode. It takes some companies by surprise, but in the end they usually understand my reasoning: Whiteboards are for writing down algorithms and quick charts and other design-phase stuff, not writing compilable code.
  • kyralis 7y ago
    I explicitly tell candidates that they should use pseudocode. Nitpicking stupid syntax that the compiler can catch in a whiteboard interview is pretty pointless.
• rooam-dev 7y ago
  Culture fit is a thing, especially when working remote. You have to trust people you work with. Of course it can be abused.
• ddebernardy 7y ago
  I presume you haven't submitted candidates to a fizzbuzz test. Try it. The test is well known and out there in the wild. It's almost part of programmer culture. Yet it is absolutely shocking how many candidates that apply to jobs that involve programming will fail that simple test or some minor variation of it. Almost as shockingly, they will also fail to spot their bug after producing a solution that doesn't work as expected.
  • cr0sh 7y ago
    From what I gather, what is most shocking of all is that candidate still fail this test, despite it being so common, despite there being an several github repos devoted to it, as well as other pages and articles about it (somewhere out there was a page or a repo or something I encountered that had it written in almost every programming language out there, include whitespace and brainf*ck). Even when given as a "take home" challenge, they can't even copy-pasta an example off the internet...
    • falsedan 7y ago
      > include whitespace and brainfuck make part of the test a reverse question where the interviewers have to work out what language your solution is in 1:v!`*5*54p2*62*77,*5< v _@>v >v>:#<.>1+:2^ >:3%|>:5%|> 1#^_^ v"z"<pvv<"p :>v>v2,"-z2 "",8**,B5"* iF,622#"::4 "",,3*^<^<3 >^>^>^>,8#^6#*<
      • edoceo 7y ago
        I'll be using this one (or similar). Thank you
        • falsedan 7y ago
          ^_^
• jb3689 7y ago
  > We call it "culture fit" but we're really just trying to vet their personalities I've seen this end up in teams that lack diversity several times. My last company was big on interviewing for fit. Then a year goes by and you realize most of the people you've hired are a clone of everyone else. I had a co-worker that once argued that you can't judge people based on personality in an interview and I tend to agree with that now
• jiveturkey 7y ago
  way too cynical. We need to admit that interviewing is hard, and we aren't good at it. In fact, we don't need to admit it, we know it already.
• jaredklewis 7y ago
  All interviewing techniques are broadly disliked. A quick summary of complaints found on HN every time we discuss this (about once a week): - Whiteboarding: algorithmic knowledge not relevant to daily tasks, we have google, obtuse coding environment - Take home exams: companies have less incentive to respect time of candidate, favors candidates with lots of time to spend interviewing - Small consulting gigs: not practical for programmers with existing jobs, draws out job search - Informal conversations, reading resumes: not stringent, susceptible to talented bullshitters To be 100% clear, none of the above is my opinion, I am simply restating what is regularly posted at this online watering whole. A discussion of the failings of white-boarding without the context of alternatives is meaningless because interviewing techniques are search functions that all have precision/recall tradeoffs. That there are negatives to white-boarding is a given. For example, consider that white boarding interviews are short (3 hours). This naturally limits the company's ability to evaluate candidates (less precision), BUT it saves time for the candidate and company (more recall). So what happens here at HN every week is you get five people all bad mouthing a different interviewing technique, but we never get any closer to a consensus on a technique that would please even a simple majority of programmers (let alone everyone). TLDR; you don't like white boarding, so what about making a compelling case for something else?