[caminante]

!!!

You're missing the point.

The premise is that someone capable can blast through trivial assignments in no time. Either this is the final proficiency challenge or there are subsequent, harder questions. In the former case, why not see the salary/offer and then decide?

[eropple]

Typically, because one has other opportunities that are no less compelling and where potential employers show respect for candidates' time.

I have a GitHub profile with a lot of code on it and on my resume I highlight projects I've done a lot of work on. "What if faked tho?"--there's literally too much there to be worth faking. If a hiring manager looks at my resume, has the option of going to my GitHub profile, and between the two goes "I'm going to hand him a college-level Java problem because I'm not sure," then there probably isn't a way we're going to work together. And that's okay, on both sides of it; there are a lot of developers who aren't bothered by that kind of low-trust relationship. I am. Not a fit.

(This is in contrast to, for example, asking a question like that during an interview. Interviews are bidirectional, and are showing an investment in the hiring process on the part of the employer. If a card-deck Java problem is worth addressing with my time, then it's worth addressing with your interviewer's time. The contrapositive is also true.)

[tsukikage]

Personally, I only ever ask people to solve coding/problem-solving questions live. The best experience IMO is when we talk through the problem together, since this approximates what collaborating with this person on real tasks will be like - not very well at all, but about as well as one can do in the amount of time available for a live interview.

However, I do understand where the offline exercise idea comes from - it's not necessarily about lack of respect for candidates' time, but is generally done with the best of intentions in response to feedback, because candidates complain that the interview technical exercise scenario is needlessly artificial: in a live interview candidates do not usually have easy access to their usual tools or Google/Stackoverflow, and many feel pressure and panic from having to code/problemsolve live while someone is watching and feel they would do better if left alone to do the same thing for the same length of time.

Given the incredibly strong feelings either way, perhaps it might not be a terrible idea to let people choose which approach they prefer; but I've never seen any company's hiring do that, though, thinking about it, there really is no good reason why not (provided I still get to talk through the results of the offline exercise with the candidate during the live bit!)

[eropple]

I think this is a good analysis of where the offline idea started from, but in my experience the majority of interviewers who want you to do a "take home" thing are asking you to sign up for a multiple-hour mess of a project. That's where the lack of respect comes from, and the lack of acknowledgment of the market--most people you want to hire are already employed, after all, and time pressure from life is a thing.

Making it an option for somebody who would rather wouldn't be bad, but yeah, as you say, nobody's learning a lot about the other people that way, and they're probably more important.

(The OP's card deck problem is just faintly ridiculous and a bad allocation of the candidate's time, and I assume there are more hoops to jump through afterwards.)

[caminante]

> "What if faked tho?"

> If a hiring manager looks at my resume, has the option of going to my GitHub profile, and between the two goes "I'm going to hand him a college-level Java problem because I'm not sure,"

I know we're talking hypotheticals. I get your position 100%, and good for you.

My view is that I'd tell you that

1. I've seen your Github profile

2. However, I didn't have time to go through your entire Github profile looking at your efficiency and productivity. I want to do a quick, ad-hoc programming exercise to see how fast you operate on basic tasks (which #1 doesn't readily address). I expect you to crush it really fast and this is the only coding exercise I'll have you do.

To me, that doesn't seem unreasonable if I'm upfront about expectations. Your response will also say a lot about you (not necessarily negative, but for fit).

These requirements come up because someone always slips through diligence. While you might be getting punished, interviewers are trying to de-risk candidates as much (and as fast) as possible.

[eropple]

> I want to do a quick, ad-hoc programming exercise to see how fast you operate on basic tasks (which #1 doesn't readily address).

Right. And to do so in good faith, this absolutely can and should be a collaborative exercise with an interviewer. It demonstrates that the employer has skin in the game and isn't body-shopping. Once you're out of junior/low-mid hiring, this is really, really important to getting quality candidates to go through your funnel.

> interviewers are trying to de-risk candidates as much (and as fast) as possible.

Of course they are. They should also be aware of the tradeoffs in doing so.