I hope this doesn't sound unfriendly but that is a pretty "boring" PR post. People are generally way more interested in learning about your motivations and what you do and what drives you. So in the future I'd suggest a way more personal OP.
Also the recaptcha box is misaligned in the layout (FF curren, OSX/MBP).
As far as I can tell, it drives home the point. Straight and without beating around the bush.
If someone finds the post as a boring "PR" job, then it probably wasn't meant to be read by that someone. Agreed, it's not the best of the introductions one typically reads on a TechCrunch or a Vogue cover, but it really hits the eye for someone looking for a job in his dream company, and is deciding to try the service out, having been really exhausted with all the other unsatisfying 'resources' already out there that promise you more than what they can seemingly offer, under the garb of all the "PR" they display on the surface.
It is frustrating how much time and energy is wasted on these useless tech interviews when it really has nothing to do with most real world jobs out there.
That was a question someone asked on Quora, and I thought there was an interesting discussion regarding joining Google as a mid-career professional (the conclusion was that it is not a good idea, Google is more fresh-graduate oriented shop - thus the need for that useless interviews, I believe).
As for personally me, these kind of interviews is one of the main reasons I've never applied to Google (other reasons: not remote friendly, not part-time friendly, and now I know - not mid-career friendly...).
I don't see how that invalidates his point at all. If our industry required an acrobatic performance by all applicants to tech companies, doing somersaults would get one into a certain position -- but would still be useless.
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.
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.
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.
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.
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 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.
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.
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.
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.
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 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.
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.
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.
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.
These types of nitpicky, detail-oriented comments are toxic. Who cares? The only thing that matters right now is that they solve a real problem and do it well. Anything else is peripherals at this point.
very good sight for the preparation of interview.The coachs are very helpful,they will listen your problem even at midnight and tell you the way to solve the problem
Well done, I'm really impressed, works well on mobile, feels like elevate for CS. Still lot of work, but better than anything else out there that I know of.
One obvious question: How do you plan to monetize? Become a hiring broker like piazza? Do these things work?
Thanks for this. I'm absolutely awful in Tech Interviews (I'm a competent developer but I'm overcome with self-doubt and anxiety in these situations) and I'm planning on a move very soon. I've been putting it off because of the stress of the interview process, so hopefully this will help!
To those who are unaware, in a country like India, there's real a lack of opportunities to work for top firms. What InterviewBit does is not just solve a problem of matching candidates with prospective employers, but solve the problem of preparing the candidate for the interviews. The success of interview books like one by Gayle Lakmann McDowell is an indicator enough that there's a huge market for this sort of stuff.
Courses like one offered by InterviewBit provides a lot of candidates with a clear curriculum to getting a job at a mega-corp like Google, Amazon, LinkedIn, Microsoft, or Facebook. Think of it as a highly specialized course in Interviewing. Of course, the right approach would be to what Recurse Center and the Insights Foundation are doing... focusing on the means (gaining expertise), rather the end itself (getting a job, making an earning); but that's not a priority in a country like India where STEM graduates by the millions graduate every year and only a smaller percentage of them land jobs at a "dream company" as it were.
I personally think InterviewBit is an excellent product/market fit for a country like India. They're also good acquisition targets for companies like HackerRank, and LinkedIn.
45 comments
[ 727 ms ] story [ 156 ms ] threadAlso the recaptcha box is misaligned in the layout (FF curren, OSX/MBP).
If someone finds the post as a boring "PR" job, then it probably wasn't meant to be read by that someone. Agreed, it's not the best of the introductions one typically reads on a TechCrunch or a Vogue cover, but it really hits the eye for someone looking for a job in his dream company, and is deciding to try the service out, having been really exhausted with all the other unsatisfying 'resources' already out there that promise you more than what they can seemingly offer, under the garb of all the "PR" they display on the surface.
FYI, the "useless" tech interviews are what would get you in, for now, or unless you are this guy: http://imgur.com/Fn1a8xr
You mean this?
http://www.quora.com/Is-Google-a-good-company-to-join-for-a-...
That was a question someone asked on Quora, and I thought there was an interesting discussion regarding joining Google as a mid-career professional (the conclusion was that it is not a good idea, Google is more fresh-graduate oriented shop - thus the need for that useless interviews, I believe).
As for personally me, these kind of interviews is one of the main reasons I've never applied to Google (other reasons: not remote friendly, not part-time friendly, and now I know - not mid-career friendly...).
Please don't do that here.
If you're interviewing, I maintain a list here (that desperately needs some attention from me, btw): https://github.com/andreis/interview
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.
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 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.
>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 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.
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 sur...
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.
0: http://startbootstrap.com/template-overviews/landing-page/
One obvious question: How do you plan to monetize? Become a hiring broker like piazza? Do these things work?
Courses like one offered by InterviewBit provides a lot of candidates with a clear curriculum to getting a job at a mega-corp like Google, Amazon, LinkedIn, Microsoft, or Facebook. Think of it as a highly specialized course in Interviewing. Of course, the right approach would be to what Recurse Center and the Insights Foundation are doing... focusing on the means (gaining expertise), rather the end itself (getting a job, making an earning); but that's not a priority in a country like India where STEM graduates by the millions graduate every year and only a smaller percentage of them land jobs at a "dream company" as it were.
I personally think InterviewBit is an excellent product/market fit for a country like India. They're also good acquisition targets for companies like HackerRank, and LinkedIn.
InterviewBit's co-founder on the product: https://www.quora.com/What-are-Anshuman-Singh-and-Abhimanyu-...