[Прим. пер.: на этом моменте статьи выяснилось, что редактор статей Хабра при сохранении обрывает текст на непонятных ему символах, в частности, на иероглифах и эмодзи.
Вероятнее всего в таблице MySQL у Хабра сравнение general_ci, а для такой задачи нужно utf8mb4.
Нужно специально модифицировать способ хранения строки в базе данных, чтобы получить возможность хранить эмодзи (впрочем, для Хабра это вроде бы не очень частая проблема?).
Из того, что я слышал о mail.ru и наблюдал из попыток туда устроиться, у меня сложилось впечатление, что это скорее сеть полузамкнутых профессиональных клубов, чем компания, в которую действительно ведётся рекрутинг.
Чтобы просто попасть на собеседование, у вас должен быть человек внутри, который может ногами пройтись до эйчара. Что ж… Думаю, это хорошо для тех, кто уже внутри, но не очень выгодно для тех, кто повёлся на HR-бренд и зачем-то захотел туда попасть.
Поэтому рекомендации от компании с таким ресурсом могут существенно отличаться от того, что будут ожидать от эйчара в фирме на 20-50 человек (который находится в менее выгодном предложении даже если предлагает более высокую зарплату).
> Что касается художников, попробуйте сперва припомнить навскидку количество великих картин, написанных 2+ художниками, затем написанных одним.
Часть великих художников представляли собой бренд, под которым работали их ученики и подмастерья, делавшие работу по их уровню скилла (скажем, мастер мог специализироваться только на лицах на больших сложных групповых портретах, ученики писали всё остальное). Это нормально для средневекового цехового уклада, хотя в наше время задают вопросы, были ли картины написаны самим мастером — или его учеником.
Чтобы получилось такое число, достаточно просто ходить на собесы 1-2 раза в месяц 6 лет кряду, чтобы сложить для себя представление о том что востребовано.
Что удивляет в высоком шансе отказа? Эйчары вполне могут составлять обоймы из кандидатов, которые требуется отсобеседовать целиком до найма одного из них, таким образом шанс каждого соискателя будет даже не 50%.
Тут хотелось бы ссылку на то как художники реально работают над одной картиной.
Если речь идёт про digital, то может быть несколько сценариев:
1. Глава проекта намечает общую композицию, определяет единообразный художественный стиль, дробит на множество мелких объектов (персонажи, пропсы, фоны), отдаёт их художникам для детализации (возможно, после того как для картины построили черновой эскиз или 3D-модель), затем всё это пытаются свести, если получили всё необходимое в разумные сроки.
2. Есть пайплайн «лор/сюжет» — «скетч» — «лайнарт» — «шейдинг» — «колоризация», разные стадии могут быть поручены разным людям.
Рынок уже испорчен эйчарами, которые абузили желание и возможность кандидатов писать тестовые задания сроком на несколько дней для первичного отсева.
Логично, что это формирует позицию «пишу тестовое задание только за деньги», пусть даже тестовое задание занимает всего один час.
Почему я на словах должен верить в том, что чувак крутой программер, а не просто имеет хороший подвешенный язык?
Почему чувак должен хотеть работать в вашей компании достаточно сильно, чтобы согласиться на бесплатную работу (пусть и на час)?
На рынке есть некоторый пул компаний, в которые нанимают после того, как зададут пару-тройку вопросов инженерного толка, после которых не ощущаешь себя выжатым досуха, как лимон. Если перебирать достаточно интенсивно, вполне можно на них наткнуться. Закономерно, что работники стремятся минимизировать неоплачиваемую неприятную работу и фильтруют компании, которые устраивают чрезмерно жёсткие на их взгляд вступительные испытания без заметного вознаграждения.
Больше того, то, что я могу дать им новые знания, мне гораздо важнее того, что код в данном конкретном месте будет лучше
Это мода.
Мода диктуется в первую очередь не удобством или прагматичностью, а укоренённостью среди активных приверженцев, которые распространяют её с помощью широкого спектра механик отторжения (включая насмешки, отказ в приёме на работу, обширные атаки репутации других стэков etc).
Совсем нежизнеспособная мода в высококонкурентных областях может вымереть (потому что бизнес иногда подсчитывает деньги и увольняет / не нанимает модников, следующих стэкам, которые не обладают достаточно весомой репутацией в требуемой области). Из-за этого отсева модные стэки как-то решают свои задачи помимо обычной для себя генерации сопутствующего инфомусора, который станет бессмысленным через несколько лет.
Мода оперирует абстрактными параметрами привлекательности («лучший», «современный», «престижный»), которые лишены другого внутреннего содержания, кроме маркировки апологетов моды и тех, кто не успел или не захотел перейти на сторону этого агрессивного меньшинства.
Мода, безусловно, является подмножеством знания, однако её конечной целью не является решение задачи бизнеса, а извлечение для своей ядерной группы некоторого количества престижа, способного удовлетворить их человеческие потребности.
Согласно этой трактовке, «сеньорность» как признак сводится к совпадению модных фетишей у двух охотников из техно-варварских племён, один из которых оценивает, а другой — оценивается; при этом набор паролей и ответов постоянно меняется. Что ж… Раз это даёт какие-то результаты, которые можно зримо оценить, это иногда работает. Но меня смущает в этом механизме то, что если сотрудник умеет очень хорошо проходить собеседования (то есть обладает большим количеством паролей от них), значит он часто по ним ходит, а следовательно не занят производительной деятельностью и/или может обладать другими качественными недостатками, которые не может вскрыть система чеклистов.
Поэтому да, если вы не можете аргументировать ваши решения, которые вы принимаете здесь и сейчас, то это буллшит.
Среди всех возражений, которые я получал когда-либо на код-ревью, я встречал следующие виды:
1. Структурно значимые (решение задачи является неверным во всех случаях, в некоторых случаях или выполнено неоптимально по некоторым метрикам, например время выполнения или потребляемая память в высоконагруженном участке кода).
2. Сепульки (задача формально решена, но ход её решения оскорбляет глаза ревьюера, который придерживается определённых взглядов — или наоборот игнорирует — цикломатическую сложность, среднюю длину метода, нейминг переменных, включает в себя изменение написанных лично ревьюером методов etc). Заметная часть сепулек можно автоматизировать однажды настроенным линтером, остальные запоминаются как больные мозоли ревьюера, на которые лишний раз наступать нежелательно.
3. Неверные (предлагаемое и подразумеваемое ревьюером решение в принципе не будет работать в силу специфики кодовой базы, при этом ревьюер может ухитриться проигнорировать даже поясняющий комментарий в коде, в котором прямо упоминается об этом нюансе).
Поэтому любое собеседование в сущности сводится к двум вещам:
1. к тестированию, насколько велик запас терпения миссионера тимлида к вводимому в лоно истинной веры кающемуся язычнику нанимаемому сотруднику после чтения им местного извода Кахетезиса модных цитат про паттерны программирования, KISS, SOLID, модели OSI, количество бакетов на острие хэш-таблицы, местонахождение мяуколки у кошки, дефолтный способ вычисления хэша для объектов в данном ЯП и прочие вещи, которые было бы слишком оскорбительно использовать для решения приземленных задач вроде катания круглых апи и таскания квадратных крудов.
2. и насколько хорошо тимлид умеет обучать новоприобретённого серва прыгать на минах своего собственного ОКР (потому что вполне возможно, что нанимаемый гребец может не подавать сигналы желания пройти очередной этап дрессуры, а следовательно бесполезен для дрессировщика).
А умение отыскивать и применять, если за этим не стоит фундаментального знания и понимания технологии, приводит к такому:
Если проблемы проекта обычно невозможно решить пятью минутами гуглежа, значит у него есть проблемы (для разработчика или для бизнеса). Например, отсутствие архитектора. Или бас-фактор, стремящийся к единице. Или есть велосипеды. Или высокая сложность, которая приводит к отваливанию кусков при попытке добавить к этому дирижаблю новую фабрику бассейнов.
Я однажды участвовал в проекте, который включал в себя редкоиспользуемый диалект скриптового языка, который почти нигде не используется (и следовательно, невозможно нагуглить решение типовых задач, посмотреть лучшие практики организации кода и т. п. — по сути, были доступны только кодовая база, доставшаяся от предыдущего поколения разработчиков, и исходники компилятора вместо документации). Для доступа к статистике использовалась самописная база данных, которая не справлялась с выросшим за годы объёмом данных. Что ж… После этого проекта мне пришлось заливать в себя уйму инфотрэша перед тем, как я снова смог ходить по собеседованиям и не просыпаться после них утром с ощущением, что мои глаза сейчас взорвутся.
Я согласен, что слепая вставка нагугленного кода без подгонки к реалиям проекта (хотя бы обычного форматирования под его стандарты или проверки, что эта штука решает задачу слишком избыточно и неоптимально) — порочная практика, которая ведёт к усложнению чтения проекта (а следовательно, и удлиннения времени выполнения задач, поскольку большую часть жизни программист проводит за чтением, немного времени пишет код, а остаток времени кричит). Тем не менее, где ещё программист наберётся модных техник, как не изучая то, что используют другие модники?
Мне кажется, если программисту надо имплементировать (в очередной раз) метод сортировки и при этом он не разработчик ядерных библиотек языка, то в используемом им стэке что-то очень сильно не так.
Интервьюерам выгодно придумывать чеклисты, нанимать по гороскопу и строить как можно более высокий барьер при собеседовании. Это экономит ресурсы компании и позволяет нанять каких-то кандидатов (не совсем обязательно лучших, но достаточно сервильных, чтобы впитать весь не имеющий отношения к самому труду инфомусор, который от них требуется усвоить). Опять же, можно прогнуть по зарплате, пользуясь тем что кандидат что-то не знает (а он гарантированно чего-то не знает).
Работникам выгодно минимизировать затраты на собеседование и не хранить в голове знания, которые они не используют каждый день. Благодаря чрезвычайно мощным средствам поиска информации такое в наше время уже возможно: умение искать и адаптировать информацию может быть ценнее, чем хранение информации у себя в кэше.
> Ну т.е. какая *реальная* польза от того, что чел будет знать, какая там хэш-функция используется?
Я однажды заморочился и откопал типовой комплект ответов на вопросы по Java, залил себе в мозг эту мусорную инфу по хэш-таблицам и потом пугал ею интервьюеров на собеседованиях, которые спрашивали что такое hash index в MySQL. Думаю, они ожидали менее развёрнутый ответ, который и приличествовал программисту LAMP-стэка. Такие знания — это сила. Это мощь паровоза, который несётся по болотам, распугивая квакающих лягушек. Это булава интеллектуальной битвы, это боевой клич берсерка из драккара компьютерных наук, обожравшегося пшеницы со спорыньей и прочих некачественных продуктов.
Практически неприменимо в быту, но вы же не станете требовать, чтобы руны образовывали вокруг голого торса огненный щит? Один покарает вас за такое желание облегчить свою участь инфоберсерка.
1. Вероятность полного совпадения опыта случайно взятого специалиста и интервьюера (или составителя чек-листа) довольно низка. Если взять список из 28 вопросов, не дать к ним подготовиться и предположить, что шанс знания любого из них составляет 95%, то шанс безошибочного ответа по всему чек-листу составляет 23%. При этом специалист с опытом умудрялся как-то находить работу и приносить ощущение пользы, раз его оттуда не выгоняли.
2. Теоретические знания помогут на практике только чтобы осадить ретивых коллег в комментах к пулл-реквесту или надуть щёки на собеседовании, чтобы лягушка показалась больше, опаснее и увесистее. Ну, наверное эти слои брони хороши для кандидата, раз он их на себя навешивает. Только вы нанимаете писателя кода руками или говорителя ртом университетских лекций?
Знания per se, на мой взгляд, в решениях проблем имеют более низкий приоритет перед умением своевременно их отыскивать и применять.
Странно, что производители браузеров озаботились приватностью пользователей: ведь это не несёт им очевидной выгоды и вызывает очевидное противодействие других игроков (цензоров и сборщиков бигдаты), которые привыкли к раскладу без шифрования, скрытия DNS, антитрэкинга и прочих фокусов. В чём подвох?
Предыдущая статья отмечала большую часть активностей, связанных с компьютером, как чрезвычайно сильный раздражитель, который способен забивать шумом все направленные активности.
То есть исторически игры, конечно, развивались как развивающий симулятор реальности (начиная от прусских варгеймов XIX века, в которых изобрели туман войны как игровой приём), однако благодаря своей эффективности иногда они приносят сопутствующее наслаждение слишком сильно.
Статистически на сотню/тысячу/милллиард благоразумных сотрудников может найтись один, который соблазнится любой возможностью (несмотря на страх наказания) и каким-то образом прошёл фильтры компании во время приёма на работу. Разумеется, скорее всего таких через некоторое время застукают за неблаговидным занятием и выгонят, а сам вопрос тихо замнут, но осадок-то останется.
> Можно притянуть за уши вариант доступа к результатам ДНК правоохранительными органами, но вы же не совершаете ничего противозаконного, вам же нЕчего бояться?!
В современном мире да, но в довольно недавней истории были случаи, когда по итогам анализа родословных некоторые категории населения подвергались заточению и убийству.
Это выглядит как следствие того, что между работодателями на местности существует нечто среднее между картельным сговором и мирным договором, касающееся зарплат сотрудников. Если компания платит своим сотрудникам существенно больше, она заявляет свои приоритетные права на рынке рабочей силы этого города или местности, и либо вынуждает других игроков увеличить свои ФОТ, либо подвергается множеству мелких атак и придирок, истинная причина которых не объявляется (поскольку рациональный игрок не станет сообщать своим сотрудникам в явной форме, что он не хочет платить им больше).
Вероятнее всего в таблице MySQL у Хабра сравнение general_ci, а для такой задачи нужно utf8mb4.
Нужно специально модифицировать способ хранения строки в базе данных, чтобы получить возможность хранить эмодзи (впрочем, для Хабра это вроде бы не очень частая проблема?).
Чтобы просто попасть на собеседование, у вас должен быть человек внутри, который может ногами пройтись до эйчара. Что ж… Думаю, это хорошо для тех, кто уже внутри, но не очень выгодно для тех, кто повёлся на HR-бренд и зачем-то захотел туда попасть.
Поэтому рекомендации от компании с таким ресурсом могут существенно отличаться от того, что будут ожидать от эйчара в фирме на 20-50 человек (который находится в менее выгодном предложении даже если предлагает более высокую зарплату).
Часть великих художников представляли собой бренд, под которым работали их ученики и подмастерья, делавшие работу по их уровню скилла (скажем, мастер мог специализироваться только на лицах на больших сложных групповых портретах, ученики писали всё остальное). Это нормально для средневекового цехового уклада, хотя в наше время задают вопросы, были ли картины написаны самим мастером — или его учеником.
Что удивляет в высоком шансе отказа? Эйчары вполне могут составлять обоймы из кандидатов, которые требуется отсобеседовать целиком до найма одного из них, таким образом шанс каждого соискателя будет даже не 50%.
Если речь идёт про digital, то может быть несколько сценариев:
1. Глава проекта намечает общую композицию, определяет единообразный художественный стиль, дробит на множество мелких объектов (персонажи, пропсы, фоны), отдаёт их художникам для детализации (возможно, после того как для картины построили черновой эскиз или 3D-модель), затем всё это пытаются свести, если получили всё необходимое в разумные сроки.
2. Есть пайплайн «лор/сюжет» — «скетч» — «лайнарт» — «шейдинг» — «колоризация», разные стадии могут быть поручены разным людям.
Логично, что это формирует позицию «пишу тестовое задание только за деньги», пусть даже тестовое задание занимает всего один час.
Почему чувак должен хотеть работать в вашей компании достаточно сильно, чтобы согласиться на бесплатную работу (пусть и на час)?
На рынке есть некоторый пул компаний, в которые нанимают после того, как зададут пару-тройку вопросов инженерного толка, после которых не ощущаешь себя выжатым досуха, как лимон. Если перебирать достаточно интенсивно, вполне можно на них наткнуться. Закономерно, что работники стремятся минимизировать неоплачиваемую неприятную работу и фильтруют компании, которые устраивают чрезмерно жёсткие на их взгляд вступительные испытания без заметного вознаграждения.
Это мода.
Мода диктуется в первую очередь не удобством или прагматичностью, а укоренённостью среди активных приверженцев, которые распространяют её с помощью широкого спектра механик отторжения (включая насмешки, отказ в приёме на работу, обширные атаки репутации других стэков etc).
Совсем нежизнеспособная мода в высококонкурентных областях может вымереть (потому что бизнес иногда подсчитывает деньги и увольняет / не нанимает модников, следующих стэкам, которые не обладают достаточно весомой репутацией в требуемой области). Из-за этого отсева модные стэки как-то решают свои задачи помимо обычной для себя генерации сопутствующего инфомусора, который станет бессмысленным через несколько лет.
Мода оперирует абстрактными параметрами привлекательности («лучший», «современный», «престижный»), которые лишены другого внутреннего содержания, кроме маркировки апологетов моды и тех, кто не успел или не захотел перейти на сторону этого агрессивного меньшинства.
Мода, безусловно, является подмножеством знания, однако её конечной целью не является решение задачи бизнеса, а извлечение для своей ядерной группы некоторого количества престижа, способного удовлетворить их человеческие потребности.
Согласно этой трактовке, «сеньорность» как признак сводится к совпадению модных фетишей у двух охотников из техно-варварских племён, один из которых оценивает, а другой — оценивается; при этом набор паролей и ответов постоянно меняется. Что ж… Раз это даёт какие-то результаты, которые можно зримо оценить, это иногда работает. Но меня смущает в этом механизме то, что если сотрудник умеет очень хорошо проходить собеседования (то есть обладает большим количеством паролей от них), значит он часто по ним ходит, а следовательно не занят производительной деятельностью и/или может обладать другими качественными недостатками, которые не может вскрыть система чеклистов.
Среди всех возражений, которые я получал когда-либо на код-ревью, я встречал следующие виды:
1. Структурно значимые (решение задачи является неверным во всех случаях, в некоторых случаях или выполнено неоптимально по некоторым метрикам, например время выполнения или потребляемая память в высоконагруженном участке кода).
2. Сепульки (задача формально решена, но ход её решения оскорбляет глаза ревьюера, который придерживается определённых взглядов — или наоборот игнорирует — цикломатическую сложность, среднюю длину метода, нейминг переменных, включает в себя изменение написанных лично ревьюером методов etc). Заметная часть сепулек можно автоматизировать однажды настроенным линтером, остальные запоминаются как больные мозоли ревьюера, на которые лишний раз наступать нежелательно.
3. Неверные (предлагаемое и подразумеваемое ревьюером решение в принципе не будет работать в силу специфики кодовой базы, при этом ревьюер может ухитриться проигнорировать даже поясняющий комментарий в коде, в котором прямо упоминается об этом нюансе).
Поэтому любое собеседование в сущности сводится к двум вещам:
1. к тестированию, насколько велик запас терпения
миссионератимлида квводимому в лоно истинной веры кающемуся язычникунанимаемому сотруднику после чтения имместного извода Кахетезисамодных цитат про паттерны программирования, KISS, SOLID, модели OSI, количество бакетов на острие хэш-таблицы, местонахождение мяуколки у кошки, дефолтный способ вычисления хэша для объектов в данном ЯП и прочие вещи, которые было бы слишком оскорбительно использовать для решения приземленных задач вроде катания круглых апи и таскания квадратных крудов.2. и насколько хорошо тимлид умеет обучать новоприобретённого серва прыгать на минах своего собственного ОКР (потому что вполне возможно, что нанимаемый гребец может не подавать сигналы желания пройти очередной этап дрессуры, а следовательно бесполезен для дрессировщика).
Если проблемы проекта обычно невозможно решить пятью минутами гуглежа, значит у него есть проблемы (для разработчика или для бизнеса). Например, отсутствие архитектора. Или бас-фактор, стремящийся к единице. Или есть велосипеды. Или высокая сложность, которая приводит к отваливанию кусков при попытке добавить к этому дирижаблю новую фабрику бассейнов.
Я однажды участвовал в проекте, который включал в себя редкоиспользуемый диалект скриптового языка, который почти нигде не используется (и следовательно, невозможно нагуглить решение типовых задач, посмотреть лучшие практики организации кода и т. п. — по сути, были доступны только кодовая база, доставшаяся от предыдущего поколения разработчиков, и исходники компилятора вместо документации). Для доступа к статистике использовалась самописная база данных, которая не справлялась с выросшим за годы объёмом данных. Что ж… После этого проекта мне пришлось заливать в себя уйму инфотрэша перед тем, как я снова смог ходить по собеседованиям и не просыпаться после них утром с ощущением, что мои глаза сейчас взорвутся.
Я согласен, что слепая вставка нагугленного кода без подгонки к реалиям проекта (хотя бы обычного форматирования под его стандарты или проверки, что эта штука решает задачу слишком избыточно и неоптимально) — порочная практика, которая ведёт к усложнению чтения проекта (а следовательно, и удлиннения времени выполнения задач, поскольку большую часть жизни программист проводит за чтением, немного времени пишет код, а остаток времени кричит). Тем не менее, где ещё программист наберётся модных техник, как не изучая то, что используют другие модники?
Интервьюерам выгодно придумывать чеклисты, нанимать по гороскопу и строить как можно более высокий барьер при собеседовании. Это экономит ресурсы компании и позволяет нанять каких-то кандидатов (не совсем обязательно лучших, но достаточно сервильных, чтобы впитать весь не имеющий отношения к самому труду инфомусор, который от них требуется усвоить). Опять же, можно прогнуть по зарплате, пользуясь тем что кандидат что-то не знает (а он гарантированно чего-то не знает).
Работникам выгодно минимизировать затраты на собеседование и не хранить в голове знания, которые они не используют каждый день. Благодаря чрезвычайно мощным средствам поиска информации такое в наше время уже возможно: умение искать и адаптировать информацию может быть ценнее, чем хранение информации у себя в кэше.
> Ну т.е. какая *реальная* польза от того, что чел будет знать, какая там хэш-функция используется?
Я однажды заморочился и откопал типовой комплект ответов на вопросы по Java, залил себе в мозг эту мусорную инфу по хэш-таблицам и потом пугал ею интервьюеров на собеседованиях, которые спрашивали что такое hash index в MySQL. Думаю, они ожидали менее развёрнутый ответ, который и приличествовал программисту LAMP-стэка. Такие знания — это сила. Это мощь паровоза, который несётся по болотам, распугивая квакающих лягушек. Это булава интеллектуальной битвы, это боевой клич берсерка из драккара компьютерных наук, обожравшегося пшеницы со спорыньей и прочих некачественных продуктов.
Практически неприменимо в быту, но вы же не станете требовать, чтобы руны образовывали вокруг голого торса огненный щит? Один покарает вас за такое желание облегчить свою участь инфоберсерка.
2. Теоретические знания помогут на практике только чтобы осадить ретивых коллег в комментах к пулл-реквесту или надуть щёки на собеседовании, чтобы лягушка показалась больше, опаснее и увесистее. Ну, наверное эти слои брони хороши для кандидата, раз он их на себя навешивает. Только вы нанимаете писателя кода руками или говорителя ртом университетских лекций?
Знания per se, на мой взгляд, в решениях проблем имеют более низкий приоритет перед умением своевременно их отыскивать и применять.
То есть исторически игры, конечно, развивались как развивающий симулятор реальности (начиная от прусских варгеймов XIX века, в которых изобрели туман войны как игровой приём), однако благодаря своей эффективности иногда они приносят сопутствующее наслаждение слишком сильно.
В современном мире да, но в довольно недавней истории были случаи, когда по итогам анализа родословных некоторые категории населения подвергались заточению и убийству.
— Робот может написать симфонию? Робот может превратить кусок холста в шедевр искусства?
— А ты можешь?
— …