5 ms·

Exactly this. In the interviews I give I care about whether the candidate can write code, yes, but also talk and think about code. The conversation is the most

• spyspy 2y ago
  Coding tests are an awful place to test someone’s conversational skills. I don’t talk while I code. You don’t either. Honestly I can’t even remember the last time I talked to anyone about the code itself outside of a PR. People talk about architecture and database migrations and why their containers aren’t behaving locally. Nobody ever tests for that stuff.
  • the_sleaze_ 2y ago
    If you're anything like me then you think a lot while you code, like inner monologue thinking, and that's what the interviewer is testing for.
    • 331c8c71 2y ago
      And vocalizing this inner dialogue comes naturally to you I suppose.
      • chessnerd42 2y ago
        If you can't explain your thoughts out loud then you're going to have a difficult time working anywhere.
        • simoncion 2y ago
          For me, it's not at all "I'm incapable of explaining this to you given a few minutes to collect my thoughts." and very much "You either get Coding Mode, or you get Conversation Mode, but not only do you never get both at the same time, I need time to context switch from one to the other.". The second paragraph in this comment is very, very, very close to how my brain operates: <https://news.ycombinator.com/item?id=40290732 https://news.ycombinator.com/item?id=40290732>. And I've been programming professionally for quite a long while now, so this quirk of mine doesn't seem to have made it difficult for me to work at programming shops.
        • DHPersonal 2y ago
          As I've gotten older I've discovered that I really can't judge normalcy based on what I find natural to me. Every brain is different and abilities range. Some people visualize things in their head; some people have to talk out their thoughts; some people are more optimistic. If we are only grading on one very particular brain type then we are missing out on the opportunities for diverse thought patterns producing something even better than expected.
    • IggleSniggle 2y ago
      This provided me with a fascinating, albeit somewhat familiar, piece of insight: which is that I don't really ever hear my inner monologue. I'm not sure I have one! I'm either typing out my thoughts as I have them or speaking them as I have them. I struggle in coding interviews precisely because of this: either I end up vocalizing my emotions and insecurities instead of coding, or I end up coding instead of talking about what I'm trying to accomplish. Often I will see many alternate pathways branching out before me, but if I try to start talking about them, I am no longer coding, and so my brain context-switches to "social and emotional." Probably something I could get better at with practice, but I honestly end up commenting on places like HN simply because it "allows" me to think. If I could have a coding interview in the form of realtime text chat + code, that would be ideal for me. I guess I have seen companies do things like "contribute to this open source project and work through an MR." I do find that quite appealing as an interview process.
  • deleted 2y ago
    [deleted]
  • bobthepanda 2y ago
    Personally I only ask super easy questions because you should at least be able to talk about something trivial. Yet unfortunately the question “find the second largest number in an array of numbers” has a high failure rate as the first question, because there are a lot of people lying on their resume just throwing spaghetti at the walls.
    • 6510 2y ago
      Thats to easy man arr.sort((o,O)=>o<=O)[1] One for you: Write a recursive function that finds the second largest number in an array of numbers.
      • 6510 2y ago
        https://jsfiddle.net/9ykxqw2t/ https://jsfiddle.net/9ykxqw2t/
  • bragr 2y ago
    It's not a test of someone's conversational skills, its a test of their technical communication. Conversational skills get tested in the small talk and introduction phases at the start and end of the interview.
  • feoren 2y ago
    > I don’t talk while I code. You don’t either. That's quite an assumption. You've never heard of pair programming? You've never asked for help on a bug in your code? You've never talked through alternate approaches to a piece of code with a coworker? You've never hashed out an interface or a method signature or some pseudocode while talking through the problem? You've never walked through a calculation with an SME? All of these are "code and talk at the same time" exercises. If I'm being brutally honest, I have a deep-seated suspicion that everyone who says they can't talk and code at the same time also just cannot code at all. I don't know you, of course, and I'd love to be proven wrong. My sample size is small, but the few people I've met who cannot talk-and-code also simply could not code.
    • deleted 2y ago
      [deleted]
    • _akhe 2y ago
      Here's my brutally honest take on pair programming: Usually 1 person wants to do it more than the other, and usually that person is being unnecessarily assertive. The only scenario I think pair programming is socially acceptable to force on developers is a senior type onboarding a new developer out of necessity - might screen share and direct them around some places to show the ropes. Of course if you love to hang out with someone else while you write code for some reason - more power to you, have fun. For me it's a private thing, even after 20+ years. If anything the LLM is a much more useful sidekick to figure things out. > Can't talk and code means can't code at all I disagree with that, I can't even have lyrics in my music really if I'm working on something super hard especially outside my normal wheelhouse. It would at least be disruptive. The last time "hanging out and coding" was a thing was learning it for the first time - I used to hang out with friends as a kid and we would all try to figure out what Visual Basic was lol and I remember hanging with a friend learning JavaScript during the early web days, drinking coffee through the night, good times. These days it would feel forced and can't imagine why anyone would regularly pair program, especially now with LLMs.
    • P_I_Staker 2y ago
      Lots of people in tech have never heard of pair programming, because it's an absurd idea. This site isn't just silicon valley. This is a tiny fraction of the tech universe.
  • greenavocado 2y ago
    > I don’t talk while I code. You don’t either. Speak for yourself
  • klysm 2y ago
    I consider taking while I code to be a somewhat useful skill. I’m totally capable of verbalizing my thought process as I work through a problem
    • _akhe 2y ago
      What's the quality of output like? Have any links?
• nox101 2y ago
  You are the exception I think. Most interviewers care about the correct answer. Get it and maybe get the job. Fail and definitely don't get the job. If the interviewer said at the beginning, "I don't expect you to solve this problem in the 40 minute nor to have an optimal solution. I just want to watch you write some code and hear the problems you foresee and how you'd solve them" then maybe I could relax and do that. But, generally the pressure is on "get this right in 40 minutes or you're rejected"
  • kyralis 2y ago
    This is actually why I dislike these "coding interviews are useless" type articles. The issue has as much or more to do with bad interviewers than it does with the fact that it's a coding interview. When I'm tasked with interviewing candidates and evaluating these basic algorithmic and coding skills, I have a 5-part problem (each building on the next, and only revealed when the previous one is complete) that is basically impossible to finish in the time allotted. I tell the candidate ahead of time that it's an ongoing problem that's designed to not be completable in the time: we're going to work through this problem and see how far we get. I've passed candidates who "failed" the actual problem, when the conversation and coding that were shown still gave me a good understanding of their capabilities.
• darrenkopp 2y ago
  I, personally, cannot _think_ and _talk_ at the same time. It's just a stream of half-sentences, many of which my brain has already moved on from because what I originally thought won't work. After writing this article it became very apparent to me that I'm complete garbage at interviews, but I'll outperform and exceed at the actual job function.
  • feoren 2y ago
    In my work, if you literally cannot write any code while also discussing the code, and if you literally cannot express thoughts while also thinking them, then you actually wont exceed at the actual job function, at all. You're not the only programmer on the team. I don't know why people think communication skills are not required for programmers. You won't be coding the correct thing unless you can talk about what you're doing. And that's all I ever ask in an interview. Ask questions and talk about what you're doing. The worst hires I've ever seen were all the ones who never asked questions and never talked about what they were working on. Half sentences are fine; moving away from the keyboard while we talk is fine; being unable to talk and think at the same time probably is not.
    • darrenkopp 2y ago
      If I'm not cut out to work in your environment, that's fine. I do disagree with your other conclusions, however. I'm not bad at communication, I'm bad at verbal communication while simultaneously trying to solve a problem. I'm excellent at problem solving and simultaneously chatting in something like slack, however.
    • BeetleB 2y ago
      > In my work, if you literally cannot write any code while also discussing the code, and if you literally cannot express thoughts while also thinking them, then you actually wont exceed at the actual job function, at all. Followed by > You're not the only programmer on the team. It sounds like you're implying some connection between the two, whereas most successful teams don't require the behavior your team is demanding. Including the ones with good communication skills. I can write code well. I can discuss it well. I simply don't need to do both at the same time. Unless people are in a pair programming session, they don't need to openly discuss the code while they're thinking about them and writing them. They can discuss the problem before and after. Why do they need to discuss it while coding? It's like telling journalists or authors "Hey, if you can't discuss your story with the editor while you are authoring it then you can't succeed here."
• xandrius 2y ago
  I would like you to be the interviewer of all my future jobs, please.
  • hansvm 2y ago
    The normal way to phrase that is "are you hiring?" :)
• kyralis 2y ago
  You are not alone! This is also how I run coding interviews - I have absolutely passed candidates who did not actually complete the described problem. I always inform my candidates that we want to have a conversation about the problem and its solution. I also deliberately pick questions that are going to need thought and some design, specifically to spark that conversation - talking about reversing a list gets boring pretty fast. The issues people have with coding interviews are more about the interviewers than the questions, honestly.
• darrenkopp 2y ago
  Adding another comment here, because this is part of the reason why I wrote this article. > These kind of articles make me sad because I (and many other interviewers I've worked with) try to make it clear that this isn't a test - we don't care so much about being "right" or "wrong", and there shouldn't be any tricks of "a ha" moments. > We explain the goals and what we're looking for right up front. And I would hope most interviewers do the same, but I guess not. So there's this persistent myth among both interviewers and candidates that coding questions are about getting a right answer. I understand all of those things. I've written the same before[1]. However, as clear as your instructions are and as well meaning you may be, it may not help. I can logically understand every word you say, but as soon as that question rolls out, I will now be dealing with stress hormones and 30 years of learned behaviors from thousands of experiences, whether I choose to or not. So while I applaud your methodology and wholeheartedly agree, just telling people that doesn't guarantee that it's not still an issue because humans are complex organisms. [1]: https://darrenkopp.com/posts/2016/02/25/always-learn-something-from-an-interview https://darrenkopp.com/posts/2016/02/25/always-learn-somethi...
• dclowd9901 2y ago
  Meh. I’ve met dozens like you. People who swear they just want to see “how you think.” Then, in the post interview roundup we talk about the candidates and you’re a bit disheartened that they didn’t complete the exercise, so you give a pass even when every other person in the room gives a thumbs up. Nah. Re evaluate yourself and your biases.
  • _akhe 2y ago
    My favorite question to ask these "see how you think" types when it's my turn is: What is the most impressive thing you've ever done? Just watch how they struggle with this one. I've never met anyone slinging code tests who is so curious in "how we think" that has ever made anything interesting whether it's code, design, music, a company, anything. It's just a pretentious statement made by gatekeeping noobs who love to interview, nothing more. I tried to save your comment lol
• bitwize 2y ago
  This is pretty much how it worked at the robotics company I worked at. We would give them a whiteboard problem, but: a) it was a simple, stupid problem in C (C++ was our implementation language, so thinking at byte level was an important skill) b) we were very generous about minor mistakes like missing semicolons, etc. c) we were very generous about "points for effort"; if they didn't make it through the problem but we saw that they were on the right track we might pass them. Total frauds outed themselves very early; they would produce between jack and squat in terms of actual code (a lot of bloviation though). But again, most companies aren't that company, or your company. For most screening coding exercises, a correct answer (and even something like optimal algorithm complexity) is a must to pass the candidate.