Logged in to second that.

I might not be the best programmer, I'd say that I'm about 'average', but I have about 20 years of experience building apps in a dozen programming languages and operating systems.

I could count on my fingers the number of times I had to solve a problem similar to these tech interview puzzles, like 'count the number of mushrooms that a person can collect in M steps' or 'How many jumps can a frog make' or whatever.

My issue is understanding the problems, because they have nothing to do with what I usually have to solve on a day by day basis. Added to that is the fact that many problems have some irrelevant clauses, just to fuck with you :).

Yes, you want the most efficient solution for a tight loop that runs on a list with a gazillion elements, but in a typical application, it's usually the only place where you need to apply deep CS knowledge.

And that thing has to be researched, usually a 10-minute investigation on google/stack overflow or just steal the solution from someone smarter than me on github, even if it involves translating it to a different programming language.

That's how the real world works.

99% of the code deals with APIs, UIs, file formats or network protocols, etc. Real, palpable stuff.

What worries me is that now these interview things are being automated and your 10 minute half-baked solution is being tested against huge datasets with all the possible corner-cases. Good thing in theory, I guess, but still irrelevant for the real world.

I've worked with interview ninjas who couldn't put together more than a console application.

> it's usually the only place where you need to apply deep CS knowledge

And usually, at the level you're talking about, you're probably going to be using a library that's been custom built for the problem you're dealing with.

Amazing how many people will yell out "don't reinvent the wheel" but would also not hire you because you'd choose to just use Apache Commons instead of writing your own sorting algorithms from scratch.

It is all true for most web / mobile jobs. But if you are looking to work on medical devices, driverless cars, AI / game development, image manipulation, fraud detection, machine learning, data mining, scheduling. Then the real world actually does work this way. You'll need to know these things. Even for uber or home joy, finding the right taxi / cleaning service to match the provider with the client on a map needs usage of graph and scheduling algorithms, and understanding their complexity. You are right that once this is done, most of the work is APIs, UIs etc. but someone needs to write these APIs.

Agreed. There's a lot of places where CS knowledge is necessary and those algorithms are usually the main IP of the company.

But these algos are developed during months or years of research, team meetings, white boarding and experimental prototyping.

These things are not developed under the pressure of a ticking timer (well, technically there is the time constraint, but usually the limit is more than 30 minutes).

Also, the problems are very palpable and concrete and the drive to solve them is much stronger than in an interview, where the anxiety of failing the interview hangs over your head.

You are conflating many things. Nobody ever has expected candidates to produce an answer that would be the equivalent of months of work.

Basic CS/Math/AI/Physics knowledge affords you a starting point that's further along in the development/tweaking of an algorithm. That is NOT the end point. Its simply - knowing whats out there.

If you start with "well let me go read about whats out there" you will only have time for superficial knowledge from wikipedia or what have you. Because that starting set of knowledge takes years to accumulate. Testing whether you have this starting set is a crucial setup in knowing whether a candidate is going to constantly end up wasting time reading up on basic stuff. You can't build a plane by opening a high school physics book.

One other thing is that when you have a broad enough set of domain knowledge in your head, its much more likely that you're able to connect the dots cross-domains. This is essential if you're going to be doing some interesting algorithmic work.

Of course, all of what I said is predicated upon you being interested in that sort of work.

Most systems I've worked with have a core piece that embodies the "hard" algorithm (as you say). The 80-90% of code required to make most user-facing systems work is not "hard" algorithm code in my professional experience. Why does every developer at a company that works on "medical devices, driverless cars, AI / game development, image manipulation, fraud detection, machine learning, data mining, scheduling" need to go through the same interview?

On top of that, I've never interviewed at a company doing that level of complexity where I was going to be expected to write it, from scratch. By the time they're interviewing people, they have something in place, and even if I actually could write it better, politics and personalities are likely going to prevent that anyway (or perhaps even legal).

More than likely you'll be working on a team, where you need to understand some of these concepts, and you'll grow in to them. Almost every single person on that team did not come in off the street with expert knowledge in those domains.

I agree that it has only been a few times in my 20+ years that I needed some CS knowledge to get a project done. However, when those times did arise, it was a complete roadblock for developers who lacked the knowledge.

It is the difference between being able to say, "I can code anything... some things are just harder than others." and "I can only do web development, and cannot be put on project requiring CS or advanced math."

Which does not mean you need a CS degree - on the contrary, I find self-taught coders to be quite good. But self-tech yourself at least some CS knowledge as well.

I really hope you are saying this tongue in cheek :)

I agree that tech interviews are broken but you can't say big O is rubbish for all coding jobs. Yes, when I was doing web development it was true most of the time (even then knowing the difference between scanning a list or lookup in a map/dictionary was helpful) but now I'm working on machine learning, big data, and it involves a lot of graph algorithms. All this academic rubbish is stuff that I need to do my job. The fact you can get a great paying job in mobile and web based on street cred is wonderful! This is how I got my first job without any official CS education. But I actually need to know how to prove an algorithm I developed is linear, I need to understand all known graph algorithms to know I'm not reinventing the wheel. For web and mobile and also enterprise you are right. For building self driving cars, search engines, databases, machine learning and more, you kind of ought to know all that big O, data structures and algorithm rubbish.

The concept is not rubbish, the interviewing technique is.

I can think of any number of people that can rattle off what O(n) means, yet inevitably write O(N^3) code given half a chance. And vice versa. And another group that forget the constants that big oh notation throws away very often really do matter.

Talk about efficiency, sure, why not? Throw a piece of code at somebody with convoluted terminating conditions on a loop and ask for the big oh, under pressure, while being worked? Rubbish.

+1 agree

>GitHub speaks for my talents

But the problem is most often I hear terms like "We love opensource and send us your github links" but I really doubt anyone (interviewer) bothered to look at them.

I at least skim a candidate's Github if it's on the resume or information I receive.

Gayle Laakmann McDowell has a good Quora answer on the pros and cons of tech inteviews:

http://www.quora.com/Why-are-programmers-in-the-software-eng...

It's worth reading the whole thing, but here's a summary of why alternative interview techniques have their own problems:

* Testing for specific technology knowledge excludes good programmers who don’t happen to know that technology.

* Asking someone to explain their past projects is biased towards people who can explain effectively, not necessarily people who can do the work.

* Giving candidates a homework problem has several drawbacks: they may have someone else do the work for them; it is biased towards candidates with more free time; and because it requires negligible time for a company to send off a canned assignment, but potentially a lot of time for the candidate to complete it, it can be unfair to candidates.

* Having candidates work on a real project for one day makes it difficult to focus on characteristics that distinguish great programmers from good or mediocre ones, since real projects have a lot of simple tasks that almost any programmer can handle.

* Letting candidates use a computer during the interview can cause them to focus on syntax rather than problem-solving.

Basically, although many people hate the coding interview, there's no good alternative.

I really dislike them too but I'd be shooting myself in the foot if I didn't study these problems. Learning them has also made me a better programmer since I graduated with an ECE degree and never had a formal data structures class. But it's not like I'm going to be implementing a prefix trie at my job anytime soon.

What's your preferred solution?

Honestly, I like to hear high level architectural decisions. Take a project the candidate did and just ask them questions on it. Talk and reason about it.

Then, hack on a small project for the hiring startup that would be useful. An internal tool or dashboard. Make it fun.

This isn't school, college, academia. We don't need tests. Companies first and foremost need good culture fits, self-starters, independent, passionate, people. In fact, I'm actually fine with having a (beer || soda) with a candidate, and just talking as a first step.

Seriously this is the best way to hire developers and have interviewed 100+ this way.

Tell them they have a billion dollars and they need to invent a pinning, photo, social, whatever site that can scale to everyone on the planet. Then give them a whiteboard. With one question you can determine how they communicate, their thought process, level of creativity, what they know, what they don't know and because it is open ended their nerves will quickly fade away.

The best developers are creative problem solvers not wrote learners.

That interview actually sounds fun.

Rather than a test that doesn't mean anything, you go on an adventure of code/design/architecture and you can see how the developer thinks/organizes and the depth of their knowledge and experience.

Hopefully companies start doing this more.

Judging by the jobs I have applied for lately, its all going towards an hour and a half hacker rank challenge, just to get the chance to speak with the technical department.

Makes sense.

My take is that it's best to make the 'interview' as close to representative of the actual job as possible. It sounds like you're on the money there.

I'm always wary of 'culture fit' though, it's an umbrella for all the personal biases and ill-informed gut feelings that anyone feels like shoving under it. Do you have an opinion there?

Discuss previous projects, experience.

I have serious misgivings about tech interviews, though I do understand why people do them. While I don't think it's unreasonable to ask programmers to demonstrate strong programming skills (even on what seem to be academic-ish problems), the process is bad enough that it is a bit of a scourge on the industry, and I do think it deters talented people from entering the industry, remaining in the industry, or applying for new jobs or pursuing new opportunities that would be a good match.

I think we need to start calling them tech exams rather than tech interviews. I think many of the problems come from the fact that we're acting like an exam is an interview. If you think of it as an exam, then you realize most "exams" in your life comes with some rights and expectations on the part of the examinee, and some obligations on the part of the examiner.

Here's my ideal wish list:

1) An exam should come with an associated study path. A good exam doesn't give you a set of questions with solutions to memorize, but you should know roughly what will be tested and how to prepare for it.

2) An exam should be conducted by someone skilled enough to recognize novel but good solutions.

3) An exam should be graded in a consistent and fair manner.

4) An exam should lead to a publicly acknowledged and lasting credential (you passed the bar, or an actuarial exam, you got credit for a class, you obtained a degree).

5) Ideally, an exam will come with some sort of feedback if you fail, with some opportunity to retake (not an unlimited opportunity but some kind of structured opportunity).

I've been through a number of tech exams, and most of them would be 0/5 on this list. Even the best tech "interviews" provided extremely limited feedback on how I did, even the best gave only very general information about what would be tested. My university exams typically met all the above criteria, including my exit exam for an MS degree. Certification boards often do as well. Standardized testing exams generally let you know how you did (how many questions you missed, sometimes what questions you missed), and perhaps what the breakdown was.

But in tech? Sometimes you get a study path (Steve Yegge's advice about getting the job at google is very good, if high level). Often, you don't know what you'll be tested on. If you do fairly well, just not quite well enough to get a job offer, you may very well remain unaware of this. I understand this is because of liability, but that doesn't really make it better for a student who may have put fifty or more hours into studying and is back to square one.

Think of it this way - imagine if you took the bar exam and did quite well, but a top law firm decided not to hire you. As a result, you get no credit for how well you did do, nor do you really have any idea if you did miserably, poorly, fairly, well, or exceptionally well on the test. If you did well enough to pass the bar but not well enough to get hired, you'd still have a credential. Not so with tech tests.

I understand some people may say this is the market at work, the price we pay for not having a formal system of credentials. Honestly, I'd happily take a "bar exam" for software development if it meant I wouldn't have to do it over and over, each time I interview (though I am not in favor of a required exam to work as a software developer).

In general, I support tech companies right to do what they think is best. I am free to opt out if I feel it is unfair. If they want to quiz people on difficult data structures and algorithms problems, at a whiteboard rather than terminal with compiler, fail them if they don't make enough progress in 45 minutes, and accept a high "false negative" rate, that is their right. It only starts to rankle/infuriate me when these same companies start raising an alarm about the "shortage" of qualified software developers.

Just a final word here - I want to be sure people don't think I believe I'm entitled to this sort of thing from tech companies, that they owe me this kind of exam. I came up with this list as part of trying to get my thoughts straight on why (some) people hate tech interviews enough to give up on new jobs or the field. I believe it is because exams are extremely stressful, and that many of the institutions that make heavy use of exams (actuarial profession, the bar, universities) recognize this, and have adopted a set of obligations on their part - a kind of "if we're going to put you through the gauntlet, here's what we owe you in return". The second half of this informal but actually somewhat venerable relationship between academic institutions and students is missing from tech interviews.