В нормальном состоянии префронтальная кора свободно осуществляет высокоуровневое мышление. При стрессе выделяется большое количество нейромедиаторов, которые активируют сети, связанные с миндалевидным телом (эмоции), блокируя префронтальную кору
Миша отличный программист. Для него сложная задача — как личный вызов. Он затихает, молча бродит с отсутствующим взглядом несколько дней… Пока его не прорвёт. Тут словно огонь загорается в глазах, парень светится как маньяк, и даже влюблённая девушка не вытянет его из кода поздним вечером. Реально гений.
Но есть проблема. Мишу трудно понять. Видно, что в голове куча мыслей и абстрактных концепций. Но выразить словами толком не получается. Все предложения словно кубики из разных конструкторов, которые никак не скрепляются в единое целое.
И самое главное. Миша прекрасно знает, что он, мягко говоря, не великий оратор. И как только его просят высказаться в незнакомой компании или на собрании с начальством, то сразу начинает волноваться — и ситуация становится ещё хуже. Мысли путаются, он пытается подобрать слова… но его опять никто не понимает, кроме друзей. И парень волнуется ещё больше, краснеет, и кажется, уже сейчас заплачет, но просто машет рукой и садится в раздражении.
У людей есть реальные физиологические и психологические особенности, которые трудно исправить. И не нужно. Зачем ломать физиологию и психологию человека, если мы говорим о чертах личности. Тренировать интроверта выступать перед публикой — это как учить «сову» вставать в 5 утра. Конечно можно, но путём жёсткого вмешательства и переделки психики. Прямой путь к выгоранию и антидепрессантам. Стоит ли оно того?
Некоторые разработчики не способны связать слова в устной речи, но при этом остаются высочайшими профессионалами.
Другие пишут с ошибками.
Третьи подолгу обдумывают слова, а на собесе надо реагировать быстро. С первого взгляда такой человек может показаться слегка «заторможенным», хотя в реальности у него IQ 180. Слишком мощный интеллект и огромное количество усвоенных абстракций мешают сообразительности, не дают быстро реагировать на слова и чётко отвечать на любые вопросы, как это делают менеджеры («Без проблем, мы нарисуем пять перпендикулярных линий!»).
А ещё обострённая реакция на стресс.
Сразу отметим, что полное отсутствие страха — это жёсткая психическая аномалия, с которой человеку чрезвычайно сложно дожить до старости за пределами психушки.
Так что страх — это нормально. Вопрос в том, как именно обострённая реакция на стресс изменяет поведение человека.
Как меняется мышление в условиях стресса
Реакция человека на стресс обусловлена эволюцией. Миллионы лет стресс был связан с физической опасностью. Отсюда выброс гормонов, прилив крови к мышцам, повышение давления, учащение дыхания и т. д. Всё логично. Нужно убегать от врага или вступать в драку.
В наше время источники стресса изменились — дедлайны, ипотека, собеседования. Но физиологическая реакция осталась такой же, как была 60 000 лет назад, в момент появления хомо сапиенса на нашей планете.
В контексте рабочих собеседований важно понимать, как изменяется работа мозга в таких условиях. Понятно, что ничего хорошего ждать не приходится. Мозг явно не приспособлен для абстрактного мышления и долгосрочного планирования в ситуации, когда на вас прыгает леопард.
Учёные проводили массу экспериментов для изучения работы мозга добровольцев в условиях стресса. И сейчас известно, что больше всего от стресса страдает префронтальная кора, которая отвечает за некоторые интересные особенности мышления, а конкретно:
- абстрактное мышление;
- планирование;
- концентрация внимания;
- обработка больших объёмов информации;
- терпение.
Как показали исследования на лабораторных животных и людях, даже относительно слабый стресс может заглушить сигналы этого центра.
Хронический стресс
Характерный эксперимент был проведён в 2008 году на выборке из 20 студентов-медиков, которым предстояли экзамены на получение лицензии. После месяца напряжённой подготовки к экзаменам паникующие студенты показали худшие результаты в тесте на внимание, чем после окончания экзаменов.
Воздействие психосоциального стресса в течение месяца перед первой сессией сканирования связано с изменением функциональной связности в левой и правой дорсолатеральных частей префронтальной коры (DLPFC). Стресс уменьшил связь между левой и правой DLPFC, премоторной, вентральной префронтальной корой (PFC) и задней теменной корой (PPC), но увеличил связь с областями средней височной доли. Повторное тестирование через месяц не зафиксировало отличий от контрольных уровней, источник
Сканы МРТ показали, что под воздействием хронического стресса у студентов ослабли связи префронтальной коры с другими областями мозга. Однако через месяц после экзамена показатели вернулись в норму. Результаты опубликованы в научной статье «Психосоциальный стресс обратимо нарушает префронтальную обработку и контроль внимания», журнал Proceedings of the National Academy of Sciences, 20.012009; 106 (3) 912-917; doi: 10.1073/pnas.0807041106.
Влияние стресса на функцию префронтальной коры (PFC) у подопытных крыс (вверху) и человека (внизу). Как видим, хронический стресс явно нарушает функциональную связность DLPFC и замедляет скорость переключения внимания (attention shifting), то есть снижает концентрацию внимания, источник
Таким образом, человек может внешне выглядеть нормально. Но если он живёт в состоянии хронического стресса, в некомфортных условиях, под воздействием различных угроз, психологического давления (дедлайны на работе, эпидемия ковида, криминогенная обстановка в стране и др.), то префронтальная кора будет работать не оптимально. От этого страдает концентрация внимания, рациональное мышление и долговременное планирование.
Для мыслительного процесса необходимое условие — комфорт, отсутствие стресса и любых «напрягающих» факторов.
Человек в комфортных условиях мыслит более ясно, логично и рационально.
Другой вопрос, что в условиях стресса возрастает внешняя активность человека. Поэтому некоторые менеджеры зачастую умышленно создают атмосферу стресса для повышения производительности труда. У них даже есть выражение «выйти из зоны комфорта» — способ искусственной генерации стресса с мобилизацией трудового ресурса и повышением видимой активности («Все забегали-забегали»).
Но это бестолковая, нерациональная активность.
Отсутствие плана
В текущему году был проведён ещё один интересный эксперимент по когнитивной нейробиологии. Он иллюстрирует, как стресс мешает вдумчивому планированию.
В этом эксперименте участвовали 38 человек. Они выучили несколько маршрутов по виртуальным городам, а также расположение узнаваемых объектов, таких как зебра, яблоко, степлер и лицо Тейлор Свифт.
Вопрос заключался в том, как в условиях стресса (слабый удар током) людям найти дорогу к заданному объекту, например, зебре. Испытуемые не знали, когда их будут бить током, и не могли контролировать ни один аспект эксперимента.
Как показал эксперимент, люди в стрессе выбирали короткий путь в 31% случаев, тогда как среди испытуемых в нормальном состоянии таких оказалось 47%. В состоянии стресса люди всё равно достигали нужного им объекта, но окольными путями.
Сканирование МРТ показало, как дополнительный стресс влияет на мышление добровольцев. Разбросанные по городу предметы вызывали узнаваемые паттерны мозговой активности. По этим паттернам исследователи могли определить, когда люди думали о каком-то конкретном пути. Участникам давалось восемь секунд на то, чтобы спланировать путь к целевому объекту. У людей, не испытывающих стресс, обычно был план: мозговая активность содержала паттерны объектов, расположенных вдоль кратчайшего пути. Нейронные сигналы о наличии плана проявлялись даже у тех, кто выбрал привычный маршрут.
А вот люди в стрессе не проявляли признаков планирования. Они действовали словно на автопилоте.
У подопытных стресс снижает активность участков мозга, необходимых для планирования, включая часть префронтальной коры и гиппокамп — структуру, важную для памяти. Эти результаты свидетельствуют о том, что в состоянии стресса труднее вспоминать усвоенные знания.
Учёные приводят параллель между лабораторными стрессами и сложными и длительными стрессами в реальной жизни. Участники эксперимента пытались сделать что-то сложное, одновременно беспокоясь о чём-то другом. Стрессор действует на заднем плане, мешая ясно рассуждать и планировать свои действия.
Результаты этого эксперимента опубликованы 18 мая 2020 года в журнале Current Biology (doi: 10.1016/j.cub.2020.03.006).
Навык прохождения собеседований — отдельный скилл
Вернёмся к нашим собеседованиям.
Очевидно, что навык прохождения собеседований — это отдельный скилл. Он прокачивается отдельно. Самое интересное, он практически не связан с основной работой.
Если говорить конкретно о стрессе, то есть специальные методики, как с ним справляться наиболее эффективным образом. Например, вот научная статья о подготовке бойцов тактического подразделения Сил специальных операций ВМС США (Navy SEALs). Оказывается, люди под влиянием стресса могут демонстрировать «положительные, даже преобразующие изменения в поведении». Эти изменения в поведении «более вероятны, если человек находится в соответствующем состоянии сознания», которое достигается путём тренировки.
Если вкратце, то обученный человек готов к стрессу, видит его наступление, знает об изменениях мышления. И во время физиологической реакции (выделение нейромедиаторов) использует её с выгодой для себя. Он понимает, что разумное планирование невозможно, поэтому работает по выученному сценарию для таких ситуаций. И благодаря огромному количеству возбуждающих нейромедиаторов действует по этому сценарию даже эффективнее, чем человек без стресса. Статья опубликована 15 января 2020 года в журнале Frontiers in Psychology (doi: 10.3389/fpsyg.2019.02962).
Комментарии (203)
vgogolin
24.12.2021 12:03+15Есть парижское кабаре, кто называются Crazy Horse. Процесс отбора туда - рост, вес, объем груди. Все должно быть не больше, не меньше установленного стандарта. Тенденция современных собеседований начинает всё больше напоминать этот отбор. Не важно какой у тебя был прошлый опыт и насколько сложные системы ты поддерживал и вытаскивал из глубокого легаси... Вот не можешь онлайн за 20 минут решить публично задачку с Leetcode - значит не программист )
novoselov
24.12.2021 12:16Дело не только в стрессе или магическом умении прохождения собеседования. Есть условно говоря 2 типа программистов: те кто быстро херачат и мало думают и те кто долго думают, медленно делают. Хорошую команду можно собрать из обоих групп, некоторые компании специально выделяют быструю команду которая делает работающий MVP и тестирует разные теории. Вторая медленная команда отрабатывает уже проверенные теории, они делают полноценный анализ моделей, потоков, потребностей, прорабатывают архитектуру, выстраивают процессы разработки и жизненного цикла, и т.д. По сути это реализация подхода: Make it work, Make it right, Make it fast
По опыту первая группа больше любит хакатоны и лайвкодинг в стиле Google. Люди из второй группы более глубоко могут описать проект и принятые решения. Стресс при этом больше влияет не на конкретный этап, а на реакцию в незнакомой ситуации, поэтому чем больше знаешь, тем меньше неожиданностей может быть на интервью ;)
DarthVictor
24.12.2021 15:52+5Не важно какой у тебя был прошлый опыт и насколько сложные системы ты
поддерживал и вытаскивал из глубокого легаси... Вот не можешь онлайн за
20 минут решить публично задачку с Leetcode - значит не программист )В больших компаниях это не от хорошей жизни. Если не вводить трудно подделываемых критериев приёма на работу, то 2/3 сотрудников будут наниматься потому что они с кем-то из сениоров или тимлидов вместе служили / бухали / ходили в один гей-клуб. В фаангах по пять разных ревьюеров не на пустом месте.
В свою бытность работы в одном хорошо известном банке я там видел несколько весьма посредственных разработчиков, кажется они Jir'у поддерживали. Про одного из них я точно знал, что он работал, потому что его забыли уволить в течение испытательного срока, а ещё пара его коллег были не лучше. Они могли по нескольку недель делать вид, что занимаются какой-нибудь фигней, которая делается за полчаса, читая при этом книжку / сидя в интернете. И таких людей много. А с появление массовой удалёнки такая работа и вовсе стала желанной даже для хороших разрабов с изрядной долей цинизма. Бёрешь такую работу второй / третей и тратя пору часов в неделю на кивание в зуме и имеешь + 50% к зарплате.
В общем любите литкод и живые собеседования — это последние рубеж, отделяющий вас от миллионов красиво брешущих джунов, вайтишников и просто нелюбителей неприкасаемых.
SwingoPingo
24.12.2021 17:04А каким образом литкод исключает любителей двух часов на кивание в зуме? По моему он как раз вероятность и повышает.
Да и то, что книжки читают это в плюс.
jarvis
24.12.2021 20:06+3Так никто не мешает циничному, но хорошему разработчику поднатаскаться на литкод задачах, а потом точно также устроиться на вторую-третью работу, чтобы ничего не делать.
Это даже еще проще будет, если везде собеседования одинаковые и везде требуют литкод задачи, то задача хорошо пройти собеседования упрощается.
Yser
24.12.2021 20:27+5Со мной работает персонаж который думает что он написал сложные системы и что он решал сложные задачи, и.т.к. он нейтив он может рассказать об этом во всех красках. По факту - он никакой программист и как только встречается что-то чуть более сложное чем заявлено by default у него начинается истерика.
Итого, на словах - он поддерживал сложные системы, любая же валидация его опыта приведет в фейлу.
vassabi
25.12.2021 01:03+7А если он при этом умеет еще и рассказывать - "какой он молодец", то вот увидите - он еще вырастет до вашего начальника.
pyrk2142
24.12.2021 12:34+12Реально гений.
Пожалуйста, не бросайтесь такими фразами. Программист, который вроде как умеет решать вроде бы сложные задачи - не гений. Возможно, он талантливый. И это уже довольно редкое явление. Гениальный программист - это тот, чьи действия настолько продвинут индустрию, что не потребуется объяснений, почему он гений. И уж точно у него не будет проблем с прохождением собеседований.
i360u
24.12.2021 12:55+7Пока индустрию не продвинул - проблемы будут. А когда уже продвинул, не будет собеседований. Абсолютно ничего страшного во фразе из статьи нет, пожалуйста не бросайтесь такими предложениями.
zirf
24.12.2021 13:01+5Сказать честно, современное ИТ мало требует гениев на производство. Там станки... станки. Рутина. Человек с исключительными способностями как правило, аффектик. И для стандартной "командной игры" он мало приспособлен. Объяснить ход своих мыслей он не может, так как процесс мышления в фазе возбуждения (маниакальной, когда-то использовали термин "Депрессивно-маниакальный синдром", но чтобы человека не стигматизировать сейчас говорят "Биполярное аффективное рассторойство", он далеко не всегда серийный убийца) толком не изучен, похоже он не в состоянии запомнить ход мыслей. Кажется, что это озарение. Увы, за способность он расплачивается депрессиями, плохой социальной адаптацией. Да и самое главное. Плохо если ведущий собеседование технарь просто не умеет их проводить. Это 90% случаев. Еще хуже если он сам из таких. Не дай бог, соискатель умнее его. Для него это больно. И как как в "Красном драконе" Томаса Хэрриса, Ганнибал Лектор, уже в психушке кричит Грэму, "Да Вы меня поймали, потому, что Вы такой же как и я!".
vectorplus
24.12.2021 13:11+2Про социальную адаптацию ничего не написано. Может, он душа компании и мировой парень, которого все любят, ас командной работы. Ну, не оратор, так что теперь.
i360u
24.12.2021 13:17+8Точно. "Бизнесу" нужна предсказуемость посредственностей но результаты гениев. Этот неразрешимый конфликт приводит ко многим, широкоизвестным гримасам современного найма.
Uze_zanyat
24.12.2021 18:28+10"на рынке наблюдается дефицит высококвалифицированных низкооплачиваемых кадров"
TokarLimadze
24.12.2021 20:05Не дай бог, соискатель умнее его. Для него это больно.
Странно слышать, учитывая, что "покупаются" мозги.
А почему ему больно?
vassabi
24.12.2021 20:10+3так ведь не собеседующий же их покупает!
насчет больно - могу только предположить, что это больно для людей с развитым нарциссизмом (а-ля "один я дартаньян в белом").
zirf
24.12.2021 20:57+1Вам ответили, но добавлю. Такой "умный" свою умность осознает. 95% людей - обычные. Он не относится к ним снисходительно или презрительно. А вот ему подобный вызывает зависть, если он лучше, и презрение если хуже. Многие способны это подавлять. Но не все.
Да, покупаются не мозги. Бизнесу нужен результат.
i360u
24.12.2021 13:07+11Когда я волнуюсь, у меня пальцы не попадают по кнопкам на клавиатуре. От чего начинаю еще больше волноваться. Это как с заиканием. Поэтому ненавижу лайвкодинг. Код на бумажке - это вообще признак процветающего маразма в компании, если мне предложить такое - сразу вежливо попрощаюсь. Мне есть что показать и что рассказать, и если кому-то это не интересно - мне становится взаимно неинтересно. Пока что мои принципы меня ни разу не подводили.
fkafka
24.12.2021 16:37+1Лайвкодинг или код на бумажке могут быть разные. Я лайвкодинг очень люблю, и у меня вообще никогда на лайвкодинге не просили написать прямо готовый к исполнению код - достаточно было начеркать какой-нибудь псевдокод который бы демонстрировал принцип решения задачи. На бумажке то же самое. Писать на бумажке тест SQL или C# это бред, но схематично нарисовать на бумажке идею какого-то алгоритма почему бы и нет.
JustDont
24.12.2021 19:09+1Поэтому ненавижу лайвкодинг. Код на бумажке
Но… первое и второе — две большие разницы. В 2021 году нет ни малейших проблем лайвкодить в IDE, а не на бумажке/доске, и не в текстовом редакторе без языковой поддержки.
fkafka
24.12.2021 22:22+3Хороший лайвкодинг это как преферанс с друзьями - тут важна не игра и результат, а общение. Поэтому, мне нравится писать код параллельно его с кем-то обсуждая. И ревью кода, поэтому, часто может быть даже интереснее чем написание самого этого кода.
Бывает, конечно, жесть. Но существование отдельных дебилов всегда имеет место быть. Однажды договорился с HR об интервью с лайв-кодингом. Ну, говорю, отлично, я не против. Оказалось, что там надо задачу на Литкод решать прямо в самом литкоде (т.е. вбивая код просто в <textarea> на странице) без IDE, остального интернета и вообще без присутствия технических специалистов, а только под надзором HR (а то вдруг я все-таки IDE запущу, или на diocs.microsoft.com полезу). Это писец. Я просто сразу же написал ей, что, типа, извините за ваше потраченное время, но я этого делать не стану :)
aelaa
24.12.2021 13:30Видно, что в голове куча мыслей и абстрактных концепций. Но выразить словами толком не получается.
А кодом получится? Я сам иногда говорю транслируя код в русский язык, не очень чисто, но понимаемо.
Но проблема даже в другом.
А понятным и легко читаемым сторонним разработчиком кодом? Если у него в голове каша, что у него в коде?
А документацию написать? "Not my obligation"?
И должен ли такой "программист" проходить собеседование, если он не проходит по всем требованиям, кроме одного - знать как писать код?
Ritan
24.12.2021 13:40А документацию написать? "Not my obligation"?
Так написание документации к коду - довольно формальное занятие. А что-то более литературное( и лицом к пользователю ) - извините, тут есть технические писатели.
Если у него в голове каша, что у него в коде?
Так каша то потому, что не можешь выразить словами то, что происходит в голове. Кодом выразить проблем нет.
И должен ли такой "программист" проходить собеседование, если он не
проходит по всем требованиям, кроме одного - знать как писать код?Так стоп, знать как писать и что писать - это и есть основная цель. К тому же в спокойной обстановке всё заметно лучше, чем при публичном выступлении
aelaa
24.12.2021 14:02-2Даже тут всегда есть фактор дедлайна.
знать как писать и что писать - это и есть основная цель
А вот тут сильно холиварный вопрос.
vassabi
24.12.2021 19:29+4И должен ли такой "программист" проходить собеседование, если он не проходит по всем требованиям, кроме одного - знать как писать код?
вы там точно программистов набираете, а не лидов - тимлидов, техлидов ?
знать как писать и что писать - это круг обязанностей специалиста, коммуницировать с людьми и управлять проектом - это немного другой круг обязанностей. Меня конечно радуют попытки переложить его с менеджеров на программистов, но вы там обозначайте тогда вакансию корректно, а не просто "программист".
0HenrY0
24.12.2021 20:56Тимлидов со стороны берут не от хорошей жизни, только когда внутри команды нет ни одного подходящего кандидата. А откуда они возьмутся, когда для программиста простой разговор с человеком уже стресс.
vassabi
25.12.2021 01:01+1дело в том, что если у кого-то и лидерские и программистские качества развиты - то я обеими руками ЗА, чтобы таких людей нанимать (а потом растить внутри команды - хоть до ПМов).
Но мне тут рассказывают, что надо всем программистам быть еще немножечко и тимлидами, а если у человека таких склонностей нет - то таких на собесах брать нельзя, ибо общение! и софт-скиллы!
inkelyad
24.12.2021 14:13А что-то более литературное( и лицом к пользователю ) — извините, тут есть технические писатели.
Не пользовательскую документацию. А документацию для наследника твоего кода.
Так каша то потому, что не можешь выразить словами то, что происходит в голове. Кодом выразить проблем нет.
И нас всех в индустрии за подобных подход про умение писать документацию надо больно бить. Тупому компу, значит, словами объяснить что-то сложное можем. А значительно менее тупому человеку так же словами — уже почему то нет.
Ritan
24.12.2021 14:55А значительно менее тупому человеку так же словами — уже почему то нет.
Человеческие языки значительно более многозначные и неточные. Не просто так существует почти отдельный "юридический" язык, который непривычному человеку понимать достаточно сложно. Я частенько спотыкаюсь о попытку подобрать наиболее точно подходящее для передачи нужного смысла слово. В языках программирования набор встроенных "слов" сильно меньше.
Ещё забавнее выходит, когда нужное слово можешь вспомнить только на каком-нибудь другом языке( например, помнишь его на английском, но нужно-то русское слово, причём достаточно точно передающее смысл, чтобы не пришлось потом ещё минуту тратить на уточнения )
bankir1980
24.12.2021 21:27+1Самое забавное, что описание, скажем, функции - это по сути краткий(сжатый) перевод компьютерного языка в человеческий. А программист - это знаток компьютерного и вроде как сам должен уметь перевести :)
vassabi
25.12.2021 01:09+1о, про "быть знатоком и уметь перевести", напомнило классика: https://mislitel.info/quote-946879
vassabi
24.12.2021 15:09+1Тупому компу, значит, словами объяснить что-то сложное можем. А значительно менее тупому человеку так же словами — уже почему то нет.
Тупому компу никто ничего не объясняет - ему просто дают четкие инструкции как и что делать и связи между этими инструкциями.
Во-вторых, если это не просто менее тупой человек,а профильный специалист, то хорошо написанный код гораздо лучше документации, ибо код - не устаревает, а документация "как обычно" - не полна, устарела или недоступна (хорошо, когда все хорошо умеют писать на каком-то одном языке. А если например немецкий я умею только читать?).
Единственная документация, которая пишется человеком и при этом не устаревает при изменениях в коде - это тех. задание. Сами понимаете - в здоровых фирмах его пишут НЕ программисты.
inkelyad
24.12.2021 15:15+1то хорошо написанный код гораздо лучше документации
Только когда какому-нибудь фреймворку обучают, не сразу в его код посылают, а все-таки используют книжки, примеры, объяснения словами и видео итд итп.
Считать, что тот код, который не фреймоворк, а прямо в приложении чем-то легче в изучении — это как то очень оптимистично.
vassabi
24.12.2021 19:22+1Только когда какому-нибудь фреймворку обучают, не сразу в его код посылают, а все-таки используют книжки, примеры, объяснения словами и видео итд итп.
что-что? вы когда пишете про "книжки" - это про книжки без кода?
или "примеры" - это НЕ примеры кода ?
а "объяснения на видео" - там наверно в ютубчике всё на словах да на пальцах обучается, ни строчки кода, да?
Хорошо, когда вам дают задачу "вот фреймворк, вот ТЗ, сделай задачу с нуля"... Подавляющее количество задач - это как раз "есть код, он работает\не работает, там нужно еще фиксить баг\добавить фичу\прочая", поэтому смотришь уже существующий код и стараешься писать свой рядом - как можно понятнее для себя в будущем (или следующего, кто встретит твой код).
(и заметьте, после этого - у вас потенциально устаревшая документация, которую еще надо будет найти и поправить отдельно, если она была создана вручную. Поэтому я и люблю автогенераторы документации)
inkelyad
24.12.2021 20:17что-что? вы когда пишете про "книжки" - это про книжки без кода?
Нет, это про книжки, где написано (с примерами, разумеется), как используя существующий код (фреймворка) сделать то, что хочется. И в которых написано, какие вообще готовые кубики тут у нас имеются. Ну вот вроде таких, что тут живут. И бесчисленные статьи разного качества про него же. Хотя почему бы просто не скачать его и не научиться пользоваться ну вот просто по коду всех этих библиотек. Нет, потом ты в него полезешь, но вот сразу с этого кода начинать, никуда больше на заглядывая - это какое-то очень злобное предложение.
Соответственно, в идеале для этого вот нашего мелкого Legacy на н-ное количество сотен тысяч строк кода должна существовать книжка, где написано, как, используя то что тут у нас уже понаписано, сделать то что хочется.
поэтому смотришь уже существующий код и стараешься писать свой рядом - как можно понятнее для себя в будущем (или следующего, кто встретит твой код).
О да, смотришь и видишь, что одно и то же по смыслу действие делается в десяти разных местах шестью разными способоми при помощи четырех разных библиотек. Причем про два из них тебе говорят 'не надо так, это устаревшие варианты, просто их выпилить некогда'. И о том, что они устаревшие - сам, просто глядя на код, никогда не догадаешься.
А почему так? А потому что на очередной итерации предыщего 'идеологически правильного' способа просто не нашли или не осилили (документации-то по использованию нет) им воспользоваться и решили изобрести велосипед и/или сделать заново.
vassabi
25.12.2021 01:13+1не переживайте - любой "новый и современный код" написанный сейчас через пару лет будет "устаревшим вариантом". Любые книжки выпущенные сейчас с конкретными фреймворками - устареют через 5 лет (или даже раньше).
Во-вторых - всегда можно написать код плохо. С этим я не спорю и не спорил.
fkafka
25.12.2021 01:31Поэтому я и люблю автогенераторы документации
Это, конечно, вещь ценная, но, генераторы по сути выдают только reference по фреймворку, а освоить фреймворк только по reference это то же самое что выучить язык программирование только по формам Бекуса-Наура.
vassabi
25.12.2021 19:51вот кстати мне в документациях Оракла для SQL (PL\SQL) их тамошние формы Бекуса-Науэра нравятся поболее иных документаций,написанных маркетологами ...
fkafka
25.12.2021 20:08Я регулярно слышу, что в мире Оракла не все гладко, но чтобы там документацию писали маркетологи, такого я никогда даже представить не мог :))
А если серьезно, то как форма Б-Н сможет, например, описать внутреннее устройство индексов или отличие разных уровней изоляции транзакций?
vassabi
25.12.2021 20:22-1Я регулярно слышу, что в мире Оракла не все гладко, но чтобы там документацию писали маркетологи, такого я никогда даже представить не мог :)
я регулярно общаюсь текстом, но чтобы так извращали мои реплики, такого я никогда даже представить не мог :)
1) зачем вам документация про внутреннее устройство индексов ? вы хотите в них что-то внутри поменять ?
2) отличие разных уровней транзакции не описывается БНФ.
И вообще - при помощи БНФ не описываются различия (это как "какими красками нарисовать до-мажор?"), но вы можете прочитать их БНФ в той библиотеке, которую используете, чтобы их потом правильно написать у себя в коде.
PS: надеюсь вы ещё помните свое оригинальное утверждение:
освоить фреймворк только по reference это то же самое что выучить язык программирование только по формам Бекуса-Наура.
fkafka
25.12.2021 20:37+11) зачем вам документация про внутреннее устройство индексов ? вы хотите в них что-то внутри поменять ?
Ну, это точно так же как зачем мне знать чем отличается просто List от LinkedList - менять я ничего там не буду (да и не смогу), а максимум что плохого будет, это что где-нибудь вставка вместо O(1) будет всего лишь O(n)
чтобы их потом правильно написать у себя в коде.
Написать код правильным синтаксисом (который описывают Б-Н) это еще не значит написать правильный код.
vassabi
26.12.2021 00:32характеристики сложности - это все же не внутреннее устройство, а нормальное внешнее описание.
То что вы пишете про "правильный код" - это когда уже фреймворк усвоен.
Для его изучения и\или выучивания языка программирования спокойно можно использовать БНФ. Понятно, что потом можно начать смотреть "а что там под капотом" - исходники boost или std для сишников или java.util.concurrent для джавистов и т.д. Но это уже все потом.
fkafka
24.12.2021 15:21хорошо написанный код гораздо лучше документации
Твои б слова да богу в уши :)
fkafka
24.12.2021 15:14Тупому компу, значит, словами объяснить что-то сложное можем. А значительно менее тупому человеку так же словами — уже почему то нет.
Не срача ради :) У подобных "стрессонеустойчивых интровертов" которые свои мысли выражать могут только кодом зачастую и есть все "ну, тупые" кроме них самих и их кода. :)))
vassabi
24.12.2021 19:34для того тимлид предназначен, а не просто за "он тут давно уже работает", чтобы уметь переложить простыми словами техническое знание (для ПМов, ПродактОунеров, воспитателей детского сада и т.д.) и ровно в том объеме, который нужен для решения задач команды.
Если же именно код плохой - то понятно, что нет смысла таких писателей держать.
0HenrY0
24.12.2021 20:54-2Через пару лет этот человек станет тимлидом, а затем пойдет дальше по карьерной лестнице?
Или навсегда останется на этой должности, даже не сумев выстроить взаимодействие в команде?
vassabi
24.12.2021 14:07+2В голове как раз всё кристально и очевидно ясно.
Как только это из понимания сказать словами - вот где закавыка. Непонятно даже - откуда лучше начать рассказывать? С этапов старта и загрузки приложения? Или лучше с первого экрана для пользователя ? Или с базовых интерфейсов иерархии АПИ? Или все-таки с конфигурации по умолчанию? хммм....
PS: И про документацию - если это не комментарии в коде, из которых автогенерируется документация, то да, это "Not my obligation" - этим технические писатели занимаются. Да, я тоже могу это написать, но у меня это будет такого же качества как и сделанные мной же (а не дизайнерами) UI-мокапы - это будет в виде "сделано роботами для роботов".
lunacyrcus
24.12.2021 14:09+1Ну можно поспорить с отдельными утверждениями (как вот непонятный вывод о том мол незачем "интровертам" развивать "экстравертные" скиллы, и почему-то это мол приведет к депрессии и т.д.). Но так в целом довольно хорошая статья и может даже будет реально полезная многим.
Особенно этот момент важно учитывать, и даже не в контексте каких-то там собеседований, а вообще в контексте хоть какой-либо деятельности требующей сколь-нибудь сложных интеллектуальных усилий.
Таким образом, человек может внешне выглядеть нормально. Но если он живёт в состоянии хронического стресса, в некомфортных условиях, под воздействием различных угроз, психологического давления [....]
От этого страдает концентрация внимания, рациональное мышление и долговременное планирование.
А, еще со многими людьми такая забавная фигня наблюдается. Для них сами по себе интеллектуальные усилия -- это большой стресс, которые тянет за собой вот все подобные снижения качества мышления. Ну вот уж не знаю что о подобном сказать, наверно в любом случае (даже если для этого нет причин вроде этих вот некомфортных внешних условий что выше упомянуты) нужно как-то развивать общую стрессоустойчивость и иметь возможность осознанно влиять на свое мышление. Ну по сути самоконтроль, как это сделать и как это работает, то тоже огромная темка с кучей деталей.
fkafka
24.12.2021 14:50+2Очевидно, что навык прохождения собеседований — это отдельный скилл. Он прокачивается отдельно. Самое интересное, он практически не связан с основной работой.
Очевидно, что навык прохождения собеседований - это отдельный скилл. Он прокачивается отдельно. И он очень связан с остальной работой. Можно относится к этому как угодно положительно или негативно, но работать все равно приходится в некотором обществе, команде, комьюнити, или т.п. Поэтому хорошие профессиональные навыки это всегда будет совокупность технических и социальных и работать над ними надо всегда параллельно с самого начала. К сожалению, иногда это понимаешь позже чем хотелось бы.
vassabi
24.12.2021 15:12+3" И он очень связан с остальной работой"
ээ...а как именно? (ну кроме как "не получишь остальную работу, если не пройдешь собес")
Ritan
24.12.2021 16:04А какой именно навык очень связан с работой? Решение задачек про круглые люки, или, может, написание кода на бумажке? Ну если в вашей компании такое - повседневность, то хорошо, что я работаю не в вашей компании.
fkafka
24.12.2021 16:28+2Мне показалось, что статья вовсе не про круглые люки, или код на бумажке, а про людей которые могут провалиться на интервью из-за неумения общаться, выражать свои мысли, или из-за полной неустойчивости к стрессу. А я написал о том, что это такие же важные умения для работы как и технические, поэтому абсолютно нормально, что наличие или отсутствие этих умений влияют на выбор того или иного претендента на работу.
Ritan
24.12.2021 16:50+2Я бы не назвал это "полной неустойчивостью к стрессу". Собеседование - довольно специфичный стресс, где нужно доказывать, что ты не верблюд некоторому количеству людей, которых ты видишь впервые. И с работой такой стресс связан достаточно отдалённо. По работе я вообще новых людей не встречаю - мне норм. А на собеседованиях всё валится из рук и писать начинаю как первокурсник. Особенно если кто-то сидит над душой.
fkafka
24.12.2021 17:19доказывать, что ты не верблюд
Ну, про верблюдов доказывать еще не приходилось. Может быть имеет смысл просто сначала выбирать места куда на интервью ходить? А то в ином месте могут ведь даже избить и мобилу с бумажником отобрать :)))
netch80
24.12.2021 15:50+5Ещё в 99-м в Киеве была история — один очень высокоуровневый (все функции интернет-провайдера от BGP до настройки диалапа), но странный в общении сисадмин приехал в Киев из своего областного центра наниматься… со своим менеджером(!) Мы обсуждали это с офигением — он не мог сам? зачем менеджер? зарплату побольше выбивать? Дальше он очень быстро смог уехать, кажется, в США.
Позже я понял, что тут был где-то такой же случай: если проблемы в личном общении, можно организовать работу, но даже с непосредственным работодателем надо общаться особым образом, может, через выделенного человека.
Прохождение собеседования, да, тут усложняется. Ой не каждая фирма готова работать с таким…
LynXzp
26.12.2021 00:40Я слышал некоторые нанимают себе менеджера. Причем вполне себе такие сеньоры-экстраверты умеющие общаться. Личные менеджеры занимаются планированием и общей синхронизацией, но интересно чем-то еще занимаются? (Знаю одного такого программиста, но он говорил что это перенял у другого).
Люди попроще используют телеграм скрипты которые помогают уменьшить рутину общения. Но это уже тут не причем.
Ironcast
24.12.2021 16:55-4Послушайте, HR это ещё та фигня. Там где они есть у них точно такое стремление изображать свою работу как у чиновников - отчётность, бумажки. У них есть негласная норма по отсеиванию кандидатов, если свои внутрикастовые представления о том, каким должен быть кандидат и т.д Я многих и программистов знал, и ещё моя мама в советские времена программистом и я их помню их отдел НИИ, и её описание: там самые неуверенные, с блуждающими глазами люди были первыми во всём отделе. А там где есть HR, даже на склад не возьмут без знакомства, потому что .. отчётность у них. Чем больше кандидатов просеили - тем круче их "работа". Ещё с каким-нибудь психологическим образованием, какой-будь "тренер" -это вообще беда.
WraithOW
24.12.2021 20:41А там где есть HR, даже на склад не возьмут без знакомства
Вот это ничего себе. Я, оказывается, безработный.Ironcast
24.12.2021 21:42-2Не, ну возьмут. Минимум после 10 собеседований. Пару знакомых уходило на шабашки, надоело ходить по собеседованиям и ждать когда "мы вам перезвоним". У этих товарищей HR, даже когда мест нет, есть тактика помещать объявы. И там по сути на место грузчика рассказывают что нужно образование, мотивация, стремление к карьерному росту и подобный развод. На деле им никто в данный момент вообще не нужен. А когда реально нужны работники, узнать можно только по каналам знакомых, тогда уже берут если не всех, то многих. Так что знакомство не в плане "работа по блату", а просто нужна информация в данной сфере.
WraithOW
24.12.2021 21:51+1Ни разу не ходил по 10 собеседованиям, так что это, мелочишки не найдется?
Ironcast
24.12.2021 22:26Гы, я тоже, только по знакомым. Зато я очень важную подробность вспомнил. Как мой школьный товарищ, пусть это уже давно было, до кризиса 14 года, меня как-то огорошил "А я работаю на фирму ***. " С такой радостью, я подумал какое же счастье, погуглил, оказалась какая-то фирма-склад канцелярских товаров. Но с подобными понтами я знаком. В 2004 году я был связан с сисадминством одной фирмы по продажам сотовых, тогда на них был бум, прям как сейчас на джунов. И вечерам тамошним менегерам устраивали нечто вроде партсобраний, о том какая у них великая фирма, карьерная перспектива и пр. бред. И делали это HR, они же тренеры по продажам. Вверхом этого бреда было когда в салоне ввели рэп-музыку, в которой речитативом повторялось название фирмы. Потом этих тренеров попёрли и они перешли в банки, видимо, на склады , а теперь вот их услуги востребованы на отсеве джунов-тимлидеров-мидлов. Нет, ну есть у меня знакомые среди программистов, сверстники под 40 - "ведущие специалисты", но они этот жаргон при мне никогда не употребляли (может возрастное?!), сто пудов опять эти тренеры-мотиваторы, новоявленные парторги нашли новое применение.
Lexicon
24.12.2021 17:02+4Вау, мне очень тяжело проходить интервью целого класса, - "с задачками"
Но я не могу согласиться с текстом статьиВо-первых, тезис "собеседование это отдельный навык", - мало связан с навыками коммуникации, лидерства и тп.
Да, собеседование это общение, но разработчиков оценивают по неким, пускай эфемерным, но стандартам. Вам не обязательно иметь навыки коммуникации, чтобы пройти большинство интервью. Скорее умение противостоять стрессам и хорошо заученные ответы.
Некоторые разработчики не способны связать слова в устной речи, но при этом остаются высочайшими профессионалами.
Во-вторых, навык коммуникации - ключевой для разработчика, претендующего на звание"высочайшего профессионала", ибо профессиональная разработка, - командная разработка.
За пределами собеседования важно, чтобы человек нашел свое место в компании.
Прежде всего это важно для самого специалистаfkafka
24.12.2021 17:32+6Во-вторых, навык коммуникации - ключевой для разработчика,
Меня уже тут талантливые интроверты заикающиеся и забывающие таблицу умножения на собеседованиях заминусовали по самое не хочу. Так что зря ты тут это написал :)
Vlad_IT
25.12.2021 01:01+2Я социофоб, но плюсонул вас обоих, т.к. на своей шкуре испытываю эти проблемы. И чем выше по уровню становишься, тем ярче стает проблема
fkafka
25.12.2021 01:15+1Ну, я тоже часто могу быть и нетерпимым и раздражительным и иметь проблемы с коммуникациями (в том числе из-за этого), но я понимаю, что от жизни и работы в обществе никуда не деться, поэтому, если хочешь лучше жить, то нужно стараться хоть как-то над этим работать.
vassabi
24.12.2021 19:14-6Во-вторых, навык коммуникации - ключевой для разработчика, претендующего на звание"высочайшего профессионала", ибо профессиональная разработка, - командная разработка.
вы наверно хотели написать "претендующего на звание "тимлида""? Потому что общение с людьми, которые тебе достались по работе, - это не совсем про программирование, а уже немного управление персоналом
WraithOW
24.12.2021 20:44+3У вас если есть вопросы по багу — вы ждете, пока у вас тимлид спросит, где бо-бо, или идете к тестировщику и сами словами через рот уточняете, что там да как?
vassabi
25.12.2021 00:57+4нет, ни куда я не иду и никого не отвлекаю словами через рот. Я спокойно пишу в джиру "недостаточно данных, дайте сценарий\скриншот" и т.д. и отправляю тикет обратно на автора.
После чего автор тикета добавляет когда ему\ей удобно это вот всё.
WraithOW
25.12.2021 21:25Ну то есть всё таки общаетесь с людьми, мысли формулируете, выражаете их в каком-то виде. Что и требовалось доказать.
vassabi
26.12.2021 00:35да, я мысли формулирую и выражаю в каком-то виде, но это все происходит в формальном виде - я не общаюсь с людьми и не управляю их действиями (мотивация, контроль, критика, поощрение и т.д.).
И тем более - не словами через рот.
WraithOW
26.12.2021 00:51я не общаюсь с людьми
Обще́ние — сложный многоплановый процесс установления и развития контактов между людьми (межличностное общение) (...), порождаемый потребностями совместной деятельности и включающий в себя как минимум три различных процесса: коммуникацию (обмен информацией), интеракцию (обмен действиями) и социальную перцепцию (восприятие и понимание партнера). Вне общения невозможна человеческая деятельность.
This.мотивация, контроль, ..., поощрение и т.д
Это менеджерские функции, которые требуют навыков конструктивного общения, но ими не являются. Мимо.критика
Код-ревью — это критика. Вы можете провести код-ревью?vassabi
26.12.2021 01:11еще раз - там нет межличностного общения. Есть недостатки описания, я на них указываю.
Код-ревью — это критика. Вы можете провести код-ревью?
это не критика людей. Это описание замеченных мной возможных недостатков предложенного решения.
Я регулярно делаю код-ревью, но я думаю что не все, чей код я комментировал скажут "он умеет делать код-ревью" (если конкретнее, то я знаю как минимум 1 человека, которому не нравится мой код-ревью его кода. Но похоже это взаимно - его код-ревью моего кода не нравится мне :) )
fkafka
26.12.2021 14:35Мы практикуем взаимное код-ревью, у нас запросто даже джун может ревьюить код синьора. И это не критика, а обсуждение кода. А всякую фигню, типа стилистики кода и т.п. у нас робот-линтер ревьюит.
evil_random
24.12.2021 17:10+10У вас заголовок статьи конфликтует с тремя последними абзцами.
Я тот программист, который никогда не пройдёт собеседование. Но я прекрасно знаю про это своё свойство, поэтому перед собеседованиями я сначала читаю всё подряд, из разряда "что могут спросить", просто чтобы освежить речевые обороты и наименования в голове, а затем устраиваюсь на 3-5 трешовых собеседований в компании, в которых я никогда не буду работать (как правило это галеры), но которые сильно прессуют на собеседованиях, чтобы закалиться и немного расшевелить разговорную речь.
После этого можно смело идти собеседоваться в компанию мечты.
---
Не так давно, на собеседовании на позицию Senior Javascript Developer, ребята меня спрашивали из чего состоит IP-адрес и какие бывают классы сетей. Вот ради таких ребят, я их хожу на трешак всякий.
wolfy_str
25.12.2021 12:46Классы сетей это же 2 курс университета, причём у нас специальность не связана с сетями (но связана с IT вообщем). Так что не буду вас огорчать, но это обычно теория, которую знает студент теортик, а потом забывает. Для этого вообще не нужно никакого опыта.
evil_random
25.12.2021 13:54+2Так и я о том же. Конечно же когда-то я знал про классы сетей, не смотря на то, что не учился в университете. Но потом это успешно забылось и вопрос меня застал врасплох.
В подобных этому случаях, даже если я бы прошёл интревью, работать я бы к такому работодателю не пошёл. Если они так проводят интервью, то можно себе представить, что у них творится в компании.
wolfy_str
25.12.2021 14:36+1плюсую если бы мог :) мне вот после того как прошёл техническое отказали на менеджерском "недостаточно мотивирован". Ну вообще ппц отмашки. Хорошо ребята программисты поддержали, но отдел кадров с их HR отдельная песня (ладно хотя бы техническое собеседование не пройти, но менеджерское ПОСЛЕ технического - дурдом). Такие компании лучше обходить, даже с учётом того, что я не самый профессиональный программист
LynXzp
26.12.2021 01:02Ну с контекста еще не понятно действительно ли все так плохо. Слышал хорошие отзывы про компанию, где на одном из этапов собеседования спрашивают базовые знания в тех областях которые не пересекаются с резюме + рассказать последние новости из IT и практическое задание написать простенькую программу на языке который ты не знаешь.
vsb
26.12.2021 10:08А для чего они нужны? Я вот в университете или не слышал, или пролетело мимо ушей. Сейчас прочитал - чушь какая-то.
FloorZ
27.12.2021 03:36Уже не проходят. Шина, кольцо, звезда - все типы сетей времен коаксиала вымерли и остались гибридные сети, которые не классифицируются по типу соединения между устройствами и "хабом"
olku
24.12.2021 17:23Есть кто разбирается в тестах EPSO? Что проверяет verbal, numerical и abstract reasoning в стрессовых условиях? Явно не шаблонное поведение же.
CrocodileRed
24.12.2021 21:35+5Любопытная статейка, но я бы исправил заголовок на что-то среднее между существующим и " некоторые рекрутнры никогда не найдут хорошего программиста". Истина, как всегда, где-то рядом
via-site
25.12.2021 09:20Спасибо за статью! Попали прямо в душу. Я уже давно понял что стресс тестирование не для меня. Кидаю ссылку на гитхаб и предлагаю ещё сделать тестовое задание, дома в спокойной обстановке. Если не соглашались - значит не моя компания!
Driver86
25.12.2021 12:00Я думал, один такой)
Лайв кодинг не могу, сижу смотрю в монитор, а в голове будто бы какой-то блок.
Иногда доходило до смешного, оценивали как junior+
Да и в целом в общении не слишком, активен что ли. Некоторые собеседующие, ожидающие от меня инициативы, потом оценивали меня как якобы малоопытного.
И это при наличии 15 летнего опыта, наличию собственного успешного проекта, где я применил достаточно нетривиальные решения, вроде самописного быстрого хранилища под файлы (и, как выяснилось, в крупных стартапах а-ля TopFace придумали аналогичное). Про осталые нереализованные идеи, которые я придумал и описал ещё до того, как они появились и стали мейнстримом (Dropbox, GeForce Now), но не реализовал, т.к. не имел финансов, я вообще молчу. Наверное, будь я общительнее, сейчас бы стоял у истоков какого нибудь крупного сервиса...
zynaps76
25.12.2021 13:0125 лет в IT. Любой собес - это лотерея и вообще я там регулярно тупняков ловлю. Вот не мое это - "а, давайте код на доске/notepad напишем за 20 минут". Почему за 20? Почему на доске? А какую проблему мы пытаемся решить этим кодом? А эту боль-печаль точно нельзя решить по другому и лучше? И это... а мы точно первопроходцы и нет готовой либы, которая сделает лучше, чем я тут вам за 20 минут навелосипедю?
К таким фейлам отношусь спокойно. Ну ребята в этой команде пол дня решают типовые задачи с литкода в чужом нотепаде, строго в рамках ТЗ и с таймером. А я так не умею. Хех. :( Пойду лучше обычными и привычными делами позанимаюсь.
comerc
25.12.2021 14:53Я вообще не верю в банальные технические собеседования, а собеседования - моё любимое хобби. Завалил 99%. И меня выбирали без этого треша, и сам выбираю по другим критериям. Ошибка выжившего. :)
pyrk2142
25.12.2021 18:56+3Имхо, есть ещё один очень неоднозначный момент: а есть ли смысл так рисковать и нанимать такого программиста?
Приходит на собеседование Миша, код пишет на собеседовании криво, описывает свои действия с трудом, социальные навыки не очень хорошие. Попытки что-то ещё вытащить обламываются.
И приходит Вася, код на собеседовании пишет лучше, описывает то, что делает, и зачем, общаться с ним легко и приятно, вытягивать клещами ничего не надо.
И надо выбирать между ними. Но вот, неловкий момент, Миша часто просит не меньше Васи. И получается, что нанимающему специалисту требуется решить, почему ему надо нанять плохо показавшего себя Мишу, а не Васю. Дефицит кадров пока не настолько сильный, чтобы на соебеседование в адекватную компанию пришёл только Миша. Когда так будет (или там, где это уже происходит), надо будет учиться оценивать Миш (ведь не все из них плохо себя показывают, но хорошо кодят, кто-то ещё и кодит плохо). Когда дефицит закончится, и каждый сможет позволить себе выбирать специалиста, Мише будет ещё тяжелее.
vassabi
25.12.2021 19:58извините за нескромные вопросы, но
какой у вас опыт проведения собеседований? (можно округляя до лет и до десятков кандидатов)
как давно вы собеседовали кого-то в последний раз?
fkafka
25.12.2021 21:34как давно вы собеседовали кого-то в последний раз?
Вчера :)
vassabi
26.12.2021 01:01-1это хорошо! что скажете - быстро вакансии заполняются? Велика ли текучка?
а я давно уже никого не собеседую. Вообще моё ИМХО, после 5 лет найма людей - если хочет человек учиться и не дурак - всему можно научить и переучить и найти в итоге применение в проекте. Любому, хоть экстраверту, хоть социопату, хоть зануде. Для этого иногда потребуются усилия тимлида и ПМа, но это всё возможно, и знания фреймворков уже вторичны. А не хочет учиться (или хочет выучить фреймворк один раз и всё) - то увы.
(Или если менеджмент в позе "мы набираем только синьоров" или "нужно набирать таких чтобы их неучить, а чтобы сразу вджобывали" - то не только найм стагнировать начинает, а и команды начинают "голосовать ногами")
fkafka
26.12.2021 11:34По-моему, хорошего специалиста и не нужно ни о чем спрашивать. Нет необходимости. Ему просто тему какую-нибудь для начала разговора подкинь и он сам будет хоть часами с тобой о ней разговаривать :))
vassabi
26.12.2021 11:48тоже верно. В этом отношении показателен тред вверху про хеш-таблицы и сложность (куда даже 0xd34df00d не утерпел покомментировать, что я считаю признаком успешности флейма ) - там бы пиво, закусон и было бы трендежа на весь вечер - а кто какие структуры видел\писал в практике программирования, для чего и почему.
(про текучку и вакансии вы так и не ответили, но не буду настаивать - это действительно больное место :D )
fkafka
26.12.2021 12:35там бы пиво, закусон
Был случай еще в Москве. У нас тогда была небольшая команда и когда подыскивали человека, то с ним беседовали всей командой. А дело было запланированно на вечер пятницы, когда мы собирались пойти на Петровско-Разумовскую посидеть в "Бирмаркет" (я даже не знаю есть ли он там до сих пор). Естественно, всем задерживаться на работе из-за интервью очень не хотелось, и у тимлида родилась идея просто пригласить этого парня туда посидеть с нами, на что он с удовольствием согласился :)) Ну и отлично посидели, оказалось еще, что мы все знакомы по одному популярному тогда техническому форуму, правда, перень этот потом все равно выбрал другое место для работы, потому что у нас уж очень беда была с качеством унаследоанного кода (чего мы от кандидатов не скрывали).
sergeaunt
27.12.2021 05:19(Или если менеджмент в позе "мы набираем только синьоров" или "нужно набирать таких чтобы их неучить, а чтобы сразу вджобывали" - то не только найм стагнировать начинает, а и команды начинают "голосовать ногами")
Полностью поддерживаю такой подход, если компания может себе это позволить. А могут многие компании, и оттуда не бегут толпы сеньоров, которые вместо программирования хотят обучать молодежь без знаний но с горящими глазами.
Где набираться опыта джунам? Видимо, в компаниях, которые берут с улицы и учат. Ну или как я - в вузе. Да, представьте себе, некоторые вузы выпускают вполне себе мидлов.
sergeaunt
25.12.2021 21:26+3Ну вот, наконец-то здравые мысли.
Такое ощущение, что противники задачек рассматривают процесс найма только с точки зрения Миши. А поставьте себя на место интервьюера Пети, который знает, что из 100 заикающихся Миш, которые не могут развернуть список на собеседовании, 99 не смогут его развернуть никак и никогда. И сразу "а вдруг мы упустили гения" - ни разу не проблема по сравнению с "наняли говнокодера, который за наши деньги наплодил нам багов и техдолга, уволился и поливает нас грязью в интернете".
vassabi
26.12.2021 00:44то что вы пишете - перекливается с https://habr.com/ru/company/itsumma/blog/597561/comments/#comment_23870055 т.е. "уж лучше ложноотрицательный, чем ложноположительный".
я не против такого подхода, в нем ничего удивительного. Вот только в моей практике (ака "ошибка выжившего" :) ), это обычно как раз про тех, у кого коммуникативные умения развитее чем квалификационные - плодят техдолг и баги в архитектуре, а потом поливают грязью (и не только в интернете). Возможно, конечно, в вашей практике наоборот - это делают молчуны с заиками а не говоруны...
sergeaunt
26.12.2021 19:42Вот только в моей практике (ака "ошибка выжившего" :) ), это обычно как раз про тех, у кого коммуникативные умения развитее чем квалификационные - плодят техдолг и баги в архитектуре, а потом поливают грязью (и не только в интернете).
Охотно верю. Многие профнепригодные миши наловчились бодренько рассказывать про ключевые слова из своего внушительного резюме, но при просьбе закодить простейшую задачку вдруг превращаются в заик со сломанными пальцами.
zynaps76
26.12.2021 16:22+1Миш, которые не могут развернуть список на собеседовании, 99 не смогут его развернуть никак и никогда.
Это неправда и заблуждение. Попытка считать всех ниже себя, любимого. Этакий самообман. :-) Ну или HR-ы совсем мусорный трафик к вам гонят.
Поясню: пару недель назад на собесе надо было вывести порядок импортов библиотек. Втупил. Не решил вообще. Совсем. Собес завален. Тупой? Тупой. Ну и ладно. Cходил на ежедневный стендап, пообщался с коллегами по текучке. Поревьювил чужое, повыкатывал свое, позакрывал/подвигал таски.
Выдалась минутка - вернулся к задаче. Ба! Да, это же деревья с рекурсией. Гы. 10 минут и код готов. Ответ сходится. Скопировал код в туда, где интервью было. Думаете интервьювер вернулся посмотреть ради любопытства? Неа. Я ж тупой,- откуда там что возьмется. ;-)
И так процентов 80 интервью. С работой вообще проблем нет, если что. Не ищу - сама находит.
sergeaunt
26.12.2021 19:45Попытка считать всех ниже себя, любимого.
Всего лишь попытка оградить себя от работы с болванами. И пусть хоть весь мир ставит мне диагнозы.
zynaps76
27.12.2021 00:45Ага, вот поэтому 80% работодателей и не проходят этап собеседования с написанием кода. Оставшиеся 20% сливаются уже на финале, когда будущую ЗП озвучивают. ;-)))
romeoq
Периодически прохожу собеседования для саморазвития. Так вот, самые сложные вопросы обсуждаю с тех-лидом. В этом плане все хорошо.
Но как только дело доходит до лайв-кодинга или правок не совершенного кода в режиме онлайн - полный провал. На последнем собеседовании не смог хитро массив отсортировать, просто сидел, смотрел в монитор. В итоге отказался от продолжения мучений.
Думаю что стрессовые методы собеседований подходят не всем.
vassabi
случайно как-то в зуме, когда шаришь экран, попробовал Annotations - там можно рисовать как на доске! и обнаружил что мне жутко как нравится рисовать алгоритмы и структуры вместо лайвкодить - стрелочки, квадратики, как UML - sequence diagrams, structure, use cases - вот это вот всё.
Не знаю как с этим в других программах (я наверно буду там шарить там простую рисовалку и рисовать это всё в ней), но в общем рекомендую попробовать (особенно когда ступор в "рассказать словами\кодом") - показать рисунком.
romeoq
Надо попробовать, и я уверен что на графике с легкостью всю структуру алгоритма нарисую. А потом можно по этому графику и код написать.
Рисование алгоритмов - этот навык еще из ВУЗа остался, к тому же эти графики и на экзаменах рисовались, в стрессовых ситуациях, так что отличная идея.
Спасибо за подсказку.
ScarferNV
Потому что собеседовать тоже надо уметь. И понимать, что любой кандидат испытывает стресс, а его заставляют в такой обстановке решать не понятные задачи.
Интересно, если бы хирургов, собеседовали на операциях, сколько бы пациентов пострадало?
Так что, считаю, на собеседованиях давать кодить это бред. Совсем другое дело, просто поговорить по техническим темам.
Вот все говорит, то кандидаты не справляются. А может наоборот, работодаль не умеет собеседовать и не знает чего он хоачет и кого он ищет?
F0iL
Поскольку код, написанный на собеседовании, в продакшн не идёт вообще никогда, то разумнее было бы сравнить не с собеседованием на живом пациенте, а на препарировании трупа или манекена, и там никто не пострадает :)
А случаи, когда человек великолепно разговаривает на технические темы, делится опытом и решенными сложными случаями, в курсе о фичах и технологиях, отвечает даже на каверзные вопросы, а потом в реальной работе выдает такой лютый говнокод, что ревьюверы разбивают себе лицо, я наблюдал лично (привет парням из южной Азии), не знаю уж, что это было :)
kwasd
Один из моих друзей как-то раз устроился в компанию по разработке известного импортозаместительного дистрибутива для одной большой страны. В качестве тестового задания нужно было написать небольшую скрипт-обёртку для сборки пакетов под весьма популярный дистрибутив, что было с лёгкостью исполнено.
Оказалось что единой билд-системы у них нет, и каждый на своём рабочем месте фактически занимается допиливанием своего собственного тестового задания, но уже с целью собирать релизные пакеты.
Надеюсь, это лишь плод больного воображения моего товарища - ну не может же такого быть, правда?..
Alexandroppolus
Этот код был написан прямо на собесе в режиме лайвкодинга, за 15 минут?
Обычно тестовое задание - совсем другое дело. Оно хоть и крупнее чем литкод, зато можно спокойно потупить вечер, потом собраться с мыслями, сделать, отослать с припиской, что управился за 2 часа.
kwasd
Не в режиме лайвкодинга, но качество там действительно уровня "написал за полчаса".
Меня несколько больше смущает не качество отдельной тулзы в этой истории, а то что у каждого свой "наколеночный ad-hoc" делающий схожие вещи, и организаторов всего этого процесса ничуть не смущают риски такого write-many подхода. Некоторые из рисков (баги скриптов, человеческий фактор, и т.д.) таки "выстреливали" и приносили убытки предприятию.
Sky550
Обычное явление, создания нескольких похожих продуктов для вызова конкуренции отделов. Через некоторое время все отделы по хорошему пилят лучший (по объективным показателям) проект.
kalombo
Было дело и понимали, и по задаче подсказывали, и впечатление приятное оставалось, а задача мной зафейлена. Как вариант, просто не требовать обязательного решения задачи, а рассматривать по совокупности: опыт, решение задачи, тех. вопросы, софт скилы.
JediPhilosopher
Проблема в том, что люди очень любят врать, или хотя бы переоценивать себя на собеседованиях. И в резюме и на словах у человека все прекрасно, куча технологий и якобы опыта в проектах. Но закодить простую задачку типа разворота массива он внезапно не может.
Один раз взял такого, но чуда не случилось - в реальной работе он точно так же кодить не умел, и на любые задачи сложнее чем "по совету со стековерфлоу переложить данные из коллекции в коллекцию" впадал в ступор.
Так что увы, хотя бы простейший кодинг на собеседовании - необходимый фильтр для отбраковки тех, кто в принципе не может в программирование.
Alexandroppolus
Согласен. Буквально на этой неделе был такой чел. Красиво рассказал про сложные задачи на последней работе, но облажался на простейшем лайвкодинговом паззле (который, что самое смешное, был абсолютно по той же теме, что и рассказанное кандидатом).
FloorZ
А, какой пазл?
А то может быть вы просили написать реализацию для очень быстрого перебора и поиска всех вхождений для матч3
Alexandroppolus
На js, написать функцию глубокого копирования объекта. С доп. условием - внутри есть циклические и иные ссылки между элементами, то есть объект - не дерево. Это единственный лайвкодинг у нас на собесе. Обычно без доп.условия справляются, но последний чел не смог.
DrPass
Бывает и так, и так. Я, как человек, много раз побывавший с обеих сторон стола на собеседовании, могу сказать своё мнение: в целом нет ничего страшного в том, что кандидат испытывает стресс, и может растеряться и что-то там забыть. Собеседующий, если он опытный, это определит, и поддержит, поможет разобраться. Если он не опытный, ну, самое плохое, что с ними может произойти — они не возьмут этого специалиста на работу, а возьмут какого-то другого, а этот специалист в свою очередь пойдёт работать в какую-то другую компанию, где его лучше поймут. Разве это такая уж проблема?
А что касается самого стресса… ну да, бывает. И у меня бывал в начале. Но стараться убегать от стресса, это плохая практика, как по мне. Испытывая стресс в первый раз, во второй раз будет легче, в третий ещё легче, в пятый его вообще не будет. А если его избегать, тогда всю жизнь будешь бояться, обкладываться подушками и закапываться в песок.
Uze_zanyat
"ну, самое плохое, что с ними может произойти — они не возьмут этого специалиста на работу, а возьмут какого-то другого, а этот специалист в свою очередь пойдёт работать в какую-то другую компанию, где его лучше поймут. Разве это такая уж проблема?"
Оплачиваемые люди за счет компании упускают возможность решить проблему. Человек, нуждающийся в работе, пойдет на другое собеседование, будет терять время.
Разве это такая уж проблема?
StriganovSergey
.
sim31r
А в какую сумму проблема? При оплете в 375 рублей в час, проблема на 375 рублей ровно, или около 5$. Просмотр еще одного кандидата к N кандидатам просмотренным. Для самих кандидатов собеседования часто как развлечение, даже не собираясь менять работу многие проходят собеседования.
DarkTiger
Давайте посчитаем
Поскольку на собесах обычно сидят сеньоры и обычно вдвоем, а у них зарплата около 300К в месяц на руки, то мы получаем (300 000/180)*2 = ~3300 р/ч на руки или 5000р расходов чистыми, включая накладные. И это мы еще закинули в накладные расходы на сидящего на собеседовании HR, ожидание опоздавшего (как всегда) кандидата, выписывание пропуска, обсуждение результатов собеседования и т.п.
А теперь вспоминаем, что сеньор приносит прибыль (иначе зачем он нужен), это раз, и их на рынке найти трудно, это два. Поэтому я бы оценил одно собеседование для компании в 7-10К руб. В принципе - тоже не очень много, на фоне общих расходов компании, но все же жалко и их
WraithOW
А теперь прикиньте траты, если вы наймете человека, проонбордите его, потратите на него время кадровиков, админов, тех же синьоров, зарплату ему заплатите — потом выяснится, что не подходит человек.
Потому все и предпочитают ложноотрицательные результаты ложноположительним. Да, неприятно, но кто б рассказал, как сделать лучше.
DarkTiger
Мне кажется, Вы веткой ошиблись. Я всего лишь стоимость одного собеседования посчитал. Риски - это другое, хотя и тесно связанное, в смысле стоимости их уменьшения
DarkTiger
Если компания пускает на самотек процесс найма, когда собеседующие, как коршуны, набрасываются на кандидата, а присутствующий на компании HR боится/ленится дать собеседующим обратную связь - компания/отдел сама себе злобный Буратино и процесс найма затягивается до бесконечности. При том, что время на собеседования прибавляется к рабочему времени собеседующих, поскольку текущих задач никто не снимал.
Пусть лучше потеряет еще десяток часов на другие собеседования, чем полгода-год жизни на работу в окружении агрессивных коллег и руководства.
sergeaunt
Ну давайте рассмотрим альтернативную проблему: мы взяли на работу человека, который, несмотря на внушительное резюме и занимательный рассказ про технологии, совершенно не умеет программировать. К сожалению, это не фантастика, а обыденность. Далее этот кандидат: 1) тратит время лида на онбординг; 2) пишет говнокод, порождая баги и технический долг; 3) после разоблачения уходит и пишет гневные отзывы про нашу контору; 4) мы еще и платим ему зарплату.
Всё еще считаете проблемой то, что мы не рискуем нанять потенциального гения, который почему-то не умеет решать простейшие задачки на собеседовании?
isden
Потенциальный гений вполне может впасть в ступор на собесе, особенно когда на него налетает стая собеседующих. Статья то как раз об этом.
А в спокойной обстановке он вполне может выдавать свой гениальный код.
Я не знаю как решить эту проблему, просто констатирую факт.
Возможно HRу стоит лучше покопать отзывы с предыдущих мест работы, гитхаб и т.п.
sergeaunt
Безусловно. С этим я не спорю. Это риск, но, по-моему, лучше пойти на него и с вероятностью
отвергнуть гения, чем с вероятностью 
нанять профана. Мой коммент как раз об этом.
DrPass
Собеседование — это такая штука, в которой стоимость ошибки «не взять подходящего кандидата» и «не устроиться в подходящую компанию» несоизмеримо ниже, чем стоимость ошибки «взять неподходящего кандидата» и «устроиться в неподходящую компанию». Поэтому это действительно не проблема. И оплачиваемые люди тратят своё рабочее время в рамках ожидаемого бюджета, и соискатель в общем случае также ищет работу, заранее ожидая, что он потратит на общение какую-то часть своего времени, а не устроится с первого же звонка.
Вы же, например, когда хотите купить себе какой-нибудь гаджет, не тыкаете пальцем в первый попавшийся на витрине ближайшего магазина, а тратите определённое время на выбор, сравнение характеристик и т.д., хотя оно тоже может быть конвертировано в какой-то денежный эквивалент? Собеседование — это то же самое, для обеих сторон.
victor_1212
> Бывает и так, и так. Я, как человек, много раз побывавший ...
вполне соответствует моему опыту тоже, полезный комментарий, замечу также что с опытом приходит понимание как мало " собеседующих" на самом деле умеют это хорошо делать
funca
У хирургов есть сертификация. Получение сертификата это сложный квест, где требуется и подтверждение образования, и опыта, и отзывы с предыдущих мест работы. В сертификатах указываются конкретные действия, которые может совершать его владельц. Сертификат периодически нужно подтверждать, иначе он протухает.
Для айти такой вариант тоже местами используется. Но это все муторно и дорого. Поэтому в общей массе работодатели обходятся собесами и тестовыми задачками.
SaintMortum
Может и бред. Не считаю себя стрессоустойчивым, но единственный раз когда был лайв-кодинг прошёл нормально и даже мысли не путались. Но бывало что и обсуждение по результатам проверки тестового задания не очень проходило, ибо такие грубияны попадались что уже и ответить ничего не мог. Хотя, казалось бы, надо лишь пояснить ход мыслей почему именно так сделал.
Если ещё раз попадётся лайв-кодинг, то только порадуюсь лишней возможности оценить адекватность нанимающих.
kalombo
Тоже не люблю лайв-кодинг, также заваливал их из-за ерунды, через час открывал задачу и сходу писал решение уже без собеседующего. Да и вообще забыть можно хоть что на собеседовании и не дай бог пожаловаться где-то, сразу же набежит толпа топ-сеньоров, которая скажет с надрывом: "Как? Вы забыли про инкапсуляцию? Это же АЗЫ!11 Вам надо дворником быть" И это, несмотря на то, что у человека 20 лет опыта с большим набором технологий. Всё равно самозванец :)
marshinov
Ну если забыл про инкапсуляцию и не смог доходчиво объяснить, что она в данном случае не особо то и нужна, то может за эти 20 лет опыта кандидат так ничему и не научился?
Glandit
А вот и топ-сеньёр набежал.
kalombo
У вас какие-то взаимоисключающие вещи написаны. Если он забыл, то значит научился, но просто забыл. А если ничему не научился, то и забывать ему бы было нечего.
marshinov
Представьте две гипотетические ситуации:
Да, это азы и это надо знать. Если кандидат не знает, что это такое, то ему не по пути с ООП.
Кандидат может возразить, что лайвкодинг - это стрессовая ситуация, предполагающая быстрое решение здесь и сейчас. Поэтому он(а) решил(а) пренебречь инкапсуляцией в пользу скорости выполнения задания. На работе он(а) конечно же бы так не поступал(а). Или это вообще был DTO и там инкапсуляция и инварианты не нужны и интервьюер уже попутал(а).
kalombo
Вы путаете "забыл" и "не знал", ещё раз пишу, это взаимоисключающие состояния, а вы их приравняли друг к другу.
isden
ООП, к слову, это не серебряная пуля, и в большинстве случаев задачи можно эффективно решать и без него.
wolfy_str
Тут вообще сложно. Про 20 лет, конечно, это чёт слишком. Возьмём просто человека с несколькими годами опыта. Бывает сложно сформулировать понятия - инкапсуляция или интерфейс. Но ты их значешь. Допустим инкапсуляция это сокрытие данных или что то ещё? У меня такие заминки с хэшмапой, когда объясняю что это массив из связанного списка. Потом спрашивают как (каким образом) в этот массив залетают данные, как вычисляются индексы и тут начинается реально ерунда, так как я не могу это нормально объяснить. Ты знаешь какие то узкие веши когда расширяется мапа, или методы итератора в коллекциях, или вон тот метод в том классе в той теме, но тебя об этом не спросят если завалил "простые вещи". Так что как то тоже не люблю деление на простые и сложные вопросы. Как то мне лучше знать, для меня простой вопрос может быть сложным, а сложный - простым. Тут не всё однозначно.
marshinov
Нет. Если человек не может дать определение, он не до конца (или вовсе) не понимает, что он делает. И пример с хешмапой это только подтверждает.
wolfy_str
Ясно понятно. Тогда назовите нативную функцию, которая вычисляет хэшкод, как она считается? Каким образом выбираются индексы из массива хэшмапы? И не надо про простейшие вещи, типа сколько по умолчанию ёмкость хэшмапы - 16. Или про ёмкостный (capacity) фактор - он равен 0.75. Расскажите и вообще легально ли с такими вопросами вгрызаться на уровне простого миддла.
Valle
Да. Все используют хэш таблицы чуть ли не каждый день, и надо знать и самому уметь ее написать. Там, массив, остаток от деления и два вида разрешения коллизий, причем можно знать любой один. Это что, невозможное знание?
dmbreaker
Это просто лень изучать свои инструменты. Я сам только спустя 5 лет с начала карьеры разобрался с хэшмапой. Потому что лень было. Зато когда разобрался - поразился красоте инженерной мысли.
И теперь нет ощущения магии в этом, понимаешь, что всякие индексы БД на тех же алгоритмах работают и понимаешь как они это делают, что могут, а чего не могут.
sergeaunt
Я думал, для понимания работы индексов БД актуальнее Б-деревья, а не хеш-таблицы.
aegoroff
А кстати хэш индексы тоже есть, в том же постгресе. В реальной жизни hash и B-Tree применяются совместно, то есть для вычисления значений B-Tree индекса все равно применяются хэши.
sergeaunt
А можно ссылку для общего развития? А то гугл выдает только в духе "b-tree vs. hash".
Valle
B-tree это упрощенное 2-3 дерево, в нем нет хэшей. Так что да, BST и hash maps это две сильно разных структуры.
aegoroff
Да, конечно в самой структуре данных ничего подобного нет, но в конкретной реализации СУБД для реализации индекса могут использоваться и хэши, например для обеспечения уникальности в каких либо внутренних структурах данных этого индекса
aegoroff
Это закопано где-то в этих файлах
Вставка в BTree дерево
https://github.com/postgres/postgres/blob/master/src/backend/access/nbtree/nbtinsert.c
Всякие вспомогательные функции которые делают реальные операции
https://github.com/postgres/postgres/blob/master/src/backend/access/nbtree/nbtutils.c
Собственно стартовый код дерева
https://github.com/postgres/postgres/blob/master/src/backend/access/nbtree/nbtree.c
sergeaunt
Поиск "hash" по этим файлам ничего не дал, а читать всё подряд мне лень. Эх... Ну да ладно. Интересовался спора ради.
kalombo
Кстати, мне довольно часто такой вопрос попадался во время последнего рейда по собеседованиям. Я интересовался когда то, как оно все устроено, но с тех пор много времени прошло и поскольку в реальной жизни мне писать собственные хешмапы не приходилось, то и как оно реализуется вспоминается очень туго, в основном на уровне ключевых слов. На кой черт это спрашивают, для меня до сих пор загадка. Ну буду я заучивать это перед каждым собеседованием, это же маразм какой-то. Работу с регистрами процессора используют тоже каждый день, давайте их тоже требовать знать, как оно там под капотом на ассемблере.
Valle
Нужно это чтоб понимать как оно работает и, например, не написать случайно перебор содержимого с квадратичной сложностью или там не класть в нее объекты у которых hashCode/equals контракт нарушен. Или же тут ситация сложнее и есть непонимание чем хэштаблица от массива отличается?
vassabi
во-первых - вы сейчас очень языкоспецифическую штуку затронули. Не во всех языках так же сделано.
во-вторых - в отличие от знания хешмапы, знание что есть "hashCode/equals контракт" - гораааздо полезнее ( например, из классических приколов - про то как вычисляются hashCode/equals для URL )
kalombo
Это натягивание совы на глобус. Чтобы не написать случайно перебор содержимого с квадритичной слжоностью или там не класть в нее объекты у которых hashCode/equals контракт нарушен нужно знать как не написать случайно перебор содержимого с квадритичной слжоностью или когда там не класть в нее объекты у которых hashCode/equals контракт нарушен. И этого достаточно. Это и спрашивайте на собеседовании. Если вам это нужно на работе. Хешмапу то писать зачем? Логика, чтобы ездить на автомобиле нужно уметь собрать и разобрать его до последнего винтика - это оверинжениринг в чистом виде.
Valle
Я не спрашиваю. Но у нормального разработчика не составит труда показать, как он умеет писать код для реализации простой задачи. Если кто-то считает эту задачу очень сложной, то я не знаю, можно в таксисты пойти.
fkafka
А зачем в деталях знать? Достаточно знать принцип, что элементы раскидываются по конечному количеству корзин на основе быстро вычисляемого кода (т.е. хеш-кода). Ни разу не сталкивался чтобы требовали какого-то большего знания.
Valle
Ну да, этого достаточно чтоб написать свою хэшмапку, не правда ли?
vassabi
хммм, а как часто вы пишете свои хешмапки? Когда в последний писали на работе свою хешмапу ?
Valle
Ну не на работе, но недавно писал k-nearest neighbor на хэш-таблицах для многомерных векторов, а что? Хотите сказать, что знание что в хэш таблицах используется оператор MOD это слишком сложно и совершенно бесполезно?
Valle
А знание как оно внутри у разных коллекций устроено использую каждый день на работе.
vassabi
вы действительно используете знание "как оно внутри устроено", а не "асимптотическую сложность операции вставки\поиска\удаления" ?
Уважаю!
Valle
Знание сложности не всегда достаточно даже для тривиальных оценок. Скажем, какой big-O у "for(key : map.keys()) print(map[key])" и почему?
vassabi
это всё зависит от мапы, но конечно перебор по коллекции два раза - "это пять" :)
во-вторых, недавно встретил табличку "если 1 операция занимает 1нс, сколько потратится времени при разных сложностях алгоритмов", так там для N=10 то даже алгоритм со сложностью n^n работает 10с, что конечно очень долго, но дождаться можно. Для алгоритмов сложности n^3 можно брать коллекции в 1000 элементов, и жить можно. На практике - это значит, что если у автора сего кода несложный UI - то никто из бизнеса даже не почешется, чтобы улучшать.
Valle
Да, все верно. И для хэшмапки самый плохой случай для этого кода будет O(n^2), что будет отличным сюрпризом если там несколько миллионов элементов. Не зная как это устроено будет сложно сказать какого черта все встало ) Так же будет сложнее сказать RB или AVL дерево для вот именно для этого плохого перебора будет лучше.
0xd34df00d
Для стандартной неупорядоченной мапы а-ля unordered_map из плюсов — amortized O(n) или вообще O(n), без всяких amortized (если автор хэшмапы вас не ненавидит, конечно). O(n) на сбор ключей, потом n раз по [amortized] O(1) внутри цикла. А что?
Alexandroppolus
O(n) в среднем на итерацию, если кто-то облажался с кастомной функцией вычисления хеша для ключа.
0xd34df00d
А если вычисление хеша занимает O(n²) (что вполне легко сделать, достаточно внутри хэшера как-нибудь изощрённо обращаться к некоему глобальному репозиторию объектов для поиска позиции объекта в этом репозитории, не знаю), то этот цикл может быть произвольно тяжёлым. Я бы не стал рассматривать такие случаи
Valle
Обычно имплементация hashcode контролируется, но данные могут и нет. Если данные - это, например, строки, которые приходят от пользователей, то это можно использовать для DOS атаки.
0xd34df00d
И проблемы у вас в таком случае возникнут сильно до того, как вы начнёте хэшмапу обходить — они начнутся где-то в районе вставок в хэшмапу. Для этого обычно берут хэширование с дополнительным случайным сидом.
vassabi
ну, их можно написать и без оператора mod (например - наложив ограничение на хеш).
просто нечасто по работе такое надо, и обычно за такую интересную задачу борются сразу несколько синьоров (если конечно у вас отделе больше одного синьора)
fkafka
Я не писал свои хешмапы, и в этом не было нужды, но однажды у меня был случай когда я неправильно реализовал GetHashCode() для класса и у меня целый кусок приложения с Dictionary этого класса перестал работать. И если не знать что Dictionary работает на основе хеш-кодов, то провозиться с таким багом можно до пенсии, т.к. ошибка в одном месте всплывает совершенно в другом.
vassabi
я уже писал, но повторю :
в отличие от знания хешмапы, знание что есть "hashCode/equals контракт" (и что многие структуры коллекций используют не указатель на объект, а вычисление хеша от содержимого объекта) - гораааздо полезнее ( например, из классических приколов - про то как вычисляются hashCode/equals для URL )
fkafka
Да, но без знания того, что хешмапа (у нас оно называется Dictionary<TKey, T>) использует GetHashCode() можно просто не догадаться, что нужно искать именно это самое нарушение контракта. Ну а если про это знаешь, то сути уже и знаешь в общих чертах как оно устроено.
sergeaunt
Человеку, который действительно умеет программировать и понимает суть, достаточно.
Самозванцу, который может только рассказать заученное в общих словах, а при просьбе закодить впадает в ступор, - нет.
Вот поэтому и нужно на собеседовании кодить, а не только "беседовать о технологиях".
"Болтовня ничего не стоит. Покажите мне код" (с) Linus Torvalds
0xd34df00d
Я знаю минимум три (со списком, с несколькими хэшами, с линейным сканированием) и знаю, что есть ещё. Откуда два?
Для типов, мономорфных машинным целым, есть и более интересные структуры, имеющие свои преимущества, например.
csl
А из ваших пакетов на Hackage есть именно типы и структуры данных?
0xd34df00d
Нет — я слишком тупой, чтобы придумывать что-то новое, а всё уже имеющееся интересное там есть.
wolfy_str
думаю въедливые собеседующие могут не остановится на остатке от деления. Опять же вопрос открытый вы не ответили. Нативная функция вычисления хэш-кода - какая она? Она написана на С и закрыта модификатором native.
Valle
Зависит от платформы, я думаю. В яве можно command-left click и посмотреть имплементацию, по умолчанию это адрес объекта вроде, для строк это простой хэш от содержимого. В Go это aeshash от содержимого.
aegoroff
инкапсуляция это не совсем сокрытие данных. Тут как раз и заключается тонкий момент - Инкапсуляция (англ. encapsulation, от лат. in capsula) — в информатике размещение в одном компоненте данных и методов, которые с ними работают.
И уже как следствие, инкапсуляция как раз обеспечивает сокрытие, но не наоборот - сокрытие это не есть инкапсуляция.
и далее продолжаю цитировать википедию
В сообществе C++ или Java принято рассматривать инкапсуляцию без сокрытия как неполноценную. Однако, некоторые языки (например, Smalltalk, Python) реализуют инкапсуляцию, но не предусматривают возможности сокрытия в принципе. Другие (Standard ML, OCaml) жёстко разделяют эти понятия как ортогональные и предоставляют их в семантически различном виде (см. сокрытие в языке модулей ML).
https://ru.wikipedia.org/wiki/Инкапсуляция_(программирование)
FloorZ
С каких пор хэшмап стал связным списком? Это ассоциативный контейнер. А как его реализует конкретный Фреймворк - дело десятое.
Детали реализации конкретно stl ной мапы - больше похоже на зубрежку, чем на понимание паттерна и как он должен работать в Qt, stl и любом другом фреймворке.
0xd34df00d
Ну, конкретно в случае stl'ной unordered_map детали реализации протекают в API и его гарантии.
isden
А вы не рассматривали вариант, что не "забыл", а интуитивно не использовал там где не нужно? И даже не задумывался о том, нужно или нет, а сразу готовый паттерн сформировал в голове на основе своего опыта.
marshinov
Ну тогда этот человек на уточняющий вопрос "а почему нет инкапсуляции" моментально ответит, что "здесь оно не надо". Я про то что "знал, но забыл" - это брехня. Не знал никогда
wolfy_str
не брехня. У меня такое было только на 5 раз вспомнил то что уже учил/знал. Первые 2-3 раза когда спросят любой вопрос можно забыть. А на вопрос про "здесь оно не надо" обязательно спросят "почему оно не надо". Так что вы думаете только кандидаты могут мухлевать, а как память работает и далеко не все всё сразу могут вспомнить - забываете.
dmbreaker
Кажется вы путаете "учил" и "знал".
Если ты в коде использовал что-то осознанно, тогда знание закрепляется очень основательно.
А если два раза прочитал и три раза рассказал, то да - можно легко забыть.
Без практики нет знания.
KoCMoHaBT61
О! Прям на любимую мозоль...
Забавно, что топ-сеньоры очень часто в мантре "инкапсуляция, полиморфизм, наследование" под инкапсуляцией подразумевают сокрытие (а это даже в учебниках пишут) -- и это слегка немного выбешивает очень сильно.
wolfy_str
Инкапсуляция - разве не сокрытие данных? вот я помню, что что-то ещё, но не помню что... На пальцах могу объяснить, что это когда в классе скрывают данные от других классов и вообще закрывают от "сайд эффектов", что бы не было наследования.. Вот примерно так могу объяснить не заглядывая в определение. И кстати прочитанное определение не гарантирует что я его запомню. Если только произнесу раз десять то запомню, а так бывает, что уже вроде знаешь определение - но не можешь сказать так как забыл.
fkafka
Нет. Инкапсуляция это сокрытие реализации. Очень связанный с этим вопрос это для чего инкапсуляция вообще нужна или полезна.
PerseforeComplete
Я обычно на собесах отвечаю - инкапсуляция это сокрытие прямого доступа к состоянию объекта (состояние объекта это значение всех его полей), и предоставление в замен этого контролируемого доступа через интерфейс (в широком смысле этого слова)
fkafka
Это только часть правды. Т.к. объект может еще иметь закрытые статические поля (не часть состояния) и закрытые свойства/методы, а еще есть internal. А еще объект может хранить свое состояние не в полях, а, допустим, в БД, или вообще не иметь состояния.
А вот это, как раз, на мой взгляд, был бы уже сам по себе абсолютно полный ответ, которого бы с головой хватило.
aegoroff
Да откройте же википедию - там все доходчиво объяснено https://ru.wikipedia.org/wiki/Инкапсуляция_(программирование)
Инкапсуляция (англ. encapsulation, от лат. in capsula) — в информатике размещение в одном компоненте данных и методов, которые с ними работают. В реализации большинства языков программирования (C++, C#, Java и другие), обеспечивает механизм сокрытия, позволяющий разграничивать доступ к различным компонентам программы.
Инкапсуляция зачастую рассматривается как понятие, присущее исключительно объектно-ориентированному программированию (ООП), но в действительности обширно встречается и в других (см. подтипизация на записях и полиморфизм записей и вариантов). В ООП инкапсуляция тесно связана с принципом абстракции данных (не путать с абстрактными типами данных, реализации которых предоставляют возможность инкапсуляции, но имеют иную природу). Это, в частности, влечёт за собой различия в терминологии в разных источниках. В сообществе C++ или Java принято рассматривать инкапсуляцию без сокрытия как неполноценную. Однако, некоторые языки (например, Smalltalk, Python) реализуют инкапсуляцию, но не предусматривают возможности сокрытия в принципе. Другие (Standard ML, OCaml) жёстко разделяют эти понятия как ортогональные и предоставляют их в семантически различном виде (см. сокрытие в языке модулей ML).
KoCMoHaBT61
Вот именно. Сокрытие не есть инкапсуляция. Сокрытие это сайдэффект в некоторых языках для разделения интерфейса и реализации.
Но в учебниках пишут другое и описывают инкапсуляцию как сокрытие в чистом виде (public, protected, private).
aegoroff
Да, про это и говорится что в C++, Java, C# и пр. инкапсуляция без сокрытия это мол неполноценная инкапсуляция, но в данном случае сокрытие - это просто деталь реализации, артефакт языков так сказать. В общем инкапсуляция концептуальное понятие, а сокрытие это детали реализации.
В том же Golang - вы внутри модуля делаете структуру, в которую помещаете все нужные поля и реализуете для нее какие-то методы, в том числе методы разных интерфейсов - это есть инкапсуляция. Но внутри того же модуля вы не сможете другим его членам запретить использовать все приватные свойства этой структуры, т. е. в данном случае есть инкапсуляция но нет сокрытия данных
stdamit
Я за фразу "вам надо дворником" сходу отвечу "слышь дядя, а тебе надо сварщиком в коммуналку, где сосед заземлил электрокамин на батарею а в подвале потекло и тебе срезать надо. и вот стоишь ты такой с фортуной, наступает момент истины и тут ты понимаешь что на трубе слева 370 вольт а справа - 90, и тебя █ботоком смертельно убъёт если ты за неё руками возьмёшься. дворником, ищьчё придумал, баклан. щезни с темы, не беси меня". Как говорится, "не просите меня пояснить за мой ластхит, и я не попрошу вас пояснить за мой пинг". Как там это они называют? а, "не стрессоустойчивый".
Ну как по мне, на такое радоваться надо что я так, словами. ласково. А не бутылкой по голове. Некоторым людям было бы полезно испытать опыт макания их прекрасного светлого личика в непроницаемую темноту главного предмета санузла. С небес спуститься, если в метафорах понятнее.
Vitaly83vvp
Показывать в онлайн режиме разработку даже примитивного кода очень сложно. По крайней мере, у меня был один такой опыт. Забывается всё подчистую. Хотя, за несколько минут до этого, спокойно писал код в разы сложнее и на том же языке, но без демонстрации.
stardust_kid
Вам надо попрообовать проводить live coding самому, то есть со стороны нанимателя. Мне очень помогло, когла я увидел какую херню творят другие программисты. Понял, что я на их фоне вполне норм. Однако попадаются и такие ребята, которые выдают production quality код с первой попытки.
Когда-то собеседовал фронта. Парень плавал в реакте, но когда я попросил обработать данные, он сразу стал писать с O(n) сложностью, хотя там были вложенные массивы.
SwingoPingo
В коде, как и в человеческой речи, достаточный объем "вводных и выводных фраз". "К примеру, если рассмотреть ситуацию с с Вашей стороны, что бы решить поставленную Вами задачу... " и т.д. Я еще совсем ничего не сказал, но беседа то идет и Вам кажется что я норм собеседник, заинтересован в Вашей задаче и поддерживаю разговор, а другой вон вообще замолчал т.к. у него еще нет решения (так и у меня еще нет) и сказать ему нечего.
Так и в коде, надо написать область описания переменных, интерфейс, типовой обработчик результата - это все уйдет в прод практически неизменным и это же и хороший стиль.
Само же решение же будет в ядре этого. Однако вот эта деятельность по написанию вводной обертки возможно снизит эмоциональную атаку, веренет в привычное русло да и даже если не поможет решить задачу, просто покажет что код эстетически красивый, что само по себе очень хорошо. Может и не прокатит, но в любом случае это лучше чем ничего.
elisoff
+++ Лайв кодинг - лютый стресс
Vilaine
Намного сложнее soft skill interview, где задают вопросы типа «расскажите о ситуации, где вы изменили процессы на работе через инновации или упрощение, и ваша фирма получила кучу профита». И где собеседующий ожидает ответа в формате STAR. Для этого нужно заранее перед интервью вспоминать все свои ситуации и стараться натянуть их на возможные вопросы, но это сложно сделать на новый вопрос, а во время стресса вообще придумать адаптацию ещё сложнее, и у интервьювера может сложиться впечатление, что не такой уж вы были полезный сотрудник для предыдущей компании.
Такой скилл нередко сформирован ранними этапами жизни и взрослому человеку намного сложнее его набить, чем полумеханический кодинг.
vassabi
... и другой маркетинг буллшит
Когда мне нравится проект - то пишу код и думаю, сколько пользы он принесет. А когда я пишу код для финансистов каких-нить, то у меня только мысли о пятнице. Он может принесет им прибыль, а может и не принесет - это все забота ПМа.
Я могу конечно на интервью рассказывать истории про то, как мой про супер код (с инновациями, рефакторингом, BDD и бохатым UI) месяц добирался до клиентов - потому что проходил сначала черз ДБА, потом через ДевОпсов продакшена, а потом через РискДепартамент....
Vilaine
Вот как раз и нужно рассказать, что вы сделали для того, чтобы такого впредь не случалось (и желательно со счастливым концом).
Я думаю сейчас нанять консультанта по карьере, чтобы улучшить свои навыки прохождения вот этого всего.
vassabi
эх! ... читаю я эти строки и скупая мужская слеза невольно катится по моей небритой щеке. Прямо не в бровь, а по самому больному месту бьет!