The Programming Interview from Hell • Hacker News Board

Re: The Programming Interview from Hell

#41

Post by Apocryphon » Mon, Feb 20, 2017, 3:05 PM UTC

mankyd wrote: post #13

I interviewed someone who gave responses akin to "I'd Google it." When presssed, he did finally give some reasonable answers. We ended up hiring him, as we'd interviewed 10 other candidates who'd failed at that point. He ended up being a terrible employee. Seriously, when someone asks you the details of a linked list, they're not trying to find out if you will be able to use one specifically on the job. They're tryin…

If he gave reasonable answers when pressed, despite being initially resistant, it sounds like the interview didn't give any insight into whether he was a good employee or not.

Re: The Programming Interview from Hell

#42

Post by ryandrake » Mon, Feb 20, 2017, 3:06 PM UTC

ensiferum wrote: post #12

Thats hilarious. I was once interviewing for a C++ position and the interviewer presented me with some C code with a broken "swap" implementation and a driver function and asked me to fix it. I simply prefixed the call to swap with "std::". He wasn't very happy about it. ;-)

Nice. I was once asked to implement a basic filesystem API in C++ including file manipulation, directories and paths, etc. I just said use boost::filesystem and move on with your life. Interviewer was not impressed but at 95% of companies that's what you are going to want to do.

Can you imagine interviewing someone to build you a house and spending 90% of the interview time asking him how he'd chop down trees for wood and manufacture the nails? Welcome to software interviewing.

Re: The Programming Interview from Hell

#43

Post by dwringer » Mon, Feb 20, 2017, 3:07 PM UTC

8166284 wrote: post #21

I've called out interviewers for stupid puzzle questions multiple times. Never got the job in any case, but I like to think I improved the hiring process marginally before being rejected.

Heh, I would imagine they just found fellow aristocrats who had seen the puzzle questions before and whose groupthinking conformity was a perfect match for the companies.

Re: The Programming Interview from Hell

#44

Post by zero_iq » Mon, Feb 20, 2017, 3:07 PM UTC

Neliquat wrote: post #6

SeanLuke wrote: post #4

> Manholes covers are round because that is the shape that won’t fall in It's worth mentioning that this oft-repeated canard doesn't have much evidence. Manhole covers come in a great many shapes, and this has always been true: the Romans made them square. There are plenty of shapes which won't fall in, such as any curve of constant width. Basically fake-Feynman is right: manhole covers are round because it is often…

Modern manhole covers are overwhelmingly round, and cast as not to fall into their own fitting, also cast. Not sure how a obscure counter example does anything other than disprove your point further. Source: worked IT for public civil engineer for a few years.

I assume that by 'obscure' you mean 'outside your-state, USA'. Here in the UK, rectangular manhole covers are the overwhelming majority.

Re: The Programming Interview from Hell

#45

Post by adamkittelson » Mon, Feb 20, 2017, 3:11 PM UTC

hackerboos wrote: post #34

fishnchips wrote: post #15

I once had to use a linked list to implement a sorting algorithm on a huge but partially sorted input. This was to detect duplications in an AST, for a static code analysis startup. This was literally the only time I professionally used any sort of non-trivial data structures and algorithms, and I've been working in the field for some 10 years now.

Knowing of data structures is more important IMO. The hoops I've seen people jump through in code because they don't know about sets.

And when you see that do you wish they'd never been hired due to this insurmountable hole in their knowledge of data structures or do you take 30 seconds to tell them about sets?

Re: The Programming Interview from Hell

#46

Post by doppel » Mon, Feb 20, 2017, 3:14 PM UTC

While I understand the context is "stupid inteview questions", I would not say Big O-notation is useless, even for non-Google companies - just read some of the stories at thedailywtf.com to learn how bad it gets.

Also, there's a difference between asking "How would you solve X (in Y language)" and expecting a line-by-line code sample. In the former you should be able to talk about how you would structure the code, what input/output you would need, how to set it up, data stores, etc. whereas the latter is (virtually) impossible without help from Google.

While it would be lovely to hire candidates by "everything it says in the resume", the truth is that only works for really great hire... which you don't know until you've talked to them about how they work, what they've done and how they like to solve problem.

Re: The Programming Interview from Hell

#47

Post by satysin » Mon, Feb 20, 2017, 3:16 PM UTC

kabdib wrote: post #37

The hiring manager of a small software company gave me a quick brief before handing me off to his technical heavy. "He's hard to get along with, but he's really smart. Oh, and he has two PhDs. He'll tell you that." I was ushered in. The Guy with Two PhDs (he showed me his business card first, and there were indeed two PhDs on it) asked me: "What is the simplest way to synchronize two threads?" I rattled off some sync…

If someone asks you the "best" way to do something but does not give you context for the problem being solved then the question is stupid. There is no all-purpose "best" way to do anything when it comes to complex systems. You use the "best" way for the problem in hand that may be shared memory, pipes, writing to a file, RPC, etc.

Re: The Programming Interview from Hell

#48

Post by Kurtz79 » Mon, Feb 20, 2017, 3:17 PM UTC

ensiferum wrote: post #12

Thats hilarious. I was once interviewing for a C++ position and the interviewer presented me with some C code with a broken "swap" implementation and a driver function and asked me to fix it. I simply prefixed the call to swap with "std::". He wasn't very happy about it. ;-)

Of course, you acted like a smartass for no apparent reason.

You will never be asked to reimplement a library function on your job, these questions are used to see how you approach a problem, your reasoning, etc...

Re: The Programming Interview from Hell

#49

Post by monodeldiablo » Mon, Feb 20, 2017, 3:17 PM UTC

I've actually used (politely, of course) many of these answers in interviews, whenever I felt the interviewer was trying to show off or read from the script instead of actually judging my abilities.

"I'd google it. Anything less would be a waste of our time." That cuts through a lot of bullshit. After saying that at my last interview, we got into actual problems (structuring a program, building an API, writing code to approximately simulate real world problems, data structures). Had a good time, got hired, and loved working with those people.

On the other end of the spectrum, I've been torn to shreds in an interview for not being able to write a fast hash table implementation in Java (didn't know Java at the time and the interviewer didn't know Ruby/Python/C) in an hour of trying. That was soul-destroying.

Re: The Programming Interview from Hell

#50

Post by harveywi » Mon, Feb 20, 2017, 3:17 PM UTC

kabdib wrote: post #37

The hiring manager of a small software company gave me a quick brief before handing me off to his technical heavy. "He's hard to get along with, but he's really smart. Oh, and he has two PhDs. He'll tell you that." I was ushered in. The Guy with Two PhDs (he showed me his business card first, and there were indeed two PhDs on it) asked me: "What is the simplest way to synchronize two threads?" I rattled off some sync…

> I never found out the BEST way to share data between programs

Come on, add another layer of indirection! When given a problem to solve, hand back another problem.

In this case:

Q: "I want the SIMPLEST possible way to synchronize two threads. What is it?"

A: The SIMPLEST possible way to synchronize two threads is a global maximal element (not necessarily unique) of a poset induced by a partial ordering on possible methods for synchronizing two threads. If the induced poset is totally ordered, and assuming that at least one possibly way of synchronizing two threads exists, then there exists a SIMPLEST possible way to synchronize two threads. If you hand me a method for comparing two synchronization methods for SIMPLICITY, then an algorithm retrieving such a best possible solution is trivial, but at this point you must define define what you mean by SIMPLEST before we can move any further.

Mr. Double PhD was trying to be clever.