I think many HR people will just ignore you if you e-mail what OP posted. Once, I wrote a blogpost why programmers don't get jobs due to random factors ("Why software engineers don’t get jobs: Four horror stories" https://goo.gl/v4PUWV), but being patronising and "explaining programming to HR" is one of the things where you just shoot yourself in the foot by being too demanding too early in the process. You can be demanding ONLY AFTER they told you that they want to hire you, but not before.
A tip for e-mailing HR and business e-mails in general: Try to never signal that you will be hard to work with. Always be kind and even a little bit submissive.
Don't try to teach people something, don't quote authors and don't do footnotes. Imagine the person will take a maximum of 3 seconds per paragraph and 10 seconds in total to read your e-mail. There is a chance the reader is listening to an audiobook or is watching Youtube while answering e-mails in a cubicle. If you need to discuss something critical, invite the person for a phone call. Salary, negotiating or deviating from a standard process (like here) should be discussed in person/in a call.
Hope that helps to get some insight from "the other side".
I think your approach would work if there was a shortage of jobs; there is exactly opposite situation right now and HR should adapt or they would end up with a very narrow dissection of what is available. You are often asking accomplished individuals to waste their time on badly compensated job proposals, just because it makes your life easier. No wonder so many programmers think recruiters in this industry are a joke and try to actively avoid them.
I agree totally with what you said, but you're confusing macro- and micro-economics here. On a macro-level it is true, HR people should be treating programmers like gods at all times, but on a micro-level, the HR person sitting in the cubicle doesn't care about one programmer more or less.
There might be ten other CVs of "okay'ish" engineers in HR's inbox and your interview will end by never hearing back the firm. Or if, despite being cocky, you get an offer there might be a note somewhere next to your CV on the CEO's desk saying "easy-to-work-with level: Only 50% score" which leads to 10k less for you in salary. As an applicant, you want to "manipulate" the employer to give you the best possible offer and why shouldn't you be friendly and a bit submissive to achieve your goal?
There's a distinction to be made here about the level of the position being discussed and the particular skillset. What you're saying makes more sense on the junior to mid-level dev positions or for more common skillsets. However, this is the Hacker News audience and you're clearly replying to someone who has already narrowed it down to senior dev positions. Given that context, I'm going to have to disagree with your assessment. If you're hiring for the best, then it's up to HR to respect their time. Otherwise you are just perpetuating the belief that recruiters add no value to either side of the equation.
I see that you're receiving a bit of flak (which, given the audience, isn't unsurprising). But I wanted to let you know that I found this comment pretty insightful.
Happy to help. When I was a full-time programmer I also thought writing ten paragraph e-mails with footnotes is smart but turns out it isn't (I learned this the hard way).
> I think your approach would work if there was a shortage of jobs
There is always a shortage of good jobs. You can fight the process all you want, if any job at all will do, and you don't care how long it takes to get it.
> You are often asking accomplished individuals to waste their time on badly compensated job proposals
What do you mean by badly compensated?
Why would you assume someone else knows anything about your accomplishment and credentials and trusts the skills you list on your resume before you've demonstrated anything?
Also, if you're good, then why does a low bar for entry scare or offend you? A screen for basic aptitude is narrowing the field and removing people from competition who can talk well but don't have programming experience. That seems like an advantage for anyone who can pass the easy tests.
Alright, imagine you worked for top engineering company, have github full of bleeding edge stuff anyone can observe, wrote books, have patents under your belt, do public speaking, teaching at universities etc. and some HR person comes in and wants you to do trivial HackerRank stuff. She basically interrupted you from working on something benefiting humanity just because she was lazy to check your CV and ignorant of the industry. Then you see the same company awarding their good jobs to friends of higher ups and all they have left are generic jobs they need to fill that would end up with all the work, complaining "where have all the good programmers gone?". And then you read on HN post like this and wonder why there is so much resistance to acknowledge one's qualification from what they provided in their CV. Imagine the same doing in other areas of industry - we don't care you won these multi-million law cases in the past, all we care is how the history of US North-East affected common law between years 1870-1893.
FWIW, I have a patent and do public speaking, recently sold a startup, and I gladly take the coding quizzes for all my interviews.
They are fun, and they give me a chance to shine. The coding quizzes actually saved me once when I did really badly in another part of the interview. That company hired me, and gave me what others there thought was the good job.
I also administer coding quizzes to people I hire, and I find them a small but useful part of the larger interview process. I'm giving an assembly language coding quiz to someone later today.
> She basically interrupted you from working on something benefiting humanity
That seems a little hyperbolic. Do you want the job? You have to spend time interviewing. Simple as that. Don't do the quizzes if you don't want the job.
> Then you see the same company awarding their good jobs to friends of higher ups
Most companies try to promote from within, and many people think that's a good thing. The alternative is you hire unknowns from outside the company over people who've been there putting in the time and know the system.
> just because she was lazy to check your CV and ignorant of the industry
It's both presumptuous and pessimistic, and also likely wrong, to assume that a coding quiz implies any laziness on anyone's part.
> Imagine the same doing in other areas of industry
Other jobs have it much worse, you have to get bureaucratic certifications for a lot of jobs that are a lot less fun than Hackerrank, and take months and months. Or you could be a lawyer or doctor, and you have to raise money and bring in clients in order to get the good jobs.
What jobs are you thinking of that have it so much better than programmers?
It was about accomplished people getting the same treatment as newbies or wannabes that have no clue what they are doing. You don't see it in other industries. E.g. I wrote this new language/library everybody uses, but I am forced to solve some crappy puzzles I probably was solving when I was 14 and match the current mood/skills/tunnel vision of the interviewer. As a consequence, I rather start my own company and charge you much more for the same service you'd get if you employed me with a bit of a good will on your part, or by simply reading my CV and clicking on the links there.
If their hiring process involves jumping through hoops before being granted permission to interview and if the tasks assigned to you bear almost no relationship to the job at hand, the chances of the job actually being good are low.
Employers that do this kind of thing typically have an entitlement complex and not the smartest. People with an entitlement complex who are not very clever are bad to work for.
>Why would you assume someone else knows anything about your accomplishment and credentials and trusts the skills you list on your resume before you've demonstrated anything?
In my case because I have a bunch of open source available that they can just read.
If a company expects me to complete a 1 hour badly thought through exercise that is at best barely related to the job before they grant me permission to talk to them, just exactly how well do you think they'll treat me once I'm actually hired?
I'd love to hear examples of how to do it right, without taking all my time. I'm genuinely interested in how to hire people without wasting their time or mine. I'd love to screen people with a day of pair programming or a 2 week paid internship, or whatever other good ideas are floating around. I can't.
You have just dismissed most tech companies. All the large ones (Google, Apple, Amazon, Microsoft, etc.) give coding puzzles as part of their interview process.
If you don't want to work for one of those companies, that's absolutely your choice, but you'd be wrong to say they have an entitlement complex or aren't the smartest.
> In my case because I have a bunch of open source available that they can just read.
I do read people's OS projects, but I simply can't do that for every candidate before I screen them, I don't have enough time. If the coding tests are easy, and you want me to see your open source project, then just ace the coding test and move on.
If you don't want the job, then don't do the coding test. It is your choice.
In the past I've given programming tasks that mimic real life work as closely as possible and fit them into a reasonable time frame - for example, 1 hour of pairing/programming during an arranged face to face interview. If the test is well designed, touches on a number of areas and self contained, I think this was sufficient for me to assess their skills.
"Mimic real life" means no puzzles (unless I've literally experienced them in real life), no binary tree reversals and no big O notation questions.
>You have just dismissed most tech companies. All the large ones (Google, Apple, Amazon, Microsoft, etc.) give coding puzzles as part of their interview process.
I think that type of thinking leads to embarrassments like this:
I think he experienced exactly the same problem the OP is talking about and in this case it's not him who was dumb, it was Google.
I wouldn't rule out any of those companies but I think I'd rule out joining through the standard interview process - I'd look for specific people who looked to be doing exciting work on specific teams and try to befriend them.
>you'd be wrong to say they have an entitlement complex or aren't the smartest.
I think it would depend upon the team. I think they're not all geniuses, and they do have a tendency to drink their own kool aid. For sure some teams are great though.
> All the large ones (Google, Apple, Amazon, Microsoft, etc.) give coding puzzles as part of their interview process.
They are considered the best and give above average compensation. Is your company considered the best, properly paying top talent, to employ the same schema? Those tests were done to distill the top end performers with the accepted risk of huge number of false negatives. Now every mom-and-dad shop is trying to use it. That's why I call it insanity, getting extreme practices into mainstream in our industry.
> Also, if you're good, then why does a low bar for entry scare or offend you?
It's not a matter of fear or offense. It's a matter of judiciously investing my time on the right opportunities.
I get about 3 to 4 calls from recruiters everyday. If I agree to go through this kind of interviewing process every day (even if the bar is low), I would be spending more than 20 hours every week just doing HackerRank tests. This is not feasible for me. Therefore just like the recruiters need a way to filter candidates out, I need a way to filter recruiters out.
Requesting a HackerRank test is just one of the many filters I use.
> It's a matter of judiciously investing my time on the right opportunities. I get about 3 to 4 calls from recruiters everyday.
I agree completely, I was under the assumption that this entire conversation is about what happens after you (the candidate) submit an initial job application, or respond to a recruiter about a job you're actually interested in.
I'd never do Hackerrank tests in response to recruiter spam.
That's been my observation. Tons of openings, but many companies lean toward denials, under the assumption that firing the wrong person is more costly than not hiring the right person. It also seems that many companies are looking for ready-to-go engineers, rather than being willing (or able) to build talent in-house. The only door open to many junior devs is the internship-to-hire funnel.
>>Tons of openings, but many companies lean toward denials, under the assumption that firing the wrong person is more costly than not hiring the right person.
This might be their claim, but they almost always end up hiring wrong people and firing them.
Its really simple, making hiring decisions based on an interview is really like deciding to go into a long term relationship with a person based on the make up they put up during a date.
If you are choosing on these qualities alone, then the prettiest person would get selected. This says nothing about the person at all, or worse, bad people are likely to put up more make up to hide other obvious flaws.
> ...assumption that firing the wrong person is more costly than not hiring the right person.
I take it you've never had to hire or fire anyone. At mid-sized and large companies, it's a cumbersome process and, unless they're complete sociopaths, firing is also unpleasant for the firing manager and the team. It also means taking on the work and cost of doing a new candidate search and another new hire ramp-up.
If easy-hire/easy-fire worked, everybody would be doing it.
Oh, the assumption is definitely warranted in many/most situations. Though there are often alternatives (such as contract-to-hire) to mitigate the risks.
Regardless of how the job market is currently, I see it as having a set amount of 'difficulty capital' that can be spent. The fewer openings, the less of this resource you have, but otherwise everything works the same.
Given there is a limited supply, regardless of size, one should try to spend it optimally. That means being difficult when it comes to pay and benefits, and spending some of this capital when trying to determine the work/life balance. Using it to be insulting or patronizing is effectively wasting it with no return.
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.
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.
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.
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.
> 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.
> 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.
...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.
"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.
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.
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".
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.
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).
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.
> 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.
>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?
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.
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.
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.
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'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.
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!
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!
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.
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.
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 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".
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 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.
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.
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.
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.
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.
> 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.
Many recruitment agencies won't even talk to you until you pass some FizzBuzz test on HackerRank or similar. Even Facebook strongly suggest you to take their own training based off similar platform and Google does something similar. So it seems that even entry level jobs these days require Googlesque excellence just to get your foot in the door. It's similar to law firms requiring you to take parts of bar exam during your interview or physicians to perform autopsy during interview. Even worse situation is with Machine Learning now, where you are expected to answer PhD exam-style questions for entry level data augmentation jobs. Unless you are from Top 10 school your credentials don't matter at all. It's IMO complete insanity and I am throwing such companies out of the door instantly unless they offer $500k+/year. Then we can talk that way.
FizzBuzz is a bit of understatement, most of those tests are alike once you practice a bit and sink into trivial category; some companies actually give you way more difficult questions than what you get at Google/FB etc. and after you pass that terror then present you with an offer where you don't know if you have to laugh or cry. I haven't seen a single company doing that outside top 5 to compensate you properly for it. Everybody wants the best, everybody thinks they are the next Google (well, they are far from it), and everybody thinks coders are stupid and don't value their craft (which they don't it seems).
Indian IT services and consulting firms long realized these problems. Its just not possible to expect to hire the best and expect them to work for McDonalds burgers. So they state honestly what they want and what they can pay.
At the same to be cognizant of your business, profit margins and by that definition what you can pay and remain profitable is a good thing. Not every shop has to be a world changing venture, and if you can pay low and hire people good enough to run your business is just perfectly Ok.
> I haven't seen a single company doing that outside top 5 to compensate you properly for it.
There are small financial firms which will conduct significantly harder interviews than Facebook/Google. The offers are also commensurately higher (significantly so).
And that's totally fine. If they offer you 500k or work on space ships/self driving car core then I am willing to go through a grueling interview process. If all they offer is 50-80k and a vision of making founders rich, they can go literally stuff themselves.
Nope, it's not moving from there. HackerRank is now the step 0 before the whiteboard interviews even start. At best it removes the technical phone interview.
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.
> 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.
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 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.
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.
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.
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.
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.
It seems to me that this is a well-written, polite, non-confrontational counter-proposal.
My opinion is that the company may have two responses that are both valid and legitimate: i) "Sure, go on, nice idea!" or ii) "No, sorry, please follow our established hiring practices".
Now, if the company takes that as arrogance and that email only is reason to eliminate the candidate, the email still actually worked as a great way for the candidate to eliminate the company. If a company punishes a polite, thoughtful disagreement from a candidate, it must be a horrible place to work for.
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.
Not being a programmer, nor a recruiter for IT jobs, but having some experience in recruiting in my professional field, it doesn't look to me like such a great letter/proposal.
Mind you, this might also depend on the specifics of the ad/request Mr. Fasiha was responding to.
I mean this same letter if received from a senior developer would be received very differently than if coming from a first time or junior developer.
What strikes me as negative, is - beyond the unneeded citation - is the sneaky/flattering tone (IMHO) or - maybe - failed attempt at humour in this sentence:
>I'd never heard of HackerRank, but after you wrote two other employers sent me their own HackerRank tests. Having worked on those tests first (I considered them practice, for the real thing with ABC :)
Then right after having confessed an almost total ignorance on the test, and only two previous experiences with it, the Author goes on at length enumerating in detail why and how the tests are "wrong".
I would have more liked a sentence to the effect of either "after having gone through these tests n times I find them inaccurate" or "never heard about these tests, not being familiar with them I fear they might not reflect entirely my potentiality".
Pontificating on something you just stated not being fully familiar with doesn't sound that good to me.
When looking for a new job I typically run a few applications at a time since companies are so unreliable and, frankly, I don't have the time or inclination for
* 5 x 45 minute phone screens
* 5 x 2-3 hour coding test (some of which will be the same)
* 5 x 3 hour face-to-face interview
Over the course of 2 weeks while attending my current job. Companies should consider this when trying to hire "exceptional" candidates who value their own time.
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.
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.
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.
I wonder what happened to human discernment. It’s like people think liars get away without detection. The only reason a person who bullshits an interview gets hired is because the interview was a formality to begin with; eg. Friend of management who the whole interview board knew was BSing but also value their paycheck too much to object. Yea, we don’t want that situation, and clamping down on nepotism etc. at the candidate level is just wrong. “Boo hoo, too many candidates, lets engineer a rube goldberg machine to make us feel objective.” Just treat candidates as people...
I can’t imagine hiring to scale product development inside such a dirty room. The most successful businesses I know of simply don’t complain about these things, nor have personnel problems; people do the work that needs to get done with a good attitude etc, with little awareness of title... acting more like “mom and pop” businesses who value relationships.
How is any company building an awesome thing with an awesome team, with word of mouth not bringing a torrent of personal references from the rank and file? The good ones have that going on in my experience, there is just a glut of shit rung employers (and candidates) here shaping our views toward defensiveness.
> Would ABC be willing to work with me to define a better way...
"Better"
Open source contributions carry a set of particular demographic biases to a hiring process. They skew things towards comparatively well-resourced white men.
There's certainly an argument to say that open source contribution is an indicator of ability, but there are other ways to assess ability which don't introduce such a heavy skew.
This tells me that author was never involved in recruiting people. He may be smart (even exceptionally so) but that can only be validated through a direct interview. However since a lot of people (and I mean A LOT) cheat in their CV and even GitHub portfolios, getting upset over "show us that you can do anything" minimal bar test is something I'd rather not get in my mailbox. It's polite and well worded, that's true, but shows that he doesn't understand the realities recruiters are facing. I'd respond to his mail explaining why these tests are mandatory but inevitably I'd have to treat him like a child that faces the world for the very first time. I guess he should ask himself: do you want to be treated exceptionally throughout the recruitment process? If you think you're that unique, you're probably wrong (and that level of detachment from reality isn't looking good).
> getting upset over "show us that you can do anything" minimal bar test is something I'd rather not get in my mailbox
A minimal bar test shouldn't take 90 minutes. If you want a test like that, ask a FizzBuzz question, which is solvable in ten seconds and will be just as good a discriminator. Asking people to basically solve riddles isn't productive.
Well, although I'm not one of these types that is insulted by online coding challenges as a hiring prerequisite, I think they're probably a lot more pointless than you believe. I've been working as a developer now for a little over 25 years - although online coding "challenges" are a relatively new thing, I've been given actual sit-down, pencil-and-paper, quiet room for an hour aptitude/language trivia tests as prerequisites for jobs in the past. This was actually the sort of thing that certifications (remember Java certifications?) were supposed to obsolete but never really did.
Last year I found myself back on the market for the first time in quite a while and was presented with an online coding "challenge". It was actually really trivial, but I failed it anyway, because I'd never done one before. I'm used to coding in an IDE (or just in good-old vi), not in an online editor, and not with a ten minute time limit. The "challenge" was to write a Java function that would take in a number in words (like "four") between one and ten and spit out the numeric value of that number (like "4"). Well, it was timed, and I sort of panicked, thinking I wouldn't have enough time, so I jumped into it without reading the description. I skimmed over the description, and though I had to write a Java _program_ that would accept a _list_ of numbers, parse the list, and output their numeric values. So I hurried up and started coding in the (completely unfamiliar) online editor. Then I copied and pasted the whole thing into an editor on my local machine so I could compile it and run it and check for silly mistakes (since I was under the gun). Only after I had verified and tested it locally did I re-read the description and realized I had done the wrong "challenge"... so I tried (with three minutes on the clock) to refactor it so that the part that read in the number in words was a function inside my overall program. With maybe 30 seconds to spare I had refactored and re-tested it with a note that (/* here is the function you asked for */). Well, they failed me. Why? Because I took way too long to complete such a simple task...
Now, if I had to take another one of these today, I'd read the instructions very carefully (I'd probably spend the first minute reading and making sure I didn't overlook anything - which of course we should always do anyway) - but it struck me how infinitely game-able and simplistic that portion of the modern job interview is. It doesn't much measure programming ability so much as your familiarity with that sort of exam, which us old folks ain't.
Evaluating someone based on their GitHub repos isn't trivial at all, and it's not something a (non-developer) recruiter generally can do effectively. At the stage when HackerRank is relevant, the recruiter is trying to decide who to put in front of a technical interviewer.
It's important to keep in mind the big advantage of tools like HackerRank: They're scalable for the employer, allowing the employer to take a chance on more candidates.
Without something like HackerRank, recruiters will tend towards lesser heuristics, such as top schools or top firms on candidates' CVs. While HackerRank has its issues, it's certainly a vastly superior heuristic than the alternative for those many of us that don't have that kind of CVs.
It's also relatively scalable for the applicant, because it is asynchronous, and can be taken whenever convenient. For many people in jobs, taking a phone interview during business hours isn't easy.
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.
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.
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'm hoping ABC's recruitment policy is flexible enough to let me offer alternative, or at least parallel, routes to quantifying my skill in coding [...] Would ABC be willing to work with me to define a better way to check my technical qualifications by choosing one of these projects?
It's good to see someone take the initiative to express this, but IMHO, it would be even better to just take the initiative to contribute to one of the proposed open source projects and put it on your resume, and participate in the Hackerrank part of the interview.
I like the proposals, and I'd probably land on the side of impressed if a candidate I was interested in sent me a letter like this. But, I still need a quick way to screen people, and I also need a set of standard questions that all candidates get so I can compare & rank them. I don't use Hackerrank, but I do ask easy weeder questions in the same style.
Then, after the candidate passes the easy part, I look at their portfolio of work projects and side projects, and consider everything they have to offer.
It is difficult to believe that the person who knows how to sling slang like "chops" (technical command and facility in a given domain)is the same person who is only just hearing of HackerRank through an employer's request. Also saying condescending things like "cute little" in your response takes away from your earnestness cred and makes you seem angry. No one wants to start off angry with a new hire. That said, you have a right to be angry when an employer chooses to "batch process" you like just another piece of data. While your proposal is great and it shows you go above and beyond, and employer who uses HackerRank isn't looking for above and beyond. Use it to weed out employers who won't meet you halfway as a partner- the way you want to be met. If you are looking to work with a Willy Wonka, consider the thought and care that went into his job interview.
You are not alone in your frustration, and I suspect most people here will sympathize with you as this topic comes up quite often in the software community. Just be aware that drawing this kind of line in the sand is going to greatly limit your options.
If you want to be evaluated in a more holistic manner (including side projects) you'll probably have better luck with very small companies. When the people in charge will actually be the ones working with you every day, and they are only filling a small number of positions, they will be more likely to find it worthwhile to get to know you as a whole person during the hiring process.
Unfortunately, once a company is beyond a certain size this just isn't possible because it doesn't scale. They have to fill hundreds or thousands of positions and also maintain a universal set of hiring standards. Things degrade into a game of numbers. This makes cookie-cutter tests almost inevitable.
While frustrating in their own right, for me what makes things worse is that you have to do one of these screens for every single company you apply to. And most companies have the same evaluation goals for the phone screen stage (e.g., do you actually understand data structures & algorithms).
What I'd really like to see is the emergence of something like a "common app" for software hiring. Outsource technical screening to a reputable third-party, and once you've proven yourself by obtaining a good enough "score" you can move immediately to on-sites (what constitutes a "good" score would vary by company). This doesn't solve the problem of the efficacy of technical screens, but it at least cuts down on all the redundant effort.
Two services I've tried so far that are doing something like this are Interviewing.io and A-List. Unfortunately it seems these services merely make it easier to get a phone screen, rather than replacing them. But it seems like a step in the right direction.
In general, I find that assuming that other players will act rationally or in their own best-interests (according to my subjective definitions) is inadvisable. If OP has a major problem with the quality of their hiring process then, by extension, he could also have major problems with his potential co-workers and the organisation's culture.
The value proposition of investing time and effort into interviewing with this company appears to be less than, say, interviewing companies whose priorities are well-aligned with OP from the get-go. That being said, these kinds of "coding puzzle" screeners aren't going anywhere, and may lock him out of great opportunities at great companies.
"I'd rather have it and not need it, than need it and not have it."
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 don't think I can find it right now, but I recall a comment by Patrick MacKenzie (https://news.ycombinator.com/user?id=patio11) to the effect that companies that have onerous interviews often also have a "cheat code" path for highly accomplished candidates (well known figures, or someone who's strongly vouched for by someone highly trusted within the company) who find the normal interview process unwelcome.
This response seems like an attempt to engineer that path out of nothing. Good luck, but you can also avoid these interviews if you can make those connections/build your reputation to the right extent.
I think this is a perfectly valid response if you are senior/experienced/specialist and asked to do these impersonal quizzes. "We need to filter out the idiots" is not a valid reason to waste an experienced candidate's time either.
There's no question that some questions are inappropriate for senior hires. For example, if someone comes in with a lot of open source work, I think it's probably wise for the hiring manager to devote some more time and personalize the process a bit since that person has already has signals that they are probably good (or at least more likely to be good than most candidates).
But most developers (and I'd venture most good developers) don't have reputations that proceed them. Since it's hard to separate the wheat from the chaff, I think that a quick coding quiz is fair game so long as it doesn't waste too much time. For example, if I were interviewing, I'd probably be willing to devote about 30 minutes to this sort of thing, but more than that and I'm probably not going to bother unless I'm very interested in your company.
Sure, valid points, and agree there's a place for this type of screening.
I'm mostly referring to when you're experienced, and approached by a company via an on-site recruiter or employee referral. You are busy and not actively looking, but then trying to then feed you through hackerrank quizzes or whiteboards is just so off-putting.
My experience has been worse: After I'd do all that, they said "great, we'd like to hire you at 80% your current salary!". It angers me.
Nowadays I say up-front "I just want to mention this because it's generally been a sticking point and I don't want to waste your time, I'm looking for a salary in the range of $X". That has saved me a whole bunch of time.
Agreed. I've seen this a lot myself. Companies want you to jump through hoops for them, but the most qualified people for the job probably don't have the time, patience or desire to do so.
One the one hand, I agree about the mismatch between hackerrank and engineering skill. On the other, I also suspect there are many engineers who can code amazing personal projects who lack the motivation/communication to handle the kinds of maintenance tickets you'd likely see in a mediocre codebase for a noname b2b (or whatever the job is).
I'll admit my initial reaction to these sort of requests can be pretty negative, I did find this letter well written and wouldn't have a problem with it if I received it.
That being said, depending on the type of company and the number of candidates they are dealing with, I wouldn't be surprised if they simply ignore your letter rather than trying to deal with it. If you have 60+ more or less qualified applicants for a single job opening your first job is to get that down to less than 10 as quickly as possible and throwing out anything that doesn't fit into your template is a quick and popular first step.
I worked in a job a couple of years ago with a small team that was hiring quite fast so it was typical to have to evaluate 10 applicants a week. Since as leads and seniors we were very busy Hackerrank was a useful way to evaluate lots of people without much effort and easily compare them by “score”. That said I regret it because the results were not as good. Every candidate is different enough that each interview turns out completely different. I think a better policy is if you’re too busy to give people the attention they need as they go through the pipeline - just wait until you’re not busy if possible.
I have no allegiance to the HackerRank or the current hiring process of most Bay Area tech companies. The basic formula is: first a chat with the recruiter/hiring manager to establish interest; follow up with a screener that is a take-home exercise, HackerRank exercise, or phone interview with an exercise; then a four to five hour on-site. This is a lot of time for everyone involved.
What are the alternatives?
They need to minimize time, give everyone a fair chance, and improve the signal. I certainly wouldn't say the current method is great at meeting those criteria.
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.
IMO If employer is adamant to rely only on cookie cutter first round interviews, then it’s probably not worth joining such places. It’ll be filled with people who are great at cracking such interviews and believing that these cookie cutter interviews are the only way to go.
There will be people on both sides of this debate, pro and anti.
If you don’t believe in solving algorithms/ hackarank type initial interviews, it’s good to challenge such requests.
If you are fine with it, that’s great. You and the employer have the same thinking. And it’ll/ May work great!
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.
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'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.
> 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).
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.
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.
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.)
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 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.
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.
One of our hiring managers uses HackerRank as a basic filter. (If you are applying for a position called Data Scientist and you cannot do a linear regression, you are applying at the wrong company.)
I think an email like this would be just fine, for them.
I think it would go over badly at companies where HR runs the hiring process.
From both sides as a hiring manager and candidate, I’ve found that a take-home coding challenge that’s tailored to the company is a far better indicator of fit.
With a tailored take-home, the company has a chance to evaluate candidates based on more realistic, holistic challenges than “solve this academic comp sci problem that you won’t actually encounter on the job”. And candidates can get a better sense of the type of work and challenges they’d actually be tackling on the job.
The take-home isn’t tailored to each candidate. The opposite, actually: it needs to be the same for all so that candidates’ solutons can be compared.
Here’s the tl;dr example of a challenge we give web engineering candidates:
“Here’s our API and API docs: <link>. Create an interactive data visualization using D3 and any other tools you’d like. Your submission should include instructions on how to run it.”
By keeping the challenge relatively unconstrained, we allow candidates to show some creativity and prompt them to make the same feature/quality/speed tradeoffs that they’d have to make in the role. We look for autonomous individuals, so this turns out to be a good filter. We encourage them to spend less than 4 hours on it, but our time limit is a pretty generous 1 week since they likely already have a full time job and other interviews.
I very much agree after adding similar at my last company, it was a great way to screen the best-fit hires. Ironically the on-site recruiters didn't like it because it gave better results than their phone screens.
As reasonable as this seems on the surface it implies a person who will likely next send me 3 pages about how he should be exempt from the vacation policy and a treatise on how we are doing our health insurance. I'd be a hard pass after reading this.
Developers that are in high demand can help guide prospective employers on what sort of technical interviews are acceptable and which are a waste of time on everyone's parts.
There are very, very many comments here accusing HackerRank and/or puzzle/algorithm problems in general of being poor tests for how good a programmer someone is, or that people who use such problems just want "robot" workers to churn out meaningless code.
These comments are completely missing the point. HackerRank's value is as a screening process. The point of such problems in the early phases of an interview is not to find out how good a programmer you are, but how bad a programmer you are.
There are an ASTOUNDING number of candidates for programming jobs who can barely code. FizzBuzz eliminates a lot of them, but sometimes you need something just a bit more difficult. That's where HackerRank comes in.
When talking to people that are "professional programmers actively seeking work" I find that the majority of them can't do simple tasks. "Simple" isn't meant in an arrogant way, either; examples include reversing an array (with no space constraint), iterating a dictionary/map (regardless of understanding map implementation, a lot of people don't understand that iteration order isn't predictable), and basic use of nested lists/non-scalar data structures. Those aren't esoterica that "nobody uses" on a daily basis, they're bread and butter of programming work.
These people have hobby projects/OSS work, it's just . . . not sufficient, in many cases, to indicate basic competence on the job. I don't know why that doesn't correlate. I don't think most of these people are lying and publishing work that isn't theirs. It might be that they have a very long time to write the stuff in their GitHubs or whatever and can't do basic things in a hurry otherwise. It might be something else. Regardless, they turn out to be unqualified when tested on the basics.
If you find the problems insultingly easy, choke it down and consider it equivalent to the question of "are you comfortable being asked to show up to work on time?"--patronizing, but an easy box to check, and not meant for you.
There are companies that rely entirely on very hard/complex algorithms problems for interviewing, with the full knowledge of what they're testing for and why they're using those tests. I'm not talking about those companies; there are good and bad reasons for doing that. I'm talking about simple coding challenges presented early on in the candidate's process.
There are also companies that get confused as to what they're using the HackerRank-equivalent tests for, and give really hard problems (or, worse, puzzle problems that block all progress and rely on some sort of "gotcha" trivia knowledge to even approach), but evaluate candidates' performance as if those problems were FizzBuzz++ basic competence screenings. That's a mistake, but also not what I'm talking about here.
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.
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.
I have had the misfortune of doing a few HackerRank tests where the problems were not prepared well.
For example, the correct answer does not appear in the list of available options, or where the problem statement is not precise enough to solve in an unambiguous manner.
There is no human I can talk to and ask clarifying questions to resolve the ambiguity because, you know, it is a HackerRank test!
After going through these experiences, I have decided that HackerRank test is just not worth the time. As a rule, I decline any request to take a HackerRank test citing my reasons as politely as possible. Surprisingly, more often than not, the recruiter is happy to setup a telephone round where I can talk to an actual human.
I think many HR people will just ignore you if you e-mail what OP posted. Once, I wrote a blogpost why programmers don't get jobs due to random factors ("Why software engineers don’t get jobs: Four horror stories" https://goo.gl/v4PUWV), but being patronising and "explaining programming to HR" is one of the things where you just shoot yourself in the foot by being too demanding too early in the process. You can be demanding ONLY AFTER they told you that they want to hire you, but not before.
A tip for e-mailing HR and business e-mails in general: Try to never signal that you will be hard to work with. Always be kind and even a little bit submissive. Don't try to teach people something, don't quote authors and don't do footnotes. Imagine the person will take a maximum of 3 seconds per paragraph and 10 seconds in total to read your e-mail. There is a chance the reader is listening to an audiobook or is watching Youtube while answering e-mails in a cubicle. If you need to discuss something critical, invite the person for a phone call. Salary, negotiating or deviating from a standard process (like here) should be discussed in person/in a call.
Hope that helps to get some insight from "the other side".