Tag: interview

UPDATE: You can follow the discussion on Hacker News.

Figuratively of course but still, array search, sorting and related interview questions are very boring, unreasonable and borderline irritating. Last month I was looking what is out there on the job market. All this hype about shortage of developers got me interesting in exploring new opportunities. I enjoyed meeting new people and learning about technological stack and problems companies try to solve. There were about a dozen phone interviews and a half-dozen face-to-face meetings. Most of the companies are regularly featured on TechCrunch. They are your typical VC-backed, 100–300 people startups. They have tons of perks as bicycle storage, tennis tables, free drinks and lunches, nerf guns, casual approach, lots of beer — all these tricks to lure employees. :)

Now here is the bad part. It didn’t matter much what technology startups use or what level of seniority was required for the position I was interviewed for. No. 95% of the time there were variations of array search and sorting, finding min / max value in array combined with providing big O notation, complexity and efficiency of such algorithms and functions type of questions. Two times I was asked exactly the same question:

Write function find_matches(haystack, needle) which returns array of all the matched elements needle array in haystack array with duplicates considerations.

The best answer to this question involves the use of a hash in which keys are values of needle array elements. And values are counts of repetitions of needle array elements in haystack array. Second time I’ve heard it I was bored even more than my interviewer, the VP of that startup. :)

I understand that there is never enough time in a startup. I’ve been on the other side of an interview process a few months ago. But I never took a shortcut. Maybe arrays are the only thing those “brain-dead” people remember from C++ class they took 10 years ago to fulfill their Computer Science degree requirement. Yes, 10 years ago it did matter which function to use, because memory and CPU were expensive. Not anymore! When is the last time you had to write your own array sorting function or function that performs search in an array? There is always a function for that in a high-level languages like Ruby (index), JavaScript (indexOf) or Python (index). And if you did write your own that is probably because you couldn’t find it (learn how to Google) or you didn’t bother to find it. In both cases it’s usually a bad idea because build-in functions are very efficient and your / our code is usually not efficient. Why test and ask for something which you are not using in real development? Why not look at candidate’s GitHub repositories, live websites and apps? Why not solve real problems your startup has at the moment?

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.

Dear interviewers, please be creative if your goal is to find creative, smart people! Also remember that code is not an asset. It’s a liability. The more you code the more you’ll have to maintain. :)