Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Programming Interview from Hell

pythonforengineers.com

Post reply on HN
Print view View original

141–147 of 147 posts

Re: The Programming Interview from Hell

#141

Post by btschaegg »

llukas wrote: post #127
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…

My guess would be that simplest way to sync two threads is exit them both. ;)

...or not running them in the first place.

Re: The Programming Interview from Hell

#142

Post by btschaegg »

kppiskingpp wrote: post #14
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…

linked list is not complex for christ sake.

> linked list is not complex for christ sake.

...unless you need them for lock-free programming. There was a nice C++ talk by Herb Sutter on that, with the apt title "Juggling Razor Blades". That pretty much says it all.

From a practical standpoint, the question "what is a linked list good for?" really might be more interesting. Does anyone know of potential use cases besides kernel design, lock free programming or Clojure-style immutable datastructures? I'd guess CPU caches to have erradicated most of them...

Re: The Programming Interview from Hell

#143

Post by ryandrake »

scarface74 wrote: post #103
ryandrake wrote: post #42

Earlier quoted context omitted.

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 woo…

I partially agree. It depends on what you are hiring for. If you are hiring for a low level code monkey, you want to see how they code. If you are hiring for a senior level engineer/architect, you want to see how often they avoid coding and know how to leverage existing frameworks.

Old post but wanted to respond: Even when interviewing more junior roles, I want to see the solution that involves the smallest amount of code, ideally no code. Nothing wrong with expecting that existing mentality from both junior and senior people alike. Saves you from having to instill it.

A candidate's ability to re-implement the language's standard library is not so useful if we simply use the language's standard library in our application code.

Re: The Programming Interview from Hell

#144

Post by kabdib »

kazinator wrote: post #137
kabdib wrote: post #136

Earlier quoted context omitted.

You can raise IRQL and get okay synchronization on simple systems. It was fine for early versions of Unix, and I've used it quite a bit on uniprocessor embedded systems. Just a few instructions, hard to get wrong. Of course it fails if you're working in user mode. Or you have non-maskable interrupts that you need to sync with. In this case the poor PhD x 2 had been working for years on consumer PCs, which were at the…

Early versions of Unix were co-operative. While a task executed kernel code, it was not preemptable. That might be the simplest thread synchronization. Masking interrupts is then just for exclusion between the one and only kernel thread, and interrupt context.

That's true.

Re: The Programming Interview from Hell

#145

Post by StreamBright »

zhte415 wrote: post #64
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. In fact, I'm still looking. I think we all are. Copy-paste.

You guys... Forgot about email...

Re: The Programming Interview from Hell

#146

Post by StreamBright »

kppiskingpp wrote: post #14
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…

linked list is not complex for christ sake.

No it is not. However, it is totally irrelevant for 99% of jobs require programming skills. Being 15 years in this business I haven't seen linked lists being used for any particular problem, but I understand that when you work in the right industry it is invaluable. If I had to implement it I would probably use a library and I would educate myself on the subject. I usually find programmers running into many other issues that don't show up during interviews.

Few questions I usually ask:

- How can you make sure that your Java application runs on the server not only on your laptop? (I take any answers: containers, single JAR, etc.)

- What is printed out

def add_list(val, list=[]):

    list.append(val)

    return list
print add_list(10)

print add_list(20)

print add_list(123,[])

- Explain recursion

Funny to see how a non-trivial amount of programmers fail to answer these questions.

Re: The Programming Interview from Hell

#147

Post by smsm42 »

I'd take very negative view of interviewee that claims linked lists and big-O (and optimization lore connected to it) is relevant only in interviews. Of course, if he's interviewing for HTML-"coding" grunt in a company making trivial website, I'd get it. But if any substantial programming involved, it's completely false.
Post reply on HN