Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 213
У нас точно не практикуется выдача доступа к исходникам для канидатов ;)
Впрочем, про наш процесс и так все всё знают.
Впрочем, про наш процесс и так все всё знают.
если у вас проект только php+mysql то все оке, но если у вас пару демонов, и еще чтонить рядышком mongo, sphinx или какие то патчи на php то вся эта схема не будут работать. а так отличное решение спасибо за статью
У нас не PHP, а Ruby, postgres, memcache, mongodb, демоны: delayed_job, loop_dance, sphinx. И такая схема работает, ограничений пока не видно.
На счет патчей к php — почему бы не выложить патченный код в одном место?
На счет патчей к php — почему бы не выложить патченный код в одном место?
т.е новый человек еще пару дней себе на локальную машинку половину вашего проекта доставляет. Можен быть проще образ сделать со всем установленным софтом и его отдавать что бы не издеваться над человеком.
…
php или Ruby или Python особого значения не имеет. я исключительно про простоту установки всего этого дела.
…
php или Ruby или Python особого значения не имеет. я исключительно про простоту установки всего этого дела.
Да, спасибо, проект должен устанавливаться просто, образом там или инструкция не суть важно.
У нас есть INSTALL.txt который периодически дописывают ребята, столкнувшиеся с неожиданными трудностями.
В Ruby кстати с этим проще, там практически все устанавливается сразу парой стандартных команд.
У нас есть INSTALL.txt который периодически дописывают ребята, столкнувшиеся с неожиданными трудностями.
В Ruby кстати с этим проще, там практически все устанавливается сразу парой стандартных команд.
У меня проект на Python. Django, PostgreSQL, memcached, redis, sphinx. Изначально не было четкой схемы установки и многие кандидаты отсеивались еще на этапе установки — не могли справиться. Затем я чуть больше чем за неделю реорганизовал проект, перевел под buildout, теперь достаточно склонировать исходники из репозитория mercurial и запустить buildout.
В общем-то, это правильный метод. Над скриптами для deployment'а надо работать. Это скучно и на первый взгяд не очень полезно, но экономит массу времени и нервов не только новым разработчикам.
В общем-то, это правильный метод. Над скриптами для deployment'а надо работать. Это скучно и на первый взгяд не очень полезно, но экономит массу времени и нервов не только новым разработчикам.
Идея хороша, но по моему опыту работы в различных проектах такое просто не возможно по ряду причин:
1. Новобранец имеет право работать с кодом только после подписания договора и NDA.
2. Зачастую сборка и запуск проекта — ооочень небанальная задача. Но это скорее наши проблемы, нежели ограничения. Но тем не менее это присутствует.
3. Вникание в структуру проекта и суть задачи — тоже не минутная и часто не банальная задача. На практике встречаются перегибы в разные стороны:
— UI & tech documentation крайне подробные, но объемом 150+ страниц.
— Документации нет, а задачи поставлены в пару строчек.
Я вижу, что такое работать может, но редко в каких случаях/компаниях.
1. Новобранец имеет право работать с кодом только после подписания договора и NDA.
2. Зачастую сборка и запуск проекта — ооочень небанальная задача. Но это скорее наши проблемы, нежели ограничения. Но тем не менее это присутствует.
3. Вникание в структуру проекта и суть задачи — тоже не минутная и часто не банальная задача. На практике встречаются перегибы в разные стороны:
— UI & tech documentation крайне подробные, но объемом 150+ страниц.
— Документации нет, а задачи поставлены в пару строчек.
Я вижу, что такое работать может, но редко в каких случаях/компаниях.
1. Ну согласен, конечно, бывают и хорошие патентованные алгоритмы и т.д.
2. Про сборку и запуск проекта — лично у меня это принципиальная позиция, проект должен собираться и запускаться легко, это как тест. Если это не так, значит нужно потратить время и сделать чтобы это было так, иначе проект представляет из себя очень хрупкую субстанцию.
3. Тут тоже понимаю что такое может быть, а часто так и бывает. Но, это ужасно не эффективно. Менеджеру такого проекта 2 в дневник и идти обратно переучиваться. Одна из типовых рекомендация в таком случае — рефакторить. разбивать на модули, документацию переписывать/писать в тестируемые spec-и.
То есть о чем я хочу сказать, понятно что это может работать не во всех случах, но также понятно что в тех случаях, зачастую низкий уровень организованности проекта.
2. Про сборку и запуск проекта — лично у меня это принципиальная позиция, проект должен собираться и запускаться легко, это как тест. Если это не так, значит нужно потратить время и сделать чтобы это было так, иначе проект представляет из себя очень хрупкую субстанцию.
3. Тут тоже понимаю что такое может быть, а часто так и бывает. Но, это ужасно не эффективно. Менеджеру такого проекта 2 в дневник и идти обратно переучиваться. Одна из типовых рекомендация в таком случае — рефакторить. разбивать на модули, документацию переписывать/писать в тестируемые spec-и.
То есть о чем я хочу сказать, понятно что это может работать не во всех случах, но также понятно что в тех случаях, зачастую низкий уровень организованности проекта.
1. У нас разве можно запатентовать алгоритм?
Да вообще желательно всегда делать что-то типа install.sh/js/rb/py/bat который автоматически развернет все что надо на целевой системе.
Так можно вообще никого не нанимать, кандидаты потихоньку всю работу сделают. Шутка.
Лично я бы сразу послал такого работодателя нафиг. Мое время оплачиваемо, хотите посмотреть мои навыки — денежки вперед. Халявки захотелось? Не ко мне.
Тем более тестирование боевыми действиями не показывает реальных знаний или умений, а показывает уровень совпадения потенциального кандидата с бизнес-процессами компании. Это хорошо для компании, но это не очень хорошо для соискателя. Поясню почему. Если компания ищет способ развивать продукты, то она ищет людей, которые будут как минимум нестандартно мыслить. Только в постоянном креативе рождаются новые методики разработки, новый подход к генерации кода, новые реализации. В противном случае набираются роботы-реализаторы, которые будут как шахтеры, не подымаясь на поверхность, колбасить денно и нощно уголек в забое. И чем больше твои руки заточены под определенную марку отбойного молотка, тем лучше.
Тем более тестирование боевыми действиями не показывает реальных знаний или умений, а показывает уровень совпадения потенциального кандидата с бизнес-процессами компании. Это хорошо для компании, но это не очень хорошо для соискателя. Поясню почему. Если компания ищет способ развивать продукты, то она ищет людей, которые будут как минимум нестандартно мыслить. Только в постоянном креативе рождаются новые методики разработки, новый подход к генерации кода, новые реализации. В противном случае набираются роботы-реализаторы, которые будут как шахтеры, не подымаясь на поверхность, колбасить денно и нощно уголек в забое. И чем больше твои руки заточены под определенную марку отбойного молотка, тем лучше.
Не соглашусь. Если компания ищет человека для работы над проектом, то ей надо, чтоб человек мог работать над проектом.
А не пришел со словами «а давайте ка мы все это полностью перепишем»
А не пришел со словами «а давайте ка мы все это полностью перепишем»
А если у них действительно все плохо, и переписать все не мешало бы?
Всегда есть борьба между «консерваторами» и «революционерами». Менеджмент должен понимать все плюсы и минусы обоих подходов к разработке.
Например, новый модуль потребовал серьезной переработки подхода в построении интерфейса, и, соответственно, это потянуло за собой увеличение энтропии кода. Но, в процессе «размывания» основы было обнаружено, что есть более удачное решение не только текущей проблемы, но и трех предыдущих, которые решались в «лоб», только бы не увеличивать энтропию. Вопрос, что делать? Консерваторы говорят, что нужно забыть про модуль-отщепенца, далее использовать старые методы. Революционеры говорят, что нужно везде провести рефакторинг. Первые правы с точки зрения общей стабильности и скорости работы команды, а вторые правы, потому что рефакторинг сегодня может серьезно увеличить скорость разработки завтра.
Так что мысля «а давайте ка мы все это полностью перепишем» не явняется негативом. Все зависит от точки зрения управленцев на процесс разработки.
Всегда есть борьба между «консерваторами» и «революционерами». Менеджмент должен понимать все плюсы и минусы обоих подходов к разработке.
Например, новый модуль потребовал серьезной переработки подхода в построении интерфейса, и, соответственно, это потянуло за собой увеличение энтропии кода. Но, в процессе «размывания» основы было обнаружено, что есть более удачное решение не только текущей проблемы, но и трех предыдущих, которые решались в «лоб», только бы не увеличивать энтропию. Вопрос, что делать? Консерваторы говорят, что нужно забыть про модуль-отщепенца, далее использовать старые методы. Революционеры говорят, что нужно везде провести рефакторинг. Первые правы с точки зрения общей стабильности и скорости работы команды, а вторые правы, потому что рефакторинг сегодня может серьезно увеличить скорость разработки завтра.
Так что мысля «а давайте ка мы все это полностью перепишем» не явняется негативом. Все зависит от точки зрения управленцев на процесс разработки.
Конечно бывает и такое. Но опять же решение о рефакторинге должно приниматься внутри команды. И если это решение принято, то уже тогда искать человека, который этим займется (внутри или снаружи).
Но в Вашем варианте скорее будет так, что приходит человек, незнакомый с технологиями, использоваными в проекте. Но знакомый с чем-то иным. И захочет переделать под то, что знает.
Вовсе не факт, что это принесет пользу проекту.
Но в Вашем варианте скорее будет так, что приходит человек, незнакомый с технологиями, использоваными в проекте. Но знакомый с чем-то иным. И захочет переделать под то, что знает.
Вовсе не факт, что это принесет пользу проекту.
Очень тяжело найти человека, который на 100% знает всю кухню вашей разработки. Новички будут знать в лучшем случае только часть, и их первым делом нужно обучать.
Если у новичка возникает желание внедрить что-то новое, то я посадил бы его за кусочек кода, написал бы список проблем, которые ему нужно будет решить, и пусть он докажет эффективность его реализации. Справится, будем пытаться внедрять новые решения, не справится, значит будет хороший повод более тщательно изучить текущие реализации. :)
Если у новичка возникает желание внедрить что-то новое, то я посадил бы его за кусочек кода, написал бы список проблем, которые ему нужно будет решить, и пусть он докажет эффективность его реализации. Справится, будем пытаться внедрять новые решения, не справится, значит будет хороший повод более тщательно изучить текущие реализации. :)
Естественно.
Но хочется, чтоб часть, которую они знают была побольше. Или же новичек должен показать хороший уровень обучаемости.
Если мы ищем человека на проект, то скорее всего это связано с тем, что текущая скорость разработки нас не устраивает. И нужно ее повысить. И чем скорее человек разберется во всем и начнет работать — тем лучше.
Либо возможен вариант, что решили перейти на новую технологию — тогда будем искать человека, знакомого именно с этой технологией.
Разные причины поиска — разных людей будем искать.
Но хочется, чтоб часть, которую они знают была побольше. Или же новичек должен показать хороший уровень обучаемости.
Если мы ищем человека на проект, то скорее всего это связано с тем, что текущая скорость разработки нас не устраивает. И нужно ее повысить. И чем скорее человек разберется во всем и начнет работать — тем лучше.
Либо возможен вариант, что решили перейти на новую технологию — тогда будем искать человека, знакомого именно с этой технологией.
Разные причины поиска — разных людей будем искать.
Не факт еще, что увеличив количество работников, вы получите прирост в скорости разработки. Вообще разговор на тему достижения эффективности разработки — отдельная тема, очень долгая, и очень флеймообразующая.
Но все же есть и объективные показатели.
Например есть какие-то давно висящие задачи, на которые постоянно не хватает времени.
Например есть какие-то давно висящие задачи, на которые постоянно не хватает времени.
Экономическая эффективность решения этих задач слишком низкая, раз они давно висят… Если на что-то нет времени, то скорее всего это что-то не сильно то и нужно потребителям. Добавив мелочи, некоторые пользователи конечно скажут спасибо. Но добавив новый модуль, который делает их жизнь проще, они дружно скажут не просто спасибо, а еще и денег дадут.
К счастью нам не нужны «показатели реальных знаний и умений», нам от веб-разработчика требуется на самом деле не многое — эффектинове выполнение задач из списка, который уже составили взрослые дяди.
Понимаю что не многим это нравится, поэтому сразу и сообщаю.
Если разработчик чувствует себя взрослым дядей достойным раздавать задачи и заниматься проектированием это уже другой вопрос, другая должность и иная методика отбора.
Понимаю что не многим это нравится, поэтому сразу и сообщаю.
Если разработчик чувствует себя взрослым дядей достойным раздавать задачи и заниматься проектированием это уже другой вопрос, другая должность и иная методика отбора.
Метод управления компании основывается на выкачивании интеллектуальных ресурсов из сотрудников с последующей их утилизацией после полного истощения. Метод имеет место быть, но лично я его не приветствую.
Вы явно переоцениваете интеллектуальные ресурсы большинства современных разработчиков )
ну, а если разработчик этими ресурсами обладает, то ему их хватат чтобы не обламываться и начать общаться с руководителем помимо/параллельно выполнению задания.
ну, а если разработчик этими ресурсами обладает, то ему их хватат чтобы не обламываться и начать общаться с руководителем помимо/параллельно выполнению задания.
Вы сразу настроены на негатив. Я встречал подобные ситуации, не персонально, но по отзывам коллег. Потенциальный работодатель оговаривает стоимость предложенной задачи и оплачивает ее в случае удачного выполнения в независимости от того, будет ли предложена в итоге позиция кандидату или нет. Эдакий пробный фриланс с возможностью дальнейшего трудоустройства.
Собеседования и испытательный срок тоже больших денег стоит. Не нужно это забывать. В большинстве небольших компаний даже так называемая «стажировка» не оплачивается, или оплачивается исходя из минималки.
Это не желание халявки, эта халявка обычно в кошмарах снится.
Это не желание халявки, эта халявка обычно в кошмарах снится.
В большинстве??? Я, видимо, живу в другом мире. Не, на предложение в качестве теста закрыть тикет в неизвестной мне реальной системе, да ещё с контролем результатов на следующий день, я бы сильно почесал репу. Но бесплатно «стажироваться» — это уже что-то совсем из ряда вон. Весьма дурно пахнет даже несколько сниженная (10%) на «испытательный» первый месяц зарплата, а уж такое, да ещё и в большинстве… Ужос-ужос какой-то!
Ну, снижение стоимости весьма оправдано. Ведь ваша эффективность в это время далеко не 100%. Компания за свой счет обучает вас, и не факт, что вы подойдете компании.
Так и бесплатная «стажировка» оправдана! Даже более чем оправдана (особенно, если она ещё и бессрочная) :). Для компании. Но у каждой медали ведь две стороны. Такая ситуация не оправдана для меня — мне семью кормить. Ко всему прочему, это вообще напрямую запрещено трудовым законодательством (понятно, что есть 100500 способов относительно законного отъёма де… как это обойти, но тем не менее). Поэтому, при прочих равных, компания с такими заявками скорее не будет выбрана претендентом.
Трудоустройство на работу всегда напоминают торги. Выставляете на продажу свой товар и пробуете сторговаться.
Если вам предложат ЗП на 30% выше рыночной, но после 2х месяцев работы за 70%, вы откажетесь?
Если вам предложат ЗП на 30% выше рыночной, но после 2х месяцев работы за 70%, вы откажетесь?
Если сработает правило «при прочих равных», то откажусь :)
Но вы описали случай нетипичный, когда даже «испытательная»! зарплата неплохо выше рыночной. В таком виде это предложение хорошее, разумеется. Я и не говорил, что обязательно откажусь. Плохо пахнет — да. А с другой стороны, выбор моей текущей работы чем-то напоминал ваш вариант — «стартовая» сразу выше средней и «срок» её всего месяц. Хотя привлекло не это, но это тоже сильно не отвратило. Но вот то, что большинство компаний якобы предлагает вообще бесплатно работать — я такое впервые услышал.
Но вы описали случай нетипичный, когда даже «испытательная»! зарплата неплохо выше рыночной. В таком виде это предложение хорошее, разумеется. Я и не говорил, что обязательно откажусь. Плохо пахнет — да. А с другой стороны, выбор моей текущей работы чем-то напоминал ваш вариант — «стартовая» сразу выше средней и «срок» её всего месяц. Хотя привлекло не это, но это тоже сильно не отвратило. Но вот то, что большинство компаний якобы предлагает вообще бесплатно работать — я такое впервые услышал.
Поздравляю! вы изобрели open-source :)
Таким образом можно вообще всех на удаленку отправить, и вообще упразнить HR отдел.
Если б я был программистом, который получил вместо собеседования задание поправить что-то в рабочем проекте, то даже не дёрнулся бы, скорее всего. По следующим причинам:
1. Им вообще насрать кто я и что я. Нужен только код.
1. Им вообще насрать кто я и что я. Нужен только код.
Это точно. Только маме на нас не наплевать )
упс. нечаянно Ctrl+Enter.
2. Украдут мой код, сделанный в качестве тестового и не заплатят.
3. Что-то скрывают, не хотят показываться сами, себя показать.
2. Украдут мой код, сделанный в качестве тестового и не заплатят.
3. Что-то скрывают, не хотят показываться сами, себя показать.
Согласен, почему то многие работодатели с упорством считают, что выбирают новых сотрудников из кучи кандидатов, и никак не могут понять, что кандидаты могут выбирать работу из кучи вакансий…
Интересная тема, а что разработику нужно? И что мешает ему получить то что нужно в используемой мной схеме?
Как минимум разговор с руководителем проекта, и оговорить условия на которых будет проводится работа, и тестирование в том числе..., если работа удаленная, то в принципе все это можно сделать удаленно, но тема ввида:
-Здрасте, я к вам по работе…
-Здрасте, вот вам тиккет…
Не совсем прокатывает…
-Здрасте, я к вам по работе…
-Здрасте, вот вам тиккет…
Не совсем прокатывает…
А что мешает поговорить? Мне не очень интересно резюме разработчика, я его и не спрашиваю, общих вопросов достаточно, а ему, возможно, мое резюме интересно — так никто не запрещает его у меня спросить.
Тем более если он мне написал, то наверное уже что-то знает обо мне и хочет тут работать.
Тем более если он мне написал, то наверное уже что-то знает обо мне и хочет тут работать.
>Тем более если он мне написал, то наверное уже что-то знает обо мне и хочет тут работать.
Совершенно не факт. Резюме можно разослать в 5-10 контор за раз и потом ходить, разговаривать, выбирать.
Совершенно не факт. Резюме можно разослать в 5-10 контор за раз и потом ходить, разговаривать, выбирать.
Можно сделать гибридную схему —
собеседовать (ну по легкому, чтобы отсеять совсем неадекватов), а после давать работу по вышеописанной схеме, НО оплачиваемую по сдельному принципу. Эдакий внештатный сотрудник на первое время. И если он справится с заданием — получает оплату за работу и вливается в коллектив (штат).
собеседовать (ну по легкому, чтобы отсеять совсем неадекватов), а после давать работу по вышеописанной схеме, НО оплачиваемую по сдельному принципу. Эдакий внештатный сотрудник на первое время. И если он справится с заданием — получает оплату за работу и вливается в коллектив (штат).
Есть люди кому важна атмосфера в коллективе, возможность развиваться в компании, учиться у кого-то и т.д. А вы подходите к человеку как к машине по генерации кода.
а когда ты приходишь на собеседование, что тебя там спрашивают. Бердовые вопросы про приоритеты, что важнее деньги или сколько вы будете ездить на работу или коллектив. Должно быть все в совокупности.
Думаю собеседование должен производить главный в том или ином отделе. Например манагеров, главный манагер. Программеров- прогер. и т.д.
Думаю собеседование должен производить главный в том или ином отделе. Например манагеров, главный манагер. Программеров- прогер. и т.д.
2. Украдут? Все 5 строчек? ) Предоставив при этом код 2-х летнего проекта?
3. Вот тут можно по-подробнее, в чем вы узрели закрытие?
Я на самом деле не скарказничаю, очень важна точка зрения со стороны, тем более разработчика.
То есть вот я ничего не скрываю, даже наоборот — отдаю ему код (что многие вообще боятся делать), а у него складывается ощущения что я что-то скрываю?
3. Вот тут можно по-подробнее, в чем вы узрели закрытие?
Я на самом деле не скарказничаю, очень важна точка зрения со стороны, тем более разработчика.
То есть вот я ничего не скрываю, даже наоборот — отдаю ему код (что многие вообще боятся делать), а у него складывается ощущения что я что-то скрываю?
Как-то раз мне на собеседовании выложили топологию сети, карту сервисов и спросили что бы я здесь изменил. Я сказал «5 тысяч рублей». HR и директор даже два раза переспросили. Оказывается, я единственный из полутора десятков кандидатов отказался на халяву выдавать на гора идеи модернизации их сети.
Несмотря на то что я не устроился туда работать на постоянной основе, потому что работодатель не был готов оплачивать мои запросы, я провёл небольшую работу по перепланировке сети и получил за неё честный червонец.
По поводу пяти строк.
Мир знает уйму многолетних багов в различном софте, об которые обломали сотни копий. Я же не знаю, что за продукт мне предлагается править. Не знаю его подноготной. А вдруг я свежим взглядом его разгляжу и починю, а баги — они, как известно, как хорошее вино, с годами только дорожают.
По поводу «отдаю ему код».
Если говорить опять же метафорически, то ваша отдача кода — это новому подмастерью выдать гору нарезков ткани со словами «это — куртка для слона», и заданием перешить карман.
Думаю, что не ошибусь, если скажу что большинство людей идут работать с людьми, а не с кодом или должностной инструкцией. А ваша политика в большинстве случаев соберёт только тех, кому равно наплевать с кем работать или «перекати-поле» на сезон перебиться.
Несмотря на то что я не устроился туда работать на постоянной основе, потому что работодатель не был готов оплачивать мои запросы, я провёл небольшую работу по перепланировке сети и получил за неё честный червонец.
По поводу пяти строк.
Мир знает уйму многолетних багов в различном софте, об которые обломали сотни копий. Я же не знаю, что за продукт мне предлагается править. Не знаю его подноготной. А вдруг я свежим взглядом его разгляжу и починю, а баги — они, как известно, как хорошее вино, с годами только дорожают.
По поводу «отдаю ему код».
Если говорить опять же метафорически, то ваша отдача кода — это новому подмастерью выдать гору нарезков ткани со словами «это — куртка для слона», и заданием перешить карман.
Думаю, что не ошибусь, если скажу что большинство людей идут работать с людьми, а не с кодом или должностной инструкцией. А ваша политика в большинстве случаев соберёт только тех, кому равно наплевать с кем работать или «перекати-поле» на сезон перебиться.
А я отвечу про «что-то скрывают». Из стандартного часового собеседования хорошим тоном считается оставить 10 минут на вопросы кандидата. И это могут быть самые любые вопросы. Я один раз обговаривал недельный отпуск через неделю после начала работы — сложный был вопрос, и если бы компания не согласилась, я бы в ней не работал. А когда собеседовался на тим лида, то моим вопросом было «можно я познакомлюсь с командой?», что в итоге стало решающим в выборе работы (таких хороших программистов я немного в жизни встречал). В вашей схеме места для таких вопросов не видно.
Опять же часовое интервью показывает в интервьювере его управленческие навыки. История из моей жизни — я уже видел код проекта до собеседования и знал главного его разработчика. Код был отличный и разработчик грамотный. Но после собеседования с его начальником, я в компанию не пошёл. Начльник был ужасный и, как я потом подтвердил в личной беседе, весь проект висел на программисте, с постоянными овертаймами и нервами. В половине случаев начальник только вредил, а в другой просто не помогал. Если бы меня брали по вышей схеме, я бы это узнал слшком поздно (код-то был хороший!).
И последнее. Вы понимаете, что вы заставляете программиста потратить на вас значительное количество времени? Это нормально, если вы потом будете холить и лелеять этого программиста, он ведь так много сил приложил, чтобы попасть именно к вам. Если же у вас средние по рынку условия труда, то вы просто паразитируете на малоопытности соискателей (говоря об опыте в поиске работы) и я искренне желаю вам обанкротиться.
Опять же часовое интервью показывает в интервьювере его управленческие навыки. История из моей жизни — я уже видел код проекта до собеседования и знал главного его разработчика. Код был отличный и разработчик грамотный. Но после собеседования с его начальником, я в компанию не пошёл. Начльник был ужасный и, как я потом подтвердил в личной беседе, весь проект висел на программисте, с постоянными овертаймами и нервами. В половине случаев начальник только вредил, а в другой просто не помогал. Если бы меня брали по вышей схеме, я бы это узнал слшком поздно (код-то был хороший!).
И последнее. Вы понимаете, что вы заставляете программиста потратить на вас значительное количество времени? Это нормально, если вы потом будете холить и лелеять этого программиста, он ведь так много сил приложил, чтобы попасть именно к вам. Если же у вас средние по рынку условия труда, то вы просто паразитируете на малоопытности соискателей (говоря об опыте в поиске работы) и я искренне желаю вам обанкротиться.
Вы отвечаете человеку, который однажды уволился с хорошей во всех отношениях работы из-за недостаточно удобного стула. После нескольких месяцев попыток выбить апгрейд мебели.
Это контр-пример к тезису про абсолютную важность зарплаты. По поводу остальной части Вашего коментария мне сказать нечего.
Это контр-пример к тезису про абсолютную важность зарплаты. По поводу остальной части Вашего коментария мне сказать нечего.
не обобщайте.
Если задание не велико, то потеря будет несколько часов времени. К тому же не факт, что таким образом выдадут рабочий проект или еще не решенную проблему. Бывает такое, что созревает проблема, создается чекпоинт, находится решение. На «проверку боем» вполне могут дать чекпоинт и посмотреть на сообразительность, даже если возникнут какие-то проблемы по правообладанию написанным соискателем кодом, то у заказчика уже будет решение проблемы, написанное по-другому как минимум, с использованием других методов решения — как максимум.
> Кроме того удачный проект это далеко не код+база…
Если вы действительно так считаете, пожалуйста, дайте мне доступ на чтение к вашему репозиторию. Я попробую найти для себя что-нибудь полезное.
Если вы действительно так считаете, пожалуйста, дайте мне доступ на чтение к вашему репозиторию. Я попробую найти для себя что-нибудь полезное.
Пожалуйста github.com/dapi/
Погодите, а названия доменов в вашем аккаунте на GitHub — это сайты ваших клиентов? Я это к тому, что вывешивая этот код, вы даете возможность хакерам бесплатно попрактиковаться во взломе защиты этих сайтов.
Вы оплачиваете выполненную работу, если кандидат вам не подошел?
Спасибо, не надо такого счастья. Если можно посмотреть код на гитхабе — то тестовое задание, в принципе, можно опустить, при условии что там достаточно связного кода от кандидата, но без оценки качества кода кандидата набирать точно не стоит. Как на устном собеседовании отсеять любителей спагетти-кода на пару тысяч строк?
Я лично посылаю, если на тест надо потратить более 4 часов.
Либо выполняю частично, чтобы навыки показать.
Либо выполняю частично, чтобы навыки показать.
А зачем вы решали тестовые задания, если вас не устраивает такой подход? Послали бы такого работодателя сразу, и всё.
Интересный подход можно посмотреть код приложения решить хочеться ли тебе рабираться в этом говнокоде или нет, посмотреть чем занимаются каких демонов пишут и т.д.
С недавнего момента решил что при устройстве на работу надо спрашивать у работодателя его код посмотреть, почему эта практика распостарнена в 1ну сторону?
Вот так придешь и окажеться большая куча «хитрого» кода 5 летней давности, в котором и разбираться то не хочеться, а работать с ним придеться.
Про собрать самому: считаю неудачный подход, когда человек чтоб влиться в проект должен потратить день-полдня на сборку окружения — то это не тру.
Должен быть 1 скрипт — сделать деплой, + загрузить девелоперскую бд, если у вас его нет из коробки то это уже показатель, что может там и тестов нет и сервера интеграции и прочих полезных и приятных штук.
С недавнего момента решил что при устройстве на работу надо спрашивать у работодателя его код посмотреть, почему эта практика распостарнена в 1ну сторону?
Вот так придешь и окажеться большая куча «хитрого» кода 5 летней давности, в котором и разбираться то не хочеться, а работать с ним придеться.
Про собрать самому: считаю неудачный подход, когда человек чтоб влиться в проект должен потратить день-полдня на сборку окружения — то это не тру.
Должен быть 1 скрипт — сделать деплой, + загрузить девелоперскую бд, если у вас его нет из коробки то это уже показатель, что может там и тестов нет и сервера интеграции и прочих полезных и приятных штук.
Про посмотреть код приложения — очень резоный довод. Да и локально приложение тоже должно запускаться с полпинка со всеми тестами, это показатель отношения к новичкам.
А мне уже и на код пофиг. Главное — кадры и способ работы этих кадров. Говнокод переписать можно, были бы руки правильной кривизны.
«Зачем же срать в туалет, когда можно насрать под дверь и потом убрать ?»
Утрирую, но подход в чем-то похожий. Если там такие «хорошие» кадры то почемцу пишут говнокод?
И приходить в компанию чтобы переписыть весь ее код — какой-то непонятный подоход.
Утрирую, но подход в чем-то похожий. Если там такие «хорошие» кадры то почемцу пишут говнокод?
И приходить в компанию чтобы переписыть весь ее код — какой-то непонятный подоход.
Разница между говонокодом и суперкодом — ну очень относительная. Что для одного разработчика говнокод, для другого может быть примером подражания. Переписывание говнокода — нормальный рабочий процесс. Его нужно переписывать всегда.
Иногда компании приглашают более опытных работников не потому, что им захотелось увеличить свои расходы, а потому, что хотят что-то улучшить в процессах, которые происходят внутри компании. Они хотят задать новую планку качества, и это очень позитивно.
Иногда компании приглашают более опытных работников не потому, что им захотелось увеличить свои расходы, а потому, что хотят что-то улучшить в процессах, которые происходят внутри компании. Они хотят задать новую планку качества, и это очень позитивно.
Вообще говоря для нового девелопера потратить полдня на сборку окружения — это мало. В ядреных Enterprise-проектах считается нормальным закладывать что на это уйдет день-три (считая всякие неожиданности).
Единственное, чего не хватает в этой схеме, это пункта:
N. Независимо от того, будет в последствии принят разработчик на работу или нет, время, которое он потратил на работу над проектом будет оплачено.
Конечно это правило может не распространяться на тех, кто так и не смог запустить проект.
Но если человек сделал для Вас какую-то работу в проекте, то эта работа должна быть оплачена. Независимо от того, будете Вы с ним дальше сотрудничать или нет.
N. Независимо от того, будет в последствии принят разработчик на работу или нет, время, которое он потратил на работу над проектом будет оплачено.
Конечно это правило может не распространяться на тех, кто так и не смог запустить проект.
Но если человек сделал для Вас какую-то работу в проекте, то эта работа должна быть оплачена. Независимо от того, будете Вы с ним дальше сотрудничать или нет.
Спасибо, уже не первый комментарий на эту тему, важный момент значит, нужно его сразу озвучивать.
0. Так и непонятно: платили ли вы за эти дни или нет?
(Напишите P.S. ?)
1. А это действительно самый существенный момент — вероятно вы за ним и пришли.
2.
2.1. Принимаете 1 из 15; а почему так?
У меня стойкое ощущение, что значительная доля из них (33—50% ) просто развернулась и ушла; и именно из-за вот этого момента. Что-то за бесплатно делать несколько дней…
Пришли, полюбопытствовали, потыкали, и бросили. За эти несколько дней потенциальный кандидат может сделать деньги $ пойдя на тот же фриланс.
2.2. Вторая грань: кандидат может думать, что его просто используют. Закроет он пару ошибок, а ему пока-пока. Вот из-за этого многие дают тестовое задание, которое всем очевидно, что пойдёт в /дев/нуль.
(Вариант вам: давайте настоящий опенСорс — любой проект на ваш вкус)
3. Всё это отменяется если вы гугль, но вы же не гугль? И даже не локальный гугль. У вас же нет очереди на год?
4. А вот в этой 1/15 вы ещё упускаете кандидатов, которые не настолько любопытны, чтобы вступать в контакт. (Ну, или разворачиваются сразу поле предложения исправить ошибку) Они просто проходят мимо вашей такой сомнительной вакансии.
Сдаётся мне, что самые квалифицированные кадры здесь как раз.
(Напишите P.S. ?)
1. А это действительно самый существенный момент — вероятно вы за ним и пришли.
2.
2.1. Принимаете 1 из 15; а почему так?
У меня стойкое ощущение, что значительная доля из них (33—50% ) просто развернулась и ушла; и именно из-за вот этого момента. Что-то за бесплатно делать несколько дней…
Пришли, полюбопытствовали, потыкали, и бросили. За эти несколько дней потенциальный кандидат может сделать деньги $ пойдя на тот же фриланс.
2.2. Вторая грань: кандидат может думать, что его просто используют. Закроет он пару ошибок, а ему пока-пока. Вот из-за этого многие дают тестовое задание, которое всем очевидно, что пойдёт в /дев/нуль.
(Вариант вам: давайте настоящий опенСорс — любой проект на ваш вкус)
3. Всё это отменяется если вы гугль, но вы же не гугль? И даже не локальный гугль. У вас же нет очереди на год?
4. А вот в этой 1/15 вы ещё упускаете кандидатов, которые не настолько любопытны, чтобы вступать в контакт. (Ну, или разворачиваются сразу поле предложения исправить ошибку) Они просто проходят мимо вашей такой сомнительной вакансии.
Сдаётся мне, что самые квалифицированные кадры здесь как раз.
0. Я плачу всегда. Иногда даже когда код не принимается, но видно что кандидат старался.
2. Да, 1-2 некоторые уходят со словами «это слишком сложно для меня», некоторые начинают обсуждать варианты оплаты за не удачу и т.д.
2. Доверие оно или есть или нет и кому-то нужно сделать первый шаг на встречу — я сделал, открыл код, отдал базу, теперь очередь претендента, если он не способен себя пересилить и для него представляет такую огромную опасность потратить 3 часа чтобы получить работу которую он хочет (а если не хочет какого пишет?) то нам такой кандидат не нужен.
3. Очереди на год у нас нет. Дали объявление — неделю разгребаем кандидатов, потом дали следующее, еще неделю разгребаем.
4. Да, еще упускаем тех, кто не увидел наше объявление.
К сожалению квалификация не означает результативность конкретно в нашем проекте. Поэтому мы и проверяем на результат.
2. Да, 1-2 некоторые уходят со словами «это слишком сложно для меня», некоторые начинают обсуждать варианты оплаты за не удачу и т.д.
2. Доверие оно или есть или нет и кому-то нужно сделать первый шаг на встречу — я сделал, открыл код, отдал базу, теперь очередь претендента, если он не способен себя пересилить и для него представляет такую огромную опасность потратить 3 часа чтобы получить работу которую он хочет (а если не хочет какого пишет?) то нам такой кандидат не нужен.
3. Очереди на год у нас нет. Дали объявление — неделю разгребаем кандидатов, потом дали следующее, еще неделю разгребаем.
4. Да, еще упускаем тех, кто не увидел наше объявление.
К сожалению квалификация не означает результативность конкретно в нашем проекте. Поэтому мы и проверяем на результат.
0. Зачем мне этот головняк: заплтят… а вдруг кинут, как в тот раз… Да ну его нафиг.
2. Есть 2 варианта: работа в большой компании с обычным собеседованием и симпотичными HR, куча проектов и корпоротивные плюшки
и небольшая конторка без HR и стремным тестовым заданием, когда вместо 1-2 часов собеседования мне придется потратить 8 часов на весь процесс. Выбор 2ого варианта будет лишь в том случае, если откажут в первом.
3. За день кондидат рассылает....100-200 резюме. отвечают 5-15 %. получаем 10-30 предложений… даже если будет 2 тестовых задания, то нужно уже расставлять преоритеты. А что будет если заданий 4-5? А каждый работодатель хочет мгновенного ответа, ведь у него «так хорошо работается: и офис светлый и обеды халявные и xbox есть». А от куда это можно узнать по коду и скорее приступить делать тестовое задание?
2. Есть 2 варианта: работа в большой компании с обычным собеседованием и симпотичными HR, куча проектов и корпоротивные плюшки
и небольшая конторка без HR и стремным тестовым заданием, когда вместо 1-2 часов собеседования мне придется потратить 8 часов на весь процесс. Выбор 2ого варианта будет лишь в том случае, если откажут в первом.
3. За день кондидат рассылает....100-200 резюме. отвечают 5-15 %. получаем 10-30 предложений… даже если будет 2 тестовых задания, то нужно уже расставлять преоритеты. А что будет если заданий 4-5? А каждый работодатель хочет мгновенного ответа, ведь у него «так хорошо работается: и офис светлый и обеды халявные и xbox есть». А от куда это можно узнать по коду и скорее приступить делать тестовое задание?
Я, как кандидат, не стал бы ничего делать за бесплатно — это плохая практика. Такой подход прокатит только со студентами или с разработчиками, не умеющими ценить и оценивать своё время.
А как должен выглядеть процесс отбора кандидата на ваш взгляд? Если объективно, учитывая все ваши тредования/опасения как разработчика, а также учитвая нюансы компании, что в нее приходит 5-10 писем от кандидатов ежедневно?
Предлагаю пофантазировать и найти взаимовыгодный механизм.
Предлагаю пофантазировать и найти взаимовыгодный механизм.
Если вы хотите нанять действительно профессионала, и вы не гугл или ещё какой-либо IT-гигант, то, быть может, стоит посмотреть в сторону фриланса? Т. е. нанимать на сделюную работу (ваши тикеты) на фрилансовой основе.
5-10 писем ежедневно, странно. Попробуйте поработать с текстом вакансии для начала.
По статистике, мы нанимаем одного из 10-20 обратившихся кандидатов
приходит 5-10 писем от кандидатов ежедневно
Т.е. вы нанимаете в среднем одного человека каждые два дня? О_О
Поддерживаю, хотят посмотреть как я работаю — пусть берут из резюме любой проект, как старые, так и из текущих живых, ну и смотрят код.
Тоже верно. Подобный подход подходит, разве что, в том случае, когда кандидат только начинает карьеру программиста и имеет девственно чистое портфолио.
то есть вы хотите сказать, что ни один опытный php-программист не согласиться испытать себя в такой задании на вакансию веб-разработчика за 80 тыс?
Нет, кто-то и согласится, но лично я бы вряд ли стал делать испытательную работу только из-за того, что мне посулили хорошую зарплату. Тут многое зависит от имени (бренда) компании, и от условий, которые она предлагает. Например, если бы мне вместо собеседования так в лоб кинули испытательное задание, я бы однозначно отказался. Просто, я уже давно прошёл тот этап, когда на собеседовании выбирают только меня. Подбор действительно хорошего кандидата — процесс обоюдный.
Конечно, можно и нужно поговорить, тыры-пыры, бла-бла, но все равно, в любом случае, рано или поздно, дело дойдет до первой задачи. И ни вы, ни я не хотим оказаться в положении, когда вы бросили свою старую работу, пришли к нам на новую и оказалось что мы не подходим с вами друг к другу потому что задание вами не может быть выполнено.
Так может разговоры разговорами, а задачу все равно придется делать? Вы или хотите ее делать или нет, если нет — то только вы знаете почему, так только вы и можете разобраться с этим.
Или без прилюдии все-таки никак? )
Так может разговоры разговорами, а задачу все равно придется делать? Вы или хотите ее делать или нет, если нет — то только вы знаете почему, так только вы и можете разобраться с этим.
Или без прилюдии все-таки никак? )
Не, без прилюдии никак) Или вы хотите нанять разработчика, единственной мотивацией которого являются деньги? Не думаю, что в долгосрочной перспективе от такого работника будет много толка…
А почему вас не устраивает тот факт, что вам придётся оплатить тестовую работу? Даже если человек не подошёл по каким-то параметрам, но сделал свою работу с приемлемым качеством, то, я считаю, его труд должен быть оплачен вне зависимости от того, берёте ли вы этого человека к себе на работу или нет.
А почему вас не устраивает тот факт, что вам придётся оплатить тестовую работу? Даже если человек не подошёл по каким-то параметрам, но сделал свою работу с приемлемым качеством, то, я считаю, его труд должен быть оплачен вне зависимости от того, берёте ли вы этого человека к себе на работу или нет.
Ну вот посмотрели, хороший код, что дальше?
А дальше собственно начинается само собеседование, где мы взаимно узнаем друг об друге, договариваемся об условиях и прочих вещах. И если и тут все хорошо, то можно приступать к работе, не без испытательного срока конечно.
А все эти проверки вроде тестовых мелких заданий или ващего случая имеют смысл только если у человека пустое резюме и именно он нуждается в вас, а не вы в хорошем специалисте. Любому разработчику с опытом всегда найдется что показать.
А все эти проверки вроде тестовых мелких заданий или ващего случая имеют смысл только если у человека пустое резюме и именно он нуждается в вас, а не вы в хорошем специалисте. Любому разработчику с опытом всегда найдется что показать.
Ну хорошо, договорились об условиях. Дальше и вы стоите перед выбором — уходить со старой работы на новую или нет? А вдруг я им не подойду и потеряю и новую, и старую? Или вы без страха и упрека кинетесь в «проверенный на словах» омут? Дальше я вас возьму на испытательный срок, дам первую задачу и если вы ее не выполните — испытательный срок сразу закончится.
Не проще ли сразу сделать реальный рабочий тикет? Вы ведь даже не знаете какого размера тикеты у нас, может его неделю делать, а может час?
Ну если нравится, до этого, конечно поговорим )
Не проще ли сразу сделать реальный рабочий тикет? Вы ведь даже не знаете какого размера тикеты у нас, может его неделю делать, а может час?
Ну если нравится, до этого, конечно поговорим )
Открытость — это приятно, но не опасно ли давать всем желающим исходники своего проекта? Ведь имея код гораздо проще найти уязвимости.
Сорри за оффтоп но «не убидело» пишется через е, затем и(«не убедило»), наверно опечатались.
с таким подходом вам и сотрудники не нужны. Можно распределить задачу между соискателями, а потом дать всем отпор.
У нас на contractor scheme (Великобритания) зачастую используется следующее (оговаривается в контракте):
Первую неделю уведомление о расторжении для обоих сторон — 1 день.
Последующие 3 недели — 1 неделя уведомления. После окончания первого месяца — 1 месяц.
Делается это зачастую что сроки горят, найти контрактного работника (на срок 1 -3 мес без оформления в штат) сложно, собеседования как правило по телефону (проходятся очень легко) и поэтому решение о принятии происходит в 1-ый 2-ой день работы.
Приехать на собеседование несколько накладно для кандидата — в провинции за счет малой концентрации работ выборка нового места происходит в радиусе 50 км + билеты на поезд дорогие, попытка съездить на собеседование обойдется кандидату примерно в $30 — $50, по времени тоже полдня потерять.
Таким образом если первичный телефонный фильтр пройден, то кандидат приезжает уже на 1-ый рабочий день и если он уж совсем не подходит то он получит компенсацию за время + деньги в размере одного рабочего дня и дальше стороны ничего не должны друг другу.
А для компаний эти деньги в рамках погрешности. Особо дотошные работодатели могут продолжать собеседования и тесты в первый день, просто за это придется немного заплатить.
Мне кажется это удобно для обоих сторон.
Первую неделю уведомление о расторжении для обоих сторон — 1 день.
Последующие 3 недели — 1 неделя уведомления. После окончания первого месяца — 1 месяц.
Делается это зачастую что сроки горят, найти контрактного работника (на срок 1 -3 мес без оформления в штат) сложно, собеседования как правило по телефону (проходятся очень легко) и поэтому решение о принятии происходит в 1-ый 2-ой день работы.
Приехать на собеседование несколько накладно для кандидата — в провинции за счет малой концентрации работ выборка нового места происходит в радиусе 50 км + билеты на поезд дорогие, попытка съездить на собеседование обойдется кандидату примерно в $30 — $50, по времени тоже полдня потерять.
Таким образом если первичный телефонный фильтр пройден, то кандидат приезжает уже на 1-ый рабочий день и если он уж совсем не подходит то он получит компенсацию за время + деньги в размере одного рабочего дня и дальше стороны ничего не должны друг другу.
А для компаний эти деньги в рамках погрешности. Особо дотошные работодатели могут продолжать собеседования и тесты в первый день, просто за это придется немного заплатить.
Мне кажется это удобно для обоих сторон.
хочу пояснить что contractor scheme — это некий аналог договора подряда, когда вместо того чтобы нанимать человека в штат заключается контракт с другой Ltd (ООО организацией) его представляющей. В итоге компания — работодатель избегает многих проблем присущих постоянному найму — проблемы социалки, оплачиваемые отпуска, увольнения ненужного работника (как правило по contractor набирают людей под краткосрочные проекты пару месяцев). С другой стороны это все учитывается при оплате — почасовые рэйты у контракторов как правило процентов на 20 — 30 выше аналогичного уровня постоянного работника
Хороший вариант. Часто программисты сами предлагаю попробовать что-то сделать в домашних условиях вечером удаленно, так как не имеют возможности приехать днем ввиду текущей занятости.
Круто. Серьезный подход который как бы говорит всем: наши сотрудники — это просто программисты. Мы их не видим, мы с ними не общаемся — они просто пишут код и получают зарплату.
Как говорится, из перечня советов того чего не надо делать чтобы сделать из набора людей команду.
Как говорится, из перечня советов того чего не надо делать чтобы сделать из набора людей команду.
Такое отношение имеет право на жизнь. Это довольно распространенный способ взаимоотношений управленцев и работников. Потому что цель одна — рубить бабло. Не важно на чем, не важно с какими последствиями, не важно кто будет это делать, важен результат в виде хрустящих бумажек, новых побрякушек, Майбахе за окном. При таком подходе программирование является ничем не отличимым способом заработать от садоводства или доставки пиццы. Люди просто выбрали самую высокодоходную отрасль среди аналогичных с низким порогом вхождения, и занимаются себе зарабатыванием денег. Это нормально. :)
С точки зрения бизнеса — нет. Смысл любой компании — максимизировать прибыль. И основная задача PM'а — сделать из людей команду. Я всегда считал что это главная задача PM'а.
Собственно команда работает намного продуктивнее. А в данном случае «продуктивнее» эквивалентно «лучше с точки зрения владельца бизнеса в денежном эквиваленте».
Собственно команда работает намного продуктивнее. А в данном случае «продуктивнее» эквивалентно «лучше с точки зрения владельца бизнеса в денежном эквиваленте».
Максимизация прибыли достигается множеством способов. Можно выстроить такую модель, при которой рост доходов будет превышать рост расходов. А можно строить модель, которая будет стараться чередовать рост доходной+расходной и уменьшение расходной части.
Приведу вам график из своей же статьи.
habrastorage.org/storage/8469b7b8/766ffd3e/c922afc6/3abb9e30.png
Красная линия — расходная часть. Даже если вы особо не хотите, затратная часть компании постоянно растет. Старые работники хотят роста выплат по заработной плате, плюшек в офисе, удобные креселки и новые ноутбуки.
Если доходы растут гораздо быстрее расходов, то вы забиваете на расходную часть, и наслаждаетесь увеличением прибыли. Ваша основная задача — поддержание позитивного баланса роста доходов. Это выражается в ускорении темпов разработки, выдачи новых продуктов на гора, привлечение новых клиентов, увеличении количества продаж и так далее. Больше полезного кода выдал — больше продал — больше заработал. Кто именно делает, какая команда — все равно.
В более вялотекущей ситуации на рынке рост доходов гораздо меньше, и он напрямую завязан на рост рынка. Как увеличить прибыль? Снижая затратную часть. Скорость разработки играет роль, но быстро переломить ситуацию на рынке будет тяжело. На дополнительные 20% фич нужно будет потратить 80% ресурсов. Это дороговато, плюс результат не гарантирован. Можно повышать отдачу текущих работников. Можно увольнять дорогих работников, набирать на их место кого-то попроще. Команда в данной ситуации может действительно играть роль.
Приведу вам график из своей же статьи.
habrastorage.org/storage/8469b7b8/766ffd3e/c922afc6/3abb9e30.png
Красная линия — расходная часть. Даже если вы особо не хотите, затратная часть компании постоянно растет. Старые работники хотят роста выплат по заработной плате, плюшек в офисе, удобные креселки и новые ноутбуки.
Если доходы растут гораздо быстрее расходов, то вы забиваете на расходную часть, и наслаждаетесь увеличением прибыли. Ваша основная задача — поддержание позитивного баланса роста доходов. Это выражается в ускорении темпов разработки, выдачи новых продуктов на гора, привлечение новых клиентов, увеличении количества продаж и так далее. Больше полезного кода выдал — больше продал — больше заработал. Кто именно делает, какая команда — все равно.
В более вялотекущей ситуации на рынке рост доходов гораздо меньше, и он напрямую завязан на рост рынка. Как увеличить прибыль? Снижая затратную часть. Скорость разработки играет роль, но быстро переломить ситуацию на рынке будет тяжело. На дополнительные 20% фич нужно будет потратить 80% ресурсов. Это дороговато, плюс результат не гарантирован. Можно повышать отдачу текущих работников. Можно увольнять дорогих работников, набирать на их место кого-то попроще. Команда в данной ситуации может действительно играть роль.
Минуту, минуту. Все замечательно, но вы рассматриваете все это дело с точки зрения топ-менеджмента, когда у них нет явных рычагов управления стоимостью.
На нижнем уровне команды, вам в принципе не все равно (должно быть) что доход вашей команды превалирует над расходами.
Грубо говоря позитивный тренд вы можете поддерживать тем что за каждый созданный продукт вам платят N рублей, а на этапе разработки вы тратите N-1. У вас константная разница. При этом вы некими манипуляциями можете добиться что ваши затраты упадут до (N-1)/k. Вы в большом-большом профите.
Кстати, поддержание позитивного баланса роста доходов.
Был бы рынок — была бы конкуренция (а то что вы описываете — это попросту один из ответов на факт существования конкуренции).
Рынка нет — все делается проще, на увеличение собственных затрат, компания реагирует повышением цен для заказчика.
На нижнем уровне команды, вам в принципе не все равно (должно быть) что доход вашей команды превалирует над расходами.
Грубо говоря позитивный тренд вы можете поддерживать тем что за каждый созданный продукт вам платят N рублей, а на этапе разработки вы тратите N-1. У вас константная разница. При этом вы некими манипуляциями можете добиться что ваши затраты упадут до (N-1)/k. Вы в большом-большом профите.
Кстати, поддержание позитивного баланса роста доходов.
Был бы рынок — была бы конкуренция (а то что вы описываете — это попросту один из ответов на факт существования конкуренции).
Рынка нет — все делается проще, на увеличение собственных затрат, компания реагирует повышением цен для заказчика.
Программисты не должны заботиться над тем, как управляет компанией топ-менеджмент. Им должно быть комфортно творить. Если программисты вдруг озаботились объемом продаж или новым лексусом директора, то это будет лакмусовой бумажкой, сигнализирующей про проблемы в компании. Программист должен получать моральное и материальное удовлетворение от работы. Точка.
Задача PM-а — сделать продукт или выполнить проект. В рамках сроков и бюджета.
Ну почему вы считаете что мы их не видим и не общаемся? Ну где это написано? Общайтесь на здоровье — вам же с первой минуты дают доступ в общий чат — говорите с кем хотите о чем хотите, где еще в «общительных» компаниях вы с первой минуты можете увидеть и поговорить со всеми участниками проекта?
Скажу честно,. мой недавный опыт хождения по собеседованиям показывает абсолютную несостоятельность hr'ов. При этом чем меньше компания, тем хуже hr'ы (казалось бы закономерно: чем компания больше — тем лучше hr'а она может себе позволить), но тогда каким образом маленькие конторки собираются набирать себе персонал?
Смысл в том, что например в фидбеках с отказами (после 3-4 интервью в одной компании), hr'ы даже не удосуживаются описать по какому набору причин было решено отказать. Некоторые hr'ы даже не пишут об отказе.
Я думаю вы понимаете что такого рода компании запоминаются надолго и в далеко не лучшем свете.
У вас схожая штука. Ваш метод приема на рабоут заточен под нужды вашей компании, но никак не в интересах вашего _потенциального_ работника.
Ну и да, время соискателя так же стоит денег, а вы бросаете его что-то делать еще до того как он осознал что он хочет у вас работать.
Смысл в том, что например в фидбеках с отказами (после 3-4 интервью в одной компании), hr'ы даже не удосуживаются описать по какому набору причин было решено отказать. Некоторые hr'ы даже не пишут об отказе.
Я думаю вы понимаете что такого рода компании запоминаются надолго и в далеко не лучшем свете.
У вас схожая штука. Ваш метод приема на рабоут заточен под нужды вашей компании, но никак не в интересах вашего _потенциального_ работника.
Ну и да, время соискателя так же стоит денег, а вы бросаете его что-то делать еще до того как он осознал что он хочет у вас работать.
Если он еще не осознал что хочет у нас работать и просит взять его на работу, то это просто какой-то не осознанный сотрудник. Если он уже совершеннолетний, то пора бы осознаться.
Каким образом? Все что соискатель знает — как компания выглядит извне.
Не согласен. Тут уже приводили примеры, когда соискатель посылает несколько резюме в разные места, не потому что он ищет работу именно в этих местах (по совокупности причин), а потому, что он ищет работу по данной специальности. И ваша фирма — не лучшая — а просто одна среди многих. Может быть — несколько выше других по рейтингу — может быть — ниже.
Так что соискатель должен лишь осознать, что он хочет работать — а остальное уже «плюшки». Ровно как и Вы, как работодатель, ищите человека, который может работать с вашими тикетами, а остальное лишь «плюшки».
Так что соискатель должен лишь осознать, что он хочет работать — а остальное уже «плюшки». Ровно как и Вы, как работодатель, ищите человека, который может работать с вашими тикетами, а остальное лишь «плюшки».
hr-ы зачастую и сами не знают, почему соискатель не прошел техническое собеседование.
Разве что в крупных компаниях технический специалист, проводящий собеседование, отчитывается перед hr о результатах.
А зачастую hr получает отчет о техническом собеседовании в виде пары слов. Типа «не, слабоват» или «полный ноль». Вот и нечего Вам ответить о причинах отказа.
Разве что в крупных компаниях технический специалист, проводящий собеседование, отчитывается перед hr о результатах.
А зачастую hr получает отчет о техническом собеседовании в виде пары слов. Типа «не, слабоват» или «полный ноль». Вот и нечего Вам ответить о причинах отказа.
Собеседования
а) не технические, а на менеджерские позиции
б) простите, а чем hr занимается, если он даже не знает/не хочет знать почему именно человек не прошел? Он спам чтоли только может рассылать: «приходите...», «вы нам подошли», «вы нам не подошли»?
а) не технические, а на менеджерские позиции
б) простите, а чем hr занимается, если он даже не знает/не хочет знать почему именно человек не прошел? Он спам чтоли только может рассылать: «приходите...», «вы нам подошли», «вы нам не подошли»?
Как обстоит дело с менеджерскими позициями, не знаю. Но подозреваю, что так же
Чем занимается hr? Поиском и первичной фильтрацией соискателей.
Но если уж человек пришел на техническое собеседование, то он уже выпал из компетенции HR. И никаких решений по нему hr уже не принимает. Просто передаст ему потом результаты.
Чем занимается hr? Поиском и первичной фильтрацией соискателей.
Но если уж человек пришел на техническое собеседование, то он уже выпал из компетенции HR. И никаких решений по нему hr уже не принимает. Просто передаст ему потом результаты.
Мне почему-то казалось что hr ведает всем процессом обследования человека.
И это следует из того, что если он этого не делает, то о компании создаются негативные представления. Что само по себе не смертельно, но и не особо хорошо, с учетом того что это связано с главным ресурсом компании, т.е. с людьми.
А так да, пусть как хотят, так и работают.
И это следует из того, что если он этого не делает, то о компании создаются негативные представления. Что само по себе не смертельно, но и не особо хорошо, с учетом того что это связано с главным ресурсом компании, т.е. с людьми.
А так да, пусть как хотят, так и работают.
Может где-то и так. Не знаю.
Но в IT работать с человеком придется тимлиду или ПМ.
Отвечать за его косяки тоже.
Так кто же должен принимать на себя ответственность за прием человека на работу?
А если говорить об имидже компании среди разработчиков, то тут профессионализм hr стоит на последнем месте.
Они вообще обычно воспринимаются, как мелкое, но неизбежное зло.
По работе в дальнейшем с ними сталкиваться не придется, так что обращать особое внимание.
Но в IT работать с человеком придется тимлиду или ПМ.
Отвечать за его косяки тоже.
Так кто же должен принимать на себя ответственность за прием человека на работу?
А если говорить об имидже компании среди разработчиков, то тут профессионализм hr стоит на последнем месте.
Они вообще обычно воспринимаются, как мелкое, но неизбежное зло.
По работе в дальнейшем с ними сталкиваться не придется, так что обращать особое внимание.
Один только вопрос — если я в процессе такого собеседования вам закрою тикет, вам понравится, вы сделаете мне оффер, а оффер не понравится мне и я от него откажусь, то мне оплатят работу по тикету? и даже если я соглашусь мне работу по тикету зачтут уже в будушей зарплате?
Далее, собственно собеседование это двухсторонний процесс. Я на собеседование прихожу не только себя показать, но и о компании узнать. Причем понятно до того как писать какие либо тесты.
В какой момент вы рассказываете о своей компании, отвечаете на вопросы разработчика? Описываете условия работы, вилку, структуру компании и т.п.? Ну т.е. собственно работата HR.
Мне подобный подход видится вполне жизнеспособным. Но он требует повышенной мотивации. Т.е. компания меня должна заинтересовать предварительно, прежде чем бросать на амбразуру :) Чем вы заинтересовываете??
И еще, вы говорите о 5-10 резюме. Откуда эти резюме? От HR отдела вашего или агенства? Или это просто на ваш адрес компании?
Как они получаются?
Просто после определенного кода стажа, скажем так, у меня и моих знакомых тенденция следующая — чаще наоборот на собеседования больше приглашают компании, чем ты сам отправляешь резюме. Что в целом согласовывается с рынком, на котором ситуация такая что количество хороших программистов с опытом сильно меньше чем потенциальных вакансий.
Т.е. если это 5-10 резюме это результат работы HR-а, который обзвонил и убедил прислать резюме и придти на собеседовние это одно. А если это саморазосланные резюме — то это немного другой уровень специалистов.
Может в этом направлении покапать — и не придется тогда делать такие стресс тесты?
Далее, собственно собеседование это двухсторонний процесс. Я на собеседование прихожу не только себя показать, но и о компании узнать. Причем понятно до того как писать какие либо тесты.
В какой момент вы рассказываете о своей компании, отвечаете на вопросы разработчика? Описываете условия работы, вилку, структуру компании и т.п.? Ну т.е. собственно работата HR.
Мне подобный подход видится вполне жизнеспособным. Но он требует повышенной мотивации. Т.е. компания меня должна заинтересовать предварительно, прежде чем бросать на амбразуру :) Чем вы заинтересовываете??
И еще, вы говорите о 5-10 резюме. Откуда эти резюме? От HR отдела вашего или агенства? Или это просто на ваш адрес компании?
Как они получаются?
Просто после определенного кода стажа, скажем так, у меня и моих знакомых тенденция следующая — чаще наоборот на собеседования больше приглашают компании, чем ты сам отправляешь резюме. Что в целом согласовывается с рынком, на котором ситуация такая что количество хороших программистов с опытом сильно меньше чем потенциальных вакансий.
Т.е. если это 5-10 резюме это результат работы HR-а, который обзвонил и убедил прислать резюме и придти на собеседовние это одно. А если это саморазосланные резюме — то это немного другой уровень специалистов.
Может в этом направлении покапать — и не придется тогда делать такие стресс тесты?
Офер обсуждается до того. Да, похоже я сам виноват, что в топике слишком сильно утрировал первоначальный диалог )
Мы рассказываем о компании сразу после получения вопроса о компании )
HR-а нет.
На счет мотивации хороший вопрос. Мы не мотивируем. Это мой принципиальный подход. И вот почему.
Мотивация у каждого своя, сугубо личная, каждый находится на своей ступеньки пирамидки Маслоу и только он сам знает (правда, чтоже не всегда) что его мотивирует. Мы даем возможность поработать в нашем коллективе и понять — мотивирует его работа у нас или нет. Кого-то мотивирует применение все более новых и новых технологий — но у нас в одном проекте они приеняются, а в другом нет. Кого-то мотивирует что его постоянно хвалят, так это вопрос также индивидуальный и выясняетвы в процессе работы. Кого-то мотивирует наличие хороших специалистов в команде — так они или есть или нет, являются наши сотрудники для новобранца авторитетами или нет мы можем только догадываться. Поэтому я считаю что разработчику нужно дать все что необходимо для того, чтобы он могу ни о чем не заботиться и сконцентрироваться на работе, а остальное это уже его дело.
Про чаще «чаще приглашают компании чем отсылаешь резюму» — могу только порадоваться за вас, еще на одного востребованного программиста больше, замечательно!
Насчет стресс тестов не понял. Мой топик как раз о том, что эти тесты делать не нужно, нужно сразу давать работу и не обманывать ни себя, ни соискателя. Ведь для этого его и на нимают.
Мы рассказываем о компании сразу после получения вопроса о компании )
HR-а нет.
На счет мотивации хороший вопрос. Мы не мотивируем. Это мой принципиальный подход. И вот почему.
Мотивация у каждого своя, сугубо личная, каждый находится на своей ступеньки пирамидки Маслоу и только он сам знает (правда, чтоже не всегда) что его мотивирует. Мы даем возможность поработать в нашем коллективе и понять — мотивирует его работа у нас или нет. Кого-то мотивирует применение все более новых и новых технологий — но у нас в одном проекте они приеняются, а в другом нет. Кого-то мотивирует что его постоянно хвалят, так это вопрос также индивидуальный и выясняетвы в процессе работы. Кого-то мотивирует наличие хороших специалистов в команде — так они или есть или нет, являются наши сотрудники для новобранца авторитетами или нет мы можем только догадываться. Поэтому я считаю что разработчику нужно дать все что необходимо для того, чтобы он могу ни о чем не заботиться и сконцентрироваться на работе, а остальное это уже его дело.
Про чаще «чаще приглашают компании чем отсылаешь резюму» — могу только порадоваться за вас, еще на одного востребованного программиста больше, замечательно!
Насчет стресс тестов не понял. Мой топик как раз о том, что эти тесты делать не нужно, нужно сразу давать работу и не обманывать ни себя, ни соискателя. Ведь для этого его и на нимают.
Под мотивацией я подразумевал что вы должны как-то донести до разработчика чем ваша компания лучше для него чем другие. А уж понять что именно для него значит «лучше» и сделать соответствующий оффер это работа HR.
А мы не лучше, звезд с неба не хватаем, у нас просто много работы для веб-разработчиков, мы за нее платим выше рынка, сотрудников обучаем, повышаем. Также не смотрим на рассу, серьги вносу, сексуальные предпочтения, манеру говорить, способность производить впечатление, послужной список — нас интересует только код. Об этом мы и даем понять с самого начала.
А по поводу стресс тестов. Я вот тут пообщался по поводу некоторых предложений с некоторыми компаниями. У них проекты не то чтобы очень большие, но не маленькие. Если переносить в вашу облать — то скажем это проекты уровня drupal наверно. Так вот, когда было обсуждение — как быстро от меня ждут результатов было сказано следующее — мы будем рады выесли первый реальный код который вы внесете в продашен ветку будет через месяц, но это будет нормально если он будет через 3 месяца. До этого вы должны будите разобраться с системой и процессом разработки. Поэтому извините, то что вы предлагаете это супер стрес тест :)
Да вот именно, что размер задач у всех разный. На самом деле всегда есть возможность давать задчи, которые выполняются за пол часа. Также есть возможность смотреть на реальный код претендента по настоящим задачм и принимать решение о его трудоустройстве в не зависимости от того решены они или нет. Но стоит ли об этом говорить сразу?
На счет мотивации хороший вопрос. Мы не мотивируем. Это мой принципиальный подход. И вот почему.
Можно прямой вопрос? Вы когда-нибудь работали с ребятами с мех-мата/вмк? Лично мне таких приходилось мотивировать оочень много. Не всех, но часть из них.
Можно прямой вопрос? Вы когда-нибудь работали с ребятами с мех-мата/вмк? Лично мне таких приходилось мотивировать оочень много. Не всех, но часть из них.
Нет не работал. Но думаю что их должна мотивировать сложность задачи. Поделитесь опытом.
Без интересной задачи они вообще не работают. Это на поверхности.
При этом если дать им рутину, то она займет у них намного больше времени чем у другого программиста, может и не настолько титулованного.
Таким образом я хочу сказать что к каждому нужен личный подход. А вы их всех стрижете под одну гребенку. Хотя если у вас это работает — замечательно :)
При этом если дать им рутину, то она займет у них намного больше времени чем у другого программиста, может и не настолько титулованного.
Таким образом я хочу сказать что к каждому нужен личный подход. А вы их всех стрижете под одну гребенку. Хотя если у вас это работает — замечательно :)
насчет титулованности, у выпускников ВМК, по моим наблюдениям, совершенно разный уровень встречается. От сразу готовых к боевой разработке до полных нулей. А вот от выпускников Бауманки сразу можно ожидать определенный уровень. Чисто наблюдение
Насчет рутины — вы абсолютно правы. И как показывает практика на рутину найти программистов сложнее всего, именно поэтому мы их сразу на ней и проверяем.
Если у вас есть рутина в работе, то вы явно что-то делаете не так…
Хорошо что в моей работе ее мало ) а вообще смотря чтобы называете рутиной. Строить дома, например наиболее рутинная из известных мне работ, трудно сказать что строители при этом делают что-то не так. При этом архитекторы возможно смотрят на этот вопрос иначе, штукатур может тоже находит в ней развлечение, но для меня это рутина.
Также и в разработке, если задачи которые решаются, а есть которые выполняются. Решение требует творческого подхода, выполнение — достаточно рутинная работа. Признаться честно наши проекты в основном состоят из рутины, креативные решения требуются не так часто.
Хорошо что не всем людям нравится постоянно что-то решать, некоторые способны выполнять достаточно монотонную работу и это достойно глубочайшего уважения.
Также и в разработке, если задачи которые решаются, а есть которые выполняются. Решение требует творческого подхода, выполнение — достаточно рутинная работа. Признаться честно наши проекты в основном состоят из рутины, креативные решения требуются не так часто.
Хорошо что не всем людям нравится постоянно что-то решать, некоторые способны выполнять достаточно монотонную работу и это достойно глубочайшего уважения.
а что не так с ребятами из МГУ? Просто интересно, приходят иногда на собеседование
А если у соисскателя ноги воняют невыносимо? Вы это по коду никогда не узнаете, а придется брать и мучиться всем коллективом.
Это я к тому что работа HR — не пустое место
Это я к тому что работа HR — не пустое место
Тут есть другой нюанс, а что если у соискателя рабочее место будет, рядом с другим сотрудником у которого воняют ноги :)
об этом даже при традиционном собеседовании не скажут, увы :)
на обыкновенном собеседовании на каком-то этапе дают посмотреть рабочее место потенциально и быстро познакомится с остальными участниками команды.
хм. никогда такое не практиковал. смысла не вижу:
— Парни!!! это Сережа, он ВОЗМОЖНО будет у нас работать
натянутая улыбка Сережи, подозрительный взгляд дюжины глаз из-за мониторов.
— Вот тут под кактусом будет твое место.
— Угу
вышли. голос из-за монитора:
— Третий за сегодня.
— Что ни рожа то Сережа
— бгггг
— Парни!!! это Сережа, он ВОЗМОЖНО будет у нас работать
натянутая улыбка Сережи, подозрительный взгляд дюжины глаз из-за мониторов.
— Вот тут под кактусом будет твое место.
— Угу
вышли. голос из-за монитора:
— Третий за сегодня.
— Что ни рожа то Сережа
— бгггг
а я вижу
Похожим образом и происходит. На самом деле за эти 15 секунд Серёжа получил огромное количество информации. На тумбочки у одного девеолпера велосипедный шлем — значит компания лояльна к велосипедистам. У бородатого здоровяка кружка Solaris (и даже не Open!) — значит будет чему поучиться у человека. Под столом у третьего футбольный мяч, значит можно будет поиграть после работы. Над рабочим местом очкарика в галстуке висит «мотиватор» про «нет глупых вопросов» — значит по крайней мере с ним можно будет обсуждать теорию программирования. А вот этого чувака Серёжа кажется на пойнтовке ещё в школе видел… И так далее.
Хорошо вы описали работу HR )
давать соискателю рабочий код неплохая идея, возможно он посмотрев на него и работать-то у вас не захочет
а вот настройка/сборка/написание кода для вашего проекта должно оплачиваться, причем по ставке привычной соискателю, иначе ему интереснее потратить это время на фриланс
в связи с этим на мой взгляд логичнее просто показать код + поставить какую-то задачу после чего соискатель бегло/тщательно (в зависимости от желания разработчика) просматривает код и пишет краткое описание решения аля я бы сделал так-то с применением таких-то библиотек/технологий/паттернов/фреймворков с такой-то примерной схемой классов/данных, возможно какие-то наброски wireframe
у хорошего разработчика это не должно занять много времени (не более часа-двух) и сразу будет видно умение проектировать и с какими технологиями знаком
после этого уже можно разговаривать об написании какого-то кода для вашего проекта за оплату, которая соответствует уровню разработчика
да и вообще можно просто попросить соискателя прислать какой-то свой код, качество кода не зависит от поставленной задачи, это очевидно
а вот настройка/сборка/написание кода для вашего проекта должно оплачиваться, причем по ставке привычной соискателю, иначе ему интереснее потратить это время на фриланс
в связи с этим на мой взгляд логичнее просто показать код + поставить какую-то задачу после чего соискатель бегло/тщательно (в зависимости от желания разработчика) просматривает код и пишет краткое описание решения аля я бы сделал так-то с применением таких-то библиотек/технологий/паттернов/фреймворков с такой-то примерной схемой классов/данных, возможно какие-то наброски wireframe
у хорошего разработчика это не должно занять много времени (не более часа-двух) и сразу будет видно умение проектировать и с какими технологиями знаком
после этого уже можно разговаривать об написании какого-то кода для вашего проекта за оплату, которая соответствует уровню разработчика
да и вообще можно просто попросить соискателя прислать какой-то свой код, качество кода не зависит от поставленной задачи, это очевидно
Про настройку вы скорее всего правы. В наших интересах сделать ее максимально упрощенной.
тем более, что вполне возможно применяемые в вашем проекте технологии достаточно далеки от разработчика, хоть он и работает в этом же стеке технологий, и ему потребуется некоторое время для того, чтобы в них разобраться
мне кажется все же важнее правильное проектирование и понимание основ
а тупо писать код можно научить дажеобезьяну индуса
мне кажется все же важнее правильное проектирование и понимание основ
а тупо писать код можно научить даже
Я практикую просто тестовое задание на дом после собеседования. Бывает, что на собеседовании прям нравится человек, готов брать. А задание как пришлёт…
эта схема совершенно не применима для выпускников и джунеоров по уровню.
эта схема совершенно не подходит для кандидатов, которые умеют мыслить, но по стечению обстоятельств занимались рутиной/поддержкой проекта. Не зря в MS и Google простя простой код написать прямо на собеседовании на доске, а не поправить баг в винде.
Эта схема позволяет заменить одного кодера на другого быстро. Она не позволяет найти человека, который является разработчиком.
эта схема совершенно не подходит для кандидатов, которые умеют мыслить, но по стечению обстоятельств занимались рутиной/поддержкой проекта. Не зря в MS и Google простя простой код написать прямо на собеседовании на доске, а не поправить баг в винде.
Эта схема позволяет заменить одного кодера на другого быстро. Она не позволяет найти человека, который является разработчиком.
При таком подходе, может сразу уйти в OpenSource? Если у более ста человек есть ваши исходники, то можно их смело открывать.
Мне думается это весьма правильный подход. Не обязательно давать на доработку то приложение, над которым работает контора. Можно написать свое простое приложение и попросить его доработать, например. Это реально лучше, чем «набирать по объявлению», т.к. по личному опыту, у программистов обычно умение красиво говорить заменяет умение писать код.
Когда передо мной начальство поставило задачу написать тест, я сделал очень простую задачу: из текстового файла (csv) сгенерировать rss, плюс еще выдрав нужные подстроки из текста в некоторых колонках. Не справился никто, даже идеально.
А приведенные автором тест сразу покажет уровень, с этим ни один ruby-разработчик не поспорит, т.к. априори он должен знать как работать с git и как править хорошо организованный ruby-код (если он является таковым). Но это, конечно, не может исключать некоторых вопросов к разработчикам со стороны тестируемого.
Когда передо мной начальство поставило задачу написать тест, я сделал очень простую задачу: из текстового файла (csv) сгенерировать rss, плюс еще выдрав нужные подстроки из текста в некоторых колонках. Не справился никто, даже идеально.
А приведенные автором тест сразу покажет уровень, с этим ни один ruby-разработчик не поспорит, т.к. априори он должен знать как работать с git и как править хорошо организованный ruby-код (если он является таковым). Но это, конечно, не может исключать некоторых вопросов к разработчикам со стороны тестируемого.
Если я посажу перед своим проектом хоть одного кодера со знаниями выше среднего, у него взорвется мозг. И не потому что говнокод, а потому что такого подхода к разработке я не видел нигде. Именно эта причина и будет основой для его коллапса мозга.
Кандидат с большим потенциалом и даже с хорошим опытом, вполне может не знать как работать с git, правда вы его не упустите все равно, потому что для него не будет никакой проблемы по тихому потратить полчаса собственного времени, чтобы разобраться с ним, вместо того чтобы жаловаться и обещать научиться когда-то потом.
Что правда из-за git'а не возьмете? Его же за полчаса с перекурами можно освоить. К тому же в офисной разработке git я лично не встречал
Поддерживаю автора. Хотя отдавать соискателям коммерческий код в качестве тестовых задач это какой-то панк. :)
Если в проекте используются сторонние opensource фреймворки или библиотеки, то у них, как правило, уже есть свои публично доступные баг-трекеры с кучей тикетов, актуальность и полезность решения которых не вызывает сомнений.
Для подготовки к собеседованию мы предлагаем кандидатам проработать один из нескольких тикетов, отобранных нашими разработчиками. При этом выбор конкретного тикета и степень проработки решения целиком лежит на совести кандитата и определяется его желаниям произвести впечатление на интервью по заявляемым скилам (опыт работы с данным фреймворком, умение разбираться в чужом коде, писать тесты, ...). Весь код, написанный в рамках подготовки к собеседованию, отправляется соискателями не нам, а в opensource проект — все честно.
Если в проекте используются сторонние opensource фреймворки или библиотеки, то у них, как правило, уже есть свои публично доступные баг-трекеры с кучей тикетов, актуальность и полезность решения которых не вызывает сомнений.
Для подготовки к собеседованию мы предлагаем кандидатам проработать один из нескольких тикетов, отобранных нашими разработчиками. При этом выбор конкретного тикета и степень проработки решения целиком лежит на совести кандитата и определяется его желаниям произвести впечатление на интервью по заявляемым скилам (опыт работы с данным фреймворком, умение разбираться в чужом коде, писать тесты, ...). Весь код, написанный в рамках подготовки к собеседованию, отправляется соискателями не нам, а в opensource проект — все честно.
Полностью поддерживаю. Кандидат всегда может проявить себя в OpenSource-проектах. А учитывая, что абсолютное большинство веб-программистов используют плоды OpenSource в своей профессиональной деятельности, нежелание внести безвозмездный вклад в открытый проект в виде нескольких часов рабочего времени вполне может расцениваться как неуважение к своим коллегам.
Про opensource — хорошая идея!
Тут задали интересный вопрос — rsdn.ru/forum/job/4280134.1.aspx
Т.е. приходим на собеседование, делаем реальный кусок задачи, решение устраивает мы получаем должность и оно идет в продакшен ветку.
Ждем пока система где будет наш код будет реально продаваться в США к примеру.
Идем в суд, и заявляем о нарушении наших прав — продажи на территории США приостанавливаются на время суда.
Обсуждаем сумму о полюбовном соглашении, чтобы возобновить продажи на территории США.
Профит??
Т.е. приходим на собеседование, делаем реальный кусок задачи, решение устраивает мы получаем должность и оно идет в продакшен ветку.
Ждем пока система где будет наш код будет реально продаваться в США к примеру.
Идем в суд, и заявляем о нарушении наших прав — продажи на территории США приостанавливаются на время суда.
Обсуждаем сумму о полюбовном соглашении, чтобы возобновить продажи на территории США.
Профит??
А в чем заключается нарушение прав если вы получили должность?
Если у вас хватит ресурсов, что бы такое провернуть, то работа программистом вам не нужна.
Я как раз о том и говорю. Цель данного мероприятия не работа программистом как раз.
Ну надо учитывать теоретическую вероятность такого попадоса, но она мала и легко купируется подписанием какой-нибудь бумажки или акцептованием какой-нибудь оферты на вебе. Теоретически сюда попадает вообще большая часть удалённой-полуофициальной работы, однако о подобных разборках что-то пока не слышно. Т.е что бы кого-то так поиметь, надо 1) найти подобный заход 2) нанять кого-то, что бы сделал задание, причем большое и много — если будет мало, к суду весь чужой код выкинут и доказывай потом, что там был твой код 3) если контора станет настолько толстой, что ее будет иметь смысл доить, то, вероятно, она придет к традиционным формам найма с HR и т.п. В общем, конечно можно попытаться кого-то таким образом посудить… Ну успехов, что.
У вас отличный подход, несогласные могут быть 2 категорий: завистники, которым ограничения их проекта (иногда надуманные) не позволяют внедрить подобный метод и неумехи, «знающие себе цену» в болтологии, но не умеющие решать реальные задачи. Мои опыт показывает, что проекты, где используют подобный подход, наиболее успешны и для меня, как разработчика, там наилучшие шансы, что сотрудничество будет долгосрочным и взаимовыгодным, так что подобные работодателя автоматически попадают в список фаворитов. Так что продолжайте в том же духе и никого не слушайте :)
>но, обычно, достаточно группового чата в skype
Хистори чата вроде как не доступно свежедобавленным пользователям.
Хистори чата вроде как не доступно свежедобавленным пользователям.
Прикольно. Вместо тестового задания настоящий код, настоящая база и настоящая таска. Тогда чтоб мне быть уверенным в работодателе — давайте уж настоящую зарплату за это всё? (которая будет учитывать усилия, необходимые чтоб разобраться в куче абсолютно нового кода, который не является документированным оперсорс-проектом, а потому наверняка содержит мало комментариев ну и так далее) + риск того, что вы меня не примете (и я впустую потратил время)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
С корабля на бал