Hacker News Reader

Comment by ladberg | Hacker News Reader

Design mistakes maybe, but syntax errors are just not representative of any real debugging experience IMO.

I think some of this is filtering out bullshitters. In a previous job I used to interview a lot of unfiltered candidates. What we did was sit them down at a Linux command line and ask them to show us the files in the directory, open a file for editing and that kind of thing. A surprising number of people who claimed years of Linux experience had clearly never used the command line at all.

I've tried questions like this (super basic but can quickly filter out people who know nothing), but sometimes the candidate seems insulted! I try to quickly move on to a harder question.

If you start with "I'm sorry if you find this question offensie, but recently we had a wave of candidates who had problems with basic things so we need to start from the beginning" and the candidate still feels offended, well, they're being offended too easily which might cause problems in the future.

I don't think the problem is offending the ones who know how to do things. It's making them think they're applying for a worthwhile job.

I remember thinking what you're writing about there, that there's a lot of people to be filtered out, and that good candidates wouldn't be offended.

So we had this simple two-part quiz question for people, starting with "what is the expectation of a dice roll?". Amazingly a lot of people can't figure this out.

But also a lot of people know the answer immediately and will wonder WTF you are asking such a simple question for. I remember this one lady who interviewed with my firm, the look on her face when she realized we weren't asking anything complicated. You could just tell she thought we were a bunch of amateurs, and she'd better be on her way to see some other proper hedge funds.

I think people can still find it off-putting that after all the evidence they provided you to get to that point, you're challenging them to prove they aren't complete frauds. Like you could has spent 30 seconds googling them and verify they are legit, but it seems you didn't even bother to read their resume. Not saying it's the case, but rather that not everyone is aware of how good the frauds can be at presenting themselves and bullshitting through interviews.

How did people like this even make it to the interview rounds

Sadly because in that disfunctional start-up we didn't pre-screen except to have someone look through their CV to check that boxes were ticked :-(

But I think the point in this thread is the Google question about Linux inodes was actually part of a pre-screen interview done by an outside agency.

I could see it if you're resume talks about a whole bunch of intense recent development in the exact same language they want to test, but only then.

In contrast, I've been stuck in a giant multi-language integration-fest, and... well, there are definitely languages on my resume that I would not be comfortable being pop-quizzed on, simply because I've been using others for the past two years.

I've been doing C++ full time since 1996, and yet I frequently have intellisense warning me about forgetting something silly - like a missing capture in a lambda, or even forgotten semi-colons. That's because I'm not an f'ing compiler.

_Can_ I make sure the code is 100% correct before even compiling? Sure, but I'll spend an hour checking every detail, while intellisense does it while I type.

I mean, yes. In a whole program, typos or mistakes happen. No need to try to prevent those. So do spelling or grammar errors when writing in English. We expect a professional writer to have a human editor to catch those and not be perfect. But asking an applicant for a writing job to find the spelling/grammar errors in a paragraph seems reasonable to me.

The simple fact that you think so tells me that you aren't a programmer, and that you should stay far away from interviewing or managing programmers. About the only thing the two situations have in common is that both are based around a text-based medium; for the rest there is just no comparison between writing computer code, and writing text for humans. Have you ever noticed how very few people can actually write both good computer code, and good documentation for the users of that code? That's because they are completely different disciplines, requiring a completely different mindset.

Let's turn this around: if I were interviewed by someone who flagged down my code for missing a #include or lambda capture (both very easy mistakes to make), I'd know that the people I'm interviewing with are idiots with no understanding of the thing they claim to be testing me on. Would I want to work there? Nope.

You seem very confused. At first I was worried you misunderstood my text: maybe you have trouble with natural language but not programming (or maybe English but not code). That would certainly explain your claim that they are disjoint skillsets. But as you went on, you committed a logic error, so now I'm just thrown.

There is a difference between "find the errors in this provided code" and "write code on a whiteboard with no errors". At no point was I talking about code you wrote.

Also, it's an aside, but I find people who can program well write excellent documentation for the users, if what they are writing is an API. Of course, they are not the best at explaining the steps in a GUI, but that probably has less to do with communication skills in general and more to do with the difficulty understanding how they perceive the problem.

Reply on news.ycombinator.com