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

1–10 of 147 posts

Re: The Programming Interview from Hell

#2

Post by rammytech »

i recently had an interview which was plain smart what i need to get my work done questions i loved it ( i took that offer ). but then there were few where they did ask me a question on solution implementation and when i solve it they said there is a better way to do this and then I would be like ok then let's discuss but then they were quiet on the other side and waiting to hear me answer the best possible way to solve question ( like 15 mins )

Re: The Programming Interview from Hell

#3

Post by magic_beans »

rammytech wrote: post #2

i recently had an interview which was plain smart what i need to get my work done questions i loved it ( i took that offer ). but then there were few where they did ask me a question on solution implementation and when i solve it they said there is a better way to do this and then I would be like ok then let's discuss but then they were quiet on the other side and waiting to hear me answer the best possible way to so…

Punctuation is your friend.

Re: The Programming Interview from Hell

#4

Post by SeanLuke »

> 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 convenient to make manholes round.

Re: The Programming Interview from Hell

#5

Post by coldcode »

What a fun interview it would be to actually do this.

My favorite interview was for an architect position, where my two future peers took turns telling me horror stories about working there, to see if I would run away screaming. I got the job and only ran away screaming 18 months later.

Re: The Programming Interview from Hell

#6

Post by Neliquat »

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.

Re: The Programming Interview from Hell

#7

Post by salesguy222 »

magic_beans wrote: post #3
rammytech wrote: post #2

i recently had an interview which was plain smart what i need to get my work done questions i loved it ( i took that offer ). but then there were few where they did ask me a question on solution implementation and when i solve it they said there is a better way to do this and then I would be like ok then let's discuss but then they were quiet on the other side and waiting to hear me answer the best possible way to so…

Punctuation is your friend.

not everyone who speaks desires to be heard by everyone :)

Re: The Programming Interview from Hell

#9

Post by Patient0 »

OK - but here's a genuine problem that came up the other day in my work (reconciling two datasets - we have various many-to-one mappings of ids that we then want to reconcile against each other). I think it's quite a neat computer science/algorithm challenge, so here goes:

Write a function which takes as input a list of sets, many of which are not disjoint, but will output a list of sets where all of the non-disjoint ones have been merged back together again. So the output is a list of sets which are all disjoint from each other because any intersecting sets have been merged together.

e.g. given the input:

    [(1,2,3), (2,4,8), (10,11,12)]
it will report back:

    [(1,2,3,4,8), (10,11,12)]
because (1,2,3) and (2,4,8) are not disjoint, but the (10,11,12) set is.

Whereas given the input:

    [(1,2,3), (2,4,8), (10,11,12), (8,10)]
it would report back a single set:

    [(1,2,3,4,8,10,11,12)]
because now all of the sets are connected - the 8 and the 10 now connect everything else together.

I came up with an algorithm which is acceptable for the dataset we currently have - but I've no idea what time complexity it is (for our real dataset it was able to do it in "one pass" - but in principal it could be worse than that). I don't know how I would implement a distributed version if the list of sets was too big to fit in memory, etc. etc.

And I haven't found a good solution on Google (but I'm not even sure what to Google).

Post reply on HN