Pull to refresh
6
Karma
5.7
Rating

Фронтэнд-разработчик

  • Followers 5
  • Following

Angular Junior: Null Object Pattern

Можно спокойно взять одну из maybe-либ, к тому же почти не нагружающих проект (т.к. там преимущественно типы, а не код), и все | undefined | null превратятся в maybe<T>. Читать это заметно приятнее.

«Это что! А вот у меня на собесе было…», или Байки с технических интервью

Создать игру "жизнь"? Вы задачки по проекту точно так же будете ставить?

Справедливости ради, если к такому заданию будет идти ремарка "я знаю, что ТЗ очень расплывчатое, мне хочется посмотреть на то, как вы будете его уточнять" — то я бы к этому отнесся крайне положительно.
Если без такой ремарки — то да, попахивает пренебрежением.


Особенно прикольно, кстати, что дальше по тексту статьи другой из участников жалуется, как ему поставили задание "сделать таймлайн в гуглмапсах". А это как раз тот же подход.

Моя жена умирала от рака мозга. Мой босс в Amazon сказал мне вернуться к работе или уволиться

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

Одна задача с собеса

Я бы сказал, что не "можно", а "нужно".
Вообще по тексту статьи не прослеживается главного — а зачем вообще появился throttle? setState можно фигачить десятками тысяч раз в секунду без каких-либо проблем, это я вам точно говорю. Там тормозить попросту нечему. Что будет тормозить — так это вовсе не setState, а последующий render.


Но да это проблемы архитектурного уровня. Если мы говорим про реальность, а не выдуманный пример — тут надо бы начинать с вопросов типа "вы одним компонентом делаете 2 разные вещи, почему тут не два компонента?"; "задачи вида "получить значение с сервера" должны решаться не компонентами (не презентационным слоем приложения), а стейт-менеджментом, либо же вообще в своем отдельном I/O слое, если у нас проект достаточно масштабен, чтоб его выделить отдельно"; "почему реальность получения значения с сервера замазана гораздо более упрощенной абстракцией, что произойдет, если запрос упадёт, будете вечно показывать Number: undefined?"

Софт-скиллы в IT: необходимость или косвенный навык?

Я бы дополнил, что "нормальные бизнес-процессы" — это не то, что можно отлить в граните. Это всё имеет свойство меняться, и довольно быстро. Нормальные бизнес-процессы на протяжении длительного времени бывают только тогда, когда эти процессы непрерывно выстраивают и модифицируют, те самые "люди с софт-скиллами". А иначе их и не будет.


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

Перестаньте врать себе. Я middle, а вам нужен senior

Я, например, некоторое время назад нанимался в Сбер именно через собственный официальный HR сбера (вакансию мне бросили третьи лица, но всё общение шло с собственным HR). Но да, знаю много людей, которые через третьих лиц шли.

Перестаньте врать себе. Я middle, а вам нужен senior

а можно пример навороченного веб приложения?

Гуглдокс? Codesandbox? Фигма? Тысячи их.


но фронтэндер думает иначе

"Иначе" обычно думает вовсе не фронтэндер, а владелец сайта.

Как проводить собеседования объективно и с пользой

Я не работал в каких-либо крутых компаниях.

Я тоже. Из самого крутого — делал визуальный (и невизуальный, чисто конфигами) конструктор UI, чтоб продукт был гибко настраиваемым либо шарящим в теме (сетевое администрирование) клиентом, либо же собственными конторскими спецами предметной области, без дальнейшего привлечения программистов.
Дальше я по этой теме могу еще минут 10 минимум говорить, там есть что вспомнить, но давайте пример на этом завершим :-)


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


За 5 секунд на собесе не смогу среди сотен (а то и тысяч) выполненных задач вспомнить крутую и сформулировать что и как я там делал несколько лет назад.

Вспомните заранее. Вопросы подобного вида сейчас, без преувеличения, задают на 8 собеседованиях из 10.


Без подготовки к этому вопросу меня уже на этом этапе отнесут к непрограммистам или плохим программистам.

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

Как вести себя с тимлидом, чтобы работа была продуктивной, а отношения — здоровыми

Тимлид нужен, чтобы контролировать работу команды

Зачем, если у вас и так все ответственные?


ставить командные цели

Аналогично — все же открытые, прозрачные, собрались и поставили себе целей на вырост, распределив их по команде как надо.


рассказывать о важных новостях и изменениях в компании или продукте

Я и не знал, что на роль RSS теперь нужно нанимать человека.


поддерживать тиммейтов, если что-то не так

Так они же все как на подбор правильные, что у них может пойти не так? Друг друга поддержат, опять же, зачем для этого человек с отдельной ролью и на отдельную зарплату?

Идеальная экономика

Понятно, что оценка в рублях имеет срок годности.

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

Идеальная экономика

То есть, беря кредит в 10000 руб, я не оцениваю его в золоте или в долларах, а оцениваю в тех же рублях.

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

Как вести себя с тимлидом, чтобы работа была продуктивной, а отношения — здоровыми

Из статьи прекрасно понятно, как обращаться с тимлидом. Но теперь стало непонятно, а зачем в команде вообще такой тимлид. Если разработчики прекрасны, открыты, последовательны, подготовлены, проактивны, и очень конкретны в общении — то нафига им тимлид? Чтобы что, чтоб приходить зарплату получать?

Идеальная экономика

Нет, насчёт "товара" я в принципе не против, с оговорками. Которые вы собственно и привели. Но там еще и "мерой самих себя", а вот это уже совсем дичь.

Old Skull — фронтенд-фреймворк из альтернативной вселенной

Для vscode есть extensions (в основном написанные для Polymer), которые что-то такое делают, только конечно не прямо вот "самостоятельно", а с некоторыми движениями руками (типа там, писать именно через tagged template literal — html`` и тому подобное).

Перестаньте врать себе. Я middle, а вам нужен senior

Кстати да, поддерживаю. В какой-то момент понимаешь, что ты можешь просто это написать и прокатит.

Перестаньте врать себе. Я middle, а вам нужен senior

И какой гарантированной проверкой вы будете выявлять такого кадра на собеседовании?

Как проводить собеседования объективно и с пользой

Что-то я не очень понимаю, как выглядят "вопросы в виде задач" — нельзя ли один (хотя бы совсем мелкий) пример?


Секцию по реакту-то можно проводить, конечно, только что она покажет? Разные люди пользуются реактом на совсем разном уровне — у одних всё готово и настроено и код обязан укладываться в пространные и подробные code style guide, другие всё сами на коленке настроили-собрали, третьи в силу каких-то соображений шпарят на голом реакте без всего остального, у четвертых реакт только рендерит, а всё остальное делают другие либы… что из этого принципиально именно для вашей вакансии, и насколько это критично?


Это скорее нужно для команды собеседующих: если процесс интервью распределяется на несколько человек, очень важно, чтобы все кандидаты получали одинаковые входные данные, и чтобы интервьюер не упустил никакие важные моменты в формулировке впороса и не повлиял бы этим на объективность ответа.

Я, если честно, совсем не понимаю, зачем это вам. Вы не ЕГЭ проводите же, зачем вам откалиброванные вопросы? В моем понимании, любая процедура технических собеседований обязана ответить на один, максимум два вопроса:
1) Берем ли мы этого кандидата? Да/нет.
2) Если на первый вопрос ответ "нет", то почему?
И второй вопрос — нужен по большей части для выдачи фидбека.
В чем смысл выставлять кандидатам какие-то оценки? Да, если в моменте у вас есть несколько подходящих кандидатов, то естественно их можно и сравить (если нет возможности и необходимости нанять всех). Но вообще-то надо вакансию закрыть пригодным для этой роли человеком, а не сидеть и ждать божественного программиста, который восхитительно ответит на вопросы.
А когда не надо ставить оценки — то калибровка вопросов не нужна. Специалист по проекту/направлению, на которое нужны люди — составляет вопросы/задачи, и конкретной вакансии сопоставляется конкретный набор этих вопросов и задач. На другие вакансии может быть легче/сложнее отбор? Ну так и пусть, что в этом плохого? Если надо будет отбор скорректировать (слишком хреновых кандидатов берем, либо наоборот никто не может пройти отбор) — то скорректируете.

Как проводить собеседования объективно и с пользой

Из всей своей практики (не супермного, но за полсотни перевалило, за сотню пока нет) — могу только сказать, что никогда в жизни я не встречал кандидата, чьи ответы на вопросы в стиле школьного экзамена (у меня было много коллег, обожавших экзаменационные собеседования) создавали бы более полное впечатление, чем сессия лайвкодинга на 15 минут на задаче уровня FizzBuzz.
Те, кто быстро и уверенно пишут простой код — так же спокойно ответят на существенную часть экзаменационных вопросов, те, у кого возникают затруднения уровня "как же мне написать цикл?" — засыплются на вопросах.
Я никогда не видел людей, которые бы прекрасно писали простенький код, но откровенно сливались бы на теоретических вопросах, зато я видел людей, которые могли очень долго и очень правильно отвечать на вопросы, но вот очень простой код писали с огромным трудом.


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


Из этого вывел список приоритетов по убыванию:


  1. Мотивационно-жизненные вопросы ("секция HR"). Это без преувеличения самые важные вопросы, которые вы (не обязательно вы как технический специалист, но кто-то их должен задать обязательно) можете задать, и самые важные ответы, которые вы вообще получите от кандидата. Это практически единственная точка, на которой можно как-то отсеять тех людей, которые тем или иным способом навредят команде или компании (например тем, что возьмут и через квартал уволятся без объявления войны). Любые сомнения в мотивации и вовлеченности кандидата и в его способности работать в команде — это очень серьезно.
  2. Вопросы на подтверждение опыта. Это те самые "что наиболее крутое вы делали", просто разговор за плюсы и минусы технологий из опыта кандидата и по вашей вакансии (людям с опытом всегда есть что сказать на этот счет, всегда с кровавыми деталями), и тому подобное. С хорошими кандидатами эта секция практически всегда из вопросов превращается в беседу. Плохие — опять же крайне быстро выявляются по их куцым и формальным ответам. К джунами и трейни эта секция, увы, не применима, но для остальных она крайне важна.
  3. Лайвкодинг. Максимально быстрый способ понять, может ли кандидат писать код. Иногда это уже заведомо понятно из прошлой секции, но в случае сомнений или собеседования людей без особого опыта — это становится ключевой проверкой. Задачи лучше давать исключительно очень простые, но открытые (в которые можно продолжать добавлять новые условия вплоть до превращения очень простой задачи в очень сложную). Ни в коем случае не с заковыристым алгоритмом (чтоб не было ложноположительной офигенности, если кандидат вдруг откуда-то назубок знает этот конкретный случай), и ни в коем случае не с leetcode и подобных источников (мы проверяем, может ли человек писать код, а не практиковался ли он перед собеседованием на leetcode). Тут очень важно именно постепенное усложнение задачи — насколько далеко за отведенное время кандидат способен забраться в дебри постепенно усложняющейся задачи. Заодно это и проверяет не менее важные вещи типа понимания добавляющихся условий и их влияние на уже написанный код.
  4. Специализация. Это если нужен именно гуру реакта или тому подобное. Зачастую (если команда уже укомплектована специалистами) эта секция может быть вообще не нужна, т.к. отсутствие опыта энтерпрайзовой практики с конкретной либой/фреймворком — весьма незначимая деталь, и чуть более хороший "в общем" кандидат без опыта того же реакта — куда лучше чуть более плохого, но с опытом. Но если в команде специалистов нет — то это имеет большее значение, и выделять под это отдельную часть собеседования может быть весьма оправданно. И, опять же — только если после секции №2 остались какие-то сомнения.

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

Перестаньте врать себе. Я middle, а вам нужен senior

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


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


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

Идеальная экономика

Но так как любому новому товару нужна реклама, то да, новой валюте будет нужна реклама. Тем более, крипте.

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


Покопайтесь,… заодно найдите валюту, лучше бумажную, на которой будет написано "гарантированный обмен, на ценности".

Вы из негарантированной обеспеченности современных валют делаете совершенно неправильный вывод.

Information

Rating
638-th
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity