23 ms·

Number 2: No One Believes Anyone Can Actually Code It's surprising to see the number of people who interview for lead technical roles that cannot code, or whos

• enraged_camel 8y ago
  Not all technical roles require coding skill. Unless you meant “lead software engineering role” in which case yes, you are right.
  • pg_bot 8y ago
    Yes, that is what I meant.
  • ataturk 8y ago
    Most of my day as a lead was on the phone putting out fires, not coding. I hated it and the politics and blame shifting that came with it.
• solaris999 8y ago
  This was the one that really stood out to me. MOOCs, bootcamps etc are wildly popular now and vary massively in quality. It's very easy for candidates to look good on paper but not actually know the technical side as well as they should. More importantly, software engineering is one of the few jobs where you can get a (somewhat) quantitative measure on prospective performance so it's natural to take advantage of that. I'm not saying that All Coding Tests Are Good, but they do provide a modicum of certainty in a very uncertain environment.
• lostcolony 8y ago
  Seriously. I've sat on the hiring side. I've seen impressive resumes. I've had reasonable discussions with people. And then I give them a very, very trivial coding exercise (a take home, they're free to Google, do it on their own computer, in their own IDE, in their professed preferred language), in a time frame that while constrained is still plenty...and the result is -terrible-. I can try and come up with reasons why that might be the case, why a simple OO modeling problem + a couple of trivial algorithmic problems (like, take an ascii string, return me a dict mapping characters to character counts) would trip someone up...but that isn't sufficient justification for me to want to continue to an onsite. And that's the people who get past the verbal screen. Plenty drop out at that point. "I see you spent two years as a Senior DBA. Can you tell me what the acryonym ACID stands for?" "No, I'm not familiar with that" "Okay. Well, the 'C' stands for consistency. Can you tell me what one means when we talk about data being consistent in the database?" "It means when you write something it stays written (or some other made up twaddle)" "I see." That said, I agree that coding tests that are completely unrelated to the job, and are geared toward college grads rather than long term developers (i.e., "Implement a (data structure)" or "Remember/discover an algorithm that was a PhD thesis 30 years ago to solve a contrived problem in a theoretically optimal way" rather than "Solve a real problem of a kind similar to what we'd expect you to do here") are dumb.
  • crdoconnor 8y ago
    It's weird, I've heard plenty of stories about this kind of thing but when I sat on the hiring side and interviewed for intermediate roles (couldn't even afford senior) I didn't come across anybody who was stumped and simply couldn't code. There were people who were bad at (possibly some because they were under pressure), it but nobody who couldn't do it at all. I wasn't giving out a trivial question either.
    • vonmoltke 8y ago
      Same here. I have given an interview to exactly one person who would fall into this category, though most have been bad coders.
    • psyc 8y ago
      I've given coding interviews for 20 years, and I'd estimate 9/10 candidates have been competent whiteboard coders. I don't have any explanation for the extreme discrepancy between my experience, and the "hardly anyone can fizzbuzz" folks. Of course this colors how I treat people. I'm much more inclined to interview seniors conversationally and judge competence by the way they talk about work they have done. I have a hard time imagining people investing the time to become conversationally fluent in a domain, as some kind of long con.
      • hermitdev 8y ago
        Beyond fizzbuzz, whiteboard coding is rough. Better to put someone in front of an actual computer. Space is constrained, hard to make corrections, some people (such as myself) have crappy handwriting...
    • ryandrake 8y ago
      It's such a weird hiring market. 1. There are a lot of imposters out there applying for programming jobs who can't program, and 2. There are a lot of very talented programmers out there who are being rejected by overly picky companies. Both can be true, and I'd argue that both are true. I don't know what the solution is. Current interviewing methods don't seem to be solving the problem. I'd suggest a widely-accepted professional certification could help a lot, like doctors and lawyers have with the medical board exam or the bar exam. Easier said than done, but what we have today, where the candidate pool is overflowing with impostors with great resumes is not working.
• d23 8y ago
  Yeah. In all honesty, I would prefer _more_ of our interviews be straightforward coding problems that are reflective of the job the interviewee is going to be doing. Not whiteboarding. Not pseudocoding. Not puzzle problems. Just: write some code, let's see how well you google when you get stumped, let's see how clean your code is, let's see how quickly you implement it relative to other people, let's see how well you document it, let's see how well you collaborate with the interviewer.
• haskellandchill 8y ago
  I feel like this is a myth, what do you estimate the figure is? I think under 10%, maybe under 5%. I have significant experience interviewing senior, junior, and mid-range candidates. 99% of my candidates can code, as in iterate over collections, write case statements, and call functions. I've only had one junior candidate who couldn't code at all. Sloppiness is rampant, but sloppy code that gets things done is what my company wants (not me personally).
  • chillydawg 8y ago
    It's not a myth. I see it when recruiting for my teams. My sample size is too small to give a proportion, but it's enough that not having tests would be a total waste of my and their time since I'd have to fire them on day 1.
    • deleted 8y ago
      [deleted]
    • Clubber 8y ago
      I'm amazed you can't tell an imposter just by talking to them.
      • twodave 8y ago
        The real problem is everyone looks like an imposter until you watch them code.
        • Clubber 8y ago
          I don't mean this the way it sounds, but if you can't tell if someone is an imposter by talking shop with them in your chosen profession, you probably shouldn't be doing the interviewing.
          • twodave 8y ago
            I think unless you're prideful enough to believe you can identify someone's level of productivity from a short conversation, it's probably better to see the proof. Again, why would I settle for a conversation when I can ask for first-hand proof? It's like a judge dismissing concrete evidence and just basing their verdict on the circumstantial. Sure, it's likely to be right most of the time, but what about when it isn't?
• vorpalhex 8y ago
  I understand that's a problem, but if I have an entire github of highly starred and heavily developed projects with reasonable commit histories... don't make me do your do damned homework or implement a toy BST. I have better things to do with my personal time than toy problems because you can't be bothered to open my github. The worst part is that usually these toy problems are justified with "but you can post this to your Github for others to see!"
  • twodave 8y ago
    I'm not going to speak to the homework type of problem (because honestly I think you should be paid for that sort of thing), but I always ask people programming questions in on-site interviews, not strictly because I want them to prove they can program (although that's one useful side-effect), but because I want to observe the candidate's problem-solving process. I can't deduce anything like that from your Github or a homework problem.
    • vorpalhex 8y ago
      And that is entirely fine. I'm all for group white boarding exercises, or pair programming. I think there's a lot of value to be had in making sure the other person can communicate in a technical setting effectively, and explain why they make choices. Likewise, if someone wants me to walk them through a project I have with explanations of what choices I made and why, I'm happy to do that. But please don't waste my time asking me to implement DFS, or write another twitter API client.
    • ryanianian 8y ago
      If the GH code is there, works, and is up to coding standards, why do you care about how the sausage was made? I'd look to see if the code is well-designed, organized, original, tested, etc. It's generally easy to see if the author of code knows how to decompose a problem into pieces. So..saying "we're looking for thought-process not the actual code" feels a bit disingenuous tbh. Now: If you care about being able to collaborate on a tough problem with somebody, work on a problem neither of you has seen before together :)
• mixmastamyk 8y ago
  The idea that no one can code is often a result of poor interview practices, i.e. coding trivia contests under the gun. Then misconstruing poor performance as coding ability.
  • hermitdev 8y ago
    At a former job, I had a set of simple, if contrived examples, that I asked. Programs were short, less than 20 lines; candidates were instructed that the source would compile unless indicated otherwise, in which case they were given the entire compiler output. I would ask fairly simple questions that would expose a lot about the candidates knowledge. Such as: if (~false == true) std::cout << "true"; else std::cout << "false"; In C++, what does this print? And if they answered correctly, I'd ask them to explain how/why. This question wasn't a deal breaker, but did immediately given an insight into their depth of knowledge of the language.
• notyourday 8y ago
  That is because over last few years it became extremely prevalent industry to make everything about "teams": projects are responsibility of teams, failures are attributed to teams, etc. It used to be that code won arguments. Now it is not ruffling feathers that wins arguments. If I'm not hiring the entire team, how do I know who in that team actually can code based on the result? What does it all mean? It means exactly what it meant in a high school/college group assignments - one or two people carried the group project but everyone took credit. I have seen hundreds of resumes where people claimed that they have done XYZ where through some side channels I know they just happened to be on that team but their contribution was limited to tweaking spelling. I see coding tests as one of the two ways to evaluate that someone can code[1]. I trust it. [1] The other way is that I know this person and I'm already aware what they can do.
• wnevets 8y ago
  Exactly. The number of people who can't do basic development going into interviews pretending they can is kinda crazy.