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.
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.
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.
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.
> 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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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?
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.
>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.
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.
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.
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.
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.
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 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.
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.
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.
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.
"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.
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.
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.
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.
Readit News
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.
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.
So -- do people "push" each other around a lot, in your environment? Just to, you know, see how they react?
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.
Dead Comment
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.
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.
One could swap "a company" and "one engineer there" and still have a perfectly valid argument.
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.
Deleted Comment
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.
Deleted Comment
I recently interviewed for a position at a small Amsterdam based company. They simply asked me to work with them and refactor a part of their code base. It was really interesting and frankly, we all had lots of fun during the 3-4 hour process.
Coming from the USA, it was eye opening to see the ingenuity of this simple way to determine candidates ability. It's such a shame that Stack ranking like HackerRank are being favoured instead of on-job evaluation.
1. Coding challenge <- Your interview was mostly this.
- Make an object
- Make a mini-app
- Fix this code
- Refactor this thing
2. Design a program on a whiteboard
3. Algorithmic & Data Structures <- Cracking the coding interview helps here, and is the type many engineers struggle with.
4. Hiring manager interview <- the most subjective
People also will bring up if you're an asshole in any of the above interviews.
[1] Google gets 2 million resumes a year https://www.fastcompany.com/3044606/hit-the-ground-running/g...
[2] Headcount increased from 57,148 to 66,575 between Q2 15 and Q2 16: https://abc.xyz/investor/
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 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.
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 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.
I think you would be hard-pressed to demonstrate that their processes are consistent.
Sure, interviewers themselves are inconsistent (accents, prejudice, interview difficulty, etc), but that's not something that can be fully mitigated when every candidate gets a different set of interviewers.
Again, I'm not defending the practice and would just like to have a constructive discussion.
Technical chops are a prerequisite, of course, but they're useless if the candidate doesn't make the right tradeoffs and technical decisions.
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.
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...).
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.
Can you point me to the part of the HackerRank website where they ask people (not businesses) to pay them money?
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.
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.
Last time I looked at hackerrank, they were 90 minutes long. So I am expected to do nearly a full weeks work to interview with some companies. Thats why I refused last time Skyscanner asked me to do this (actually they have asked me 3 times! Before I even get to speak to anyone technical).
Plus the platform is frustrating to use - I don't my write code in a web browser. I use an IDE step through debugger especially for the algorithmic style stuff that's on there. I don't particularly like writing code in a rush, as it leads to poorer quality code.
I hate these things. They're shit.
So... don't write your code in a web browser. Use an IDE and then copy-and-paste it in. Lots of people do that.
We might have pushed the limits with coding questions. Why do you need 5 coding rounds? does one programming problem not clarify if this person can code or not?
The coding questions are not literally "Can they physically write code or not?" They're evaluating your problem solving skills and coding skills.
There is some inconsistency though with someone's performance in coding questions. Someone usually won't bomb one and then do great in another (although they might feel as though they did). But someone might do mediocre and then do pretty well on the others. Asking multiple questions is just getting multiple data points.
I understand Big4 doing this as they're bombarded by resumés, but the problem starts when mom'n Pop CRuD shops start aping these blindly.
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.
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.