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

131–140 of 147 posts

Re: The Programming Interview from Hell

#131

Post by [deleted] »

yunolisten wrote: post #38
kppiskingpp wrote: post #14

Earlier quoted context omitted.

linked list is not complex for christ sake.

> linked list is not complex for christ sake. There are many people for whom this is complex, you're assuming a foundation that not everyone has. There are also many people for whom nothing is complex, they assume they can understand everything, while they don't currently, they assume they'll be able to learn it without issue. Dealing with new starts who are straight out of education is often like reading posts from…

[deleted]

Re: The Programming Interview from Hell

#132

Post by flukus »

scarface74 wrote: post #97
golergka wrote: post #65

Earlier quoted context omitted.

Have you ever hired developers? FizzBuzz is still a very effective filter.

At my last job, we asked two simple questions and many "senior developers" couldn't get them: 1. Write a function that determines if a number is prime. If they didn't know what a prime number was, we would tell them. 2. A simple problem that required designing a database schema and sql query that involved a left outer join. There were a lot of developers who couldn't do it. On the other hand, there was one developer…

> Write a function that determines if a number is prime. If they didn't know what a prime number was, we would tell them.

Did you also give them an algorithm to implement or was a brute force method good enough?

Re: The Programming Interview from Hell

#133

Post by scarface74 »

HeyLaughingBoy wrote: post #120
scarface74 wrote: post #104

Earlier quoted context omitted.

That is how I approach a problem. I've seen too many inexperienced developers reinvent the wheel - badly - instead of taking a step back and wondering, "is this a solved problem"? Is this part of our core competency or can we outsource it, find an existing package, etc.

Even good, senior developers do this. A lot of people just jump into a problem because it's fun, but don't stop to say "hey, someone must have solved this already. Let me see if there's an open-source solution out there."

I might do something like that on my own time as a learning experience, but not as part of my job. The less surface area we have to support the better.

It's also a lot easier to onboard new people if you're using a popular third party package and you have thousands of people that have already had the same problems you might encounter.

Re: The Programming Interview from Hell

#134

Post by scarface74 »

flukus wrote: post #132
scarface74 wrote: post #97

Earlier quoted context omitted.

At my last job, we asked two simple questions and many "senior developers" couldn't get them: 1. Write a function that determines if a number is prime. If they didn't know what a prime number was, we would tell them. 2. A simple problem that required designing a database schema and sql query that involved a left outer join. There were a lot of developers who couldn't do it. On the other hand, there was one developer…

> Write a function that determines if a number is prime. If they didn't know what a prime number was, we would tell them. Did you also give them an algorithm to implement or was a brute force method good enough?

First the brute force algorithm. Then we would ask them how could they optimize it. A lot of people couldn't even get to the brute force algorithm.

1st level optimization: skip even numbers.

2nd level optimization that I was the only person to get when I had to interview for the company: loop starting at 2, and go the square root of the argument.

Re: The Programming Interview from Hell

#135

Post by kabdib »

harveywi wrote: post #55
satysin wrote: post #47

Earlier quoted context omitted.

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.

Exactly. When handed an under-specified problem (semantics), hand back a lambda compiled in the target language (syntax). "What do you mean? African or European?"

Upvote for "hand back a lambda". I was laughing.

"Here, run this unsigned code for me in your head." That has all kinds of possibilities . . .

[See John Barnes' book _Candle_ if you want some scary prognostication. Warning, it's kind of graphic and disturbing in spots]

Re: The Programming Interview from Hell

#136

Post by kabdib »

kazinator wrote: post #119
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…

"Raise interrupt priority" is not a way to synchronize threads , let alone the simplest. I know what I'm talking about; I worked on multithreading for Linux before the rewrite to NPTL and I invented the PTHREAD_MUTEX_ADAPTIVE_NP type that you still find in Glibc. On a project several years ago, I did use interrupt priority in conjunction with threads as a complete hack. The issue was this: the interrupt service routi…

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 time nearly all single CPU. I'd been mucking about with multiprocessing a fair amount, and the IRQL thing never even occurred to me during the interview. Just as well.

Re: The Programming Interview from Hell

#137

Post by kazinator »

kabdib wrote: post #136
kazinator wrote: post #119

Earlier quoted context omitted.

"Raise interrupt priority" is not a way to synchronize threads , let alone the simplest. I know what I'm talking about; I worked on multithreading for Linux before the rewrite to NPTL and I invented the PTHREAD_MUTEX_ADAPTIVE_NP type that you still find in Glibc. On a project several years ago, I did use interrupt priority in conjunction with threads as a complete hack. The issue was this: the interrupt service routi…

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.

Re: The Programming Interview from Hell

#138

Post by manu29d »

I had a recent interview where it literally went like this:

He: "Hi. My name is [X] from [Y:company]. We were scheduled for an interview now."

Me: Yes.

He: "Ok. Am I audible?"

Me: Yes.

He: "Cool. [Answer this question]"

Me: baffled screeching

He talked about a lot of things then including "How does Node.js manage it's asynchronus thread? Where is the sequence of functions to run stored in the memory?". In the end I asked him what was a general day like. To which (no kidding) his reply was:(sad tone) "It's Friday 6pm. Everyone is having donuts and here I am taking this interview".

Well, if you're more concerned about your donut, thanks I guess. I got rejected after this round.

Re: The Programming Interview from Hell

#139

Post by joncrocks »

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 think the point is that a circle is not the only shape that can't fall into it's own hole/fitting, so it's the combination of this fact along with other factors that make a circular cover popular.

https://en.wikipedia.org/wiki/Manhole_cover#Circular

Re: The Programming Interview from Hell

#140

Post by btschaegg »

willis77 wrote: post #80
Ntrails wrote: post #68

Earlier quoted context omitted.

See, I was gonna go with Data.txt in a shared network drive. Btw = if you're worried about conflicts - it's Ok there's a second file called "writeStatus.txt" which you have to claim by replacing the String NULL with your processId - thereby claiming write access to data.txt and causing any other processes to Thread.Sleep until it's free. Unrelated, who's hiring...

But who has access to writeStatus.txt? Classic rookie mistake. You needed a writeStatusWriteStatus.txt.

Sounds like playing Byzantine Generals on the file system :)
Post reply on HN