Exactly. What kind of hiring "bar" is it if all it measures is the motivation (or more specifically: degree of desperation) necessary to pony up for a 30-day cram school... led, not coincidentally, by the very company that's administering your weeder tests?
> led ... by the very company that's administering your weeder tests?
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.
then do it like I do. Whenever they send you a link to one, don't take it. Explain you are more than happy to talk to an engineer but you won't do some random online test.
(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)
Good call. The sheer idiocy of expecting people to show off their mad hacking skills in such an obviously crippled environment is just... breathtaking. Especially when the cost of renting a session on one of the services that does offer a full-featured IDE (with vi and emacs modes) is close to zero.
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.
I've written code for pay for over two decades in a variety of languages and on a variety of platforms. I can say if I don't wish to write code into a Google Document, nothing misguided about that. Someone fresh out of school, maybe, even then, most coders are using an IDE all day or have another window or terminal open so we can do a quick compile sanity check so even for a new coder fresh out of school, this makes no sense.
You should be able to write code with half-busted crayons on the back of yesterday's newspaper, also. But it's much classier (and time-efficient) for all concerned if the employer provides at least ballpark-adequate tools upfront (meaning at the very least an editor that doesn't overtly work against you -- like Google Docs does).
I have begun doing this. The RoI just isn't there for me.
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.
Yeah, you have to pretty much assume that if you balk on their "weeder" test, they'll balk on you.
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.
The College Boardification of software has begun. Arguably it was already here back when companies were hiring based on candidate SAT schools and college pedigrees, this is just a new chapter with sw interviewing platform firms becoming the new Princeton Reviews.
Along with the "Top 20 Startups to Work For in 2017" mentality.
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?
Oh, totally. If interviews were a perfect science, and perfectly measured ability, then you wouldn't need to prepare for them at all. You're absolutely right there.
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.
In my experience over the past year, programmer interviews are almost all the way towards the "preparation" (learning to interview, not learning to do the job) end of the scale, with a unhealthy doses of sadism and elitism. I've rarely been asked anything that has something meaningful to do with my abilities as an engineer, only demeaning HackerRank style tests that check only for algorithmic academics knowledge, insulting take-home exams that ignore existing code and industry experience, and torturous whiteboard sessions that select for nothing except ability to withstand day-long in-person inquisitions.
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.
I'd guess as an alternative to the "demeaning" HackerRank style tests which are purely meritocratic and allow smaller companies to interview large amounts of people you would prefer nepotism and only hiring and interviewing people with high GPAs from expensive schools?
The problem with meritocracy by standardized testing is eventually you reach Eastern/Southern Asian extremes with cram school culture of people endlessly drilling for tests. It's possible to rotely memorize strategies for applying algorithms until you excel at HackerRank type tests. By then you're just interviewing for candidates who spent the most to enter the most expensive boot camps.
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.
I think the high tech industry has always been ran and controlled by sick people. That' why its not considered a proession like med, law, or finance.
When I was younger I worked at DEC for a while, about the time the VAX came out, it was hot. We had a HR manager who required all new hires to strip in a private room, and then if the HR liked what he saw the newbie would get passed on to engineering.
I thought this odd, and the HR manager was openly gay, and a sleaze to boot.
The simple fact that people of power in our industry can be sadists, and not anybody is willing to step forward hasn't changed one iota since 1970's.
I have no idea why people who otherwise are against practices like stack ranking think that companies like "Hacker"Rank which assign you a score based on a set of simplistic algorithm are a good idea. If you are a manager and your company uses HackerRank as a hiring filter, I request you to take a good, hard second look at it – specially if you lament that you are unable to find any developers.
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 am sorry -- since Gayle's book of the same name is a product worth ~$30, I assumed there was a paywall at some point behind https://www.hackerrank.com/domains/tutorials/cracking-the-co... -- I guess I was wrong? It doesn't clearly say on the page that it was, and I don't want to sign up for their product.
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.
They make money by selling the snake oil that are these tests and interviews. They need interviewers to believe they are useful and diagnostic, and they need interviewees to put up with them and think it's acceptable to be put through it.
You're right -- HackerRank does leave out those things. It's a filter, not a replacement for the entire interview process.
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.
Yes, not filtering is good, interviewing is good, hiring qualified candidates is good, not insulting senior candidates is good, blind filtering is bad.
Interviewing _is_ a filter. Each step where you eliminate candidates is a filter; that's what that word means.
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.
> so this is just weeding out people who clearly wouldn't pass
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.
It depends on where you put the bar and how challenging your questions are on each side.
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.
> It's worth noting that on HackerRank, candidates can see how they're performing against the test cases.
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.
Agreed. HackerRank works great as an 'initial' filter. The way to use it correctly is to ask people a couple fairly easy questions, because if they can't pass the easy stuff, then you shouldn't waste their time with a full onsite. A person who is at least moderately capable, shouldn't at all struggle with your initial filter.
Save the tough questions for the onsite interview, where an interviewer can subjectively make judgments about their performance.
Or, ask two questions, where (on at least one) it's fairly easy to get an inefficient solution, but requires more thought to get a more efficient one.
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.
Imagine a world where the interviewers sat a candidate down in the company's typical environment, with a simplified version of their codebase, and asked them to re-implement a small piece of striped-out functionality. Give them a couple of hours, and then allow them to ask questions, explain what they did, where they got stuck, and give their own feedback. Now you know that they understand your environment/stack, and get an actual sense of how they would perform for your company on code that matters. Let them see the actual code you use at the end, and discuss differences, why they made certain choices, and see if they get excited or frustrated with your company's practices (style, systems, conventions).
Yeah, some companies do those (or a slight variation, called pair programming interviews). There are a lot of benefits of those, but also some drawbacks.
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.
> 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.
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).
A hiring process that can be gamed by reading a book sold by the process giver is especially flawed and morally corrupt.
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.
> A hiring process that can be gamed by reading a book sold by the process giver is especially flawed and morally corrupt.
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.
I have no idea why I am being compared to Donald Trump.
> 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.
People don't consider that not only does the software engineering process weed out those that don't know algorithms, it also weeds out those that don't have the discipline to sit down and study for a couple of weeks.
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.
Wrong about what? That all hiring processes are flawed? That some new grads could be better than some experienced hires, 6 months down the road? That build-a-project-in-3-hours doesn't weight experience heavily?
Essentially younger are better amiright? Otherwise why are they smarter than someone who actually has real world experience? Is your new grad smarter than Jeff Dean? Or Rob Pike?
Nope. Not even close to what I was saying. In fact, I repeatedly said that I am NOT saying that inexperience people are better/smarter. I'm not sure how you got to that, other than pure determination to believe I was saying that.
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.
How does repeating the same tasks every day for 20 years make someone a better software engineer?
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."
I agree in principal - I was being slightly facetious (as I hope you were with the 6 month figure).
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.
I just turned down an offer after a technical interview. Just after my tech call, I call the hiring manager and said I didn't want to move forward.
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.
> but this 'My way or the highway' from pseudo engineers
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.
Not really. Im open to discuss any solution to a problem, from the most performant one to the most simple one (code wise) that does the job.
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.
You may have dodged a bullet because if someone has a "only one answer approach to interviewing" then the inability to see other possible solutions may carry over into their daily work as well.
Had a weird experience where the guy interviewing me would shake his head "no" when he didn't like the answer I was giving. Not that it was wrong, it just didn't conform to what he was expecting. It was really weird to describe a proper technical solution to someone who was doing that.
If the guy was from India(especially southern states and West Bengal) be aware that shaking the head side to side means that he was agreeing with you or indicating that he was following you.
I've been giving a lot of interviews lately. It has been really difficult to come up with questions that don't end up turning into "guess my magic answer". As a result, I spend the majority of the time talking through work they did in the past with the primary goal being to determine "what did the applicant actually do on this project?" As opposed to simply hanging around the team or flipping switches to enable pre-packaged features.
Here's the problem I have -- how do you avoid hiring professional bullshitters? Wouldn't the guy who put together the PowerPoint for upper management sell himself better than the guy that actually wrote the machine learning system? I've just known too many people who are better talkers than coders. at least with CtCI-type questions you can't really lie or stumble your way through it. I'd rather take a few bad rejects than a few bad hires.
And it's the totally right thing to do. Bad hires are disastrous and have a much greater impact than missing out on a few pretty good engineers because they didn't think to use dynamic programming. Programming interviews aren't perfect, but the reality is there aren't better alternatives.
> Bad hires are disastrous and have a much greater impact than missing out on a few pretty good engineers because they didn't think to use dynamic programming.
Citation needed. I frequently see the dangers of false positives exaggerated and the costs of false negatives downplayed.
Aside from the monetary cost of hiring them, you're making the team less productive. Time is spent training, on-boarding, doing their code-reviews, and after all that it takes at least a few months of settling in to see how they actually perform. Tthere's also the opportunity cost -- whatever project you had hoped they could tackle is now months behind and at best all you have is some slapshod code you'll need to rewrite anyways.
Of course there are gradients to bad hires, but the really bad ones are a terrible experience for everyone involved.
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?
Ask how many people have been fired. I like to think the people I have are all very good because I fire all the bad ones. Much better to weed out because of on the job performance than select on the basis of some poor proxy for on the job performance.
really the only part that makes bad hires so bad is the impossibility to get them fired at most companies. Even if you hire someone and realize you've made a grave mistake thats obvious to everyone, some stupid moral value or company culture thing will force people to put up with it for 6 months, then have them be on probation for 6 months, then do an evaluation for 3 months, and by the time you finished the process to fire them, they quit first anyway.
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.
> really the only part that makes bad hires so bad is the impossibility to get them fired at most companies. Even if you hire someone and realize you've made a grave mistake thats obvious to everyone, some stupid moral value or company culture thing will force people to put up with it for 6 months, then have them be on probation for 6 months, then do an evaluation for 3 months, and by the time you finished the process to fire them, they quit first anyway.
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 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.
I will never understand the absurdity that is the US obsession with covering your ass. In Canada you take reasonable steps, but in the US it's just crazy.
It has to do with our legal system. If you're a defendant, it's extremely hard to sue your plaintiff to recover legal fees, even if you win the suit.
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.
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.
Legal issues aside (and those are real), there's the morality aspect to it.
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.
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.
Why shouldn't companies invest in training? What's with offloading job training to universities and to the applicants themselves? Yes, HN is a startup-focused site, -'d startups have limited resources. But large tech companies, or at least IBM, had historically trained engineers, at least in the 70s and earlier.
When I've asked this question in the past, the most common reason I've heard is that there's a fear, because of the prevalence of other companies poaching engineers, that money and time spent on training will benefit the company that manages to hire away the trainee (and sometimes a direct competitor).
It's not that companies shouldn't invest in training, it's that bad hires will cost you more in training among other things and have little to show for it.
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.
After all that it takes at least a few months of settling in to see how they actually perform.
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.
Have you ever been at a big company where you found more than one or two exceptions to "I just don't give a fuck this company or any of youse", and which one, because I'd love to submit my resume there.
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.
This confirms with a lot of my observation, also. For example, the modern interview process has tricked interviewers into believing that (armed with the right set of questions and/or hoops to be jumped through), they can "size up" the candidate. When at very best, all you can "measure" is the intersection of your backgrounds.
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.
It's a mixed bag. Not hiring good engineers will, ceteris paribus, give bad engineers more chances to luck through your interview process.
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.
Bad hires are not disastrous unless new people are put in charge of critical projects. I continue to take chances on people who might not workout - sure I fire a lot (never fun), but I have also found amazing people that are overlooked by everyone else.
What is the end game for this hypothetical professional bullshitter? Let's say you hire someone who can successfully bluff past your interview. They come in on the first day, do all the HR forms, get their computer and start setting it up. Eventually they will be assigned a task, or pairing, or whatever it is you do. At this point what happens? If they are able to do the job they did not bullshit you. If they are able to do the job but not as well as you wanted, then maybe it wasn't bullshit but slight exaggeration. If they completely cannot do the job, they were obviously bullshitting.
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.
This relies on being able to accurately identify poor performing engineers, which is very tough at a big company. What I've seen happen is they hang around for a year or two, jump from failed project to failed project, until they either find a niche role where they can do no harm or run out of options and get fired -- but at that point they have a year or two on their resume and will find it that much easier to get the next gig.
> This relies on being able to accurately identify poor performing engineers, which is very tough at a big company.
"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.
If the person who has the power to do that knows it, might as well fire them... why even bother? The person is politically-savvy generally savvy enough to smell it ahead and get promoted else where...
Because at the moment we are talking about, we yet don't know whether the new hire is a good programmer or not (he just passed the interview). Thus my point is to put new hires into positions where political savviness will be of no use until you are sure that he is indeed a good programmer, so that they don't have any option to fake anything by political means.
The difficulty of identifying poor hires scales with their impact. If they are hard to identify, they are minimally harmful. At a big company, poor hires are diluted by size and revenue. At a small company, it is easier to identify poor hires.
The successful bullshitter will prepare himself for the requirements of the job by using the two weeks as an opportunity to become familiar with the relevant tech and code base.
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.
> Here's the problem I have -- how do you avoid hiring professional bullshitters?
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.
> It has been really difficult to come up with questions that don't end up turning into "guess my magic answer".
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.
There are two kinds of questions worth asking in a coding interview, in my opinion. Very straightforward questions that should be solved by anyone with familiarity with the relevant techniques (basic programming, bit-wise operations, multi-threading, depending on the level you want to hit) basically as fast as they can write. And open ended questions which require a lot of back and forth dialogue and design and give you a chance to gauge the experience and overall maturity of the candidate. These are depth / basic competence versus breadth questions. You simply can't expect to get a much better read than that in an hour, even working side by side with someone for a year you won't necessarily have a good sense of how good a dev they really are, you're not going to find that out in an hour or a day for sure. The best you can hope for is to gauge basic competence and make a guess at sophistication and maturity then hope for the best.
Earlier in my career I would give white board coding questions. I would get excited when someone did come up with the same solution as me, but often get even more excited when they came up with a better solution, or made me think about changing how I posed the question. That's a good way to know if you want to work with someone - if you or they or both, get excited.
The worst is when the interviewer gets a question of stack-overflow, then modifies it slightly. The slight modifications mean that a completely different data structure should be used, but the interviewer doesn't realize that.
Dismissing a company because one engineer there is bad at interviewing seems potentially short-sighted. First, you're getting a single data point. And second, how the person operates in interviews quite likely has nothing to do with how he or she is to work with on projects.
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.
If the only look into a company is that tech interview, and he or she will be someone you will have to work with on a day to day basis, and s/he is someone that just flat out refuses to accept that maybe his answer isn't the right one, would you want to work with someone like this 8 hours a day?
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.
> Dismissing a company because one engineer there is bad at interviewing seems potentially short-sighted.
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.
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.
I'm curious. What would be a good reaction? Not reacting and accepting that's only truth from now on? Reacting respectfully saying why you think there are more than one answer, then continue getting 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.
[edit: Both the reactions you listed seem fine, depending on what you're looking for. But I wouldn't do this myself, anyway.]
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.]
I'm not the parent post, but many, many of the interviews I've done, the candidate just says "I'd use a hashtable." Why? well, the honest answer was because the candidate had another interview, and the answer was a hashtable. Now he knows hashtables. Okay great, but I'm not interested in whether or not you know how to use a hash table. I'm asking if you know how to choose which data structures fit the question, ie, can you program. I expect its the same reason google asks (used to?) everyone about red/black and b trees. Same thing, just levelled up a level.
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)
I find it's more of communication problem, because what you assume they know does not match the reality of the situation. Like you ask "can you program?" A mechanical engineer who did a little VBA could apply for that job... People who stay in school all their life rarely get opportunity to be current and relevant stuff used today. This is referring to new grads. They just celebrated a huge life achievement without actually knowing what they don't know with a :D face... some more resourceful ones would find these kind crack-the-interview stuff and maybe get a job - to know what you know for compensating what you don't know. I'm wondering what if tech hiring reach out to students in school and learn what hiring people don't know and work with school to teach what students should know would probably have saved a lot of time... Again, this refers to new grads. I've seen too many not getting jobs these days.
Well. Communication problem exists with professional hirings as well. I blame engineers' lack of empathy (both interviewer and interviewee).
Pretty much. This is where I am right now. I get off work and stop doing web development to practice data structures and algorithms because that's what intviewers want. They don't care about the actual web development experience and the questions I've been asked in all my recent interviews reflect this.
I can't wait to be done interviewing so I can go back to working on fun side projects after work.
If only you could have someone review your comment and tell you all the ways you show bias, presumptions, not-like-me prejudice and a general insiders vs outsiders tone.
A very simple example of the complete divergence between "algorithmic" thinking and "software engineering" oriented thinking is explained in this blog post [1]. You cannot, for example, TDD your way to writing a sudoku solver without figuring out the basic math. The line below is an indication of not-like-me, there is no guarantee that doing the first part well (data structures) means you can do the second one well (unit testing), but vice versa too.
> 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.
But you can also discover that (and much more) without pushing. Or at least not by "pushing for the sake pushing".
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.
Meh. Ultimately people advocate for interview styles they're good at. We all think that we're the type of dev Google wants if only they would interview properly. Give me objective information over "authentic" conversations any day.
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.
I think might have been Google who said this, but you should design for 100x of your expected load and when you get within 10x you redesign and rewrite it.
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 had an interview with amazon before that went exactly like that. The question was asking for a search algorithm the answer I gave was O(n log n) if you ran it the first time and O(1) every time after that. But the answer he wanted was O(n) every single time, wouldn't accept my explanation / answer.
While there are many legitimate criticism of whiteboard-style coding interviews, I have yet to see a convincing alternative that scales well to the size of big companies. Google [1][2], Facebook et al. hire thousands of engineers per year, meaning they conduct at least 10-100k interviews per year. How do you design a process that is consistent, measurable and efficient at that scale?
Give them a computer and some resources. Let them work on a problem for a few hours. Then have a discussion with them about how they approached the problem, any limitations of their implementation, and what they would do if they had more time.
I don't see how whiteboard-style coding interviews can scale any better than that approach.
The thing I don't like about whiteboard: A solid candidate that has a bug near the top of a function ends up looking sloppy because whiteboards don't have "insert". The same candidate making the same bug at the bottom of the function can just erase a closing brace and continue looking marvelous. It's very arbitrary I think.
> How do you design a process that is consistent, measurable and efficient at that scale?
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.
This is what I'm starting to think of as the "sympathetic customer fallacy".
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.
I love whiteboard questions! I've been on both sides, (given whiteboard, handled whiteboard,) and they always tell me a lot about the other person. They're also fun.
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.
>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".
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.
The majority of people that pass these kinds of interviews are the kind of person who will study for months the various coding interview books. Do you think that sort of person correlates with the "cream of the crop"? There may be some loose association there.
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'd argue they are consistent in that every candidate who made it past resume screening is given equal opportunity to partake in a well documented process. Whether or not the process itself is effective is a different question.
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.
One size fits all type of interviewing might be bad for your company or team. If you are hiring for short term, you might find someone who can crank the code appealing, but for long term hiring, you want to choose someone who is creative, who has better imagination or at least has a healthy amount of passion for tech ideas.
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?
> 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 wonder what percent of these questions in all the 5 rounds have production level significance? Do people really solve these "Invert a red-black tree" problems regularly at their day jobs?
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.
Exactly. The only time I have needed to implement a quick sort was for university exams or interviews. The rest of the time, pick an appropriate library.
No, and people don't really ask that interviews. (Or if they do, they shouldn't.)
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.
multiple data points that test for the same thing.
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.
Yes, multiple data points for the same thing. Exactly. It's to get a better measure on that thing (problem solving / coding).
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.
Yeah, I don't understand that approach to interviewing. Technical questions are great, but IMO the point isn't to get the right answer. The best technical questions have many "right" answers, depending on the context. And the best interviewees know how to find that "right" answer by analyzing the use cases, customers, clients, etc. to find the best tradeoff. THAT is what I care most about in a technical interview--the ability to handle ambiguity and make the right tradeoffs.
Technical chops are a prerequisite, of course, but they're useless if the candidate doesn't make the right tradeoffs and technical decisions.
I wonder if such a scheme would fly in other disciplines of Engineering? Would they hire a person at a Thermal power station, who can dazzle people with fancy Laplace transforms on a white-board?
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.
This is the Amsterdam startup scene, basically an extension of the US startup scene where you can smoke weed. Try France, Spain or Italy that truly have a different culture for tech things, I am not sure if you will like it.
Ignoring your snark, I had the similar experience at a Salzburg and Berlin based company. On the other hand there were many companies (Zalando, ProhectA etc) which were copying the shitty model of useless programming puzzles.
Google recruiters tell candidates to buy this book to pass the interview. It drives the interviewers crazy. Clearly there is some friction between interviewers and recruiters at Google, incentives aren't quite aligned.
Where did you get the idea it drives interviewers crazy?
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.
We've been running a very effective initial filter coding interview that simply tests the very basic ability to write loops, refactoring and a little recursion. It's astonishing how many people with CVs of 5+ years professional contract experience in London fail this test. We've had a <15% pass rate on that test alone.
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.
Have you looked into why these people fail? I see all the time claims made like this (i.e. that a large percentage of programmers fail fizz-buzz type questions), but I never see why. Are they morons, frauds, frazzled, confused?
Of the 6 tests I've personally run, 1 passed decently, 2 were probably affected by nerves, 3 just weren't capable. We've had >30 people come in so far and offered to 3 or 4 I believe.
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.
It may be a difference between contractors and perms, but it seems not many actually have a github or similar portfolio. We're more interested in their previous experience and if it is relevant (fintech specifically) though.
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.
Thank you for sharing your opinion which is really quite contrary to mine. To me a portfolio signifies where their interests are and what they are clearly capable of achieving without help.
That sounds like my experience as well. We have been hiring for senior level positions and ask a fairly trivial string manipulation question (no code, just algorithm) and I have yet to see a candidate answer even close to correct. I suppose one or two candidates could have been nervous, but I expect the rest were truly imposters.
Thanks for this. I have not found this such a problem for developers I have interviewed (might be because I am hiring niche backgrounds), but for the sales area frauds are a huge problem. I wish there was the equivalent of fizz-buzz for sales people.
I have the paperback and I've been following her for a long time (she's very active on Quora but I quit that site long ago). I think if you're a moderately good programmer looking for a job at the big four you only need to read Cracking the Coding Interview, maybe aosabook.org, and solve all medium problems on leetcode. This course is just the right thing to get me to actually start preparing for my upcoming Google interview.
"According to our data, developers with at least two years of experience, who practiced even just a little (20 challenges) increased their chances of getting an onsite interview by 50 percent".
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 refuse to take these tests today. Let's have a conversation, break down a problem, look at on a white board. If you want me to take your fucked up bullshit coding test, pay me my contracting rate for it.
They are debating over whether or not to pay you 150-250k a year and you're upset over a weeks worth of effort?
I'll put in a week's worth of effort for decent shot at a salary increase every single time I have the opportunity.
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.
> 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?
Pretty close. They'd present a problem, then expand on it. The problems would keep evolving, so that kept it engaging. Then at a certain point, they'd say we're done, we're about out of time, etc - and we'd have a few minutes to chat about life, technology, etc.
I interview plenty and I've moved away from technical questions and puzzles. We have a conversion, and talk about programming. I ask scenario based questions and just see how they think and will solve it.
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?
Those type of interviews have been the most enjoyable. Having to code a function to do a very specific thing while also having to come up with the algorithm with strict requirements in a half hour while the interviewer watches over your shoulder are the worst. And then having to repeat that for 4+ more interviewers just isn't worth it to me anymore.
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.
Industry requiring professional level resources is having a very hard time coming up with a sane method for screening candidates not screened by professional degree programs.
(-> taking the ad hoc Bar exam, again, and again.)
I've been programming for 24 years (12 professionally). I've worked in startups, BigCo, and Facebook. I've been a jr. dev, lead, E4, E5, E6, EM, and VP. I've worked in the capacity of a PE, SWE, Front-end, Back-end, Data Engineer, and Data Scientist. I've worked with various clients such as: web, android, ios, tv, playstation, mac, and windows. I've been interviewed a dozen times, and have always been given an offer. I've been an interviewer throughout my career, and have conducted interviews at each company.
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.
204 comments
[ 4.8 ms ] story [ 244 ms ] threadhttp://blog.hackerrank.com/introducing-cracking-the-coding-i...
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.
When I was younger I worked at DEC for a while, about the time the VAX came out, it was hot. We had a HR manager who required all new hires to strip in a private room, and then if the HR liked what he saw the newbie would get passed on to engineering.
I thought this odd, and the HR manager was openly gay, and a sleaze to boot.
The simple fact that people of power in our industry can be sadists, and not anybody is willing to step forward hasn't changed one iota since 1970's.
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.
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.
(if you are even able to see my post, hehe)
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.
[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.
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.
Technical chops are a prerequisite, of course, but they're useless if the candidate doesn't make the right tradeoffs and technical decisions.
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.
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.
Are the Editorials generally approved by the author of the book?
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.
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.
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?
If you really want to crack the HackerRank test, read this instead:
https://thehftguy.wordpress.com/2016/07/13/cracking-the-hack...
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.
(-> taking the ad hoc Bar exam, again, and again.)
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.