[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 :-)