LINUX.ORG.RU
ФорумTalks

Эйчары vs айтишники


7

1

Ошибки эйчаров, руководителей и прочих «собеседовальщиков».

1) «Работать в нашем банке» - большая честь! Отлично. Но _почему_? На этот вопрос очень редко кто может ответить. Когда ты задаешь этот вопрос эйчару, он просто ставит тебе «минус балл».

2) Отличным специалистам всегда есть где работать, они просто выбирают лучшее. Первый же вопрос эйчаров обычно состоит в том, «чем не понравилось текущее место работы», а следующий «почему

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

4) Молодому специалисту, по ряду причин которые здесь объяснять очень долго, вообще нужно менять работу раз в несколько месяцев. Получается, набирая студента на проект сроком на два года, они либо делают ему медвежью услугу (если таки уговорят остаться на два года), либо создают плохой прецедент (человек получает травму после срача „ты же обещал что останешься с нами навсегда, а сваливаешь сейчас!“, а компания приобретает дурную репутацию). Поэтому когда на работу устраивается бывший студент, вместо того чтобы расценивать его молодость и энергию как преимущество, обычно она расценивается как „минус несколько баллов“.

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

6) На вопрос „а если у меня есть собственные проекты?“ обычно говорят „это очень плохо“. При этом зачастую сами же в резюме пишут „наличие кода на гитхабе“. Это же вообще шизофрения. Теперь посмотрим, что считается причинами плохости в глазах эйчара. Первая - предпринимательская жилка. Знакомые америкосы специально ищут программистов с задатками предпринимательства. У нас такие задатки скорее считаются признаком того, что будущий сотрудник может обмануть и как-то хитро насрать работодателю, кинуть его, украсить его супертайную интеллектуальную собственность, или еще что-то такое, на что требуется неконвенционная самостоятельность. Вторая причина - „побочные проекты отвлекают от основной работы“. Аргумент про то, что 24-8 = 16 обычно не прокатывает. Подводя итог, собственные проекты - это „минус несколько баллов“.

7) Финансовая грамотность, особенно подкрепленная предпринимательскими талантами, тоже считается огромным минусом. Вслух мне так никто и не признался, почему, но на практике это означает, что вопросы типа „почему наш проект стал в 1.5 раза дороже, а зарплата у нас всё та же“ будут восприняты в штыки.

8) Вопросы про зарплату со внутренним настроем обмануть и поторговаться. „А с какой частотой стоит делать перерасчет? А что так часто?“. „А если мы заплатим вам не столько, сколько в вакансии, а на 10 тысяч меньше, вы обидетесь?“. Да, конечно обижусь. Идите нафиг. Кстати, многие пишут в вакансиях заведомо неправильные зарплаты, например 150т.р. при реальном максимуме в 80, надеясь, что таким образом они дадут начало „конструктивному диалогу“. Набирая людей, которые соглашаются с подобным положением вещей, они набирают тех, кто наиболее склонен обмануть работодателя по полной программе. Когда ты рассказываешь, что всё это отваритительно и лицемерно, тебе ставят минусбаллы.

9) Эйчары почему-то всегда считают, что именно они должны назначать встречи, и встречи эти можно назначать в стиле „когда-нибудь на следующей неделе“. И потом просрать встречу много-много раз, „ну я же женщина, мы всегда опаздываем!“ Также если ты не подошел (или даже подошел) на какую-то позицию, эйчары часто не звонят и не пишут об этом. О результатах собеседования приходится узнавать самому соискателю.

===

Имхо, как это должно быть.

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

В том числе:

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

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

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

4) Каждый должен иметь возможность понять, зачем и как работает компания целиком, и каждый его коллега в отдельности. Чтобы работать не по указке, а в соответствии с общими целями. Цели должны совпадать с собственным мироощущением человека.

===

Соответственно, правильные вопросы при приеме на работу:

1) Насколько тебе интересно то, чем мы занимаемся? Чем бы из этого ты хотел заняться?

2) Что тебе нравится? Чем мы можем помочь, чтобы ты занимался тем, что тебе нравится?

3) Сколько ты планируешь у нас прорабоать? Что нужно, чтобы ты проработал у нас дольше? Куда ты отправишься после нас?

4) Для того, чтобы тебе было хорошо, мы сделали вот это, это и это. Хочешь ли ты чего-нибудь еще?

5) Мы можем заплатить тебе вот столько, потому что (и расскажем еще больше когда подпишешь NDA, но пока вот только так). Перерасчитывать мы можем не чаще чем раз во столько-то, потому что наша структура работы с баблом такая-то.

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

===

Вы согласны?

★★★★☆
Ответ на: комментарий от nu11

может наоборот, не?

А слабо понять, почему написано именно так?

Как оценивать багфиксы

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

коммиты по одной строчке

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

много воплей и постоянные разборы

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

Что делать с гуем, архитекторами и тимлидами

А в чём проблема? Тимлиду 5% [прироста] бонуса ведомых. Архитекторы, по большому счёту, пишут тот же код, но на более высоком уровне абстракции, точно так же, компактная архитектура проще для понимания исполнителями, и исправления в ней точно так же дороги, т.ч. та же формула более-менее подойдёт и для них %(формальость выходного языка). Или, наоборот, весь «бюджет» уходит архитектору, и уже он «платит» исполнителям в зависимости от вклада, себе - что осталось. Проблемы с гуём мне неведомы, излагай, порешаем.

Пробовал на практике внедрять подобное

В отличии от TC я финансово неграмотен, предпринимательская жилка ампутирована в раннем детстве, а среди желающих порулить много людей и с харизмой >0; т.ч. внедрение недоступно. Но можно прогнать на существующем проекте с доступной историей, и сравнить полученные рейтинги с оценками участников. Готов финансировать исследования?

DonkeyHot ★★★★★
()
Ответ на: комментарий от DonkeyHot

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

самая большая глупость считать кого глупей себя)

quest ★★★★
()
Ответ на: комментарий от DonkeyHot

А слабо понять, почему написано именно так?

у тебя формула в общем виде и свойства f1 вообще не описаны. Кто ж тебя знает, что ты имел ввиду :)

f1 же над чертой - удалённый код так или иначе относится к багам

далеко не всегда верно.

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

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

Кто умудрился это сделать одной строкой, тот молодец.

и получит мало, т.к. в формуле сложность задачи никак не учитывается. Введешь поправочный коэффициент? ;)

Готов финансировать исследования?

я похож на спосора?

nu11 ★★★★★
()
Ответ на: комментарий от Gannet

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

Все, закрыли тему. Тебе и не такое придется услышать и увидеть :)

gh0stwizard ★★★★★
()
Ответ на: комментарий от loki_

Чушь, надо просто иметь голову на плечах и хороший опыт

Речь как бы о молодых специалистах.
Хороший опыт это обычно не год и не два работы, а лет 5.

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

winddos ★★★
()
Ответ на: комментарий от nu11

свойства f1 вообще не описаны

(обе с положительной производной)

точнее на глаз трудно.

удалённый код ... относится к багам ... далеко не всегда

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

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

Именно; он должен думать, как не написать 256 страниц лапши, которая потом ни в какую голову не влезет.

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

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

DonkeyHot ★★★★★
()
Ответ на: комментарий от DonkeyHot

При изменении архитектуры(бага в архитектуре)

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

Именно; он должен думать, как не написать 256 страниц лапши

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

Если у тебя есть метод априорной оценки сложности

оценить сложность можно только субъективно. При этом вся оценка становится по сути субъективной и смысла городить точные формулы нет

nu11 ★★★★★
()
Ответ на: комментарий от winddos

а, да, пропустил насчет молодых специалистов :)

сразу с вуза - разве что в техсаппорт на звонки отвечать

loki_ ★★
()
Ответ на: комментарий от nu11

отсутствие лапши решается другими методами

Какие из них проще тупой меркантильной заинтересованности испонителей?

Погоня за абстрактными попугаями приносит только геморрой

Нет, его приносят недостаточная автоматизация и/или неправильные попугаи. Автоматизация в предложенном варианте практически идеальна(человакам остаётся только выборочный review подозрительных патчей). А неправильность попугаев очень неочевидна; пока не видно ни желаемой но подавляемой характеристики процесса, ни нежелательной но стимулируемой.

Да, у некоторых несознательных пользователей может возникнуть желание воспользоваться дырами *любой* системы, и заняться тупым прокачиванием счётчиков. НО! для того, чтобы это стало интересным профессиональным разработчикам нужно, чтобы их недооценивали, держали на голодном пайке, и другими способами расстраивали. Такие конторы нам *неинтересны*, т.е. не попадают в область определения ф-ии.

DonkeyHot ★★★★★
()
Ответ на: комментарий от DonkeyHot

неправильность попугаев очень неочевидна

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

nu11 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.