Study material for tech interviews(geeksforgeeks.org)
geeksforgeeks.org
Study material for tech interviews
http://www.geeksforgeeks.org
5 comments
Another way of looking at this:
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.
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.
This has been my strategy for a while, and it's always worked for me. I never study for interviews, and I can usually find jobs.
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.
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.
> "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."
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
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
I agree. It seems better to spend your time investigating the company and to try to obtain information about the interviewers with the purpose to discover some common ground, rather than to learn dozens of algorithms by heart, just to forget the a month later.
Interviewing is a social event at least much as it is a technical one.
Interviewing is a social event at least much as it is a technical one.
Then maybe they should stop asking algorithm questions that can be answered by cramming for a week or a Google search.
May I ask you in which company you've been asked about implementing coroutines in C?
[deleted]
can't forget those basic string manipulation questions too! :)
How about we collectively protest these kinds of interview questions. I vote that instead of answering questions, we ask difficult ones to our interviewers. When they protest, we explain "Just making sure I won't be working with idiots".
Remember folks, these companies are getting more from you then you are from them.
Remember folks, these companies are getting more from you then you are from them.
> Just making sure I won't be working with idiots.
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.
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.
"probably take this as an insult."
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.
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.
And if you want to see if you could literally, truly derive a working solution to any of these puzzles in a realtime interview environment, I make a tool for that: https://coderpad.io
It also works for administering the interview!
It also works for administering the interview!
All of these examples are in C , is it common for interviews to be conducted in C for major tech companies (assuming the job is not a C programming role)?
Generally the candidate picks their best language. Personally, I would never pick C because there is too much minutiae and not enough meat.
"I would never pick C because there is too much minutiae and not enough meat"
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.
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.
You spend half the time allocating memory, deallocating memory and checking error return values. I gave a couple hundred interviews at twitter, people that picked C wasted a ton of time not solving the problem.
A lot of higher level languages abstract away the fundamental implementation details and provide a lot more scaffolding than C.
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.
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.
Easier to write your own answer once you've seen how the C works in a higher level language than to go in the other direction, assuming you need this material to begin with.
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.