Hacker News Reader

Comment by banana_giraffe | Hacker News Reader

I once walked into an interview where some code was already written on a whiteboard. It was presented to me as a "find the problem with the code" sort of puzzle, and I pointed out the one big logic problem with it's algorithm and wrote a quick fix.

The interviewer responded with "hold on", and grabbed a colleague, pointed at the whiteboard, and the colleague said "yes! that'll fix it!" and ran off.

I was offered the job that I was clearly qualified for, but I declined. I often wondered how many candidates it took them to fix their bug.

View on HN

I had an interview question that dealt with knowing some crazy shit about C data structure layout and pointers and casting. (Embedded development position)

You had to solve it on a blackboard, with chalk, and the intent (I later learned) was not necessarily that you got the right answer, but how you worked through it. Did you just lock up? Did you get frustrated? Did you ask the interviewer to clarify with more data? They wanted to see your thought process.

I was able to answer it (not everyone that got hired did), and when I was done, I looked at the interviewer and asked "Do you write code this way, here?". He laughed and said 'no, no no no'. I told him, I wasn't sure I would want to work there if they did. We both laughed. He ended up being my first supervisor at that company.

Hello Dan! (If you happen to read this...)

> I was offered the job that I was clearly qualified for, but I declined.

Out of curiosity, why?

Nothing to do with this event, I just had another offer from a company I interviewed at during the same period that was more interesting to me.

Not the OP, but for my money, a company that does that isn't a company to work for. I don't work for free and you shouldn't either.

Honest question: What difference does it make whether you work on a l33tcode question or a real problem in the interview? At least the real problem has a chance of being interesting.

Sometimes I do give candidates examples of real challenges we're facing. The purpose is not to get anything for free, but rather to see if they're good at coming up with new ideas.

It also gets boring asking the same questions that may or may not have leaked to the Internet over and over.

AITA?

Because you're literally working for them for free.

Leetcode is fine. Once a dude asked me to write out merge sort. Like, I’m not from a CS bg (I suppose that wouldn’t matter). And I literally did look at merge and other sorts two days back. But that didn’t matter, the only way you can write merge sort is if you memorize it (or spend an inordinate amount of time writing sorting algos). I didn’t get that job, but I’ve been monitoring that company and they’re not doing that well anyway. Perhaps a coincidence?

> the only way you can write merge sort is if you memorize it (or spend an inordinate amount of time writing sorting algos)

Umm, what?

  void merge(int* d,int const* a,size_t za,int const* b,size_t zb)
    {
    size_t zd = za+zb,ia=0,ib=0;
    for(size_t i=0; i<zd ;i++)
      {
      if(ia < za && ib < zb)
        {
        if(a[ia] < b[ib]) d[i] = a[ia++];
        else              d[i] = b[ib++];
        }
      else if(ia < za)    d[i] = a[ia++];
      else if(ib < zb)    d[i] = b[ib++];
      else abort(); // should have i==zd now
      }
    }
  void msort(int* d,size_t z,int const* s)
    {
    if(z==1) *d = *s;
    if(z<=1) return;
    size_t h = z - (z>>1); // round up
    int* x = malloc(h * sizeof *x);
    if(!x) abort(); // out of memory
    msort(x,h,s+(z-h));
    msort(d+h,z-h,s);
    merge(d,d+h,z-h,x,h);
    }
  // not that this is any *good*, but it does *work*

Are you using a absurdly broad definition of what counts as memorizing something or something?

> the only way you can write merge sort is if you memorize it

Nah. You only have to remember the central idea (if you have two sorted "runs", you can merge them into a single sorted run). You draw a quick diagram to explain the idea, you go ahead and write code that does it.

Then you apply recursion, and write down the overall algorithm (subdivide into runs until you can use some other method to sort it, then merge recursively).

Bonus points if you can explain the circumstances when this is useful (when you want to sort data that is a lot larger than your main memory, but you can write it on disk or tape). Which is kind of obsolete today, unless you are again dealing with BIG data (everything old is new again...)

That’s a great question. Thanks for continuing to ask these so I can avoid those orgs.

When I do come to having to decide on a sorting algorithm, I can refer to the code and algos and then decide. All I need to be able to do is understand the algorithm when I see it not memorize the differences between quick and merge sort. I’m actively working with multiple Olap and regular db solutions and my teams responsible for keeping 100 billion row tables in the most queryable format and it’s never been possible for me to make such a choice, only on whether I use spark or redshift or snowflake. So what exactly would you achieve by asking this question? The irony is I was rejected by 5 companies for not being technical, accepted by 1 where I’ve been thriving for years now at one of the most technical roles in the org.

Giving actual problems during an interview is fine, and I'd actually prefer getting an interview problem that the company is really working on. I think people are just pattern-matching this to the kind of scam where the company farms out their work as multi-hour take-home problems with no intention of actually hiring the candidate afterwards.

I prefer to use real problems with the work that have already been solved. It shows what the day-to-day is like, you know there's at least one solution to the problem, and you aren't asking someone to work for free.

I wouldn't say you are, but some people have been burned by the concept of spec work that employed tricks like this to basically get free brainstorming. In other industries like art it's especially egregious.

It's a real shame in tech with its (past and present) history of open source work and contributions that can be interpreted as such, especially with many projects nowadays being maintained by billion dollar coporations that can certainly pay a candidate for contributions. But that's a huge beast to tackle.

follow up note: I'm not sure if this[0] comment is parody or unironic, but situations like this are exactly what gives the idea such a bad reputation.

[0] https://news.ycombinator.com/item?id=31265554#31266239

> The purpose is not to get anything for free, but rather to see if they're good at coming up with new ideas.

These "new ideas" are things you should be paying them for.

They are so understaffed they need to use interviewees to do their work! Bad news!

Asking an interview candidate to solve an actual problem the business is currently facing is shitty, and I wouldn't want to work for them either.

Any code problems we present to the interview candidate are _clearly_ made-up examples. Though one of them was simplified from a real-world project we had years and years ago.

Reply on news.ycombinator.com