Hacker News Reader

Comment by ownagefool | Hacker News Reader

I don't think the problem is the format, i.e. a 30-50 minute interview on simple coding with DS&A problems, but the escalation.

The reality is, fizz buzz got us 75% of the way there. It turns out when pressed, a lot of people can't write code. Yes, there's false positives, but there's also people brute focing their way through via copy & paste.

This doesn't manifest as a person who can't do any task, just as a person that's slow, delivers weird abstractions, and would take a lot of your time to get anything useful from.

But those people are also making those arguments, because, as you said, there's hundreds of thousands of dollars in it.

View on HN

A lot of people couldn’t even read this thread if someone was watching closely. They’d recognize words and idioms, but couldn’t make sense of these or think. It’s called anxiety and rarely has anything to do with actual performance. Anxiety is a frequent guest in a smart guy’s home.

As an early 2000s integrator/analytics I learned to write code when someone watches out of interest or straight time pressure (still taxing sometimes). But most developers that I know intellectually curl up in such situation, regardless of their skill or performance levels. We worked with one very math-y low-level-skilled guy whom our clients described as “literally freezes for an hour without moving, should we pay for it?” when he did field work. He was a very strong developer otherwise.

Not that a company must hire or want these people, but the idea of writing code under uncanny pressure all day makes as much sense as that swordfish scene.

I have empathy for the false negatives. I have been them, or maybe at times I'm simply a false positive, the problem is those people are likely to freeze no matter the interview.

Further still, I get push back with folks citing self-prescribed medical conditions, but the same people generally display the same behaviours during the working day.

So other than contract to hire, which typically limits you to people with a job, I don't personally have a better way.

> I have empathy for the false negatives. I have been them, or maybe at times I'm simply a false positive, the problem is those people are likely to freeze no matter the interview.

I can't speak to the statistical claim that "those people are more likely to freeze no matter the interview."

But just my personal anecdote: I do fine on take-home coding tests, but I freeze up on live-coding tests.

This is one reason I'm vexed by the allegedly common cheating in take-home coding tests. It makes employers suspicious of the testing style that I'm best at.

I've actually had people cheat on live coding sessions.

For north of $2m over your career, cheating probably is the smart thing to do, especially for a borderline candidate, as there's a fair amount of evidence that the prestige on your CV will make things easier going forward.

However, my problem with take homes was never that the candidate would cheat, but rather they'll probably spend way more time than the 2 hours allocated.

I'm actually less worried about the candidate doing that, than I'm worried that the interviewer bakes in a bunch of assumptions like having a machine setup to do the task, having the specific domain knowledge and experience, and then accidentally trolls the candidate with little to no avenue for feedback.

> I've actually had people cheat on live coding sessions.

What tipped you off?

Also, I'm curious: do you think having them discuss their solution in depth would have been a good countermeasure?

I mean it was pretty obvious with their eyes darting then several lines of code appearing in the code editor.

Of course, this doesn't mean I've discovered 100% of the cheaters, just the obvious ones.

> Also, I'm curious: do you think having them discuss their solution in depth would have been a good countermeasure?

To some degree. But not everyone communicates as well as they code or vice versa, and then it comes to what you're trying to qualify.

I've also used FizzBuzz at several companies, and the insane amount of people it filters out continues to boggle my mind.

Do you tell them what the "mod" operator is before giving it?

The failure rate of FizzBuzz has always struck me as depending on the idea that you can do a lot of programming and just never need that operator.

Yeah I know how to implement FizzBuzz since it's such a meme, but I've basically never used the mod operator in real code. Maybe it comes up in more math-y code I suppose, but for most backend/frontend/SQL code I've never reached for it.

More mathy code like checking if a number is even or splitting a total number of seconds into minutes and seconds?

I’ve used it for coloring alternating lines differently in UI code, and as a lazy way to log only every so many times some loop runs.

I only know it well because it was covered near the beginning of one of the first programming books I picked up (on Perl 5) and it stuck with me because it seemed wild to me that they had an operator for that.

  for (…) {
    heavy_op();
    if (i % 100 == 0) {
      printf("not dead");
    }

Classic

Depends on the application. I've written accounting software that makes use of it, along with heavy use of floor() and ceil(), including in SQL.

Even if that's so, modulus (or at least the concept of remainders) are elementary school math and any competent programmer could bang together an (inefficient) modulus operator in a few minutes.

So even in a language w/o a mod operator, it's not a hard problem if you understand how to solve problems with code.

You don't actually need mod to do fizzbuzz, even if that's the most obvious way for people who know what mod is.

But without any "real" math at all you can do it with, eg, two counters and some if statements. Or if you recognise that there's a repeating pattern you can work out that pattern manually and just write code to emit it over and over.

I once worked with a guy who was an incredibly good developer and I was surprised when he didn't see anything special about the number 64 (i.e. a power of two) - turns out that he'd never done any bit fiddling type work so he hadn't had to think in those terms. It wouldn't surprise me if a lot of people hadn't heard of "mod" either....

A huge majority of programming work is basically just CRUD stuff and other data shuffling. It’s not surprising that someone wouldn’t have needed to work with big shifting (or modulus) in that case.

He was an expert in complex multi-organisation enterprise integration and was the go to guy to work out why horrific distributed transactions were failing... He also did a lot of cool stuff as side projects in his own time - just none of them happened to involve worrying about powers of 2.

No but I permit internet access as long as they don't search for the solution (I trust them not to do that, and don't monitor what they do)

You're too trusting.

Whilst I agree, his point still stands that either they do it fast or never.

Unless you specifically want a compiling and running version of FizzBuzz you don't actually need to use or know about the mod operator.

At least for me it would be sufficient if the person used a function like IsMultipleOf(x, m), or Remainder(x, n). This would at least make it clear what the function did even if they didn't get the exact operator.

The other thing to note is that the mod operator works differently on different languages and platforms.

> the mod operator works differently on different languages and platforms

Not with positive inputs, which is the domain of FizzBuzz.

Even if you don't know what "mod" means, if you have no idea know what a remainder is, and that the problem calls for it, and you can't derive the mod operator using integer addition, subtraction, multiplication, and division, then your math and problem solving skills are pretty weak, which FizzBuzz tests.

I stopped using fizz buzz a long time ago. 90% of candidates can't define a 2d array in their chosen language without first filtering the candidates, where you get to about 50%.

Same experience, used FizzBuzz at many places and always got surprised by the amount of people it can filter. The best interview process I've ever ran at a company consisted of a basic FizzBuzz for about 15-30 min followed by a pairing session no longer than 1h30m on a problem that could get as tricky as we wanted to assess their skill level.

We would both test the basics as well as go through with the candidate on how they think, how they collaborate, help them out if we felt nervousness was impacting them showing their skills, and in the end got a much better grasp on how skilled they were than if we were looking at Github repos or giving DS&A trivias to solve.

I once froze in an interview when asked a simple technical question - I'd been giving a presentation for an hour on how to launch a new product and I was asked by the CEO how to do something technically trivial - my brain could not do it. So he probably thought I was some marketeer pretending to be technical - which isn't really true.

I suspect quite a lot of people who are labelled as "can't code" are freezing like I did.

When I ask people to code FizzBuzz I:

  - give them ~30 minutes on their own machine
  - they get to pick the language they code in
  - I leave the room for large parts of it
  - I bring them a drink
  - I tell them I want to see what they can do and that I don't care if they complete it
  - permit them to search on the internet (as long as they don't copy/paste a solution)

I see this usually:

  - they finish in a few minutes
  - they just can't do it, even with hints

Yes that sounds pretty sensible.

Do you ever have a conversation with these people as to why they think they couldn't do it?

> permit them to search on the internet

really? they get 30 minutes + internet and they couldn't google "javascript how to get divisible by 3"? That's just bad research at that point.

I suspect some do, and some will be a lot when you bunch them all together.

However, counter point, I've had people forced on me through much of my career who just can't code for the most part, and despite being pretty reasonable about it ( it's part of the nature of the work I do ), I'm very rarely surprised by competency.

I failed FizzBuzz the first time someone gave it to me in an interview...

The specific failure was that I first attempted to solve by using repeated subtraction. The guy kept asking me to "solve it a different way", or saying "there is a better way to solve this". I tried using arithmetic tables, I tried using results about base10 remainders and I even tried using one of the corollaries to Fermat's little theorem to speed it up for larger inputs... every time I was told I was getting it wrong because "there was a better solution". In the end he pointed out that the only solution he would accept was use of the mod operator.

Since then I have actively kept a tally: I naturally use the mod operator an average of twice a calendar year, it has always been in personal life code when dealing with complicated geometry problems, the bit of code containing it almost always fails on some edgecase because at the point of using mod it is convoluted.

Honestly sounds like a bad interviewer. repeated subtraction is a good first step and I would try to push more if that was the first implementation. But If you could derive a base 10 remainder you know conceptually what problem the mod operator is trying to solve.

a % b = a - (b * a/b) /assuming a sane language with integer division, else cast a/b to int/

Figuring the above operation (or getting close) is when you should more or less pass, and That's a good point to show the interviewee what the operation is. That should be the point of an interview problem, to show the thought process, not that you know fancy tricks.

But alas, I was shown an XOR swap in an interview last week and spent 3 minutes deriving it on paper instead of 3 seconds saying "oh yeah, a => b and b => a" to a trick that I haven't seen since college some decade ago. The current market loves tricksters, I suppose.

And yes, the actual real world use of modulo is surprisingly sparse, despite easily imagining situations where you could use it.

I am highly reluctant to use type casting as a mathematical function!! I was burnt by early languages struggling with this problem... Even modern languages still have issues with this! Try running this in Python3.11

``` float(9007199254740993) == int(9007199254740992) ```

FizzBuzz is a highly artificial problem. It makes sense that people who are not familiar with it will assume that there is an elegant solution. But in the end the right approach is to be very boring and to notice that you need to check for divisibility with 15 before you check for divisibility with 3 and 5.

FizzBuzz is a problem that doesn't have an elegant solution. That is the point: to see how you approach the problem. (there are 3 possible solutions, each in-elegant in their own way)

I don't like FizzBuzz because it over-weights the interviewees knowledge of the relatively obscure modulo operator. Yes, there are other ways to do it, but the expectation of FizzBuzz is that the candidate has that "Eureka" moment and remembers modulo.

If I need a "Non-Programmer Weed Out" question, I'd rather give a problem that is 1. as easy as FizzBuzz, but 2. is just 'if' statements and loops and cannot be solved by knowledge of a particular operator (or bit twiddling tricks).

Some years ago I was remotely interviewing at Google, and I was asked to code up the reversal of a linked list. But my brain just froze.

This is something I can easily solve in 5-10 minutes, correctly handling every plausible corner-case.

I'm curious how common this is, statistically speaking. I'm also curious how it correlates with other things about the interviewee.

Reply on news.ycombinator.com