Cracking the Coding Interview Tutorial
hackerrank.com
hackerrank.com
Technical interviews aren't the problem, is when interviewers already have an answer they want, and if anything strays from it, they just flat out refuse the answer. Sure datastructure X maybe better when getting to a million items, but for most use cases, Y is valid, and when Y is a problem, I can easily google an alternative, but nooooooo, it has to be X from the start because or A B or C.
I like being chalenged in a interview, talk about various topics, but if for every question you have, you have one and one answer only, and any other that may fit but isn't on your spreadsheet is wrong, then seriously, F U.
Fortunately also talked with other companies that were more sane, but this 'My way or the highway' from pseudo engineers is what is wrong with hiring in tech.
Aren't you saying the same thing to them when you decline to move forward? Looks like your both have the same message just relative to your position in the discussion.
When someone says: Maybe you could use a binary tree. and the reply is: No, that is wrong, what you need is X, is a different thing.
Beste inverviews I had were always a give an take. I talked algorithms, data structures, etc but never with the interviewer having a one solution answer. Best interview questions are like:
Ok, we have this domain problem, what can you do about it? and then spend a couple hours on a whiteboard on a back and forth discussion about it, maybe you get it right, maybe you dont but have another idea, etc.
When you know more than the interviewer, it's actually tough to handle that situation. I'm honestly not sure how to handle it.
This is the root cause of interviewing being shitty.
Citation needed. I frequently see the dangers of false positives exaggerated and the costs of false negatives downplayed.
Of course there are gradients to bad hires, but the really bad ones are a terrible experience for everyone involved.
The rhetoric is that a bad hire is pretty much the worst thing ever, and it's used to justify absurd interview practices.
Several citations in there, but it seems like a common sense thing to me. Why interview at all if you're so willing to take on the risk of a bad hire? Just take them out for lunch and ask them how they like coding.
It's also bad for recruiting purposes. If I have an easy interview I'll be reasonably assured that my future coworkers went through that same process -- what metric do I have to assume they're going to be good engineers to work with?
That happened at multiple companies I worked at, both small and large, and it just makes me terrified to hire wrong.
If you're in an environment where you hire fast, but punt fast, you can give more people chances to prove themselves. Honestly, it would help with diversity, too. If people are as good as they claim, they don't have to worry about a thing.
That's a completely self-imposed cost. A company with a process like that has no business whining about the cost of bad hires.
That's the consequence of deep pockets, unfortunately. If you're a young startup without much in the way of assets you certain can hire quickly and fire quickly. You don't have any asserts to sue for.
However, if you're a Google or Facebook, suddenly the stakes rise. They can always find a way to make the firing seem unjustified if they're fired on short notice, from ethnicity, gender, "culture fit" (I didn't want to go out for drinks with them), or age.
And it only has to work once for the disgruntled employee, and then they don't have to work for a while. And you better believe that a lawyer will take the chance to sue a large tech company on a contingency basis.
That's why there are so many frivolous lawsuits in the US. If you can make a halfway reasonable claim that you're not being malicious in filing the suit, and your lawyer is working on a contingency basis, you really have no downside, whereas the guy you're suing has a huge downside.
It's about differing incentives.
There are several variables involved here.
First, what's the possible payout. If the lawyer had a 10% chance to make 10 million, that would be fairly profitable. If he only had a 1% chance to make 10k, not so much.
Second, what else is the lawyer doing? There's a glut of lawyers in the United States right now. If he has his own practice and there's not much business, he might as well take the case. He wasn't getting paid for sure anyways, he might as well take a long shot.
Finally, and the part the makes the US a hotbed for frivolous lawsuits, is the question of whether or not large judgements will be enough of a deterrent for the defendant to settle, regardless of the merits of the case. Look at patent trolls suing amazon, and getting settlements of millions of dollars because they patented an online shopping cart.
Same thing like that, especially if you're a smaller business. The settlements are likely to be lower and the reward less, but they're more likely to pony up 5k to just make the problem go away without the courts getting involved.
Most companies I've worked for had people who thought firing someone was immoral unless they did something criminal. Essentially, its the company's fault for messing up in the hire process, and the employee should not have to suffer the consequences. So the employee stays in anything but the most extreme case.
Freagin sucks.
But, as with most negatives in this discussion, overblown.
> Most companies I've worked for had people who thought firing someone was immoral unless they did something criminal. Essentially, its the company's fault for messing up in the hire process, and the employee should not have to suffer the consequences. So the employee stays in anything but the most extreme case.
That is a ridiculous position, IMO. While those people would probably consider me a sociopath, I don't see any moral imperative to maintain a business relationship beyond what was explicitly and honestly agreed to in assuming the relationship. The company has no paternalistic responsibility to its employees.
I would sooner invest in training somebody from the ground up, even straight out of college, if I knew that they had the humility to listen and apply their learnings to their job. It'll cost me team resources and it'll take time to get them to where I need them, but as long as I can find junior level work for them to cut their teeth on, I will take them over someone who doesn't learn any day.
The problem is that training is expensive, so I need to filter for people who will give me good ROI on training. I'm not afraid they'll leave. People who feel that they are learning a lot generally won't leave their job unless you're doing something shitty to them.
Which brings us to the common debate about how big the talent pool really is. On one extreme, you have the argument that competence is really rare and the applicant pool mostly sucks. On another extreme the applicant pool would be huge if companies would be willing to train employees. In my experience it's somewhere in the middle: there are a lot of okay people who can do certain jobs to a certain level, but most of them have an immediately visible growth ceiling because they are not as adaptable or reliable as they need to be, and as a manager it's very hard to give such a person more challenging projects to grow into.
Some of this is a managerial problem. Some managers are better at developing talent than others. Some managers are better fits for certain employees.
However, there are also employees that are just not reliable, or culturally toxic, or unable to deliver the level of results you expect for how much you're paying them. You pay the cost for such employees in taxes on team morale, project cohesion, and predictability of execution, all of them leading to projects weirdly taking far longer than they should and ending up far more complex than they needed to be.
So making a bad hire costs you much more than just the money you paid him/her. However, it's not clear that you have more to lose on a bad hire than you have to gain on a good one. That's how I ended up on the "fire fast" approach, but that had its own pros and cons.
It does? I find incompetent people are generally easy to spot. As in, almost instantaneously (or at most, within a few hours). It's almost as if they want to show you how incompetent they are.
But the "long-term" bad kind? Generally that's not incompetence, per se, but personality issues ("I only wanna do it this way", "I don't want to learn / won't work with people who use X or even don't look down on it like I do", "I just don't give a fuck this company or any of youse", etc). Which by nature are of course much more difficult to spot.
And which are a completely different (orthogonal) set of issues than those addressed... "this idiot didn't immediately see the dynamic programming approach which I knew about already because, of course, I picked the problem. Even when I stared at him impatiently and distracted him with hints" style of filtering which seems to be the goal of the modern hiring process.
Issue with interviewers is that they invariably think themselves smarter than they are. For instance, just because something has a linear programming solution doesn't mean it doesn't just have a closed form solution too (most software engineers that have interviewed me would say "closed what ?", I feel). I've found, often, on interviews that you have to lower yourself to the interviewers' level to pass. Even when the problem is not so much that the interviewer doesn't know the stuff at all, the problem may be that they don't know it well enough to have a thorough understanding of the problem without preparation (and they never prepare), so they simply can't deal with other approaches. Or they provide a "warmup" question that is ridiculously hard or easy, and don't deal well with the fact that you approach it very different from what they expect for the real question.
Very few engineers, even at companies that claim to be different like Google or Microsoft, truly have a mathematical background in algorithms. This does not seem to stop them from often smugly pointing out the "right" solution from a blogpost that happens to be flat-out wrong, ill-specified and handwavy, to a Math PhD. Putting any math on the whiteboard in such situations is a bad idea. Even just pointing out the flaws in their assumptions ... Constructing a proof that it's equivalent to a well-known problem with lower complexity than their optimal solution does not often end well, as they neither can nor want to understand actual algorithm theory. They don't know the assumptions they use, and never once have I known one to question if the assumptions apply to the posed problem.
And about preparation -- it's not so much that they ask pretentiously hard questions sometimes. It's that their own level of preparation, correctness of execution and general forethought will only very seldom even roughly match what they expect the candidate to deliver. As in, they screw up all the time -- everything from picking the problem to stating the problem to stating true expectations (these are basically almost never stated) -- to simply listening to another person's perspective on it... to just watching the clock and their body language and tact in general. Yet candidates are almost always expected to deliver near-flawlessly.
As to big companies: I've found the solid majority to be quite considerate about others as human beings, generally (abstract questions about their company's impact on society or the environment aside). But as a general rule, the larger the company, the more the "not giving a fuck about this company" measure approaches 1 - uniformly and geometrically.
IMO, the key thing is that interviews are designed to give political cover for the interviewers to make the hire. If and when bad hires happen, the interviewer can say that their process was technically challenging, even if it did end up rejecting someone like Brendan Eich and passing someone who put 200 hours into Cracking the Coding Interview.
At this point, what happens? If they can actually do the work, then you are fine. If they can actually do the work but not as well as you want, maybe they can be trained. If they are completely incapable of doing the work, every state is At Will, and though I know from personal experience firing someone is no fun, that is the risk you take.
I believe the threat of someone talking a good game but being unable to produce is vastly overstated. It absolutely happens, but the harm is minimal.
"Very tough"? The only big company I ever worked at was a more traditional engineering company, but identifying the poor performers was easy. The problem was the politically-savvy poor performers who used their savvy to shield themselves.
The first 90 days on the job usually don't require much code output. This is more than enough time to either learn what is required for the job. If it's too much, you still can find someone on Fiverr that you can outsource your work to.
You poke at their bullshit until the stench is overwhelming. I personally find a variation of "Five Whys" questioning very useful. Bullshitters can only go a level or two deep and so trip up fairly quickly.
I don't know, specifically. But not asking bullshit questions would seem to be a good place to start.
Yeah, that's a really hard thing to do. I try to think of many solutions to the problem I'm giving ahead of time, but that takes a lot of time and I know I'm not going get each one.
Obviously it's your prerogative to decide where to work. But walking away because you didn't like a single interview is a little bit petty.
One could swap "a company" and "one engineer there" and still have a perfectly valid argument.
To be fair, I might have been that guy 10 years ago, and I was probably quite an annoying know it all co-worker then, but now, after close to 20 years in the industry, having worked in software that is used by millions, being a referenced author, honestly, no, I refuse outright to deal with bullshit like this. I don't expect everyone to think what I say is right (because it isn't) but to just dismiss it since it isn't THEIR answer, is a RED flag for me and I would prefer not to work there, no matter the offer.
I keep hearing about a shortage of quality talent in the industry. Given that, I would expect employers to pay particular attention to putting their best foot forward in interviews -- since interviews work in both directions.
One that fails to do so -- or whose best foot is off-putting -- is revealing that their attitude toward potential hires and/or their ability to offer a good working environment is poor.
People talk about how a bad hire is a significant cost for employers, but taking a bad job can be a much bigger cost for the employee than a single bad hire is for an employer, and quite worth avoiding.
"Best" (in doing interviews) is not a criterion that lies on an ordinal scale, but is a multicriterial property.
I ask because we interview lots of candidates who always jump straight to their favorite data structure. Given any algorithmic question, they'll immediately create an instance of their pet data structure (usually it's a HashMap), without specifying the types of keys or values. They can't explain why they're choosing this, and continually try to shoehorn the problem into it even when it makes no sense.
This interview doesn't sound nearly that bad to me. It sounds like you were discussing the advantages / tradeoffs for your choices, given various performance considerations. How do you know they considered you "wrong"? Maybe they were seeing how you reacted to being pushed.
When I test people's reaction, it's generally not because I want to hire them. I just want to learn about people. If the purpose is hiring, overreacting but good coder will not take the job, under-reacting but good coder will not stay long because he/she will get angry eventually, over-reacting and taking the job seems desperate... I just don't see what can possibly get out this kind of test from a hiring perspective.
I don't know the correct reaction, and don't do this when I'm interviewing. My point was that I could easily see a different side of this story, from the interviewer's perspective. Maybe the interviewer understood the OP's solution, and wanted them to explore a different angle.
We're lacking so much context here - what did the interviewer actually say? Was their tone gentle or aggressive? Were they flat-out ignoring the OP's answer, or acknowledging it while taking it through different use cases? We can't know, we weren't there.
I understand there are many places with poor interview practices, but I've seen enough devs come out of these types of interviews with wildly incorrect self-assessments that I no longer blindly trust these anecdotes. Unless they told you the exact reason you failed, you're speculating. And if you're an engineer that repeatedly gets turned down after these interviews at many different shops, you may not know what you don't know. Complaining about the interview process isn't a productive way to improve in those situations.
[note that my critique goes both ways: I have no way of knowing OP's skill, and their story could be completely accurate. however, I see this attitude a lot from overconfident junior devs, and that's to whom this rant applies.]
What's horrifying is there are now people (occasionally) on /r/learnprogramming where the person can wax on for ages about obscure data structures or algorithms, but you ask them something simple (What sorta unit tests would I write for this? What should I keep in mind before deploying this app?) and it falls apart, they don't know how to program, they've just been reading crack-the-interview type books. (though at least that shows a _lot_ of gumption, dedicate, intelligence)
Well. Communication problem exists with professional hirings as well. I blame engineers' lack of empathy (both interviewer and interviewee).
Exactly as the standard modern interview culture incentives them to do.
I can't wait to be done interviewing so I can go back to working on fun side projects after work.
> where the person can wax on for ages about obscure data structures or algorithms, but you ask them something simple (What sorta unit tests would I write for this?
And
> I expect its the same reason google asks (used to?) everyone about red/black and b trees. Same thing, just levelled up a level.
This is quite presumptuous. After all, even the folks who actually invented these data structures went through many, many iterations of failed attempts at data structures before finding out that a red/black tree or a b-tree is the right "problem-data structure" fit. Does their previous failed attempts mean those people didn't know what they were doing? These data structures were iteratively and slowly refined into what they are today: does anyone believe they just "struck" the inventors as the right structure for the problem at hand?
Suppose the "right" data structure is more complex than a hashtable. How often are you running into this data structure in your code base? If it really is a lot, you PROBABLY know how harsh it is to judge a candidate by their inability to come up with the appropriate data structure for something more advanced than a hash-table. Don't believe me? Go and look at the many open source projects you use at work today. What is the most advanced data structure you see there? Now ask yourself how much value the programmer has provided you by creating that project? Would you reject that person if you found out their data structure knowledge maxed out at the hashtable? (Of course, if you are actually some company where the impact of the correct choice of data structure can be directly observed on your bottom line - you are already an outlier. What are you doing dispensing generally applicable advice?)
And lastly, based on what I see in the comment, suppose the data structure is more complex than a hashtable, say a tree. Would you ask whether they have used/maintained tree data structures in their code before? If they have not, will you chalk it down to lack of exposure, or lack of smarts? If you are keen on seeing if they can write recursive code, surely you have some simpler ways to test that?
Whatever ability you THINK you are gauging by choosing the candidate who can do a spontaneous problem-data structure match in an interview environment, it is more likely you are just optimizing for the time you can spend on a given candidate and then justifying your decisions based on their failure to answer "a simple thing such as X". There is an excellent chance the candidate could go out of the office, spend a few hours thinking about it deeply, and come up with a clever, maintainable solution to the problem using neither a hashtable nor the data structure you have in mind. They may have failed to meet your expectations, but there is a not very small percentage possibility that this says more about the interviewer's time constraints rather than the candidate's abilities.
So -- do people "push" each other around a lot, in your environment? Just to, you know, see how they react?
By like, you know, having a normal conversation. "I'm curious about this project this little repo of yours. Is there some particular reason you chose to use to use / not-use X", for example, where you're asking because you're genuinely curious, as if they actually had something to teach you, perhaps.
If they're legit you'll get a solid answer right away. And if they're not legit... you'll find that out just as fast. But the whole idea is to maintain flow and authenticity. And keep it framed as if you're learning from them, not sitting back and grading everything they say and do on some unseen scale.
And if you're not learning anything? If there's no flow, authenticity? That's when you know it's not going to work out.
Especially people in favor of endless whiteboarding and zombie-like quiz-show sessions.
This kind of question is exactly what I had in mind when I said "pushing to see how you react." I think we agree :)
Here is my issue with this reasoning: Y could turn into a problem in production and cause real impact of the business before you know it's a problem. You're writing hundreds of Y's over the course of months as the project goes on so some amount of first-guessing is good to have. You don't want to play wait-and-see with all of them. If it is a product where demand can spike very rapidly then it is more important to take the time to find a best solution first. One day, you thought Y would never reach this magnitude but it just did because something went viral and the internet is essentially DDOSing you (happens all the time with sites posted here going down). And some companies may take to this approach on the first step and don't want to wait until things fail to realize they used the wrong data structure for this demand. Because often, it only takes a single thing to break a product or produce the wrong output or fail gracefully.
Now naturally if your interviewer wraps this problem up in vagueness, confusion, and gotchas then you aren't going to do well. A sane interview should be more than willing to answer questions about magnitude and that tells you that Y is now a problem and you need to think of a better solution than your first one even though it is fine for most use cases.
If it seems like they were trying to confuse you or just throw their ego around, just write this business off. They are only interested in playing slots. They pull the lever until eventually someone walks in and just happens to know the answer and also wants to work there.
It will make sure you don't try to design for a billion users when you have a thousand but still gives you decent room to handle spikes and more time to write a more lasting architecture.
I recently interviewed for a position at a small Amsterdam based company. They simply asked me to work with them and refactor a part of their code base. It was really interesting and frankly, we all had lots of fun during the 3-4 hour process.
Coming from the USA, it was eye opening to see the ingenuity of this simple way to determine candidates ability. It's such a shame that Stack ranking like HackerRank are being favoured instead of on-job evaluation.
1. Coding challenge <- Your interview was mostly this.
- Make an object
- Make a mini-app
- Fix this code
- Refactor this thing
2. Design a program on a whiteboard
3. Algorithmic & Data Structures <- Cracking the coding interview helps here, and is the type many engineers struggle with.
4. Hiring manager interview <- the most subjective
People also will bring up if you're an asshole in any of the above interviews.
[1] Google gets 2 million resumes a year https://www.fastcompany.com/3044606/hit-the-ground-running/g...
[2] Headcount increased from 57,148 to 66,575 between Q2 15 and Q2 16: https://abc.xyz/investor/
I don't see how whiteboard-style coding interviews can scale any better than that approach.
None of these are strict requirements. Individual groups who are hiring can decide best what kind of person will make a good team member, and should be largely charged with hiring one (with some cross-team supervision to remove obvious biases).
It's humans you are hiring, not AWS instances –– a process that easily scales to large numbers (like HackerRank) should be viewed with some skepticism.
Coming up with a scalable hiring filter mechanism that doesn't belittle or frustrate the kinds of engineers are you are trying to attract is fundamentally not the problem of your hirees.
Now, maybe the top engineers will suffer through the process, in which case fine, run the whiteboard interviews. But increasingly, it seems like the real cream of the crop are saying "companies that run these kinds of interviews are too rigid for me to be willing to work for them".
Complaining about it won't actually attract those engineers back, because _your_ hiring process is not _their_ problem. They don't care about your hardships, and why should they?
First impressions matter, and if their first impression of your company is that you make everyone you see jump through arbitrary hoops regardless of merit, it's not really surprising they might not want to work for you. Telling them that the hoops are needed to keep the riffraff out hardly improves your image.
Maybe you'll have to accept you'll have to hire some bad engineers in order to get the great ones, and do the filtering as a longer process.
Maybe it's not possible for a 50,000+ employee company to have a hiring process that isn't belittling.
Maybe there's a third technique others haven't worked out.
But whatever the answer, you can be damned sure that complaining the world is unfair won't actually solve the problem for you.
To be clear, I can see why big companies prefer coding interviews (it's more "consistent" when interview feedbacks are boiled down to a score), but at the same time I'm not defending it because like many have said it's not a great measure of an engineer's capability. I'm looking at the problem from the employers' point of view.
I do not believe this for a second. The real cream of the crop comes into these interviews, passes them with ease and sometimes even enjoy the process. The worst companies I've seen had low hiring standards, they let any fool join the company and then that fool will go on to interview other fools and lets them join. It's like a cancer and rejecting a few potentially good candidates is worth preventing it.
I have been hired at both G and MS. In my tenure at both, my connects (performance reviews) have been stellar (you'll have to take my word on that, unfortunately).
At the risk of saying something I should never associate with my professional profile, I have also been rejected at both, in combination ~5 times to the 2 I was accepted. (both prior and post my acceptances at each place).
I reasonably consider myself to be a "good engineer" in a pragmatic, "you pay me money to make your company money" sort of way, however, I would not say I pass the interview process with ease or enjoy it; and would VERY MUCH say the process puts me off interviewing for companies I know behave this way instead of just waiting for a prior coworker who trusts my output to say "hey we need someone"; those latter arrangements have historically worked out far better in the long run for me given both outcomes and ROI of time spent in the process.
While I certainly welcome that I am either a fraud or an outlier, the fact that I've heard similar stories from coworkers I see as very high end engineers allows me to assert at least that this occurs (interviews putting off good candidates) although not necessarily how much.
The fact of the matter for me, at the end of the day, is the common lament: if the interview (and when it is) even VAGUELY about what we do day to day, I will surf without blinking, with the exception of the occasional "culture fit" rejection which I've come to accept in stride, but between those rejections and the sheer volume of "I clearly don't want to be interviewing today so going to make this hellish/I expect a magic question to a problem I prepared ahead of time" that I've seen, it seems divorced from reality that such an often arbitrary and painful process wouldn't put people off it. I recently likened it to be most similar to what it used to feel like to ask out someone in middle school, when you felt somewhat clueless despite your best effort, with low chance of success and high chance of shameful failure.
I think you would be hard-pressed to demonstrate that their processes are consistent.
Sure, interviewers themselves are inconsistent (accents, prejudice, interview difficulty, etc), but that's not something that can be fully mitigated when every candidate gets a different set of interviewers.
Again, I'm not defending the practice and would just like to have a constructive discussion.
Technical chops are a prerequisite, of course, but they're useless if the candidate doesn't make the right tradeoffs and technical decisions.
I actually didn't even notice this conflict of interest. It would line up exactly with how such an awful class of product has gotten so popular. I've been subjected to HackerRank tests before, along with a few competitor's products. They are universally demeaning, insulting, infuriating, and useless as an indicator of skill.
(or if you want to be mean, take it, answer every question with a variant of 'this is dumb' and then email the company saying they just wasted their money on these systems)
But given that it's most likely the result of junior hiring managers giving marching orders to junior engineers (i.e. the people conducting the screening) who just don't know any better than to say "no" to such a silly and insulting request to make of incoming candidates... the depth and reach of this annoying fad becomes less surprising.
On the other hand it would be idiotic to expect people to be able to code in IDE XYZ (whether it has vi and emacs mode or not).
I've been looking for full time employment for over 6 months now, doing contracting to make ends meet and to stay involved in the industry. I started out doing the tests, putting lots of effort into the insipid take home exams, and so on. It amounted to absolutely nothing. I'd get invited on site, get tortured with a whiteboard for 6 hours, and get no offer.
Meanwhile, contract "interviews" have been "What have you done at your previous jobs?", "How can you help us do $THING", and finally "What's your rate?". They have, unlike FT interviewers, understood that I am telling the truth about what I have done, what I can do, and how I do it, and so didn't require a college test to prove it.
The only alternative is to be at least -somewhat- compromising -- as I don't mind these tests too much, if they're on the short and sweet side (up to 90 min timed, or 3-4 hours untimed). But once you've decided what your limit is, hold to it. "I'm sorry, but I've done enough of these already -- sometimes without getting any response at all from the company, even though I felt pretty confident my solution was at least ballpark correct -- so unfortunately I can't justify the time investment for your drippingly pretentious mandatory 4-hour HackerRank hazing session."
(Same goes for ridiculously over-hard and/or over-rushed algorithm questions which in realistic terms almost no one is able to genuinely "solve" in the time provided -- unless they crammed and/or did them very shortly before. Just sit back and assess the situation for 5 minutes before jumping in. And if, heaven forbid, you don't think you'll be able to crank out the flawless the solution they'll undoubtedly expect in the next 35 minutes -- just say, "I'm sorry, but I done challenges like these before and I just don't they're realistic problems to ask people to solve on the spot. So I'll have to pass.")
Of course you don't have to use the exact phrases "drippingly pretentious" and "mandatory hazing session." But at least you're giving them a qualified rejection (instead of "Neah, I'm just too cool for your shit.") Which they'll also almost certainly decide to pass on you for. But if so, then at least you've managed to hold your ground, and keep your head up.
And who knows, maybe at some point these companies will start looking at the response data on these poorly considered "challenge" tasks -- and will move on to some other filtering fad.
As if for the same crop of... for want of a better term... "kids" who had the whole stack-ranking and "human beings are infinitely measurable and weighable" ethos so relentlessly and successfully drilled into them from pre-K up through graduate school -- there's not even a question of jacking up and scaling out that same system out into the professional working sphere. It's just the way universe works.
And so of course getting a leg up and "making it" means cramming one's brains out for however many months as necessary in order to graze whatever "bar" they set because... that's just what learning is, right?
And if it were 100% about preparation -- if preparation could land anyone any job they wanted -- then the interviews would be mostly worthless (other than perhaps assessing how much work someone is willing to put in).
The reality is somewhere in between: Preparation helps someone perform at their best, but it will not land anyone any job they want. This is why tech companies actually encourage preparation -- it reduces the number of good candidates who get rejected.
Note that this isn't really unique to coding interviews. People prepare for ALL types of interviews, so it's revealing the same flaw in all of them.
HackerRank is a symptom of the terrible interview cult that is pervasive in our industry which is so extremely guarded against the fabled false positive hire. It is designed with absolute certainty that no one is qualified for any job unless they are some silly notion of a 10x engineer or "hacker" while claiming there is an engineering shortage. It allows us to opine about how terrible impostor syndrome is while simultaneously engendering it in others through these interview practices. It allows us to write off people with experience who are further out from college (and therefore older) or never even went under the guise of algorithmic knowledge requirements without admitting ageism.
As to other industries, I have little direct experience. I know that my friends and family (none of which are in tech) have been on interviews that are humane and conversational as opposed to the inquisition our industry supports. They have all been aghast at what I've been going through.
A. Don't make the interviews so hard that they require multiple months of preparation. You can be prepared for the google interview by simply having taken an algorithms course and studying for 2 or 3 weeks.
B. Make sure the people you hire are good communicators and are a good culture fit.
C. Try to make your workforce diverse.
These companies make bank from both sides (the person interviewing who is cramming on their material, and the employer), and leave out important things like how well you work with teams, how fast you adapt to new frameworks, or how maintainable your code base is.
I guess it is no surprise that another of their "featured" blog posts talks in extremely glowing terms about someone for coding for 24 hours without any sleep. (http://blog.hackerrank.com/recap-how-mimino-solved-78-projec...).
Can you point me to the part of the HackerRank website where they ask people (not businesses) to pay them money?
A slightly weaker version of that argument is that having a vast base of signed-up users and data about their challenges is still making bank out of the efforts of individual users, but clearly not as bad as requiring you to pay for this tutorial.
By having a filter, it allows a company to evaluate a lot more people and not rely entirely on the resume (which might not do a good job of representing your skills). Presumably, they are already doing these same style of coding+algorithm questions later on in the process, so this is just weeding out people who clearly wouldn't pass (and identifying people who would unexpectedly pass). Not a bad thing.
If a company is using it as total replacement for the hiring process then, yeah, that's broken. They won't be able to evaluate team work and a bunch of other things.
I think what you're really trying to say is that blind filtering is bad (okay, you said this part explicitly) and you think that HackerRank is a blind filter. Unfortunately, this is pretty obviously not true. HackerRank uses quite a bit of data. Arguments that HackerRank is using the wrong data, or using what data it has poorly, would make a lot more sense than what you've said so far.
This is true only if your coding/algorithm interview process is the exact same as HackerRank. Alternately (like they do at the place I work at), if your coding interview is conducted in person and relies upon you correctly describing a thought process rather than coming up with the correct code snippet, it's an awful replacement.
Yes, the fact that in-person interviews involve some back-and-forth conversation makes the HackerRank ones slightly less predictive. But slightly less predictive doesn't mean "awful."
It's worth noting that on HackerRank, candidates can see how they're performing against the test cases. So when people don't perform well, it's not that they made some silly mistake or misinterpreted the problem. It's because they truly weren't able to get something more optimal or more correct.
Companies can set the bar wherever they want. There are times when a company sets a bar too high. You certainly can implement HackerRank in a good way. You can also implement it in a bad way.
You can see how you do against test cases in aggregate. You are given a few examples, the rest are hidden from you. A completely arbitrary and vindictive restriction.
Save the tough questions for the onsite interview, where an interviewer can subjectively make judgments about their performance.
You don't necessarily demand perfection on this test though.
One mistake that companies make is that they think they want to set a lower bar, so they make the questions easy. But then, in order to distinguish candidates, they basically require perfection. Now, a simple mistake can "fail" a good candidate.
It's better if they make the questions harder, but just don't require perfection.
First, it's much harder to scale in a consistent way.
Second, and more importantly, you also evaluate how they code right now, on these specific technologies, not how well they would code with a bit of training.
Think about it: There are a ton of new college grads who are better software engineers (or would be, with 6 months) than people with 20 years of experience. But a person with 20 years of experience who knows that technology will perform better in an immediate sense than the new grad.
No interviews are perfect.
Citation? How does having fresh recollection of algorithms that you will rarely if ever use outside of interviews make someone a better software engineer?
I wasn't saying that new grads are, on average, better than experienced hires. I was just saying that experience is not everything.
An experienced hire will outperform a new grad on a "build this project in 3 hours" test. But the new grad might actually be a fundamentally better engineer - they might be smarter, more careful, etc. Given 3 - 6 months of training, the new grad might actually make better technical decisions.
Obviously, the reverse can also happen: the experienced hire might be not only more knowledgable, but also smarter, more careful, etc.
The problem with the "build a project in 3 hours" test is that it weights experience and knowledge so heavily that you end up eliminating people who could be great, with a little bit of training.
Again, a new grad could also be a fundamentally terrible software engineer (there are fundamentally terrible software engineers with experience and with no experience). And in 20 years, they'll be a terrible software engineer with 20 years of knowledge and experience. They might be able to build a 3-hour project better than some smart inexperienced coder but I'd still rather hire the smart inexperienced coder (assuming I have some time to train them).
Ultimately, ALL hiring processes are flawed.
A hiring process that acts as if years of experience mean nothing and which reduces your career to a score on a web page generated by a terrible constructed test is especially flawed and inhumane.
The companies that sell these products are profiting from hurting people.
Hahaha, please tell me another one Mr. Trump.
> A hiring process that acts as if years of experience mean nothing and which reduces your career to a score on a web page generated by a terrible constructed test is especially flawed and inhumane.
Being old is not an indicator of success.
You seriously seem to live in some wonderland where the quality of a candidate just magically appears out of thin air.
I want candidates to have studied. Studying isn't gaming. Studying is being smart. I want candidates that studied. Those that didn't I don't want. They don't want the job badly enough.
I routinely test older candidates who can't program anywhere outside of the little box they made for themselves, and freak out when they see a programming language that isn't the one they've used for the last 20 years. Is that inhumane?
Gayle is awesome. Cracking the Code Interview is a really great book, and I credit it for getting me through some of my interviews. Everyone here poking at her are people shooting the messenger for delivering the inconvenient truth.
> Being old is not an indicator of success.
I didn't say it was. A history of success is an indicator of being successful though.
> You seriously seem to live in some wonderland where the quality of a candidate just magically appears out of thin air.
You seem to love in a wonderland where a candidate's aptitude can magically get turned into a score on HackerRank.
> They don't want the job badly enough.
Yeah, fuck them for not wanting to waste time on your startup that will likely bomb in a year. How dare these people want a personal life.
> I routinely test older candidates who can't program anywhere outside of the little box they made for themselves, and freak out when they see a programming language that isn't the one they've used for the last 20 years. Is that inhumane?
And I've met hotshot new grads who think they're the best thing since static typing, yet can't benefit from years of experience in how software is made in the real world.
> Gayle is awesome. Cracking the Code Interview is a really great book, and I credit it for getting me through some of my interviews. Everyone here poking at her are people shooting the messenger for delivering the inconvenient truth.
I only now realized the user who I am going back and forth with elsewhere in this thread was the author of these books. I am pointing out the flaws in these types of interviews and how they are very overvalued. The book's ability to get you through interviews means nothing about how those interviews select for people who can do the job, only that the book was designed to help you get through interviews.
I also don't think companies should dismiss years of experience. That is valuable. It's not everything -- you can, of course, have bad but experienced engineers. But experience is certainly valuable. It makes you a better engineer.
If a company entirely relies on coding interviews, they are making a mistake.
This is pretty simple.
Experience makes someone a better software engineer. Smartness also makes someone a better software engineer.
Some experienced people are smart. Some are not. Some inexperienced people are smart. Some are not.
All else being equal, I'd prefer to hire experienced over inexperienced, and smart over dumb. But, sometimes, all else isn't equal.
Given two candidates (P = smart but inexperienced vs Q = dumb but experienced), who would you rather hire?
I, personally, would rather hire P. I can train P and turn them into a pretty good software engineer -- and P will only get better with time.
A process that is a "build this project in 3 hours" test will favor Q. If you prefer Q over P, then that's a great process to have.
If you prefer P over Q, then this probably isn't the right process for you. You might do better with the whiteboard coding/algorithms process -- or some mix of different things.
And, you know, that's okay. All interview processes are flawed. A company should pick one that is the least flawed for their situation, be aware of the weaknesses of their process, and do what they can to mitigate it.
Tech companies are generally aware that one of the weaknesses of the algorithm-focus is that good people sometimes do poorly do to lack of preparation, and that's why they encourage preparation.
There are better and worse candidates in either camp. I developed software professionally for about two years before graduated. Is it 20 years? Nope. Conversely, it's more experience than many college grads. Working with super talented individuals with an express focus of learning/improving also gave me a hell of a lot more than "a fresh recollection of algorithms."
But that said, you always need to gear your interview to the hiring goals. Hiring someone with no experience is a completely different effort than hiring an experienced dev or lead.
It also certainly depends on the environment and task.
Last time I looked at hackerrank, they were 90 minutes long. So I am expected to do nearly a full weeks work to interview with some companies. Thats why I refused last time Skyscanner asked me to do this (actually they have asked me 3 times! Before I even get to speak to anyone technical).
Plus the platform is frustrating to use - I don't my write code in a web browser. I use an IDE step through debugger especially for the algorithmic style stuff that's on there. I don't particularly like writing code in a rush, as it leads to poorer quality code.
I hate these things. They're shit.
So... don't write your code in a web browser. Use an IDE and then copy-and-paste it in. Lots of people do that.
We might have pushed the limits with coding questions. Why do you need 5 coding rounds? does one programming problem not clarify if this person can code or not?
The coding questions are not literally "Can they physically write code or not?" They're evaluating your problem solving skills and coding skills.
There is some inconsistency though with someone's performance in coding questions. Someone usually won't bomb one and then do great in another (although they might feel as though they did). But someone might do mediocre and then do pretty well on the others. Asking multiple questions is just getting multiple data points.
I understand Big4 doing this as they're bombarded by resumés, but the problem starts when mom'n Pop CRuD shops start aping these blindly.
The point of these questions is basically to assess intelligence (as it relates to coding). It's not about having you solve a specific problem because you might need to solve that exact thing in the real world.
You're right though that part of the issue is a bunch of companies trying to replicate the Google process (which might not even be right for their company) -- and then not knowing what it's all about. So they ask super common or really easy problem, which don't even test problem solving skills.
Based on my own personal experience, this is my assessment of the interns who knew too much about interviewing questions
They performed very badly compared to someone who did not pay enough attention to interviewing questions. Its as if the more they read about the various interview questions online, the less confident they were because there is always a tricky "problem solving question" they cannot answer.
They showed reluctance to explore any new areas of engineering except writing java code. practically no curiosity in anything else. They truly believe that their job will be only writing more java code.
Next time if you interview, change the context of the interview and talk to a new grad, some of them had solutions to 500 common interview problems and read every cracking interview book and blog and it still did not get them a job.
There are absolutely people who "learn" dozens or hundreds of problems and then still don't get a job. That's actually a good signal about the interview process. Preparation shouldn't land a bad engineer any ol' job they want.
Unfortunately, it sometimes does -- and that can happen when a company asks easy or well known problems. Far too many companies do that.
i.e You have a program, it's running slow, how do you debug it.
You find that the slow part has a query, how do you debug it?
So you check the table, it has indexes, as a matter of fact, it has index on all 10 columns and the insert is slow as hell, what now?
What's your opinion on OOP vs procedural? or OOP vs functional?
Two developers come to you with various idea, idea A and B, which will you pick why? What do you think is the pros and cons of A and B?
This is very revealing.
I did an interview at Fitbit where I did a phone interview with the manager who asked me algorithmic questions, then I had to write a program and make it optimized and pretty which took about a day to write, then I had to do about a 4-5 hour interview on site where I was drilled by about 8-10 different people 2 at a time to write code on a whiteboard. After all that and taking off work to do it I didn't get an offer saying my experience doesn't match up with what they are looking for. It was after that I realized I'm not going to go through all that bullshit anymore.
Personally I'm not a fan of taking these interviews, but now being involved on the other side I've seen how essential it to filter out those who don't actually understand how to code.
The test is essentially writing a function that can take any number of numbers and add them together followed by a couple of bits around javascript's built in functions and object syntax.
1 of the failures couldn't write a for loop despite having 5 years experience including React.
The test also works as a general personality test as we need people who are fully confident in their abilities due to the difficultly and scale of the product. We are specifically aiming for the top 20% of candidates who come in, so there are subsequent tests after this one.
I thought I'd be able to spot a bad CV, but it turns out either people are lying or they are crediting other people's work to themselves when they are able to hide amongst the team at large organisations.
We probably should check it out for those that have one to be fair. But I'd rather it didn't factor in as a implicit negative for those who are too busy to work on projects outside of the office.
http://blog.hackerrank.com/introducing-cracking-the-coding-i...
a) I shouldn't ask questions that are in that book, any question found in the wild is banned.
b) I want my candidates to study and show me the best of themselves, and that they want the job and are not wasting my time by throwing their resume on the pile as an afterthought.
c) Cracking the Code Interview is really good at helping you through the algorithmic questions popular on whiteboards. I find the signal:noise ratio on those questions pretty poor, so I ask more straightforward questions that more closely represent things a software engineer encounters in their everyday life. CtCI is good for getting you up to snuff at the stuff you don't do all the time (if ever) just in case you get That Interviewer.
Admittedly, I am but one interviewer and there are many others who do many things many different ways, but I've never heard anyone denounce candidates studying.
While I'm sure there are interviewers who are opposed to preparation, mostly interviewers support this.
(-> taking the ad hoc Bar exam, again, and again.)
If you really want to crack the HackerRank test, read this instead:
https://thehftguy.wordpress.com/2016/07/13/cracking-the-hack...
I'm now in a place where I've made my money, and now I'm set to move outside of the Valley. Given that I'll be near Irvine, I thought it might be fun to see what Google is up to. Completely ignoring my history, this is what I'm told I have to prepare for when I come onsite: - Be ready to talk about complex algorithms like Dijkstra and A* - Be comfortable with sorting and efficiency (be comfortable knowing when insertion sort, radix sort, quick sort, merge sort, heap sort - Be aware of discrete math solutions and know probability theory, combinatorics, n choose k, etc.. - Know all data structures and what algorithms tend to go with them - Know graph algorithms and structures, their representations, and how to traverse them - Be comfortable with recursion and how to think recursively - Know OS concepts like processes, threads, concurrency issues, locks, mutexes, semaphores, monitors, etc..
So, to join the "best of the best", I have to brush up on all of these concepts (again) enough to answer random questions from random interviewers for 5 hours. Also, I'll need to do it in one of the preferred languages... on a whiteboard... and be syntactically correct. Oh yeah, I'll also need to talk through my thought process the entire time, and explain the tradeoffs, time complexity, space complexity, alternative paths, etc... I'll also need to show a go-getter attitude and not get flustered while the interviewer "pushes" me in various ways. I'll also need to build a rapport with half a dozen different people with various personalities, quirks, and moods. If it involves lunch, I'll need to pay attention to what I eat, how I eat, what I chit chat about, what the temperature is (am I sweating, am I dressed the same), etc.. Depending upon the type of work being performed, I'll need to show good "excitement" for the product, be it ads, games, VR, AR, etc... I'll need to show intelligence, but not be abstract. I'll need to think through problems very quickly, but also be thorough and not make mistakes.
Do you have any idea how long it takes to prepare for this? Do you realize how taxing it is on your life? I'm an introvert... this stuff destroys me for weeks. ...and this is from someone who has a 100% success rate, and already knows all of the answers!
The sad part in all of this, is that it doesn't actually work. You've made your candidates go through this awful gauntlet, and your people are no better than any other company. You still have great people that leave, bad people that stay, bad solutions to easy problems, features that shouldn't be built, genius developers that can't communicate, teammates that won't stop talking, managers that make your life hell, managers that are amazing, problems that excite people, problems that bore people, etc... There's no difference, and that's why it's tiring.
Would you like to know the absolute worst project you could ever work on as a developer? It's one that takes a lot of time, work, thinking, personal interaction, consumes personal time, requires ridiculous scrutiny, needs to be perfect the first time, and wether or not it succeeds or not, it is trashed as soon as you're done with it. That's our interview process. That's what we're making thousands of good people do, every single day.
Are the Editorials generally approved by the author of the book?
Recently, with help from Cracking the Coding Interview and HackerRank, I was able to pass some fun yet challenging technical screens with Google, Facebook, and Uber.
How challenging were the actual screens compared to the CtCI practice problems on Hacker Rank?