There are several things I might consider, but this is by no means an exhaustive list:
* Tech fit -- how does this technology solve the business problem? Have you considered how the overall architecture will look like? You might end up splitting them up to several different components each potentially valid to be written in different languages, depending on their nature. Given that, what do you need to achieve? Perhaps a Rails app is fit for purpose if you're writing a proof of concept. Or you might opt for a language that has established libraries for exposing a RESTful interface and write an SPA on top of that. My point is that it really depends on the business problem and how that is tackled.
* Ecosystem -- are there libraries out there that help you do what you need it to do? Will you have to roll your own?
* How will it be maintained? If you're not working for yourself, then you can assume your code will be maintained by someone else. Is the technology chosen accessible for your intended audience? Like you said, if it is a xyz shop, then it might make sense to write it in xyz. If it's a polyglot shop, then perhaps this is less of a consideration.
* What are the development tooling like? IMO this is quite important for my sanity because I dislike using clunky tools.
* How will the code be pushed out to production. Are there established best practices for pushing the code you're written in xys language into production?
* How easy is it to write tests for the language?
Something to also consider is whether it is good for the future. There is an element of YAGNI here, but it's worth considering the longevity of your technical choices and how easy it will be to upgrade.
As a company interviewing candidates, we see the recruitment process much like a conversion funnel for any website: there will be a lot of hits on our spec, some people will apply, of which some will do the telephone interview, of which some will get through to the coding test, and so on.
If OP doesn't want to do a test, then he will just end up as one of the ones that didn't make it through the funnel. This then boils down to whether there are companies out there that will take him on his project's merit or whether OP is desperate for a job.
A couple points I disagree with:
* "My main gripe with coding tests is that they ask me for an investment of my time and resources so that they can gather information about me, but I'm getting nothing back." -- you can potentially progress to the next interview stage, you will refresh your memory on coding tests, etc. There is still something to be gained.
* "I've already expressed interest in their position." -- there is minimal effort required to apply for a job. As an interview we get swamped by CVs that all look equally similar - we often need something to distinguish between these CVs. We have seen a wide range of coding test submissions and from this you can glean how interested the candidate is.
Finally, while the OP's suggestions are sensible, they are not always practical for companies, especially when it scales. We can't afford to be distracted by bringing a candidate into the office and work with us especially if we have multiple candidates. Even if the company decided to bring someone in, and assuming the candidate is capable, it will take them the better of a day to get up to speed and running -- setting up the dev env, getting the source, building it, making sense of the application, making sense of the feature/bugfix, making sense of the coding style, etc. They won't be effective enough to actually check in working code.
Getting to the next interview stage is not 'getting something back' according to his criteria - at that stage he doesn't know if he wants to progress, and doing a test doesn't provide more information. It gives the company information on whether it wants to progress, but not the candidate.
Also, refreshing memory on coding tests is not exactly getting a lot back. You don't need to do an interview to do a coding test, if that's your fetish.
Not that I completely agree with the guy. I don't mind coding tests or assignments, except when I have no idea whether or not I actually want to work at a company when they give me one. So, in that case, unless I'm really bored or feeling especially unemployed, I don't put a lot of effort in. I do understand why companies do them, and the company I work for does.
Thanks, that's essentially the answer I was about to write.
I think the main disagreement here is that OP considers hiring him to be a privilege where parent considers being hired by him to be one. As long as parent is OK missing out on all the developers that aren't hungry enough to subject themselves to one-sided interviews like this, he'll be fine.
I like to think there's a high correlation between one's skills and unwillingness to accommodate arbitrary processes, but have nothing to back that up.
| so you'd think they would know almost instantly what they're looking for.
What they are looking for is probably a subset of good startups, ie. your startup can be good but it's not what they are looking for.
To some extent it must be a statistics game for them. The investment they make flying founders out must have a good return for them in terms of potential investments. Since they have been doing it for a while now the numbers must be close to optimal.
The paragraph heading said 'Old People.' Particularly poignant for me - my dad is highly experienced but was recently laid off and has been searching for a job in the tech sector for months. Ageism in tech is brutal.
Feels like GoDaddy tried desperately to gain mind-share of ruby/rails developers, realised it was costing more than it was making and hence shutting it down.
I have a similar resolution. I find that I excessively judge others internally (even though I don't voice it) and that places irrational pressure on myself. I judge because of various reasons, but I think mainly to make myself feel that I'm better. This illusion ended when I realised I'm not actually that good at anything. I wonder if I am the only one.
* Tech fit -- how does this technology solve the business problem? Have you considered how the overall architecture will look like? You might end up splitting them up to several different components each potentially valid to be written in different languages, depending on their nature. Given that, what do you need to achieve? Perhaps a Rails app is fit for purpose if you're writing a proof of concept. Or you might opt for a language that has established libraries for exposing a RESTful interface and write an SPA on top of that. My point is that it really depends on the business problem and how that is tackled.
* Ecosystem -- are there libraries out there that help you do what you need it to do? Will you have to roll your own?
* How will it be maintained? If you're not working for yourself, then you can assume your code will be maintained by someone else. Is the technology chosen accessible for your intended audience? Like you said, if it is a xyz shop, then it might make sense to write it in xyz. If it's a polyglot shop, then perhaps this is less of a consideration.
* What are the development tooling like? IMO this is quite important for my sanity because I dislike using clunky tools.
* How will the code be pushed out to production. Are there established best practices for pushing the code you're written in xys language into production?
* How easy is it to write tests for the language?
Something to also consider is whether it is good for the future. There is an element of YAGNI here, but it's worth considering the longevity of your technical choices and how easy it will be to upgrade.