I've absolutely bombed tech interviews in the past, I now will refuse to do any. Particularly, because I've got some "street cred" with my startup, and basically my work with my company and GitHub speaks for my talents. I get it, you have to "vet" a candidate, but tech interviews in my opinion are not a good solution.
O(N) notation, data structures, academic computer science.... Rubbish.
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.
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.
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.
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.
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.
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 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.
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.
>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.
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.
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.
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.
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.
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?
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.