Devenir un responsable technique senior – Le blog Coinbase


Jesse: Hé! Nous allons donc avoir une conversation informelle pendant une heure sur la façon dont vous êtes arrivé où vous êtes aujourd'hui. Et j'aimerais commencer, qu'avez-vous fait avant Coinbase?

Miguel: Juste avant Coinbase, je dirigeais le côté technique d’une startup; un début de retour client à entreprise. Similaire à UserVoice. Cela m'a aidé à m'apprendre à gérer moi-même le travail technique.

Jesse: Quelle était la taille de l'équipe?

Miguel: Deux personnes. Je pense qu'une fois que les défis techniques ont disparu, je suis devenu moins intéressé par la start-up. Je cherchais donc des opportunités. Auparavant, il travaillait principalement pour le gouvernement. Mon projet principal était une application de visualisation des sciences de la Terre qui a développé OpenGL et Java. Principalement la programmation de bureau. Nous avons utilisé WebGL à la fin, mais nous avons surtout créé une application de bureau sous Eclipse RCP et OpenGL pour la visualisation. C'était donc intéressant. Et puis, avant cela, je travaillais pour un petit consultant web C #.

Jesse: Un avantage important de faire le départ?

Miguel: C'est difficile. Il est particulièrement difficile de travailler très fort sur quelque chose et de ne pas recevoir de paiement.

Jesse: Ils ne vous ont pas payé?

Miguel: Oui, ils ne nous ont pas payés pendant deux ans. Les défis techniques m'ont beaucoup motivé et j'ai également vécu dans une belle ville. Donc c'était bien. Mais dans un instant, je pensais que je ne pouvais plus le faire.

Jesse: Et en dire plus sur les défis techniques? Quels ont été les défis techniques?

Miguel: Je devais tout résoudre: comment nous avons implémenté dans AWS, comment créer du back-end, comment interagir avec le data warehouse. Nous avons utilisé Ember dans le front-end et j'étais tout à fait nouveau dans les applications front-end. Donc, apprendre à créer une application de l'infrastructure à l'interface, du début à la fin. Et puis, les autres défis étaient de savoir comment sortir et comment lancer cette application. C'était le travail qui était beaucoup plus difficile pour moi. Je comptais principalement sur mon partenaire commercial pour cela.

Jesse: Quel a été le moment le plus difficile?

Miguel: Je pense que c'était difficile de laisser tomber. C’était quelque chose que nous avions travaillé dur pendant deux ans et nous avons vraiment essayé de le vendre. Nous avons eu un peu de traction, mais cela ne valait pas la peine de continuer à pousser. Je pensais que la plate-forme était techniquement assez bonne, donc partir a été difficile.

Miguel: De plus, c’était vraiment le moment idéal pour être disponible; J'ai dû prendre l'avion pour SF afin d'interviewer Coinbase et y travailler pendant une semaine. Si j'avais un travail normal, je ne l'aurais probablement pas envisagé. Donc, j'étais vraiment préparé pour ça.

Jesse: Et que cherchiez-vous lorsque vous avez commencé à chercher un emploi?

Miguel: J'ai grandi en Australie et Il avait toujours voulu travailler aux États-Unis. La culture de travail ici est différente. À l'université, j'avais rencontré des personnes qui avaient travaillé dans la Silicon Valley et j'ai été impressionné. Travailler dans un autre pays a toujours été un rêve. Et puis, vers la fin du voyage de retour à la maison, la crypto-monnaie s’intéressait beaucoup à moi et Coinbase cherchait des personnes à Reddit. Je n'avais aucune idée de Coinbase à cette époque, la société en particulier ne m'intéressait pas, j'aimais simplement la crypto-monnaie.

Jesse: Donc, vous ne connaissiez pas Coinbase avant de voir un fil de Reddit à la recherche d'ingénieurs?

Miguel: Oui, c'est Brian qui a publié. Même quand je me suis approché, j'ai pensé: "ils ne semblent pas si légitimes". Ensuite, une fois que j'ai commencé le test de travail, j'étais super exagérée. Cette première chance m'a peut-être aidé, car j'étais moins nerveux.

Jesse: Alors parlez-moi de l'épreuve de travail? Qu'as-tu fait?

Miguel: J'ai travaillé avec New Relic. Passer en revue nos principales transactions, en les rendant plus efficaces et en trouvant des goulots d'étranglement.

Jesse: Vous travailliez donc sur notre application monolithique Rails? Avez-vous déjà travaillé dans Ruby ou Rails?

Miguel: Non, je n'ai jamais vu Ruby et je n'ai jamais utilisé New Relic. Je n'ai jamais utilisé Redis ou Mongo ou quoi que ce soit du genre auparavant, tout était nouveau.

Jesse: Comment avez-vous progressé dans cela?

Miguel: Je pense que je voulais juste faire un bon travail, alors j'ai travaillé de nombreuses heures et je me suis assuré d'avoir quelque chose à montrer. Il avait pour objectif quatre transactions améliorées. C'était un processus très méthodique. Vous pouvez aller à New Relic et jeter un coup d’œil sur les différentes traces et voir où en étaient les choses.

Jesse: Quel a été le résultat final?

Miguel: Différents points de terminaison posaient différents problèmes. Nous en avons trouvé un qui avait 100 appels Redis alors qu'il aurait dû en être un; C'était une requête n + 1. C'était une question intéressante que je pouvais mettre dans la présentation à la fin et montrer la chute dans le graphique. J'ai trouvé ça très drôle. Il a parlé avec le responsable du recrutement avant l'examen du travail et a déclaré: "Qu'est-ce qui vous intéresse?" Et j'ai mentionné "J'aime beaucoup optimiser le code", mais jamais auparavant dans un contexte Web. Alors j'ai sauté sur ça et je pense que ça m'a vraiment plu et j'ai continué à le faire quand j'ai commencé.

Jesse: Ensuite vous avez commencé, quel niveau avez-vous entré? Quelles étaient vos attentes à venir?

Miguel: Oui, j'ai commencé comme IC4. Un ingénieur de niveau intermédiaire. Je n'avais jamais travaillé aux États-Unis auparavant. UU., Donc je ne savais pas à quoi m'attendre. Je m'attendais à être vraiment mis au défi, n'ayant aucune expérience de ces technologies. J'ai mentionné que la culture est différente. Et je n'avais vraiment pas l'impression d'appartenir au premier mois environ. Le syndrome lourd de l'imposteur.

Jesse: Comment vous sentiez-vous?

Miguel: J'ai dit à ma femme: "Ils me vireront à tout moment." C'était toujours si neuf. Mais c'est aussi très excitant. Nous étions une jolie petite équipe.

Jesse: Quelle était l'équipe?

Miguel: Nous étions quatre personnes et nous étions responsables de Coinbase.com, le site Web. L'API, le backend et le front-end.

Jesse: Quel a été ton rôle dans l'équipe?

Miguel: J'ai été embauché en tant qu'ingénieur de pile complet pour travailler sur l'application Web. J'ai fait quelques trucs frontaux, j'ai travaillé un peu sur les graphismes, mais j'aimais davantage le côté backend des choses. Parce que je réfléchissais à la performance sur une base hebdomadaire, certaines choses ont commencé à se démarquer et je suis devenu de plus en plus impliqué dans le travail sur les plateformes de niveau inférieur. L'une de mes premières tâches a été l'API de portefeuille. Pour ce faire, je devais exécuter une migration dans nos données de transaction historiques depuis le début des temps pour modifier leurs identifiants. Cela a pris environ trois mois pour vraiment le faire. C'était difficile et nous avons fini par nous engager. Nous avons travaillé à 20% pour obtenir 80% des résultats. Il y avait une erreur au début, ce qui voulait dire que je devais refaire toute l'agrégation, mais après ça a très bien fonctionné.

Jesse: Assez impressionnant Parlez-moi pendant vos six premiers mois. Les choses sont devenues folles, comment c'était?

Miguel: J'ai commencé le 1er février. En mai, Ethereum a commencé à exploser. J'ai donc eu 4 mois pour apprendre Ruby et notre application monolithique Rails et découvrir comment les choses fonctionnent. Ensuite, Ethereum est devenu fou et nous avons eu des problèmes d'escalade. C'était notre objectif principal. Nous avons eu des défis Redis et Mongo, et une fois que cela est arrivé, tout mon travail sur les produits était essentiellement à la porte. Je travaillais toujours sur le produit, ils m'avaient encore attribué ces tâches, mais finissaient par glisser. C’était une partie difficile, c’était comme si mon rôle avait changé sans que ce soit explicite.

Jesse: Parlez-moi de ça.

Miguel: Notre équipe était composée de sprints travaillant sur les produits. Il s'agissait d'un travail d'échelle difficile à hiérarchiser car il ne contribuait pas vraiment à l'un des objectifs de nos produits. Je devais donc simplement dire à l’équipe «c’est ce sur quoi je travaille cette semaine», et j’avais parfois l’impression de décevoir les gens parce que je ne travaillais pas sur les éléments du produit qui ont motivé l’entreprise. Et je me souviens d'avoir dit cela explicitement aux gens. Donc, je pense que c'était compliqué. Ne pas avoir des objectifs explicites pour résoudre ce problème.

Jesse: Alors, pourquoi as-tu fait ça? Pourquoi avez-vous effectué le travail de mise à l'échelle au lieu du travail du produit?

Miguel: J'avais peur. Je savais que nous avions des problèmes et cela semblait être l'effet de levier le plus important.

Jesse: Cela ressemble donc à une crise semblable à celle de Brian, notre PDG, "mode guerre". Partir au jour le jour pour être un collaborateur efficace et faire face à un défi énorme inconnu et qui pourrait aider à résoudre.

Miguel: Oui, et ce groupe de personnes qui se sont rencontrées, nous étions très proches et nous étions très concentrés sur cet objectif singulier de pouvoir servir plus de clients. Et comme nous sommes toujours dans ce mode de guerre, cela nous a vraiment unis en tant que groupe de personnes. C'était super amusant

Jesse: Dans le changement de ce service, quel était le plus difficile et le plus amusant?

Miguel: Vous pourriez dire que les heures étaient difficiles, car nous avons passé de longues heures à lutter contre ces difficultés d'escalade. Mais ils étaient aussi très drôles. Je pense que personne n’aurait abandonné cela pour le monde. Nous voyions des choses que nous ne reverrions probablement plus jamais dans notre vie, des défis de cette ampleur, tout le monde voulait y être, peu importe la difficulté.

Jesse: Et quel était votre rôle dans ce groupe de personnes? Comment cela a-t-il changé de mai à janvier, après la fin de la plupart des problèmes d'escalade?

Miguel: Je ne sais pas. Je ne sais pas si je me vois différent des autres membres de cette équipe. Peut-être y a-t-il eu une partie où j'aurais poussé un peu plus ou un peu plus de poids, mais je ne suis pas sûr.

Jesse: Dites ah. J'étais là et j'ai l'impression que vous êtes le chef, du moins d'un point de vue technique. Il y avait un groupe de personnes importantes, mais quand la merde a mal tourné, ils se sont tous dit: "Où est Michael?"

Miguel: Oui, je pense me souvenir de certains de ces moments. Je pense qu’il est très important d’être capable de penser de manière méthodique et pratique pendant les incendies. Dégagez votre esprit et ne paniquez pas, mais soyez capable de penser clairement afin de pouvoir trouver les causes principales du problème ou de trouver des solutions réellement innovantes.

Jesse: Et puis la folie a pris fin en janvier et que s'est-il passé ensuite?

Miguel: Après janvier, nous avons mis en place cette équipe de performance et de fiabilité; Nous avons finalement pris cet équipement implicite et l'avons rendu explicite. Et les personnes qui y sont ciblées. Je pense que cela a été très utile car nous avions enfin quelque chose à dire sur ce que nous pouvions mesurer nous-mêmes. Et nous avions un énoncé de mission pour notre équipe.

Jesse: Comment pensez-vous qu'il l'a fait? Comment pensez-vous que cette équipe l'a fait?

Miguel: Nous avions ces métriques que nous essayions de corriger et, comme elles étaient faciles à mesurer, nous pouvions explorer certaines solutions pour les déplacer beaucoup. Certains des moments les plus excitants sont ceux où vous effectuez un changement, que vous mettez en production et que vous visualisez ces graphiques en plongée. Nous avons donc toujours poursuivi l'émotion de ce sentiment. Chaque fois que nous faisions quelque chose comme ça qui réussissait, nous faisions de Coinbase un endroit plus sain. Avant cette équipe, la plate-forme était un peu ponctuelle. Et maintenant que nous avions quelqu'un qui se concentrait sur ce travail à plein temps, nous pouvions penser non seulement à la performance, mais également à la création d'outils pour que les personnes soient plus en sécurité. Comment pouvons-nous rendre notre application monolithique Rails plus sûre? Je vois ces choses comme réussies et je pense que sans cette équipe, nous n’aurions pas pu faire pression, nous aurions principalement travaillé sur le produit.

Jesse: Et quel était votre rôle dans cette équipe?

Miguel: J'étais un technicien à la tête de cette équipe et les deux autres membres de l'équipe me soutenaient. Traçage de la direction de cette équipe d'un point de vue technique. Découvrez quelle était la chose la plus importante avec laquelle travailler. C'était la première fois que je commençais vraiment à comprendre comment résoudre les problèmes à un niveau supérieur à celui du code. J'apprenais à penser à un niveau supérieur, puis à communiquer l'importance des problèmes et du travail que nous voyions. Et contactez l'entreprise: hé, c'est vraiment important, voici pourquoi c'est si important, pourquoi ne pas investir dans ces domaines serait une erreur. Travailler et communiquer à ce niveau était un nouveau défi, mais je pense que nous avons fait beaucoup de progrès. Entre temps, notre équipe SRE avait été formée du point de vue de l’infrastructure et les travaux liés aux performances se chevauchaient beaucoup. Nous avons donc décidé de fusionner l’équipe de performance et de fiabilité avec celle de SRE. Mais je suis resté chez Consumer dans un rôle d’équipe général, vous rendant directement compte.

Jesse: Vous avez vraiment prouvé que vous pouviez penser à un niveau élevé des problèmes les plus importants à résoudre. Je voulais votre aide pour résoudre certains des problèmes les plus importants que nous ayons rencontrés au niveau organisationnel. Je recherchais un partenaire capable d'assumer le leadership technique au sein de Consumer. Comment était ce changement?

Miguel: Oui, je ne savais pas dans quelle direction j'allais aller. Je ne savais pas sur quoi j'allais travailler. Donc, j'étais très nerveux à ce sujet. Ce n’était pas clair, mais j’étais aussi excité d’avoir le temps libre pour réfléchir aux initiatives inter-équipes et repérer les domaines les plus problématiques, ou les plus pénibles, pour ensuite me concentrer sur ces domaines.

Jesse: Vous avez eu un rôle dans lequel vous n'étiez pas rattaché à une équipe, c'était très incertain et vous avez eu peur. Face à cette peur, qu'as-tu fait?

Miguel: Semblable à ce que je faisais avant. Essayez juste de trouver l'endroit où la douleur est. Ensuite, découvrez comment résoudre ce problème. L'une des premières choses sur laquelle j'ai mis l'accent était le processus d'examen technique par le consommateur. C'était quelque chose qui était une équipe croisée et avait un impact important sur la qualité de l'ingénierie chez le consommateur. À l’avance, il n’ya pas eu beaucoup de réflexion ou de discussion sur les décisions architecturales pour les projets nouveaux ou existants. Ainsi, l'ajout d'une fonction de forçage permettant aux ingénieurs de décrire ces décisions dans un document technique, puis de les revoir avec un groupe, s'est avéré très utile.

Jesse: Cela ressemble à un problème culturel que vous avez résolu. Nous avons beaucoup parlé de problèmes techniques. Quand avez-vous commencé à penser à la résolution de problèmes culturels ou organisationnels?

Miguel: Les choses me frustrent beaucoup et je voulais ensuite prendre l’initiative ou les approprier, comme lors de l’entrevue.

Jesse: Quelle était l'entretien?

Miguel: Nous savions que l'écran de la technologie avait fui, nous n'interviewions donc que ces candidats avec cet écran de la technologie que la moitié des candidats connaissaient clairement. Nous avons trouvé des candidats qui avaient la réponse dans un autre onglet. Et personne n’en était réellement le propriétaire ou n’en assumait la responsabilité. J'ai vu la douleur là-bas et je voulais aider. J'ai donc commencé à construire un nouvel écran technologique et à former l'organisation à l'utiliser.

Jesse: Il semble donc que vous voyiez quels problèmes techniques ou d’organisation vous posaient le plus de problèmes et que vous ne vouliez pas savoir quels problèmes vous avez résolus.

Miguel: Oui je crois bien. Prendre une initiative dans les choses, et ne pas attendre qu'on les demande ou attendre que les choses empirent au point que quelqu'un d'autre les résolve, est un élément très important de cela.

Jesse: Oui, bien dit. Alors, dans ce nouveau rôle dans lequel vous étiez flottant et sans toucher d’équipe, quelle a été la partie la plus difficile et la plus amusante?

Miguel: C'est difficile de ne pas avoir une équipe. J'avais l'habitude d'avoir des gens autour de moi pour échanger des idées et travailler avec eux. Des personnes avec qui je pourrais partager le fardeau si je me sentais dépassée et faire de même pour elles. Et puis découvrir comment gérer mon temps a probablement été le plus difficile. Nous pouvons faire tellement de choses et découvrir à quel point l'établissement des priorités est vraiment difficile. La partie la plus amusante? Pouvoir participer davantage à la future forme de Coinbase. Je trouve cela très enrichissant et agréable.

Jesse: Quel conseil donneriez-vous à quelqu'un qui est actuellement ingénieur principal dans une équipe et qui veut avoir un impact plus important au niveau organisationnel?

Miguel: Comme je l’ai déjà dit, être au courant de la douleur de l’équipe transversale ou de l’organisation, puis prendre l’initiative de la résoudre, est une chose que tout le monde apprécie. Nous ne pouvons pas avoir assez de cela. Tout comme le processus d'entrevue, comment créer des outils dans Monorail pour rendre les spécifications plus rapides ou moins complexes, ou tout ce qui améliore la vie de vos coéquipiers ou la santé de l'organisation. J'insiste vraiment là-dessus et prends l'initiative que je considère être le meilleur conseil.

Jesse: J'adore ça. Y a-t-il quelque chose que vous auriez fait différemment pour arriver ici?

Miguel: Oui, j'ai toujours besoin d'améliorer la communication, surtout lorsque j'ai commencé à travailler en équipe. Plus la taille de l'équipe est grande ou plus votre portée est grande, plus la communication est interrompue. Et c'est quelque chose sur lequel je dois encore travailler. Assurez-vous que les bonnes parties prenantes sont présentes dans la salle, faites-les accepter et communiquez les choses de manière claire et générale.

Jesse: Qu'est-ce que vous réalisez maintenant que vous ne réalisiez pas quand vous travailliez à votre niveau avant de commencer?

Miguel: Je pense que c'est la communication. Il est beaucoup plus difficile de faire avancer les choses quand il y a plus de personnes intéressées par les décisions. Même lorsque vous pensez que quelque chose est évident pour vous, les autres personnes ont de très bonnes opinions à ce sujet et vous expliquent pourquoi vous vous trompez. Découvrir comment naviguer est une leçon constante.

Jesse: Sur quoi travaillez-vous en ce moment?

Jesse: Donc, je travaille sur deux choses. La première est la voie pavée de l'API: créer un moyen cohérent et compatible de créer une API dans Coinbase. Découvrez comment nous le faisons en interne, comment nous le faisons en externe. Différentes équipes ont actuellement différentes manières de coder les API et présentent les avantages réels d’une approche cohérente. La seconde consiste à créer en tapant dans notre application monolithique Rails, en Ruby. Alors que nous commençons à examiner notre application monolithique Rails et à diviser les choses, il est nécessaire d'accroître la sécurité. Avoir des types vous permet de raisonner davantage sur votre code.

Jesse: Comment est votre horaire quotidien?

Miguel: Je suis probablement dans 40% des réunions? J'essaie de bloquer les mercredis, puis les lundi et jeudi matin. Slack m'a beaucoup aidé et beaucoup de gens m'ont posé des questions sur notre application monolithique de Rails. Il me semble donc que la plupart de mes travaux techniques sont effectués en dehors des heures de travail. C'est une autre chose qui a été vraiment difficile en réalité. Plus vous en saurez sur les systèmes, plus ils vous poseront de questions. Et il est difficile de vraiment se concentrer sur un problème quand on continue à poser des questions. Mais c’est aussi un excellent moyen de libérer les gens: c’est quelque chose de bon, c’est quelque chose que je dois continuer à apprendre à gérer. En outre, c'est comme une impulsion. Si un groupe de personnes dit "J'ai vu ce problème récemment", il est clair qu'il y a quelque chose à réparer.

Jesse: Oui, intéressant De quoi êtes-vous vraiment fier?

Miguel: Je suis vraiment fier de deux choses. Obtenir le sorbet dans notre application monolithique Rails est vraiment excitant: il s'agit d'une nouvelle technologie et d'un nouveau produit inaccessibles pour une grande partie du monde et qui suscitent l'enthousiasme des gens. Je m'intéresse aux langues, alors avoir des polices statiques est vraiment génial. Ensuite, le processus de redimensionnement de MongoDB, puis de présentations sur le travail. Je suis aussi fier de ça.

Jesse: Incroyable, merci pour votre temps. Soyez reconnaissant pour les deux dernières années que nous avons passées ensemble.

Miguel: Moi aussi!