An employer asked me to do a HackerRank test. Here's my alternative proposal.

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.

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.

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.

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.

> 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.