Если человек на собеседовании начинает критиковать компанию или ее специалистов и проверять, насколько технически подкован человек, проводящий собеседование, то, на мой взгляд, у этого человека есть большие проблемы с пониманием рабочих взаимоотношений и своего места в компании, и нанимать его не нужно.
Матрица компетенций — хороший совет. Действительно хороший.
Остальное… Ну, пройдем по пунктам.
2. Про объявление. Объяснение «В связи с ростом компании» вряд ли кто-нибудь примет всерьёз. Не будете же вы писать честно «В связи с повальным бегством сотрудников...»? А вот дата, до которой принимаются резюме, может, скорее, сослужить медвезью услугу. В моем опыте бывало, что первый круг поиска ничего не выдал. То есть собрали резюме, отфильтровали, провели собеседования, выбрали, сделали предложения — и все кандидаты отказались. Если бы у нас на объявлении стоял срок подачи, то мы бы начинали все заново. А так за время наших бесед с кандидатами пришли новые резюме, и мы смогли выйти на второй круг гораздо быстрее.
3. Каналы поиска. Ну, они, наверно, специфичны для конретного места и позиций, но, например, мне самые интересные предложения приходят через LinkedIn и StackOverflow. Не стоит ограничиваться сайтом вакансий — там, как раз, толкутся те, кто не знает других мест для поиска, не самая лучшая публика.
4. Групповое собеседование для меня означало бы неприемлемость данной компании. Во-первых, я не буду работать в условиях конкуренции с коллегами, это трата нервов и времени, и мне не нравится создание такой атмосферы уже на собеседовании. Во-вторых, это означает, что начальник ценит свое время больше, чем мое; это приведет к проблемам в будущем, нам не по пути.
5. Вот этот самый багаж и есть самое ценое в людях. Это возможность получить чужой опыт без наступания на грабли. Чужой устав не нужен, но опыт бесценен. Другое дело, что нужно быть осторожным, принимая людей с опытом руководства на не-руководящие позиции. Но это уже другой разговор.
6. Этот вопрос — классический. То есть да, это нужно спрашивать (хотя вероятность получения честного ответа невысока), все верно — но это, вроде, и так все знают?
7. Тоже вроде как очевидно. Дотягивали до 10 пунктов, нет?
8. Как уже было сказано, с места в карьер нормальной производительности не получить. Кроме того, я лично не пошел бы — если я уже где-то работаю, то я не буду брать такой риск, ведь если я не подойду, то я останусь вообще без работы! Ну, а если я активно ищу работу, то выпадать на три дня из поиска тоже не хочется.
9. Изначально по умолчанию не доверять людям — не самая конструктивная позиция. Вы в ответ можете рассчитывать на такое же отношение.
10. Лишние доступы вообще никому давать нельзя, даже тем, кто проработал в компании 15 лет. Подписывать нужно не только соглашение о неразглашении — но этим должны заниматься юристы.
Любую идею можно саботировать или довести до абсурда. Скрам — это не методология, а фреймворк, который нужно подстраивать под каждый конкретный случай. В основе Скрама лежит некоторое количество вполне здравых мыслей — что команда способна сама себя регулировать; что двигаться стоит небольшими шагами, чтоб суметь при надобности быстро переориентироваться; что важно добиться понимания всеми того, что делается, в каком виде проект и сколько времени он займет; что в нынешних условиях быстро сделанный минимум лучше опоздавшего на полгода максимума…
А элементы методологии нужно применять и адаптировать по назначению. Ну, например, пресловутый Stand-up. Он на самом-то деле нужен не всегда, и не обязательно каждый день. Но идея весьма проста — быстро глянуть на то, что мы, как команда делаем, и что собираемся делать дальше. Никакая полемика и никакое обсуждение проблем не допускаются, stand-up должен занимать минут 10, ну 15 от силы. В некоторых командах это не нужно, там и так все хорошо знают, что делается. А в некоторых нет хорошего контакта, и получается кто в лес, кто по дрова.
Или планирование. Оно, на самом деле очень полезно хотя бы тем, что происходит проговаривание задач, и можно добиться того, что все понимают задачу одинаково. Ну, например, если стоит задача «Сделать автоматический бэкап данных», то очень возможно, что заказчик хочет иметь возможность записать данные в отдельный файл, а программист собирается создавать сложную облачную систему. Кроме того, благодаря такому проговариванию есть шанс отловить ситуацию, когда внешне простая задача на самом деле гораздо сложнее, чем кажется. У меня бывало несколько раз, что один из членов команды оценивал задачу в гораздо больше баллов, чем остальные, и при обсуждении указывал на подводные камни, которые он знал из своего опыта. Я уж и не говорю про то, что вычисляемая в результате скорость команды замечательно помогает при разговоре с начальством.
Вам, похоже, просто не повезло, и вы не работали в месте, где такого рода методология по-настоящему успешно применяется.
Ну, а то, что в Америке распространен наем по телефону — это, извините, чушь. Первое собеседование — да. А наем без встречи в реальной жизни — очень редко. Дешевле оплатить человеку билет и гостиницу, чем потом расхлебывать.
Это довольно сложный процесс, который может происходить по-разному, в зависимости от типа площадки. В общем ситуация примерно такая: часть баннеров, действительно, как вы и сказали, размещается через прямой договор. И да, это может происходить и в виде присылания баннера, как вы описали. Но такие договоры, во-первых, работают далеко не везде; так могут заполняться очень дорогие площадки (ну, типа баннера на первой странице крупного новостного портала типа CNN) или очень нишевые. Во-вторых, даже в этих местах такие прямые размещения постепенно уходят в прошлое, поскольку они трудны и для рекламодателя, и для владельца площадки. Ну, например, рекламодатель может иметь определенный выделенный бюджет, и не желать показывать больше чем, скажем, 50000 баннеров в день. В такой ситуации или будет простаивать очень дорогая площадка, или ее владельцу придется изобретать какие-то хитрости, а это не его дело. Поэтому все большее количество рекламы идет через специальные системы. В настоящий момент такие системы проводят аукцион в реальном времени, и меньше чем за секунду подбирают баннер, который будет наиболее выгодным на этом месте. Они умеют учитывать и прямые сделки — например, если еще есть бюджет, то будет показан баннер из договора, а если уже нет, то будет показано что-то еще.
Крупные компании, которые занимаются такими технологиями, очень следят за тем, чтобы баннеры вели себя прилично, не свинячили, показывали именно то, что заявлено, и по минимуму раздражали пользователей. К сожалению, рынок пока очень-очень мутный; огромное количество недобросовестных игроков, жуликов, которые пропихивают черт знает что, стараясь заработать любыми способами. К примеру, компания, в которой я работаю (я не могу назвать, извините) очень следит за тем, чтобы баннеры не звучали неожиданно для пользователя — но, к сожалению, иногда проскальзывает и такая гадость.
Вообще-то современная реклама работает совсем не так. И да, я рекламщик, то есть занимаюсь рекламными технологиями. Конкретно — технологией видео-рекламы, именно VPAID и VAST. Так что, если интересно, что там и как на самом деле, то спрашивайте :)
VPAID — это не обязательно видео-реклама; видео-реклама — это не обязательно VPAID, есть и другие стандарты — VAST, например. VPAID позволяет использовать в баннерах не видеофайл, а некий исполняемый модуль, на Flash или на JavaScript. То есть, например, это может быть опрос, или игрушка, или какая-нибудь еще интерактивная штука. VPAID просто определяет интерфейс для такого модуля.
Главной задачей по составлению оффера — показать пробелы в знаниях сотрудника и вектор развития.
А на мой взгляд, главная задача при составлении оффера — четко проговорить все ключевые моменты и дать кандидату понять, что он нравится, и что компания хотела бы, чтобы он стал частью команды.
Меня совершенно поразила идея указывать в оффере пробелы в знаниях. У меня такое предложение вызвало бы негативную реакцию, и я, скорее всего, не принял бы его. Полное ощущение, что компания специально пытается «опустить» меня, вероятно, чтобы платить поменьше.
https://medium.com/@mproberts/a-discussion-about-the-breaking-of-the-internet-3d4d2a83aa4d#.edmjtps48
Kik опубликовал куски из переписки их сотрудника с Азером. Надо сказать, что — если верить этой переписке, конечно — сотрудник, в общем, вполне корректно обратился к Азеру с просьбой отдать имя, использующее запатентованное название их компании. Компания Kik была зарегистрирована в 2009 году, то есть имя было занято довольно давно. Более того, сотрудник (Боб) несколько раз спрашивал, что и как Kik может сделать, чтобы облегчить процесс смены имени у проекта. Азер же — опять-таки, судя по опубликованному — повел себя совершенно по-детски.
В общем, все в этой истории выглядят не очень красиво — но, надо сказать, что, как мне кажется, Kik все же действовал довольно корректно. И, конечно, весьма любопытен тот факт, что одна раскапризничившаяся примадонна способна встряхнуть такое количество серьезных проектов.
Есть разница между алгоритмами и библиотеками, их реализующими. Одно дело — взять существующий алгоритм и самому реализовать его; другое дело — самому написать алгоритм. Первое — вполне понятно, и зачастую оправданно. Второе — нетривиально, и, скорее всего, не нужно (если хороший алгоритм уже есть, конечно).
Двадцать лет назад меня в институте учили именно так подходить к проектированию программного обеспечения. Однако времена изменились, «водопад» в большинстве случаев не подходит для современных условий. Пора обновить методику, пора…
Во втором тесте, мне кажется, не нужно делать проверку на наличие элемента в сете. В этом и сила структуры Set, что она сама проигнорирует попытку вставить дублирующийся элемент.
Я бы только добавил: выигрывают только и исключительно компании, обладающие самым плохим из приемлемого для данной ситуации кода. Потому что требования к этому самому минимальному качеству кода у, скажем, производителя программного обеспечения для самолётов и разработчика онлайн-игрушек будут принципиально разные.
Ну, окончания у этой истории пока нет, так что посмотрим. Для компании Б она может кончиться по-разному. Вполне возможно, что так, как вы описываете. А может, и по другому…
На самом деле есть довольно просто формулируемое правило: качество кода должно быть коммерчески оправдано. Эта самая коммерческая оправданность очень, очень зависит от конкретного проекта.
Вот пример, можно сказать, из личного опыта. Было две компании, А и Б. Занимались примерно одним и тем же. Компания А была сильна технологически. У нее был вычищен код, были все элементы грамотно организованного технологического процесса. В компании Б было в два раза меньше программистов, и очень многие вещи делались, что называется, на коленке, на скорую ручку, побыстрее. При этом компания А при ближайшем рассмотрении оказалась убыточна, а компания Б — прибыльна. И, как выяснилось, убыточность во многом происходила из-за непомерных затрат на технологию. При этом там не было особо ненужных трат; просто поддержание такого уровня качества кода и процесса оказалось делом более дорогостоящим, чем компания могла себе позволить.
При этом я не могу сказать, что в компании Б царил сплошной говнокод. Младшие разработчики периодически получали, фигурально говоря, по шее от старших товарищей за особо впечатляющие художества, код периодически просматривался и рефакторился… Просто это не было на столь высоком уровне, не отнимало столько ресурсов.
Так вот, в данной ситуации в компании Б трезвее оценили то, какой уровень качества им нужен и доступен. Да, низкое качество кода впоследствии икнулось и не раз: из-за нестабильности продукта компания потеряла несколько клиентов; пришлось выделять отдельное время на залатывание самых вопиющих дырок; в какой-то момент в компании Б пришлось просто остановить новые разработки и ьросить все силы на восстановление управляемости и стабильности проекта. Конечно, ничего бы этого не случилось, будь качество кода в компании Б на том уровне, на каком оно было в компании А…
Это очень и очень зависит от обстоятельств. Команда, в которой я тогда работал, занималась построением виртуальных миров. Заказы большие, но их очень немного, и пропуск заказа мог бы обернуться потерей команды.
Остальное… Ну, пройдем по пунктам.
2. Про объявление. Объяснение «В связи с ростом компании» вряд ли кто-нибудь примет всерьёз. Не будете же вы писать честно «В связи с повальным бегством сотрудников...»? А вот дата, до которой принимаются резюме, может, скорее, сослужить медвезью услугу. В моем опыте бывало, что первый круг поиска ничего не выдал. То есть собрали резюме, отфильтровали, провели собеседования, выбрали, сделали предложения — и все кандидаты отказались. Если бы у нас на объявлении стоял срок подачи, то мы бы начинали все заново. А так за время наших бесед с кандидатами пришли новые резюме, и мы смогли выйти на второй круг гораздо быстрее.
3. Каналы поиска. Ну, они, наверно, специфичны для конретного места и позиций, но, например, мне самые интересные предложения приходят через LinkedIn и StackOverflow. Не стоит ограничиваться сайтом вакансий — там, как раз, толкутся те, кто не знает других мест для поиска, не самая лучшая публика.
4. Групповое собеседование для меня означало бы неприемлемость данной компании. Во-первых, я не буду работать в условиях конкуренции с коллегами, это трата нервов и времени, и мне не нравится создание такой атмосферы уже на собеседовании. Во-вторых, это означает, что начальник ценит свое время больше, чем мое; это приведет к проблемам в будущем, нам не по пути.
5. Вот этот самый багаж и есть самое ценое в людях. Это возможность получить чужой опыт без наступания на грабли. Чужой устав не нужен, но опыт бесценен. Другое дело, что нужно быть осторожным, принимая людей с опытом руководства на не-руководящие позиции. Но это уже другой разговор.
6. Этот вопрос — классический. То есть да, это нужно спрашивать (хотя вероятность получения честного ответа невысока), все верно — но это, вроде, и так все знают?
7. Тоже вроде как очевидно. Дотягивали до 10 пунктов, нет?
8. Как уже было сказано, с места в карьер нормальной производительности не получить. Кроме того, я лично не пошел бы — если я уже где-то работаю, то я не буду брать такой риск, ведь если я не подойду, то я останусь вообще без работы! Ну, а если я активно ищу работу, то выпадать на три дня из поиска тоже не хочется.
9. Изначально по умолчанию не доверять людям — не самая конструктивная позиция. Вы в ответ можете рассчитывать на такое же отношение.
10. Лишние доступы вообще никому давать нельзя, даже тем, кто проработал в компании 15 лет. Подписывать нужно не только соглашение о неразглашении — но этим должны заниматься юристы.
А элементы методологии нужно применять и адаптировать по назначению. Ну, например, пресловутый Stand-up. Он на самом-то деле нужен не всегда, и не обязательно каждый день. Но идея весьма проста — быстро глянуть на то, что мы, как команда делаем, и что собираемся делать дальше. Никакая полемика и никакое обсуждение проблем не допускаются, stand-up должен занимать минут 10, ну 15 от силы. В некоторых командах это не нужно, там и так все хорошо знают, что делается. А в некоторых нет хорошего контакта, и получается кто в лес, кто по дрова.
Или планирование. Оно, на самом деле очень полезно хотя бы тем, что происходит проговаривание задач, и можно добиться того, что все понимают задачу одинаково. Ну, например, если стоит задача «Сделать автоматический бэкап данных», то очень возможно, что заказчик хочет иметь возможность записать данные в отдельный файл, а программист собирается создавать сложную облачную систему. Кроме того, благодаря такому проговариванию есть шанс отловить ситуацию, когда внешне простая задача на самом деле гораздо сложнее, чем кажется. У меня бывало несколько раз, что один из членов команды оценивал задачу в гораздо больше баллов, чем остальные, и при обсуждении указывал на подводные камни, которые он знал из своего опыта. Я уж и не говорю про то, что вычисляемая в результате скорость команды замечательно помогает при разговоре с начальством.
Вам, похоже, просто не повезло, и вы не работали в месте, где такого рода методология по-настоящему успешно применяется.
Ну, а то, что в Америке распространен наем по телефону — это, извините, чушь. Первое собеседование — да. А наем без встречи в реальной жизни — очень редко. Дешевле оплатить человеку билет и гостиницу, чем потом расхлебывать.
Крупные компании, которые занимаются такими технологиями, очень следят за тем, чтобы баннеры вели себя прилично, не свинячили, показывали именно то, что заявлено, и по минимуму раздражали пользователей. К сожалению, рынок пока очень-очень мутный; огромное количество недобросовестных игроков, жуликов, которые пропихивают черт знает что, стараясь заработать любыми способами. К примеру, компания, в которой я работаю (я не могу назвать, извините) очень следит за тем, чтобы баннеры не звучали неожиданно для пользователя — но, к сожалению, иногда проскальзывает и такая гадость.
А на мой взгляд, главная задача при составлении оффера — четко проговорить все ключевые моменты и дать кандидату понять, что он нравится, и что компания хотела бы, чтобы он стал частью команды.
А хамить-то зачем?
Kik опубликовал куски из переписки их сотрудника с Азером. Надо сказать, что — если верить этой переписке, конечно — сотрудник, в общем, вполне корректно обратился к Азеру с просьбой отдать имя, использующее запатентованное название их компании. Компания Kik была зарегистрирована в 2009 году, то есть имя было занято довольно давно. Более того, сотрудник (Боб) несколько раз спрашивал, что и как Kik может сделать, чтобы облегчить процесс смены имени у проекта. Азер же — опять-таки, судя по опубликованному — повел себя совершенно по-детски.
В общем, все в этой истории выглядят не очень красиво — но, надо сказать, что, как мне кажется, Kik все же действовал довольно корректно. И, конечно, весьма любопытен тот факт, что одна раскапризничившаяся примадонна способна встряхнуть такое количество серьезных проектов.
Я бы только добавил: выигрывают только и исключительно компании, обладающие самым плохим из приемлемого для данной ситуации кода. Потому что требования к этому самому минимальному качеству кода у, скажем, производителя программного обеспечения для самолётов и разработчика онлайн-игрушек будут принципиально разные.
А вот для компании А она УЖЕ ЗАКОНЧИЛАСЬ.
Вот пример, можно сказать, из личного опыта. Было две компании, А и Б. Занимались примерно одним и тем же. Компания А была сильна технологически. У нее был вычищен код, были все элементы грамотно организованного технологического процесса. В компании Б было в два раза меньше программистов, и очень многие вещи делались, что называется, на коленке, на скорую ручку, побыстрее. При этом компания А при ближайшем рассмотрении оказалась убыточна, а компания Б — прибыльна. И, как выяснилось, убыточность во многом происходила из-за непомерных затрат на технологию. При этом там не было особо ненужных трат; просто поддержание такого уровня качества кода и процесса оказалось делом более дорогостоящим, чем компания могла себе позволить.
При этом я не могу сказать, что в компании Б царил сплошной говнокод. Младшие разработчики периодически получали, фигурально говоря, по шее от старших товарищей за особо впечатляющие художества, код периодически просматривался и рефакторился… Просто это не было на столь высоком уровне, не отнимало столько ресурсов.
Так вот, в данной ситуации в компании Б трезвее оценили то, какой уровень качества им нужен и доступен. Да, низкое качество кода впоследствии икнулось и не раз: из-за нестабильности продукта компания потеряла несколько клиентов; пришлось выделять отдельное время на залатывание самых вопиющих дырок; в какой-то момент в компании Б пришлось просто остановить новые разработки и ьросить все силы на восстановление управляемости и стабильности проекта. Конечно, ничего бы этого не случилось, будь качество кода в компании Б на том уровне, на каком оно было в компании А…
… которая до этого момента просто не дожила.