[renegadesensei]

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.

[zaphar]

    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.

[UncleMeat]

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.

[zaphar]

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.

[hysan]

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.

[agentultra]

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

[renegadesensei]

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.

[agentultra]

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.

update: just markup.

[dlgeek]

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

[renegadesensei]

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.

[flukus]

The recruitment process is not the place to address economic inequality.

[kamaal]

>>The point of coding tests is that you can't prepare or easily Google an answer.

Several thousands of students solve these questions on online judges. These are some of the easiest questions to Google and get answers for.