1. Запланируйте сеанс кодовой клавиатуры на 10 утра буквально на следующий день после 7-месячной поездки, когда 100% вашего мозга было сосредоточено на изучении испанского языка.
  2. Назначьте телефонное собеседование на час позже, чтобы вы все еще волновались и пытались решить проблему №1 в своей голове, разговаривая с менеджером по найму другой компании.
  3. Запланируйте встречу с компанией, которая вам больше всего нравится, * первой *, не давая себе гораздо больше времени, чтобы освежиться в памяти после катастрофы в №1.
  4. По сути, столькими словами можно сказать нескольким стартапам, которые пытаются создавать микросервисы, что, судя по вашему опыту, им, вероятно, не следует делать микросервисы.
  5. Убедите другой стартап настолько тщательно в важности DevOps, что он решит пойти с кем-нибудь с большим опытом DevOps.
  6. Полностью соблюдайте правила собеседования на месте, а затем, практически, на выходе, скажите интервьюеру, что единственный реальный недостаток - это поездка на работу, что оставляет неприятный привкус во рту - в стиле Джорджа Карлина. (Я не собираюсь связывать это - либо вы получите ссылку, либо нет).
  7. Прежде чем что-либо из этого, остановитесь и дайте интервью по скайпу на стоянке McDonald’s в Примме, Невада, и еще одно интервью по телефону где-нибудь за пределами Барстоу.

Вы могли подумать, что это очевидно. Но нет, я обучаюсь на собственном опыте, и это хороший способ сказать, что мне нужно изучать вещи на собственном опыте, и это хороший способ сказать, что я очень плохой планировщик, который любит YOLO вещи, которые слишком важны для YOLO. , что является хорошим способом сказать, что я идиот, к чему всегда сводится эта рекурсия.

В старшей школе я заблудился, приходя и собираясь в кинотеатр на первое свидание с самой красивой девушкой, с которой я встречался к тому моменту (или много лет спустя) - потому что я отказывался смотреть на карту или план. куда я шел. На обратном пути мы оказались в какой-то промышленной зоне дна, когда начался глубокий туман, и, конечно же, она испугалась, что я собираюсь ее убить. Излишне говорить, что второго свидания не было, и с тех пор я боялась первого свидания.

Это немного похоже на то.

Я почти уверен, что компания, занявшая первое место выше, до сих пор смеется надо мной. Если так, то по крайней мере я внес это. Меня практически выгнали со сцены, Showtime в стиле Аполлона. Я не мог вспомнить indexOf (да, не исполнилось 40 детей). С этого момента все пошло под откос, поскольку мой мозг застыл на том, что было объявлено сверхлегким вопросом, и у нас осталось всего 30 минут или около того, так что давайте посмотрим, сколько мы сможем ответить. С таким же успехом могла быть тема Jeopardy или большие тикающие часы, играющие на заднем плане.

Вот проблема для всех, кому интересно:

Я потратил 10 минут на решение не той задачи. Потом я продолжал получать синтаксические ошибки и идти неправильным путем, пока меня не прогнали. Конечно, я решил ее через 5 минут после собеседования, когда мой мозг успокоился, и отправил электронное письмо. Позже той же ночью я отправил лучшее решение. Без ответа. И, конечно же, я все еще думал об этом во время собеседования по «технической философии» с другой компанией, упомянутой в пункте 2 выше.

Все концепции остались там, но названия команд, а также сотни сокращений и названий предыдущих проектов, похоже, вытеснены испанскими словами. Я получаю их обратно, но сбивает меня с толку, когда я нахожусь в середине предложения и не могу вспомнить настоящее название какого-либо инструмента или проекта, о котором я пытаюсь говорить осмысленно. о.

Я только что услышал старый EDM-римейк Rocket Man, который не слышал уже 15 лет, и сразу сказал: Это Дафна Рубин-Вега. Я увидел фотографию старого Camaro в ленте FB моего друга и сразу понял, что это 1968-й по задним фарам. Хорошая расстановка приоритетов! Мне действительно нужно было, чтобы эта информация была немедленно доступна - я использовал команду Javascript примерно 100 000 раз. Хорошая песня, кстати.

Подтекст - темный демон, висящий в тени, вызывающий эту панику, - это страх, что, возможно, я слишком стар для этого дерьма. Я так не думаю. Всего несколько лет назад я взял в руки совершенно новую технологию и набор инструментов и добился большого успеха. Но программирование - это игра для молодых людей. Если весь остальной мир найма думает, что я слишком стар, то какое это имеет значение? Если я наткнусь на доску, все в комнате подумают, что это потому, что я старше? Они правы? Это нехорошие мысли, которые приходят вам в голову, когда вы пытаетесь мыслить творчески.

Когда я в панике или даже не на пике игры, я не слышу своего внутреннего голоса. Этот внутренний голос абсолютно необходим для таких вещей, как шутка, когда вы разговариваете с девушкой, или размышления о творческом способе решения проблемы. Он заглушается. Я знал ответ на интервью Netflix, которое я провалил. Я просто не мог слышать этого из-за всего шума.

Помню, когда я только начинал, я смотрел на старых разработчиков. В первый раз, когда они ошибаются или демонстрируют какое-либо разочарование - я сразу думаю, не могут ли они больше это исправить. О, это просто эксцентричный старый программист COBOL Боб, снова борющийся со своей IDE. Хотя я действительно думаю, что переход от разработки из командной строки к разработке современного мультиинструментального графического интерфейса был гораздо большим концептуальным скачком, чем когда-либо приходилось сталкиваться кому-либо в моем поколении программистов. К тому же я все еще выгляжу довольно молодо, и я всегда был крайне незрелым для своего возраста. Так что у меня это происходит.

Суть в том, что я на 99,9% уверен, что умею программировать так же хорошо, как раньше, даже если мне потребуется немного больше времени, чтобы решить сложную проблему. Программирование никогда не было связано со скоростью, или вы делаете это очень неправильно, imo. Опыт, позволяющий не идти неверным путем, должен с лихвой компенсировать то, что, возможно, вы немного медленнее прорабатываете вещи.

Но очень важно вписаться в коллектив. Разнообразная команда с людьми разного возраста и жизненного опыта, подобная той, с которой я работал последние 7 лет, легко справится с кем-то за 40. В команде, где все моложе 28 лет и недавно имеют диплом по CS, это может быть более сложной задачей. Это честно. И, конечно, вы никогда не узнаете, настоящая ли это причина очевидных последствий судебного процесса. Поэтому есть опасения, что вы будете преследовать свой хвост по заявленным причинам, по которым вы не получили работу.

Ну что ж, теперь я догоняю, пересматривая каждое видео FunFunFunction:

В этих видео говорится об одной ошибке в интервью за другой, и я понимаю, что ARGH - я это знаю. Мне просто нужно было немного подтолкнуть его, чтобы вытащить его из мрачных глубин, чтобы я мог говорить об этом разумно.

Я также получил несколько болезненных откровений о своей карьере и продолжении поиска знаний в моей области знаний. Как Маттиас (мой герой Javascript выше) умоляет в конце каждой серии: «Оставайтесь любопытными».

Но сначала давайте поговорим о триггере этих разоблачений - современном техническом интервью. Прошло 8 лет с тех пор, как я всерьез искал работу, и, похоже, все значительно изменилось.

На всех предыдущих собеседованиях, на которых я когда-либо был, было 1-2 вопроса типа доски - в основном, чтобы убедиться, что вы не пытаетесь навязать им какую-нибудь ситуацию «Поймай меня, если сможешь». Ваше резюме и то, насколько хорошо вы могли говорить о технологии, показались достаточно хорошими, что на самом деле менее справедливо по отношению к разработчикам, которые не наделены даром болтливости. Я знал многих из них в свое время.

До этого поиска работы и того, что я предпринял несколько лет назад, когда я подумывал о новой работе, я никогда не встречался лицом к лицу на собеседовании по программированию и не получал работу - даже вакансии, на которые я не имел удаленной квалификации. Не хочу сказать, что на собеседовании я был дерзким, но вот некоторые настоящие кадры того, как я вошел в комнату:

Но теперь все по-другому. Карма вполне могла расплатиться со мной.

В начале моего поиска старый коллега, который работает в FAANG (Facebook, Apple, Amazon, Netflix, Google), обратился ко мне - я хотел взять интервью? Конечно, почему бы и нет. Хорошо, вот программа из 1000 слов со ссылками на 4 сайта практики, чтобы вы могли начать переваривать. Ожидайте, что потратите около двух месяцев на обучение и пройдите несколько практических собеседований в компаниях, которые вам не интересны, в первую очередь.

Эээээ…

Примечание: этот человек - один из самых умных разработчиков, которых я когда-либо встречал, и добросовестный значительный вклад в крупный проект с открытым исходным кодом, которым пользуются миллионы - но все же провалил первые несколько собеседований - пока не поставил себя через этот специальный курс.

Глоток.

Видимо, некоторые другие опытные разработчики немного недовольны этой ситуацией:

О сумасшествии нынешнего процесса найма технических специалистов было много написано, задаваясь вопросом, действительно ли он проверяет профессиональные навыки:

… Или комбинация «мелочей» и решения абстрактных головоломок под давлением:

FWIW - Я не согласен, что это мелочи бара. Думаю, это важно. Может быть, не для вашей непосредственной работы, но о вещах, о которых вам обязательно нужно знать, если вы хотите, чтобы вас считали лидером в своей области. Подробнее об этом ниже.

Этот менеджер по найму предлагает сеанс парного программирования, который, я думаю, мне нравится намного больше, чем нынешний стандартный трехчасовой гриль:

Может быть, для некоторых компаний было бы лучше, если бы по контракту было нанято больше рабочих мест, и они могли бы нанять нескольких разработчиков одновременно? Так что они могли бы просто рассказать о нескольких разработчиках и надеяться, что один из них превратится в хранителя. Я, наверное, был тем летчиком, который несколько раз превращался в хранителя. Может быть, менеджеру стоит почаще действовать интуитивно, даже если кандидат не справляется с классными досками и не ставит все галочки?

Интересно, боятся ли компании нанять плохого разработчика больше, чем реальный ущерб, который плохой разработчик может нанести - по крайней мере, в небольших компаниях, где легко кого-то отпустить. Аналогия с покером - это игроки, у которых сильная рука, но они боятся попасть в стек из-за руки-монстра и, таким образом, не могут максимизировать вэлью в 95% случаев, когда они не играют против монстра. Или что-то подобное.

Этот сайт предлагает курс CS для программистов-самоучок:

Зачем изучать информатику?

Бенедикт Эванс ✔ @ BenedictEvan s

Существует два типа инженеров-программистов: те, кто разбирается в информатике достаточно хорошо, чтобы выполнять сложную инновационную работу, и те, кто просто справляется, потому что они знакомы с несколькими инструментами высокого уровня.

Оба называют себя инженерами-программистами, и оба, как правило, получают одинаковую зарплату в начале своей карьеры. Но инженеры первого типа со временем начинают выполнять более полноценную и хорошо оплачиваемую работу, будь то ценная коммерческая работа или прорывные проекты с открытым исходным кодом, техническое лидерство или высококачественный индивидуальный вклад.

Инженеры первого типа находят способы углубленно изучать информатику, будь то с помощью обычных средств или путем непрерывного обучения на протяжении всей своей карьеры. Инженеры 2-го типа обычно остаются на поверхности, изучая определенные инструменты и технологии, а не лежащие в их основе основы, и приобретают новые навыки только тогда, когда меняются ветры технической моды.

В настоящее время количество людей, поступающих в отрасль, быстро растет, а количество выпускников CS практически не меняется. Избыточное предложение инженеров типа 2 начинает сокращать их возможности трудоустройства и удерживать их от более полноценной работы в отрасли. Если вы стремитесь стать инженером первого типа или просто ищете более надежную работу, изучение информатики - единственный надежный путь.

Я не уверен на 100%, что согласен с некоторыми из этих предположений, особенно с полужирным шрифтом. Мне было бы интересно услышать отзывы об этом от других людей в отрасли.

Интересно, может быть, текущая эволюция собеседований - это больше самостоятельного выбора инженеров типа 1 и меньше проверки того, что на самом деле необходимо для выполнения работы? В любом случае, очевидно, что разработчику-самоучке не повредит потратить некоторое время и изучить то, что выпускники CS знают (или узнали однажды).

Вот еще один вывод из вышеупомянутого защитника парного программирования и интервью о том, что самая современная разработка программного обеспечения - это просто« водопровод . IE - такая работа, которая никогда не требует глубоких концепций CS. В моем собеседовании по скайпу в McDonald’s я на 100% собирал / склеивал готовые вещи. Мне это нравится, поскольку он полностью сосредоточен на том, что лучше всего работает для создания продукта, а не на том, какие технологии могут привлечь лучшие таланты.

Независимо от этих аргументов - я думаю, что большинство согласится с тем, что современные технические собеседования проверяют что-то, что может показать способности разработчика, но также необходимо изучить, и, возможно, не проверяет навыки, необходимые для выполнения работы. Может быть, компаниям меньшего размера стоит попытаться поймать инженеров, которые не выдерживают критического процесса FAANG, вместо того, чтобы пытаться подражать им?

‹бессмысленная тирада›
Клянусь, если бы вы только что закончили колледж и пошли на собеседование, вы бы подумали, что творческое использование вызова и подачи заявки и глубокое обсуждение классового и прототипного - основанное против функционального против любых других сомнительных типов наследования - вот самые важные вещи, которые вам нужно знать, чтобы быть успешным разработчиком Javascript.

Получил вчера вот такое:

var length = 10;
function fn() {
  console.log(this.length);
}
var obj = {
  length: 5,
  method: function(fn) {
    fn();
    arguments[0]();
  }
};
obj.method(fn, 1); // what is the output?

Прежде всего, в какой среде выполняется этот фрагмент кода - потому что это влияет на глобальную область видимости. И, во-вторых, можем ли мы просто console.log (это) и двигаться дальше? Это требует в 100 раз меньше усилий, чем пытаться возиться с этим в своей голове.

Кроме того, я думаю, что нашел источник для большинства своих вопросов на JS-интервью - тсс, не говори никому, кого мы знаем.

Знаете, о чем меня ни разу не спросили? Узел. «Сколько лет вы работаете с node?» очевидно, все доказательства, необходимые для экспертизы узлов. У меня было больше вопросов по AWS - и в моем резюме даже нет AWS (пока).
‹/ кислый виноград›

Так что это триггер моих откровений - испытание огнем белой доски и страх перед новым. Хуже всего, когда вы делаете это через 2 раунда, не прикасаясь к доске, тогда входит последний интервьюер дня и начинает стирать его, когда ваш мозг уже раскис после двухчасового трепа. Дун Дун ДАНННННН.

На самом деле кодовая панель пугает меня еще больше, поскольку вам действительно нужно заставить ее работать, но она также не выполняет таких действий, как выделение не синхронизируемых скобок или другое выравнивание. Так в 2018 году никто не развивается - зачем мне делать это в хронометражном тесте с максимальным давлением? Я опираюсь на линтер, как пьяный на барный стул.

Что касается глубокого размышления о коде - моя конкретная ситуация такова, что я был разработчиком узлов в течение последних 5–6 лет - в среде, где 99% времени узел нажимает пальцами, ожидая возврата серверных служб. Крики не были моей главной заботой.

Я провел множество отладок производительности на макроуровне, например таймеры промежуточного программного обеспечения, но мне ничего не понадобилось на уровне микро / умных алгоритмов. Что касается архитектуры программного обеспечения, такие как ясность кода / ограничения, масштабируемость компонентов и гибкость области действия, в то время почти все мое внимание было уделено.

Вот что я имею в виду под выделенным жирным шрифтом techno-gobbledy-gook выше (можете пропустить эту часть, если вы не программист):

Ясность кода / ограничения - потому что мы работали с оффшорными разработчиками, которые могут быть не совсем уверены в закрытии, промежуточном программном обеспечении или асинхронном программировании в целом. Больше всего меня беспокоило то, что они попали в асинхронный ад или случайно установили что-то в глобальном масштабе. Последнее легко сделать в узле, и его можно легко проскользнуть через однопользовательское тестирование в многопользовательскую производственную среду - где это все еще будет действительно очень странно и сложно реплицировать для отладки. Это то, что не давало мне уснуть по ночам.

Теперь вы можете сказать: Ну, это чушь, найдите более опытных разработчиков. Но это мир, в котором я жил. Поэтому я заставил его работать, создав барьеры относительно того, где разместить бизнес-логику, и абстрагировав асинхронное поведение до фреймворка.

Я действительно думаю, что есть что сказать об упражнении по разработке фреймворка, который избавит разработчиков от неприятностей, но при этом дает им 100% свободу создавать функцию, которую они пытаются реализовать. Однако недостатком для разработчиков функций было то, что они не уходили, чувствуя, что действительно изучили узел или асинхронное программирование. Что меня беспокоило.

На кухне в приложении Monster Node есть место для шеф-повара и, возможно, одного или двух учеников. Но всех там не может быть. К сожалению, такова природа зверя, ресторана. Превышен размер стопки метафор.

Масштабируемость компонентов означает, что создание компонентов 90–100 причиняет приложению не больше боли, чем компоненты 10–20. К концу у нас было около 200 компонентов - это могла быть полная веб-страница, отрисованный на стороне сервера фрагмент HTML или вызов AJAX, возвращающий JSON.

Для этого я намеренно допустил некоторую избыточность в том смысле, что каждый интерфейсный компонент объявил свои собственные вызовы внутреннего API и внутреннюю логику. Если бы мы увидели, что одна и та же сложная бизнес-логика обработки API появляется в нескольких компонентах, мы бы просто создали служебный метод. Это противоречит стандартной парадигме одного уровня для служб API и другого уровня для обработчиков маршрутов внешнего интерфейса (во взаимосвязи "многие ко многим" ). Но у нас это сработало отлично.

Кстати, я действительно не поклонник многоуровневого подхода внутри узлового приложения. Каждый маршрут должен быть отдельным компонентом imo, со всей бизнес-логикой, легко доступной в этом компоненте. Это значительно упрощает разработчикам интерфейса пользователя, чтобы быстро понять, что делает код, и избавиться от необходимости копаться во всем приложении в слоях абстракции, с которыми они не знакомы. С этой парадигмой вам действительно не нужен выделенный разработчик узла, кроме сопровождающего (-ых) фреймворка. Разработчики интерфейсов могут чувствовать себя комфортно, создавая и изменяя свои собственные компоненты на стороне узла.

Мне кажется, что первые 10 лет своей карьеры программиста я потратил, пытаясь построить идеальную абстракцию, а остальное с тех пор узнал, когда отступить ради ясности кода и будущей гибкости. ИМО, нет ничего хуже для рефакторинга, чем большая многослойная абстракция, которая, как вы внезапно понимаете, не справляется с новым вариантом использования. Я участвовал в подобных проектах. Гораздо проще разработать простую базу с избыточностью, а затем исключить очевидные ситуации повторного использования кода позже. Обратите внимание, что многие из тех же концепций компонентно-ориентированной разработки применимы и к микросервисам.

Гибкость объема просто означает, что даже с более чем 100 компонентами по-прежнему очень просто реализовать сквозные задачи. Мне удалось добиться этого, управляя всей конфигурацией из объекта свойств по умолчанию и добавляя глобальные перехватчики промежуточного программного обеспечения на каждом этапе цепочки запросов / ответов, а также на каждом этапе цепочки вызовов back-end REST api (которых много к одному против индивидуальный http-запрос). Когда требовалось новое глобальное или полуглобальное поведение, я просто добавлял новое свойство по умолчанию, а затем находил подходящие места в цепочке промежуточного программного обеспечения для его реализации. Это практически не создавало риска поломки существующих компонентов, было очень просто сделать для меня и очень просто для других разработчиков.

Или, поскольку отчеты всегда идут последними, мы можем просто привязать промежуточное программное обеспечение отчетов с перехватчиками к отдельным компонентам отчетов - все из которых являются излишними для фактического кода функции. Тестирование прошло точно так же. Промежуточное программное обеспечение действительно хорошо подходит для такого рода ползания области видимости, имо, иерархии часто не подходят.

‹*** (конец техно-жаргона непонятливости) ›››

Все это было запланировано заранее, когда я разрабатывал фреймворк - зная ситуацию нашего разработчика, размер сайта, который в конечном итоге вырастет, и хаотический характер, из-за которого наши требования имеют тенденцию развиваться и расти. Точнее, фреймворк претерпел итерации, которые возникли с течением времени, но спроектирован просто и достаточно гибко, чтобы допускать итерации такого рода.

Смысл всей этой многословности в том, чтобы, надеюсь, продемонстрировать, что я глубоко думал о своей работе последние 5 лет. Что хорошо.

Плохо то, что мне удалось это сделать, не будучи в курсе всех последних и лучших функций ES6 и не только, и даже не изучив многие из последних последних и лучших функций. Все сводится к простому и понятному отсутствию любопытства. Я был инженером второго типа.

Я просто провалил интервью Netflix, потому что забыл о генераторах javascript, о которых я действительно когда-то узнал. Но я не продержался достаточно, чтобы получить более глубокое понимание. Я не уверен, понадобились бы мне генераторы в моей реальной работе, но если бы они были, мне бы, наверное, не пришлось бы их использовать. Это законный удар по мне как ведущему разработчику.

Я был доволен игрой с инструментами, которые у меня были, до тех пор, пока я мог заставить их работать. Я не пытался угнаться за возможно лучшими, более чистыми решениями или получить более глубокое понимание того, что я использовал. Или просто регулярно знакомьтесь с Javascript. Я стал «парнем по Javascript» в своем офисе и не искал форумов и других источников общения со своими сверстниками. В мире покера мы называем это «утечками в вашей игре».

Что ж, это не совсем так. Я ходил и выступал на узловых конференциях и встречах, а также на внутренних презентациях, и я многому научился, создавая и выпуская свои библиотеки с открытым исходным кодом. Что, кстати, когда github стал совсем не крутым для использования в процессе найма? Кажется, я полностью пропустил поезд покажи нам свой гитхаб. Это пришло… и ушло… пока я был на той же работе.

Но я мог бы сделать намного лучше.

Я также упустил шанс изучить DevOps с нуля на моей подработке. Меня наняли в качестве специалиста по ноде, но меня постоянно выгоняли с кухни другой разработчик, который хотел быть парнем по ноде. , и знает основателя еще со средней школы. IE - Я не выиграю эту битву. Я легко мог бы перепрыгнуть и стать парнем DevOps. Но рабочая среда была крайне дисфункциональной, и я не хотел, чтобы на меня указывали пальцы, когда что-то не работает. Оглядываясь назад, мне, наверное, следовало просто выпотрошить это, выдержать дерьмовый шторм и многому научиться в процессе.

Урок здесь - в следующий раз, когда я захочу отправиться в долгую поездку без ожидания работы, мне лучше быть на 100% в курсе последних и лучших профессиональных навыков и моей области знаний. Будь то сторонние проекты, курсы Udemy или участие в таких вещах, как местные слабые каналы - я никогда больше не смогу потерять любопытство. Независимо от того, действительно ли это необходимо для продуктивного разработчика в конкретной работе, я должен был этим заниматься.

Хорошая новость в том, что я никогда больше не забуду генераторы или темы множества других тестовых вопросов. Во время этого процесса я на самом деле узнал массу полезного с разных точек зрения. В долгосрочной перспективе я, вероятно, буду счастлив, что провел собеседование с таким количеством компаний, увидел, что есть на рынке, что пользуется спросом и как они нанимают сотрудников.

(Я пришел из будущего, чтобы сказать - если вам это понравилось, вы можете прочитать заключение моего поиска работы здесь.)

…

Подождите, подождите, только что пришла идеальная работа. «Фил» из ZipRecruiter много работал для меня и, наконец, добился ее. asfasgasgagagagaagasga находится прямо в моей рулевой рубке. Я подгоняю!