4 ms·

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 puzzl

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.

ansible 4y ago
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.
Victerius 4y ago
> I was offered the job that I was clearly qualified for, but I declined. Out of curiosity, why?
- banana_giraffe 4y ago
  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.
- eropple 4y ago
  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.
  - metadat 4y ago
    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?
    - maximus-decimus 4y ago
      Because you're literally working for them for free.
    - ramraj07 4y ago
      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?
      - a1369209993 4y ago
        > 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?
      - dirkt 4y ago
        > 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...)
- op00to 4y ago
  They are so understaffed they need to use interviewees to do their work! Bad news!
greyhair 4y ago
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...)

ansible 4y ago

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.

Victerius 4y ago

> I was offered the job that I was clearly qualified for, but I declined. Out of curiosity, why?

banana_giraffe 4y ago
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.
eropple 4y ago
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.
- metadat 4y ago
  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?
  - maximus-decimus 4y ago
    Because you're literally working for them for free.
  - ramraj07 4y ago
    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?
    - a1369209993 4y ago
      > 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?
    - dirkt 4y ago
      > 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...)
op00to 4y ago
They are so understaffed they need to use interviewees to do their work! Bad news!

greyhair 4y ago

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...)