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

Lessons from 3,000 technical interviews

blog.interviewing.io

Post reply on HN
Print view View original

281–290 of 330 posts

Re: Lessons from 3,000 technical interviews

#281

Post by [deleted] »

SomeStupidPoint wrote: post #269
timr wrote: post #258

Earlier quoted context omitted.

Not that I can see. The OP said: "find the subset in a given collection that matches this specific criteria" So basically, a loop through a single table. That's as simple as it gets. You can make the problem more complicated, of course (e.g. "write a method to find the minimum and maximum ages of the male users" ), but it's still pretty simple stuff. A slightly less trivial "algorithm" question that should be equally…

I would like to see a solution to your problem with bounded memory. In particular, the case where I want the top 3 words, you don't know the length of the stream, and you get random permutations of the same 4 words until I stop emitting them (where I will end by emitting 3 to break the tie). That's not to say your problem isn't interesting -- just that while specifically constructing a problem as an example, you crea…

[deleted]

Re: Lessons from 3,000 technical interviews

#282

Post by BigJeffeRonaldo »

Futurebot wrote: post #183

The takeaway from this is that those who do best are those with: - the wealthiest/most financially supportive parents/relatives - upbringings that are conducive to academic success - the most free time as those are the ones who, by a large margin, attend top schools, work at top companies, and have time to spend on self-learning. Another data point of confirmation of a well-studied idea. Assortative mating: http://ww…

Great post. If you have a worse background, you have to fight your way up, whereas those with more family resources just have to not screw up badly and they'll probably end up alright.

Re: Lessons from 3,000 technical interviews

#283

Post by literallycancer »

FLUX-YOU wrote: post #241
blindhippo wrote: post #206

Earlier quoted context omitted.

I used to think along these lines. Then I started doing 10+ interviews a month and realized a very clear reality: basic CS knowledge and problem skills is far more important to me and my team then knowing how to slap together some semblance of a working CRUD system. I ask "algorithmic" questions, normally expressed as a legitimate business case (invent a real world problem, solution is implement some algorithm or use…

>The average coder should be able to solve this type of thing, on their own, in about 10 minutes max, 15 with some feedback on improvements. >Yet, 80% of my candidates take nearly 45 minutes and cannot deliver a workable solution without massive handholding, and I don't even get to my higher order, "real questions". You need to ask yourself why you believe the "average coder" should be able to solve that because clea…

You interpreted what he said as "average applying coder", but he probably meant "average employed coder".

The people that weren't successful during the interview today? They are going to have more interviews tomorrow and next week too. Doesn't mean they are representative of the average coder (most of whom are not being interviewed, because they have jobs already).

The population is skilled enough, it's just that of those who are left, most are not (so it takes more time to fill positions).

Re: Lessons from 3,000 technical interviews

#284

Post by timr »

SomeStupidPoint wrote: post #269
timr wrote: post #258

Earlier quoted context omitted.

Not that I can see. The OP said: "find the subset in a given collection that matches this specific criteria" So basically, a loop through a single table. That's as simple as it gets. You can make the problem more complicated, of course (e.g. "write a method to find the minimum and maximum ages of the male users" ), but it's still pretty simple stuff. A slightly less trivial "algorithm" question that should be equally…

I would like to see a solution to your problem with bounded memory. In particular, the case where I want the top 3 words, you don't know the length of the stream, and you get random permutations of the same 4 words until I stop emitting them (where I will end by emitting 3 to break the tie). That's not to say your problem isn't interesting -- just that while specifically constructing a problem as an example, you crea…

"I think most interview questions are similar nonsense."

It's probably a good idea to be careful with your words when you admit that you don't know the answer to a question.

First off: your example (random permutations of the same four words) doesn't require much memory at all. So if you think it does, you're wrong. You might overflow your counters, but that's a different problem.

A stream of random gibberish is certainly more challenging. But the cardinality of the English language isn't infinite (the OED has about 230k words, and that's with lot of words that nobody ever uses), so even a naive solution doesn't require "unbounded memory", as long as you take the problem statement seriously and don't do something ridiculous. That would be good enough to pass an interview.

But OK, let's say you do have a stream of random latin-encoded gibberish. What then? The problem statement is that you have to determine the top-10 words (or in this case "tokens") by frequency. The cardinality of the set is infinite, but the probability of duplication per token is small, and the output set is tiny. Do you really think you need unbounded storage?

In any case, even if you think a problem is "nonsense", it's probably true that the interviewer has thought about it more than you have. The part that frustrates you is highly likely to be the bit worth probing. A bad candidate will bomb out immediately; a decent candidate will provide a solid, if not perfect solution; a great candidate will solve the problem, see the broader theoretical aspects, and investigate those as well.

Re: Lessons from 3,000 technical interviews

#285

Post by timr »

sten wrote: post #274
timr wrote: post #258

Earlier quoted context omitted.

Not that I can see. The OP said: "find the subset in a given collection that matches this specific criteria" So basically, a loop through a single table. That's as simple as it gets. You can make the problem more complicated, of course (e.g. "write a method to find the minimum and maximum ages of the male users" ), but it's still pretty simple stuff. A slightly less trivial "algorithm" question that should be equally…

I'm hard pressed to imagine how this couldn't be done efficiently. Do you have an example which correctly solves the problem but takes too long? The only thing I can think of is something like the output rewriting an array on update over and over.

Which problem? The first one? Don't underestimate the badness of the average interviewee.

For the "find the min and max of a set" in particular, a lot of folks start out with terrible solutions.

Re: Lessons from 3,000 technical interviews

#286

Post by noxToken »

blindhippo wrote: post #273
vonmoltke wrote: post #262

Earlier quoted context omitted.

> If you resume screen for "has written code before" I wish that was the resume screen criteria at all the places that ignored my applications. The more I read these threads the more I think resume filtering is part of the problem. It makes some sense; if the bad applicants have to apply to hundreds of jobs to get hired they have likely learned how to game the resume scteen.

Resume filtering is terrible - I tend not to be involved in the process since usually recruiters or hiring managers do this. However, when someone stops by my desk and asks "should we schedule a phone screen with this candidate who lists HTML, CSS, and jQuery, as programming languages" for a senior web developer position, I say no. A huge problem is people list technologies as keywords on their resumes and rarely ind…

I know this isn't always the case, but how does one note competency in a given language or with a given tool(set) while fitting a resume on a single sheet. Especially if it's for a senior/lead or higher position?

There's a lot that's broken with the hiring process. One of the toughest thing as a potential candidate is how to properly tailor a resume to fit the bill without "gaming" the hiring process. There is no standard - only methods that work better than others in most situations.

Re: Lessons from 3,000 technical interviews

#287

Post by dsp1234 »

SomeStupidPoint wrote: post #269
timr wrote: post #258

Earlier quoted context omitted.

Not that I can see. The OP said: "find the subset in a given collection that matches this specific criteria" So basically, a loop through a single table. That's as simple as it gets. You can make the problem more complicated, of course (e.g. "write a method to find the minimum and maximum ages of the male users" ), but it's still pretty simple stuff. A slightly less trivial "algorithm" question that should be equally…

I would like to see a solution to your problem with bounded memory. In particular, the case where I want the top 3 words, you don't know the length of the stream, and you get random permutations of the same 4 words until I stop emitting them (where I will end by emitting 3 to break the tie). That's not to say your problem isn't interesting -- just that while specifically constructing a problem as an example, you crea…

In the given case, it's actually the "English words" limitation that saves the question. An exact answer to top-k problems is O(N) is storage space where N is the number of distinct items. So since N is ~200k, it's not a terrible problem to deal with. When N is 3 as in your given case, it's not really a problem. The general case, of when the stream is unbounded in the number of distinct items, is much harder, say the stream is 1 quintillion non-repeating words, then starts repeating. This requires an approximation algorithm, but is not likely the solution that was looked for since the person specifically said "slight less trivial", and the streaming approximation algorithm is more complex.

Though it could be still be saved by flipping the question back onto the interviewer's phrasing. They said "don't run out of memory", not "don't run out of disk space". So you could also solve this problem by, for example, writing the data into a database, then using SQL group by and top X functions to solve it once the stream has ended. But as an interviewer, I probably wouldn't be amused.

Re: Lessons from 3,000 technical interviews

#288

Post by Roboprog »

blindhippo wrote: post #271
FLUX-YOU wrote: post #254

Earlier quoted context omitted.

Is he talking about this problem (with a filter at the end)? http://www.geeksforgeeks.org/finding-all-subsets-of-a-given-... Because I have never done that. That's different than just running through a list and picking out items that meet a criteria.

That's more advanced then the question I ask typically. Though I might use something like this if I'm interviewing someone with many years of experience (10+). As I explained above, my question is a warm up - meant to break the ice, calm nerves. But it's surprising to me how effective even a simple list traversal is at identifying weaknesses in a candidates programming ability.

Depending on the platform, there's at least 2 ways to do that :-)

E.g. - "functional" is simply something like:

    subset = filter( predicate, superset )
... but on a "procedural" platform, it's a bit more challenging, starting with how much space to allocate for the result, or whether to mutate the input, and other wading through the swamp.

But, yeah, I can see how it would get people to start up talking somewhere, or else go into "deer in the headlights" mode.

Re: Lessons from 3,000 technical interviews

#289

Post by cr0sh »

forrestbrazeal wrote: post #71

The author draws a hard distinction between Udacity/Coursera MOOCs (good) and traditional master's degrees (bad). I'll interject that with Georgia Tech's Online Master's in Computer Science program [0], which is delivered via Udacity and insanely cheap [1], you can get the best of both! (Their "Computability, Complexity and Algorithms" class is one of the top Udacity courses cited in the article.) Keep in mind that a…

I so want to enroll and take the OMSCS; I know I could succeed at it if I took it, but the school requires you to have at least a Batchelor's degree to attend (they don't count work experience in software development - so my 25+ years mean nothing).

I found out about the OMSCS after I started my work on Udacity's "Self-Driving Car Engineer" nanodegree course, which I am currently taking. My plan (hopefully) is after I complete the nanodegree, I'm going to take some kind of online BS program (maybe accelerated if I can find one), then hop over to the OMSCS (hopefully it or something similar is still running). I mainly want to do it to prove to myself I can do it - I believe that I can.

I made some early life choices that have led me to where I am at, and while it hasn't hindered my job or career prospects, I have always wanted what I should have done in the first place.

Re: Lessons from 3,000 technical interviews

#290

Post by erroneousfunk »

matt_wulfeck wrote: post #49
geebee wrote: post #14

Interesting bit on the MS degree. I followed the link, and I'm not quite as surprised that the correlation is poor, or even negative, given the way the data was collected and analyzed. Absolutely agree that some MS degrees are pretty much less rigorous cash cows by now, that allow students to skip the fundamentals such as data structures, operating systems, and compilers. However, many CS MS degrees actually do requi…

> Absolutely agree that some MS degrees are pretty much less rigorous cash cows by now, that allow students to skip the fundamentals such as data structures, operating systems, and compilers. At what point do we not consider operating systems and compilers "fundamental"? What percentage of CS/programming jobs require deep knowledge in these arenas?

I did general engineering in undergrad, and software engineering (not CS) for my master's, so I'm somewhat of an outsider to a "computer science" degree. But if you have 6 whole years to turn someone into a "computer scientist," I would expect that, in ADDITION to compilers and operating systems, they'd also have a healthy dose of physics, chemistry, and especially math. I mean, for crying out loud, the degree has the word "science" in it.

My freshman year physics class had us building computer models of the solar system from Kepler's laws, constructing vocoders by manipulating raw sine waves, and discovering the equations that governed op-amp circuits through experimentation and a little deep thinking.

At my last job, one of my first tasks was to take raw data from truck engines computers (a data point ever 300ms) and turn point measurements like "instantaneous velocity" into data like "how far as the truck traveled over the last week"? Trivial. By combining that with engine speed and fuel usage, you could also say things like "what gear is the truck in?" "Has the engine performance declined recently?" "What percentage of the time has the driver idled in the last month?" And roll all that data up into an efficient database, build a super-flexible API around it, and create a series of web apps to display the useful stuff that managers wanted.

Having a deep understanding of the physical relationships between measurements, understanding what the data can and can't tell you, being able to spot potential problems in a proposed project (for instance, something that relies on an impossibly accurate GPS in a subtle way) -- these are all things that computer scientists absolutely should be able to do.

Yes, they should understand their computers from the electrons on up -- operating system included -- but they should understand the world that the computers interact with, as well.

Post reply on HN