И вы верите, что сразу после института она будет в одиночку отвечать за подбор ключевого персонала для ООО ТЛК? Думаю, даже этой прекрасной конторе такое не под силу))
Тут речь идет не про гуглояндексы, а про ООО Теплый ламповый код. Я сильно сомневаюсь, что в такой компании будут ожидать что-то большее. Хотя, случаи разные бывают.
Чем выше должность тем выше ответственность и больше личного вклада требуется от человека. Люди, работающие только за зарплату, как правило не склонны к таким вложениям.
Человеку рассказали почему эта машина такая клевая. Как она разгоняется до сотни. Есть круиз-контроль.
Потом, когда он пришел заплатить денежки и попасть в узы кредитной кабалы ему задали вопрос: почему ты хочешь ее купить?
Первая мысль на выбор: потому что она — то, что мне сейчас нужно/блин, а вот тут климата нет, а там — есть, ну ее нафиг.
Заметьте: сейчас речь не идет о hr-е. Тот уже все соискателю рассказал и объяснил. Речь идет о человеке, с которым ему потом работать. И этот человек спрашивает, если расшифровать: «Вот тебе рассказали о том кто мы такие, чем занимаемся, какие перспективы у тебя тут будут и т.д. Теперь скажи: почему ты хочешь у нас работать?»
На ваш вопрос человек сидящий на втором-третьем-четвертом собеседовании скажет «Да.»
Вопрос «почему» задается не из-за желание услышать причины или штампованный или односложный ответ. Вопрос «почему» задается, чтобы вы сами смогли поразмыслить.
Я о других плюшках.
Вот смотрите: легко представить, что вы можете хотеть работать, скажем, в Google (Apple, MS, Yandex...) не только из-за технологий, зарплаты и макбуков. У этих компаний есть гораздо больше что предложить своим сотрудникам: причастность к большим делам, некая статусность, ну и технологии, конечно.
Представить что компания ООО Теплый ламповый код сможет в принципе заинтересовать вас до собеседования чем-то кроме оплаты и технологий (ну может, обучением, бесплатными обедами, командировками на Гоа — когда как) глупо. После первых раундов собеседования вы уже знаете о компании больше чем просто адрес и контактный телефон. Они уже рассказали вам о себе. И вам задается вопрос: «почему вы хотите у нас работать?».
Сказать: «Потому что меня устраивает зарплата и мне хочется работать с теми технологиями, которые вы предлагаете» — честно. И никто не ждет от вас сильно большего или сочинения на тему «Почему наши поезда поездаче». От вас фактически требуется только одно: принять для себя решение действительно ли вы хотите работать в компании. Все.
А вот то, что «Я не хочу у вас работать» — неправда, ведь вы же резюме прислали, на собеседование пришли.
Я бы вас на работу не взял из-за первого ответа.
Точнее — из-за первых двух предложений первого ответа. Если вы не хотите у меня работать, то зачем вы тогда пришли на собеседование. Если пришли, то вы хотите у меня работать. Другое дело, что я не смог предложить вам каких-нибудь действительно весомых плюшек, за исключением технологий+оплаты. Это нормально. И честно.
Но вы же не хотите.
Вы приходите устраиваться на работу в компанию, где по коридору ходят одни сплошные офисные зомби. Вам задают этот так вами нелюбимый вопрос. Вы думаете и решаете, что причины по которой вы хотите работать в этой компании у вас нет, а наоборот, есть причина не работать.
Собеседование — процесс обоюдной торговли: вы хотите продать себя подороже, но компании важно, чтобы вы тоже ее купили. Причем заметьте: из данной статьи следует, что вопрос задается уже после серии других собеседований, то есть у вас уже сложилось мнение о компании и задающий вопрос просто расчитывает, что вы для себя решите хотите ли вы работать с ними или нет.
Вот кстати пример: договоренность об использовании какого-либо стандарта оформления кода — это уже формализация инспекции (и разработки, соответственно).
Или есть у тебя гипотетически два способа реализации одного и того же алгоритма: простой и посложнее, но с оптимизацией по скорости. И вот если нет формального требования скорость оптимизировать — как выбрать наилучший?
Мысль по поводу:
Не возьмусь утверждать это со 100% достоверностью, однако видится мне, что большинство команд, которые только начинают внедрять гибкие методологии у себя в проектах рискуют наступить на одни серьезные грабли. Грабельки эти заключаются в том, что большинство самых популярных книжек относятся как это ни странно к процессной части аджайла (как планировать, как показывать, какой длины выбирать итерацию, какие практики использовать и т.д.). А вот о том, как управлять собственно людьми (которые, как известно, важнее процессов) в таких книжках ни сказано, как правило, ни слова. Подразумевается, что об этом вы почитаете в других уменых книжках.
И вот процесс вроде бы поставлен, а профита нет. Реальная причина этому — люди. Точнее — неумение их готовить.
Так что спасибо, Боря, что хоть затронул эту тему.
И позанудствую: формальная инспекция в отличие от просто инспекции кода имеет критерии начала, окончания и, извините, здравого смысла.
Если у тебя нет хоть капельку формализованного процесса инспекции (минимум тяжести — хотя бы опорные пункты), то ты рискуешь (с хорошей вероятностью) получить спор сколько должно быть пробелов в отступах и где открывается скобочка: в конце строки или в начале новой.
Вопрос только в том, что в гибких методологиях, имхо, не надо тяжелых чеклистов и сложных процессных конструкций, но договоренность (хотя бы) о том что проверяем и как быть должна.
ЕСЛИ (Вопрос == «Вы хотите у нас работать?») Ответ = «Да»
Он хочет, чтобы вы взвесили все свои за и против и приняли решение. Если он задаст простой вопрос, то вы даже думать не будете.
Потом, когда он пришел заплатить денежки и попасть в узы кредитной кабалы ему задали вопрос: почему ты хочешь ее купить?
Первая мысль на выбор: потому что она — то, что мне сейчас нужно/блин, а вот тут климата нет, а там — есть, ну ее нафиг.
Вопрос «почему» задается не из-за желание услышать причины или штампованный или односложный ответ. Вопрос «почему» задается, чтобы вы сами смогли поразмыслить.
Вот смотрите: легко представить, что вы можете хотеть работать, скажем, в Google (Apple, MS, Yandex...) не только из-за технологий, зарплаты и макбуков. У этих компаний есть гораздо больше что предложить своим сотрудникам: причастность к большим делам, некая статусность, ну и технологии, конечно.
Представить что компания ООО Теплый ламповый код сможет в принципе заинтересовать вас до собеседования чем-то кроме оплаты и технологий (ну может, обучением, бесплатными обедами, командировками на Гоа — когда как) глупо. После первых раундов собеседования вы уже знаете о компании больше чем просто адрес и контактный телефон. Они уже рассказали вам о себе. И вам задается вопрос: «почему вы хотите у нас работать?».
Сказать: «Потому что меня устраивает зарплата и мне хочется работать с теми технологиями, которые вы предлагаете» — честно. И никто не ждет от вас сильно большего или сочинения на тему «Почему наши поезда поездаче». От вас фактически требуется только одно: принять для себя решение действительно ли вы хотите работать в компании. Все.
А вот то, что «Я не хочу у вас работать» — неправда, ведь вы же резюме прислали, на собеседование пришли.
Точнее — из-за первых двух предложений первого ответа. Если вы не хотите у меня работать, то зачем вы тогда пришли на собеседование. Если пришли, то вы хотите у меня работать. Другое дело, что я не смог предложить вам каких-нибудь действительно весомых плюшек, за исключением технологий+оплаты. Это нормально. И честно.
Но вы же не хотите.
Собеседование — процесс обоюдной торговли: вы хотите продать себя подороже, но компании важно, чтобы вы тоже ее купили. Причем заметьте: из данной статьи следует, что вопрос задается уже после серии других собеседований, то есть у вас уже сложилось мнение о компании и задающий вопрос просто расчитывает, что вы для себя решите хотите ли вы работать с ними или нет.
Или есть у тебя гипотетически два способа реализации одного и того же алгоритма: простой и посложнее, но с оптимизацией по скорости. И вот если нет формального требования скорость оптимизировать — как выбрать наилучший?
Не возьмусь утверждать это со 100% достоверностью, однако видится мне, что большинство команд, которые только начинают внедрять гибкие методологии у себя в проектах рискуют наступить на одни серьезные грабли. Грабельки эти заключаются в том, что большинство самых популярных книжек относятся как это ни странно к процессной части аджайла (как планировать, как показывать, какой длины выбирать итерацию, какие практики использовать и т.д.). А вот о том, как управлять собственно людьми (которые, как известно, важнее процессов) в таких книжках ни сказано, как правило, ни слова. Подразумевается, что об этом вы почитаете в других уменых книжках.
И вот процесс вроде бы поставлен, а профита нет. Реальная причина этому — люди. Точнее — неумение их готовить.
Так что спасибо, Боря, что хоть затронул эту тему.
Если у тебя нет хоть капельку формализованного процесса инспекции (минимум тяжести — хотя бы опорные пункты), то ты рискуешь (с хорошей вероятностью) получить спор сколько должно быть пробелов в отступах и где открывается скобочка: в конце строки или в начале новой.
Вопрос только в том, что в гибких методологиях, имхо, не надо тяжелых чеклистов и сложных процессных конструкций, но договоренность (хотя бы) о том что проверяем и как быть должна.