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.
| 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.
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.
I don't see how that article talks about the FB killer. It merely states that it has observed UK teenagers moving away from Facebook and cites various reasons, one of them being parents encouraging the use of FB.
Maybe a FB killer is an app made for parents that persuades them to encourage their kids to use FB?
I'm on Windows at work and the scroll bar was visible (when I went there the 2nd time) but either I didn't notice it or I ignored it. In any case I think the content itself just didn't look like it required scrolling. Instead I clicked on the features on the left.
As an Asian, I can say with some amount of certainty that government official or company executive is viewed by the culture as 'successful'. All the parents I know want their kids to end up in a few industries: medicine, finance (accounting!), and law. It's an Asian thing. If similarities could be drawn, working in these industries in Asia would be comparable to living the American dream in the US.
It's truly a shame that the Korean news pan and label him as a 'failure'. It can only suggest what kind of a culture they have (as well as the majority of Asians). The man is spot on -- he is living a happy life as defined by himself, not anyone else.
Finally, you can argue whether IQ is a suitable metric or not, whether whatever metric should be considered, but the more important question is why is he being labelled as a failure for not turning out the way society expects of a person with high IQ?
The other side of the argument is that the more people that are creating/working with and disseminating/peer reviewing crypto projects, the better we will be educated on crypto collectively.
An example is web technology: plenty people have made plenty html/css/js mistakes in the past but there is also an overwhelming amount of evolving best practices on this topic, no doubt because of the mistakes made before. If all we do is decry crypto is hard, don't roll your own, then no one would be learning anything, and cryptography will be left to the a few select mathematicians and organisations that are referred to with acronyms.
It should be: crypto is hard, learn it and experiment with it, share your thoughts, and don't roll your own for critical applications.
Edit: clarity of argument in my example and grammar
I would very much be interested in the source describing this media-politics marriage dynamic that you mention.
>> Not surprising, there is no free speech in France.
I don't see this as a free speech thing. I could argue there's no free speech in X. This kind of thing happens everywhere. People with money has power.
Agreed. I will be interested to know what the lessons learned were and perhaps regulation will be the answer specifically for government projects, ie. civil projects similar to aircraft/military software development.
* 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.