[kwillets]

It's entirely bullshit, and I regret being on both sides. I used to do coding screens, but I feel like some moderate knowledge of syntax and a decent education is enough to skip the rest. The whole cargo cult of coding screens came up during the 00's when Google made it look important, and you're correct that it's largely an exercise to convince the team that they're special.

Software engineering is the science of avoiding coding! And the code that these elite teams produce is often pure shit anyways.

[hinkley]

The things they ask you to code too... anyone who would ever let you commit that code to the codebase isn’t someone you’d want to work with.

I’ve been trying to cook up plausible examples but it’s a challenge.

[d0paware]

Do any of the solutions I've personally suggested or mentioned here in this thread seem reasonable to you though? I was hoping we could at least talk about trade offs or pitfalls of various things people have suggested.

I feel like maybe I screwed up here with the thread since it got flagged early on for having Ask HN in it, and people responded with a knee-jerk reaction going straight to the comments section. Not sure if it's possible to get a mod to rename this and remove the Ask HN, I originally tried to paste in my content directly into the self-post textbox but 9k chars exceeded 2k chars.

[nwatson]

At my work we give coding exercises to interviewees with screen-sharing and give candidates lots of time and as much interaction as they want. The questions we pose are simple and do not require years of algorithmic experience and generally don't involve coding that couldn't be done by somebody with a couple of introductory software courses. Candidates choose their own programming language and environment.

The problems can be solved naively with a straightforward solution, or much more optimally after some further considerations.

The approach is absolutely not b.s., and we observe:

* some candidates completely misunderstand the very straightforward problems posed and their solution has no hope of addressing the issue

* some candidates have a rough idea but can't write the two nested for-loops required, for example, for the naive solution to one particular problem

* some candidates don't ask for clarification or confirmation that they understand the problem correctly even when they'd benefit -- others do and make better progress

* some candidates don't consider the full range of allowed possible inputs for the problem statement and assume the happy path always ... this is plenty forgivable, but when this is suggested or pointed out, some candidates find an easy way to resolve, others jump through interminable hoops to address, and others have deficit in communication that doesn't let them discuss the issue

* when discussing perceived flaws in implementations, some understand the language used to discuss software, others have a hard time communicating or answering questions about their implementations -- e.g., when one candidate wrote a recursive function all of whose branches ended up calling the same function recursively and we asked "when will your recursive function ever stop?" in many forms, they could not see or understand the intent of our question

* some candidates misunderstand writing a solution addressing a particular test case vs a general solution

* a few candidates are able to see the more optimal solution and write a good second algorithm based on that approach

* very few candidates resort to stepping through code in their IDE, unfortunately, to see or demonstrate what happens

We've eliminated many candidates we feel would have been a poor match based on inability to understand requirements, consider all possible input situations, inability to write naive algorithms, inability to communicate effectively about interview problems. ( Note that we also let candidates continue addressing the problem as "take-home" after the interview if they show promise. )

One junior candidate we just recently hired in a South Asia office did quite well on the algorithms portion, but unfortunately did not know Linux/UNIX/macOS command-line ... and assumed she was going to fail that portion of the interview -- she'd worked only in Windows contexts before. We had pointed her to a Linux-in-the-browser site and we just asked her to Google/search for the solutions to the various fairly basic operations we asked her to perform on the command-line -- she was surprised we'd let her do that. She struggled through and found solutions, and that's exactly what we wanted to see. There's nothing that exposes a candidate's suitability more than an open environment with a problem to solve and opportunity to discuss.

[ronilan]

You have described a process that helps your company eliminate candidates efficiently.

Your company has become very good at finding what people are not good at.

Your company is not alone in that approach and this is exactly where the tech industry interview process fails.

It looks for the wrong thing.