Краткая инструкция по найму нормальных людей в ИТ Материал редакции

Материал автора блога о технологиях «Вастрик.Инсайд».

В закладки
Аудио

Привет, Олимпийский!

Сегодня постараюсь уложить в один выпуск весь свой и людской опыт проведения хороших айтишных собеседований. После определённой планочки развития это умение совершенно внезапно оказывается нужно каждому сеньору, и никуда от этого не убежишь. Как от скрама и формата «один на один».

Сортировки и кручёные деревья давно стали мемами говноинтервью. Но как делать правильно, никто так и не рассказал. Попробую я.

Для более удобного чтения рекомендую сразу открывать веб-версию, потому что получился опять лонгрид. Кто не читал выпуск «Войти в айти» — тоже рекомендую. Они во многом пересекаются.

Идеального собеседования не существует

По двум причинам.

Практическая: никто не придумал ЕГЭ для айтишников. Нет универсальной для всех линейки. Стандартные приставки «джун-мидл-сеньор-лид» помогают не больше, чем найденная в лесу палочка построить космический корабль. Потому в каждой компании свои грейды, и сеньор из одной может оказаться недомидлом в другой. Давно пора уже сделать единый стандарт коммьюнити, но пока я такого не встречал (покажете?).

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

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

После этого ранние сотрудники обычно в ужасе разбегаются, пишут, как там «всё просрали» и «XXX уже не торт», а компания может стабильно продолжать расти.

Суровая правда жизни, из которой логично вытекает следующий пункт.

Знай место между селом и Google

Популярная дурная практика — копировать интервью крупных компаний. Культ карго вообще любимое развлечение в ИТ. После выхода книжки про собеседования в Microsoft о круглых люках и шариках для гольфа спрашивали ещё лет десять. Сейчас чудом прекратили.

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

Крупняки на серьёзных щах выдумывают себе списки субъективных правил для найма, которые на деле выглядят как анекдот про «неудачники нам не нужны». Кандидат не помнит наизусть случайное определение из «Википедии» — нафиг его, допустил в коде опечатку — гони его веником, не расслышал вопрос и не уложился в отведённые 15 минут — до свидания. Поток желающих всё равно не иссякнет.

Как в той истории с автором Homebrew, которого не взяли на работу в Google

Говно ли это? Да. Зато такой отсев экономит много бабла, а значит, для кровавого корпората это эффективно. Таковы правила игры: хочешь гугловскую зарплатку и ДМС — будь готов месяц на фултайме сидеть над Cracking Code Interview вперемешку с Корменом и в любое время суток размышлять, сколько мячей поместится в Эмпайр-стейт-билдинг.

С другой стороны, есть стартапы, которым пофиг, сколько сортировок ты знаешь, зато жизненно необходимо, чтобы ты делал дела и вписался в команду. Чтобы все были «на одной волне», или like-minded, как там любят говорить. Для них собеседование с пивом в парке — офигенно эффективный процесс, отсеивающий душных дидов.

Корпоративная честность с собой — большая редкость.

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

Где искать людей

Если у вас есть внутренние специалисты по найму — вы прекрасны и великолепны, смело пропускайте эту главу. Часто их нет, потому остаётся два варианта.

Первый — рекрутеры-аутсорсеры. Это рак ИТ. Они срали на рынок, компании и кандидатов, но неплохо живут за их счёт, получая по одной-две месячных зарплаты каждого найденого кандидата.

Работают по одному шаблону, которым массово спамят везде: «Доброго времени суток, %username%. Мы заметили у вас большой опыт в %programming_language% и %framework_name%. Для вас уникальная работа в Европейской Компании ООО “Домофон Блокчейн Ltd”. Возможна релокация в Воронеж. Подробности расскажу по телефону. Приготовьте веб-камеру. Название компании под NDA».

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

Когда-нибудь их всех заменят скриптами.

Остаётся второй вариант: искать самим. Пишем честный текст вакансии, пытаясь избежать штампов про «кофе-печеньки-лидеры-рынка», размещаем на одном из популярных сайтов и ждём. Не верьте в сказки, что «хорошие кандидаты сами не приходят» — приходят, да ещё как. Главное — честность. Она привлекает именно тех, кто нужен. Если вы команда распиздяев — так и напишите.

А денежные бонусы лучше платите своим же работникам за приведённых рефералов. Вот и вся тайна.

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

Цель любого интервью — принять бинарное решение «да» или «нет», и есть лишь три качества в кандидате, на которые надо смотреть. Чувак не подходит хотя бы по одному — сорян, до свидания. Такие вещи не подтягиваются за год, так что на моей памяти компромиссы ни разу не заканчивались хорошо.

Первые два качества взяты из статьи Джоэла Спольски “The Guerrilla Guide to Interviewing (version 3.0)”, которая сама по себе тоже ок (спасибо, Максим Базаров).

1. Мудрость (умность)

Не стоит путать со знаниями, начитанностью или уровнем IQ. Дипломы олимпиад от говнокода не спасают. Синтетические тесты или вопросы на знания алгоритмов — полный булщит, означающий, что интервьюер вообще не понимает, как делать свою работу (ну либо таков процесс, смотри первую главу).

Ум — это умение рассуждать, задавать вопросы, анализировать аргументы, не делать поспешных выводов, видеть плюсы и минусы решений, процессов, фреймворков. Особенно своих.

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

2. Умение делать дела

Get Shit Done, как ёмко называют это умение в английских статьях. Чем моложе и свежее проект — тем больше ему нужны люди, умеющие за неделю на коленке нафигачить стартап. Старым и стабильным проектам, наоборот: чем меньше люди фигачат фичи и больше думают о логике — тем лучше. Если бы Google давала каждому джуну коммитить в мастер, представляете, что бы началось? Так что снова надо знать баланс.

Определить умение делать дела просто — по прямоте ответов на задаваемые вопросы и пресловутым «горящим глазам». Даже если они горят ненавистью ко всему ИТ — этот чувак точно соберёт MVP за неделю.

У умения делать дела есть неприятная особенность: оно уменьшается с ростом мудрости.

3. Совместимость с командой

ИТ — командная игра, одиночки тут неконкурентны. На моей памяти несовместимость человека с командой — одна из главных причин увольнений. Так что даже при совместимости остальных пунктов остаётся третий — насколько кандидат «похож» на команду и сработается с ней.

Брать даже самого умного ботана в команду высокоэффективных алкашей — хреновая затея. «Ниндзя-суперстар» так же сгниёт в команде, в которой переименование файла надо согласовывать с тимлидом (тру стори), а для исправления опечаток назначают сторипоинты.

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

Как избегать собственную необъективность

Любое интервью — это схватка двух ёкодзунов, находящихся в заведомо неравном положении. Сторона компании владеет всей информацией и готова ко всему, кандидат — как студент, пришедший на экзамен без понятия, по какому предмету.

Умные интервьюеры помнят, что избавиться от собственной необъективности невозможно, но можно пытаться её обмануть. Много лет назад я придумал свой универсальный способ избегать предвзятость.

Если ты задаёшь кандидату вопрос, на который есть однозначный ответ и ты его знаешь, — это плохой вопрос.

Любой вопрос вида «а знает ли он» — провал со стороны интервьюера. Он не знает, а ты знаешь (прочитал об этом пять минут назад или запомнил с универа) — значит, кандидат говно, да? Нет. Говно здесь интервьюер, который не догадывается о собственной предвзятости.

Правильная постановка вопроса — «понять, умеет ли он». Дальше разбираем вместе варианты и оцениваем по трём качествам выше. Всё.

Вопросы не должны быть попыткой самоутвердиться знанием слов «интрузивный список» и запоминанием наизусть статьи про нажатие Enter в браузере или любой другой, что вы недавно прочитали.

Когда вы нанимаете джуна — ок, это может быть условным маркером, что он прочитал две рекомендованные на лето книжки. Сеньор же к своим годам повидал столько говна, что 90% из него он уже тупо забыл.

В универе, например, я помнил наизусть все кодировки юникода и мог прочитать строку циклом по байтам, соблюдая BOM. Сейчас я без гугления даже не назову разницу между UTF-8 и UTF-16. Значит ли это, что я безграмотное быдло? Конечно! Но менее опытным программистом я от этого не становлюсь.

К сожалению, в большинстве случаев на всё забивают и делают интервью по принципу «тимлид с тем чуваком из команды, которому лень сегодня работать, допрашивают, какая функция обрезает строку в РНР».

Смешная история приключилась, когда я готовил этот выпуск и опрашивал людей: одни ребята прислали мне в личку ссылку на список из полусотни теоретических вопросов на все виды алгоритмов и структур данных, который, по их заявлениям, «отлично помогает отсеивать всяких слабаков». Хотел привести его в пример, как делать не надо, но не смог — их сайт уже третий день недоступен с UnhandledException. Ирония, бессердечная тварь.

Структура хорошего технического интервью

Напомню, как выглядит классический процесс найма:

  • Скрининг эйчаром на предмет общей адекватности и соответствию вакансии.
  • Техническое интервью (от одного до бесконечности).
  • Разговор с одним из главных инженеров о ценностях, порядках входа в хату и leadership principles (это та хрень, которой сегодня заменили «коммуникабельность» и «нацеленность на результат», когда все стали над ними слишком уж откровенно ржать).
  • Оффер, и все пьют.

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

Не пытайтесь упихать все этапы в истощающий интервью-марафон. Всё это отлично делится на несколько 30-минутных разговоров

Шаг первый: рассказ о компании, продукте, задачах и планах

Лучше всего с ним справляется продукт-оунер (или кто там у вас по скраму), но техлиды иногда тоже неплохо продают. Подойдёт простая домашняя заготовка на пять минут вида:

  • Мы в %company_name% занимаемся тем-то.
  • Наша команда делает то-то для того-то (чтобы стало понятно зачем).
  • Нас N человек, из которых M разработчиков, и так далее (команда и процессы).
  • Мы пишем всё на %language_name% с использованием %framework_name% и %database_name% (описание стека).
  • Сейчас ищем новых людей, чтобы то-то (планы и понимание, что будем пилить).

Всё. Вы великолепны.

Шаг второй: «Расскажи о себе»

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

  • Я Олег, пишу на том-то столько-то лет.
  • Сейчас работаю в %company_name%, занимаюсь тем-то (рассказ о настоящем).
  • Мы всё делаем на том-то с использованием вон той модной хрени (текущий стек).
  • Раньше я занимался тем-то и сделал то-то (рассказ о прошлом и опыте работы).
  • Мы делали то-то, а потом то-то, а самое крутое было то-то (более общий технический бэкграунд).

По желанию рассказ можно разбавить пруфами и фактами. Если какой-то из пунктов упущен — про него можно спросить на следующем шаге.

Шаг третий: смоллтолк за жизнь и технологии

Место, где начинается собеседование. Здесь стоит вспомнить, что мы нанимаем не продажника с Уолл-стрит. Перед нами инженер, который так запуган книжками про интервью, что уже заранее принял позу для вращения деревьев и выписал на руке основные свойства нотации Big-O.

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

  • Какой твой любимый язык или фреймворк? Теперь расскажи его минусы.
  • Почему вообще программируешь и что тебя драйвит?
  • Ты сеньор и можешь дать один совет себе джуну 10–20 лет назад. Какой он будет? (Спасибо, @theKashey.)

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

Шаг четвёртый: настоящая задачка

Когда контакт установлен, можно бомбить заданиями. Обычно время есть на одно максимум, так что выбирайте с умом. Сразу приведу примеры идиотских и бесполезных из популярных:

  • «Какая функция делает X», «какие бывают У», «как работает Z» — и другие вопросы теории. Пустая трата времени и яркий звонок, что интервьюер некомпетентен, контора — говно и надо сразу прощаться.
  • «Что происходит после нажатия Enter в браузере». После выхода той самой статьи на «Хабре» все прям заболели этим вопросом. Ничего, кроме потехи самолюбия, этот вопрос не даёт.
  • Задачки на монетки, верёвочки и «горы Фудзи». Устарело лет пять назад, и все так и не смогли понять, зачем их спрашивали.
  • «Ваши слабые стороны», «личные достижения», «проблемы, с которыми столкнулись» и так далее. В 100% случаях получите социально одобряемый ответ или домашнюю заготовку. Никто не будет отвечать на такое честно. (Спасибо, @skv_nskv.)
  • Лайв-кодинг в Whiteboard или «Google Документах». Унизительная практика, особенно когда это делают на время (почти всегда). Хотите понаблюдать, как человек пишет код (зачем-то), — сядьте рядом, займитесь парным программированием в любимом IDE. «Google Документы» хороши, чтобы накидать варианты решений, не более.

Теперь хорошие:

  • Давать упрощённую версию задачи, которую сами недавно решали. Мой любимый вариант. Кандидат сразу понимает, чем занимается команда, а команда видит, насколько кандидату это интересно. Проходит в режиме диалога: как бы ты решал? А какие ограничения? А что тут использовал бы? (Спасибо, @crecotun.)
  • Как бы ты спроектировал продукт, похожий на наш. Подходит для молодых продуктов или строгих правил NDA. Можно взять похожий продукт конкурентов и вместе разобрать. (Спасибо, @tapokshot и @sshbrnv.)
  • Вот пул-реквест, сделанный одним из наших джуниоров. Сделайте код-ревью. Кандидат видит реальный проект, а интервьюер умение читать, писать, обсуждать код без фанатизма и истерик. (Спасибо, @chaos_helga.)
  • Расскажи о неоптимальном архитектурном решении в одном из твоих прошлых проектов и почему оно было принято. Инженер должен уметь принимать и обсуждать неоднозначные решения. (Спасибо, @lazeez.)

Шаг пятый: тестовое на дом

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

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

Наличие кода на GitHub заменяет тестовое на 100%.

Сам придерживаюсь такого подхода, и это мегаудобно. Интервьюеру не надо ждать несколько дней, а кандидату тратить вечер на очередные крестики-нолики. Даже если нет проектов — можно легально опубликовать на GitHub тестовое, сделанное для другой компании. Офигенно. Делайте так.

Шаг шестой: вопросы от кандидата

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

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

Вы счастливы делать то, что делаете? Почему?

Ну и сами на досуге подумайте. Пока.

{ "author_name": "Вадим Скворцов", "author_type": "editor", "tags": [], "comments": 238, "likes": 338, "favorites": 757, "is_advertisement": false, "subsite_label": "hr", "id": 73687, "is_wide": false, "is_ugc": false, "date": "Tue, 02 Jul 2019 14:04:44 +0300", "is_special": false }
0
{ "id": 73687, "author_id": 120027, "diff_limit": 1000, "urls": {"diff":"\/comments\/73687\/get","add":"\/comments\/73687\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/73687"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199121, "last_count_and_date": null }
238 комментариев
Популярные
По порядку
Написать комментарий...
134

> Разговор с одним из главных инженеров о ценностях, порядках входа в хату

Если бросают под ноги клавиатуру и просят написать абстракцию, надо перешагнуть.
Что бы завести корпоративный email, заходишь в офис и кричишь: "Опенспейс братуха, дай кликуху!"

Ответить
24

У младших тестировщиков (или джунов) не брать ничего, первым с ними не заговаривать, за их стол в корпоративной столовой не садиться

Ответить
11

балуете тестировщиков, столовую надо еще заслужить. вообще сначало IT бояре отобедать должны, потом все остальные.

Ответить
4

А если не бросают под ноги, а рисуют на стене?

Ответить
24

Если просят код на стене написать, то попроси синтаксис подсветить.

Ответить
4

Перед тобой 2 кубикла, в какой сам сядешь, в какой коллегу посадишь?

Ответить
4

аж проорался! спасибо)

Ответить
37

Идиоты рекрутеры честно просто за***ли!!!
Мало того что вся почта забита дерьмо предложениями.
Так когда ты действительно устраиваешься работать на должность senior developer с 15+ годами у тебя спрашивает сортировку пузырьком.
А сука тестовое задание написать универсальную фукнцию ( что уже антипаттерн, о чем ты и сообщаешь ) парсинга строки регуляркой которая отработает в любом случае.
Да ещё и предлагают не писать тесты.
Передать словами как от этого бомбит просто невозможно.

Просто позвони дегенерат в скайп и я покажу свои проекты и посмотри как я код пишу.

Причем частенько ты понимаешь что сам в одиночку писал проект в 10 раз больше и сложнее чем тот на который ты сейчас претендуешь.
А у работодателя это пишут 10 человек.
Чем они там занимаются история умалчивает.

Я уже не молчу и в лицо говорю рекрутеру что его интервью бред и пусть не тратит мое время.
Конечно же я оказываюсь ВНЕЗАПНО не подходящим кандидатом.

Тут выбор один молчать в тряпочку и выполнять все задания тратя на это чушь время.
И может быть ты выплывешь сквозь эту навозную кучу к работе.
Что тоже не гарантируется так как собеседование с рекрутером это очень субьективная вещь.

Не согласен с "деланье дел".
MVP которе сделает новичек за неделю я сделаю за пару дней и будет и лучше и стабильнее работать.
Спасибо за интересную статью надеюсь хоть кто то из рекрутеров начнет думать головой а не задницей!

Ответить
52

Как-то раз дали математическую формулу, листочек, сказали написать код ее решения. Говорю - не могу - я даже не понимаю что тут написано. Пальцем показали на проходящего парня: "Вот видишь студент 3 курса идет - он ее закодит за 2 минуты". Говорю: Логично - он наверняка с пары по вышке идет, а я ее проходил 12 лет назад - ничего не помню. В общем - не взяли меня (на чисто прикладной проект).

Ответить
7

Мм, прямо пахнет моим собесом в Варгейминг в этом феврале.

Ответить
44

Подавался я тогда на фронтенд в Питерский офис, собеседование через скайп. Первый вопрос на техническом собеседовании: "Как посчитать длину вектора?". Выбили из колеи сразу, растерялся. Они продолжают: "А с графами работали? Знаете теорию графов, чтобы самый короткий путь построить?". Тут я уточнил, когда про фронтенд-то вопросы будут? Джаваскрипт, все такое. А они мне: "А какие бывают типы данных? А чем hashmap от dictionary отличается?" Тут я сказал, что в js нет ни одного, ни другого, а типы данных бывают такие-то и такие-то, но вопрос для первого курса. Где-то тут мы и попрощались, а потом я получил отказ от рекрутера и предложение попробоваться еще в Минский офис, там будет все по-другому, но нужно сделать тестовое задание на 8 часов.
Нужно ли говорить, что варгейминг в черном списке работодателей с таким подходом.

Ответить
4

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

Ответить
19

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

Ответить
7

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

Ответить
3

Ага. "Как изменить высоту башни с помощью барометра"
https://bocharik.livejournal.com/62514.html

Ответить
0

Да, читал, потрясающий расказ.

Ответить
0

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

Ответить
5

ох, прочитал ваш коммент и вспомнил свой собес на Senior QA Automation в "крупнейший инвестиционный банк Европы". Были вопросы по теории Java, логические задачи, тест-кейсы и вот это вот все. А затем я получил ответ от рекрутера, что "ребятам вы понравились, но по логическим задачкам слабо" или как-то так) хочется устроиться в такую компанию и начать целыми днями проверять на практике как давление на люк действует

Ответить
3

Тут я сказал, что в js нет ни одного, ни другого…

Ну, в движке браузера под капотом они есть. Грубо можно даже сказать, что это Map и Object, соответственно. Но вопрос на фронтенд действительно странный. Если с графами ещё можно как-то куда-то (хотя должен быть очень специфичный проект), то это непонятно зачем понадобилось. Обычно такие вакансии идут лесом, так как вряд ли что-то толковое предложат.

Ответить
1

Да вроде Map и Dictonary - это одно и то же, просто в разных языках по разному называется. Но Map - это абстракция. Тут спрашивают про HashMap - это разновидность Map которая для сопоставления ключей использует хэш объекта-ключа (можно юзать и что-то другое, например, тупо адрес в памяти). Получается что HashMap - это разновидность Dictionary. Я б такой ответ дал. Но хз что они хотели услышать, тем более в фронтах не разбираюсь.

Ответить
0

можно юзать и что-то другое, например, тупо адрес в памяти

Нет, это тоже будет хеш-мэп. Альтернатива - можно сделать коллекцию через деревья, например B-tree или красно-чёрное

Ответить
0

В js любой object это dictionary, и реализован он скорее всего как hashmap. А как можно теорему Пифагора не знать?

Ответить
0

Поумничать пришли? Любой dictionary можно прописать как объект в js, но не наоборот. И массив, и функции - это все объекты. А __proto__ как в dictionary реализовать?
А вектора в моей голове с Пифагором никак не связаны.

Ответить
2

А вектора в моей голове с Пифагором никак не связаны.

Жаль

Ответить
0

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

Ответить
0

У меня несколько побед в мат. олимпиадах, был в десятке на олимпиаде по ЦФО, губернаторская стипендия и премия "Интеллектуальный ресурс 2011".
Так что свои оценки можете оставить при себе.
Люди теряются, когда им задают неожиданные вопросы.

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить
1

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

Ответить
0

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

Ответить
0

лучше чем чем те же участники программы умники и умницы,

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

они примитивны если вы это когда-то осмыслено делали, даже если забыли то минимального умственного усилия достаточно чтобы всё восстановить

Ответить
0

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

Ответить
0

ну и я, просто мне это не понятно и для меня это как-то подозрительно очень. всегда хочется проверить как именно думает человек и хочет ли он это делать

Ответить
0

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

Ответить
0

Адекватность == знание математике? Дружок, ты невменяем.

Ответить
0

не расстраивайся, речь очевидно про работу программистом, инженером и т.д.. вот твоя адекватность сейчас после всего что было написано в треде под сомнением)

Ответить
13

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

Хотелось бы конечно после этого заставить сожрать его эту бумажку.
Но к сожаление подобное принуждение в нашей стране и не только уголовно наказуемо.

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

Ответить
2

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

Ответить
0

Вы путаете структуры данных (пусть базовые) и формулы. Одно дело здание, совсем другое - по каким правилам по зданию идет вентиляция.

Ответить
0

Знать и помнить это разные вещи.
Вы можете написать на листочке по памяти алгоритм левита или пирамидальную сортировку ?
99% нет если заранее не подготовились.
И как часто вы будете применять подобные алгоритмы в обычном проекте.
Дай бог получится разок использовать и то маловероятно.

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

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

И к чему мы приходим так ли критичны знания всех алгоритмов и структур данных особенно в высокоуровневых языках.
Они не критичны.
Это просто набор редко используемых иструментов, как ящик с ключами и отвертками где то в гараже. В ящике если редкие ключи которые раз в год берешь под задачу. А все нужные держишь при себе.
А остальное время они пылятся, и надо вспомнить где они вообще лежат.

Любой программист сам к ним приходит со временем, даже если его изначальная профессия была другой.
А те кто учил алгоритмы в вузах через три года уже не помнит большу часть и нужно повторять. Про 10+ лет я вообще молчу.

Программисту более важно писать читаемый, хорошо комментируемый и документируемый код. С хорошим покрытием тестами.
Знать и понимать хотя бы часть шаблонов проектирования.
Разбираться в методологии ООП как самой распространенной.
И главное в кухне языка на котором он пишет.

Ответить
–13

Для старшего разработчика с большим опытом работы у вас слишком неграмотная и эмоциональная речь.

Ответить
23

Не несите бред.
Умение писать комментарий с T9 никак не коррелирует с умением писать код.
Такой уже я человек токсичный, если мне что то не нравится я говорю как есть.

Ответить
10

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

Ответить
13

Доказательство чего ?
Что я хреновый разработчик, ну может быть.
Смотря кому судить.

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

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

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

Ответить
5

Падажжи, ёмана

Ответить
5

это ты просто опытный программист, но плохой сотрудник

Ответить
0

Подчиненные и много общения с людьми есть у синьоров только на галерах. В остальных местах все очень индивидуально.

Ответить
0

Синдром самозванца

Ответить
0

Ох незнаю. Если бы вы хотели меня оскорбить то вам надо было приписать мне Эффект Даннинга — Крюгера.
Мое мнение что я просто злой перфекционист.
А скорее всего просто злой.

Ответить
0

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

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

Ответить
0

Ну незнаю чуть выше назвали жуликом.

Тут дело не в этом, не хочется работать там где код не прогрессирует.
И медленно сваливается в legacy, которое потом тебе же и поддерживать.
А нет тестов, нет документации и никто кроме тебя не хочет это делать.
Не понимаю что просто сидя на месте он в первпективе себе же создает проблемы.

Совещания если они не два раза в день, очень полезная вещь.

Ответить
0

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

А так - надоедает - надо двигаться.

Ответить
0

Спасибо учту ваше мнение)

Ответить
9

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

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

Ответить
0

Надо было соглашаться и брать, но не пройти испыт

Ответить
4

Иногда зарвавшимся собеседующим я напоминаю, что это СОбеседование, а не экзамен. То есть, это общение в обе стороны, а не в одну.

Ответить
6

хаха, мне однажды рекрутер на собеседовании на должность РМ, вроде, выдала "вопросы здесь задаю я". я даже растерялся и задумался, нужно ли мне вызывать адвоката

Ответить
1

У меня были случаи, когда коллеги собеседовали кого-то и приходили опустошённые и потерянные, со словами: "что это сейчас было? Нас как будто выебали". То есть, кандидат хорошо понимал своё место в этом мире

Ответить
1

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

Ответить
0

Коллеги - технари, менеджеры

Ответить
0

Андрей +100 к вашему пониманию рекрутера. Главное, чтобы рекрутер был профи, с высоким социальным интеллектом а не "залетной милашкой"

Ответить
1

Юнец )) Ниче, повзрослеешь, и рекрутеров примешь как неизбежное зло.

Ответить
6

Последние 20 лет не могу привыкнуть.
Это когда на пенсии ?
До которой боюсь не доживу)

Ответить
0

Прикол в том, что тесты и задачи даёт сама команда с тимлидом. Рекрутер несёт это в массы и становится козлом отпущения.
Т.е. сейчас в чести рекрутеры, которые вовремя скажут заказчику, что его заказ г..но и не запустит "это" в тираж рынка

Ответить
32

Блэд, Вэстрик!

Ответить
0

Чёт я за последние два дня уже второй или третий раз натыкаюсь, что на него ссылаются
*paranoia mod on*

Ответить
9

Хороший контент сам пробьет себе дорогу. Для плохого потребуется маркетинг и SEO :)

Ответить
7

Больше не на кого.

Ответить
–3

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

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

Ответить
26

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

Ответить
–20

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

Ответить
27

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

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

Ответить
0

это потому что вы всё валите в одну кучу. в яндексе алгоритмические задачи - на уровне easy..medium с leetcode. в гуглах и фейсбуках аналогично, только уровень сложности повыше. а где-то могут и пор гномиков на полном серьёзе ещё спрашивать, но это совсем другая история

Ответить
1

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

Ответить
4

Просто предупреждайте об этом, тогда не пересечемся.

Ответить
1

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

Ответить
0

через 2 недели после интервью выйти на работу в яндексе? да вы, дедушка, романтик

Ответить
14

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

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

Ответить
–4

Пригождаются, каждый день.

Ответить
5

У вас наверно на рабочем месте нет интернета, да? Поэтому вашим сотрудникам нужно помнить все алгоритмы?

Ответить
5

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

Ответить
4

Для подсчета сложности алгоритма не нужно знать алгоритмов.

Ответить
0

Я не знаю что на это ответить, честно.

Ответить
2

Можете не отвечать, если не знаете. Но оценка сложности алогритма не подразумевает знания конкретных алгоритмов.

Ответить
3

Знать алгоритмы нужно для того, чтобы разбирать разные типы алгоритмов, учиться оценивать сложность и вот это все? Я правильно вашу мысль понял?

Ответить
–1

Нет, вы просто повторили то, что было в моем комментарии слово в слово.

Ответить
2

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

Ответить
–2

Он отвечает на ваш вопрос.

Ответить
1

Мой вопрос был "для чего нужно помнить алгоритмы". Выше вы написали, что это не был ответ на мой вопрос. Вы уже начали тонуть.

Ответить
0

- "Я правильно вашу мысль понял?"
- Нет, вы просто повторили то, что было в моем комментарии слово в слово.

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

Ответить
10

Вовсе нет, я пытался у вас узнать, зачем нужно обязательно знать/помнить алгоритмы, но вы как апологет этого утверждения даже не смогли внятно объяснить зачем же все-таки это нужно,

Ответить
2

Может быть, если вы перестанете регулярно придумывать свои алгоритмы, продукты JetBrains перестанут так тормозить? :)

Ответить
1

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

Ответить
3

Преподаватель, наверное.

Ответить
0

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

Ответить
5

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

Ответить
0

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

Ответить
52

Вот я читал книжки про алгоритмы, изучал все методы сортировки, разные сложности алгоритмов, всякие там обходы, минимальные значения, деревья и прочую классную штуку, и ничего из этого я не помню так, чтобы сходу на доске нарисовать - потому что уже пятнадцать лет как всё это не нужно для работы. Но эти знания легко вспомнятся, освежатся при необходимости, потому что всё это однажды пройдено и осознано. (Да, я пробовал.)
Вот если вы перед собесом предупреждаете: "мы тут любим алгоритмы, извольте освежить", - тогда честь вам и хвала. А так, откуда рандомному человеку знать, какие у вас особенности? Одному алгоритмы вспомни, чтобы от зубов отлетало, другому принципы SOLID наизусть, третьему команды линукс-консоли, четвёртый захочет про Пролог поговорить, пятый про синтаксические парадоксы джаваскрипта...
Разработчик - это же настраиваемый биоробот. Если он в целом подходящий, то ему заточиться под конкретные задачи будет нетрудно. Вы же отсеиваете всех и ждёте того, кто просто удачно зайдет к вам сразу после прочтения соответствующего учебника. Нерационально.

Ответить
1

ну если вы вашим знаниям не нашли применения - это ваша проблема, верно? если вы устраиваетесь в компанию, где нужно быстро обрабатывать большие обхёмы данных, то внезапно все эти знания становятся нужны

ну и приличные компании объясняют, что там потребуется на интервью, у того же яндекса есть страничка со сслыками на leetcode, hackerrank, cracking code interview и т.д.

Ответить
1

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

Ответить
1

Прям даже интересно что вы разрабатываете.

Ответить
–6

UPD На самом деле ничего особо интересного.

Ответить
3

Это под NDA? Или сейчас окажется, что вы пилите очередной интернет-магазин на php, и тогда все ваши доводы про алгоритмы и вайтбординг пойдут прахом?

Ответить
–9

Нет, просто я полагаю, что вы умеете пользоваться интернетом и в состоянии нагуглить любую интересующую вас информацию.

Ответить
12

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

Ответить
–5

Спасибо, я полагаю, что для них очень ценно ваше мнение.

Ответить
24

А в JetBrains знают, что вы так себя ведете в интернетах в топиках, которые затрагивают имидж компании?

Ответить
0

Да ладно, всем и так понятно, что нужно в JetBrains или в Яндексе, имидж тут не испортишь илитарностью.

Ответить
43

Хз, у меня лично о JetBrains было несколько лучшее мнение до этого топика, я в целом и подписку с радостью платил. До сего дня. А у них там оказывается вот, собеседования на вайдбордах и илитарные разработчики.
Я просто очень и очень не люблю, когда люди в разговорах преплетают компанию, где они работают с налетом эдакой "илитарности". Прям аллергия.
Тем более что в 99% случаев говорить "мы" о компании где-либо в публичном пространстве могут только специально на то уполномоченные люди, к которым господин Андрей в должности Senior разработчика вряд ли относится.
Я про его фразу "Вот только мы как раз одна из тех компаний, где работать хотят многие, теория нужна для работы".
Меня прям подмывает спросить - это официальная позиция компании?

Ответить
–7

Заметьте, ни слова о элитарности не было (а если возникло такое ощущение, то готов извиниться), а про вайтборды и необходимость некоторого знания фундаменталки - это как бы не секрет.

Тем более, что явно я своего работодателя никак не упоминал, это уже вы откопали, когда вам стало интересно.

Ответить
22

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

Ответить
2

Наезжать на разраба упирая на то, что он забирает хлеб у PR-отдела - не очень достойная позиция для другого разраба. Ну и да, ни для кого не секрет, что в "Гуглы" без алгоритмов не берут. Логика такая - человека, который может вертеть алгоритмы из Кормена, хрен что остановит, а "матерого" фронтдера под React, может остановить всё что угодно.

Ответить
14

Я не упираю на то, что он у кого-то хлеб забирает, тем более у PR. Я наоборот предостеригаю коллегу от высказываний, которые наверняка нарушают пару пунктов его договора, т.к. прекрасно знаю что написано в контрактах у "кровавых энтерпрайзов" и сколько галочек и подписей он под этим всем поставил.
Как показывает мой опыт, человека, который может "вертеть алгоритмы из Кормена", останавливает практически любая практическая задача, когда надо не "алгоритмы вертеть", а "сделать конкретно дело, далекое от алгоритмов, но непосредственно относящуюся к его обязанностям" или "починить конкретную проблему, далекую от алгоритмов, но опять же непосредственно относящуюся к его обязанностям".
В том числе и человека из пресловутого Гугла, довелось мне с ними поработать. Просто потому, что между "алгоритмы вертеть" и "решать проблемы продукта\бизнеса" - гигантскя пропасть.
Это совершенно прекрасно, если человек умеет в алгоритмы, но он тогда в дополнение должен уметь и свою работу делать, на которую его нанимают, а вот тут - беда. Более того - это даже не проверяют (знаю из первых рук - своих). Просто на нужное место надо нанимать нужных людей и правильно их отбирать, а не ставить единую сетку отбора и для алгоритмописателей, и для TSE/SRE, допустим. Если первым точно надо отлично все это знать, то для вторых это конечно полезно, но не основопологающе. Но тут не мне решать, возможно сверху виднее, очевидно что их все устраивает.
При этом, я знаю людей, которые прекрасно умеют и то, и то.
Но их к сожалению в моей выборке (за 10+ лет) меньшинство, но даже корреляция между "вертеть алгоримы" и "делать дело" не особо прослеживается, если только "делать дело" это не "писать алгоритмы", что чаще всего не так.

Ответить
1

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

Согласен, но может у них действительно задачи неординарные, особенно, если это отдел, связанный с Kotlin

Ответить
0

Как показывает мой опыт, человека, который может "вертеть алгоритмы из Кормена", останавливает практически любая практическая задача,

и у человека есть 5+ лет опыта? или вы о студенте?

В том числе и человека из пресловутого Гугла, довелось мне с ними поработать.

стесняюсь спросить, как же гугл до сих пор держится?

даже корреляция между "вертеть алгоримы" и "делать дело" не особо прослеживается,

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

Ответить
0

Спешите видеть! Сисадмин рассуждает о пользе алгоритмов!

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

Ответить
0

Давайте, чтобы не было путаницы. Там где я пишу "я" - действительно мое личное мнение. Оно может быть предвзятым и каким угодно.
Там где я пишу "мы" нет ничего, что в общем случае противоречило бы известной мне политике компании и ничего что бы вы не могли узнать у рекрутера, увы. И там я как раз отвечал на комментарий про "базовый набор ценностей", а не про свое личное мнение.

Ответить
–2

Andrew Vasilyev, Я, кстати, подписку JetBrains покупаю и всем советую, главным образом, потому, что Нестерук - няша, а не пафосный токсичный хер.

Ответить
0

Мир меняется и компания таковыми обрастает. Не буду продлевать свою подписку, пожалуй

Ответить
0

Вы не поверите, но они о нем даже не узнают! Рассказать почему? Хотя нет, вы наверно и сами разберетесь.

Ответить
0

Ракеты "Авангард"?)))

Ответить
0

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

Ответить
0

В такой формулировке соглашусь, конечно же.

Ответить
1

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

Ответить
6

Помню мы в универе программировали в тетрадке ручкой. А ещё нам говорили, что хороший программист всегда носит с собой дискету. Шёл 2005 год.

Ответить
2

Вот видите, знания универа вам пригодились!

Ответить
1

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

Ответить
0

яндекс, гугл и прочие крупные компании

Ответить
2

Без негатива. Как вам такой тезис: все что есть в свободном доступе и нормально задокументированно не должно мешать найму сотрудника даже если он не смог ответить? Ведь не все алгоритмы в мире юзаются у вас. Есть тех.собес, где можно выяснить сумеет ли соискатель выдрочить нужные вам, есть испытательный срок чтобы проверить не спиздел ли он, есть тимлид который это проверит... Пример: вот на прошлой работе кандидат писал лютую асинхронщину, но не втыкал в алгоритмы, а вы ему на собесе заворачиваете теорию графов и футболите за незнание ее незнание. Собсно вопрос: кто тут некомпетентный мудак?

Ответить
0

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

Ответить
0

Вы правы. Прошу прощения. Мое мнение тут не прав hr (или собеседующий технарь). Переспрошу: Вы считаете это нормальная ситуация?

Ответить
3

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

Ответить
0

Базовые и полезные вещи забываются, невозможно знать и уметь всё. Человек 2 года делал сложное А, а вы заворачиваете его потому что у вас сложное Б. При том что если дать ему времени он вполне сумеет и ваше сложное Б и станет ценным кадром.

Ответить
0

а зачем? пусть идёт в компанию где нужно А, не тратя ни своё ни чужое время

Ответить
0

Тут речь немного о другом - они ищут(чисто мое предположение) человека, который жонглирует алгоритмами лет 5-10 (да Вы не ошиблись, лет с 12ти, со школы). И в таком случае, человек, который может посмотреть какой-то вариант алгоритма в инете им не очень подходит(вернее совсем). Потому что им нужен не сам алгоритм, а возможность выкрутить его совершенно наизнанку и заставить его работать так как надо им.

Ответить
0

Скорее "свести задачу с неизвестным решением к известному алгоритму с известными характеристиками или близкому к нему". Для этого не нужно заниматься с этим с детства или быть олимпиадником, достаточно вдумчиво прочесть одну-две книжки или послушать лекции в вузе или даже на Ютубе.

Ответить
0

Присоединюсь к предыдущим ораторам.
Автор оценивает кандидатов грубо говоря по софт скилам и берет всех «хороших парней»: «даже обезьяну можно научить кодить». Вы же фильтруете по знанию BFS-а и DFS-а. Вроде ничего особенного. Вроде культурный разраб должен это знать. Отбираются явно более «умные» в некотором роде. Но действительно ли это важнее? Не кажется ли такой фильтр искусственным? Действительно это используется в работе или 4-часовое «евроинтервью» нужно только чтобы уменьшить непомерный поток желающих в Яндекс или в Jetbrains. Вы уже отвечали, что да, используется. Вам оппонировали, что можно нагуглить. Но все же...
В Касперском, например, упор не на алгоритмы, а на технологии, но сомневаюсь, что задачи принципиально отличаются.

Ответить
0

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

Ответить
0

Если вас интересует мое личное мнение - то я тоже уверен, что любому можно объяснить про BFS и DFS. Только вот я так же уверен, что "хороший парень" уже на основании постоянных срачей в интернете на эту тему в силу природного любопытства потратит неделю на прочтение одной книжки, что уже сильно увеличит его шансы и сделает лучше как программиста. А "плохой" потратит то же время на доказывание того, почему именно он прав, а собеседования - токсичные, а потом даже не поймет, когда посадит в продакшн n^3 на пустом месте (и тем более не поймет что ему гуглить и что ему вообще надо погуглить). И ведь это же тоже про софт скиллы и "get shit done". Вайтбординг ни разу не дает гарантии найма хорошего разработчика, но очень эффективно отсекает людей с неправильной мотивацией.

Ответить
0

Ну вот видите... вы тоже признаете главенство «софт-скилов». А вайтбординг - он не для всех.
Насчёт Каспера - даже не знал, что здесь есть вайтбординг. Пронесло славбогу. Собеседовался в 5 команд, нигде его не было.
Это ещё раз подтверждает, что вайтбординг это команд-левел традиция и не более.
Я знаю алгоритмы Дейкстры, Прима, Крускала, блум фильтр, минхэш, симхэш, гиперлоглог, но вайтбординг не для меня. Надо устроиться в крупную компанию - надо учить алгоритмы. Значит выучил. Надо значит надо. Но я не могу решить ничего! Даже самые простые задачи. Какой там нафиг даже BFS? Думаю о том, что скорее бы это истязание закончилось.
Так я не смог попасть в mail.ru, Яндекс, nvidia и проч и проч только из-за этого глупого вайтбординга. Немного привираю. В mail.ru вайтбординга не было, им мое резюме принципиально не понравилось.
Можно наверно с этим справиться, но собесы настолько не соответствуют реальной работе! Как на известной картинке, где на собесе сражаешься с врагами, а в реале с плюшевыми медведями.
Так что вайтбординг не для всех и судить по нему о чем-то не всегда возможно.

Ответить
0

все что есть в свободном доступе и нормально задокументированно не должно мешать найму сотрудника даже если он не смог ответить

тогда берите прям с яслей. вся CS более чем документирована, не говоря уж о математике

на прошлой работе кандидат писал лютую асинхронщину, но не втыкал в алгоритмы, а вы ему на собесе заворачиваете теорию графов и футболите за незнание ее незнание

а если он в футбол играл, а нам нужен прораб на стройку? если на вашу должность можно взять ЛЮБОГО программиста независимо от его знаний и опыта, то это фигня, а не работа

Ответить
0

Вы уж сильно-то не утрируйте. В моем примере речь скорее об одной специализации. Работал со стеком А, требуется на кандидат на стек Б. А не переобучаться с фронтенда на военные коммутаторы.

Ответить
1

Так и представляю диалог:
- Юрочка, а вот Андрюшенька, наш умный сениор разраб!
- Здравствуй Андрюшенька!
- Тамбовский волк тебе здравствуй! Ты на доске деревом вертел?
- Эм... нет, зачем?
- Я с ним не играааааю!

Ответить
0

Даже интересно, а от собеседующихся на hadoop, data science или BI, вы тоже ждете знания стандартных алгоритов??

Ответить
9

За кривую умения делать дела даже как-то обидно. С чего бы это это умение так стремительно падает?

Ответить
7

Я так понимаю "делать дела" = лепить костыли
И чем больше опыта (мудрости), тем меньше хочется этим заниматься.

Ответить
1

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

Ответить