Thursday, September 22, 2016

A modest proposal on solving the problem with developer latin

Latin is considered a dead language, as it has no native speakers any more. Whether this is true or not depends on your definition since it is indeed learned and spoken all over the world by a minority of speakers, mostly for use in esoteric rituals or for academic studies.

In either case, Latin is incidental at best to gauging the proficiency of (say) an English-speaker of today. However, Latin is really clearly defined with lots of interesting grammar and is probably kind of a cool language to ask questions about and to see how well English-speakers are able to articulate themselves in it.

Also, some English words and syntax derives directly from Latin and that can be quite interesting to follow in itself.

But if you were to hire a journalist, a tech writer or perhaps a person working a lot with written communication in general, how useful would a throughout test on Latin be? Not very? I thought so.

So, what has this to do with developers?

Every two or three years I forget past experiences and think how nice it would be to work at, for example, Google, where I know lots of people and which seems to be an OK place to work. This often coincides with the re-evaluation of going it all alone in my own company and sometimes not having the kind of traction I'd like with what I do.

And I realize this is a flogging a dead horse which has seen quite a lot of action throughout the years, but the main gist of all this is that I realized, mid through an interview, that the technical details we were discussion were very similar to Latin knowledge for an English-speaker.

Even worse, I have it from the horses mouth (the very same) that in actual practice, there an awfully little Latin being spoken inside Google after you've been hired.

Ho often do you re-balance a red-black tree? How often do you map a tree according to certain criteria onto an array? It sounds like you might, at some point. I guess.  I'm using a lot of priority queues and trees when coding, but implementing them myself? Has never happened. Or, I did make my own quad-tree once. tbh.

So how hard can it be? These are super-easy programming problems from university, after all. If you don't know them, what do you know? Right?

Do you remember learning that new library or framework recently? The one where you sort of understood what it did but still made lots of silly mistakes the first week. And you, who have been coding for more than ten years (or 20 or 40, you get it). Isn't that embarrassing?

It turns out that never mind how experienced you are or how smart you are, unless you are experienced in the specific area in question, you're not so hot anymore. You don't get that extra days or week or whatever.

That's all fair, but to train specifics of implementing certain classical algorithms and edge-cases thereof that will never ever at all be used in production is indeed a bit like asking for knowledge of Latin for a position where a thorough, current knowledge of (say) English is required.

And of course you can spend those extra days and weeks and read all those websites and books that train you what the current slew of Latin is hot, people do it all the time.

But - and here comes the modest proposal btw - wouldn't it be a better approach to actually test people on the skills they are supposed to use at the position they are supposed to be hired for?

As a company you are certain to hire people who are smart - smart enough to read up on a number of very odd and old, basic algorithms, learn their edge-cases and actual talk fairly fluently about it all at the end of the interview. So you're sure to get both unnecessarily motivated and very smart people to hire.

That's great!

And you won't get the people who quite frankly are tired of all that Latin.

How about this;

- You already know the devs you've sourced and filtered out are the top 5% or so
- You know what they've been working on, which companies and github projects and so on
- Go over one of their projects one-on-one
- Ask them how they feel about testing
- Ask them the worst bug or problem they've been responsible for
- Ask them to write something on their own machine, on their IDE of choice, that is applicable to the position they're hiring for.


You already know very well what you've got to lose, because you're losing it every day, by the tonnes. First company to go non-bonkers wins. :)

No comments: