Je te rappelle

Salut, je suis Katya, j’ai trouvé un travail. Et elle a écrit un manuel de formation sur la communication avec l'employeur. Je vais vous dire quoi demander lors de l'entretien, ce qu'il ne faut pas demander et comment le faire correctement.



J'ai conduit tout le mois à travers des dogmes. J'ai regardé les startups et Yandex. Il existe de nombreuses entreprises, c'est difficile à choisir. Pour trouver celui dont vous avez besoin, tenez compte de nombreux facteurs. Pour chaque entreprise, j'ai compilé une liste individuelle de questions. Universel encadré dans cette faq. Il contient les questions clés du demandeur et leurs analyses. Certaines questions sont adaptées aux développeurs, le reste conviendra à tout le monde. Allez sous la coupe!

TL; DR


Je ne sais pas quoi et comment demander.


Tenez l'algorithme!

  1. Réfléchissez.
    Qu'avez-vous aimé lors de votre dernier emploi? Qu'est-ce que tu n'as pas aimé? Pourquoi es-tu parti?
    Mappez ces points clés aux questions.
  2. Faites une feuille de route.
    Que voulez-vous d'un nouvel emploi?
    Affichez ces exigences pour les questions.
  3. Filtrer.
    Supprimez les questions inutiles. Une autre question, si elle relève des éléments de la liste:
    - la réponse peut être google;
    - la réponse ne vaudra pas le temps passé;
    - une grande chance d'obtenir une réponse socialement attendue;
    - la question est inconfortable, ils vous mentiront très probablement;
    - vous ne connaissez pas la bonne réponse;
    - vous ne savez pas ce que vous voulez entendre;
    - vous ne savez pas ce que vous ne voulez pas entendre;
    - la réponse n'affectera pas la décision.
  4. Précisez.
    Spécifiez les questions ouvertes.
    Si la réponse dépend des circonstances, demandez un cas spécifique.
  5. DĂ©finissez vos attentes.
    Que veux-tu? Que suis-je prĂŞt Ă  supporter? Qu'est-ce qui est inacceptable?
    Marquez les drapeaux rouges.
  6. Starget.
    À considérer:
    - taille de l'entreprise;
    - position;
    - description de poste;
    - objet de la réunion (étape).

Pourquoi si dur?


Afin de ne pas regretter le choix. Pour trouver une entreprise qui vous fournira tout ce que vous recherchez: tâches, perspectives, conditions - nous ne travaillons pas ici pour de l'argent :)

Le temps d'entrevue est limité. Nous ne voulons pas le dépenser pour des réponses socialement attendues, des excuses, des informations inutiles. Trouver le bon n'est pas facile. Vous devez savoir où percer pour que l'infa coule. Et ne piquez pas sans discernement, afin de ne pas vous noyer dedans. Nous préparerons des questions de visée subtiles. Nous allons construire un dialogue cohérent et significatif sur eux.


Clause de non-responsabilité


Le but de l'article est d'orienter ce qu'il faut demander et pourquoi. Il n'y a pas de connaissances sacrées ni de questions magiques. Composez approprié basé sur la liste. Utilisez l'algorithme ci-dessus.

Je vais aider à analyser les réponses. Sous chaque question (pas toutes), il y a des analyses par paramètres:

  • «Demandez-vous»: ce que vous pouvez entendre, ce Ă  quoi vous devez penser;
  • «Bon Ă  entendre», «Drapeaux rouges»: quelles conclusions tirer, Ă  ne pas prĂ©cipiter;
  • «Discuter»: que clarifier, oĂą rĂ©orienter le dialogue.

Les analyses ne sont pas exhaustives et sont basées sur une expérience personnelle. S'il n'y a pas de section, je ne considère pas mon opinion comme objective ou je n'ai rien à ajouter. Mes «bons à entendre» et «drapeaux rouges» peuvent ne pas correspondre aux vôtres. L'analytique n'est pas nécessaire partout: je ne sais pas ce que vous avez en tête, ce que vous voulez, ce que vous recherchez. Traitez cela avant d'aller à la sécurité sociale.

Dans la section "Wacky Questions", j'ai rassemblé des informations spécifiques et inutiles. Je ne les aime pas, j'ai énuméré les raisons. Si vous le souhaitez, utilisez-le.

J'ai couru dans 70% de ce que j'ai écrit, le reste n'a pas eu le temps. Si je me trompe, ce n'est pas comme ça, c'était différent avec vous - écrivez dans les commentaires comment c'est correct, cela aidera le reste.


Entreprise


"Montrez de l'intérêt - renseignez-vous sur l'entreprise." Des conneries. Pas intéressant - ne demandez pas, google.

1. Que gagnez-vous? Quel produit est la principale source de revenus?
Analyse
Demandez-vous
Cas 1. Votre projet est une locomotive.
Le produit principal est la vache sacrée: tout le monde prie pour elle, la verse avec de l'argent, elle fournira les ressources hier, mais aussi les attentes correspondantes. Prêt à travailler à l'avant-garde avec toutes les conséquences?

Cas 2. Vous êtes invité à un nouveau projet jeune.
Dans une pile et des processus aussi flexibles, mais ils peuvent s'effondrer: travailler à table, réduire le personnel. Comprenez-vous les risques?

Offtop. Connaissant le modèle économique et les sources de revenus, vous pouvez estimer la position actuelle de l'entreprise sur le marché, les perspectives de développement. Il est inutile d'analyser en profondeur une grande entreprise. Il ne sera pas superflu d'évaluer une startup si vous êtes guidé sur le terrain.

Discuter
Si vous participez au projet principal, faites attention aux questions sur le calendrier et les priorités de développement. Si vous en avez un nouveau, découvrez ce qui vous arrivera si le projet ne fonctionne pas.

2. Dans quels domaines travaillez-vous? Que sont les projets B2B, B2C, R&D?
Analyse
Demandez-vous
D'autres projets intéressants? Si vous en avez assez, y a-t-il un endroit pour faire une rotation?

Offtop. La question est plus probable pour les grandes entreprises, mais la réponse est inattendue dans les petites - elles peuvent s'avérer plus importantes que vous ne le pensiez.

Bon Ă  entendre
L'entreprise analyse le marché, recherche de nouvelles directions de développement, participe à des projets communs avec d'autres sociétés. De nombreuses équipes de produits différentes. Il existe des intégrations avec d'autres services. Investi en R&D.


La motivation


Le recruteur parlera de nishtyaki. Si quelque chose est particulièrement important pour vous, précisez.

Demandez à montrer au bureau. Spectacle le plus probable. Tabourets rembourrés, cuisine, salle de sport - cool si le lieu de travail est également pratique. Et puis les poufs sont au cinquième étage, et vous travaillerez au deuxième, où la réparation est en cours.

1. Qu'est-ce qui affecte mon salaire autre que l'augmentation? De quoi dépend la prime?

2. Quelles sont les incitations? Comment les mériter?

3. Quels sont les ordinateurs / ordinateurs portables? Puis-je travailler pour eux Ă  domicile?

4. Envoyez-vous des gars à la conférence? Et international? Où êtes-vous allé la dernière fois? Comment décide-t-on qui ira?


DĂ©partement


1. Combien de personnes compte le département? Comment communiquent-ils? Dans quelle mesure interagissent-ils?
Analyse
Demandez-vous
Les équipes / unités savent-elles ce qui se passe dans les équipes / unités voisines? Comment fouille-t-on les connaissances?

Discuter
- Quels problèmes sont résolus ensemble?
- Pourquoi vous êtes-vous réunis pour la dernière fois?
- Combien de personnes sont venues?
- Quel a été le résultat de la réunion?

Bon Ă  entendre
Les décisions clés sont prises ensemble, en tenant compte des différentes opinions. Le niveau d'indépendance nécessaire est maintenu. Tout le monde a une compréhension de ce qui se passe dans d'autres projets afin d'aider à la révision du code et de savoir qui peut résoudre le problème. Les décisions et les connaissances sont fixes et accessibles à tous. Les réunions formelles pour partager des nouvelles et des expériences sont des vins.

2. Quelles équipes sont réparties entre les développeurs?
Analyse
Demandez-vous
En plus des produits d'épicerie, il existe des produits hautement spécialisés: développement de composants communs, développement d'outils, équipe de refactoring, équipe d'architecture.

Cas 1. Beaucoup d'Ă©quipes.
Mieux se concentrer sur les tâches, une plus grande expertise des développeurs dans leur domaine, mais plus faible dans d'autres, leur intérêt pour les tâches "étrangères" est réduit. Je suis pour spécialisation + rotation. Es-tu avec moi

Cas 2. Peu d'Ă©quipes.
Plus grande implication, plus large éventail de tâches, mais plus large éventail de responsabilités. Prêt pour le rôle de «Suisse et Faucheur»?

Discuter
Clarifier la façon dont la responsabilité des projets et des microservices est répartie entre les équipes.

3. Combien de personnes travaillent dans le département depuis plus de 3 ans? Y en a-t-il?
Analyse
Demandez-vous
Combien de personnes pourront vous orienter lorsque vous refacherez des fonctionnalités importantes ou un héritage très ancien?

Offtop. N'essayez pas d'apprécier la fluidité. Trop de facteurs affectent si les gens partent ou restent. Un tas de vieux peut refléter non seulement des conditions de travail confortables, mais aussi un tas de connards ambitieux paresseux dans le département.

Bon Ă  entendre
S'il y en a plus de deux, c'est la faute. Il y avait beaucoup d'anciens au dernier emploi, cela m'a aidé une douzaine de fois.


L'Ă©quipe


Les équipes sont similaires dans la composition, les tâches, les processus et la pile, et sont complètement indépendantes les unes des autres. Si vous êtes invité dans une équipe qui n'est pas différente des autres, les questions des sections «Équipe», «Tâches», «Processus» et «Empiler» peuvent être posées immédiatement. Sinon, demandez une réunion supplémentaire avec l'équipe après avoir passé l'entretien. Vous ne serez probablement pas refusé. Souvent, une telle réunion est déjà prévue. Passez ensuite immédiatement à la section "Développement".

1. Qui fait partie de l'Ă©quipe?
Analyse
Demandez-vous
Cas 1. Une grande Ă©quipe amicale. Peut-ĂŞtre interfonctionnel.
Plus de communications, plus de réunions et de planification. Êtes-vous un joueur d'équipe?

Cas 2. Vous ferez tout vous-même, ne dépendez de personne.
Un plus large éventail de tâches, une plus grande responsabilité. Vouliez-vous cela?

Cas 3. Il y a des gestionnaires distants.
Il ne s'est pas retourné et a demandé. Et n'allez pas dîner ensemble. Ça va?

Discuter
Si interfonctionnel:
- Que faites-vous s'il n'y a pas suffisamment de testeurs fixes?

Si seuls:
- Qui teste? Combien de jours attendez-vous habituellement pour un testeur gratuit?
- Qui est d'accord avec les plans de gestion?

2. Qui est le client (propriétaire du produit)? Vous avez un chef de projet?
Analyse
Demandez-vous
Cas 1. Un produit avec un fond de développement invalide (oh, mon Dieu!), Ou trop ambitieux, ou inexpérimenté et ne connaît pas bien le produit. Le projet est faible / il n'est pas là / c'est un produit.
Vous protégerez vous-même vos intérêts. Vous pomperez les compétences générales, vous apprendrez à argumenter votre liste de souhaits et à rechercher des compromis. Cela fait-il partie de votre domaine d'intérêt? Êtes-vous prêt pour ça?

Cas 2. Il n'y a pas de produit, pas de projet, pas de chef d'Ă©quipe.
Vous coordonnerez vous-mĂŞme les plans, planifiez l'avancement des travaux. Pouvez-vous y faire face?

Offtop. Les projets ne nous doivent rien. Ils peuvent rendre notre travail plus facile et plus agréable, mais ils ne vous éviteront pas de communiquer avec le produit et ne garantissent pas des tâches intéressantes.

Discuter
- Qui hiérarchise les tâches?
- Qui et comment Ă©value le travail de l'Ă©quipe?

Si ce n'est pas les deux:
- Qui définit les tâches?
- Qui est d'accord avec les plans de gestion?

S'il y a un produit:
- Chaque Ă©quipe a-t-elle son propre produit?
- Combien d'années d'expérience avez-vous? Pour combien d'entre eux travaille-t-il dans l'entreprise? Combien sont dans l'équipe?

S'il y a un projet: tout de mĂŞme sur le projet.

3. À quand remonte la constitution de l'équipe? Combien de personnes sont venues? Voir sans emploi?
Analyse
Demandez-vous
Cela ressemble à une atmosphère amicale? L'entreprise travaille-t-elle à sa création?

Bon Ă  entendre
Déjeuner ensemble. Conduisez ensemble sur konf externe. Organisez des formations et des master classes les uns pour les autres. Cela se produit non seulement dans les grandes entreprises. Ils sont rassemblés par tout le département dans un cadre informel - c'est la faute, ici c'est définitivement convivial. Parce que réunir 5 personnes est difficile, réunir 5+ personnes est presque impossible s'il ne s'agit que de collègues.


Les tâches


Le pool de questions le plus important pour moi. Mais les tâches difficiles ne sont pas une panacée. Je n'y suis pas allé tout de suite.

Premièrement, en temps réel, vous pouvez et devez influencer les tâches que vous résolvez. Le rôle clé est joué par l'initiative et votre feuille de route personnelle (l'avez-vous?).

Deuxièmement, dans n'importe quelle tâche, vous pouvez trouver quelque chose de nouveau et d'intéressant pour vous. Une tâche intéressante n'est pas seulement les nouvelles technologies, la logique complexe, les belles interfaces, le développement architectural. Faites-le vous-même, faites-le rapidement, faites mieux que prévu, mieux que la dernière fois. Inventer, coordonner, refactoriser, enquêter. Dans ce projet, dans le suivant, dans celui que vous venez de créer.

Troisièmement, une équipe cool et une atmosphère agréable nivellent les tâches de routine. Dans la direction opposée, cela fonctionne moins souvent. Ne vous accrochez pas aux tâches. Il vaut mieux ne pas se raccrocher à quoi que ce soit. Fixez des priorités, mais tenez compte de tous les facteurs.

1. Quelles tâches vais-je résoudre?

2. Quelles sont les responsabilités autres que le développement?

3. Quels sont les deux derniers projets réalisés? Quels sont les prochains projets? Comment envisagez-vous de développer le service dans un avenir proche?

4. Quelles tâches de la dernière sont les plus mémorisées, appréciées?

5. De quelles tâches aimeriez-vous vous débarrasser? Que devez-vous supporter maintenant (pas de personnes, pas encore automatisé)?

6. Qu'est-ce que ce dernier a fait pour l'âme, pour le département, des tâches non productives?
Indice
Habituellement, une équipe mène des discussions, ils ont plus de ressources sur leur liste de souhaits ou une carte blanche complète. Demandez au développeur de l'équipe produit ou au plus silencieux.

7. Y a-t-il un arriéré de tâches non productives?
Indice
Parfois, tous les développeurs reçoivent un pourcentage du temps pour résoudre les tâches non productives: dette technique, expériences. Il existe un pool de tâches distinct de la catégorie «décider qui n'est pas paresseux». Ce sont des tâches d'auto-développement et d'assistance aux autres équipes / départements. Souvent, pour eux, il y a un tableau séparé en jir. Si vous êtes intéressé par de telles tâches, évaluez leur pertinence. Cela peut être n'importe quel laitier dans lequel personne ne veut grimper, et il peut y avoir des tâches difficiles que personne ne pourrait ou que tout le monde n'a pas le temps. Demandez des exemples de telles tâches afin de comprendre quelles tâches manquent de mains / de temps / de bénévoles / d'experts.

8. Pourquoi une telle technologie / bibliothèque / cadre est-elle utilisée?
Indice
Clarifiez les tâches résolues à l'aide des outils et technologies clés sélectionnés. Pour savoir dans quelle mesure vous allez travailler avec eux, dans quelle mesure vous devez / les connaître.

9. Combien de pourcentage du temps ces tâches prennent-elles?
Indice
Il est important de comprendre le pourcentage de tâches différentes. Ne demandez pas tout. Estimez le nombre de ceux que vous ne voulez pas décider. Définissez à l'avance des limites confortables.



Les processus



1. Comment vous préparez-vous pour la planification du sprint / trimestre?
Analyse
Demandez-vous
Le produit discute-t-il des projets avec l'équipe avant de compiler les TdR ? Vous souhaitez participer davantage à la phase d'analyse et de développement des exigences?

Discuter
Précisez dans quelle mesure les testeurs participent activement à l'analyse du projet. Les exigences de test affectent directement la qualité des savoirs traditionnels.

Si vous fouillez comme il se doit, spécifiez d'autres aspects de la planification. Seulement de façon ponctuelle, sinon vous obtiendrez une nouvelle version du chapitre d'un livre sur la mêlée.

Bon Ă  entendre
Planification en deux étapes. Discutez de l'objectif du projet. Ils lisent tz, cherchent ce qu'ils ont manqué. Ils examineront le code dans lequel ils monteront (ce code devra peut-être être refactorisé et les bibliothèques devront être mises à jour en cours de route). Les architectes se lancent également dans le Sat: tout d'un coup c'est impossible / faux / c'est possible plus facile / cela existe déjà. Recueillir les exigences pour l'achèvement de l'infrastructure.

Drapeaux rouges
L'Ă©quipe ne se rend pas compte de l'importance de la formation. L'Ă©quipe tombe dans la paralysie analytique.

2. Quelle couverture de code?
Analyse
Demandez-vous
Combien de tests ĂŞtes-vous prĂŞt Ă  terminer lorsque vous appuyez sur?

Discuter
- Combien de pour cent du code est couvert par des tests unitaires?
- Combien de pour cent des fonctionnalités sont couvertes par les tests d'intégration?
- Qui Ă©crit les autotests?

Bon Ă  entendre
Dans un grand projet, je m'attends à 70%, c'est un bon indicateur réalisable. Tous les testeurs manuels n'aiment pas et ne savent pas écrire les autotests: c'est bien si c'est contrôlé.

Drapeaux rouges
Un indicateur bas peut signifier une mauvaise qualité du produit, une irresponsabilité de l’équipe, une folie du manager: «continuez comme ça, puis écrivez des tests» ou «nous n’allons rien mettre à jour». Peut signifier! = Exactement signifie. La couverture du code n'est pas une métrique facile: vous pouvez obtenir un score élevé en couvrant les cas simples au maximum et en ne couvrant pas la logique clé. Les startups ont un faible taux excusable.

3. Qui révisera mon code?
Analyse
Demandez-vous
Cas 1. Tout dans le sujet, 10 relecteurs pour la demande de tirage, tout le monde se soucie de vous.
Vous souciez-vous de tout le monde? ĂŠtes-vous prĂŞt Ă  regarder plus de 5 demandes de tirage par jour?

Cas 2. Timlid examinera votre code s'il reste du temps.
Aucun examen - personne ne dira comment cela devrait, comment il est juste. Savez-vous exactement comment procéder?

Offtop. Un processus de révision du code bien organisé ne garantit pas sa qualité. En termes «nous analysons profondément la logique», mais en fait - 50 messages dans un fil sur une sorte de goût gustatif absurde. Trouvez le minimum nécessaire, mais ne vous précipitez pas vers les conclusions.

Discuter
- Combien votre dernière tâche d'examen a-t-elle suspendu? Il s'éloigna rapidement. Est-ce toujours comme ça?
- Les demandes de tirage ont-elles des priorités?
- Combien de demandes de pull par jour regardez-vous?

Bon Ă  entendre
Les membres de l'équipe sont des réviseurs obligatoires. Obligatoire est quelqu'un qui cherche maladroitement l'architecture. Une demande de tir ne se bloque pas plus de 3 jours sans raison particulière. Les demandes d'extraction abandonnées sont automatiquement supprimées. Les équipes sont guidées dans le code des autres projets, effectuent des revues de code des autres équipes.

Drapeaux rouges
Deux estropiés et demi surveillent votre code.

4. Comment se passe l'assemblage et le déploiement?
Analyse
Demandez-vous
Cas 1. CI / CD, tout est automatisé.
En règle générale, les administrateurs / développeurs font de l'automatisation. Mais ils peuvent vous attirer. Ne pisse pas?

Cas 2. Tout Ă  la main.
Collectez vous-même les packages, liez les tâches, créez les tâches de publication, contrôlez l'acceptation. Êtes-vous normal ou vous êtes-vous déjà mis en colère?

Discuter
- L'Ă©quipe a-t-elle son propre banc d'essai?
- Combien de temps faut-il pour créer un nouveau stand avec un environnement spécifique?
- Qui sort? Qui est responsable?
- Combien de temps a pris votre dernière version?
- À quelle fréquence relâchez-vous?
- Si la sortie tombe Ă  22h, quel est le plan d'action?

Bon Ă  entendre
CI / CD est configuré au maximum: l'assistant est coupé selon le commit / planning, et le schéma peut être créé par le bouton. L'équipe a son propre banc d'essai et personne n'y va. L'administrateur va rouler, mais vous êtes responsable. L'entreprise le comprend et n'en cherche pas à blâmer.

Drapeaux rouges
Beaucoup d'opérations de routine. Beaucoup de sorties, mais les conditions ne sont pas adaptées.

5. À quelle fréquence passez-vous rétro?
Analyse
Demandez-vous
Aimez-vous le format? Par exemple, je suis enragé par le rétro dans un format de jeu.

Discuter
- Combien de temps a duré la dernière réunion?
- Combien de personnes sont venues?
- Qu'avez-vous réussi à découvrir?
- Que comptez-vous en faire?
- Qu'a amélioré le dernier grâce au rétro?
- Qu'est-ce qu'un indicateur d'efficacité d'équipe?

Bon Ă  entendre
Planifié rétro, plus souvent - mieux. Il y a un plan et un calendrier serré. Il y a tous ceux qui ont participé aux projets en discussion, et pas seulement l'équipe. Les résultats sont enregistrés, des conclusions sont tirées, des actions concrètes sont prévues pour améliorer la situation. Les résultats de ces actions sont suivis.

Drapeaux rouges
Le rétro n'a lieu que dans le cas du fakap. Cela dure plus de deux heures, cela signifie que la discussion n'est pas structurée, ils ne se préparent pas pour le rétro, les holivars sont élevés. Personne ne contrôle la mise en œuvre des décisions prises.

6. Quand pratiquez-vous la dette technique?
Analyse
Demandez-vous
Le manager / produit / manager comprend pourquoi cela est nécessaire? Que fait-il pour ne pas s'enliser dans les dettes techniques? Que font les développeurs eux-mêmes pour cela?

Discuter
- Qu'est-ce que le dernier refactor?
- Quelles tâches non productives avez-vous prises ce trimestre?

Bon Ă  entendre
La dette technique est ratissée comme prévu. Considéré dans la planification. Un temps fixe (% du temps de travail / partie du sprint) est alloué pour améliorer la base de code, les expériences, l'initiative. La complexité du code est analysée automatiquement.

Drapeaux rouges
Le backlog produit n'est pas différencié de la dette technique.


Pile


N'essayez pas de comprendre l'ensemble du système: monoreps, microservices, sur quoi et pourquoi, comment ils sont amis. Eh bien, si vous comprenez tout cela en travaillant. En matière de sécurité sociale, il suffit de savoir quelle logique est écrite sur quoi, où elle se trouve et qui la soutient.

1. Sur quoi est écrit l'héritage?
Analyse
Ask yourself
?

Discuss
— ?
— , ? Pourquoi? ? ?
— - ?

Good to hear
. — . — , . — , ( ).

Red flags
« , ».

2. Pourquoi (pas) choisi une technologie / bibliothèque telle ou telle?
Analyse
Ask yourself
1. .
?

2. // .
?

3. / .
, ? - ? ?

Discuss
— ?
— ?
— ?
— ? ?
— / ?
— ? ?

Good to hear
. , . . .

Red flags
, . . .

3. Quelles technologies ont été mises en œuvre au cours des six derniers mois / an?
Analyse
Ask yourself
? ? , ?

Discuss
— , - ? Pourquoi?
— , - , ? Pourquoi?

Good to hear
, //, .


DĂ©veloppement


Juin est plus facile à développer: toute la zone est un champ non labouré, une responsabilité moindre, l'initiative sera remarquée et encouragée. C'est plus difficile pour l'aîné: plus élevé que prévu, il est plus difficile de les justifier, certaines conditions sont nécessaires à la croissance et une évaluation adéquate est nécessaire pour la croissance. Plus le niveau est élevé, plus cette section est importante.

1. Qui m'évalue? Quels sont les critères?
Analyse
Ask yourself
? ?
? ?
?

Good to hear
, .

. : , , , -, -. , .

Red flags
- . . : . , .

2. Qu'est-ce que l'Ă©valuation influence? Qu'est-ce qu'une note affecte?
Analyse
Ask yourself
?
?

Good to hear
( ) : , , . . , .

Red flags
, .

3. Est-il possible de passer Ă  une autre Ă©quipe?
Analyse
Ask yourself
, , , . ? , ?

Discuss
— ?
— (, )?
— ( )?

Good to hear
. .


Les attentes


"Qu'attendent-ils de moi?" - une question très importante. Si vous posez la question sur le front, vous obtiendrez la norme «faire face aux tâches, faire beaucoup, s'entendre avec l'équipe». On essaie pas dans le front.

1. Pourquoi les gens ont-ils besoin d'une Ă©quipe?

2. Quel spécialiste manque à l'équipe? Quelles sont les compétences difficiles qui manquent aux gars de l'équipe? Quel genre d'expérience manque?

3. Quelles tâches personne ne doit transférer? Pourquoi?

4. Quels sont les spécialistes qui manquent dans le département en plus des chefs d'équipe?

5. Que faut-il faire pour dépasser vos attentes? Donnez un exemple de tâches.

6. Quels doutes subsistaient sur mon compte?

7. Quelles seront certainement les difficultés au départ?

8. Quelles tâches me confierez-vous au début?

9. Un conservateur me sera-t-il affecté? Pour quelle période?


Offtop


Questions personnelles. La réunion devrait être intéressante pour les deux parties. Donnez à une personne l'occasion de parler de ce dont elle est fière, de ce qu'elle a accompli et de partager son expérience. Tout le monde aime se parler. C'est rentable pour vous. Premièrement, si vous parlez à votre interlocuteur, vous pouvez poser des questions inconfortables et incriminantes. Deuxièmement, vous l'aimerez et vous vous souviendrez de lui, voulez-vous passer par la sécurité sociale? Troisièmement, la communication avec un mec cool est une raison distincte d'aller à la sécurité sociale.

1. Travaillez-vous ici depuis longtemps? C’est beaucoup. Qu'est-ce qui est si accrocheur?

2. Et oĂą travaillait-il auparavant? Et que reste-t-il?

3. Qu'avez-vous appris au travail au cours de la dernière année?

4. Combien d'heures par jour codez-vous? Que prend le reste du temps? Restez Ă  la maison pour plier?

5. À quelle heure venez-vous au travail? À quelle heure divergent-ils tous?

6. OĂą puis-je travailler en dehors du lieu de travail? OĂą sortez-vous habituellement?

7. Utilisez-vous vous-même votre service? Qu'aimeriez-vous y améliorer? Vous avez essayé de le déposer dans le produit? Pouvez-vous influencer le développement du service? Qu'en est-il des décisions concernant les produits? Avez-vous réussi à pousser quelque chose? Dis moi.

8. Quelles mesures suivez-vous?

9. Comment garantissez-vous la sécurité?


Si le chef d'équipe / intervieweur est interviewé:

1. Quels processus ne sont actuellement pas satisfaits?

2. Sur quoi prévoyez-vous travailler dans un avenir proche? Quelles sont les priorités?

3. Mentorer quelqu'un du département?

4. Comment gérez-vous le manque de chefs d'équipe?


Comment finir


Avez-vous souvent des conversations? Cela prend-il beaucoup de temps?

Alors je ne te retiendrai pas. Merci pour votre temps. J'étais très intéressé par toi. J'espère que nous ne nous disons pas au revoir;)



Questions farfelues


Ils relèvent de la définition de "une question supplémentaire" (voir l'algorithme dans "TL; DR"). J'offrirai quoi remplacer. Si vous voulez, utilisez ces questions, vous savez mieux. Dans des cas spécifiques, ils fourniront les informations nécessaires. Convient pour "démarrer une conversation". J'ai commencé à m'en passer.

1. Qu'êtes-vous meilleur que vos concurrents ( USP , avantages compétitifs)?
2. Qui finance les projets (investisseurs clés)?
3. Quelles difficultés rencontrez-vous actuellement?
4. Quels sont vos plans pour l'année à venir?
Pourquoi pas. Les réponses peuvent être google. S'ils ne sont pas accessibles au public, ils ne vous accorderont pas d'entretiens. Les recruteurs sont vendeurs, ils ne diront pas la vérité inconfortable.
Solution Elle sera informée des rapports financiers (si la société est publique).

5. Le recyclage est-il payé?
Pourquoi pas. Ils ne devraient pas l'être. S'ils le sont, ils diront qu'ils ne le sont pas. Si c'est la norme, ils diront qu'ils paieront. En fait, cela pourrait être différent.
Solution Trouvez une entreprise où vous n’avez pas à poser cette question. Si vous ne prévoyez pas d'amasser des fonds pour le traitement.

6. Combien de chefs d'Ă©quipe / experts / experts? Que font-ils?
Pourquoi pas. Le leadership d'équipe dans chaque équipe est excellent, mais c'est peu probable. Ils sont toujours en nombre insuffisant. Vous en apprendrez plus sur votre chef d'équipe en discutant de la composition de l'équipe. Idéalement, ceux qui sont plus âgés passent une partie du temps à résoudre des tâches non productives. S'il s'agit d'exigences formelles, elles peuvent ne pas être respectées.
Solution Si vous êtes interviewé par un chef d'équipe, posez des questions ciblées (voir la section «Offtop»).

7. Qui est mon supérieur hiérarchique? Que fait-il? Comment ça vous plait?
Pourquoi pas. Vous n'analysez pas les qualifications du responsable. Le développeur n'évaluera pas le leadership avec vous. Si c'est le cas, il ment ou est biaisé.
Solution Si cela est particulièrement important pour vous, demandez à organiser une rencontre personnelle avec le leader. S'il vous interviewera, posez des questions ciblées (voir la section «Offtop»).

8. Comment évaluez-vous les tâches?
Pourquoi pas. Il y a une échelle d'évaluation en points historiques et il y a une vitesse. Vous n'analyserez pas leur exactitude et leur adéquation lors d'une entrevue. L'évaluation en jours ne montrera pas la qualité de la décomposition - les cas suspects ne seront pas exprimés. Les tâches sont prioritaires. La qualité de la priorisation que vous n'analyserez pas pour l'entretien.
Solution , :
— « ?»‎ Good to hear: planning poker, , , , .

9. ? ?
Why not. . . , .
Solution. ( ):
— « ? ? /?»‎
— « / ? ?»‎

10. ?
Why not. , ? ? .
Solution. :
— « ? / / . ?»‎

11. ?
12. ?
Why not. , .
Solution. :
— « ? ?»‎
— « , ?»‎

13. ?
Why not.Les commentaires sur demande sont partout. Souvent uniquement sur demande. Je crois que de telles réunions devraient se tenir comme prévu, mais vous ne savez jamais ce que je pense.
Solution S'il y a un problème, ne le gardez pas pour vous.

14. Je signale un problème dans une revue. Comment sera-t-il résolu?
Pourquoi pas. Une grande chance d'obtenir une réponse socialement attendue. Si vous communiquez avec votre chef d'équipe / chef d'équipe, discutez de cas spécifiques.
Solution Peut-ĂŞtre que cela aidera:
- «Le produit ne permet pas d'effacer la dette technique. Il a tort. »Bon à entendre: des actions concrètes sont prévues pour résoudre le problème. «Je vais lui parler» est mauvais. "Je vais planifier, évaluer la situation et aider à trouver un compromis" - bien.

15. L'entreprise m'achètera-t-elle un logiciel pour le travail?
Pourquoi pas.Bon achètera, mauvais - non. Vous comprendrez le bien ou le mal sur d'autres sujets. Ils achèteront une licence pour l'IDE, ils sont eux-mêmes intéressés. Si vous avez besoin de quelque chose de spécifique et de cher, posez une question ciblée.
Solution Par exemple:
— « Wallaby. , … ?»‎
— « . . ?»‎

16. ? ?
Why not. , . , . . — , — .
Solution. ( ) - ( ), (. «»‎).

17. ? ?
Why not. . , . .
Solution. :
— « ? ?»‎

18. ?
19. ?
Why not. , . - .
Solution. :
— « ( //), ?»‎
— « , ?»‎

20. Si le plan n'est pas réalisé, comment seront-ils punis?
Pourquoi pas. Personne ne viendra te frapper au chapeau. Le bonus maximum sera privé. Spécifiez le prix séparément.
Solution Trouvez une entreprise où vous n’avez pas à poser cette question.

21. Microservices ou monorepa? Comment en êtes-vous arrivée à une telle architecture?
Pourquoi pas. Le projet perdure, les exigences changent, le monorepa est tiré dans des microservices, parfois vice versa, mais pas nécessairement et pas tous. Aujourd'hui est ainsi, demain est différent.
Solution Si vous recherchez une architecture et "juste curieux" - précisez. Vous savez vous-même quoi clarifier.

22. Comment les développeurs apprennent-ils les plans et les réalisations de l'entreprise?
Pourquoi pas.Newsletter obligatoire, rencontres avec le directeur, une présentation avant la nouvelle année, un blog sur Habré, le produit envoie des retours des utilisateurs au chat général - que ce soit quelque chose.

23. Pourquoi avez-vous décidé de passer au kanban?
Je pense que c'est une question utile, mais je ne sais pas comment analyser la réponse.


5 règles


Pour ceux qui ont lu.

  1. S'il vous plaît aller au « vous » chaque fois que possible.
  2. Rappelez-vous les noms. Un appel de nom est +100 au karma.
  3. Ne l'ignorez pas. Demandez à tout le monde de poser des questions personnelles: ils seront offensés d'avoir posé des questions à tout le monde, mais ils ne l'ont pas fait.
  4. Ne vous laissez pas charmer. Une agréable conversation amicale peut être un pot-de-vin. Les personnes interrogées sont du côté de la vente, donc tout est si bon et si bon. Vous serez surpris de voir à quel point cela peut vous rapprocher de la mauvaise décision.
  5. Ne pensez Ă  rien, concentrez-vous sur les faits. Soyez vigilant.


Le point le plus important


Une interview est une conversation, pas un interrogatoire. Les questions ne sont que des points de référence pour cette conversation. Où vous l'emmenez, vous recevrez.

La tâche principale est de découvrir l'adéquation des exigences, la coïncidence des désirs et des opportunités, à quoi s'attendre dans un nouvel endroit, à quoi ne pas s'attendre. Pressez le maximum d'informations pour faciliter la prise de décision. Pour tout le reste, il y a une période d'essai. Je vous souhaite de faire le bon choix.



Vous êtes également apprécié pour vos questions. Laissez une bonne impression de vous.

Et le dernier. Avez-vous écrit du code sur un compte de sécurité sociale? Joel n'était pas un idiot. Les entretiens sans code ne sont pas les meilleurs entretiens d'embauche. Que ce soit notre dernier critère pour évaluer l'entreprise.

Source: https://habr.com/ru/post/fr468923/


All Articles