I will puke if I hear array search interview question again | Hacker News Reader

I will puke if I hear array search interview question again

webapplog.com

23 pointsazat_co55 comments

From your about page azat:

"My primarily fields are Ruby on Rails, NodeJS, JavaScirpt, Backbone, HTML, CSS and of course PHP!"

Now I'm sure your a great guy, but there are a lot of people out there with that exact set, or nearly that exact set, of technologies who can't program. They can take a page and hack it to do what they want, they are 'cooks' not 'chefs.' Did I mention there are a lot of them? And if someone is looking for a programming position, and they see a resume that is full of these platform things, one of the questions they will jot down is "be sure they can actually program" on their to do list for the interview.

Back in the 90's there were a ton of people who put 'web site programmer' on their resume but it meant they had used a copy of Pagemaker, not that they actually knew what the HTML spec had in it, so if you couldn't express it in Pagemaker they couldn't do it. Those interviews would start with things like "style this page using <some HTML or CSS feature>." It was a winnowing question to separate the tool users from the folks who knew what actually happened.

There's a timing thing too. If you put PHP on a resume in 1998... you were doing PHP because you had a passion for it (or strong hobbyist interest in it) and there were very few resources out there.

Putting 'node.js' on a resume today in 2012 doesn't provide the same signal. If only because of the hype about node itself. It might be signifying you're an early adopter, but it might also signify you're a serial early adopter, and that you'll jump ship for the next shiny thing.

rails/node/backbone - whatever their strengths are - signal something about you that might not be what you think you're signalling. And yes, it also says something about people like me who read something like that in to a resume with those technologies on it.

Developer is using platform A. Platform A is generating buzz/hype. Therefore, developer is too susceptible to buzz/hype?

similarly:

Developer is using Platform B. Platform B is not well-known. Therefore developer is passionate?

right.

The timing was different back then some, granted - I'm comparing 14 years ago to today - the pace of change and info distribution has changed. I'll still maintain that I'm wary of people with shiny-latest-buzzwords on a resume.

Doesn't mean I don't want someone to grow and adopt new ideas, but I see a lot of people adopting and promoting new tool X, then 6-12 months later, they've abandoned it (but the previous projects they worked on are effectively lumbered with it for a long time afterwards).

I'm probably exposed to this crowd a bit more by dint of going to local and regional meetups and conferences and such.

But...

"Developer is using platform A. Platform A is generating buzz/hype. Therefore, developer is too susceptible to buzz/hype?"

If platform A is less than a year old, and developer A is promoting it for production use to everyone they talk to, then yes, I say they may be a bit susceptible to hype (and I've been there myself).

Yes, that may be true, but there is a BIG difference between promoting a brand-new platform for production to everyone they talk to, and mentioning that they have experience with node.js (which is a few years old now) on their resume, that's all.

The answer to this is to have a portfolio full of "here are things I've built", with a complimentary "here is a link to my github".

Of course they should prove it. This don't mean the same kind of questions is always appropriate for every role. A web developer using JavaScript is very different from a C++ programmer.

This is a fair point. It does sort of depend on what you're interviewing for after all. If you are going to added to the web developer pool its not as important. But if you're going to be in an engineering leadership position, like tech lead, then you need to know not only how the web stuff works but also programming for things like the back end databases and such so that when one team says "we're going to rewrite the business logic that is fronting the back end in Erlang, it's going to be so cool!" You have some chance of knowing if that is a good idea or not :-)

> Yes, 10 years ago it did matter which function to use, because memory and CPU were expensive. Not anymore!

entirely wrong. if a candidate doesn't understand the difference between a linked list and a random access array, the difference between a hashmap and a b-tree, there's a good chance they're going to be making some pretty fundamental mistakes.

O(n^2) is still bad, no matter how much modern CPU and memory you throw at a problem.

As the interviewer, the question I'm trying to answer is "Can you fulfill a role we need fulfilled?" There's no direct way to determine the answer to that. However, a necessary-but-not-sufficient condition for a broad range of development positions is "Can you write code in any language to sort/reverse/find elements within an array".

The details will vary by interviewer and by role, but the basic idea is the same: if you are incapable of doing this, nothing you say in other interview portions will fool me into thinking we can hire you.

See http://www.codinghorror.com/blog/2007/02/why-cant-programmer...

This is sort of well-worn territory. It's been addressed with greater detail, data, and eloquence several times over. Threatening to puke about a commonplace whiteboard question really just comes off as obnoxious.

I don't see what the problem is with just memorizing the answers to these boilerplate questions. That way, you can be proactive about your response when asked. You can even just use your knowledge of the question to anticipate and disarm the interviewer's boring whiteboard exercise. But I guess being plaintive and edgy is as good a method as any to get to the front page of HN, right?

C programming interview questions are effective at detecting good generalist skills. I'm consistently surprised at how many people struggle with parsing an int from a string in C. Not that someone would ever do this on the job, but these questions are sort of the CS equivalent of math problems.

Another sad thing, which I gladly didn’t see that much (but there still were a few interviewers) in the Bay Area compared to the East Coast, is asking terms, function names, definitions, slang, etc. Expecting people to remember functions’ syntax is a sin in itself! All this leads to hiring people with good memory vs smart people. That’s especially wrong when all these information is only a Google search away. And being smart can’t be acquired or substituted with search engine results.

I hate this, and have run afoul of it multiple times[1] over the past few years. I once had an East Coast company decide I didn't "know Unix" because I couldn't regurgitate the POSIX API over the phone.

[1] My focus has always been on East Coast/Midwest companies

This reminds me of startup asking me verbatim quote from memory " what does python's lambda return?" Apparently he was trying to figure out whether i knew, it used the 'C' function pointer implementation. And the answer was function pointer. My annoyance with this is that, i was explaining my experience/past projects in python. This question is one level of abstraction lower than the context. I knew it used 'C' function pointer. I hardly got the question. I was answering, it depends on what statements you write within it. :-). Edit: And oh, i had a list lying in my drafts page and published now. http://www.blog.anandjeyahar.in/?p=1272

There's something else questions like these reveal - how you react to inquiries you consider "beneath you". Do you get annoyed? Do you preach? Do you adopt a condescending attitude? You might be able to do the tech work, but part of the job might be having to interact with various departments who just aren't as gosh-darned smart as you. How do you react when questioned about such 'trivial' matters? Do you lose your cool? You might not be a great fit for the culture of the org then.

Bad interview questions are actually quite useful, as an indicator that the company is not somewhere you ought to work.

I've had Facebook, Google, and Linkedin all use these... It's pretty systemic. :(

Just because some clueless monolithic companies don't know how to interview, doesn't mean all of us should follow in their footsteps.

True story, i know a guy who was denied a job at FB after an interview, a few months later they ended up giving him a few hundred thousand after they acquired the small company he ended up working for. He now works for FB.

Interviews are poor indicators of performance.

Or, he was a bad fit for the role he was interviewing for, and Fb --- like every other business in the world --- didn't have the foresight to consider every other possible role they could ever want him for.

Good point and an inspiring story... interviews like these are good indicator not to work there :)

I don't think it's a bad interview question, and I think the guy in the article is being a prima donna and missing the entire point of interviewing.

Enough people who can't code apply for software development jobs that asking a simple thing like "Write a sort function" is a good filter. Why waste 10 minutes on a better question when he can eliminate 50% of the applicants in 2? The interviewer doesn't think you're dumb and he's not trying to snub you - it's just how interview questions work.

If you're such an amazing developer you shouldn't have a hard time writing a sort function. Spend the 30 seconds to write the sort routine and get over it.

Any future employees who ask that I whiteboard for the will be required to whiteboard for me. If they're okay with it...then I am.

Awesome approach! :)

First, boredom is a problem of depth and duration.

Second, these are not hard questions. Bubble sort should be a slam dunk.

A few years back, we used a quiz that had the same divisive effects as fizzbuzz does today:

"Write, in your favorite language, a bit of code to reverse the bits in a word." This led to an astonishing fail rate amongst applicants that claimed to have a list of technologies on their resume.

> When is the last time you had to write your own array sorting function or function that performs search in an array?

About a month ago I wrote a merge sort routine in JavaScript where the comparison function is a person. There is no library function for this, because the response is asynchronous.

> There is always a function for that in a high-level languages like Ruby (index), JavaScript (indexOf) or Python (index).

These functions don't do what your interviewers asked. Python's index won't give you duplicates, and it's at least equally non-trivial to use JavaScript's indexOf with two arguments in a loop as it is to use a hash, and the algorithmic complexity of the former is much worse, so why would you do it?

> Another sad thing, which I gladly didn’t see that much (but there still were a few interviewers) in the Bay Area compared to the East Coast, is asking terms, function names, definitions, slang, etc. Expecting people to remember functions’ syntax is a sin in itself!

On this point, I agree.

1) array.sort didn't work for you? if not than this is an exception and could be an example of a good interview question ie solving a real problem 2) that is right, but in the algorithm of the answer you could use index function which makes code more compact

You'd be surprised at how many people fail the question "reverse this linked list", and of the people who pass that, how many fail the question "now do it without using recursion".

"Stupid" interview questions exist for a reason. They filter out a lot of people.

Well, nobody is arguing that they don't filter people (I don't think). The author seems to be saying that you could filter out just as many people with a more relevant and "modern" programming question -- and have a more accurate filter as well.

Anecdotally, I took CS I/II last year and still it would (probably) take me 5-10 minutes to remember how to reverse a linked list under pressure. I don't think this is a major concern since I never anticipate EVER having to actually reverse a linked list manually.

How about everybody that criticizes these questions, post their alternatives for determining candidates. It seems like everyday there are posts on HN criticizing these hiring techniques, but rarely does anybody post any alternatives.

there are alternatives in the post

Generally speaking, it's a good practice for interviewers to turn whatever problem they are working on into a simplified interview question and give it to the interviewee. This way they'll know if the candidate can solve problems that they'll actually face if they get the job.

Interview questions related to finding shortest path, min/mix of whatever, finding x numbers that sum to y etc.. will only tell the interviewer if the candidate has prepared academically for the interview.

In the end, the interviewer will probably end up hiring the wrong person. A person who has done his/her homework but cannot solve the simplest scalability problem.

110% agree, that was my point

When I interviewed at Google, they had me implement a basic regex parser in C on a whiteboard. I think that's a much better way to separate the wheat from the chaff.

You're not separating the wheat from the chaff with that. You're separating the cream from the crop.

It's a boring problem, but it reveals the candidates' comfort/experience with programming, approach to problem solving, and background knowledge of CS concepts. Those are things I'd want to know when hiring a candidate. These questions are used to determine competency.

If these are the only questions being asked in an interview, that is cause for concern. But they are useful for weeding out underqualified candidates.

yes, usually that was all that they asked, and that were mostly for the senior level positions

Knuth wrote Volume 3 just about searching and sorting, so there must be some interesting and challenging questions on the subject that could potentially be used in interviews.

Not that quizzing people on random pages from TAOCP is a good technique, I'm just pointing out that if you're looking for a series of increasingly complex questions to ask in an interview, searching and sorting is a rich area.

Finding duplicates in an array is a FizzBuzz question.

Yeah, well, I'll puke if I hear another badly mangled implementation of an array search again, so I guess we're even.

We use bubble sort as a kind of FizzBuzz test. Sorry, but we have to verify that you can actually write code. We can't go further without it.

Will you provide the bubble sort algorithm if asked? The first comment on this post also says they ask search questions as a FizzBuzz filter, but unless you will provide the algorithm then you're also asking it as an algorithms question.

You can't do bubble sort off the top of your head?

I'm not honestly sure I can. I can certainly do merge sort and a really naive quicksort, but bubblesort's not something I've ever written, nor have I even seen a description of the algorithm since my freshmen year of college or earlier. The name isn't exactly descriptive, so if I were asked to implement it I'd probably take my best stab at it and wind up implementing some other O(n^2) sort. Does that make me a bad programmer?

If you can do any real sort algorithm in real code off the top your head, bubble sort shouldn't matter, and any interviewer who punts you for that is interviewing for a job you don't want.

I can do insertion sort off the top of my head, because I find it very intuitive.

Bubble sort always seemed odd to me, and since I can remember insertion sort, if I ever found myself in the odd position of having to write a sort for a program without any reference materials, I'd just use insertion instead.

From looking it up on Wikipedia I found out that I would've remembered it, but it was around 15 years ago that I last wrote one myself. So I would've had to ask if it was the one where you iterate over the values and keep the largest, then repeat. I've learned these at the same time as the other generally known sorting algorithms, so names and details are quite fuzzy.

It probably depends on the position. As a high-level language developer I don't usually implement my own sorting algorithms. Either I use prebuilt libraries that offload work to low-level, or I use builtins, or I ask the database to sort it for me :)

Yes we would. I always wonder what to do when I receive three identical follow-ups. Answer three times?

If still within the window, you could just add an "edited:" to your comment including that information.

Nobody will be notified of my edit.

right, but you can at least hopefully prevent other people from asking. Comment Triage.

Ok who here over five years out of school remembers bubble sort?

Give me the Wikipedia article and I could code it in five minutes but I just don't remember the specifics of the algorithm. Does that really make me a bad hire?

Of course we will tell you how it is supposed to work.

Ok you're cool then :-).

I do, and school was a frighteningly long time ago. As a clue, I think the last language I coded it in was Fortran II.

That's somewhat odd... I've worked at some big companies and some small companies, and have never, ever been asked to code a bubble sort, either in interviews nor has it ever come up in production. Ever. I've been doing this professionally for coming up to 20 years (full-time professionally for 17, part-time before that). I'd possibly fail your interview. I wonder how I've survived in software development this long. That's not a snarky question either.

Reply on news.ycombinator.com