Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 339
«5. Почему крышки на канализационных люках круглые? (Software engineer)
Ответ: чтобы не спотыкаться об углы»
Это шутка такая? Я думал что люки круглые что-бы у крышки не было возможности провалиться в люк.
А! Извиняюсь. Это кто-то пытался ответить на вопросы. Я думал что это правильные ответы размещены. :)
Ответ: чтобы не спотыкаться об углы»
Это шутка такая? Я думал что люки круглые что-бы у крышки не было возможности провалиться в люк.
А! Извиняюсь. Это кто-то пытался ответить на вопросы. Я думал что это правильные ответы размещены. :)
Чтоб, когда воруешь люк — было легче его укатить, он же тяжелый :)
«Ушки» всё равно будут мешать катить ) лучше сразу в багажник
Это единственная форма при которой люк нельзя уронить внутрь)
Не единственная, да и в любом случае роль играет наличие бортика.
Равносторонний треугольный люк невозможно провалить, например.
Равносторонний треугольник с бортиком (естественно — без бортика все проваливается) — можно провалить? Как?
ок
Возможно. Невозможно...
Я уж было грешным делом подумал что речь о суперпозиции соостояний…
Или, если в общем случае, нельзя провалить фигуру постоянной ширины. Это не только треугольник Рёло, но и всяческие многоугольники Рёло.
P.S. упс, не заметил, что ниже уже писали об этом…
P.S. упс, не заметил, что ниже уже писали об этом…
Легко. Повернуть его так, чтобы одна сторона была вертикальна, и опускать вплотную к стенке. Высота треугольника на 13% меньше стороны, так что провалится, если по пути не заклинит.
А равносторонний треугольный можно уронить внутрь?
Предположу, что не уронится любая равносторонняя фигура с нечетным количеством сторон.
А если слегка подумать, то легко догадаться, что эти фигуры «роняются».
Любая уронится. Высота многоугольника меньше его максимальной диагонали. Но чем больше сторон, тем меньше должны быть толщина крышки и ширина бортика.
Уронится бегом. Там высота, падающая из вершины на противоположную сторону всегда меньше линии, соединяющей эту вершину с любой из 2 вершин этой стоороны (для равностороннего треугольника — высота меньше стороны). Не уронится фигура постоянной ширины.
PS. Я должен был предугадать, что и без меня разъяснят, быстрее и доходчивей))
PS. Я должен был предугадать, что и без меня разъяснят, быстрее и доходчивей))
В Германии много прямоугольных люков. может они с воровством так борются )))
Собеседование в румынском офисе гугла )
Тюбинги, простите.
Палитесь)) Два акка?)
Было похоже, что вы извиняетесь не у hshhhhh за то, что его исправили, а у всех остальных за ошибку, которую сами допустили.
Тюбинги чугунные, это наборный элемент. А кольца сделаны (сюрприз!), чтобы распределять нагрузку, иначе земля сдавит колодец, углы поползут и колодец рано или поздно схлопнется. Да и еще — круг — самая экономичная форма.
Вот интересно, почему не делают тюбинги в форме треугольника Рёло в сечении?
Ответ с точки зрения материаловеда :)
Потому что при литье углы становятся концентраторами напряжений, и в будущем могут разрушится.
Круг идеален тем, что совсем не имеет концентраторов.
Потому что при литье углы становятся концентраторами напряжений, и в будущем могут разрушится.
Круг идеален тем, что совсем не имеет концентраторов.
А еще круглая крышка не провалится в люк. Бородатая задачка.
Ща, вот задачка покруче: почему в Узбекистане все дорожные знаки треугольные?
Ответ под спойлером
Потому что круглыми хорошо бочку закрывать, а из квадратных отличная лопата выходит. Это шутка, если что, не хотел никого обидеть.
Из треугольных тоже ничего лопата!
Сделаю вид что не смотрел под спойлер :) Но у нас таки есть круглые знаки, например кирпичи у нас круглые
тоже задачка: Почему в Узбекистане кирпичи — круглые%)?
Так их проще из тандыра доставать после запекания :)
отгадка: Потому что из круглых сложнее сделать лопату.
И чем же? Конец круглых ведь закруглять не надо.
Очень широкая будет лопата и круглая — ей копать нечего просто: ни снег ею не уберешь, ни в землю не воткнешь, а чтобы хорошую сделать, придется напильник искать.
Из круглого кирпича это уже не лопата получится, а первобытный молоток — булыжник, примотанный к палке. Правда, из обычных кирпичей лопата тоже не очень, но у них хоть острые рёбра есть.
Видно, что вы не были в Узбекистане.
Сегодня мы расскажем о внутреннем быте в кампусе Google. Это здание столовой, это восьмиэтажное здание обеденного отдыха, это пристройка для кодинга, а эта будка собеседований, где спрашивают про крышки люков. А прямо за ней километровая очередь людей, которые знают 100 вариантов ответа на вопрос: «почему крышки круглые?».
Если будет подобная статья на 20 экранов сплошного текста без картинок, то в комментариях не будет обсуждаться ничего кроме люков… По-моему стоит приравнять обсуждение люков к обсуждению кармы…
Если будет подобная статья на 20 экранов сплошного текста без картинок, то в комментариях не будет обсуждаться ничего кроме люков… По-моему стоит приравнять обсуждение люков к обсуждению кармы…
Гарднера читайте, прежде чем такие безапелляционные заявления делать!
Технологически: болванку легче сделать в виде цилиндра. При этом мы еще облегчаем и удешевляем процесс изготовления: гораздо проще на токарном станке доработать до круга требуемого радиуса, чем нежели что-то еще
Какая болванка, какой токарный станок? Крышки люков, как правило, чугуниевые и их изготавливают литьем :)
Да, я всегда считал что их нарезают. Ну тогда это еще проще: чтоб сделать точный прямой угол при литье — это надо приложить усилия. А с круглой формой проблем нет.
На такой вопрос обычно ставлю работодателя в тупик:
«Потому что они бывают еще и прямоугольные. Например, ливневая канализация.»
«Потому что они бывают еще и прямоугольные. Например, ливневая канализация.»
В штатах люки нередко квадратные, У нас редко встречаются
Элементарно, Ватсон (с). Квадратная крышка с круглым выступом, при этом «дырка» утоплена ниже поверхности на толщину крышки без выступа.
Разъем может быть и квадратным (газовые распредузлы в основном квадратные). На люк всегда стоит воронкообразный переходник, форма там может быть любая, хоть звездообразную сделают, если попросит заказчик. Колодец под люком почти всегда больше, чем сам люк.
Как вы себе представляете квадратную крышку люка, если «дырка» — круглая?
А ответ прост:
Вообще-то весь интерес этого вопроса именно в том, как поведёт себя собеседуемый при ответе на вопрос, где гарантированного есть более одного правильного ответа.
А ответ прост:
Вообще-то весь интерес этого вопроса именно в том, как поведёт себя собеседуемый при ответе на вопрос, где гарантированного есть более одного правильного ответа.
Они круглые, чтобы в условиях четвертой мировой войны гоплиты смогли использовать их в качестве щитов в фаланге, по связанной с этим причине арматура чаще всего имеет форму стержня.
Что за глупый вопрос про люки? Что за идиот ведет подобные собеседования?
Квадратных люков много: www.google.ru/search?q=%D0%BA%D0%B2%D0%B0%D0%B4%D1%80%D0%B0%D1%82%D0%BD%D1%8B%D0%B9+%D0%BB%D1%8E%D0%BA&newwindow=1&source=lnms&tbm=isch&sa=X&ei=e_7CUZ3OA8iK4gSbvYCQDw&ved=0CAcQ_AUoAQ&biw=1236&bih=751
Квадратных люков много: www.google.ru/search?q=%D0%BA%D0%B2%D0%B0%D0%B4%D1%80%D0%B0%D1%82%D0%BD%D1%8B%D0%B9+%D0%BB%D1%8E%D0%BA&newwindow=1&source=lnms&tbm=isch&sa=X&ei=e_7CUZ3OA8iK4gSbvYCQDw&ved=0CAcQ_AUoAQ&biw=1236&bih=751
Я не думаю, что падения крышки в люк — насущная актуальная проблема. Просто круг — оптимальная форма (важен большой диаметр — чтобы пролезть и минимум материала/копания шахты). Да и совпадает примерно с формой спускающегося человека, если он конечно не квадратный на проекции сверху.
Проблема не актуальна пока не уронишь. Килограммов 20 поднимать одной рукой, поднимаясь по вертикальной лестнице не интересно.
И несмотря ни на что — ливневые решетки всегда были прямоугольные в СССР. Я думаю, именно потому, что тут не под форму тушки делалось, а круглые — как раз под тушку.
Вопрос эффективности и потребности — в ливнёвку человеку спускаться не надо, шанс уронить маленький (их вообще редко трогали), а вот обычные люки зачастую размещаются на проезжей части или тротуарах, по ним ходят/ездят, требуется повышенная прочность, из-за чего они тяжелее, требуется доступность для снятия, чтобы спуститься и много чего ещё.
Ну и зря. Подобный «логический срез» всегда добавлял +1 лояльности к работодателям.
Я не про набор мозговзрывающих головоломок… но один такой вопрос… почему бы нет?
Каким образом это положительно влияло на лояльность к работодателю? Соискатель чувствовал себя участником «Своей игры», и ходил на собеседование только ради этого? Собеседование это этап найма на работу, а не игра. Если такой тип вопросов не повышает качество нанимаемых сотрудников и лояльность соискателей, он не нужен.
(( ладно… не так выразился… я хотел сказать про эмоциональную состовляющую…
Цель мозговзрывающих головоломок именно в том, чтобы взрывать мозг.
Если я беру программиста, то его квалификацию я проверю тестовым заданием и опросом по технологиям и т.п.
Даже степень его пункуальности можно проверить обычными тестовыми заданиями и т.п.
А вот поведение в неадекватной ситуации, поведение в условиях жестокого цейтнота и т.п. таким образом не проверишь.
Человека нужно кинуть в состояние взорванного мозга.
У меня новый сотрудник всегда первые две недели получает половину задач в несколько раз превосходящих его способности.
Т.е. если человек еще не знает специфику — я обязательно проговорю ему специфику быстро-быстро, и прослежу чтобы он не успел ее записать и т.п.
И нет, я не мудак. Просто я был вынужден потерять хорошего, талантливого сотрудника подходившего по всем параметрам, просто потому что человечек слишком эмоционально… заступился за меня, когда это было неуместно. С тех пор у меня обязательный стресс-тест в нештатных условиях.
Вру, не всех. Сейчас беру себе начальника (да, именно начальника, не заместителя… сам быть начальником не хочу / не могу, а быть рядовым сотрудником мне разрешили только при условии что я буду отвечать за начальника которого себе возьму), так его я на стресс не проверяю — я его уже пару лет как знаю, а вот всех малознакомых я на хайлоад обязательно тестирую.
Ну а на собеседовании как узнать готовность человека к сложным условиям, хоть в каком-то приближении? Один из вариантов это задать человеку идиотский вопрос, и посмотреть как он будет себя вести. Еще раз — мне все равно как он ответит. Мне важно как он будет держаться при этом, насколько уверенно, уважительно, спокойно и т.п.
Если я беру программиста, то его квалификацию я проверю тестовым заданием и опросом по технологиям и т.п.
Даже степень его пункуальности можно проверить обычными тестовыми заданиями и т.п.
А вот поведение в неадекватной ситуации, поведение в условиях жестокого цейтнота и т.п. таким образом не проверишь.
Человека нужно кинуть в состояние взорванного мозга.
У меня новый сотрудник всегда первые две недели получает половину задач в несколько раз превосходящих его способности.
Т.е. если человек еще не знает специфику — я обязательно проговорю ему специфику быстро-быстро, и прослежу чтобы он не успел ее записать и т.п.
И нет, я не мудак. Просто я был вынужден потерять хорошего, талантливого сотрудника подходившего по всем параметрам, просто потому что человечек слишком эмоционально… заступился за меня, когда это было неуместно. С тех пор у меня обязательный стресс-тест в нештатных условиях.
Вру, не всех. Сейчас беру себе начальника (да, именно начальника, не заместителя… сам быть начальником не хочу / не могу, а быть рядовым сотрудником мне разрешили только при условии что я буду отвечать за начальника которого себе возьму), так его я на стресс не проверяю — я его уже пару лет как знаю, а вот всех малознакомых я на хайлоад обязательно тестирую.
Ну а на собеседовании как узнать готовность человека к сложным условиям, хоть в каком-то приближении? Один из вариантов это задать человеку идиотский вопрос, и посмотреть как он будет себя вести. Еще раз — мне все равно как он ответит. Мне важно как он будет держаться при этом, насколько уверенно, уважительно, спокойно и т.п.
Я понял! В стиле Сталоне надо плюнуть в морду!
Плюнуть в морду это в любом случае провальная позиция, даже без учета моих ста килограмм.
А вот когда на йух посылали, то это не обязательно приводило к провалу собеседования. Все зависит от задач которые должен выполнять собеседуемый.
А вот когда на йух посылали, то это не обязательно приводило к провалу собеседования. Все зависит от задач которые должен выполнять собеседуемый.
Если вам всетаки важна уважительная позиция, почему вы работника ставите в роль раба? Это правда единственный способ?
Если вам нужна надежная работа сервера, то зачем вы ставите его под нагрузочное тестирование? Это правда единственный способ?
Я где-то сказал про роль раба? Про оскорбления? Унижения? Или я сказал о том, что я буду человека ругать или штрафовать за то, что он не справился с задачей с которой он и не мог справится?
Всегда стараюсь, чтобы не перегружать сотрудников, могу и сам остаться срочную работу доделывать, чтобы не задерживать после работы сотрудников и т.п. Просто я всегда придерживаюсь принципа — я вами руководил, я за вас в ответе. И никогда не буду говорить начальству мол «это не я виноват, это мне материал не подготовил Н».
И по факту никто из тех кто таки был принят не жаловался ни на проверки, ни на то, что я от них утаил часть функциональных обязанностей (ничего ужасного, к примеру не сказал, что сис.админу нужно будет работать плотно с 1С, что сам обучу — многие пугались и не шли, не верили в свои силы). И в качестве бонуса я прошу лишь такую малость — позвольте мне иметь не самых умных сотрудников, а лишь тех за кого не нужно будет краснеть.
Я где-то сказал про роль раба? Про оскорбления? Унижения? Или я сказал о том, что я буду человека ругать или штрафовать за то, что он не справился с задачей с которой он и не мог справится?
Всегда стараюсь, чтобы не перегружать сотрудников, могу и сам остаться срочную работу доделывать, чтобы не задерживать после работы сотрудников и т.п. Просто я всегда придерживаюсь принципа — я вами руководил, я за вас в ответе. И никогда не буду говорить начальству мол «это не я виноват, это мне материал не подготовил Н».
И по факту никто из тех кто таки был принят не жаловался ни на проверки, ни на то, что я от них утаил часть функциональных обязанностей (ничего ужасного, к примеру не сказал, что сис.админу нужно будет работать плотно с 1С, что сам обучу — многие пугались и не шли, не верили в свои силы). И в качестве бонуса я прошу лишь такую малость — позвольте мне иметь не самых умных сотрудников, а лишь тех за кого не нужно будет краснеть.
Я вот, например, сисадмин, но с 1С работать очень не люблю. Так что, узнав о такой «утайке», скорее всего распрощался бы с работодателем.
Вы распрощались бы еще раньше — вас бы не устроили условия.
А в конкретном случае я взял человека, который бы испугался слова «1С», и человек вырос золотым :)
А в конкретном случае я взял человека, который бы испугался слова «1С», и человек вырос золотым :)
Принуждение к использованию проприетарного ПО с применением ТК РФ?
ТК РФ? В Украине?)
а если серьезно, то в чем принуждение то?
человек на собеседовании всё узнал? узнал.
с хозяйством ознакомлен? ознакомлен.
Два года я обучал? обучал…
Должностную инструкцию при трудоустройстве подписывали? Подписывали.
Сертифицированные курсы за счет предприятия проходили? Проходили…
Пыток тоже вроде не припомню… откуда принуждение?)
а если серьезно, то в чем принуждение то?
человек на собеседовании всё узнал? узнал.
с хозяйством ознакомлен? ознакомлен.
Два года я обучал? обучал…
Должностную инструкцию при трудоустройстве подписывали? Подписывали.
Сертифицированные курсы за счет предприятия проходили? Проходили…
Пыток тоже вроде не припомню… откуда принуждение?)
ничего ужасного, к примеру не сказал, что сис.админу нужно будет работать плотно с 1С, что сам обучу — многие пугались и не шли, не верили в свои силы
Или по ТК Украины нет двух недель, которые работник должен отработать перед уходом по собственному желанию?
Ну должен, и что?
Данный конкретный человек вообще две недели «проработал» бесплатно и без оформления в начале, пока я обучил хоть минимально, да «в бою» проверил. Не понимаю как КЗоТ относится к теме статьи или моим словам?
Когда человек читал объявление то человек не знал что нужно работать с 1С. Когда человек попал на собеседование, то обо всем был предупрежден, и даже легкий ликбез был проведен, чтобы не пугались они… КЗоТ появляется намного позже…
И уж тем более не могу понять смысл слова «проприетарный» в вашем комментарии… Майкрософт Виндоус тоже проприетарный софт, и админам иногда приходится с ним работать… принуждение?..
В общем заканчиваем этот некропостинг.
Данный конкретный человек вообще две недели «проработал» бесплатно и без оформления в начале, пока я обучил хоть минимально, да «в бою» проверил. Не понимаю как КЗоТ относится к теме статьи или моим словам?
Когда человек читал объявление то человек не знал что нужно работать с 1С. Когда человек попал на собеседование, то обо всем был предупрежден, и даже легкий ликбез был проведен, чтобы не пугались они… КЗоТ появляется намного позже…
И уж тем более не могу понять смысл слова «проприетарный» в вашем комментарии… Майкрософт Виндоус тоже проприетарный софт, и админам иногда приходится с ним работать… принуждение?..
В общем заканчиваем этот некропостинг.
в ТК РФ тоже нет понятия «отработки» при увольнении — есть только то, что сотрудник должен известить не менее чем за две недели до увольнения (глава 13, статья 80)
А еще есть «по соглашению сторон», которое хоть в момент подачи заявления. А еще работодатели не очень то любят «принуждать работать», как минимум потому что от принужденного ответственного работника будет больше вреда, а на не ответственных должностях так и смысла в этом нет…
Ну и ссорится при увольнении мало кто хочет, если это адекватный руководитель а не самодур, потому как трудовое законодательство сложное, а трудовые судебные споры самые противные… нафик, нафик… проще уволить человека и забыть.
Две недели делаются для того, чтобы было время передать дела, сдать материалку, работодателю хоть как-то подстроится под ситуацию без работника, а в идеале и замену найти… Как это всё применяется в случае только нанятого человека который так ненавидит «проприетарщину», что его нужно «принуждать» работать, особенно учитывая что на то, чтобы обучить человека до уровня когда я на него тратил времени меньше чем то время которое он мне экономил (т.е. до хоть какой-то пользы предприятию) ушел месяц…
Я собственно потому и не стал акцент делать на таких мелочах, что оппонент в принципе не донес свою мысль про пытки проприетарщиной. Может мы вообще его не поняли, и он совсем другое имел ввиду? Может быть «ТК РФ» это Теологический Комплекс Реабилитации Форточек?)
Ну и ссорится при увольнении мало кто хочет, если это адекватный руководитель а не самодур, потому как трудовое законодательство сложное, а трудовые судебные споры самые противные… нафик, нафик… проще уволить человека и забыть.
Две недели делаются для того, чтобы было время передать дела, сдать материалку, работодателю хоть как-то подстроится под ситуацию без работника, а в идеале и замену найти… Как это всё применяется в случае только нанятого человека который так ненавидит «проприетарщину», что его нужно «принуждать» работать, особенно учитывая что на то, чтобы обучить человека до уровня когда я на него тратил времени меньше чем то время которое он мне экономил (т.е. до хоть какой-то пользы предприятию) ушел месяц…
Я собственно потому и не стал акцент делать на таких мелочах, что оппонент в принципе не донес свою мысль про пытки проприетарщиной. Может мы вообще его не поняли, и он совсем другое имел ввиду? Может быть «ТК РФ» это Теологический Комплекс Реабилитации Форточек?)
а что, есть какой-то запрет на это? на «принуждение» работать с тем ПО, которое используется в компании, где работает сотрудник
Содержимое вашей головы можно детям на завтрак давать.
Спасибо, красивое выражение, мне понравилось.
Вероятно, вы его не так поняли. Я про блюда типа овсянки или манной ;)
Все всё поняли... И выражение действительно красивое.
Вот зачем вы так? Я не люблю овсянку, и манку тоже. Давайте договоримся на гречку?
Умри lorndesign…
сразу -10 он им добавлял.
есть куча книг с решениями этих головоломок и глупо считать, что соискатель не проштудировал их предварительно.
есть куча книг с решениями этих головоломок и глупо считать, что соискатель не проштудировал их предварительно.
Я не пытался сказать именно о головоломках с люками и всему тому, что «очевидно» придумал Гугл… если что…
Тогда я думаю, что ты неточно выразился, а остальные поняли то, что хотели, а не то что ты имел в виду.
Да, вопросы, которые могут продемонстрировать работу логики — полезны, но большинство, под такими вопросами подразумевают именно эти злосчастные люки и теннисные мячики в автобусе.
Да, вопросы, которые могут продемонстрировать работу логики — полезны, но большинство, под такими вопросами подразумевают именно эти злосчастные люки и теннисные мячики в автобусе.
Да уж… ладно, уже прочуял хорошенько… Лавина — она такая… она сама остановится, я уже не пытаюсь…
Да почему ж ) можно и более простые вопросы.
Например, попробуй ответить, почему ручки у сумок для ноутов часто делают на кольцах, вместо того, чтобы сделать просто пришитую ручку?
Например, попробуй ответить, почему ручки у сумок для ноутов часто делают на кольцах, вместо того, чтобы сделать просто пришитую ручку?
Для этого потребуется невероятное умение собеседователя «качественно» оценить ход рассуждений. Ведь по сути нет одного чёткого и известного ответа на вопрос. Собеседователю придётся самому поднапрячься.
Ох. Тяжело. Сначала не смог вспомнить ни одной такой сумки (у всех мне знакомых пришиты.)
Загуглил картинку. Подумал.
В итоге я бы пришел к варианту с более удачным распределением нагрузки, если честно. Еще был вариант, чтобы легко отгибались и не мешали пользоваться отверстием для изъятия-вкладки ноута… Но он мне кажется странным.
А вы бы что предложили?
Загуглил картинку. Подумал.
В итоге я бы пришел к варианту с более удачным распределением нагрузки, если честно. Еще был вариант, чтобы легко отгибались и не мешали пользоваться отверстием для изъятия-вкладки ноута… Но он мне кажется странным.
А вы бы что предложили?
Наконец-то! Надеюсь это дойдет теперь до HR и менеджеров других компаний где практикуют подобную дурь на собеседованиях…
Дойдет, но не сразу. Как это было с модой задавать эти глупые вопросы :)
Карго-культ в миг не закончится :)
100%.
Это ведь не только глупых вопросов касается (и кстати судя по этому топику оказывается даже в гугле не знают для чего оно было придумано).
Это касается и практических задач… даже тех же чисел фибоначи… Многих мучали этими дурацкими задачами, но не многие знают на что правильно обращать внимание и т.п. (Это кстати к вопросу о том как у нас программиста заставляют собеседовать программиста, вместо того чтобы писать программы. «Принцип Питера» — отличная книга)
Это ведь не только глупых вопросов касается (и кстати судя по этому топику оказывается даже в гугле не знают для чего оно было придумано).
Это касается и практических задач… даже тех же чисел фибоначи… Многих мучали этими дурацкими задачами, но не многие знают на что правильно обращать внимание и т.п. (Это кстати к вопросу о том как у нас программиста заставляют собеседовать программиста, вместо того чтобы писать программы. «Принцип Питера» — отличная книга)
А программиста должен ортопед из соседней клиники собеседовать?
В Гугле уже как 5 лет бан на всяческие паззлы и головоломки, поэтому автор поста немного опоздал с новостью:)
Я всегда для себя крест ставил на тех интервьюеров, которые начинают голову морочить такими вопросами. Смерть им. Своей головой думать надо, а не всяким там подражать.
Не знал, что они придавали значение оценкам, полученным в колледже, но теперь это и не важно.
И славно! Это требование меня очень настораживало (тем, что могло войти в тренд). Не потому, что у меня самого плохие оценки (да, плохие :) ), но потому что они сначала принимают на работу гениального малематика из Оксфорда, потом садят верстать 36-ю страницу хэлпа, тем самым убивая его личность, а потом удивляются снижению мотивации сотрудников.
О, годно годно. К чёрту оценки.
По-моему, это было очевидно и без признаний гугла.
Но теперь и правда, хочется верить, что эта глупость уйдет из инструментария HR-ов. Хотя меня ни разу такое на собеседованиях не спрашивали.
Но теперь и правда, хочется верить, что эта глупость уйдет из инструментария HR-ов. Хотя меня ни разу такое на собеседованиях не спрашивали.
Вы в РБК устраиваться значит не ходили. Вопрос типа «Если вы заходите в метро и там куча народу, какие Ваши предположения?», вызывает в моем мозге «Что простите?»
Мне в РБК делать нечего :)
А что такого в этом вопросе? Сам по себе он довольно полезный. Когда я вижу кучу народу в метро (особенно в необычное время или в необычном месте), то всегда перебираю возможные варианты причин, чтобы решить, что делать дальше — лезть в эту толпу, поехать по другому маршруту или выйти и сесть на трамвай. Почему бы не озвучить эти рассуждения, если собеседнику так интересно?
Возможно, они видят в этой ситуации аналогию с такой: «программа не работает, ничего не понятно. Ваши предположения?»
Возможно, они видят в этой ситуации аналогию с такой: «программа не работает, ничего не понятно. Ваши предположения?»
У меня, наверное, было бы предположение, что я не туда попал. //имеется ввиду не метро, а рбк.
Забавно, что сайт первый в выдаче гугла по поводу «Сколько настройщиков...» сейчас лежит под хабраэффектом.
А зря. Ведь мало кто понимает, что за этим стоит огромный смысл именно при интервьюировании ПМ'ов. Стоит только заглянуть в такие книги как «Жемчужины программирования» Бентли или «Сколько стоит программный проект» Макконела. В этих книгах вы можете встретить такие вопросы и еще множество других, там доходчиво объясняется зачем же нужно отвечать на такие вопросы в повседневной жизни хотя бы с 90% вероятностью попадания в результат.
Именно от предсказания событий близкой к попаданию в 90%-е границы зависят качество сроков большинства проектов.
Ошибочно думать, что эти вопросы на смекалку или проверку умения креативно мыслить. Они в первую очередь нужны для оценки точности предугадывания событий основываясь лишь на имеющихся фактах потенциального ПМ'а.
Именно от предсказания событий близкой к попаданию в 90%-е границы зависят качество сроков большинства проектов.
Ошибочно думать, что эти вопросы на смекалку или проверку умения креативно мыслить. Они в первую очередь нужны для оценки точности предугадывания событий основываясь лишь на имеющихся фактах потенциального ПМ'а.
Качество оценки сроков проекта зависит от триллиона различных факторов, начиная от качества требований и эмпирических данных об эффективности команды в предыдущих итерациях и заканчивая тем, были ли учтены риски и фокус-фактор каждого участника проекта.
Макконел в этой же книжке не просто так рассказывает об исторических данных, калибровке оценок, декомпозиции и прочих няшек.
Очень грустно, если где-то об этом не знают и формируют сроки на фоне личных переживаний ПМ-а.
Макконел в этой же книжке не просто так рассказывает об исторических данных, калибровке оценок, декомпозиции и прочих няшек.
Очень грустно, если где-то об этом не знают и формируют сроки на фоне личных переживаний ПМ-а.
Но мучали-то этими вопросами не ПМов, а разработчиков, сисадминов, QA и т.д. Эдакий «тест на интеллект» для всякого входящего в штат Гугла.
Никого уже не мучают с 2008 года — если кто-то на интервью задаст головоломку, то с ним будет серьезный разговор, так как головоломки по мессаджу от Гугла являются просто waste of time и не позволяют ничего выявлять о кандидате.
С 2008 это слишком смело, еще в прошлом году моим знакомым вполне себе задавали головоломки. Не совсем абстракно-дурацкие типа шариков от пинг понга в самолете, но что-то вроде «каково минимальное количество шагов для того, чтобы получить 3 литра воды, если у вас в наличии 5-литровая и 2-литровая емкости?»
Когда я говорил, что не нужно задавать головоломки на собеседованиях, вы продолжали спрашивать почему люки круглые. Теперь у нас все знают почему люки круглые, но чем абстрактный класс… ну вы поняли…
Ещё это говорит о том, что рынок труда больше не может предоставить компаниям достаточное количество «решателей головоломок», в то время как проектов и продуктов становится всё больше. Работать некому, поэтому гугл увеличивает область охвата кандидатов.
Решатель головоломок != Хороший разработчик
Возможно, раньше хватало хороших разработчиков, которые одновременно были неплохими решателями головоломок. Теперь остается принимать на работу просто хороших разработчиков :)
Возможно, раньше хватало хороших разработчиков, которые одновременно были неплохими решателями головоломок. Теперь остается принимать на работу просто хороших разработчиков :)
Вот совершенно аналогично подумал. По сути: «Мы собрали всех гениев, теперь нам нужны рабочие пчёлки». Изменилась целевая аудитория, и методы набора перестали быть эффективными.
похоже на то, вот интересно с чего рынок так вырос или это только у гугла так с их политикой скупки стартапов.
?
?
К слову об оценках в колледже.
Недавно смотрел требования к кандидатам. Они убрали обязательное высшее образование из требований. 1.5 года назад это было обязательным условием.
Недавно смотрел требования к кандидатам. Они убрали обязательное высшее образование из требований. 1.5 года назад это было обязательным условием.
Надо различать логико-математические задачи с однозначным правильным решением и открытые вопросы, которые якобы призваны посмотреть, как испытуемый мыслит. Задачи очень даже хорошо помогают определить способности кандидата, а вот всякий трешачок вроде «сколько шариков поместится в автобус?» или «сколько заправок в стране?» действительно бесполезен.
мне больше всего нравиться ответ на вопрос:
Потому что она закрывает шахту, которая круглая! А вот почему делают круглые шахты — это другой вопрос! (хотя, возможно здесь причинно-следственная связь может быть нарушена: возможно, важно именно что бы крышка была круглая, а шахта уже делается под крышку. Но знает ли это менеджер, который не имеет на самом деле отношения к шахтам и люкам?)
Почему крышка люка круглая?
Потому что она закрывает шахту, которая круглая! А вот почему делают круглые шахты — это другой вопрос! (хотя, возможно здесь причинно-следственная связь может быть нарушена: возможно, важно именно что бы крышка была круглая, а шахта уже делается под крышку. Но знает ли это менеджер, который не имеет на самом деле отношения к шахтам и люкам?)
Ой, «меньшее значение придается оценкам в колледже», это как? Меньше нуля?
Такими темпами скоро разрешат пользоваться текстовыми редакторами для написания кода, а там, глядишь, и ide…
На самом деле это не крышка круглая, а круг имеет форму крышки.
Ещё древние египтяне заметили, что если взять верёвку с привязанными к ней колышками, воткнуть один из них в землю, а другим, натянув верёвку, прочертить борозду, получившаяся фигура будет иметь удивительное сходство с канализационным люком. Этот факт имел огромное прикладное значение, поскольку избавил геометров от необходимости таскать с собой набор люков различного диаметра для рисования кругов разного размера. Впрочем, такое построение является приближенным. Из-за того, что круг, начерченный с помощью верёвки и колышков (или, что примерно то же самое, циркулем) по форме всё же немного отличается от люка, число пи ошибочно полагают равным не трём, а приблизительно 3.1415926, хотя в Библии значение числа пи указано совершенно чётко.
Кстати, немногим известно, что с использованием люка вместо циркуля становятся разрешимы такие задачи, как трисекция угла и удвоение куба. А ещё сферу можно рисовать, приложив гиперлюк к пространству и обведя его карандашом.
Ещё древние египтяне заметили, что если взять верёвку с привязанными к ней колышками, воткнуть один из них в землю, а другим, натянув верёвку, прочертить борозду, получившаяся фигура будет иметь удивительное сходство с канализационным люком. Этот факт имел огромное прикладное значение, поскольку избавил геометров от необходимости таскать с собой набор люков различного диаметра для рисования кругов разного размера. Впрочем, такое построение является приближенным. Из-за того, что круг, начерченный с помощью верёвки и колышков (или, что примерно то же самое, циркулем) по форме всё же немного отличается от люка, число пи ошибочно полагают равным не трём, а приблизительно 3.1415926, хотя в Библии значение числа пи указано совершенно чётко.
Кстати, немногим известно, что с использованием люка вместо циркуля становятся разрешимы такие задачи, как трисекция угла и удвоение куба. А ещё сферу можно рисовать, приложив гиперлюк к пространству и обведя его карандашом.
гиперкарандашём Он должен рисовать двумерную поверхность а не линию.
Можно гомоморфно отобразить на сферу кривую Пеано. Если обвести её обычным, линейным карандашом, сфера будет обведена всюду плотно.
Из-за ограничений СТО, на это потребуется время, большее срока существования Вселенной :(
Значит, нужно взять два карандаша.
Двух тоже мало. Надо «е» карандашей, а лучше — «пи» (учитывая, что рисовать надо сферу).
Можно взять пирог, и на каждый его рог нацепить по карандашу.
Если пирог с повидлом, достаточно разломить его, приложить к гиперлюку и замазать этим повидлом сферу. И никаких гиперкарандашей не надо.
Отсыпьте мне тоже :)
Пожалуйста: http://teamikaria.com/hddb/forum/
Скрытый текст
Достаточно иметь голову :-)
И вроде не пятница…
Круг — священная фигура, потому что имеет форму медного таза крышки, которой накроется мир в конце своего существования;-)
Явно ж где-то издеваетесь над чувствами верующих. Не могу только понять где…
На всякий случай трешечку вам выпишут :)
На всякий случай трешечку вам выпишут :)
Вау, шокирующая новость о вреде головоломок и отказе от них — 2 с половиной года назад в книге «Кодеры за работой» (интервью с Фицпатриком, стр.82 русскоязычного издания), сегодня — на Хабре! Вот это оперативность! Даёшь еще шокирующих новинок!
Google признала, что головоломки на собеседованиях бесполезны@ Просто геи из гугула издевались над натуралами приходящими к ним на работу.
Вы это не понаслышке знаете, да?
Ну зачем так грубо переходить на личности. Эти факты не обязательно «знать не понаслышке», потому что они давно преданы гласности посредством СМИ.
Разве не доводилось читать Вам, что в компании Google за гомосексуализм дают специальную надбавку к зарплате, так что в компании этой больше гомосеков, нежели в любой другой компании в США?
С учётом этих сведений и та версия, которую lokus107 изложил, вполне имеет право на жизнь.
Не понимаю, почему его реплику минусуют.
Разве не доводилось читать Вам, что в компании Google за гомосексуализм дают специальную надбавку к зарплате, так что в компании этой больше гомосеков, нежели в любой другой компании в США?
С учётом этих сведений и та версия, которую lokus107 изложил, вполне имеет право на жизнь.
Не понимаю, почему его реплику минусуют.
Депутат Мизулина, перелогиньтесь.
Ну некое абстрактное «количество извилин» головоломками измерить можно. Наверное «извилин» в компании уже хватает, больше нужны «прямые руки»
Что и требовалось доказать. Головоломки эти неплохо простебали в фильме Internship.
Человек, задающий такие вопросы, у меня всегда вызывал стойкий образ самодура, любящего наблюдать за корчами претендентов от его «нестандартненьких вопросиков».
Удивлён, что до гугла только сейчас дошло, что высокие оценки в учебных заведениях точно предсказывают лишь способность получать высокие оценки в учебных заведениях (например тупым заучиванием или дрессировкой).
Удивлён, что до гугла только сейчас дошло, что высокие оценки в учебных заведениях точно предсказывают лишь способность получать высокие оценки в учебных заведениях (например тупым заучиванием или дрессировкой).
Поэтому вы бросили школу?
высокие оценки в учебных заведениях точно предсказывают лишь способность получать высокие оценки в учебных заведениях (например тупым заучиванием или дрессировкой).
Позволю не согласиться с Вами. Во-первых смотря какой ВУЗ. Красный диплом бауманки всегда вызывает уважение. Во-вторых высокие оценки в институте все-таки дают некоторое представление о способности человека учиться. Кстати, зубрежка тоже не каждому по зубам — для этого нужно обладать определенной целеустремленностью.
Всё правильно, потому я и говорил о гарантированных предсказаниях. Так то в высокой оценке как таковой не обязательно есть что-то плохое. Но гугл раньше тупо резал претендентов по планке среднего балла, что, мне всегда казалось, неверно. Зубрёжка, в отрыве от всего остального, не даёт представление о предмете зубрёжки.
Видимо стало слишком много людей в гугле, которые только умеют решать головоломки.
Сразу вспоминается вот этот пост: habrahabr.ru/post/145960/
Сразу вспоминается вот этот пост: habrahabr.ru/post/145960/
О, да Гугел сказал, теперь это истина в последней инстанции. [сарказмъ]
Я задаю на интервью нестандартные вопросы и буду их задавать по одной причине. Паззлы — это круто. Люди которые любят паззлы любят решать задачи. Не хреначить терабайты красивого кода, не дрочить на модные книжки, не выносить мозг коллегам на тему того, как кошерно делать канбан, а именно решать задачи.
Понимаете? Они получают удовольствие от логического мышления. Это определенный класс людей. Они в детстве ходили на кружок математики, любят Myths Busters и презирают Top Gear. Из них получаются хорошие инженеры. Потому что, черт дери, инженер должен решать задачи и получать удовольствие от этого. Ну и кстати да, помимо задачек мы вместе пишем код на интервью…
А кто не любит задачки? Тот любит понты, процесс и распределение ответственности. Такие люди тоже нужны, но я их обычно не итервьирую, мне это не интересно. Фигня в том, что «нестандартное мышление» стало стандартным требованием. Поэтому теперь это часть практики. Все HR задают эти вопросы, хотя сами задачки не любят. И вы «готовитесь к интервью» подсматривая ответы в интернетах, хотя тоже не любите задачки.
Паззлы рулят, что бы там Лессло не говорило. ИМХО.
Я задаю на интервью нестандартные вопросы и буду их задавать по одной причине. Паззлы — это круто. Люди которые любят паззлы любят решать задачи. Не хреначить терабайты красивого кода, не дрочить на модные книжки, не выносить мозг коллегам на тему того, как кошерно делать канбан, а именно решать задачи.
Понимаете? Они получают удовольствие от логического мышления. Это определенный класс людей. Они в детстве ходили на кружок математики, любят Myths Busters и презирают Top Gear. Из них получаются хорошие инженеры. Потому что, черт дери, инженер должен решать задачи и получать удовольствие от этого. Ну и кстати да, помимо задачек мы вместе пишем код на интервью…
А кто не любит задачки? Тот любит понты, процесс и распределение ответственности. Такие люди тоже нужны, но я их обычно не итервьирую, мне это не интересно. Фигня в том, что «нестандартное мышление» стало стандартным требованием. Поэтому теперь это часть практики. Все HR задают эти вопросы, хотя сами задачки не любят. И вы «готовитесь к интервью» подсматривая ответы в интернетах, хотя тоже не любите задачки.
Паззлы рулят, что бы там Лессло не говорило. ИМХО.
На собеседовании присутствует стресс, мешающий получить удовольствие от логического мышления. Я посетил более десятка интервью и думал, что сохраняю хладнокровие. Однако на одном из последних собеседований не смог за 15 минут найти решение задачи, которую потом в спокойной обстановке решил за 3 минуты.
Помню, как-то раз на собеседовании поверг в шок эйчара, попросив ещё головоломок.
Умм… Интервьювер просто дал вам задачу и сказал решайте? Или вы с ним вместе ее обсуждали?
Если у вас в процессе обсуждения возникает стресс, который вам мешает думать — это очень плохо.
Если же интервьювер дал вам листочек с надписью «как сделать игру жизнь на бесконечном нециклическом поле, у вас 15 мин.» и ушел пить кофе — то он и не любит задачки.
Если у вас в процессе обсуждения возникает стресс, который вам мешает думать — это очень плохо.
Если же интервьювер дал вам листочек с надписью «как сделать игру жизнь на бесконечном нециклическом поле, у вас 15 мин.» и ушел пить кофе — то он и не любит задачки.
Обсуждали вместе. Вопрос был типа — оценить время (в O — нотации), за которое можно обойти определенную структуру данных. Я сразу взялся рассказывать первый пришедший в голову способ, чтобы не выглядеть тормозом. А надо было честно попросить минутку подумать.
С моей точки зрения это плюс. Вы придумали какое-то решение, пусть не правильное, но быстро. Потом найдете свою ошибку и допилите. Хуже когда люди утыкаются в лаптоп на полчаса и на все попытки вырвать их из мыслительной комы бурчат про «не готово». Я хочу видеть как вы думаете, на конечный результат мне пофигу.
А вы в курсе, что некоторым людям сложно общаться с незнакомыми людьми? Да, это грустно и печально, но ничего плохого о собеседнике не говорит.
К сожалению. Но нам это важно. Мы аутсорсеры. Мы продаем сервис. Нам надо говорить с богатыми, неадекватными, незнакомыми клиентами. Чтобы они стали адекватными, знакомыми, и как можно более бедными ;-)
Я думал, что для этого есть менеджеры. Не?
Люблю задачки, но, не люблю паззлы и смотрю topgear. Жаль, что вы меня не возьмете…
Плюс много. Решать интересные задачки, да ещё и в режиме диалога с интервьюерами — круто.
Те, кто пишет про стресс, что для программиста главное — спокойствие, скажите: а ошибки в продакшене вы как чините, совсем без стресса, да? Только не надо говорить, что их не бывает, если правильно тестировать и бла-бла-бла.
Те, кто пишет про стресс, что для программиста главное — спокойствие, скажите: а ошибки в продакшене вы как чините, совсем без стресса, да? Только не надо говорить, что их не бывает, если правильно тестировать и бла-бла-бла.
А что стрессового для программиста в ошибках на продакшене? Это у QA стресс, они же пропустили :) И у саппорта — поскольку им гневные письма разгребать. Программистов нервничающих по поводу бага не встречала очень давно.
То, что их надо починить в кратчайшие сроки (сервис почти не работает, пользователи волнуются, у менеджеров седеют волосы на попе), а баг то ещё найти надо и понять, как чинить. Для меня это стресс в положительном смысле, это драйв и челлендж. А для кого-то это перенапряг, ему надо спокойно думать, погулять в парке и т.д.
Не вижу причин аврала у программистов в данной ситуации.
Вот у эксплуатационщиков, которые выкатывали новую версию и не имели плана отката аврал будет, но программисты то тут причем?
Если «сервис почти не работает, пользователи волнуются, у менеджеров седеют волосы на попе», значит сервис важный и должны быть процедуры обновления/отката изменений и резервирования. Если их нет, значит сервис не на столько важный и будет лежать столько, сколько нужно для решения проблемы.
Вот у эксплуатационщиков, которые выкатывали новую версию и не имели плана отката аврал будет, но программисты то тут причем?
Если «сервис почти не работает, пользователи волнуются, у менеджеров седеют волосы на попе», значит сервис важный и должны быть процедуры обновления/отката изменений и резервирования. Если их нет, значит сервис не на столько важный и будет лежать столько, сколько нужно для решения проблемы.
Именно. Более того, даже если программист предложит плохое решение, заплатку, то на любые претензии потом разведет руками — «а что вы хотели? это же хотфикс. для нормального решения, которое будет со всех сторон протестировано, нужно время». И будет вполне себе прав.
Да, иногда надо работать быстро, иногда надо работать много (если сроки поджимают), но далеко не всегда это означает стресс. В стрессовую ситуацию программист попадает только если у него менеджер — создатель стрессовой обстановки. Но в идеале лучше не стрессоустойчивость иметь, а сменить такого менеджера или компанию.
Да, иногда надо работать быстро, иногда надо работать много (если сроки поджимают), но далеко не всегда это означает стресс. В стрессовую ситуацию программист попадает только если у него менеджер — создатель стрессовой обстановки. Но в идеале лучше не стрессоустойчивость иметь, а сменить такого менеджера или компанию.
Есть реальные идеи как сменить менеджера? Какие-то технологии есть?
1) Налаживать контакт с менеджером менеджера и доносить, что товарищ неэффективен, а без него работать будет лучше и проще чем с ним.
2) Налаживать контакты с начальниками других отделов, и в подходящей ситуации переводится к ним.
2) Налаживать контакты с начальниками других отделов, и в подходящей ситуации переводится к ним.
А оно вам надо? Проще или не парится, или сменить работу. Можно для очистки совести сначала пойти к начальству и объяснить почему считаете что нужно сменить манагера даже если ценой смены работы. Но это опасно — могут поставить манагером вас.
Технологии конечно есть, но зачем оно нормальному разрабу? Война это лишний стресс, а мы от него как раз уйти и собираемся.
Кстати вот сейчас только сообразил — а ведь в идеале не менять манагера, а проапгрейдить его. Помочь организовать работу так, чтобы без стрессов. Если не получится, то тогда уже менять.
Технологии конечно есть, но зачем оно нормальному разрабу? Война это лишний стресс, а мы от него как раз уйти и собираемся.
Кстати вот сейчас только сообразил — а ведь в идеале не менять манагера, а проапгрейдить его. Помочь организовать работу так, чтобы без стрессов. Если не получится, то тогда уже менять.
Надо/не надо — вопрос времени и места. Технологии знать надобно, даже если ты сам — уже менеджер. Где еще про такие технологии расскажут, как не на хабре. Вы считаете, что апгрейдить менеджера может быть проще, чем заменять, но ему же не 3 года от роду, мозг нитками не заштопаешь и проводки в нем не спаяешь. Нет ли случаем здесь статей типа: «Как я поменял менеджера»? А вообще эта ситуация что ты в нужном месте в нужное время, но менеджер такой — она заставляет думать на необычные темы.
Где еще про такие технологии расскажут, как не на хабре
Базовые — в книжках.
Остальные — на сайтах соответствующих проектов и в тематических блогах.
Хабр — это все-таки не системное изложение, а «по вершкам», больше для информативности. Конечно, есть отдельные хорошие статьи, но нет систематического изложения крупных порций материала.
Можно начинать работать напрямую с начальником этого менеджера.
И еще можно играть на его косяках.
И еще можно играть на его косяках.
Иногда откатываться некуда :) Редко, но бывает. Вы сконвертировали базу, пожили с ней неделю, и всё сложилось так, что появился страшный баг. Вы не можете уже откатиться без потери информации, а чинить надо. Или пиар акция уже назначена, и починить в итоге всё равно надо быстро, даже откатываясь. А вот как раз для эксплуатации аврала нету, откат — штатная операция, они всегда к этому готовы.
Альтернативная история из мира разработки на заказ: продукт надо отдавать заказчику через 3 дня, но нашёлся Страшный Баг, который не проявлялся из-за особенностей тестового окружения.
Альтернативная история из мира разработки на заказ: продукт надо отдавать заказчику через 3 дня, но нашёлся Страшный Баг, который не проявлялся из-за особенностей тестового окружения.
Вы сконвертировали базу, пожили с ней неделю
Я являюсь адептом совместимых схем :)
который не проявлялся из-за особенностей тестового окружения.
Проблемы тестировщиков программистов не волнуют. Тестировщики не смогли собрать стенд, который эмулирует среду заказчика, значит они и виноваты.
Редко, но бывает.
Да, редко бывает, но может лучше направлять усилия на минимизацию этих рисков, чем на поиск программистов, которые будут продолжать работать даже если вокруг офиса будут греметь взрывы и уж тем более не ставить стрессоустойчивость на первое место…
Вообще, в случае проблемы в продакшене обычно есть два варианта развития событий. В первом люди ищут пути скорейшего разрешения проблемы и помогают друг другу. Во втором ищут пути, как бы скинуть с себя ответственность. Судя по вашему ответу, вы придерживаетесь второго варианта. Я работал в компании, в которой тоже делали так. К счастью, на текущем месте работы мы занимаемся решением проблем.
Вы можете являться адептом чего угодно, но формат хранения данных иногда меняется, по объективным и веским причинам. Приведу простейший пример: лет 10 назад FAT конвертировали в NTFS для возможности хранения 4ГБ образов DVD дисков, обратно отконвертировать уже нельзя.
Невозможно протестировать всё. Если вы эмулируете среду заказчика — вы уже получаете не идентичный стенд. Иногда просто невозможно создать идентичное окружение: если в продакшене 1000 серверов, то ещё одной тысячи для тестирования может и не оказаться, или физически некуда поставить, неоткуда взять питание. Залить/сгенерировать несколько сотен терабайт данных тоже большая проблема. Сделать нагрузку, идентичную продакшену, сложно и затратно в плане ресурсов. Я уж не говорю про многопоточный код, race далеко не каждый раз появляется даже при нагрузочном тестировании.
Вот вам пример на счёт тестирования: пишете код, как в этом примере из официальной документации, получаете дедлок, который появляется с очень маленькой вероятностью. Отловить такое при тестировании, даже при наличии нагрузочных тестов, крайне сложно.
Вы можете являться адептом чего угодно, но формат хранения данных иногда меняется, по объективным и веским причинам. Приведу простейший пример: лет 10 назад FAT конвертировали в NTFS для возможности хранения 4ГБ образов DVD дисков, обратно отконвертировать уже нельзя.
Невозможно протестировать всё. Если вы эмулируете среду заказчика — вы уже получаете не идентичный стенд. Иногда просто невозможно создать идентичное окружение: если в продакшене 1000 серверов, то ещё одной тысячи для тестирования может и не оказаться, или физически некуда поставить, неоткуда взять питание. Залить/сгенерировать несколько сотен терабайт данных тоже большая проблема. Сделать нагрузку, идентичную продакшену, сложно и затратно в плане ресурсов. Я уж не говорю про многопоточный код, race далеко не каждый раз появляется даже при нагрузочном тестировании.
Вот вам пример на счёт тестирования: пишете код, как в этом примере из официальной документации, получаете дедлок, который появляется с очень маленькой вероятностью. Отловить такое при тестировании, даже при наличии нагрузочных тестов, крайне сложно.
Вообще-то я описал первый вариант, а Вы описали второй. Вы сами сказали, что такие ситуации — это стресс для программистов, а стресс в данных ситуациях будет только тогда, когда нет процедур восстановления и зон ответственности, те когда все пытаются валить на других и все восстановить нужно вчера.
Когда все помогают друг другу для решения задачи — стресса нет и все решается в рабочем порядке, а не путем наказания невиновных и награждения непричастных.
Если такие ситуации возникают раз в 10 лет, то их можно и пережить, но читая Ваши сообщения про стресс итд у меня возникает мнение, что это практически норма, как это ни печально…
Все невозможно, с этим я согласен, но все остальное — это отговорки, а не препятствия. Нет 1000 серверов, не переводите весь кластер сразу, используйте постепенный ввод новой версии и сплит-тестирование. Нагрузка — то-же самое.
Несколько сотен терабайт… Ну если их надо сохранить, то да дисков для тестов может и не быть, но если их нужно передать и обработать, то ничего страшного в этом не вижу.
Как я уже сказал выше, такие ситуации бывают, но они должны во первых бывать редко, а во вторых, если они случаются, то источниками стресса они быть не должны ибо стресс — это проблема менеджеров и тех, кто пропустил косяк, а остальные должны спокойно работать на разрешение ситуации.
Когда все помогают друг другу для решения задачи — стресса нет и все решается в рабочем порядке, а не путем наказания невиновных и награждения непричастных.
Приведу простейший пример
Если такие ситуации возникают раз в 10 лет, то их можно и пережить, но читая Ваши сообщения про стресс итд у меня возникает мнение, что это практически норма, как это ни печально…
Невозможно протестировать всё.
Все невозможно, с этим я согласен, но все остальное — это отговорки, а не препятствия. Нет 1000 серверов, не переводите весь кластер сразу, используйте постепенный ввод новой версии и сплит-тестирование. Нагрузка — то-же самое.
Несколько сотен терабайт… Ну если их надо сохранить, то да дисков для тестов может и не быть, но если их нужно передать и обработать, то ничего страшного в этом не вижу.
Как я уже сказал выше, такие ситуации бывают, но они должны во первых бывать редко, а во вторых, если они случаются, то источниками стресса они быть не должны ибо стресс — это проблема менеджеров и тех, кто пропустил косяк, а остальные должны спокойно работать на разрешение ситуации.
Вообще-то я описал первый вариант, а Вы описали второй.
Не вы ли писали про виноватых?
Проблемы тестировщиков программистов не волнуют. Тестировщики не смогли собрать стенд, который эмулирует среду заказчика, значит они и виноваты.
Вы сами сказали, что такие ситуации — это стресс для программистов, а стресс в данных ситуациях будет только тогда, когда нет процедур восстановления и зон ответственности, те когда все пытаются валить на других и все восстановить нужно вчера.
Наверное, стоит тогда определиться, что есть стресс. Если проблему надо быстро найти и решить, работая при этом с живыми данными, максимально сокращая стадию тестирования, и всё это сильно выбивается из нормального ритма работы — это стресс. Примерно как попасть в занос на машине зимой. Есть зоны ответственности, есть процедуры восстановления, но они уже не отработали, это та самая ситуация, что случается редко. Но как только случилась — действовать надо быстро, точно и слаженной командой.
Продолжая аналогию с машиной — у вас уже стоит зимняя резина, и вы вели машину аккуратно. Но покрытие оказалось коварным, ветер неудачно дунул, и машину начало заносить. Хладнокровно нажав на газ (передний привод) и подработав рулём вы выходите из заноса и продолжаете движение. Запаникуете и жмакнете на тормоз — в лучшем случае вас просто развернёт.
Как я уже сказал выше, такие ситуации бывают, но они должны во первых бывать редко, а во вторых, если они случаются, то источниками стресса они быть не должны ибо стресс — это проблема менеджеров и тех, кто пропустил косяк,
Заметьте, вы опять говорите про виноватых. Менеджеры, разработчики и тестировщики работают вместе, их задача — сделать качественный продукт. Если всплыл баг в продакшене, то, скорее всего, виноваты все: одни его сделали, вторые не отловили, третьи просто потому что ответственные за продукт. Вот если один и тот же баг регулярно всплывает — то что-то не так в консерватории. Кстати, совсем не понимаю, почему у QA то стресс должен быть? Ну не смогли найти ошибку, бывает, это нормально. Если косяков в самом процессе тестирования не было — то их даже премии не за что лишать.
а остальные должны спокойно работать на разрешение ситуации.
Спокойно — это как, неспешно попивая кофеёк, а в 19:00 встал и пошёл домой? Фиговенький тогда сервис, прямо скажем. Повторюсь, это ситуация, когда некуда откатываться, чинить надо здесь и сейчас. Или вы говорите про быстро и уверенно? Но темп работы всё равно же будет отличаться от обычного.
Все невозможно, с этим я согласен, но все остальное — это отговорки, а не препятствия. Нет 1000 серверов, не переводите весь кластер сразу, используйте постепенный ввод новой версии и сплит-тестирование. Нагрузка — то-же самое.
Иногда 1000 серверов — это не 1000 одинаковых независимых серверов, а единая система, и сервера постоянно взаимодействуют друг с другом. И проблема не в том, как ведёт себя каждый из них, а как они все вместе себя ведут. Например, в случае p2p взаимодействия количество внутренних связей растёт квадратично, а ресурсы каждого из серверов не растут совсем. Оценить поведение подобной системы по уменьшенной в N раз модели не всегда возможно. А с нагрузкой, простите, что то же самое? Я уже привёл пример, когда ошибку даже при нагрузочном тестировании сложно отловить.
Несколько сотен терабайт… Ну если их надо сохранить, то да дисков для тестов может и не быть, но если их нужно передать и обработать, то ничего страшного в этом не вижу.
Прогнать по сети сотню терабайт уже не быстро, но я всё же хранение имел в виду.
Есть множество людей, которым некомфортно работать в подобных условиях, и они (люди) не становятся от этого плохими. Достаточно при устройстве на работу спросить, а могут ли подобные штуки случаться, и если могут — то просто не идти туда. А кому-то решать подобные проблемы на живую нравится, и просто каждый день программировать от звонка до звонка скучно.
Не вы ли писали про виноватых?
Это значит что на разборе полетов огребут тестировщики, как ответственные за качество, за то, что какие-то аспекты недостаточно протестировали. Или не огребут, если объективно этого предвидеть было нельзя.
Но если Вы рассматриваете эту ситуацию как источник стресса для программистов, то значит у вас наблюдается не что иное, как перекладывание ответственности именно на программистов (подход ААА, все лежит нужно починить вчера — это перекладывание ответственности за срыв сроков на тех, кто не может на них влиять).
Наверное, стоит тогда определиться, что есть стресс. Если проблему надо быстро найти и решить, работая при этом с живыми данными, максимально сокращая стадию тестирования, и всё это сильно выбивается из нормального ритма работы — это стресс.
А, ну если давать такое определение то я с вами согласен. Но мое личное определение стресса несколько жестче будет и я ориентировался на него. Да и если занос зимой будет приводить к мгновенному стрессу, то адекватного руления, работы педалями можно и не дождаться.
А с нагрузкой, простите, что то же самое?
То же самое — постепенный ввод новой системы с переводом части нагрузки на нее. Если сломалось раньше, чем перешли то ой и откатываемся. Есть вариант зеркалирования части реальной нагрузки на тестовую ферму и наблюдение за ее поведением (ответы тестовой фермы отправляются в /dev/null), есть еще много других вариантов зависящих от задачи.
Спокойно — это как, неспешно попивая кофеёк, а в 19:00 встал и пошёл домой?… Или вы говорите про быстро и уверенно? Но темп работы всё равно же будет отличаться от обычного.
Спокойно — это спокойно, а не безразлично(безразлично — это в 17-30 встать и домой). По крайней мере с выпиныванием всех верещащих, что у них волосы седеют за пределы видимости, чтобы мельтешением не мешали решать проблему. Возможно, быстро и уверенно, но я предпочитаю говорить спокойно. Темп должен быть таким, чтобы не наделать еще более фатальных ошибок.
Заметьте, вы опять говорите про виноватых.
Виноватый, а точнее ответственный за недоработку, должен быть всегда, чтобы точно такая же ситуация не повторялась в будущем, но разбираться нужно потом, когда проблема решена.
Для QA выяснить могли ли они предсказать или выявить проблему заранее. Не всем разборы полетов нравятся. Возможно и программист допустивший баг должен будет узнать о себе что-то новое. Но причину появления проблемы найти в любом случае нужно.
В любом случае поиск ответственных должен проходить с того, кто подписал релиз, кто подписался за качество, и далее в низ по цепочке производства, по этому для QA тут стресс вполне может быть ибо их первых будут проверять…
Однажды CTO проводил интервью архитектора СУБД. Тот был ученый муж с идеальным резюме. «Скажите, вы теряли когда-либо данные на продакшене?» спросил CTO. «Нигода! Мы всегда все тестировали на в QA и с операционистами на стейджинге!» ответил архитектор. «Гоните его в шею» — сказал CTO, — «он либо дурак, либо врет».
Вы опять вернулись к концепции «наказать виновных». Взрослые ответственные профессионалы сами готовы сказать «да, вот тут оказалась проблема, мы не знали, что так может случиться, теперь будем знать и учитывать в будущем». Стресс на эту тему (ожидание наказания) у разработчика должен быть только если он знает, что все вокруг уверены, что он плохо работал и всё случилось из-за него. Чтобы не было такого стресса обычно достаточно хорошо работать. Так какое у вас определение стресса?
Про постепенный ввод нагрузки — вы опять забыли, что этап перехода на новую версию позади и откатываться уже некуда. Для зеркалирования внешней нагрузки на тестинг нужно решить нетривиальную, в общем случае, задачу по поддержанию одинакового внутреннего состояния систем (продакшена и тестинга). В простейшем случае — базы данных должны быть синхронны, иначе будут сыпаться ошибки. Для этого вам надо либо посылать ВСЕ запросы в тестинг (и он должен быть размером с продакшен), либо делать срезы, но это тоже сложно. Есть много вариантов, но, опять же, невозможно протестировать всё.
Если у менеджера седеют волосы — это не значит, что он верещит. Нормальный менеджер будет лишь спрашивать, как он может помочь, кого ещё вызвонить-позвать и т.д., то есть способствовать процессу.
Опять вы про виноватых. Прочитайте мой пример из камента выше, про буст и код из официальной документации. Кого назначаете виновным?
Про постепенный ввод нагрузки — вы опять забыли, что этап перехода на новую версию позади и откатываться уже некуда. Для зеркалирования внешней нагрузки на тестинг нужно решить нетривиальную, в общем случае, задачу по поддержанию одинакового внутреннего состояния систем (продакшена и тестинга). В простейшем случае — базы данных должны быть синхронны, иначе будут сыпаться ошибки. Для этого вам надо либо посылать ВСЕ запросы в тестинг (и он должен быть размером с продакшен), либо делать срезы, но это тоже сложно. Есть много вариантов, но, опять же, невозможно протестировать всё.
Если у менеджера седеют волосы — это не значит, что он верещит. Нормальный менеджер будет лишь спрашивать, как он может помочь, кого ещё вызвонить-позвать и т.д., то есть способствовать процессу.
Опять вы про виноватых. Прочитайте мой пример из камента выше, про буст и код из официальной документации. Кого назначаете виновным?
Давайте уже уйдем от чувства вины. Ну не додумались написать тест, в котором guid равен E9568F36-D428-11d2-A769-00AA001ACF42, ну всякое бывает… Или там сегфолт какой поймали в серверном ПО, или уязвимость стала известна новая. Мало ли причин где никто не виноват.
Это первое чего от него хотелось бы. Но не всегда после этого он способен сохранять работоспособность и
Если у менеджера седеют волосы — это не значит, что он верещит.
Это первое чего от него хотелось бы. Но не всегда после этого он способен сохранять работоспособность и
спрашивать, как он может помочь, кого ещё вызвонить-позвать и т.д., то есть способствовать процессу.
Опять вы про виноватых. Прочитайте мой пример из камента выше, про буст и код из официальной документации. Кого назначаете виновным?
А по вашему нечего? В данном случае вина за сбой на баге во внешней библиотеке. Или в вашей картине мира виной чего-либо может быть только человек?
Про постепенный ввод нагрузки — вы опять забыли, что этап перехода на новую версию позади и откатываться уже некуда.
Ситуации и решения разные бывают. Я предложил решения, которые в конкретной вашей ситуации не подходили. Точнее ситуацию я не знаю, по этому предлагаю закрыть эту часть спора.
Если у менеджера седеют волосы — это не значит, что он верещит. Нормальный менеджер будет лишь спрашивать, как он может помочь, кого ещё вызвонить-позвать и т.д., то есть способствовать процессу.
Разработчики нормального менеджера НЕ будут знать, где и что у него седеет. Если разработчикам об этом сообщили, то это скорее то, что сообщают всем неконструктивные детали происходящего -> мешают.
Пожалуй я переборщил с термином огребут, ибо не сторонник я прилюдной порки, но сторонник того, что после выявления причин их обязательно необходимо донести до соответствующих лиц по возможности по одиночке.
И Ваши слова тоже подтверждают такую необходимость ибо в противном случае профессионал бы сказал, «да Я допустил просчет и не ожидал появления проблемы в этой части, однако были приняты меры по ее исправлению и учету в будущем, чтобы не допустить ее повторения». Любое «Мы» в подобный объяснениях — это перекладывание ответственности с себя на группу лиц, а группа лиц по определению не может ни за что отвечать.
Ну а стресс на работе для меня, это когда во время выполнения срочной работы мне настойчиво сообщают совершенно ненужные подробности, например о поседении волос, цене простоя и т.д. Грубо говоря, когда мешают работать. А на счет живых данных — осторожность в любом случае по умолчанию должна быть включена. Чай/кофе кстати работать не мешает, по этому те, кто считает, что в таких ситуациях нельзя неспешно пить чай/кофе параллельно с работой я тоже причисляю к источникам стресса, так как их мнение в отличие от чая/кофе тоже мешает нормально работать.
А по вашему нечего? В данном случае вина за сбой на баге во внешней библиотеке. Или в вашей картине мира виной чего-либо может быть только человек?
И что теперь, наказать её и поставить в угол? Перестать использовать? Разработчики баг и так сами нашли и осознали, остальные понимают его смутно, могут разве что в чеклист проверок кода добавить.
Ситуации и решения разные бывают. Я предложил решения, которые в конкретной вашей ситуации не подходили. Точнее ситуацию я не знаю, по этому предлагаю закрыть эту часть спора.
Надеюсь, вы осознали факт, что бывают объективные причины, и не надо в первую очередь валить всё на QA.
Разработчики нормального менеджера НЕ будут знать, где и что у него седеет. Если разработчикам об этом сообщили, то это скорее то, что сообщают всем неконструктивные детали происходящего -> мешают.
Кажется, я уже несколько раз упоминал командную работу, что в данном случае означает, что менеджер помогает. Но сказать, что случилась беда и насколько всё плохо он должен.
Пожалуй я переборщил с термином огребут, ибо не сторонник я прилюдной порки, но сторонник того, что после выявления причин их обязательно необходимо донести до соответствующих лиц по возможности по одиночке.
И Ваши слова тоже подтверждают такую необходимость ибо в противном случае профессионал бы сказал, «да Я допустил просчет и не ожидал появления проблемы в этой части, однако были приняты меры по ее исправлению и учету в будущем, чтобы не допустить ее повторения». Любое «Мы» в подобный объяснениях — это перекладывание ответственности с себя на группу лиц, а группа лиц по определению не может ни за что отвечать.
«Мы», при командной разработке, очевидно, означает, что ни один из разработчиков не знал о проблеме. И, продолжая мой пример, это не просчёт, абсолютно никакой вины разработчиков нету. Наоборот, чуть ли не премию надо давать — смогли в короткие сроки найти проблему в чужой библиотеке и понять, как её обойти. Если же кто-то действительно сам багу сделал, то не обязательно его тыкать в багу носом, как нашкодившего котёнка. Если вы считаете, что вам такая терапия необходимо — то хорошо, но не всем она идёт на пользу.
Ну а стресс на работе для меня, это когда во время выполнения срочной работы мне настойчиво сообщают совершенно ненужные подробности, например о поседении волос, цене простоя и т.д. Грубо говоря, когда мешают работать. А на счет живых данных — осторожность в любом случае по умолчанию должна быть включена. Чай/кофе кстати работать не мешает, по этому те, кто считает, что в таких ситуациях нельзя неспешно пить чай/кофе параллельно с работой я тоже причисляю к источникам стресса, так как их мнение в отличие от чая/кофе тоже мешает нормально работать.
То есть саму ситуацию, когда вы в пятницу в 11 вечера уже пятый час пытаетесь понять, где же проблема, сервис, которым вы небезосновательно гордитесь, работает плохо, и вам до завтрашнего утра надо обязательно всё починить, стрессовой не считаете? Ок.
Ну и про чай. Про неспешное испитие чая я имел в виду именно неспешное испитие под беседу с коллегой о несовершенстве мира или колонизации Марса.
А любви к головоломкам достаточно, чтобы у вас интервью пройти? Или еще какие-то скиллзы нужны?
— Стоит четырехэтажный дом, в каждом этаже по восьми окон, на крыше — два слуховых окна и две трубы, в каждом этаже по два квартиранта. А теперь скажите, господа, в каком году умерла у швейцара бабушка?
Господа скажут что вы читали Швейка, это однозначно вам плюс.
В 1868-ом.
Это правдоподобный ответ, потому что в то время швейцаров было много, и у многих из них был бабушки, которые хоть иногда да умирали.
Мой ответ правильный, а если у вас есть сомнения, то докажите, что мой ответ неверный. Наличие другого верного ответа не опровергает правильность моего, так что я пошел дальше обедать.
Это правдоподобный ответ, потому что в то время швейцаров было много, и у многих из них был бабушки, которые хоть иногда да умирали.
Мой ответ правильный, а если у вас есть сомнения, то докажите, что мой ответ неверный. Наличие другого верного ответа не опровергает правильность моего, так что я пошел дальше обедать.
Но у вас не хватает доказательств, что в 1868-м умерла хотя бы одна бабушка какого-либо швейцара :-)
Умирание нешвейцарских бабушек не в счет!
Умирание нешвейцарских бабушек не в счет!
А теперь скажите, господа, в каком году умерла у швейцара бабушка?
В техническом задании не было ни слова про доказательство.
Я дал вам правильный ответ. Я дал вам эвристику которая показывает высокую степень достоверности.
В принципе даже ее не обязательно было приводить. Сомнения в правильности моего ответа сродни чайнику Рассела, так что как-то не возбуждают :)
ПЫСЫ: а вопрос кстати подразумевал ответ, или это шутка?
Если да, то есть еще такая версия ответа
В стиле жирафов и холодильников: Бабушка умерла в последний год своей жизни.
Но у вас не хватает доказательств, что в 1868-м умерла хотя бы одна бабушка какого-либо швейцараПо крайней мере это более вероятно, чем то, что ни у одной умершей в 1868-м году женщины не было внука-швейцара.
Ходжа Насреддин одобряет ваш ответ.
upd: Подумалось, что люди могут не знать, так что:
— А не скажет ли досточтимый Ходжа, сколько звезд и планет на небе?— спросил ученый.
— Скажу,— отвечает Ходжа.— Звезд и планет на небе столько, сколько волос на моем осле!
— Мы были бы счастливы услышать убедительное доказательство этого утверждения,— сказал ученый.
— А вы пересчитайте волосы на шкуре моего осла! — отвечает Насреддин.
— А не скажет ли досточтимый Ходжа, сколько звезд и планет на небе?— спросил ученый.
— Скажу,— отвечает Ходжа.— Звезд и планет на небе столько, сколько волос на моем осле!
— Мы были бы счастливы услышать убедительное доказательство этого утверждения,— сказал ученый.
— А вы пересчитайте волосы на шкуре моего осла! — отвечает Насреддин.
Я подумаю какие задавать вопросы гуглу когда они прийдут звать меня на работу а я всеравно не пойду…
Больно много шума вокруг них последнее время. Есть миллион других контор где вам будут платить лучше но Вам не понадобиться зарывать свои таланты на обычной рутине, сделать которую могут и не прошедший их тесты. Они хотят лучших- пусть тогда гарантируют интересную работу. А лепить фигню, которую, возможно потом ещё и прикроют, ради их столовки увольте.
п.с. Что бы принять человека на работу и выяснить подходит ли он достаточно 10 минут общения по теме или просто заглянуть в его код и пообщаться о жизни. Все эти уловки с тестами не более как попытка дилетантов в какой то конкретной области (в которой Вам прийдётся программировать) выяснить насколько вы подходите. Дилетант в распознавании образов не может нанимать спеца в этой области, потому что тупо знает меньше любого кто прийдёт на эту работу, и глупо подменять знания тестами. Дилетант не может оценить красоту или некрасивость его кода, его идеи и планы.
п.с. Ждём когда гугл поймёт, что нанимать спеца должны те кто в этой области работает а не менеджеры по персоналу с их бесполезными тестами. Им не мешало бы научиться выкапывать самородки на гитхабе или ещё где а не набирать пару недель потренировавшихся на их опросниках.
Больно много шума вокруг них последнее время. Есть миллион других контор где вам будут платить лучше но Вам не понадобиться зарывать свои таланты на обычной рутине, сделать которую могут и не прошедший их тесты. Они хотят лучших- пусть тогда гарантируют интересную работу. А лепить фигню, которую, возможно потом ещё и прикроют, ради их столовки увольте.
п.с. Что бы принять человека на работу и выяснить подходит ли он достаточно 10 минут общения по теме или просто заглянуть в его код и пообщаться о жизни. Все эти уловки с тестами не более как попытка дилетантов в какой то конкретной области (в которой Вам прийдётся программировать) выяснить насколько вы подходите. Дилетант в распознавании образов не может нанимать спеца в этой области, потому что тупо знает меньше любого кто прийдёт на эту работу, и глупо подменять знания тестами. Дилетант не может оценить красоту или некрасивость его кода, его идеи и планы.
п.с. Ждём когда гугл поймёт, что нанимать спеца должны те кто в этой области работает а не менеджеры по персоналу с их бесполезными тестами. Им не мешало бы научиться выкапывать самородки на гитхабе или ещё где а не набирать пару недель потренировавшихся на их опросниках.
За десять минут узнать пригодность сотрудника нельзя.
Да и за день тоже. За месяц более-менее можно.
И принимать персонал на работу должны специалисты по персоналу.
На предприятии где я являюсь фактическим руководителем, и есть кадровики, я отправляю людей к кадровикам, со своей рецензией.
На предприятии где я являюсь по факту руководителем ИТ-подразделения, я привожу человека к кадровикам со своей рецензией.
Я даю свою экспертную оценку по профпригодности, и если имею свои выводы, то по моему мнению о личностных качествах, или если я знаком с человеком и т.п. Могу не привести человека если считаю, что «мы не сработаемся», ибо мне с ним работать и за него отвечать.
Но выдав свою рецензию, я передаю инициативу специалистам. И по личностым качествам, и по психологии и по юридическим формальностям и т.п. — пусть лучше занимается тот, кто должен этим заниматься.
И я не считаю, что это неправильно.
Нет, я могу надавить, если это уместно и целесообразно. Или даже перепрыгнуть через голову ОК, если не вижу обоснованных возражений (как это и было неделю назад, когда единственным аргументом ОК против кандидата было… в общем личное мнение ОК о том, нужен ли нам сотрудник на эту вакансию), но это уже исключения, и личные взаимоотношения и т.п.
И даже когда я кого-то лоббировал, то я всегда внимательно выслушивал конструктивные возражения, и часто менял свое мнение.
ПЫСЫ: и да, у меня были люди которых мы не взяли по ошибке ОК (в том случае когда я был подчиненным). Но в целом я считаю что пользы от ОК было больше чем вреда.
Да и за день тоже. За месяц более-менее можно.
И принимать персонал на работу должны специалисты по персоналу.
На предприятии где я являюсь фактическим руководителем, и есть кадровики, я отправляю людей к кадровикам, со своей рецензией.
На предприятии где я являюсь по факту руководителем ИТ-подразделения, я привожу человека к кадровикам со своей рецензией.
Я даю свою экспертную оценку по профпригодности, и если имею свои выводы, то по моему мнению о личностных качествах, или если я знаком с человеком и т.п. Могу не привести человека если считаю, что «мы не сработаемся», ибо мне с ним работать и за него отвечать.
Но выдав свою рецензию, я передаю инициативу специалистам. И по личностым качествам, и по психологии и по юридическим формальностям и т.п. — пусть лучше занимается тот, кто должен этим заниматься.
И я не считаю, что это неправильно.
Нет, я могу надавить, если это уместно и целесообразно. Или даже перепрыгнуть через голову ОК, если не вижу обоснованных возражений (как это и было неделю назад, когда единственным аргументом ОК против кандидата было… в общем личное мнение ОК о том, нужен ли нам сотрудник на эту вакансию), но это уже исключения, и личные взаимоотношения и т.п.
И даже когда я кого-то лоббировал, то я всегда внимательно выслушивал конструктивные возражения, и часто менял свое мнение.
ПЫСЫ: и да, у меня были люди которых мы не взяли по ошибке ОК (в том случае когда я был подчиненным). Но в целом я считаю что пользы от ОК было больше чем вреда.
Не далее как на прошлой неделе беседовал с человеком. Время не засекал но довольно быстро поймал себя на мысли «как мало времени надо чтобы оценить знания спеца когда он близок тебе по тематике». После этой беседы, с вероятностью гораздо большей нежели у менеджера из отдела кадров, я знал что такой спец украсил бы наш коллектив. Мне даже дико думать, что какойто менеджер будет проверять такого на предмет сообразительности. Зачем это лишнее звено между спецами и соискателем? Где логика, зачем начинать проверять если ты не способен проверить то что нужно? Заметьте, Вы описали схему когда сначала Вы оцениваете человека а потом отдел кадров, а я о схеме когда отдел кадров отфутболивает зачастую тех кого надо брать обеими руками. Если ты сам не способен оценить профнавыки человека найми спеца который может это сделать. Кстати, человек о котором идет реч, был нанят клиентами, дабы проверить, всели мы делаем правильно при написании софта. Тоже, своего рода собеседование, только доверили его не кому попало а спецу. И это правильно, так хоть будешь уверен что тебя оценили по делам а не съиграли с тобой в лотерею.
Просьба только правильно меня понять, я не против отдела кадров как такового. Я против такой очередности. Стрессоустойчивость это важно, но важнее знания и умения.
Зависит от задачи.
Я ведь не даром писал, что некоторые из тех кто таки послал меня на йух — были приняты.
И поверьте, я не мстительный :)
Я ведь не даром писал, что некоторые из тех кто таки послал меня на йух — были приняты.
И поверьте, я не мстительный :)
Не знаю как сейчас в России но в Германии существует определённый голод на спецов. Фирмы не могут годами найти человека на определённую специфику. Поэтому потерять человека потому что отдел кадров не разобрался в его ценности не допустимо (а Вы писали что несколько человек было потеряно именно так). По моему опыту, хороший спец, при постоянно открытом объявлении на серверах работы, приходит не чаще 1 раза в 2 года и не факт что он захочет остаться. Остальные или без опыта или без достаточных знаний или хотят только как фрилансеры сотрудничать (что не всегда допустимо по условиям проекта). А спецы решают все, ушел один ушел второй и фирму можно закрывать. Спецов реально мало и замену найти очень проблематично. Даже если их код хорошо документирован. Есть много школьников окончивших курсы которые напрямую начинают втыкать $_GET и $_POST в запросы, о каких то расширенных знаниях речь и не идёт с ними. Хорошо если заметишь вовремя их ошибки. А ведь можешь тупо заболеть и тогда пошло поехало. Причем это речь не о какой то экзотической специфике, а, к примеру о php+mysql. А если экзотика, типа перевод софта с VFP -> Delphi/C#/php. Когда требуется знание и опыт во всех четырёх одновременно, да плюс специфика той ткемы которую программируешь, можно не найти вообще (приходится учить самим ипт). Собеседование спеца это дело спеца, не потому что может пройти недостаточно квалифицированный, его можно отсеять в пробный период, а потому что можно упустить действительно нужного человека. А это, в современных реалиях, абсолютно недопустимо.
Опять таки — от задачи зависит.
Вот сейчас я себе начальника брал, так тут у меня тупо один кандидат был, который реально подходил под работу, и меня устраивал и т.п. Все остальные были на две головы ниже. Тут мне пофиг было на мнение ОК. Я прыгал через их голову, напрямую согласовал с юрдепартаментом какие документы можно под него заточить, что нужно притянуть за уши и т.п., шефу все правильно в уши вложил, чтобы возражения ОК звучали как мелкие формальности, а не принципиальное НЕТ, и т.п. В общем человека я протащил.
А когда у меня есть вакансия в поддержке, то тут я лучше обучу человека с нуля, если у человека мозги правильно работают, чем буду иметь проблемы с психологией.
ПЫСЫ: тут меня в топике обвинили в жестоком обращении с персоналом и всё такое. Рассказал в отделе, что мне тут на хабре сливают карму за то, что я с ними жестоко обращаюсь. До сих пор ржут. Так что спасибо за пятничное настроение :)
Вот сейчас я себе начальника брал, так тут у меня тупо один кандидат был, который реально подходил под работу, и меня устраивал и т.п. Все остальные были на две головы ниже. Тут мне пофиг было на мнение ОК. Я прыгал через их голову, напрямую согласовал с юрдепартаментом какие документы можно под него заточить, что нужно притянуть за уши и т.п., шефу все правильно в уши вложил, чтобы возражения ОК звучали как мелкие формальности, а не принципиальное НЕТ, и т.п. В общем человека я протащил.
А когда у меня есть вакансия в поддержке, то тут я лучше обучу человека с нуля, если у человека мозги правильно работают, чем буду иметь проблемы с психологией.
ПЫСЫ: тут меня в топике обвинили в жестоком обращении с персоналом и всё такое. Рассказал в отделе, что мне тут на хабре сливают карму за то, что я с ними жестоко обращаюсь. До сих пор ржут. Так что спасибо за пятничное настроение :)
Так для тех, кто остался, это не жестокое обращение, а наоборот — интересное развлечение — головоломки, нерешаемые задачи… красота! Вот им и весело :)
Когда возвращались из командировки в другой город с докладом «у меня не получилось» — весело не было.
Потом когда я через пару недель объяснял, что объект был не таким важным как я рассказывал — ворчали.
Когда через годик оказывались в сложных психологических условиях — говорили мол да, ты все правильно сделал, что у нас все такие спокойные, веселые и адекватные, иначе бы не выжили.
Потом когда я через пару недель объяснял, что объект был не таким важным как я рассказывал — ворчали.
Когда через годик оказывались в сложных психологических условиях — говорили мол да, ты все правильно сделал, что у нас все такие спокойные, веселые и адекватные, иначе бы не выжили.
Верно они смеются над тем, что здоровый мужик, который отымел не меньше сотни здоровых мужиков, полез жаловаться на хабр, что ему на хабре кто-то карму сливает.
Сергей, простите, но вы не в моем вкусе. Предпочитаю девушек.
Что касается кармы, то карма это всего-лишь циферки, и не может быть целью. Как впрочем и деньги, и многие другие малозначительные вещи. Ну слили за одно обсуждение 20 пунктов кармы. Ну и что с того?
Голосовать не смогу? Голоса на сообщениях и топиках мало что решают, а карму я и так почти не трогал.
Опубликовать что-то не смогу? Ну так дам кому-то опубликовать. Вот той девочке которая громче всех сегодня смеялась (и почему вы ее в мужика превратили? Я понимаю, что тема про Гугл, но тем не менее) инвайт и вручу… Или не вручу. Если она тут еще и писать начнет, то когда работать будет? В общем не важно. Кому-то статьи отдам если что. Мне не жалко. Да и к тому времени когда будет что-то публиковать, я уже снова буду в плюсе.
Главное помнить, что у тебя цель, а что средство.
Что касается кармы, то карма это всего-лишь циферки, и не может быть целью. Как впрочем и деньги, и многие другие малозначительные вещи. Ну слили за одно обсуждение 20 пунктов кармы. Ну и что с того?
Голосовать не смогу? Голоса на сообщениях и топиках мало что решают, а карму я и так почти не трогал.
Опубликовать что-то не смогу? Ну так дам кому-то опубликовать. Вот той девочке которая громче всех сегодня смеялась (и почему вы ее в мужика превратили? Я понимаю, что тема про Гугл, но тем не менее) инвайт и вручу… Или не вручу. Если она тут еще и писать начнет, то когда работать будет? В общем не важно. Кому-то статьи отдам если что. Мне не жалко. Да и к тому времени когда будет что-то публиковать, я уже снова буду в плюсе.
Главное помнить, что у тебя цель, а что средство.
Просто не нужно кидаться в крайности.
Если ОК тупой, и работает формально, а руководство профильного отдела не имеет веса, то конечно технарям придется выбирать из паршивенького материала… Но даже и в таком случае при желании можно добиться результата. Один раз когда ОК повысил мне _формальные_ требования к кандидатам в два раза (опыт работы и т.п.), при этом сократив зарплату в полтора раза, я таки нашел подходящих и мне и им кандидатов. И не важно сколько пиво было пролито по знакомым, и сколько анекдотов было добавлено в объявления, и как именно подгонялись факты под требования… пусть кто-то осудит меня за то, что три года назад я сказал, что «оператор ПК» можно трактовать как «опытный сисадмин». Главное что я таки пропихнул человека с нужными мне ТТХ :)
А вообще я отвлекся… Основная мысль была в том, что не стоит подменять понятия — тупой и формальный ОК говорит лишь о том, что ОК тупой и формальный, а не о том, что функции ОК должны выполнять другие подразделения. Конечно если нельзя поменять ОК, то проще отстранить их от важных решений, но… лучше пусть в ОК как и в других подразделениях работают профессионалы и выполняют свою работу.
ПЫСЫ: пару недель назад почти в шутку попал на собеседование. Шел домой, и меня случайно затянули на собеседование. Жалкое было зрелище как меня собеседовал сеньор (я бы сказал тимлид, но как руководитель парень слабоват). Мне было интересно побеседовать с ним на тему преждевременной оптимизации, о некоторых алгоритмах, о подходах к тем или иным архитектурным решениям… Было интересно побеседовать, и уверен что не только я вынес что-то полезное из этой беседы. Но вот смотреть на то как он ведет собеседование — было жалко.
Если ОК тупой, и работает формально, а руководство профильного отдела не имеет веса, то конечно технарям придется выбирать из паршивенького материала… Но даже и в таком случае при желании можно добиться результата. Один раз когда ОК повысил мне _формальные_ требования к кандидатам в два раза (опыт работы и т.п.), при этом сократив зарплату в полтора раза, я таки нашел подходящих и мне и им кандидатов. И не важно сколько пиво было пролито по знакомым, и сколько анекдотов было добавлено в объявления, и как именно подгонялись факты под требования… пусть кто-то осудит меня за то, что три года назад я сказал, что «оператор ПК» можно трактовать как «опытный сисадмин». Главное что я таки пропихнул человека с нужными мне ТТХ :)
А вообще я отвлекся… Основная мысль была в том, что не стоит подменять понятия — тупой и формальный ОК говорит лишь о том, что ОК тупой и формальный, а не о том, что функции ОК должны выполнять другие подразделения. Конечно если нельзя поменять ОК, то проще отстранить их от важных решений, но… лучше пусть в ОК как и в других подразделениях работают профессионалы и выполняют свою работу.
ПЫСЫ: пару недель назад почти в шутку попал на собеседование. Шел домой, и меня случайно затянули на собеседование. Жалкое было зрелище как меня собеседовал сеньор (я бы сказал тимлид, но как руководитель парень слабоват). Мне было интересно побеседовать с ним на тему преждевременной оптимизации, о некоторых алгоритмах, о подходах к тем или иным архитектурным решениям… Было интересно побеседовать, и уверен что не только я вынес что-то полезное из этой беседы. Но вот смотреть на то как он ведет собеседование — было жалко.
Ну наконец-то… Теперь ждем, пока тысячи HR-леммингов получат апдейт прошивки :)
Ну вот теперь к ним уже вообще легко устроиться стало. Завтра же отправляю резюме и пускай принимают меня на работу :).
[facepalm]
Это сколько же потребовалось лет, чтобы до HR дошло.
Это сколько же потребовалось лет, чтобы до HR дошло.
А представте скольео людей охренело от этого вопроса на собеседовании, и сколько людей щас думает о том что тот самый умный интервьювер просто — пи*#$с
я видел умных людей, умнее меня, которые провалили собеседования из за нервов и вот таких вопросов, которые должны были раскрыть человека а в итоге его хоронили
я видел умных людей, умнее меня, которые провалили собеседования из за нервов и вот таких вопросов, которые должны были раскрыть человека а в итоге его хоронили
провалили собеседования из за нервов и вот таких вопросов
Повторюсь.
Цель мозговзрывающих головоломок именно в том, чтобы взрывать мозг.
И еще кусочек, чтобы не было вырвано из контекста:
когда на йух посылали, то это не обязательно приводило к провалу собеседования. Все зависит от задач которые должен выполнять собеседуемый.
Рано или поздно, но человек окажется в экстремальной ситуации. Если работа связана с людьми (к примеру первая линия поддержки), то рано. Если только с техникой, и ресурсов достаточно — то поздно. Но окажется. И пусть он лучше сорвется на собеседовании, чем через несколько месяцев работы.
Я легко отпущу на пару часов раньше «старичка», и сам останусь добивать ту работу, что мог оставить ему, но новичок будет регулярно получать от меня задачи которые ему не по силам, сколько бы мне не сливали карму :)
Господа добрые, нежные и пушистые молчаливые сливатели кармы!
Искренне желаю вам бурного карьерного роста. Чтобы вы могли по несколько самых умных и талантливых сотрудников в день нанимать под свою ответственность. И точно так же искренне желаю вам, чтобы вас не уволили когда эти таланты будут в дедлайн заниматься красотой кода, а потом кричать на тупых пользователей и говорить им, что они тупые, посылать на хутор замов генерального, за то, что замы плетут интриги против вас, забывать вовремя выполнить ваши поручения и т.п.
О нет, увольнением вы не отделаетесь. Это будет слишком легко для вас! Только увольнение сотрудников, только хардкор! И не пытайтесь увиливать. Не надо. Не рассчитывайте, что для того, чтобы не увольнять вон того милого парня, для которого код это искусство, а не работа, и который пишет идеальный код — просто можно писать костыли за него, чтобы уложиться в дедлайн. Не надейтесь — у вас будет своя работа. Так что после увольнения пятерых «хороших парней», с которыми вы будете водку пить и в десна целоваться — увольнение еще пятерых мудаков, которые будут судиться, разглашать конфиденциальную информацию и портитьвоздух атмосферу в колективе — увольнение таких гениальных специалистов покажется вам раем. Как и штрафы за все те нарушения которые будут сделаны вашими сверх-умными и сверх-талантливыми подчиненными.
Удачи вам, о добрые и сердечные молчуны.
Искренне желаю вам бурного карьерного роста. Чтобы вы могли по несколько самых умных и талантливых сотрудников в день нанимать под свою ответственность. И точно так же искренне желаю вам, чтобы вас не уволили когда эти таланты будут в дедлайн заниматься красотой кода, а потом кричать на тупых пользователей и говорить им, что они тупые, посылать на хутор замов генерального, за то, что замы плетут интриги против вас, забывать вовремя выполнить ваши поручения и т.п.
О нет, увольнением вы не отделаетесь. Это будет слишком легко для вас! Только увольнение сотрудников, только хардкор! И не пытайтесь увиливать. Не надо. Не рассчитывайте, что для того, чтобы не увольнять вон того милого парня, для которого код это искусство, а не работа, и который пишет идеальный код — просто можно писать костыли за него, чтобы уложиться в дедлайн. Не надейтесь — у вас будет своя работа. Так что после увольнения пятерых «хороших парней», с которыми вы будете водку пить и в десна целоваться — увольнение еще пятерых мудаков, которые будут судиться, разглашать конфиденциальную информацию и портить
Удачи вам, о добрые и сердечные молчуны.
Вот вас все минусуют, а я соглашусь в этом именно пункте. Я ни разу не руководитель и не стремлюсь к этому, но я прекрасно помню свои впечатления от совместной работы с совершенно некомпетентным альтернативно одаренным товарищем, которого держало на работе доброе руководство, потому что «жалко увольнять, у него же ребенок маленький». Причем люли от вышестоящего руководства, полученные прямым руководством за его косяки, тоже ничему не учили.
Да ладно, пусть минусуют. Мне не жалко, а людям удовольствие.
Смущает то, что никто ничего не пишет.
Некого даже спросить — «сколько человек вам в жизни пришлось уволить?» :)
Смущает то, что никто ничего не пишет.
Некого даже спросить — «сколько человек вам в жизни пришлось уволить?» :)
Я не из сливателей кармы (у меня и прав-то нет), но похоже, что ты сам только что прошёл тест на мозговзрывательство.
Да пока не очень. Задача была в том, чтобы услышать аргументы. А пока кроме того что я грязный работорговец, и у меня каша в голове, я так и не узнал нового…
По-моему, метод взрыва мозга не объективен, т.к. он даст разные результаты по параметру стрессоустойчивости взависимости от догадок подопытного по поводу происходящего. Надо чтобы пациент верил, что начальник псих, тогда от него будет более-менее однозначная реакция, а если бедняга затаил надежду, что это его первое время так дрессируют, то он может обмануть и прикинуться хоть даже пожизненным трезвенником.
Сергей. Ну кто же его спрашивает о том, что он думает? :)
Если человек может контролировать свои эмоции, то это плюс. Если не может — это минус.
И не важно по какой причине он решил их контролировать.
Под постоянной сильной нагрузкой даже меня можно вывести.
Но вот порог срабатывания у меня высокий. Ибо у меня есть осознано выработанный и тщательно протестированный набор жизненных стратегий на этот случай.
Все просто — Вася и Петя показали почти одинаковые знания технологий.
Петя знает чуть больше, но зато Вася моложе, и сможет быстрее догнать.
Теперь их мучают ОК.
Вася увидев головоломки скривился, мол какие ламеры.
Петя увидев головоломки решил, мол «забавно, ведь была же уже статья на хабре, что головоломки отменили. А эти значит еще не вкурсе. Может у них и пхп еще 5.3, когда уже 5.5 выпустили? Надо будет учитывать в работе что ребята довольно косные… Посмотрим, что там с этими головоломками… Помню мне тут пару приколов рассказывали, может посмеемся...»
Вася не справился с первой головоломкой. Сидит злится. «Какого дьявола они мне эту чушь толкают? Сами то хоть знают?»
Петя тоже не справился. Лицо задумчивое. Сразу видно, что «Так. Задачка не решается. Надо будет получше сосредоточится на следующей.»
Вася слил вторую головоломку. Его мысли можете додумать сами.
Петя слил вторую головоломку: «Ну зато у них кофе вкусный :). Ладно, надо думать, что общего у этих головоломок? Может пошутить на тему того, что у меня были плохие учебники, и в теории игр не было универсального алгоритма решения головоломок? Нее, не оценят, это же кадровики… ладно, сосредоточимся...»
Вася решает, что «начальник дебил, пусть поиздевается, да и отстанет. Все равно никто их не решает никогда. Это так, чисто потешить самолюбие экзаменатора. И черт с ним. Третья головоломка блин!». Нет, матом посылать он конечно не будет. Но на лице у него уже всё видно.
Петя решает, что надо что-то делать, и в мягкой форме занимает позицию Насредина. В принципе он и так все остальные головоломки толкал хоть какие-то версии, но тут он решил быть особенно упертым…
…
Так прошло десять головоломок. Вася как не странно не сбежал. Правда когда после этого его попросили написать… код для чисел Фибоначи, его лицо стало красным «Блин, вчера ведь толковый дядька задавал толковые вопросы, к чему эти школьные задачи?» и как следствие сделал пару небольших ляпов в такой простой задаче.
Петя понятное дело выдал шуточку, и написал сразу два решения. Оба рабочие.
Вопрос — кого из них вы бы взяли?
Если человек может контролировать свои эмоции, то это плюс. Если не может — это минус.
И не важно по какой причине он решил их контролировать.
Под постоянной сильной нагрузкой даже меня можно вывести.
Но вот порог срабатывания у меня высокий. Ибо у меня есть осознано выработанный и тщательно протестированный набор жизненных стратегий на этот случай.
Все просто — Вася и Петя показали почти одинаковые знания технологий.
Петя знает чуть больше, но зато Вася моложе, и сможет быстрее догнать.
Теперь их мучают ОК.
Вася увидев головоломки скривился, мол какие ламеры.
Петя увидев головоломки решил, мол «забавно, ведь была же уже статья на хабре, что головоломки отменили. А эти значит еще не вкурсе. Может у них и пхп еще 5.3, когда уже 5.5 выпустили? Надо будет учитывать в работе что ребята довольно косные… Посмотрим, что там с этими головоломками… Помню мне тут пару приколов рассказывали, может посмеемся...»
Вася не справился с первой головоломкой. Сидит злится. «Какого дьявола они мне эту чушь толкают? Сами то хоть знают?»
Петя тоже не справился. Лицо задумчивое. Сразу видно, что «Так. Задачка не решается. Надо будет получше сосредоточится на следующей.»
Вася слил вторую головоломку. Его мысли можете додумать сами.
Петя слил вторую головоломку: «Ну зато у них кофе вкусный :). Ладно, надо думать, что общего у этих головоломок? Может пошутить на тему того, что у меня были плохие учебники, и в теории игр не было универсального алгоритма решения головоломок? Нее, не оценят, это же кадровики… ладно, сосредоточимся...»
Вася решает, что «начальник дебил, пусть поиздевается, да и отстанет. Все равно никто их не решает никогда. Это так, чисто потешить самолюбие экзаменатора. И черт с ним. Третья головоломка блин!». Нет, матом посылать он конечно не будет. Но на лице у него уже всё видно.
Петя решает, что надо что-то делать, и в мягкой форме занимает позицию Насредина. В принципе он и так все остальные головоломки толкал хоть какие-то версии, но тут он решил быть особенно упертым…
…
Так прошло десять головоломок. Вася как не странно не сбежал. Правда когда после этого его попросили написать… код для чисел Фибоначи, его лицо стало красным «Блин, вчера ведь толковый дядька задавал толковые вопросы, к чему эти школьные задачи?» и как следствие сделал пару небольших ляпов в такой простой задаче.
Петя понятное дело выдал шуточку, и написал сразу два решения. Оба рабочие.
Вопрос — кого из них вы бы взяли?
Я поступил так:
Я взял Васю, потому что опыта у него чуть больше, и у меня в команде было уже пять гибких и оптимистичных сотрудника. Им обязательно нужен был один зануда-пессимист, чтобы иногда спускать их с небес на землю. Пете я посоветовал обратится в другую фирму, где работал мой хороший знакомый, и позвонил знакомому. Не помню уже, взяли его тогда или нет… давно это было.
Мне рассказывали что Королев тоже держал пессимистов, чтобы они ему объясняли почему не полетит.
Если это мне вопрос, я бы ни одного не смог взять — вакансий нет и я вообще тут ничего кадрового напрямую не решаю:)
Я же говорю, что стрессоустойчивость надо проверять эталонным стрессом, а вы своим методом не можете проконтроллировать стрессоустойчивость ли это или злоумышленник уже начал хакать вас самих с этим вашим методом.
Отгадка: если ваш хороший знакомый курит туже траву, что и Петя, то его взяли.
Если это мне вопрос, я бы ни одного не смог взять — вакансий нет и я вообще тут ничего кадрового напрямую не решаю:)
Я же говорю, что стрессоустойчивость надо проверять эталонным стрессом, а вы своим методом не можете проконтроллировать стрессоустойчивость ли это или злоумышленник уже начал хакать вас самих с этим вашим методом.
Отгадка: если ваш хороший знакомый курит туже траву, что и Петя, то его взяли.
Разве такие вопросы не задавали в Microsoft еще до появления Google?
Книга Как сдвинуть гору Фудзи издана в 2004 году, там много про Microsoft и почти не упоминается Google.
Также, там дается неплохой разбор типовых задач «на сообразительность» (можно немного понять, как мыслят люди в Microsoft и почему у них получаются именно такие продукты), а также оценка применимости интервью на сообразительность.
Книга Как сдвинуть гору Фудзи издана в 2004 году, там много про Microsoft и почти не упоминается Google.
Также, там дается неплохой разбор типовых задач «на сообразительность» (можно немного понять, как мыслят люди в Microsoft и почему у них получаются именно такие продукты), а также оценка применимости интервью на сообразительность.
Сильно задолго до появления Microsoft и Google такие вопросы любил задавать Энрико Ферми. Собственно, вопрос о количестве настройщиков пианино в Чикаго — его авторства. А делал он это просто потому, что был веселым дядькой и такие вопросы казались ему остроумными. Ну а дальше культ карго и пошло-поехало.
Да кто бы сомневался.
Ух ты… вот это на рассуждение наткнулся…
Сколько всего настройщиков пианино в мире?
В 1940 х и 1950 х годах нобелевский лауреат физик Энрико Ферми любил озадачивать подобными абсурдными вопросами, предложением оценить какие то количественные параметры, не пользуясь статистическими данными, своих студентов в Чикагском университете. Хотя «вопросы Ферми» до сих пор используют некоторые преподаватели физики, они теперь гораздо больше известны как один из приемов, используемых интервьюерами при оценке кандидата на работу. Возможно, самый известный из «вопросов Ферми» (вероятно потому, что он самый глупый) — это предложение оценить количество настройщиков пианино в Чикаго.
Версия этого вопроса, используемая Microsoft, отличается от первоначальной тем, что требуется оценить количество настройщиков фортепиано во всем мире (а не только в Чикаго). Вам для этого не нужны какие либо статистические данные о настройщиках или фортепиано. Профессиональные пианисты не знают, сколько этих инструментов существует в мире. Однако вам нужно иметь представление о численности населения Соединенных Штатов и мира. Вам также разрешат округлять числа, потому что большую часть расчетов вам придется делать в уме. (Хотя есть и исключения. Бухгалтерские фирмы, банки и консалтинговые фирмы обычно разрешают вам пользоваться при расчетах карандашом и бумагой и ожидают от вас более точного ответа, чем компьютерные и интернет компании.)
Вот типичный анализ: количество настройщиков должно быть связано с тем, сколько есть для них работы. А это, в свою очередь, зависит от количества фортепиано и от того, как часто их требуется настраивать.
Сколько же в мире пианино? В Соединенных Штатах они есть в школах, филармонических обществах, церквах, барах, студиях грамзаписи, музеях и многих других местах. Тем не менее большинство этих музыкальных инструментов все же находится дома у жителей страны.
Пианино дороги и громоздки — их трудно разместить в небольших квартирах, общежитиях или передвижных домиках трейлерах. В основном пианино можно обнаружить только в домах представителей среднего и высшего класса.
Население США — это примерно 300 миллионов человек. Предположим, что типичная семья состоит из трех человек. Это значит, что в стране 100 миллионов домохозяйств. Наиболее богатая половина из них, то есть 50 миллионов семей, — целевой сегмент для продажи пианино. Конечно, не у всех из этих семей есть пианино. Доля состоятельных семей, у которых есть этот музыкальный инструмент, очевидно, менее 100 процентов и более одного процента. Предположим, что среди состоятельных семей 10 процентов имеют пианино — это означает, что в США есть пианино у 5 миллионов семей. Именно это число мы и будем использовать для нашей оценки.
Сколько настройщиков нужно, чтобы настраивать 5 миллионов пианино? Допустим, что настройщик пианино в среднем работает 40 часов в неделю (этот ведь не компьютерный бизнес!). Сколько времени нужно, чтобы настроить один инструмент? Приблизительная догадка — один час. Но клиенты не приходят со своими пианино в мастерскую, следовательно, настройщик потратит в среднем час на дорогу к клиенту. Это значит, что настройщик в среднем сможет настраивать 40/2 = 20 пианино в неделю. За год, состоящий из 50 рабочих недель, это дает приятную круглую итоговую цифру — 1000 настроенных пианино.
Как часто необходимо настраивать пианино? Этот вопрос может оказаться неразрешимым для тех, кто ничего не знает о пианино. Догадка «с потолка» (раз в год?), вероятно, достаточно близка к истине. Поиск в Интернете позволил найти рекомендацию настраивать пианино четыре раза в первый год после покупки и по крайней мере дважды в год в последующие годы. Эта рекомендация очень похожа на другие подобные (вроде пережевывать пищу двадцать шесть раз перед тем, как ее проглотить), которые никто (за исключением настройщиков пианино) не принимает всерьез. Наверняка в гостиных стоит немало пианино, которые почти никогда не используются, и их не настраивают годами.
Если нужно настраивать пианино раз в год, настройщик может настроить за год 1000 инструментов, то, вероятно, на каждую тысячу пианино придется один настройщик. Если учесть, что в Соединенных Штатах примерно 5 миллионов пианино, то настройщиков в этой стране должно быть около 5000.
Америку во многих отношениях, нельзя считать типичной страной — количество настройщиков пианино в этом плане не является исключением. Учитывая, что США — богатая страна с европейскими музыкальными традициями, можно предположить, что доля настройщиков пианино, которая приходится на США, больше, чем процент мирового населения, проживающий в этой стране. Мировое население — шесть миллиардов человек — в 20 раз больше, чем население США. Наверное, общее количество настройщиков пианино в мире в несколько раз больше, чем в США, но уж никак не в двадцать раз. Вполне реальная догадка может быть такой: в Европе может быть в два раза больше настройщиков, чем в США, а во всем остальном мире — примерно столько же, сколько в США. Это значит, что примерно каждый четвертый настройщик пианино живет в США. Оценка общего количества настройщиков пианино в мире будет такой: в четыре раза больше, чем 5000, или 20 000 настройщиков.
Именно такой ответ рассчитывают услышать интервьюеры. Насколько он точен? У мировой Гильдии настройщиков фортепиано примерно 3500 членов во всем мире. Хотя не все настройщики входят в гильдию и не все ее члены работают исключительно настройщиками. Бюро статистики занятости США сообщает, что в стране в 1998 году было примерно 13 тыс. человек, занимающихся настройкой и ремонтом музыкальных инструментов, большинство из которых работает с пианино.
Статистика продаж, которую можно найти в Интернете, показывает, что в Соединенных Штатах производится примерно 23 процента всех пианино, выпускаемых в мире, и покупается 27 процентов всех пианино, изготовленных в мире. Если предположить, что примерно 10 тыс. настройщиков пианино, проживающих в США, — это четверть от общего количества настройщиков в мире, то в мире должно быть около 40 тыс. настройщиков — в два раза больше, чем мы предположили выше (это совсем неплохой результат для ответа на вопросы Ферми). Заниженная оценка может объясняться тем, что большинство людей, которые названы в статистических данных настройщиками, на самом деле занимаются также ремонтом и реставрацией музыкальных инструментов. Это значит, что потребность в их услугах выше, чем предполагалось, а отсюда и больше «настройщиков пианино».
Версия этого вопроса, используемая Microsoft, отличается от первоначальной тем, что требуется оценить количество настройщиков фортепиано во всем мире (а не только в Чикаго). Вам для этого не нужны какие либо статистические данные о настройщиках или фортепиано. Профессиональные пианисты не знают, сколько этих инструментов существует в мире. Однако вам нужно иметь представление о численности населения Соединенных Штатов и мира. Вам также разрешат округлять числа, потому что большую часть расчетов вам придется делать в уме. (Хотя есть и исключения. Бухгалтерские фирмы, банки и консалтинговые фирмы обычно разрешают вам пользоваться при расчетах карандашом и бумагой и ожидают от вас более точного ответа, чем компьютерные и интернет компании.)
Вот типичный анализ: количество настройщиков должно быть связано с тем, сколько есть для них работы. А это, в свою очередь, зависит от количества фортепиано и от того, как часто их требуется настраивать.
Сколько же в мире пианино? В Соединенных Штатах они есть в школах, филармонических обществах, церквах, барах, студиях грамзаписи, музеях и многих других местах. Тем не менее большинство этих музыкальных инструментов все же находится дома у жителей страны.
Пианино дороги и громоздки — их трудно разместить в небольших квартирах, общежитиях или передвижных домиках трейлерах. В основном пианино можно обнаружить только в домах представителей среднего и высшего класса.
Население США — это примерно 300 миллионов человек. Предположим, что типичная семья состоит из трех человек. Это значит, что в стране 100 миллионов домохозяйств. Наиболее богатая половина из них, то есть 50 миллионов семей, — целевой сегмент для продажи пианино. Конечно, не у всех из этих семей есть пианино. Доля состоятельных семей, у которых есть этот музыкальный инструмент, очевидно, менее 100 процентов и более одного процента. Предположим, что среди состоятельных семей 10 процентов имеют пианино — это означает, что в США есть пианино у 5 миллионов семей. Именно это число мы и будем использовать для нашей оценки.
Сколько настройщиков нужно, чтобы настраивать 5 миллионов пианино? Допустим, что настройщик пианино в среднем работает 40 часов в неделю (этот ведь не компьютерный бизнес!). Сколько времени нужно, чтобы настроить один инструмент? Приблизительная догадка — один час. Но клиенты не приходят со своими пианино в мастерскую, следовательно, настройщик потратит в среднем час на дорогу к клиенту. Это значит, что настройщик в среднем сможет настраивать 40/2 = 20 пианино в неделю. За год, состоящий из 50 рабочих недель, это дает приятную круглую итоговую цифру — 1000 настроенных пианино.
Как часто необходимо настраивать пианино? Этот вопрос может оказаться неразрешимым для тех, кто ничего не знает о пианино. Догадка «с потолка» (раз в год?), вероятно, достаточно близка к истине. Поиск в Интернете позволил найти рекомендацию настраивать пианино четыре раза в первый год после покупки и по крайней мере дважды в год в последующие годы. Эта рекомендация очень похожа на другие подобные (вроде пережевывать пищу двадцать шесть раз перед тем, как ее проглотить), которые никто (за исключением настройщиков пианино) не принимает всерьез. Наверняка в гостиных стоит немало пианино, которые почти никогда не используются, и их не настраивают годами.
Если нужно настраивать пианино раз в год, настройщик может настроить за год 1000 инструментов, то, вероятно, на каждую тысячу пианино придется один настройщик. Если учесть, что в Соединенных Штатах примерно 5 миллионов пианино, то настройщиков в этой стране должно быть около 5000.
Америку во многих отношениях, нельзя считать типичной страной — количество настройщиков пианино в этом плане не является исключением. Учитывая, что США — богатая страна с европейскими музыкальными традициями, можно предположить, что доля настройщиков пианино, которая приходится на США, больше, чем процент мирового населения, проживающий в этой стране. Мировое население — шесть миллиардов человек — в 20 раз больше, чем население США. Наверное, общее количество настройщиков пианино в мире в несколько раз больше, чем в США, но уж никак не в двадцать раз. Вполне реальная догадка может быть такой: в Европе может быть в два раза больше настройщиков, чем в США, а во всем остальном мире — примерно столько же, сколько в США. Это значит, что примерно каждый четвертый настройщик пианино живет в США. Оценка общего количества настройщиков пианино в мире будет такой: в четыре раза больше, чем 5000, или 20 000 настройщиков.
Именно такой ответ рассчитывают услышать интервьюеры. Насколько он точен? У мировой Гильдии настройщиков фортепиано примерно 3500 членов во всем мире. Хотя не все настройщики входят в гильдию и не все ее члены работают исключительно настройщиками. Бюро статистики занятости США сообщает, что в стране в 1998 году было примерно 13 тыс. человек, занимающихся настройкой и ремонтом музыкальных инструментов, большинство из которых работает с пианино.
Статистика продаж, которую можно найти в Интернете, показывает, что в Соединенных Штатах производится примерно 23 процента всех пианино, выпускаемых в мире, и покупается 27 процентов всех пианино, изготовленных в мире. Если предположить, что примерно 10 тыс. настройщиков пианино, проживающих в США, — это четверть от общего количества настройщиков в мире, то в мире должно быть около 40 тыс. настройщиков — в два раза больше, чем мы предположили выше (это совсем неплохой результат для ответа на вопросы Ферми). Заниженная оценка может объясняться тем, что большинство людей, которые названы в статистических данных настройщиками, на самом деле занимаются также ремонтом и реставрацией музыкальных инструментов. Это значит, что потребность в их услугах выше, чем предполагалось, а отсюда и больше «настройщиков пианино».
Доля состоятельных семей, у которых есть этот музыкальный инструмент, очевидно, менее 100 процентов и более одного процента. Предположим, что среди состоятельных семей 10 процентов имеют пианино
Ну или 40 процентов, или 75. Ответ линейно изменяется.
а еще есть для таких целей закон Парето.
из 300 млн американцев -20%заинтересованны в исскустве,20% могут себе это позволить и только 20% из них занимаются на пианино.
итого 2,4 млн пианино. а дальше история про настройщиков.
из 300 млн американцев -20%заинтересованны в исскустве,20% могут себе это позволить и только 20% из них занимаются на пианино.
итого 2,4 млн пианино. а дальше история про настройщиков.
И еще «Что интересно, доля людей без высшего образования в Google увеличивается с течением времени. У нас есть команды, в которых до 14 процентов составляют люди, которые никогда не учился в колледже.»
Куда катится мир?
Куда катится мир?
На моей старой работе зам. ИТ директора — к слову, отличный IT-инженер и просто хороший человек — не имел высшего образования. Не вижу в этом ничего плохого.
Ну кому как. Если принять что программирование — ремесло, то допускаю разный уровень академического знания. С другой стороны — вы хотели бы чтобы вас лечил врач без высшего образования? Всякими травками, наговорами, обкуриваниями? Поэтом программер без высшего — это для меня как раз именно «знахарь» — с непонятной методологией, своей терминологией. Скорее всего и со слабой самомотивацией.
фельдшер.
Но даже не в том дело.
Так уж сложилось, что у ИТ в постсоветском пространстве плохо развита система ВУЗов, и хорошо развито самообучение в виде курсов, вебинаров да и простого чтения + личного опыта.
Но даже не в том дело.
Так уж сложилось, что у ИТ в постсоветском пространстве плохо развита система ВУЗов, и хорошо развито самообучение в виде курсов, вебинаров да и простого чтения + личного опыта.
Не фельдшер — знахарь. У нас нет «младшего профессионального» или «среднего профессионального» образования для ИТ шника.
Однако, не обиду — знаю программеров даже с докторской степенью — в обработке изображений, сигнальные процесора, машинный перевод текста и речи, СУБД и пр. И не стесняются постоянно учиться — понимая что каждые 2-3 года техническая революция обесценивает их практики
Однако, не обиду — знаю программеров даже с докторской степенью — в обработке изображений, сигнальные процесора, машинный перевод текста и речи, СУБД и пр. И не стесняются постоянно учиться — понимая что каждые 2-3 года техническая революция обесценивает их практики
Главное, чтобы не просили писать код на бумаге — это просто нереально, это как прокатиться на велосипеде с инверсным рулём (нужно практиковаться)
Мой вариант ответа такой: круглая форма позволяет сделать крышку в виде купола и равномерно распределить нагрузку. Купол является очень интересной конструкцией, которая обладает большой прочностью при очень маленьком расходе материалов. Таким образом, мы экономим материал и делаем крышку прочной.
Ну и доводы про то, что она должна не проваливать тоже очень разумные — я за.
Ну и доводы про то, что она должна не проваливать тоже очень разумные — я за.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Google признала, что головоломки на собеседованиях бесполезны