[Osiris]

Are algorithm questions really that useful when looking for a candidate? I find myself being really nervous about applying to other jobs because I'm not formally trained in CS.

My job and side projects are mostly web sites that require knowledge about how to architecture software but I very rarely write complex algorithms.

If something comes up where I need to optimize something I can usually spend some time Googling for some insights on how to improve it, but it's been 15+ years since I've written a sort algo. The idea of being forced to come up to a solution to an unknown problem on the spot makes me feel inadequate.

[millerm]

I'm a full stack developer. Currently focusing on iOS. Interview questions should really depend on the expectations of the type of software being developed.

I've been to a couple interviews lately and this has been the first time (in my career) that I have been tested (with time constraints too, mind you). I was either pointed to a whiteboard, or sat in a room with nothing but a couple sheets of blank (unruled) paper, a non-erasable pen, and a list of ~10 algorithms questions with a few to be implemented and their running time, and memory footprint to be explained.

I was not prepared, at all.

I have been developing software for about 17 years. Do you have any idea how many times in my career I have been asked to write a heap sort, a trie, or create a power set? Never. So, I had forgotten some of the specifics of how to implement them. Let alone on paper. A quick note... My handwriting is atrocious. I'm 41 and I am extremely embarrassed as to how bad it is. I can play classical guitar, but I screw up everything I write or attempt to draw. I thought it was a dyslexia thing or something, but I don't seem to have enough of the symptoms for that. That's pretty much why I liked using a computer when I was younger; I could fix my mistakes. So, needless to say, when I am asked to write stuff down I kind of freak out.

Anyway, there is a reason I have reference materials and the Internet. If I don't remember the specifics of something, I go look it up. I know what a lot of data structures and algorithms are, but I just don't bother memorizing all their specifics. I know what to look for. I read the description and can decide what the best thing to do is. Sure, I remember the basics of the major algorithms and data structures, and some of their their Big O characteristics. Implementing these isn't really what I do on just about any given day.

So, what have I been doing about it? I've been spending the last couple weeks going back over the "Algorithms" book (http://algs4.cs.princeton.edu/home/) and grabbed all the videos from the Coursera courses on the same book/topic.

I admit it's all my fault. I have written a lot of very successful applications over my career. These have fulfilled requirements for power generation, real estate, healthcare, search engine, and marketing companies. Using higher level abstractions (like using an OO language) with industry tested APIs for sorting, lists, trees etc.. kind of makes you push that stuff to the side because for 95% of the development, that kind of low level detail is just not necessary.

Now, of course, this really depends also on what type of development you do. Sure, if you are writing a lot of C code, you may need to manually write these structures. Or, if you are writing low level code (game event loops, collision detection, file system stuff, you know) that needs to run as optimally as possible, sure. A lot of us write applications that take in data, and spew it back out. Heck, a lot of developers are forced to write just a hell of a lot of SQL queries and they'll never see a data structure beyond a class file, an array list, and a result set.

Again, I am attempting to better myself now. I don't know how long it will be before I can answer some of the more crazy questions I have been asked though.

TL;DR I was not prepared, at all.

[tgflynn]

It's not "all your fault".

The problem is that there is a belief in the industry that 15-30 minutes of technical interviewing tells more about a candidate than that person's entire career history. I have seen no actual data to support this belief.

I think someone who has a history of having built successful applications is far more likely to be qualified than someone who happens to have a good memory for algorithmic solutions and performs well under the stress of an interview situation.

This interviewing approach may make sense for entry level candidates who have nothing more to show than what they have learned in their CS classes but applying it to an experienced professional is simply brain-dead.

[eshvk]

> The problem is that there is a belief in the industry that 15-30 minutes of technical interviewing tells more about a candidate than that person's entire career history. I have seen no actual data to support this belief.

Actually, this is only true when there is no social proof. Once you have people who can vouch for your successful application building prowess in some form or the other, you will find interviewing to be dramatically easier.

[millerm]

One of my favorite quotes:

"Never memorize something that you can look up."

--Albert Einstein

[lightblade]

Then again, you probably should memorize it after looking it up for the 10th time.

[millerm]

Statistically speaking, I haven't had to look them up that many times. I've a high percentage of the JDK memorized though, and a pretty good portion of the CocoaTouch and Objective-C Foundation framework. :-)

[nairteashop]

I think the answer to this is "it depends".

When interviewing engineers at my last gig, we tried to find people who will "get things done", which in turn depends a lot on your specific job role. For a good majority of the software dev positions we had, getting things done didn't require in-depth knowledge of arcane data structures or algorithms. We just needed the candidates to be smart, and ideally have some experience in what they were being hired for.

So for say an iOS dev position, we would pick the candidate who had released two apps on his own but maybe didn't know much about say red-black trees, vs. the candidate who knew all his CS theory but hadn't yet written a single line of iOS code. We also valued good communication skills, and what Linus refers to as "good taste".

However, we did have a few roles (machine vision, big data, etc) where algorithmic knowledge was essential to getting things done. And for these roles, we always favored candidates who had excellent math & algorithmic chops.

So it depends. I think the problem really is that most interviewers run all candidates through an identical "favorite list of questions", regardless of what the role is. This is quite unfortunate.

[onedev]

If I hear the words "get things done" one more time, I might just flip out....

Sorry this isn't directed at you, but I view that phrase on the same level as "changing the world".

[nairteashop]

No offense taken, but I'm curious as to why you hate that phrase.

"Getting work done" is essentially what we're hiring people for right? As long as you can get done what you were hired to do, it shouldn't matter whether you suck at algorithms, are not a "ninja", don't fit "culturally", and whatever other weird things companies look for in candidates. It's as prosaic as it gets, and IMO it's the absolute correct metric to use.

It's as different as it gets from "changing the world", which honestly very few companies are actually doing, and is hence a source of irritation for me as well.

[gibbitz]

It's important to make a distinction between two different types of "get things done" here. There is one type where the candidate figures out what needs to be done to complete a feature in an application and does it. Then there's the type where the candidate figures out what is the least work (ie fastest way) and does that without trying to understand the potential outcomes. Given that the slapdash candidate is great at patching bugs I would maybe consider him/her, but frankly I prefer people who measure twice and cut once. I know that sounds like a separate concern --it is-- but some business cultures confuse work ethic and results along the lines of "gets things done".

[eshvk]

> Are algorithm questions really that useful when looking for a candidate?

I go back and forth on this. I do machine learning/backend large scale engineering stuff. I have typically found that very rarely do companies actually really grill me on these things. It is mostly computer science theory (a.k.a algorithms/data structures). It used to annoy me a bit especially many questions have embedded tricks that make them dramatically easier. E.g. checking the validity of a BST is as simple as checking that the invariant left subtree is smaller than the root and right subtree is larger than the root is maintained. How you choose to implement that might trip you up, even if you stumble upon the fact that recursion is necessary and key.

On the other hand, once you intensively go through the process of studying these problems. You become aware of how incredibly rich the field of practical usage is. For example, order statistics can be efficiently organized using a rank tree. These are clever tricks that it is nice to have floating about in memory. Because they help you know what to google for.

[millerm]

I like your statement. Especially "Because they help you know what to google for." That's been my thought pattern in general.

[flipside]

Does anybody conduct "open book" interviews? I'd be more curious how someone goes about finding the answer than if they knew it on the spot.