Yesterday, I failed a technical interview. It happens, and that's OK[0]. But this one left me with a pretty bad taste in the mouth: I didn't feel I was rejected because I hadn't met the company's standards, or because I made a mistake, but mostly because I was tested for something completely irrelevant for a developer job.

The technical interview wasn't a conventional one, it was one of the new fancy “automated interviews”, where you log into a website and then you're being given instructions and a tight time limit. When the limit expire, your code is checked against an automated test suite and you're being given a grade.

For the HR's perspective, it sounds awesome: you have a very cheap way to screen dozens of candidates without human interactions. No more false positive, every candidate passing the test must be “technically proficient” and all you have to do next is assess their social skill.

Unfortunately, these kinds of tests are very bad at measuring technical proficiency of a developer. To understand why, you need to understand what a developer's job is about.

A developer's job isn't to write code: the role of a developer is to turn someone's needs (1) into a product (2). We do so by writing code(3) as part of a development team (4).

• (1): a big part of a developer's job is to ask questions, to clarify the needs. You want me to write a program that converts a camelCased string to kebab-case? OK, what do you mean by “camelCase”? Does this string: PascalCase counts as “camelCase” in your mind? And how about acronyms? And numbers? And emojis? Are your input always gonna be well-formatted because they have been validated, or do I need to handle the situation when I'm being given a string which isn't “camelCase” in the first place? What do you want the program to do if an error occurs? Send an event to your telemetry system? Print a stack trace? A user-friendly error message? If so, should the message be internationalized? As you can see, there's no such thing as “a program that does X”, it's all about clarifying the stakeholders needs. And there's nothing worse than a developer who starts coding as soon as they think they understand the specification, without asking any questions to be sure that their understanding is aligned with the needs.

• (2): a product is more than a piece of code, and sometimes your users' business depends on your product working as intended. How you make sure your code is working, how you monitor when something goes wrong and how you deal with failures in production, are what makes the difference between reliable and bad software.

• (4): a developer almost never works alone: reading someone's else code, writing code that is easy to understand and maintain by your coworkers, and using a version control are fundamental skills for any developer.

• As you can see, “writing code (3)” is only a small part of our job. And it's the becoming less and less important over the years. Compared to 40 years ago, developers will probably need 80 to 90% less code than before to complete the same feature, thanks to the profusion of high quality open source libraries. And it's likely to shrink even further, with the advance of AI[1][2]. And sometimes there are tough coding tasks, which need careful design, tradeoffs, sometimes trial & errors and fights with a debugger. That's when you need developers that are good coders. But even for those tasks, measuring whether you can solve trivial problems during a timed test is a poor proxy for how well your developer is going to face difficult challenges.

[0] : to be honest, it's the fifth time in eleven years, and I've always been pissed off after failing a technical interview, but I'm usually mad at myself for being bad.
[1] : https://github.blog/2021-06-29-introducing-github-copilot-ai-pair-programmer/
[2] : https://deepmind.com/blog/article/Competitive-programming-with-AlphaCode

À exécuter dans la console, ça donne la moyenne, la médiane et les valeurs strictement au dessus ou en dessous d'une valeur arbitraire (1000 dans l'exemple parce que je regardais les stagiaires).

var salaries = $$('li[itemprop="baseSalary"]').map(elem=>parseInt(elem.textContent.replace(/(\d+)€.*/,"$1"),10));
salaries.sort((a,b)=> a > b);
console.log("moyenne", salaries.reduce((sum, val)=> val+sum)/salaries.length, "€");
console.log("en dessous de 1000€", salaries.filter(val=> val<1000).length, "annonces sur", salaries.length);
console.log("au dessus de 1000€", salaries.filter(val=> val>1000).length, "annonces sur", salaries.length);
console.log("médianne", salaries.sort((a,b)=> a > b)[Math.floor(salaries.length/2)], "€");

Edit: la première version était bugguée, merci à JavaScript qui utilise l'ordre lexicographique par défaut dans la méthode sort (du coup 500 > 1350, logique …)

… pour les neurones !

Depuis que j'ai changé mon profil linkedin pour dire que je suis disponible pour un nouveau taff, j'ai reçu un certain nombre de messages de chargés de recrutement, et je pense vraiment que ce métier a un impact délétère sur les capacités cognitives de ses pratiquants. Petit florilège de débilités:

J'ai bien conscience qu'aujourd'hui vous êtes en poste , mais […]

euh …

Nous avons tous eu affaire à des recruteurs qui ne connaissent pas la réalité du terrain.
Notre expérience d’opérationnels, à des postes à responsabilités dans les métiers de l’IT, nous permet de parler le même langage que vous et d’être familiers des questions que vous vous posez.

Et là tu regardes ses expériences passées :

• Headhunter
• Suivi Administratif RH et Commercial
• Assistante de comptabilité
• Assistante Ressources Humaines

On interviewing.io (though I wouldn’t be surprised if this finding extrapolated to the qualified engineering population at large), impostor syndrome plagues interviewees roughly twice as often as Dunning-Kruger. Which, I guess, is better than the alternative.

Je note ce site au passage.

Je ne suis pas convaincu par la pertinence des question évoquées dans l'article, par contre le 2ème commentaire beaucoup plus :

1) What is the difference between == and ===
2) How do you write decoupled JavaScript code.
3) Explain prototypes in JavaScript
4) Explain how to write asynchronous JavaScript
5) Explain why asynchronous code is important in JavaScript