So... I just failed an interview because I didn't finish the HackerRank challenge in time. I'm annoyed that I couldn't complete it, but I'm more frustrated by how robotic the process was...
When I've interviewed candidates, I focus on their problem-solving skills not their speed. If someone is focusing too much on one problem, I’ll encourage them by saying, ”I think you got close enough. Why don't we try the next one.” After all, I want the candidate to see that were a company that embodies forgiveness and iterative learning. But you don’t get any compassion from an automated email sending you to HackerRank.
So what does that say about the company that relies on this impersonal processes? Should companies even use timed coding challenges? Or are they necessary for certain types of high-pressure companies?
Top comments (31)
I have pretty much told myself any company that uses something like that to interview you, then I'm just going to turn it down and move on. For me it just tells me that I do not want to work there if they judge their candidates based off that.
It's not fair for anyone and it is not even remotely close what you will more than likely be doing for them.
My best interviews are when a conversation happens on both sides. You learn so much about how people actually are and how they think
Sometime around last year, I did a timed coding interview for a company. There will be two coding questions, 20 minutes for each question i guess. The interviewer will share the screen and they know exactly what you are typing in the IDE, it was like someone standing behind my back, when i am working.
I solved one problem and then when i am solving the next problem, Windows 10 update started to happen, the system got rebooted and i got nervous and forgot what i was doing, they came with a new laptop, had to start that problem again. The only good thing in that interview is they allowed me to search google for APIs.
That’s so unfortunate! I’m sorry that happened to you.
I agree that those kinds of interviews suck, but you also need to understand the other side of the story. Interviewing 100s or 1000s of candidates is very time-consuming. If a company can filter out some of the candidates in an automated way - they'll probably do it. And I don't think that this means that the company is a bad place to work in. Everyone just wants to save time where they can and improve the process.
Sure, but why time it instead of giving the candidate the opportunity to solve it without these constraints
I agree with that. I only wanted to address it to the part about not being interviewed by a human :)
Exactly.
I hear you, but I think a non-timed code challenge would work fine. I suppose that they do the timed challenge because they don’t trust people to come up with the solution on their own. Like if yo give someone a week to do a challenge then they can google a ton of things.
But I like to work for companies that operate on trust and forgiveness.
I'm glad I haven't encountered the "record a video" phenomenon because that sounds dreadful. I have been asked to read out every character of a solution on the phone, which I thought was a bit much.
That sounds more awful than "record a video".
Oh my. Can this please become the the “terrible interview stories” thread?
Not sure it qualifies as a terrible interview, but I have gotten IQ tests as an interview. It's illegal in the US, and I think they knew that, because they called it a personality test.
These stories are getting even worse. I feel much better about my interviews now. Thank you for the perspective! Haha. In IQ test...? Wow. Just wow.
I auto decline interviews if i find out they involve questionnaires.
I have 2 reasons, first of all it does not test problem solving skills, and second of all, i have a shitty memory. :)
I've done project tests before, the kind where you get a small app spec', a time-limit of a few hours, and just have to pass along the git repo and build instructions. I actually find those fun and challenging.
I would not do any kind of testing without a preliminary meeting first tho.
French has been pardoned. But yea, I should have declined it too.
I’d prefer to work at a company that operated on forgiveness and understanding:
Screwing up. Advice on forgiving your inner child.
Cubicle Buddha ・ Sep 4 '19 ・ 3 min read
I'm bad at solving problems under pressure. Especially a time based pressure. I often found solutions to problems that people seldom thought of. As much as I like calling myself a creative problem solver, in reality, ideas and new insights to a certain problem I faced often just come when I'm lazily procrastinating.
I can identify with that. Unfortunately I think those kinds of interviews are an entirely separate skill from day to day coding.
Exactly!!
I feel like ideas only come to you when you take time to walk away from the problem. So I agree with you.
I hate it too. However I believe it's more of a metric to check how fast can a candidate arrive to an efficient solution - which directly denotes that the candidate is familiar with the type of problem in hand, what approach they follow and how efficiently they do it.
Not saying other candidates are undeserving of the same role of the interview they were applying for, but somehow, it works. I have got many friends who practice a lot to develop this instinct of recognising problems, and coming up with an efficient solution fast.
Overall, the results are good. So I think it's a matter of personal preference.
I’m glad someone took up the opposite side because I have some questions.
I’m mostly curious about how the interview relates to the actual job. For instance:
When have you had to solve a complex problem under a stressful 30 min time crunch in your day job? (My answer: in 15 years— 0 times)
In a high performance environment like a startup consisting of about 20-100 developers where they are handling millions of users, it is vital to be both fast AND efficient at the same time. These developers wear multiple hats, ranging from devops, testers, developers and designers, etc at the same time. Usually, they are paid way more in average.
That is why, in most cases, these tests are included in the interviews conducted by unicorn startups and other bootstrapped companies, where time and efficiency is the key to achieving greater heights. It not only tests the developers capability to solve problems, but also how effectively you solve it (efficiency here is the measure of the most optimal solution in the least possible time) so that the developer is free as soon as possible for solving other problems.
The time limit allotted in these tests - anything from 30 mins to 3 hours are just an arbitrary limit by which a developer can come up with an optimal solution. But if you do practice coming up with solutions under such time limits, your personal time averages for coming up with solutions in general also decreases, since you are training your mind to think that way.
What I don't support, is that lately even normal companies who do not require such idealistic developers have started to follow this trend.
Yea, the company I experienced this was not a startup. And they don’t do anything that complex.
Good points though. But I’m not interested in training up to become the best in some “programming sports league.” I want to become the best at being the happiest me. :)
I avoid HackerRank-like screener/interviews like the plague. It's a lottery of problems. You can get lucky and figure it out quick or you can get stuck. In my opinion it's not a measure of your ability at all. And they make you feel pretty low after you fail them. It's really a loss all round for me.
I agree. Company misses out on good candidates that might have been accidentally screened out. Programmers miss out on potentially great jobs (and lose confidence).
I feel like they’re looking for efficiency, but being a human being is inefficient. That’s what makes life wonderful and nuanced.
Hiring is hard. Especially in tech and maybe more so for develooers. There are so many variables that can lead a company to weird interviews but at the end of the day I think most of us are just winging it.
Where I work we ask candidates to do a programming test after they've made it past a screening call. Sounds shitty but it filters out a lot of people who simply can't code. Or at least gives us a good sense of where they are and what to base their technical around if they get that far.
Later that test gets used as a conversation piece for our technical if they make it passed culture checks.
We used to time the test but decided not to anymore. So to answer the question, I'm not sure lol. I think it depends how that timed test is used.
Sometimes you need a way to cut through the flood of candidates that are faking it so you don't waste your time on people who can't code.
Sometimes this means you miss out on people who are probably perfectly capable of fitting on the team. But sometimes it's worth missing out on all the time wasted investing in people who are absolutely not a fit.
In our case the test is used as a screening step. We don't do coding tests in the middle of a technical because in the past it's shown to cause a lot of stress for people. So we try to keep it casual and talk about the code submission as if it were a PR or something. And if you make it to our technical you're hopefully already pretty comfortable with our team.