Так гоу что мешает
Маразм на собеседованиях, который БЕСИТ. Взгляд со стороны соискателя
Идиотские вопросы
Кроме фирменного вопроса «Кем вы себя видите через 5 лет», бывают и другие, не менее тупые и бестактные. Животрепещущие примеры: «А почему у вас так много мест работы в резюме? Вы что, нигде не можете ужиться?», «Почему вы проработали в этих фирмах так мало?», «А сколько вам платили на предыдущем рабочем месте?».
Конечно, мы понимаем, что зачастую такие вопросы помогают отсеять самых долбанутых соискателей, но в целом все равно это тупо. Потому что:
Разберем по пунктам.
2) Здесь вполне серьезно. Конечно, соискатель может сказать что-то обтекаемое про то, что «на позиции дизайнера в ООО «Ромашка» можно получить до 10 стаканов пшена в месяц», но, во-первых, а нафиг оно вообще надо кандидату, а во-вторых, эйчары, вы серьезно думаете услышать реальные цифры?:) Там однозначно будет «бывшая зп + все премии + 20% сверху, чтобы было о чем поторговаться». К чему эти вопросы и на что надеятся кадровики — искренне недоумеваем.
3) У нас было такое, что эйчарки вообще не понимали, что такое это ваше NDA и с чем это едят. Они еще вдобавок бесились, когда мы на просьбы предоставить список клиентов, с которыми работали, или выкатить список работ отвечали тем, что с подписанным NDA это сделать нельзя. Видимо, в эйчары берут особо одаренных личностей, которые не умеют пользоваться гуглом.
В целом, даже с опытом подбора персонала мы все равно недоумеваем, за каким лешим эйчары задают подобные вопросы. Ответы все равно будут максимально обтекаемыми и близкими к ожидаемым.
Отсутствие диалога
Часто у потенциального работодателя на собеседовании просыпается комплекс Бога, и начинается настоящий цирк. Например, вам могут предложить только серую зп с минимальным официальным окладом. Вам принципиальна белая зп, ради которой вы готовы ужаться в размере зп или отказаться от части плюшек. Либо наоборот — вам не нужна полностью белая, вы хотите серую, но побольше. Если работодатель начинает давить вас в стиле «Стакан пшена официально, два стакана в мешке! Или соглашайся, или пошел нафиг!», то это нереально вымораживает. Если на собеседовании работодатель такой отбитый, то каким он будет в деле?
В мире уже давно поменялись тренды и приоритеты при выборе рабочего места. Зарплата сейчас зачастую не на первом месте. Кандидату могут быть важны такие мелочи, как близость к дому, оплата фитнеса и занятий иностранным, обучения и курсов, помощь в релокации и еще тысяча вариантов. Если работодатель не предлагает варианты и не готов к диалогу, то либо у него этих вариантов нет, либо там начальник с синдромом майора в отставке. В первом случае вам предложат стол, стул и старый комп в разбитом офисе промзоны, во втором примерно тоже самое плюс долбанутого начальника, который будет видеть в вас личного раба.
Ну его нафиг в общем.
Чересчур личные вопросы
Здесь тоже начинает дергаться глаз и появляется желание втащить собеседнику стулом.
«А вы замужем? А планируете?», «Дети есть? Сколько штук, сколько лет? Часто болеют?», «А у вас квартира своя или в ипотеке». Уууусука, аштрисет.
Боитесь, что принятая на работу незамужняя девушка выйдет взамуж и начнет клепать спиногрызов? Так не берите на работу баб вообще. Не нужно устраивать на собеседовании допрос в стиле приема гинеколога или требовать справку о том, что кандидатка не беременна. Думаете, стебемся. Нифига, реально такие было!
Мужскую половину подобные вопросы также не обходят стороной. Почему-то многие работодатели искренне считают, что мужику с тремя детьми и ипотекой будет тупо некуда бежать. Так вот он засядет в фирме, будет ишачить и делать все, что ему скажут. Огорчу. Это не всегда так. К тому же, соотношение «затраченное время — результат» могут быть весьма паршивыми.
Попытки продавить кандидата по зарплате
На арене блядского цирка (зачеркнуто) наши любимые манипуляции! Представитель фирмы, собеседующий вас, смотрит в ваше резюме и устраивает разнос. Уровень фирм, в которых вы работали — говно, проекты — говно, навыки — говно, одеты вы как говно. Чтобы вы не сделали, ваши опыт и достижения один фиг обесценят и превратят в какашку. Вы ничего не добились. Вы — неудачник и говно. Над вами будут открыто измываться, перевирать слова. Дополнительный способ доебаться до вас — спросить определение любого тупого термина и устроить после получения ответа разнос с упоминанием того, в каком мусорном бачке нужно оставить ваш диплом, резюме и вас. Если вы обладаете бешеной выдержкой (и дико низкой самооценкой) и сумели досидеть до момента обсуждения зп, то ваши запросы срежут примерно раза в два. С мотивировкой «А чо ты вообще умеешь такого делать, чтобы мы тебе столько платили?»
Узнали ситуацию? Глаза налились кровью? Вот у нас такая же реакция.
Игра в «Угадай мелодию»
Отдельный вид искусства. Вам не называют четкие пожелания ни в тексте вакансии, ни на собеседовании. При этом, вы должны угадать, что работодатель вообще хотел. Если не угадали, то собеседование резко сворачивается, и вас выкидывают пинком под зад из кабинета.
Выбешивает такое просто неимоверно.
Тесты
В общем, чего тут распинаться. Тесты — отличный признак шараги. Точнее, признак того, что вы убьете тест, а на собеседование никто потом не позовет.
Тесты психуелогические и на общую логику уже на собеседовании — тоже признак шараги. Вот спросили мы сейчас друг у друга про эти тесты. Все фирмы, где они были, оказались шарагами без перспектив. И после выполнения теста прилетел отказ, кстати.
Так что пусть просто эйчарки горят в аду со своей психологией.
Анкеты
Аштрисет. Приходишь на собеседование, а тебе в зубы вручают анкету на трех листах. Где в пунктах кроме той же самой информации про работу, которая есть в резюме, еще охрененные вопросы про близких родственников и их контакты, любимые книги и данные паспорта. Мол, на тебе, сердешный. Как заполнишь — поговорим. А что мешает посмотреть инфу касательно работы в резюме? Вытаскивание информации про родственников, паспортные данные и прочее вообще незаконно.
Хочется периодически запихнуть эту анкетку прямо на месте сами знаете куда и сами знаете кому. Кстати, если не заполнять разделы с личными данными, то можно наблюдать забавную истерику эйчарки и ее попытки показать себя ниибаца хозяйкой в этой фирме. Рекомендуем для развлечения, если жить совсем скучно стало.
Такие дела, котятки. Что делать на собеседовании, если вы столкнулись с подобным, решать уже вам. Кто-то готов налить в уши эйчарке сказку о том, какой он хороший, принести хоть пять справок о том, что нет алкогольной зависимости/долгов/судимостей и вообще ты бесплодный, заполнить пять анкет и сдать десять тестов. Для кого-то такая срань неприемлема. Лично для нас это все — треш, и мы не готовы танцевать на задних лапках перед долбанутым работодателем.
Почему дизайн Go плох для умных программистов
На протяжении последних месяцев я использую Go для имплементаций Proof of Concept (прим.пер.: код для проверки работоспособности идеи) в свободное время, отчасти для изучения самого языка программирования. Программы сами по себе очень просты и не являются целью написания статьи, но сам опыт использования Go заслуживает того, чтобы сказать о нем пару слов. Go обещает быть (прим.пер.: статья написана в 2015) массовым языком для серьезного масштабируемого кода. Язык создан в Google, в котором активно им пользуются. Подведя черту, я искренне считаю, что дизайн языка Go плох для умных программистов.
Создан для слабых программистов?
Go очень просто научиться, настолько просто, что введение заняло у меня один вечер, после чего уже мог продуктивно писать код. Книга по которой я изучал Go называется An Introduction to Programming in Go (перевод), она доступна в сети. Книгу, как и сам исходный код на Go, легко читать, в ней есть хорошие примеры кода, она содержит порядка 150 страниц, которые можно прочесть за раз. Сначала эта простота действует освежающе, особенно в мире программирования, полного переусложненных технологий. Но в итоге рано или поздно возникает мысль: «Так ли это на самом деле?»
Google утверждает, что простота Go — это подкупающая черта, и язык предназначен для максимальной продуктивности в больших командах, но я сомневаюсь в этом. Есть фичи, которых либо недостает, либо они чрезмерно подробны. А все из-за отсутствия доверия к разработчикам, с предположением, что они не в состоянии сделать что-либо правильно. Это стремление к простоте было сознательным решением разработчиков языка и, для того, чтобы полностью понять для чего это было нужно, мы должны понять мотивацию разработчиков и чего они добивались в Go.
Так для чего же он был создан таким простым? Вот пара цитат Роба Пайка (прим.пер.: один из соавторов языка Go):
Ключевой момент здесь, что наши программисты (прим.пер.: гуглеры) не исследователи. Они, как правило, весьма молоды, идут к нам после учебы, возможно изучали Java, или C/C++, или Python. Они не в состоянии понять выдающийся язык, но в то же время мы хотим, чтобы они создавали хорошее ПО. Именно поэтому их язык должен прост им для понимания и изучения.
Он должен быть знакомым, грубо говоря похожим на Си. Программисты работающие в Google рано начинают свою карьеру и в большинстве своем знакомы с процедурными языками, в частности семейства Си. Требование в скорой продуктивности на новом языке программирования означает, что язык не должен быть слишком радикальным.
Что? Так Роб Пайк в сущности говорит, что разработчики в Google не столь хороши, потому они и создали язык для идиотов (прим.пер.: dumbed down), так чтобы они были в состоянии что-то сделать. Что за высокомерный взгляд на собственных коллег? Я всегда считал, что разработчики Google отобраны из самых ярких и лучших на Земле. Конечно они могут справиться с чем-то посложнее?
Артефакты чрезмерной простоты
Быть простым — это достойное стремление в любом дизайне, а попытаться сделать нечто простым трудно. Однако при попытке решить (или даже выразить) сложные задачи, порой необходим сложный инструмент. Сложность и запутанность не лучшие черты языка программирования, но существует золотая середина, при которой в языке возможно создание элегантных абстракций, простых в понимании и использовании.
Не очень выразительный
Из-за стремления к простоте в Go отсутствуют конструкции, которые в остальных языках воспринимаются как что-то естественное. Вначале это может показаться хорошей идеей, но на практике выходит многословный код. Причина этому должна быть очевидна — необходимо, чтобы разработчикам было просто читать чужой код, но на самом деле эти упрощения только вредят читаемости. Сокращения в Go отсутствует: либо много, либо ничего.
К примеру, консольная утилита, которая читает stdin либо файл из аргументов командной строки, будет выглядеть следующим образом:
Хотя и этот код пытается быть как можно более общим, принудительная многословность Go мешает, и в результате решение простой задачи выливается в большой объем кода.
Вот, к примеру, решение той же задачи на D:
И кто теперь более читабельный? Я отдам свой голос D. Его код куда более читаемый, так как он более явно описывает действия. В D используются концепции куда сложнее (прим.пер.: альтернативный вызов функций и шаблоны), чем в примере с Go, но на самом деле нет ничего сложного в том, чтобы разобраться в них.
Ад копирования
Популярное предложение для улучшения Go — это обобщенность. Это хотя бы поможет избежать ненужного копирования кода для поддержки всех типов данных. К примеру, функцию для суммирования списка целых чисел можно реализовать никак иначе, кроме как ее копипастой ее базовой функции для каждого целого типа, другого способа нет:
И этот пример даже не работает для знаковых типов. Такой подход полностью нарушает принцип не повторять себя (DRY), один из наиболее известных и очевидных принципов, игнорирование которого является источником многих ошибок. Зачем Go это делает? Это ужасный аспект языка.
Тот же пример на D:
Простое, элегантное и прямо в точку. Здесь используется функция reduce для шаблонного типа и предиката. Да, это опять же сложнее варианта с Go, но не столь уж сложно для понимания умными программистами. Который из примеров проще поддерживать и легче читать?
Простой обход системы типов
Я полагаю, читая это, программисты Go будут с пеной во рту кричать: «Ты делаешь это не так!». Что же, есть еще один способ сделать обобщенную функцию и типы, но это полностью разрушает систему типов!
Взгляните на этот пример глупого исправления языка для обхода проблемы:
Эта имплементация Reduce была позаимствована из статьи Idiomatic generics in Go (прим.пер.: перевод не нашел, буду рад, если поможете с этим). Что же, если это идиоматично, я бы не хотел увидеть не идиоматичный пример. Использование interface<> — фарс, и в языке он нужен лишь для обхода типизации. Это пустой интерфейс и все типы его реализуют, позволяя полную свободу для всех. Этот стиль программирования до ужаса безобразен, и это еще не все. Для подобных акробатических трюков требуется использовать рефлексию времени выполнения. Даже Робу Пайку не нравятся индивиды, злоупотребляющие этим, о чем он упоминал в одном из своих докладов.
Это мощный инструмент, который должен быть использован с осторожностью. Его следует избегать пока в нем нет строгой необходимости.
Я бы взял шаблоны D вместо этой чепухи. Как кто-то может сказать, что interface<> более читаем или даже типобезопасен?
Горе управления зависимостями
У Go есть встроенная система зависимостей, построенная поверх популярных хостингов VCS. Поставляемые с Go инструменты знают об этим сервисах и могут скачивать, собирать и устанавливать из них код одним махом. Хотя это и здорово, есть крупная оплошность с версионированием! Да действительно, можно получить исходный код из сервисов вроде github или bitbucket с помощью инструментов Go, но нельзя указать версию. И снова простота в ущерб полезности. Я не в состоянии понять логику подобного решения.
После вопросов о решении этой проблемы, команда разработки Go создала ветку форума, в которой изложили, как они собираются обойти этот вопрос. Их рекомендация была просто однажды скопировать весь репозиторий себе в проект и оставить «как есть». Какого черта они думают? У нас есть потрясающие системы контроля версий с отличным теггированием и поддержкой версий, которые создатели Go игнорируют и просто копируют исходные тексты.
Культурный багаж из Си
По-моему мнению, Go был разработан людьми, которые использовали Си всю свою жизнь и теми, кто не хотел попытаться использовать что-то новое. Язык можно описать как Си с дополнительными колесиками(ориг.: training wheels). В нем нет новых идей, кроме поддержки параллелизма (который, кстати, прекрасен) и это обидно. У вас есть отличная параллельность в едва ли годном к употреблению, хромающем языке.
Еще одна скрипучая проблема в том, что Go — это процедурный язык (подобно тихому ужасу Си). В итоге начинаешь писать код в процедурном стиле, который ощущается архаичным и устаревшим. Я знаю, что объектно-ориентированное программирование — это не серебряная пуля, но было бы здорово иметь возможность абстрагировать детали в типы и обеспечить инкапсуляцию.
Простота для собственной выгоды
Go был разработан, чтобы быть простым и он преуспел в этой цели. Он был написан для слабых программистов, используя в качестве заготовки старый язык. Поставляется он в комплекте с простыми инструментами для выполнения простых вещей. Его просто читать и просто использовать.
Он крайне многословный, невыразительный и плох для умных программистов.