Most active commenters

    ←back to thread

    Please stop the coding challenges

    (blackentropy.bearblog.dev)
    261 points CrazyEmi | 11 comments | | HN request time: 1.421s | source | bottom
    1. tga ◴[] No.42148125[source]
    So we should stop the coding challenges, stop LeetCode, stop whiteboarding, stop profiling candidates, stop asking for their GitHub page. How is hiring supposed to work then? Just post the contract online and the first one to mail it back gets the job?

    I like live coding challenges, something like a ~2 hour pair programming session, ideally modifying an existing project. I invest as much time as each candidate, while we are both exploring whether we want to work together.

    replies(7): >>42148151 #>>42148156 #>>42148186 #>>42148193 #>>42148420 #>>42150459 #>>42163152 #
    2. ◴[] No.42148151[source]
    3. MattGaiser ◴[] No.42148156[source]
    What is left is networking and referrals, which I suspect people also object to.
    replies(1): >>42148283 #
    4. gdiamos ◴[] No.42148186[source]
    I personally hire people I’ve worked with before and I know what they can do.

    If I can’t do that, I ask to see their prior work.

    Good programmers have usually written a lot of code. Having them walk through and explain it usually gives a good idea of what they can do and how they think.

    Sometimes you meet a programmer who only works on proprietary code and can’t share it.

    In that case I ask them to explain the design of something similar, and write a modestly sized example of a component of that system. Watching them in their own dev environment for 30 minutes usually tells you all you need to know.

    5. CharlieDigital ◴[] No.42148193[source]
    No, there are other ways, especially as AI coding assistants become more capable and developers can be more productive if they are able to leverage them.

    One approach that I've encountered (with a YC company) is that the first interview was actually a code review. One of the founders asked me to review some SQL DDL, some backend API endpoints. The DDL was missing some indices that were needed for the queries. It was using an integer ID field. The API endpoints were missing input validation, error handling, etc.

    I thought this was a GREAT way to start an interview that tested for depth of experience and platform/language knowledge.

    This actually inspired me to build https://coderev.app because the tooling for this felt like it would be clumsy for both the interviewer and it was certainly for me as the interviewee.

    But a lot of times, seeing a candidate's portfolio -- if they have one -- is probably even more insightful than any coding exercise. When I've been on the hiring side, one of my favorite things to do is to look through a candidate's GH and ask them questions about projects they've done, why they chose specific technologies, etc.

    6. makk ◴[] No.42148283[source]
    Yes, this is seriously flawed for other reasons but is the best way when you can.
    7. mrweasel ◴[] No.42148420[source]
    You could also, you know, talk to people, like we did before Google and the Silicon Valley bro-wanna-bes decided that coding interviews was the only solution.

    I've hired plenty of people without having coding challenges or any form of live coding. I've been happy with all of those hires. A former co-worker did some take-home coding tasks, which they'd then talk to the candidate about during the interview. I feel like those hires where worse in may ways, they certainly didn't stay around as long. That may very well be completely unrelated obviously.

    For years people have been complaining that exams aren't realistic, that some talented people just don't do well in an exam situation and we've mostly come to the consensus that this is correct and mistakenly filter out highly talented people. So why wouldn't we apply the same logic to hiring?

    If you're hiring for a specialist position some coding exercise can absolutely be in order, but I can't think of any reason to have them for a junior position. So I wouldn't recommend dropping coding tasks completely, but I'd apply them more selectively, otherwise you risk missing a number of really good hires.

    Part of it may also be that so many companies and interviewers are absolutely terrible at doing coding challenges, but do them anyway, because Google and Facebook do them.

    replies(1): >>42148835 #
    8. ryandrake ◴[] No.42148835[source]
    I admit I've been hired once from just a friendly chit-chat, but I can't see how this could be reliable. There are so many bullshitters in the industry, who, during character creation put all their skill points into Charisma. They are smooth talking, good looking, and have all those charming Ivy League mannerisms of an Investment Banker or Enterprise Sales person. And while they might not be able to be technically deep enough to fool an engineer interviewer, they will absolutely fool the director or VP who does the final screen and has the final say. These kinds of people flock to companies who don't do robust technical screens.
    replies(1): >>42150702 #
    9. ◴[] No.42150459[source]
    10. mrweasel ◴[] No.42150702{3}[source]
    I can see your point about the bullshitters being able to fool a VP, but in that case they wouldn't be doing the coding interview anyway.

    On the other side we're also seeing bullshitters that can ace any leetcode challenge, but not actually design anything of value or work well with others.

    There's probably not a one-size fits all, but if you're going to do coding interview do them well and understand many don't do well in these types of interviews because they don't see the value, or feel that their other skills are being ignored.

    11. em-bee ◴[] No.42163152[source]
    i had also good experiences with live coding. both as an interviewer and a candidate. you not only see a candidates skill, but also their way of communicating, and as a candidate if you are lucky to be interviewed by a future teammate or superior, you see how they will treat you when you need help working on something.

    i had this approach work even in china where people tend to be very submissive and afraid to speak up. i expected them to have trouble in the interview, but most candidates told me they felt very at ease even though they had never worked with a foreigner before.