Questions d'entrevue stupides en Javascript

Dec 11 2022
Je ne suis pas contre les questions techniques directement. Je pense que c'est l'un des moyens de se faire une idée des compétences techniques du candidat.

Je ne suis pas contre les questions techniques directement. Je pense que c'est l'un des moyens de se faire une idée des compétences techniques du candidat. Je préfère plutôt une discussion technique à un entretien technique strict. Mais laissez-moi vous expliquer l'une des pires questions de Javascript aujourd'hui et pourquoi.

Liste liée individuellement

Avant de commencer à décrire mon propos, creusons un peu l'histoire de Javascript

C'était l'année 1995 , développé par Netscape (Brendan Eich), plus tard Mozilla a continué à améliorer et à développer javascript. L'idée derrière javascript était de créer une sorte de dynamique lors de la navigation dans le monde en ligne. Il a été utilisé pour certaines alertes ou animations très basiques. Javascript a été conçu pour avoir l'apparence de Java, mais pour être plus facile à utiliser pour les non-programmeurs. A cette époque, il n'y avait même pas AJAX -> Javascript n'était pas utilisé pour les requêtes et autres.

Vers 1997, Javascript fait partie des normes ECMA.

En 2005, nous avons eu la première version officielle d'AJAX -> c'est le point où le développement Web d'aujourd'hui a commencé. Il n'était plus nécessaire de rafraîchir la page pour pouvoir recharger les données. Imaginez que vous puissiez soudainement créer une sorte d'application Web. Mais la question est : Javascript était-il prêt pour cela ? Eh bien pas vraiment. Les développeurs se sont rapidement habitués à utiliser des éléments tels que IIFEE :

(function() {
// Code that runs in your function
var name = 'John Doe'
}
)()
console.log(name) // error as the name is not defined in this scope

IIFEE était essentiellement du point de vue d'aujourd'hui une solution hacky pour pouvoir créer une application complexe avec plus de fichiers .js . Nous avions besoin de ce genre de solution car sinon, nous aurions un conflit dans le nommage des variables , des fonctions , etc, car Javascript était un langage strictement fonctionnel sans classes.

VAR et le Hoisting -> Hoisting est un comportement de déplacement des déclarations vers le haut. Et en javascript, la variable peut être utilisée avant d'être déclarée. Ceci est un scénario valide :

myVariable = ‘is this shit possible?’
var myVariable;
console.log(myVariable); // is this shit possible?

Dans cet exemple, la variable myVariable a été déplacée vers le haut et initialisée en même temps, c'est la raison pour laquelle, à la ligne 3, la variable stocke déjà la chaîne.

Et il y avait tellement plus de choses et de problèmes comme ça. Sans oublier les parties bizarres de javascript, que vous pouvez trouver ici :https://hackernoon.com/the-weird-parts-of-javascript-zxo34i8

Mais quelque chose a changé avec Javascript à partir de la version es6

Si nous revenons à notre exemple de levage avec la nouvelle approche :

myVariable = ‘is this shit possible?’
let myVariable;
console.log(myVariable); // undefined

Javascript place toujours la déclaration de la variable en haut, mais pas l'initialisation. Ainsi, notre console écrira une variable indéfinie au lieu de la chaîne.

En plus avec la version es6 nous avons :

  • Fonctions fléchées
  • Des classes
  • Modules
  • Promesses
  • Générateurs
  • déclarations let et const pour les variables
  • Opérateurs de propagation et de repos
  • Modèles littéraux
  • Déstructuration
  • Et beaucoup plus

Quelles sont alors les mauvaises questions d'entrevue ?

Il était nécessaire de montrer au moins certains de ces exemples avant que je puisse commencer à tirer mon argument.

Imaginez que vous êtes un nouveau développeur et que vous commencez à apprendre Javascript. Il n'est vraiment pas nécessaire que vous compreniez :

  • Var
  • IIFEE
  • Fermetures
  • Les promesses et leur utilisation (mais c'est bon à savoir)

Mais il n'est absolument pas nécessaire de vérifier la connaissance de l'ancienne version de Javascript. L'ancien Javascript a été construit dans un but différent de celui utilisé aujourd'hui.

En conclusion , on peut dire que : Bien sûr, Javascript a encore ses faiblesses. Mais si vous savez comment l'utiliser, vous n'écrivez du Javascript vanille que pour les petits sites Web HTML ou les petites applications. Sinon, chaque développeur sensé utiliserait le Typescript.