[shady-lady]

> If you complain about having to spend a couple hours outside the interview on work, maybe you don't really want the job that bad enough

Maybe I'm talking to more than one company and don't feel like subjecting myself to this absolute nonsense over & over. Maybe I'm just feeling out the opportunity without having to worry about solving a made up issue and hope it conforms to what the employee reviewing it considers good.

What other in-demand professions(based on demand vs. qualified candidates) make potential employees sing & dance, and then go through a full interview process on top of that?

Do accountants have to balance a fictional company's books or find the most efficient structuring of a fictional company's taxes across multiple jurisdictions before being allowed to have an actual conversation with a peer about the role?

[shady-lady]

To add to this; if a company does want me to put effort into proving I can code a solution to whatever problem, then they better have gone to the trouble of:

a) setting up a git repo with working code in it (including tests, dependencies and whatever else) so I don't have to worry about inane(but taxing) decisions in terms of project structure/code style. Also, verify it works before sending it out to candidates.

b) including clear & detailed instructions on what is expected

c) given the test to current employees (blind) & timed them on it (allowing for the fact they know the domain & technology)

d) make it somewhat representative of day to day. i.e. I have 0 interest in spending time configuring and doing anything which is a 1-off task such as authentication etc..(unless the companies primary product is security/auth)

In short, make it easy for me to prove myself.

[justinpombrio]

(c) and (d) are sensible suggestions, but I've got to question your (a) and (b).

It sounds like you don't think much of testing, if you're expecting tests to be handed to you. Testing is hard! Writing good test cases can be as hard as writing the code itself. If your tests are inane, then you're going to catch the easy bugs and miss all the hard ones.

And when on Earth do you get clear and detailed instructions on what is expected? At least in my current job, I feel like half of what I do is turn vague expectations into crisp technical requirements. If part of the assignment is for you to write a function, I can't include test cases for you because I don't know what type signature you're going to pick for the function. This isn't an inane detail. In some ways the signature of the function is more important than the implementation: the implementation is local to the function, but the signature is going to effect the structure of all of the code that uses it.

[shady-lady]

> It sounds like you don't think much of testing, if you're expecting tests to be handed to you

Should have been clearer They should have tests to cover their code (not the code I'm going to right).. This cuts down on me adding testing libs needed, any setup, and laying down a pattern for their expectations(wrt tests). With expectation dev would add tests to cover their code.

> And when on Earth do you get clear and detailed instructions on what is expected?

On the job, I have easy access to the information/easy access to the people with the information. Not to mention personal relationships with the people I need to query.

My usage of 'inane' refers to things that a dev on the job won't be doing 99.9% of the time. Things that take effort & thought to setup(initial project setup) but don't really give any insight into whether a dev can write & architect code well. All the things a company already has in place.

[justinpombrio]

Ah, that all makes a lot more sense :-)

[rahimnathwani]

"Do accountants have to ..."

I'm a qualified accountant, and have, during an on-site interview, been asked to update a company cap table based on some information about additional fundraising and employee grant transactions.

[shady-lady]

notwithstanding that (itself an interesting data point)

> before being allowed to have an actual conversation with a peer about the role?

[rahimnathwani]

During the first conversation with a peer.

[gwbas1c]

An interview is a two-way street. I've walked away from two interviews because the whole ordeal was going to be very time consuming and I just wasn't sold enough on the company.

I did do two coding exercises, though. In one case, the exercise was very fun, and I was able to use it as an excuse to work in a language that I didn't work often in. In another case, I really believed in the company, but I would only do something that took about 1-2 hours.