Hiring managers need to be sure they're being fair to everyone. How can they do that looking at your side projects? They need a way to compare apples to apples.
But hiring and the work force AREN'T fair. My performance review, salary increases, and bonus aren't based on some normalized criteria, we're rewarded for going above and beyond.
Even on the surface "fairness" isn't really the objective, because there are going to be different hiring managers and interviewers throughout the whole process. The salary negotiation isn't going to be "fair" in this way.
I'd rather have someone who had a rich github history and a record of real accomplishment than someone who had none but could produce a good hacker rank score. Hiring is the most important thing that we do as managers, I'd be selling myself short if I didn't take it all into consideration.
No, no, no. They have the job, you want it. That email comes across so arrogant that I would expect even the newest hiring manager to laugh and delete.
Without even addressing the sour grapes attitude about coding interviews, the sheer arrogance with which you try to dictate someone else's process is a red flag in the first place. That, plus the fact that you're refusing to do what they want, is really bad for your chances of being hired.
I think it depends, some employers might appreciate being showed evidence that the process they've decided on isn't suitable for reasons they were unable to see.
I've been on a few hiring panels and designed a few interviews in my day. I've never met anyone who likes being told their interview is broken. Especially not from a candidate (who failed / is refusing to do it.)
His reply was gracious and well thought out. I didn't get a vibe of arrogance or sour grapes myself.
The job hunt is a mutual process...employers are looking at candidates and candidates are looking at employers. If an employer doesn't have a process that fits a candidate's personality and values then it's better for both sides to simply move on. I think this response does an admirable job of beginning that conversation.
I agree that the arrogance is misplaced, and will be lost on the HR peon whose job it is to send out HackerRank tests to warm leads.
On the other hand, it's rare for coders to be so desperate that they'll jump at absolutely any and every job opportunity. The balancne of power has long tipped in our favor.
It doesn’t seem arrogant to me. It reads as someone who is confident in their abilities and is unwilling to spend two hours in an artificial environment when they have a wealth of experience on offer already. OP even says they’d like to do their thing in addition to HackerRank if that is an absolute requirement.
Helpful hint: there are no absolute requirements in hiring, just various levels of filters than can be overridden at will.
> They have the job, you want it.
Are you sure? If they have shitty processes and use shitty tools to evaluate the quality of an applicant - I am not sure, that they have the job someone wants.
This isn't a one way street. As an employer I want the best possible candidate. I want someone who can think on their feet and is able to say no to unreasonable demands. I want someone that brings his own perspective to the table.
If I want a code monkey - I would advertise for one.
And as an employee I want an employer who values my brain and my problem solving ability in complex and ever changing environments more then arbitrarily idiotic coding tests (or in my case analytics problems removed from anything resembling real world situations).
I am glad to be working at a place that enables me to have both (as a colleague sitting in talks with applicants and being an employee).
I've pushed against tests like this before, especially "sample projects".
My experience doing so falls into exactly two categories:
+ Companies that get very upset (one even had the CEO email me cursing me out after I said I wasn't going to remake a twitter API client considering I had a github full of API clients including one for twitter already!)
+ Companies that go "Oh, actually yeah, that seems to make sense. Can you highlight a few repos you'd prefer to show us, or do you mind doing some whiteboarding with us?"
You never, ever, want to work for the first category. The first category of companies are the same people who usually expect you to work a lot of additional hours for free, have poor internal practices at least around work/life balance, and generally treat their engineers like code monkeys instead of people.
So, I usually push back against these tests because it's very revealing to do. Even if you end up caving, it's important to test the companies response to a bit of polite push back.
He has the skills, they want his skills. They are coming to him in the hopes that they're a good fit and that their rewards are enticing enough.
He obviously doesn't need to worry about being hired by ABC.. the only reason he didn't outright reject their test and proposed an alternative is because he thinks it's an interesting company or product.
Look at it in another way - they want somebody to work for them, you can provide this service. It's a business agreement, not some mercifully offered gift. Both sides want something from the other. The sooner we stop thinking about jobs in terms of servitude, the better off we'll all be as employees.
I think it's probably a great way to understand the culture of the hiring organisation and to see if your approach would work with theirs.
It'll probably be relatively unsuccessful at a bigger company with worse internal comms, with an HR function that's too far removed from the engineering team.
I'm sure you'll find a job that suits _you_ with this approach, though.
I think that is a great response. But you also should be prepared for them to say no, not because your proposal is bad, but because many hiring managers want to put all applicants through the same hoops, to understand better how they all compare when having to decide between 5 people who all could do the job well.
Not just that, but doing a completely custom interview just for this one candidate is a lot of upfront investment to make in someone you may not even bring onsite for the full interview.
All the caveats this candidate mentioned about standard coding screens are true, but they can all also be taken into consideration by qualified interviewers.
There are flaws in this candidate's proposal too. In particular, their proposal does not satisfy their implicit criteria that the interview should mirror real-world conditions, because they chose their own projects with which they are already intimately familiar but the job most likely consists of working on a pre-existing codebase that they know nothing about.
Real world conditions like the one that you edited out of the sentence you quoted. The point is that neither exercise perfectly mimics the job the OP is being considered for, and they fail to do so in different ways.
There is no mention of "working on a pre-existing codebase that they know nothing about" in the description of the HackerRank test... so I don't know how your point applies?
Sure, it's very hard to fully approximate that aspect of the job in a quick coding screen. Small algorithmic problems don't come close in the grand scheme of things. But they still put you in an environment and context where you don't have the advantage of being an expert ahead of time.
> But they still put you in an environment and context where you don't have the advantage of being an expert ahead of time.
Yet by forbidding the use of external research and libraries they remove the two main tools I would want some to use "in an environment and context where you don't have the advantage of being an expert ahead of time"
Sure, that's not ideal. And the more that I read about HackerRank specifically the more I'm convinced it's a step back from boring old phone screens. We do the latter with a Google doc, and while it's technologically primitive in comparison it gives us complete flexibility and ensures the candidate can always ask any questions they have, either about the problem or about the company/job/etc.
The problems should be chosen such that external research and libraries are not needed. For our phone screens, we don't even require the code to compile or successfully run. For instance, we explicitly tell candidates to just make something up that sounds reasonable if they need a standard library function that they know exists but they can't remember its exact name or type signature.
We've never used HackerRank, so I don't really know how customizable it is. From the comments here, it sounds like it's designed to be fully automated with no participation from any developers at the hiring company. I don't like that at all. When I wrote my original comment, I'll admit I was thinking of it as a more advanced Google doc for programming, not as a fully automated platform. That's my bad, and I should have done my research a bit more.
For a homogenous culture of a large corporation, where each dev is a cog in the system, yes, i would agree that this person will not fit.
If i had a start-up, i would definitely give this person a good old try, because i can tell that he/she is capable enough to churn out rather advanced projects with complexity higher than just CRUD. Programmers of this type is what i'd call 10x, and one should never dismiss a 10x!
I would be even more hesitant to hire for a startup! can this person grow with the startup? what happens when we have 10, 20, 30+ engineers - how will they work with the team - will they second guess everything? will everything be an argument?
I'm not doubting this persons ability - I'm only responding my opinion of this person based solely on this email.
I have never been in a startup that fears arguments. Every startup I have been a part of has lively debates and arguments almost every other day. It's only the large slow moving corporate giants where I see such lack of debate and arguments on what is obviously wrong.
I would go to the extent of saying that a startup that does not encourage arguments in a harmonious fashion would die very soon anyway. Debates and arguments help in weeding out stupid ideas and focus on what that really matters.
This person's email shows that he can have a qualitative argument in a coherent, polite, and non-confrontational fashion - exactly the kind of people you need in startups!
I'm afraid I have to disagree. They're called 10x engineers because they're 10x as productive, not because you have to take 10x as long to talk them into not using Haskell for a basic CRUD frontend (remember, it's a startup, someone has to do that part - not everything is gonna be sexy to code).
If they're too cool to waste a single second conforming to a basic FizzBuzz test to assert that their resume isn't a lie, they're probably way too cool to do anything but write the most glamorous code in the most visible part of the product - which is the last thing, a startup - with too much work and not enough people, needs.
>If they're too cool to waste a single second conforming to a basic FizzBuzz test
I'd be willing to waste 5 minutes tops, unless the employer has put some skin in the game (fizzbuzz is ok - nothing much more than that tho).
There's a 1,000 other employers out there who might be a better a fit. I am not going to do a 1 hour, 30 minute or even 15 minute task if they can't at least even be bothered to pick up the phone to talk to me or glance at my github profile.
Companies that expect completion of a weekend-filling exercise before granting you an interview are universally run by entitled assholes. You're actually doing yourself a favor by screening them out: they'll be bad to work for, you won't get to work with other 10x engineers and the company will likely achieve nothing impressive anyway.
Maybe he cares about the industry as a whole? By putting his reasons up publicly, he has triggered a debate about the issue. This seems like a very high cost-benefit ratio to me!
...If "Tells me when I'm doing something in a way that could potentially be improved, in a polite, validated way" falls under your definition of "Difficult to work with", then perhaps he wouldn't want to work with you anyway.
However if you want to hire people to just complete tickets as fast as possible, maybe that's a valid reason to reject the candidate.
To your first point, yes exactly. The interview is as much mine as it is the candidates.
Not necessarily hiring to complete tickets as fast as possible, but some who can take a task and complete with minimal issues. I don't want to be stuck in meetings or arguing in PRs etc.
Would you really want someone to take a task and complete with minimal issues if the task does not add value to the organization or is counterproductive?
I don't know about you, but I would not want to hire someone who can take any task and complete with minimal issues. Where I work, one is encouraged to argue about what is not right in the meetings and offer better solutions.
This candidate is doing exactly that: Argue why a certain hiring methodology is not effective and what a better alternative is. Considering that this candidate does not just follow orders but challenges the status quo and the fact that he has volunteering-based projects to show makes this author very likely a good fit for my organization.
Let me explain a little better, and again I am only basing this all off the small amount of data we have.
Let me give an example as I am not the best at articulating. hopefully this helps.
Lets say I hired this engineer as Senior or Team Lead. Now I want the base docker image we use for node bumped a major version. I checked the changelog for the nodes releases and knowing our codebase I think its safe.
I could ask a Junior dev to do it, but I knowing that they are lacking experience this may seem like a "big deal" when really its not.
What I want is the node version updated, validation unit tests pass, regressions tests are good. And it to be released. If there is a failure along the way, address it or sure lets chat about it.
But this Email in response to hackerrank - would make me perceive this to be someone who would respond with a complete change to our CI/CD processes, to our infrastructure, maybe to even using Node - as this sort of task is beneath him.
Sure there would be areas this person might excel at, but some days little tasks just need to get done to keep the ball moving.
>But this Email in response to hackerrank - would make me perceive this to be someone who would respond with a complete change to our CI/CD processes, to our infrastructure, maybe to even using Node - as this sort of task is beneath him.
This makes me think that you're a poor judge of character and of a slightly authoritarian mindset.
This email is one of many protesting an industry interview culture that prioritizes badly thought through exercises that bear little relationship to the job being interviewed for.
>What I want is the node version updated
And do you really think that seeing candidates reverse a binary tree without protest will tell you how well they can perform at this kind of role?
> would make me perceive this to be someone who would respond with a complete change to our CI/CD processes, to our infrastructure, maybe to even using Node - as this sort of task is beneath him
Looks like it is a difference in culture that I am used to and the one that you are used to.
At my workplace, it is perfectly acceptable for someone to suggest a complete change to our CI/CD process. In fact, we have changed our complete CI/CD process twice (SVN/build scripts -> Mercurial/Jenkins -> Git/Travis-CI) already with minimal loss in productivity because someone questioned the existing CI/CD process and suggested a well thought plan to switch to a new one.
But I get your point that sometimes it may not be feasible to carry our such a drastic change in process, infrastructure, etc. But suggesting such a change is going to be acceptable and we refusing to accept such a suggestion is also going to be perfectly acceptable and both this person and us working in harmony even after this disagreement is also going to be acceptable.
No more extreme than suggesting that someone who raises thoughtful questions on a broken hiring process must certainly be a bad fit for an organization.
> Sorry, I don't want to work with a bunch of pedants.
If they are assuming they know more than everybody involved and making suggestions to a process they haven't even gone through 20% of, then yes, they are probably a bad fit.
It's extremely hypocritical to criticize someone for the very thing you are doing (assuming the other person doesn't know how to do their job). Couple this with the fact that they are not asking for any advice on their hiring process, it's a pretty rude thing to do.
A little bit of fluff added to the wording doesn't make it suddenly polite.
> I would not want to hire someone who can take any task and complete with minimal issues.
Someone who can't do straightforward tasks without having an issue is incompetent, pedantic, or both.
If your company wants people to just do straightforward tasks without raising pertinent questions, your company sounds like a bad fit for many good engineers I know. For example, I personally, would never work for a company like yours.
I am quite lucky to have worked in companies where the peers and management encourage debates and arguments and do not take it as a sign of incompetence.
I had no idea there were companies that would take perfectly reasonable questions on a broken process as a sign of incompetence. Thank you for enlightening me. I now know to be careful enough to avoid such organizations in future.
I never said raising issues is bad. Where I work, we highly encourage people to bring up issues as they see them.
However, when you bring something up as an issue, it usually helps to suggest a solution (which this original GitHub post fails to do) and we don't generally try to take unsolicited advice from people who aren't even part of the company yet.
I'm always struck by how many people in this field I encounter who think it's not collaborative work and that it's "OK" to work at a desk with headphones on all day.
Maybe at a consultancy and only if you're far downstream of dealing with clients.
Going on and on about issues you already brought up in the past, while they may be sensible, but for which you don't have the time or resources to fix just yet doesn't do any good either. So a constant complainer would be someone difficult to work with.
In the same spirit you could definitely see it as unreasonable for a candidate to suggest you adapt your screening process because they know better (even if it's said in a polite, validated way).
"Difficult to work with" is perhaps too harsh a statement. But the candidate is asking for a completely custom treatment at the earliest possible stage of the interview process. The candidate is also assuming that the interviewers aren't aware of the caveats mentioned about standard coding screens/HackerRank exercises. The candidate's proposal also doesn't mirror real-world conditions, because I doubt the job consists of adding features to their own codebases. The candidate also doesn't seem to acknowledge that this is not the entire interview but rather just a low-investment screen to decide whether to perform the full interview in the first place. The candidate also glosses over the value of the standard screen, which is that it's uniform across all candidates.
To be clear, I wouldn't rule out someone for this, but I can sympathize with where I believe the above poster is coming from.
You're asking the same of the candidate, though. You want them to write a unique solution to your silly puzzle tailored to your company.
It's a two-way street.
Low-investment on the part of the employer. They still expect me to spend 90 minutes on proving I have seen a REPL before, which is time I, frankly, don't have. I'm happy to answer/talk about things that relate to my job, but working on puzzles that just happen to be solved more easily by programming has exactly nothing to do with it.
> the candidate is asking for a completely custom treatment
What's next? Having to actually look at someone's CV? That's insanity.
I can only speak for where I currently work. Our phone screens take 45 minutes on average rather than 90. If you don't have 45 minutes for a coding phone screen, then you also don't have 45 minutes for anything else you just mentioned, so I actually find your response fairly disingenuous. In fact, you don't have time to interview with any company in any capacity at all.
We actually take great care in examining resumes and CVs before proceeding with a coding screen. We've had plenty of senior developers fail the most basic questions (think FizzBuzz), which is why we conduct these screens.
> Our phone screens take 45 minutes on average rather than 90
Even phone screens are better than "Here's a HackerRank link because I don't want to spend time talking to you, enjoy the next hour-and-a-half solving riddles".
I don't think I fully appreciated that HackerRank does not involve the direct participation from anyone at the hiring company. I wouldn't be on board with that, and that certainly makes more more sympathetic to the OP.
Yeah, that's what galls me about it. They even give you (the proverbial you) tests so you literally have to spend zero effort, yet you tell the interviewee to spend 90 minutes on it because it costs you nothing. If you want me to spend time on your process, at least spend that time with me. I want to learn about you as much as you want to learn about me, but you don't see me sending you a Google form with 300 questions about your company to fill out.
Well, washing cars turned out to be the point for The Karate Kid... and humility before technique. I agree that few employers will be like Mr.Miyagi though ;
It's a kids' movie. But the point was humility before the art. Always in training. Shoot, Mr. m practiced teaching better by tending tiny metaphorical bonsai trees and catching flies with chopsticks, so he was not above being a student in training himself. I'm not saying it is everyone's philosophy or should be- it just cracked me up- the car washing reference- not to say that I disagree that these tests are more a sign of an employer I would not work for. Hey- someone removed the car wash analogy I was responding to! I thought it was funny. I think swe should push back against this kind of treatment when it's worth it to them. It is insulting.
These tests aren't useless. Tons of candidates have never seen a REPL before and are totally unable to solve even a trivial coding assignment.
I suppose your company is too clever to waste their time on such useless tests? Who at your firm wastes hours interviewing candidates who have no ability to code?
If someone has never seen a REPL before, it'll take us less than 90 minutes to figure it out, so we don't tend to waste applicants' time with those.
Going through someone's Github (or any other project they feel is worthy of sharing) and asking them questions about why they made the decisions they made has been orders of magnitude more illuminating than asking them to come up with an algorithm for solving the subset sum problem without Googling.
But now your process is heavily biased against folks whose work has primarily been for their current employer, and they don't have any reasonable side projects to walk you through.
My fear would be that you wouldn't have a rigorous, well-tuned process for those folks, so there could be a lot of noise or randomness in their evaluations. And it could be very hard for you to compare them with the folks with extensive GitHub portfolios and resumes.
Perhaps, but what's the alternative? Don't look at anyone's OSS projects (and lose a LOT of valuable information) because it would put the people who don't have any at a disadvantage?
I think the main thing would be consciously correcting for that: the real value is asking about design decisions — it's my favorite technique — and just making sure that it's fully normalized that not everyone has those out in the open.
It's still easy to spot the liars — e.g. I've interviewed people who worked at the NSA and even they could talk about the skills they used, just not which projects or data — and the process of deciding which things to talk about is a pretty good way to explore their communications style, too.
Yes, that's what I generally tend to do. I present them with a scenario or a problem and have them walk me through how they'd solve it and what their tradeoffs would be.
I have a lot of problems with this paragraph, the same problems I see again and again on both sides of interviews.
> "Difficult to work with" is perhaps too harsh a statement
That's exactly what the OP meant to say, and verbatim what they would have said in an interview debrief. The interviewee wanted some amount of compromise, and all of a sudden they're "difficult to work with". Now everyone else in the room is framing this potential hire as an asshole. There's no coming back from that. I've seen this happen many times. One term of phrase like that and instantly a qualified candidate is out because someone latched onto a single fault and made wild extrapolations about it.
> just a low-investment screen
You have no idea how much of an investment it is. I've had hacker rank problems that I was expected to spend 3 hours on. That's a pretty big investment just to get my foot in the door. Sometimes (read: often) the juice just isn't worth the squeeze. The employer wants me to give it my best when they're not even willing to come up with their own questions.
> uniform across all candidates
I see this a lot as the panacea of interviewing. Sounds good to have everyone on a level playing field. But if you start out with a crappy process, applying it to everyone equally isn't going to get you good talent. As an interviewee, I'll still be bitter about the bullshit you put me through, even if everyone else had to do it.
My comments are mostly sarcastic and polarized, so don't bother that much. Companies are missing out on a ton of creative talent, but they have to play safe and keep their recruitment costs low. I only understand that from a business point of view. Every other perspective suffers.
Filed under sad-but-true. Worse, your ability to code doesn't make you special, and doesn't qualify you as an interesting human being to anyone outside of tech recruiters, and only then if you are able to produce code on demand in front of a whiteboard.
Thankfully, as a human being, you are not your ability to code. More importantly though, then it also means that people who can't code are worth just as much as you as human beings (more, if they've managed to learn social graces). If you don't hold it to be true, then code or GTFO.
Look for places like the Recurse center in NY that can help you find yourself in the context of being able to code, or more traditional non-traditional approaches like backpacking though India, or taking LSD in the Haight in the 60's (anyone got a time machine?).
If you'd like friends (who will be interested in your personality), go find some. Outside of work. Bonus points if you manage to find some that can't code.
Hint: companies are interested in your personality - if you come across as this caustic in a phone screen or in person interview, I'd be surprised if you get invited back. (Or at least they should be; Google's current HR woes are their own creation.)
I'm not sharing the view on the difficult the work with part.
For me, this just means, that he is not accepting a solution to the problem, explaining why he thinks it is not a good solution and offering another one, which would work for him. Also, he is not dismissing the hackerrank test, but asking to evaluate his skills on a different way too.
As far as I see, this is probably the best way to argue with somebody, that their chosen solution to the problem is not the ideal based on your knowledge and experience.
Depending on who you are, having a personalized interview may make perfect sense. I'd say hiring a senior developer or a team lead should always take it.
I would worry about a company who sends lead and senior devs to HackerRank to do junior level programming tests and managers who weren't willing to engage in a conversation.
I wouldn't be concerned with their being combative. I'd be concerned that, without any attempt to make sure they knew the full context, they assumed ignorance or stupidity on the part of the hirer.
This kind of approach is fine for a junior. I'd even encourage it because there's an attempt to change the parameters of the problem which is something we often have to teach people as they progress.
For a senior position, not so much. I mean, it might be that they're ignorant or stupid, in which case you've probably dodged a bullet when they don't hire you. Or it might be something else entirely.
A more sensible approach, in my view, would be to ask what they were looking for with the HackerRank test in a subsequent face to face. If they say that they don't have a better way to determine developer competency then, sure, suggest that you may be able to help with that when you join.
If it were me interviewing, I'd be particularly interested in suggestions that a) were developed from successful prior hiring practices and/or b) not so bleeding obvious as "look at their Github page".
This is my first thought as well. It costs a lot of time and money to interview and hire - I do my best to not waste candidates time, and I hope for the same consideration on the other side of the table. Been at two startups and two enterprises and have worked with dozens of great devs who wouldn't respond this way.
If I came across this in the wild, I'd reevaluate the parts of the interview I control to see if maybe I could make it less robotic and I'd probably still bring them in to make sure I'm not missing a good dev, but I would be fighting my bias at least a little. There is a small handful of people I've worked with before that would appreciate this approach and their toxic attitudes would prevent me from wanting to work with them again.
The interview process can suck, but this is not how I'd recommend standing out from the herd.
I appreciate you being so honest. Let me be honest in return:
You'll never work on interesting, important work until you embrace a worldview that discards bureaucracy.
If you want creative solutions to interesting problems, you need to sit up and listen when somebody takes the time to write a thoughtful reply like the OP did.
If you want another drone hammering out application code and working overtime out of fear, just keep ignoring folks like the OP. You'll be out of work soon enough, anyway.
Interviews are a 2 way street. Candidates have as much right to evaluate the companies that are trying to hire them as the opposite.
Not the OP but, absolutely I want a personalised interview! I want the company I'm working for to care about the people they hire -- not to efficiently fill empty seats. Yes, normally that means I tend to work for startups. I'm happy with that.
It's fair to say that you want to be able to evaluate potential employees cheaply before you invest a full interview. It's also fair for people to offer ways to do that evaluation rather than running through someone's maze. Neither side needs to accept the other's offer, but there's no need for either side to take it badly.
A "no" is quite a good result if the company would otherwise be wasting the candidate's time.
My regular policy is to ghost any employer who throws a HackerRank test at me. This is usually a strong indicator that the work environment is incompatible with my values.
US companies ghost candidates all the time. They actually do it on purpose, partly out of a fear that explicit rejections (especially with reasons given) may elicit lawsuits.
Our applicant tracking systems won't be upset if you ghost them/us. Your application will simply expire after a while.
Recruiters acting in a professional capacity or companies, both of whom would ghost you without a second thought? I gotta say I don’t really see the problem.
I politely tell them I'd be happy to have a call or phone screen with them, but I don't do automated puzzle-type tests. This gives them an opportunity to give me their side of the matter and also gives them a signal that at least one candidate dislikes automated puzzle-solving tests.
In addition to my other projects, I've also added the code of all HackerRank problems I've solved to a repository on Github. I link that profile whenever I look for a job. This way the recruiters have an abundant source of code samples they can look at when making their decisions.
If any of the candidates I've interviewed and hired had this sort of independent and outside-the-box thinking, I'd have doubled their salaries when I hired them.
If the implication is true, that would be a data point.
If the implication is false, it would be an exciting data point!
HN being what it is, here is quite a non-zero chance to meet a person with real hiring power who really could have made an offer to the person in question.
Seems to me like an org that uses a recruiter isn't looking for "outside the box" employees. Obviously they aren't sourcing candidates with outside the box processes.
You probably might as well have written 'no' for all the difference it will make, but I have to commend you on the carefully worded and actionable bits in your reply.
If I were the prospective employer I'd probably write you back that before we will invest into looking at your production we kindly ask you once again to jump over the low bar that was set for all applicants. Then again, if I were your prospective employer I'd never have used hackerrank in the first place because I feel that to expose a potential recruit to a third party service would be a breach of confidentiality and besides I feel that such services are - as you correctly identify - ill suited to picking the people I'd want to work with.
Evaluating side projects is a perfectly valid way to document a software engineer's potential value to a company, but that's not really the point of HackerRank. The purpose of HackerRank is to be a coding screen - that is, a test of basic ability to code simple algorithmic problems under moderate time pressure.
I have taken a number of HackerRank screens myself, and I have never seen one that either (a) tests beyond the coding level that would be expected of a fresh CS graduate or (b) is not vastly exceeded in scope and complexity by the coding challenges given during the onsite, which do allow considerably more flexibility and relax some of the artificial constraints.
Why attempt to circumvent a test that is meant as a slightly less trivial FizzBuzz?
I am responsible for hiring developers, and I do find online programming tests very useful.
They serve as a relatively simple early-stage screen for applications from people we've never met. Ours costs each candidate 1-2 hours. But we do not require cover letters, which in the good old days might have taken about half that time, and been thrown in the bin.
Some may think no CS graduate would fail a test that let you choose any popular language to implement some basic string parsing. But in practice about half the candidates fail this stage of the hiring process, which saves us quite a lot of time. Yes, it costs each candidate an hour or so, but that's a feature, similar to the oft-proposed idea that sending email could cost one cent to reduce spam.
If you don't mind sharing, what size company and how often do you hire devs?
>Some may think no CS graduate would fail a test that let you choose any popular language to implement some basic string parsing.
I don't see anything wrong with basic screeners like that, but I have experienced some really silly stuff. Recently I was given a test that asked ~10 questions (some trivia, some paragraph type response), a few small simple questions (reverse a string, etc.), create a class to handle card games (poker, blackjack, etc.), and create a user repository... in 30 minutes. I felt like a dog at a dog show.
45 person office, hiring developers gradually and continually. But what I wrote also applied when I was at a 6 kiloperson firm and we hired a hundred developers a year.
Some tests will seem impossible to complete in the alotted time. Often that's intentional. It saves time for the candidates and gives a better spread of scores (very few will get 100% in some test batteries). But it can be disheartening. For these initial online tests I try to give enough time that most people won't really run out of time unless they get stuck.
I've interviewed and hired many devs. I find hackerrank style coding questions very useful in interviews and I agree with the superiority of your alternative suggestions.
Keep in mind that these quizzes are only one single part of a multi-part interview. Also keep in mind that acting offended by whatever style of interview you get may reduce your chances of getting the job you want.
You might be amazed how different answers can be on easy code puzzles, or how deep of a discussion you can have over a single line of code. The easy questions might be easy for you because you're good, but often there is a low bar for the first round interviews for a specific reason: to weed out the people who have less experience than they claim and/or couldn't be bothered to prepare for the interview.
Also, when several or many candidates are being interviewed, it takes a lot of time just to administer low-preparation interviews. Pair programming, as nice as it is, simply can't be done by the lead dev for all the candidates without keeping him from his job coding.
Remember, the main thing your interviewers are trying to do is compare candidates against each other, so they need standard a way to see who's better than someone else. Hackerrank type questions are definitely not ideal, but it does what it says: rank people against each other.
I would absolutely welcome ideas for being able to rank people in programming skill with some method that is closer to pair programming but takes less of my team's time. The suggestions in the article here are lovely, but they don't help someone who's interviewing because they take too long to evaluate, and they're different than anyone else so they're much harder to rank candidates.
> how deep of a discussion you can have over a single line of code
That's the problem with HackerRank: You can't! Every single time I've tried one, it was a dismissive "do this on your own time and we'll check your answers".
Not to mention that their question sets tend to be full of puzzles, which are the type of thing where I'll have an epiphany over lunch, rather than something I'll figure out how to optimize in the ten minutes I have to code the solution.
Agreed, this is why I give my own coding quizzes, so I can have a discussion about it. I'm more interested in the thinking than the answer.
But, I do have sections in my interview that test knowledge and not skill, so I can still see the usefulness of letting Hackerrank be a part of the process.
The one thing I don't claim is that HackerRank or coding quizzes are perfect. This is why coding quizzes are only one of maybe six phases of an interview.
I've never used HackerRank personally (although I'm looking into for the next round of hiring I'll be involved in), but it seems it might be kind of useful as one step towards deciding which of the 50-100 candidates that applied you should invite to the pair programming session. You simply cannot have your lead dev doing pair programming sessions with 50+ candidates for each job opening.
It's an interesting idea. Phrased politely I think it's fine to suggest. Still I can understand why people would refuse your approach. There's an obvious risk involved letting the applicant dictate the terms of the evaluation. The point of coding tests is that you can't prepare or easily Google an answer. The employer wants to gauge your unscripted in the moment programming knowledge. Also as someone else said, you need a way to compare apples to apples. Not everyone has an amazing Github to show off.
Still I wish employers would better understand the limitations of automated coding tests. Pair exercises where I can use my own environment and think out loud with an interviewer aren't so bad. Fully automated stuff like HackerRank often make simple things overly complicated because they expect answers to be written a certain way. I think those sorts of tests are only suitable for really low level screening - ensuring a sysadmin can use basic bash for example.
> The employer wants to gauge your unscripted in the moment programming knowledge.
I see the appeal of knowing this but I think I'd take a submission from the OP as-is in place of a "coding test."
My thinking here is that I can't recall an instance where I needed to write code at a job with a timer ticking down and someone reviewing my work as I went. I usually have the luxury of doing some research and taking a few attempts at a problem before I understand it and write a decent solution.
I'm not sure what we expect from candidates when we force them into these situations. Am I supposed to be impressed by their solution? I can't think of how I would be. The code I'm most proud of writing took me several attempts to write. Often over a long period of time. Am I supposed to gain some insight into the way they think about problems? I already know how most people tend to solve problems. It's a well understood area of research. What else is left?
All I expect candidates to prove is that they've practiced a problem set and can recall a large number of solutions to trivial problems. Useful but it doesn't give me an indication about how they'll perform. Three months into the job and they'll probably forget 60% of the problem sets they practiced anyway.
Do I want to hire programmers who have an intuition of complexity and know when to use a binary tree or a linked list? Definitely! But I'd rather talk to them about real experiences they've had when they had to make such choices and find out why they made the trade-offs they did. It's hard to do that with trivial problems.
I'm a little biased as a devops guy and former SRE. When you're on call dealing with strict SLA's, your ability to make intelligent technical decisions quickly is important. I expect the guy I hire to not have to Google how to check CPU load or how to pipe tail output from log files into a grep function. At the very least a timed coding exercise tests their nerve.
For other development jobs I generally agree with you. The coding screen will not tell you much. Particularly for a mid-level or senior role. In those cases I am way more interested in their portfolio and in having a long casual technical discussion.
The SRE team is infamous! I tried the interview for the SRE team to see what it was like. At the final interview I was asked to implement a K-NN algorithm, which I did, and then optimize it for k dimensions.
When it was over I asked the interviewer if there was ever a time when he had to implement such an algorithm on the job during a production outage event and his answer: No.
In my experience working within devops teams maintaining and developing public cloud infrastructure I don't think I've ever had the pleasure either.
In retrospect I don't think it was a bad experience. I think there are roles which exist in software that do require a higher level of rigor than others. I'm often amazed how easily many developers will dismiss performance concerns (premature optimization!) for example. I would expect a hiring process to be upfront and honest about such requirements and candidates should be aware of their own skills and background before applying.
But most software development jobs at ABC Corp are not the SRE Team at Google and they hire as if they were.
I think that's the risk we take with standardizing and automating hiring processes.
Letting the applicant dictate the terms of the evaluation
That sounds vaguely biased toward the employer. An interview is a a two way process. The candidate in this case will likely have no problem finding a job. In a way, it sounds like he's doing his own pre-screening and the hacker rank request is a non-positive signal for him.
Our profession is somewhat bifurcated. There are the developers who only ever do glue code between systems and never progress beyond java 1.4 and work places where that is a valued trait.
This candidate however is in the other camp. He's creative, and self driven in his learning. He's also driven to get better. He won't be satisfied at the kind of place that doesn't look at him as a unique and creative developer.
This was a negotiation not letting an applicant dictate the terms of the evaluation.
How can I, as an employer, provide a fair interview process if every interviewee gets to pick terms? A uniform process isn't because we think it is the optimal process, but because it is the best process that ensures fairness.
Here's the thing. Not every interviewee is going to care. You do it on a case-by-case basis where you weigh the importance of the position you're trying to fill with your time. Looking for a productive, average developer? Then say no to their terms. Looking for the best of the best? Then you may want to spend that extra 5 minutes looking over their CV and consider if they might be worth your time.
Picking the terms is a negotiation. I think sometimes we forget that the interviewee is also interviewing us as a prospective employer. This isn't a school exam. Hiring is a business negotiation. Pretending that it's not is counterproductive.
> Also as someone else said, you need a way to compare apples to apples.
This is really important. For any company that does business with the federal government (even if it's only a small part of the company), they're required to keep records to prove that they don't discriminate in their hiring practices. The way almost every company does this is ensure that their practices are standardized and no candidate has any sort of different experience.
If they let this candidate have a non-standard interview, then hire them over someone who is in a protected class, they'd be opening up a TON of liability.
This is an important point that people defending the author need to consider. I agree that hiring is a two-way negotiation. Flexibility is great. But there is a significant moral (and legal!) hazard when you let some people skip the code test because they have an amazing Github and others get rejected for not passing the screen. You're filtering out everyone who isn't privileged with the free time to build up an amazing portfolio. People will argue that this disproportionately hurts minorities, women, and lower income people.
Honestly, HackerRank is a pretty standard and easy test. I really think it's a reasonable test, at least more reasonable than some. I've been given much harder take home tests:
Typically, I'd interview at least 10 people before I'd give an offer. Once we added improved screening we got that number down to 5 people before an offer (note screening wasn't HackerRank).
I think it's reasonable to screen and HackerRank is just that, it's not about complexity.
Good luck but they may just want a robot who shuts up and conforms. Despite some people here saying the balance of power does not necessarily rest with the employer, in some cases it does if there are many desperate job seekers who are willing to jump through hoops. You may want to apply to specific smaller teams and/or do your own thing. That said, if you do bite, I have learned a lot from my stints at places who hire like this. The biggest lesson I learned after several years is doing my own thing is right for me.
In their defense, they probably have a very difficult time weeding out candidates that don't know anything about programming. It seems like this is the new alternative to a 30 minute phone screen, and I bet a lot of candidates actually like it. But it's good they have your feedback, and if they aren't too crusty, they will use your demonstration of knowledge in stead of your HackerRank score as proof you know your stuff and pass you on to the next level.
> unnatural conditions including (1) time limits, (2) forbidding research on Wikipedia or StackOverflow, (3) forbidding collaboration, and (4) forbidding the use of libraries
The above indeed does not make sense, unless you're hiring a solve-puzzles-as-sports person.
I don't think it's enforced by HackerRank, though. It must be the employer's requirement. If so, their hiring process does have problems.
I think this is enforced by HackerRank, colleague recently griped that they couldn't set the time limit higher or get rid of the messages forbidding x,y,z.
I agree with you on the points that HackerRank actually is not a very good indicator of how good programmer one is.
However unless they really like your profile they will immediately next you after that kind of response because companies also don't have time for this nonsense. They just want a standardised tests for all candidates so they can rank them and then hire the best.
As a hiring manager, I personally don't use HackerRank (or anything similar), but I'm thinking about it. My issue is that many of the people who I come across (most of whom claim to have backgrounds in CS) don't have even basic coding skills. For example, "write a function to reverse a string in a language of your choice" baffles them or takes 20 minutes to write, even though it was meant to be a quick warm-up question. If I know someone is strong coming in (for example, someone I trust recommended them), I will tailor the questions more to them, but otherwise, giving some basic coding problems weeds out a lot of people and saves everyone some time.
Even a short phone screen where I just ask someone to code a simple question takes 20-30 minutes of my time (plus however much time I need to get back in the zone), so HackerRank is appealing if only to weed out the very worst candidates. I'm not familiar with HackerRank specifically, but I imagine you have some choice as to how to set it up. If I could set it up to give candidates plenty of time and ask relatively straightforward questions to weed out people who don't have the basics down, it would be a huge time saver for me.
How often does one have to reverse a string? What is the purpose of such a dumb test? How often have you had to do such a thing in the real world (outside of tests such as interview questions?)
I suppose you could make the argument we do have to reverse arrays, but strings? Give me a break, only idiot programmers spend their time practicing for useless programming interview questions.
I'm not sure if you have ever been involved in the hiring process from the first stage of screening resumes, but my experience has been that when you post a developer job, many people will apply with very weak coding skills and those people need to be weeded out. Some of them have strong-looking resumes, but I often come across people who stretch the truth on their resumes. So when I do a phone screen, I start out with a basic question that surprisingly weeds out a lot of people. I let candidates code in a language of their choice after hearing the question.
Is reversing a string something I do in the real world? Very very rarely if ever. But it's not meant to be a question that simulates a real world coding problem. The point is that it's a very simple problem that anyone proficient in almost any coding language should be able to do. And I don't know anyone I've worked with who wouldn't be able to do this in 5 minutes or less, with or without practice.
Does one really need to practice to reverse a string? Do we now live in an age where a programmer cannot reverse a string purely from basic knowledge about programming and common-sense?
Reversing a string takes 2 minutes or less even if all you know is how to work with strings and how to write a for-loop.
Of course the question is biased against certain programming languages. For example, in python:
def reverse_str(x):
return x[::-1]
works. If you remember this notation, then you'll have this problem done in 30 seconds or less. But even if you don't remember this notation, I expect a candidate to figure out some way to reverse a string within 5 minutes in some language. I can think of engineering roles that rarely work with strings, but in the roles I hire for, we use them a lot and so I want to know that you have the basics down. If you know that:
* strings are simply arrays of chars
* how to access an item in an array
* how to write a for loop
Then you have the tools you need to solve this problem. Are there any common languages where this is a particularly difficult problem (I'm genuinely curious, not trying to be obnoxious... if so, then I might consider changing the question for the future)?
I am with you. Although most modern languages would offer shortcuts to reverse a string but the spirit of this question is to see if a candidate has the mental agility to come up with a solution purely from ones knowledge to use a programming language and common sense.
One should be able to devise a solution to a simple problem like this without any CS course at all.
or code units/code points/grapheme clusters/emojis. Thanks to hard work of many developers string handling becomes easier over time, but I don't think it's trivial if you don't exactly specify what you mean by "string" and "character".
I think you and I are arguing semantics then. The very question "what do you mean by a string?" already indicates that you might be familiar with some of the differences between unicode and ascii, for example. In that case, I'll clarify what I mean depending on the language the candidate is most comfortable with. For example, if they plan to use C++, I might clarify that they can assume that the string is an array of chars containing letters a-z. I really just intend it as a filtering question, but someone can definitely get bonus points if they ask intelligent questions to clarify the problem.
You can't give those answers on computer aided code testing sites. That's why those tests needs to be long, verbose and boring so the questions will be obvious.
I can't speak for chadash, but I'm pretty sure most folks who know to ask questions like this are probably going to pass the interview. They'll ask the right questions, and the problem will be simplified to a form that is solvable in a few minutes. So I don't think this is any major hurdle.
> Even a short phone screen where I just ask someone to code a simple question takes 20-30 minutes of my time (plus however much time I need to get back in the zone), so HackerRank is appealing if only to weed out the very worst candidates.
But you took 20-30 Minutes of their time too, the only difference is that you get a compensation at the end of theses 20-30 min, they don't. If someone told me, "OK , i m gonna waste 3 hours of your time in exchange of a mere promise of a job", i will simply decline the job.I work 9hr/day , I have better things to do with my free time...
Yeah, with often very high ratios (I've seen above 100:1 in positions where I had information more than once recently) applicants for open positions, hiring simply isn't going to work if it requires symmetric time investment from hiring managers and applicants.
I'm assuming that you don't expect companies to hire everyone who applies and therefore some candidates are going to have time wasted. What do you think is a fair amount of time to expect someone to give for an initial screening?
My longest and latest job interview lasted 3 hours but we talked about the goals and the visions of the company (that part doesn't bother me), the technical part (code with a pen + questions) lasted about 15 mins. But to set a threshold, generally i ask if the test requires more than 1 hour, if yes, I decline politely.
The point of an interview process isn't to find out stuff about you in isolation; it's to be able to compare you to other candidates. That's only possible if all the candidates go through the same process. Also, processes get calibrated over time. The most bewildering thing to do as an interviewer is to try a new process, because it's difficult to tell how a candidate did without having collected some other data points.
I've done ballsy shit like this to get attention from employers. Once I was too slow with the programming questions in the screen-share, so I put up a website with a detailed solution to the last question.
I almost got the job, they randomly canceled the on-site at the last minute. Needless to say, I think my effort at least got me to that final step.
I can see giving a test like this for an entry level job, but for more senior positions it doesn't really make much sense to me. I'd rather show off a bunch of projects I have under my belt or code I've written in the past.
For example, I haven't had to write my own algorithm to parse a b-tree or implement binary search since I left school. I could explain how these algos work, but to actually implement it perfectly in python or java under timed conditions with no outside docs, I would most certainly fail and the company would miss out on a pretty good generalist.
270 comments
[ 3.8 ms ] story [ 272 ms ] threadEven on the surface "fairness" isn't really the objective, because there are going to be different hiring managers and interviewers throughout the whole process. The salary negotiation isn't going to be "fair" in this way.
I'd rather have someone who had a rich github history and a record of real accomplishment than someone who had none but could produce a good hacker rank score. Hiring is the most important thing that we do as managers, I'd be selling myself short if I didn't take it all into consideration.
(Manager, rummaging through an apple barrel)
“... apple ...” (toss)
“... apple ...” (toss)
“... apple ...” (toss)
“... fist-sized lump of uncut diamond ...” (pause... toss)
“... apple ...” (toss)
(Days later)
“Yeah, I found 2-3 decent looking apples... most are pretty bruised, though...”
Without even addressing the sour grapes attitude about coding interviews, the sheer arrogance with which you try to dictate someone else's process is a red flag in the first place. That, plus the fact that you're refusing to do what they want, is really bad for your chances of being hired.
Or at least I would consider hiring them if the rest does fit (culture and other such squishy interpersonal things).
By definition, if they have a job, they want to fill it with a qualified person. Jobs aren't (usually) charities to the person working.
On the other hand, it's rare for coders to be so desperate that they'll jump at absolutely any and every job opportunity. The balancne of power has long tipped in our favor.
Helpful hint: there are no absolute requirements in hiring, just various levels of filters than can be overridden at will.
This isn't a one way street. As an employer I want the best possible candidate. I want someone who can think on their feet and is able to say no to unreasonable demands. I want someone that brings his own perspective to the table.
If I want a code monkey - I would advertise for one.
And as an employee I want an employer who values my brain and my problem solving ability in complex and ever changing environments more then arbitrarily idiotic coding tests (or in my case analytics problems removed from anything resembling real world situations).
I am glad to be working at a place that enables me to have both (as a colleague sitting in talks with applicants and being an employee).
My experience doing so falls into exactly two categories:
+ Companies that get very upset (one even had the CEO email me cursing me out after I said I wasn't going to remake a twitter API client considering I had a github full of API clients including one for twitter already!)
+ Companies that go "Oh, actually yeah, that seems to make sense. Can you highlight a few repos you'd prefer to show us, or do you mind doing some whiteboarding with us?"
You never, ever, want to work for the first category. The first category of companies are the same people who usually expect you to work a lot of additional hours for free, have poor internal practices at least around work/life balance, and generally treat their engineers like code monkeys instead of people.
So, I usually push back against these tests because it's very revealing to do. Even if you end up caving, it's important to test the companies response to a bit of polite push back.
He has the skills, they want his skills. They are coming to him in the hopes that they're a good fit and that their rewards are enticing enough.
He obviously doesn't need to worry about being hired by ABC.. the only reason he didn't outright reject their test and proposed an alternative is because he thinks it's an interesting company or product.
It'll probably be relatively unsuccessful at a bigger company with worse internal comms, with an HR function that's too far removed from the engineering team.
I'm sure you'll find a job that suits _you_ with this approach, though.
All the caveats this candidate mentioned about standard coding screens are true, but they can all also be taken into consideration by qualified interviewers.
There are flaws in this candidate's proposal too. In particular, their proposal does not satisfy their implicit criteria that the interview should mirror real-world conditions, because they chose their own projects with which they are already intimately familiar but the job most likely consists of working on a pre-existing codebase that they know nothing about.
Real world conditions like these?
>> (1) time limits, (2) forbidding research on Wikipedia or StackOverflow, (3) forbidding collaboration, and (4) forbidding the use of libraries
There is no mention of "working on a pre-existing codebase that they know nothing about" in the description of the HackerRank test... so I don't know how your point applies?
Yet by forbidding the use of external research and libraries they remove the two main tools I would want some to use "in an environment and context where you don't have the advantage of being an expert ahead of time"
The problems should be chosen such that external research and libraries are not needed. For our phone screens, we don't even require the code to compile or successfully run. For instance, we explicitly tell candidates to just make something up that sounds reasonable if they need a standard library function that they know exists but they can't remember its exact name or type signature.
We've never used HackerRank, so I don't really know how customizable it is. From the comments here, it sounds like it's designed to be fully automated with no participation from any developers at the hiring company. I don't like that at all. When I wrote my original comment, I'll admit I was thinking of it as a more advanced Google doc for programming, not as a fully automated platform. That's my bad, and I should have done my research a bit more.
Seems like a nice way to hire carpenters, not programmers.
I would be a 'no' if i were interviewing me. You obviously can program but this makes you appear to be someone who would be difficult to work with.
If i had a start-up, i would definitely give this person a good old try, because i can tell that he/she is capable enough to churn out rather advanced projects with complexity higher than just CRUD. Programmers of this type is what i'd call 10x, and one should never dismiss a 10x!
I'm not doubting this persons ability - I'm only responding my opinion of this person based solely on this email.
I have never been in a startup that fears arguments. Every startup I have been a part of has lively debates and arguments almost every other day. It's only the large slow moving corporate giants where I see such lack of debate and arguments on what is obviously wrong.
I would go to the extent of saying that a startup that does not encourage arguments in a harmonious fashion would die very soon anyway. Debates and arguments help in weeding out stupid ideas and focus on what that really matters.
This person's email shows that he can have a qualitative argument in a coherent, polite, and non-confrontational fashion - exactly the kind of people you need in startups!
I wish I had more teammates who could write as effectively.
You hire people to solve problems, not churn out code. Code is only a tool to solve a problem.
If they're too cool to waste a single second conforming to a basic FizzBuzz test to assert that their resume isn't a lie, they're probably way too cool to do anything but write the most glamorous code in the most visible part of the product - which is the last thing, a startup - with too much work and not enough people, needs.
I'd be willing to waste 5 minutes tops, unless the employer has put some skin in the game (fizzbuzz is ok - nothing much more than that tho).
There's a 1,000 other employers out there who might be a better a fit. I am not going to do a 1 hour, 30 minute or even 15 minute task if they can't at least even be bothered to pick up the phone to talk to me or glance at my github profile.
Companies that expect completion of a weekend-filling exercise before granting you an interview are universally run by entitled assholes. You're actually doing yourself a favor by screening them out: they'll be bad to work for, you won't get to work with other 10x engineers and the company will likely achieve nothing impressive anyway.
Why are you so quick to extrapolate an entirely new character based on this person not wanting to use HackerRank?
In this case, it definitively shows a bent for the innovative and smarts, but shows lack of judgement / wisdom.
For a 10x, merely completing the test is a lot faster and more effective than trying to go change the process from the outside.
However if you want to hire people to just complete tickets as fast as possible, maybe that's a valid reason to reject the candidate.
Not necessarily hiring to complete tickets as fast as possible, but some who can take a task and complete with minimal issues. I don't want to be stuck in meetings or arguing in PRs etc.
I don't know about you, but I would not want to hire someone who can take any task and complete with minimal issues. Where I work, one is encouraged to argue about what is not right in the meetings and offer better solutions.
This candidate is doing exactly that: Argue why a certain hiring methodology is not effective and what a better alternative is. Considering that this candidate does not just follow orders but challenges the status quo and the fact that he has volunteering-based projects to show makes this author very likely a good fit for my organization.
Let me give an example as I am not the best at articulating. hopefully this helps.
Lets say I hired this engineer as Senior or Team Lead. Now I want the base docker image we use for node bumped a major version. I checked the changelog for the nodes releases and knowing our codebase I think its safe.
I could ask a Junior dev to do it, but I knowing that they are lacking experience this may seem like a "big deal" when really its not.
What I want is the node version updated, validation unit tests pass, regressions tests are good. And it to be released. If there is a failure along the way, address it or sure lets chat about it.
But this Email in response to hackerrank - would make me perceive this to be someone who would respond with a complete change to our CI/CD processes, to our infrastructure, maybe to even using Node - as this sort of task is beneath him.
Sure there would be areas this person might excel at, but some days little tasks just need to get done to keep the ball moving.
This makes me think that you're a poor judge of character and of a slightly authoritarian mindset.
This email is one of many protesting an industry interview culture that prioritizes badly thought through exercises that bear little relationship to the job being interviewed for.
>What I want is the node version updated
And do you really think that seeing candidates reverse a binary tree without protest will tell you how well they can perform at this kind of role?
Looks like it is a difference in culture that I am used to and the one that you are used to.
At my workplace, it is perfectly acceptable for someone to suggest a complete change to our CI/CD process. In fact, we have changed our complete CI/CD process twice (SVN/build scripts -> Mercurial/Jenkins -> Git/Travis-CI) already with minimal loss in productivity because someone questioned the existing CI/CD process and suggested a well thought plan to switch to a new one.
But I get your point that sometimes it may not be feasible to carry our such a drastic change in process, infrastructure, etc. But suggesting such a change is going to be acceptable and we refusing to accept such a suggestion is also going to be perfectly acceptable and both this person and us working in harmony even after this disagreement is also going to be acceptable.
> I don't know about you, but I would not want to hire someone who can take any task and complete with minimal issues.
Sorry, I don't want to work with a bunch of pedants. You can have them.
No more extreme than suggesting that someone who raises thoughtful questions on a broken hiring process must certainly be a bad fit for an organization.
> Sorry, I don't want to work with a bunch of pedants.
Now, this is taking it to an extreme!
It's extremely hypocritical to criticize someone for the very thing you are doing (assuming the other person doesn't know how to do their job). Couple this with the fact that they are not asking for any advice on their hiring process, it's a pretty rude thing to do.
A little bit of fluff added to the wording doesn't make it suddenly polite.
> I would not want to hire someone who can take any task and complete with minimal issues.
Someone who can't do straightforward tasks without having an issue is incompetent, pedantic, or both.
I am quite lucky to have worked in companies where the peers and management encourage debates and arguments and do not take it as a sign of incompetence.
I had no idea there were companies that would take perfectly reasonable questions on a broken process as a sign of incompetence. Thank you for enlightening me. I now know to be careful enough to avoid such organizations in future.
I never said raising issues is bad. Where I work, we highly encourage people to bring up issues as they see them.
However, when you bring something up as an issue, it usually helps to suggest a solution (which this original GitHub post fails to do) and we don't generally try to take unsolicited advice from people who aren't even part of the company yet.
Maybe at a consultancy and only if you're far downstream of dealing with clients.
That's not normal, nor should it be.
In the same spirit you could definitely see it as unreasonable for a candidate to suggest you adapt your screening process because they know better (even if it's said in a polite, validated way).
To be clear, I wouldn't rule out someone for this, but I can sympathize with where I believe the above poster is coming from.
10/10 !
Low-investment on the part of the employer. They still expect me to spend 90 minutes on proving I have seen a REPL before, which is time I, frankly, don't have. I'm happy to answer/talk about things that relate to my job, but working on puzzles that just happen to be solved more easily by programming has exactly nothing to do with it.
> the candidate is asking for a completely custom treatment
What's next? Having to actually look at someone's CV? That's insanity.
We actually take great care in examining resumes and CVs before proceeding with a coding screen. We've had plenty of senior developers fail the most basic questions (think FizzBuzz), which is why we conduct these screens.
Even phone screens are better than "Here's a HackerRank link because I don't want to spend time talking to you, enjoy the next hour-and-a-half solving riddles".
Maybe the whole point of the test is not how well you do, but how you react to being asked to do something you feel is beneath you...
I didn't say I'm too busy to apply, I said I'm too busy to spend 90 minutes on useless tests.
> but how you react to being asked to do something you feel is beneath you...
You know what a great test for that would be? Ask the applicant to wash your car.
These tests aren't useless. Tons of candidates have never seen a REPL before and are totally unable to solve even a trivial coding assignment.
I suppose your company is too clever to waste their time on such useless tests? Who at your firm wastes hours interviewing candidates who have no ability to code?
Going through someone's Github (or any other project they feel is worthy of sharing) and asking them questions about why they made the decisions they made has been orders of magnitude more illuminating than asking them to come up with an algorithm for solving the subset sum problem without Googling.
It's still easy to spot the liars — e.g. I've interviewed people who worked at the NSA and even they could talk about the skills they used, just not which projects or data — and the process of deciding which things to talk about is a pretty good way to explore their communications style, too.
> "Difficult to work with" is perhaps too harsh a statement
That's exactly what the OP meant to say, and verbatim what they would have said in an interview debrief. The interviewee wanted some amount of compromise, and all of a sudden they're "difficult to work with". Now everyone else in the room is framing this potential hire as an asshole. There's no coming back from that. I've seen this happen many times. One term of phrase like that and instantly a qualified candidate is out because someone latched onto a single fault and made wild extrapolations about it.
> just a low-investment screen
You have no idea how much of an investment it is. I've had hacker rank problems that I was expected to spend 3 hours on. That's a pretty big investment just to get my foot in the door. Sometimes (read: often) the juice just isn't worth the squeeze. The employer wants me to give it my best when they're not even willing to come up with their own questions.
> uniform across all candidates
I see this a lot as the panacea of interviewing. Sounds good to have everyone on a level playing field. But if you start out with a crappy process, applying it to everyone equally isn't going to get you good talent. As an interviewee, I'll still be bitter about the bullshit you put me through, even if everyone else had to do it.
While it's really just about to obey, and follow command.
People have to understand that they have to fit the soulless masses and have to be tested accordingly...
While I can understand your leap to soulless masses - that was not my intention.
p.s. Even at the best companies there is some truth in what you say, but it varies a lot.
Thankfully, as a human being, you are not your ability to code. More importantly though, then it also means that people who can't code are worth just as much as you as human beings (more, if they've managed to learn social graces). If you don't hold it to be true, then code or GTFO.
Look for places like the Recurse center in NY that can help you find yourself in the context of being able to code, or more traditional non-traditional approaches like backpacking though India, or taking LSD in the Haight in the 60's (anyone got a time machine?).
If you'd like friends (who will be interested in your personality), go find some. Outside of work. Bonus points if you manage to find some that can't code.
Hint: companies are interested in your personality - if you come across as this caustic in a phone screen or in person interview, I'd be surprised if you get invited back. (Or at least they should be; Google's current HR woes are their own creation.)
For me, this just means, that he is not accepting a solution to the problem, explaining why he thinks it is not a good solution and offering another one, which would work for him. Also, he is not dismissing the hackerrank test, but asking to evaluate his skills on a different way too.
As far as I see, this is probably the best way to argue with somebody, that their chosen solution to the problem is not the ideal based on your knowledge and experience.
I would also worry hiring a team lead/senior dev who appears to be combative from the initial screening
This kind of approach is fine for a junior. I'd even encourage it because there's an attempt to change the parameters of the problem which is something we often have to teach people as they progress.
For a senior position, not so much. I mean, it might be that they're ignorant or stupid, in which case you've probably dodged a bullet when they don't hire you. Or it might be something else entirely.
A more sensible approach, in my view, would be to ask what they were looking for with the HackerRank test in a subsequent face to face. If they say that they don't have a better way to determine developer competency then, sure, suggest that you may be able to help with that when you join.
If it were me interviewing, I'd be particularly interested in suggestions that a) were developed from successful prior hiring practices and/or b) not so bleeding obvious as "look at their Github page".
If I came across this in the wild, I'd reevaluate the parts of the interview I control to see if maybe I could make it less robotic and I'd probably still bring them in to make sure I'm not missing a good dev, but I would be fighting my bias at least a little. There is a small handful of people I've worked with before that would appreciate this approach and their toxic attitudes would prevent me from wanting to work with them again.
The interview process can suck, but this is not how I'd recommend standing out from the herd.
You'll never work on interesting, important work until you embrace a worldview that discards bureaucracy.
If you want creative solutions to interesting problems, you need to sit up and listen when somebody takes the time to write a thoughtful reply like the OP did.
If you want another drone hammering out application code and working overtime out of fear, just keep ignoring folks like the OP. You'll be out of work soon enough, anyway.
Not the OP but, absolutely I want a personalised interview! I want the company I'm working for to care about the people they hire -- not to efficiently fill empty seats. Yes, normally that means I tend to work for startups. I'm happy with that.
It's fair to say that you want to be able to evaluate potential employees cheaply before you invest a full interview. It's also fair for people to offer ways to do that evaluation rather than running through someone's maze. Neither side needs to accept the other's offer, but there's no need for either side to take it badly.
A "no" is quite a good result if the company would otherwise be wasting the candidate's time.
Our applicant tracking systems won't be upset if you ghost them/us. Your application will simply expire after a while.
Recruiters acting in a professional capacity or companies, both of whom would ghost you without a second thought? I gotta say I don’t really see the problem.
If any of the candidates I've interviewed and hired had this sort of independent and outside-the-box thinking, I'd have doubled their salaries when I hired them.
Do you have the power to double salaries of people in your org?
If the implication is false, it would be an exciting data point!
HN being what it is, here is quite a non-zero chance to meet a person with real hiring power who really could have made an offer to the person in question.
Seems to me like an org that uses a recruiter isn't looking for "outside the box" employees. Obviously they aren't sourcing candidates with outside the box processes.
If I were the prospective employer I'd probably write you back that before we will invest into looking at your production we kindly ask you once again to jump over the low bar that was set for all applicants. Then again, if I were your prospective employer I'd never have used hackerrank in the first place because I feel that to expose a potential recruit to a third party service would be a breach of confidentiality and besides I feel that such services are - as you correctly identify - ill suited to picking the people I'd want to work with.
It's akin to a luxury fizz-buzz test.
I have taken a number of HackerRank screens myself, and I have never seen one that either (a) tests beyond the coding level that would be expected of a fresh CS graduate or (b) is not vastly exceeded in scope and complexity by the coding challenges given during the onsite, which do allow considerably more flexibility and relax some of the artificial constraints.
Why attempt to circumvent a test that is meant as a slightly less trivial FizzBuzz?
I've been a part of two great alternatives: a pair programming session with the lead dev and adding some features/refactoring a sample project.
I'd be curious if anyone here is responsible for hiring devs and finds hackerrank type tests useful.
They serve as a relatively simple early-stage screen for applications from people we've never met. Ours costs each candidate 1-2 hours. But we do not require cover letters, which in the good old days might have taken about half that time, and been thrown in the bin.
Some may think no CS graduate would fail a test that let you choose any popular language to implement some basic string parsing. But in practice about half the candidates fail this stage of the hiring process, which saves us quite a lot of time. Yes, it costs each candidate an hour or so, but that's a feature, similar to the oft-proposed idea that sending email could cost one cent to reduce spam.
>Some may think no CS graduate would fail a test that let you choose any popular language to implement some basic string parsing.
I don't see anything wrong with basic screeners like that, but I have experienced some really silly stuff. Recently I was given a test that asked ~10 questions (some trivia, some paragraph type response), a few small simple questions (reverse a string, etc.), create a class to handle card games (poker, blackjack, etc.), and create a user repository... in 30 minutes. I felt like a dog at a dog show.
Some tests will seem impossible to complete in the alotted time. Often that's intentional. It saves time for the candidates and gives a better spread of scores (very few will get 100% in some test batteries). But it can be disheartening. For these initial online tests I try to give enough time that most people won't really run out of time unless they get stuck.
Keep in mind that these quizzes are only one single part of a multi-part interview. Also keep in mind that acting offended by whatever style of interview you get may reduce your chances of getting the job you want.
You might be amazed how different answers can be on easy code puzzles, or how deep of a discussion you can have over a single line of code. The easy questions might be easy for you because you're good, but often there is a low bar for the first round interviews for a specific reason: to weed out the people who have less experience than they claim and/or couldn't be bothered to prepare for the interview.
Also, when several or many candidates are being interviewed, it takes a lot of time just to administer low-preparation interviews. Pair programming, as nice as it is, simply can't be done by the lead dev for all the candidates without keeping him from his job coding.
Remember, the main thing your interviewers are trying to do is compare candidates against each other, so they need standard a way to see who's better than someone else. Hackerrank type questions are definitely not ideal, but it does what it says: rank people against each other.
I would absolutely welcome ideas for being able to rank people in programming skill with some method that is closer to pair programming but takes less of my team's time. The suggestions in the article here are lovely, but they don't help someone who's interviewing because they take too long to evaluate, and they're different than anyone else so they're much harder to rank candidates.
That's the problem with HackerRank: You can't! Every single time I've tried one, it was a dismissive "do this on your own time and we'll check your answers".
Not to mention that their question sets tend to be full of puzzles, which are the type of thing where I'll have an epiphany over lunch, rather than something I'll figure out how to optimize in the ten minutes I have to code the solution.
Agreed, this is why I give my own coding quizzes, so I can have a discussion about it. I'm more interested in the thinking than the answer.
But, I do have sections in my interview that test knowledge and not skill, so I can still see the usefulness of letting Hackerrank be a part of the process.
The one thing I don't claim is that HackerRank or coding quizzes are perfect. This is why coding quizzes are only one of maybe six phases of an interview.
Still I wish employers would better understand the limitations of automated coding tests. Pair exercises where I can use my own environment and think out loud with an interviewer aren't so bad. Fully automated stuff like HackerRank often make simple things overly complicated because they expect answers to be written a certain way. I think those sorts of tests are only suitable for really low level screening - ensuring a sysadmin can use basic bash for example.
I see the appeal of knowing this but I think I'd take a submission from the OP as-is in place of a "coding test."
My thinking here is that I can't recall an instance where I needed to write code at a job with a timer ticking down and someone reviewing my work as I went. I usually have the luxury of doing some research and taking a few attempts at a problem before I understand it and write a decent solution.
I'm not sure what we expect from candidates when we force them into these situations. Am I supposed to be impressed by their solution? I can't think of how I would be. The code I'm most proud of writing took me several attempts to write. Often over a long period of time. Am I supposed to gain some insight into the way they think about problems? I already know how most people tend to solve problems. It's a well understood area of research. What else is left?
All I expect candidates to prove is that they've practiced a problem set and can recall a large number of solutions to trivial problems. Useful but it doesn't give me an indication about how they'll perform. Three months into the job and they'll probably forget 60% of the problem sets they practiced anyway.
Do I want to hire programmers who have an intuition of complexity and know when to use a binary tree or a linked list? Definitely! But I'd rather talk to them about real experiences they've had when they had to make such choices and find out why they made the trade-offs they did. It's hard to do that with trivial problems.
For other development jobs I generally agree with you. The coding screen will not tell you much. Particularly for a mid-level or senior role. In those cases I am way more interested in their portfolio and in having a long casual technical discussion.
When it was over I asked the interviewer if there was ever a time when he had to implement such an algorithm on the job during a production outage event and his answer: No.
In my experience working within devops teams maintaining and developing public cloud infrastructure I don't think I've ever had the pleasure either.
In retrospect I don't think it was a bad experience. I think there are roles which exist in software that do require a higher level of rigor than others. I'm often amazed how easily many developers will dismiss performance concerns (premature optimization!) for example. I would expect a hiring process to be upfront and honest about such requirements and candidates should be aware of their own skills and background before applying.
But most software development jobs at ABC Corp are not the SRE Team at Google and they hire as if they were.
I think that's the risk we take with standardizing and automating hiring processes.
update: just markup.
Our profession is somewhat bifurcated. There are the developers who only ever do glue code between systems and never progress beyond java 1.4 and work places where that is a valued trait.
This candidate however is in the other camp. He's creative, and self driven in his learning. He's also driven to get better. He won't be satisfied at the kind of place that doesn't look at him as a unique and creative developer.
This was a negotiation not letting an applicant dictate the terms of the evaluation.
This is really important. For any company that does business with the federal government (even if it's only a small part of the company), they're required to keep records to prove that they don't discriminate in their hiring practices. The way almost every company does this is ensure that their practices are standardized and no candidate has any sort of different experience.
If they let this candidate have a non-standard interview, then hire them over someone who is in a protected class, they'd be opening up a TON of liability.
Several thousands of students solve these questions on online judges. These are some of the easiest questions to Google and get answers for.
https://austingwalters.com/you-are-given-a-deck-containing-n...
However, HackerRank is just a screen on:
1. Are you going to be difficult
2. Do you have basic coding skills
Typically, I'd interview at least 10 people before I'd give an offer. Once we added improved screening we got that number down to 5 people before an offer (note screening wasn't HackerRank).
I think it's reasonable to screen and HackerRank is just that, it's not about complexity.
HackerRank test can be as standard or as non-standard, and as easy or as difficult as the individual employer wishes it to be.
The above indeed does not make sense, unless you're hiring a solve-puzzles-as-sports person.
I don't think it's enforced by HackerRank, though. It must be the employer's requirement. If so, their hiring process does have problems.
However unless they really like your profile they will immediately next you after that kind of response because companies also don't have time for this nonsense. They just want a standardised tests for all candidates so they can rank them and then hire the best.
Even a short phone screen where I just ask someone to code a simple question takes 20-30 minutes of my time (plus however much time I need to get back in the zone), so HackerRank is appealing if only to weed out the very worst candidates. I'm not familiar with HackerRank specifically, but I imagine you have some choice as to how to set it up. If I could set it up to give candidates plenty of time and ask relatively straightforward questions to weed out people who don't have the basics down, it would be a huge time saver for me.
I suppose you could make the argument we do have to reverse arrays, but strings? Give me a break, only idiot programmers spend their time practicing for useless programming interview questions.
Is reversing a string something I do in the real world? Very very rarely if ever. But it's not meant to be a question that simulates a real world coding problem. The point is that it's a very simple problem that anyone proficient in almost any coding language should be able to do. And I don't know anyone I've worked with who wouldn't be able to do this in 5 minutes or less, with or without practice.
Reversing a string takes 2 minutes or less even if all you know is how to work with strings and how to write a for-loop.
One should be able to devise a solution to a simple problem like this without any CS course at all.
or code units/code points/grapheme clusters/emojis. Thanks to hard work of many developers string handling becomes easier over time, but I don't think it's trivial if you don't exactly specify what you mean by "string" and "character".
The human touch.
But you took 20-30 Minutes of their time too, the only difference is that you get a compensation at the end of theses 20-30 min, they don't. If someone told me, "OK , i m gonna waste 3 hours of your time in exchange of a mere promise of a job", i will simply decline the job.I work 9hr/day , I have better things to do with my free time...
Yeah, with often very high ratios (I've seen above 100:1 in positions where I had information more than once recently) applicants for open positions, hiring simply isn't going to work if it requires symmetric time investment from hiring managers and applicants.
I almost got the job, they randomly canceled the on-site at the last minute. Needless to say, I think my effort at least got me to that final step.
For example, I haven't had to write my own algorithm to parse a b-tree or implement binary search since I left school. I could explain how these algos work, but to actually implement it perfectly in python or java under timed conditions with no outside docs, I would most certainly fail and the company would miss out on a pretty good generalist.