Study material for tech interviews(geeksforgeeks.org) |
Study material for tech interviews(geeksforgeeks.org) |
80% of the coding questions I got were really simple; things you'd expect any college kid who'd been through a basic CS curriculum to be able to answer cold. Not having just taken an algorithms class, stuff like that took a bit of thought. 20% were things like "implement coroutines in C using setjmp and longjmp" or "implement a regular expression matcher". How can you cram for that? Sure, you can cram for any specific question, but, given the breadth of the question space, your only hope is to understand things well and be able to reason out whatever comes up.
As far as I could tell, being better prepared was negatively correlated with getting an offer. I did well in interviews where I was totally clueless and had to reason things out from first principles. Conversely, I had an interview at Palantir where I heard the question I was being asked, so I said that. My interviewer asked me to quickly sketch the answer. When I did, he asked me another question. After repeating that process a few times he gave up and asked me a simple design question. Apparently, I failed that interview so badly that I got kicked out before lunch (interviews there are normally all day). In general, having heard the question before (and telling my interviewer), or having a flash of insight and being able to write down the answer without thinking about it seem to be taken as negative signals.
I was surprised by that until talking to a friend of mine who said "the interview process is this largely protocol driven song and dance where you're supposed to scratch your head and be wowed by the technical question and then slowly and painfully make incremental progress on a solution while the interviewer can feel smug about knowing it all along and maybe they can help you along the way. If you blurt out a good approximation in the first thirty seconds, that ruins the whole courtship." That's not true everywhere, but it seems to be true at most places.
There are, of course, non-coding questions. Those seem even less useful to cram for. You might be able to impress someone if you happen to know a lg(lg(n)) data structure you can use instead of a red-black tree, but most non-algorithms questions are about thinking on your feet; just having lots of knowledge won't help you there.
[1] This assumes that you have a solid background in CS fundamentals. If not, interview prep has a very high payoff.
When I'm interviewing someone, I want to get a sense of how they work through a problem and think about things. That sounds difficult right? It is, and your cooperation is appreciated. By saying you heard everything you gave the interviewer nothing. I guess you expected him to be a perfect authority figure and have an infinite vault of questions to throw at you.
Next time, try walking through one of the problems, explaining all the parts you find interesting, and bullshitting about what context it would be useful in. Try to relate to the problem and the interviewing process, and how it might fit in the job. You can be honest and joke about it if it doesn't fit. Remember, this isn't school and your interviewer is a coworker, not a professor with a hundred tests to grade.
Try and figure out how much he knows about the problem he just asked you.. and I bet 80% of the time the interview will go well if you show them something they're missing, or take them to the limits of their knowledge and show them something new or creative. People's egos tend to get in the way when you assume they will. Assume the best about 'em. Remember, the interviewer isn't a faceless part of The Machine out to dismiss you, but a potential coworker and friend that'll probably be happy learning something new with someone who can broaden their horizons.
In my experience, technical questions typically fall into two categories. The first is trivia about a programming language or other tool. The only people who need to "cram" for these are people who lied on their resume. Everybody else will answer these questions pretty easily just from working with the tools and having hands on experience. These are weed out questions to keep people honest.
The second category is to see how the candidate thinks about problems and solving them. It's not helpful to "cram" for these because the problem space is too large, and it would defeat the point anyway. If a company wanted people who've memorized "Coding Interviews For Dummies," they would just put that in the job requirements. In reality, the job they're hiring for doesn't have cookie cutter problems and solutions, and they want to see how the interviewee will work through a problem to find a solution. Knowing the answer to these in advance can actually hurt because it doesn't show them what they're looking for.
Your friend is exactly right, and there's plenty of competitive companies out there not demanding you physically take up a whiteboard marker to cock-swing out some algorithm in a political kowtow ritual. Asking for an answer or illustration of deductive process to a non-trivial question is a good litmus test of both talent AND enthusiasm/presence and provides entry points for deeper technical discussion but relying on a '2 line perl implementation of log(log^n-dimension) reimann curvature' as a source of truth rather than understanding the person you're humiliating and how they can augment your team if the Ruby Beard of Magic approves is absolutely absurd. Unless you don't care about the people or culture you're creating and just want the work done of course, because money money or whatever :D
Interviewing is a social event at least much as it is a technical one.
Remember folks, these companies are getting more from you then you are from them.
I think the the interviewer (or company) would probably take this as an insult.
But I do agree with you in that these types of interview questions are pointless. Spitting back an answer verbatim demonstrates nothing.
A neat approach that I've seen people use is to take a you-should-know-this concept such as the merging part of merge sort and put a twist in it, so it isn't a simple spit-the-answer-back, but different enough to require some thought.
Yet isn't it surprising perspective employees don't feel the same? Or maybe we do but we suck it up to get the job.
It also works for administering the interview!
There's really not much minutiae at all when it comes to C. C++, sure, I'd agree, but not C.
You do have to be be pretty comfortable with how processors and memory work if you're going to be answering questions in C, but that aside the language's syntax, keyword usage and standard library are all quite small.
So something that might be a couple of lines of Python or Ruby (just remember the library and the method calls), could wind up being a more interesting problem in C.