Трудоустройство: проводим интервью с работодателем

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

Мировая практика

Отличной системой оценки команды является тест Джоэла Спольски. Джоэл — разработчик с многолетним опытом и автор книг из Нью-Йорка, который выделил 12 простых вопросов, призванных помочь соискателю в подборе нового коллектива. В оригинале они выглядят так.

Стоит сказать, что тест Джоэла применяется на таком крупном портале для поиска специалистов, как careers.stackoverflow.com, и дает возможность составить представление о команде еще до начала сотрудничества.

Адаптация под украинский рынок

  1. Используете ли вы систему контроля версий?
    Если команда состоит более, чем из одного человека, отсутствие контроля версий может стать настоящим ночным кошмаром для разработчика. Попутно поинтересуйтесь, какую систему использует команда, и как выглядит система бранчей.
  2. Есть ли в вашей команде тестировщики?
    Несомненно, грамотные разработчики могут писать качественный код, но стоит признать, что для тестирования необходимы отдельные специалисты. Идеальное соотношение — один тестировщик на трех разработчиков.
  3. Исправляете ли вы найденные баги?
    Стремление создавать качественный продукт тесно связано с исправлением ошибок. Если команда этого не делает, о качестве придется забыть. Стоит обратить внимание на то, как быстро исправляются баги, и выделяется ли время на стабилизацию продукта.
  4. Есть ли у вас план работы на следующий период времени?
    Планирование так же важно, как применение практик GTD. Какой период времени расписан? Насколько детально?
  5. Есть ли у вас спецификации или документация?
    Это слабое место многих проектов. Идеи касательно работы проекта нужно обсуждать и фиксировать. В противном случае команда не будет знать свой продукт, а такую работу нельзя назвать эффективной.
  6. Какая экосистема в офисе?
    Интересно будет узнать, какая в помещении обстановка. Как работают системы кондиционирования и отопления? Уделите внимание вопросу об организации ваших рабочих мест.
  7. Сколько человек в команде?
    Полезной для оценки может оказаться информация о количестве менеджеров и лидов. Также стоит обратить внимание на наличие в команде всяческих родственников, которым легко сойдут с рук оплошности и некачественное выполнение работы.
  8. Чего вы ожидаете от нового сотрудника?
    Это один из основных вопросов. Узнайте, что нужно от вас команде. Как она формировалась? Как проходит обычный рабочий день? «Мы приходим и колбасим код» — сразу нет.
  9. Кто-нибудь видел проект, кроме девелоперов и менеджеров?
    Иногда важно знать, что думают о проекте другие люди, как они оценивают его юзабилити. Продукты, с которыми невозможно работать из-за их запутанности, никому не нужны.
  10. Вы можете собрать проект за один шаг?
    Положительный ответ будет означать стремление команды автоматизировать процесс и нежелание тратить попусту время своих специалистов.
  11. Если разработчик нуждается в платном инструменте, купите ли?
    Здесь же можно узнать о том, что компания предоставляет для работы. Дополнительный монитор идет в плюс.
  12. Смотрит ли команда на код при приеме на работу?
    Просмотр кода собеседуемого — стандартная политика, и если вас попросили дать ссылку на ваш профиль в GitHub, то это добрый знак. Проведение командой code review также идет в плюс.

Внимательный читатель может заметить, что большинство вопросов получают положительную оценку, если команда применяет техники Agile. И часто команды заверяют, что у них «всё по Аджайлу». В этой ситуации стоит попросить интервьюера описать процесс разработки, не используя этого волшебного слова, и посмотреть, насколько проект соответствует ему в действительности.

Техническая сторона собеседования

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

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

Заключение

Выводя формулу для оценки команды, можно подсчитать количество положительных ответов на вопросы Джоэла и разделить их на 10. Полученную цифру умножьте на зарплату и прибавьте по 10 баллов за плюшки типа спортзала и страховки.

Маєте важливу новину про українське ІТ? Розкажіть спільноті. Це анонімно.І підписуйтеся на Telegram-канал редакції DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



Найкращі коментарі пропустити

Вообще, вопросы, которые задают на собеседовании — страшно интересная штука. Стандарта нет вроде бы, задавай что хочешь. Есть вопросы понятные и безобидные — «расскажите про проект» или «как вы разрабатываете» — открытые неконкретные вопросы. Их почти все задают, это нормально.
Некоторые этим и ограничиваются, часто студенты-джуниоры, они боятся лишний вопрос задать, если «все нормально вроде как идет», как на экзамене. Или может просто неинтересно больше ничего (опасный знак).
Некоторые начинают задавать технологические вопросы: какая у вас архитектура, какие паттерны, как устроен CI билдов, и все такое. Вроде и вопрос задал и заодно показал, какие крутые темы знает, что ему такие штуки важны и небезразличны. Ну и иннициативу типа проявляет. Что ж, неплохо. Ему, видимо, важно, чтобы проект был технологически мощным, не хочет идти туда, где это не ценят.
Некоторые задают вопросы про бизнес: а как устроена бизнес-модель, а что за рынок, какие задачи приходится решать, как сказывается рост количества пользователей на нагрузку, какие требования к разработке? Это редко бывает, обычно у программистов, «поварившихся» в стартап-тусовках. Отлично же, если программист понимает, что он на самом деле делает. Ему, видимо, важно, чтобы продукт, который он будет разрабатывать имел будущее, рос, ставил перед командой интересные бизнес-задачи. Не хочет оказаться в «тухлой» компании, дующей в одну и ту же дудку уже 5 лет, или где никто не может внятно объяснить, что они вообще делают.
Некоторые интересуются личностями основателей, менеджеров, потенциальных коллег. Просят рассказать, кто откуда, что делал, в чем силен. Наверное, такой программист побывал уже в разных командах, и ищет себе сильную команду, где он сможет поработать вместе с интересными людьми.
А есть такие люди, которых интересуют соцпакет, количество отпускных, график работы, четкие правила, регламентирующие овертаймы, больничные, курс пересчета валюты зарплаты, наличие бассейна в оплачиваемой медстраховке. Видимо, такой программист больше всего в работе ценит социальные гарантии и соблюдение КЗоТа. И пойдет работать туда, где можно больше всего отдыхать на выходных, болеть на больничном по страховке, и вообще следить за справедливостью.

«Тесту Джоеля» в этом году будет 13 лет...

91 коментар

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Алаптация под украинских рынок?????!!!! Правильно будет «убъём последние 20% адекватных IT компаний в нашей стране». Я не имею ничего против господина Спольски, но эта методику берут на вооружения как правило узкопрофильные IT компании или подразделения обслуживающие свои консорциумы. Заметьте ни один из вопросов не анализирует потребительские цели продукта, всё что хотите экосистемы, инструменты, тайм-менеджмент, всё кроме качества и направленности на клиента. Уважаемый автор эта методика работает немного по другому))))) Ответы давать не обязательно. Представьте себе каждый вопрос, который Вы указали в статье это верхушка отдельного айсберга, из которого нужно сделать ледовую скульптуру. Это отправительные точки для анализа кандидата, но никак не готовая методика. Из-за таких вот трактовок методик наш IT рынок лишается лучших умов.((( К сожалению это не единственный случай.

P.S. Суп не приготовится быстрее и не будет вкуснее, если его всё время мешать.

Самый главный показатель для «этой страны» — пропорция дёготь/мёд. Правильный ответ — в мёде не должно быть дёгтя, и только тогда можно обсуждать его качество. Если же «ложечка дёгтя» есть — ничто другое уже неважно.

В разработке ПО цикл проходит одни и те же этапы десятки раз. Обычное наукоёмкое производство. И если есть снижение качества на любом этапе, либо излишние затраты, либо запрет на изменения — проект умирает, в худшем случае уже при эксплуатации. Если проблем в итерационном цикле нет — всё остальное построится «само».

Знаю, что нельзя так безапелляционно заявлять. Всегда есть нюансы, особенности, обстоятельства, мнения и люди — с которыми нужно считаться и которым слепо верить, проявлять лояльность, нельзя называть (нужное подчеркнуть). Вот они и формируют ложечку дёгтя.

Не так важно, каких преимуществ нет, важнее какие проблемы ЕСТЬ. По секрету: есть процессы, в которых люди согласны участвовать даже без оплаты. И даже сами доплачивать. Их всегда отличает отсутствие дёгтя в определённый период времени :)

Тест Джоеля уже старенький как свет. Все еще актуальный но не все вопросы нужно задавать от туда.

Например «Используете ли вы систему контроля версий?» Я еще не видел компанию где ее не используют. Спросив именно так можно составить о себе плохое впечатление. Лучше спрашивать. «А вы используете Git/Mercurial/TFS?», или «Вы используете DVCS?» и уточняющие вопрос. Сможете определить что используется, какие взгляды на мир, и соответствует ли это с вашими представлением.

«Исправляете ли вы найденные баги?», в такой формулировке тоже спрашивать нельзя. Опять же плохое впечатление о спросившем. Лучше о том как поставлен процесс тестирования, автоматизованные тесты и т.п.

«Какая экосистема в офисе?» — ответ будет «нормальная» и куча позитивного бреда про плюшки компании и хорошие отношение команд. Никто не будет конкретно отвечать на общие вопросы и нет смысла спрашивать о кондиционере. Просто нужно попросить познакомится с командой и показать вам офис. Аргументировать это очень просто.

«Чего вы ожидаете от нового сотрудника?» опять же нужно уточнять, например для сотрудника на позиции лид девелопер .

В общем продолжать нет смысла. Вопросы Джеоля хороши как база или отправная точка чтобы построить список своих вопросов, например для кого то важно как обстоит дело с ТДД и юнит тестированием и т.п.. Ну и перевод и формулировка. Вопросы переведены буквально. Их стоит переформулировать под себя и чтобы были понятными тому с кем вы говорите.

В общем продолжать нет смысла. Вопросы Джеоля хороши как база или отправная точка чтобы пострить список своих вопросов, например для кого то важно как обстоит дело с ТДД и юнит тестированием. Ну и перевод и формулировка. Вопросы переведены буквально. Их стоит переформулировать под себя и чтобы были понятными тому с кем вы говорите.
И статья не претендует на звание Tutorial или на How To. Это отправная точка в состовлении своих вопросов. 80% собеседующихся никак не интересуются о процессах компании, а надеятся влиться, когда уже их взяли. Т.е. выходя в первый рабочий день на работу даже приблизительно не представляют с чем нужно будет столкнуться

Ну да. Но просто русский перевод вопросов Джеоля такой же. Я например ожидал большего чем я читал в оригинальной версии или в переводе (russian.joelonsoftware.com/...heJoelTest.html)

Как было сказано ранее,

«Тесту Джоеля» в этом году будет 13 лет...
Он на год старше «Agile manifesto».

Не все уже актуально.
Например,

Есть ли в вашей команде тестировщики?
В компании Facebook нет ни одного тестировщика.

Однако, тема, в целом, бесспорно, не потеряла своей актуальности.

В фейсбуке много миллионов тестировщиков, не каждая компания может себе позволить тестировать на реальных пользователях.

В компании Facebook нет ни одного тестировщика.
Не совсем так :) Тайтла QA нет, но есть Load/Performance инженеры, SDET-ы и так далее.

Это что, шутка?

Используете ли вы систему контроля версий?
Если команда состоит более, чем из одного человека, отсутствие контроля версий может стать настоящим ночным кошмаром для разработчика. Попутно поинтересуйтесь, какую систему использует команда, и как выглядит система бранчей.
Да я даже когда один над пет-проджектом работаю, не могу без VCS. А нормальная компания просто физически не может без этого сущестсовать. Это все равно что спрашивать «Есть ли у вас в офисе электричество»?
Есть ли в вашей команде тестировщики?
— Нет, мы релизим по принципу «хренак-хренак — и в продакшн» ©
Исправляете ли вы найденные баги?
Как было правильно сказано ниже, какого ответа вы ждете: «Нет, складываем воооон в ту кучу»?

Остальные вопросы не менее бредовы и их даже лень обсуждать.

Какой вы непуганый однако:)

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

UPD.
Уточнение:

его искоренить невозможно
если он появился.
Но если проект начали разрабатывать (или на очень ранних этапах) без КуА (отдела), то качество таки лучше (как говорят, те кто так работает).
Отдел КуА — это очень серьезный баг в процессе разработки, его искоренить невозможно (я не знаю примеров).
Опять сами с собой не в ладах?
Опять сами с собой не в ладах?
Где тут противоречие?
Уточнение:
его искоренить невозможно
если он появился.

> Бывает, у нас сейчас QA — на стороне заказчика
Что бывает? Поясните.

главное, что они есть хоть в каком-то виде

Без тестировщиков качество продукта выглядит лучше ровно до тех пор, пока он не попадает в продакшн.

Без тестировщиков качество продукта выглядит лучше
Без тестировАНИЯ, тестировщики — это баг.
пока он не попадает в продакшн.
И как тестеры помогут проекту в продакшине?

Тот, кто тестирует и является тестировщиком. Лучше, если он занимается этим профессионально, а не отрываясь от разработки.
Наиболее ценна помощь тестировщиков как раз до продакшна. О чем и было сказано. Т.к. после — желающих рассказать вам о багах не на ушко и даже не через джиру, а вполне публично — найдется больше чем можно пожелать.

Тот, кто тестирует и является тестировщиком.
Ууууу.
Отдел КуА
без КуА (отдела)
Это был контекст, если че :)
Лучше, если он занимается профессионально, а не отрываясь от разработки.
А кто сказал что надо от чего-то «отрываться»? Тестирование, неотъемлемая часть часть процесса разработки, и в идеале она должна быть интегрирована как можно глубже, без выделеных частей (читай «профессиональных тестеров»). Как простой пример всякие БДД.

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

Понимаю, что Вы имеете в виду, однако ТДД и БДД
Сомнительно, ибо ТДД и БДД — принципиально отличаются в данном контексте :)
покрывают лишь часть того, что проверит хороший тестировщик.
Они покрывают спеку. Спеку «тестируют» люди которые понимают бизнесс и люди которы понимают разработку (грубо говоря БА и разработчики).
Поэтому (но не только) и используется преимущество специализации.
И какая же специализация КуА? При условии что БА и Дев делают свою работу ответственно. КуА знают бизнес лучше БА? Или КуА знают технические моменты лучше разработчиков?
Все примеры, которые мне приводили в подобных спорах, сводились к тому что КуА нашел дырку на которую забил БА или Дев, именно забил. Попытайтесь еще вы, мо получитсо.
При условии что БА и Дев делают свою работу ответственно
При условии, что мир идеален и «ответственные» разработчики никогда-никогда не допускают ошибок.))
«тестируют» люди которые понимают бизнесс и люди которы понимают разработку
Дело в том, что у Вас это разные люди. Один видит одну часть слона, другой — другую. Они протестируют, что по-отдельности все у него в порядке — и хвост, и уши. А на приемке окажется, что слон мертв, хоть и обладает требуемым набором компонентов). Тестировщик — специалист, объединяющий в себе знание разных сфер, в достаточной степени, чтобы понимать систему как она должна быть и проверять это (с позиции пользователя, например, в которую разработчику еще нужно переключиться, что психологически может быть не просто).
Тестировщик — специалист, объединяющий в себе знание разных сфер, в достаточной степени, чтобы
Фикс:
в НЕдостаточной степени, чтобы понимать
-------------------------
При условии, что мир идеален и «ответственные» разработчики никогда-никогда не допускают ошибок.))
Все примеры, которые мне приводили в подобных спорах, сводились к тому что КуА нашел дырку на которую забил БА или Дев, именно забил. Попытайтесь еще вы, мо получитсо.

Поддерживаю, ТДД не может покрыть все

Поддерживаю, ТДД не может покрыть все
Понимаю, что Вы имеете в виду, однако ТДД и БДД

Сомнительно, ибо ТДД и БДД — принципиально отличаются в данном контексте :)

— Нет, мы релизим по принципу «хренак-хренак — и в продакшн» ©
Кстати, у нас в конторе тестировщиков нет совсем — принципиальная позиция компании.

И это тоже :)

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

Лично я предпочитаю иметь бета-тестеров со сторны клиента. Находят то, что тестировщики не найдут в жизни. А многие [якобы] баги которые могли бы найти тестеры, дефакто никому не попадаются.

Единственное место, где тестировщики нужны железно — вопросы безопасности. Но как правило там их и нет...

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

У меня другой опыт. Хорошо бы иметь альфа-тестеров со стороны клиента, или своих же он-сайт. Но если их нет, внутреннее тестирование очень сложно организовать. Его должен строить учёный, а не менеджер. В реальной жизни такое можно встретить в Японии, но не у нас. И потому дешевле не иметь альфа-тестеров, а спонсировать бета-тестирование.

Я знаю мало разрабов, кто вообще имеет бета-тестеров. А значит воз и ныне там.

Вспомните, «Кто сшил этот костюм?»

по всем пунктам — всякое бывает ;)

Вообще, вопросы, которые задают на собеседовании — страшно интересная штука. Стандарта нет вроде бы, задавай что хочешь. Есть вопросы понятные и безобидные — «расскажите про проект» или «как вы разрабатываете» — открытые неконкретные вопросы. Их почти все задают, это нормально.
Некоторые этим и ограничиваются, часто студенты-джуниоры, они боятся лишний вопрос задать, если «все нормально вроде как идет», как на экзамене. Или может просто неинтересно больше ничего (опасный знак).
Некоторые начинают задавать технологические вопросы: какая у вас архитектура, какие паттерны, как устроен CI билдов, и все такое. Вроде и вопрос задал и заодно показал, какие крутые темы знает, что ему такие штуки важны и небезразличны. Ну и иннициативу типа проявляет. Что ж, неплохо. Ему, видимо, важно, чтобы проект был технологически мощным, не хочет идти туда, где это не ценят.
Некоторые задают вопросы про бизнес: а как устроена бизнес-модель, а что за рынок, какие задачи приходится решать, как сказывается рост количества пользователей на нагрузку, какие требования к разработке? Это редко бывает, обычно у программистов, «поварившихся» в стартап-тусовках. Отлично же, если программист понимает, что он на самом деле делает. Ему, видимо, важно, чтобы продукт, который он будет разрабатывать имел будущее, рос, ставил перед командой интересные бизнес-задачи. Не хочет оказаться в «тухлой» компании, дующей в одну и ту же дудку уже 5 лет, или где никто не может внятно объяснить, что они вообще делают.
Некоторые интересуются личностями основателей, менеджеров, потенциальных коллег. Просят рассказать, кто откуда, что делал, в чем силен. Наверное, такой программист побывал уже в разных командах, и ищет себе сильную команду, где он сможет поработать вместе с интересными людьми.
А есть такие люди, которых интересуют соцпакет, количество отпускных, график работы, четкие правила, регламентирующие овертаймы, больничные, курс пересчета валюты зарплаты, наличие бассейна в оплачиваемой медстраховке. Видимо, такой программист больше всего в работе ценит социальные гарантии и соблюдение КЗоТа. И пойдет работать туда, где можно больше всего отдыхать на выходных, болеть на больничном по страховке, и вообще следить за справедливостью.

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

Во-первых Леша в Берлине, а во-вторых в Киеве тоже полно не-аутсорсинга. Пруфлинк: djinni.co/l/startups (да, опять джинни)

Пожди, когда мне потребуется команда, я смогу нахаляву потереть лампу?

А есть такие люди, которых интересуют соцпакет, количество отпускных, график работы, четкие правила, регламентирующие овертаймы, больничные, курс пересчета валюты зарплаты, наличие бассейна в оплачиваемой медстраховке. Видимо, такой программист больше всего в работе ценит социальные гарантии и соблюдение КЗоТа. И пойдет работать туда, все можно больше всего отдыхать на выходных, болеть на больничном по страховке, и вообще следить за справедливостью.
Это в самую точку.
часто студенты-джуниоры, они боятся лишний вопрос задать, если “все нормально вроде как идет”, как на экзамене. Или может просто неинтересно больше ничего (опасный знак).
Я на співбесіді задаю лише ті питання, які можуть вплинути на моє рішення працювати в даній компанії, а оскільки я згоден працювати в будьякій компанії, яка погодиться мене прийняти (це головний і обов’язковий критерій), то питань я не задаю.

Самые важные вопросы, кроме размера зарплаты, сути проекта и должности:

1. Удобство «окружения»:
* Покажите рабочее место.
* Время прихода на работу
* Возможность работы из дома (когда хочешь/никогда/иногда/в исключительных случаях)

2. Деньги и соцпакет
* Когда, каким образом и в какой валюте платится/считается зарплата
* Отпуск
* Больничные

3. О проекте:
* Какая на проекте текучка.
* Сколько лет проекту? На какой он стадии?
* Где находятся люди, которые принимают технические решения по проекту?
* Где находится самый младший менеджер (иными словами, есть ли на месте кто-либо кроме программистов)?
* Овертаймы, как часто бывают, какой подход к оплате (наилучший ответ здесь: они бывают редко и как-то даже и не задумывались о формализации сего действа)

Тест Джоэля сейчас уже не очень актуален, тем более в таком виде. Самый яркий пример — вопрос про систему контроля версий: врядли остались места где ее не используют.
Что касается остального, то «правильный по Джоэлю» проект — не значит успешный и не значит тот, где приятно работать. Были в моей практике команды, которые ввиду отсутствия грамотного менеджмента и обилия «программистов от блога» так увлекались «правильностью», что забывали о своей основной задаче — делать продукт. А были и небольшие квалифицированные команды, которые благодаря размеру и квалификации могли безнаказанно много чего игнорировать.

От это уже ближе к реальности.

Relocation package при переезде не забудьте.

Кроме проекта вполне можно спросить «чем ещё занимается компания»? Потому что бывает, что через пару-тройку месяцев тебе светит совсем не то, о чем была речь на собеседовании. И лучше знать, что вообще есть ещё.

Ну и технологии проекта/проектов лучше узнать сходу — согласитесь, если вас склоняют, скажем, к Джумле или Друпалу на ближайшие год-полтора, а вам они категорически не любы, лучше этот момент уточнить заранее, дабы потом не огорчать друг друга.

Далеко не всегда. Особенно огорчает, когда «нормальная компания» подразумевает даже работу на компьютерах трех- и более -летней новизны.

Пункт 3 заслуживает особого внимания.

господа — вопрос — в какой валюте расчет — это кагбы фейспалм:)

Не хочется тыкать пальцами, но в одном из наших лидеров рынка на полном серьезе предлагают платить зарплату в гривнах считая пол зарплаты в долларах по НБУ и половину по какому-то хитрорасчитанному курсу через евро.
Не хочется тыкать пальцами, но в другом нашем лидере рынка в период предыдущего «большого скачка» курс некоторое время попросту фиксировали.

Не хочется тыкать пальцами, но в одном из наших лидеров рынка на полном серьезе предлагают платить зарплату в гривнах считая пол зарплаты в долларах по НБУ и половину по какому-то хитрорасчитанному курсу через евро.
Это считается плохо?

Ох и хитер же крестьянин нынче! Мультивалютная диверсифицированная корзина — даже обсуждать не будем, просто пальцем у виска покрутим. Зачем аргументация — и так понятно, намахать хотят. Только доллар, только хардкор.

Это не мультивалютная корзина, а перекладывание валютных рисков работодателя на работника

Интересно, какая же у работника менее рисковая альтернатива? Фиксация в одной валюте? Не в гривне ли?

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

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

Интересно, где это рассчитываются долларами?
Заключают договор СПД с материнской компанией в США?

ЗП вы же вероятно в долларах оговариваете

Интересно, где это рассчитываются долларами?
Опять таки, не буду тыкать пальцами, но такое бывает. Как по мне один из самых удобных вариантов (хотя бы тем что гарантирована защита от поползновений в сторону пересчета через евро или фиксированного курса или НБУ и т. д.)
Заключают договор СПД с материнской компанией в США?
Да, именно так

Кстати, именно так, например. И не обязательно в США.

Любая поппытка работодателя кинуть по оплате — ему выходит дороже, со средним коэффициентом 6x-8x.
Всё равно что в хлеб сэкономить дрожжи (типа подорожали), а потом выбросить хлеб (якобы мука плохая), затем купить муку подороже (существенно) и опять... сэкономить дрожжи. Примерно так работает Укртелеком :)

Тем не менее. Бывают «хитрые фирмы», у которых «своя валюта». Или «свой курс» (я в такую чуть не пошел работать, кстати).

Ну и, вероятно 1000 USD выглядят неплохо, но 1000 EUR выглядят на их фоне даже привлекательнее, а ещё возможны 1000 GBP, например.

Я в такой в свое время проработал, топовая не ИТшная украинская компания. После кризиса 2008 года у них доллар для оплаты з.п. всегда был 6.15.
То есть у тебя з.п. 900уе, а получаешь 900*6.15/8 = 691 уе.

В центральном офисе в Киеве мы ( менеджеры ) на одном их тренингов предлагали компании продать нам доллар по такому курсу в неограниченных обьемах, на это все пришел начальник отдела кадров и как началось: какие мы все-таки крутые, но не можем себе позволить лишнего и прочую столичную блаблабла.

Вот такое самодурство иногда бывает

Да-да-да, мне предлагали работать на адекватную з/п тогда же (начало 2009), но с курсом 6.5 — 6.7. «Вы же понимаете, кризис пройдет и курсы вернутся к исходным значениям». Ага. У фирмы программерский отдел ориентирован на забугорный аутсорс (валютная выручка) и отдел «электронщиков» — на местный рынок (выручка в гривне). Я их могу понять, но у меня свои проблемы. Правда, в итоге пришлось тогда упасть по з.п., но хоть с честным курсом.

Есть знакомый, работавший в средней руки полухайтеке, ориентированном на СНГ — там тоже «внутренний доллар».

Лично у меня, как у многих СПД-контракторов, курс привязан к межбанку. Иногда, когда валюта нужна (турпоездки), а курс в стране штормит, немного напрягает отрыв рыночного в обменках от межбанка, но, в целом, к счастью, довольно близко.

Вобще-то оригинальная статья оченб хорошая, существует хорошо известный русский перевод: russian.joelonsoftware.com/...heJoelTest.html
(и стоит ли делать из ее такую выжимку — неочевидно.)

На момент написания статьи не знал о переводе. Статья имеет вводных характер, чтобы указать вектор куда копать и заставить разработчиков проявлять хоть какой-то интерес на собеседовании

Интерес в смысле много вопросов — кстати не обязательно. Бывало у меня такое что мне рассказали о проекте, показали команду и офис, рассказали столько всего. Просто уйма информации. После этого все эти вопросы отваливаются сами собой. Часто работодатели не проходят вопроса «А покупаете ли вы самые лучшие тулы для своих разработчиков?» тут многие подразумевают решарпер. Если это самый большой баг работодателя то я могу лицензию и сам купить.

Идеальное соотношение — один тестировщик на трех разработчиков.
Там где 1 там и 3.
Исправляете ли вы найденные баги?
пол просто лол
Какой ответ вы ожидаете? «Складываем вон в ту кучу» :)
Кто-нибудь видел проект, кроме девелоперов и менеджеров?
Ну видел. И шо? Исходный вариант как-то лучше «Do you do hallway usability testing? »
Просмотр кода собеседуемого — стандартная политика
Где?
и если вас попросили дать ссылку на ваш профиль в GitHub, то это добрый знак
Просто интересно, я один понимаю что опенсорс-проекты, проекты в гитхабе и коммерчиская разработка — отличаются принципиально?
По вопросам, которые задают на технической части, легко определить, чего команда ожидает от соискателя.
Ну да конечно. Простой пример: каждый джава программист, постоянно использует вик- и софт- референсы (в своем коде).
Адаптация под украинский рынок
Оригинал лучше.
Какой ответ вы ожидаете? «Складываем вон в ту кучу» :)
Сдали продукт и в кусты
Где?
В годных компаниях
Просто интересно, я один понимаю что опенсорс-проекты, проекты в гитхабе и коммерчиская разработка — отличаются принципиально?
Нет, но на стиль программиста можно взглянуть, чем увлекается, чем интересуется
Сдали продукт и в кусты
1) Продукт никому не надо. Нах фиксить баги?
2) Продукт успешный. Тогда фиксить баги прийдетсо.
В годных компаниях
Таких как ... Вот обсуждение dou.ua/...ums/topic/6983
Нет, но на стиль программиста можно взглянуть, чем увлекается, чем интересуется
Ну увлекается хаскеллем и лиспом, а надо говнять КРУД. И какие выводы вы можете сделать с гитхаба?
2) Продукт успешный. Тогда фиксить баги прийдетсо.
Не обязательно, бывает давайте добавим еще этих крутых фич и забьем на эксепшены
Таких как ... Вот обсуждение dou.ua/....ums/topic/6983
Меня спрашивают или я сам предлагаю посмотреть
Ну увлекается хаскеллем и лиспом, а надо говнять КРУД. И какие выводы вы можете сделать с гитхаба?
О том, что собеседуемый не хочет заниматься тем, чем вы ему предлагаете
О том, что собеседуемый не хочет заниматься тем, чем вы ему предлагаете
Фантазии. И то не верные, более корректно: собеседуемому интересен (возможно) другой род занятий, но это не говорит что он не хочет заниматся тем что вы предложили (он, кстати, зачем-то пришел к вам на собеседование) и даже не говорит что ему это неинтересно.
Не обязательно, бывает давайте добавим еще этих крутых фич и забьем на эксепшены
Если так стоит вопрос, то
1) Продукт никому не надо. Нах фиксить баги?
Бывает что эффективние забить на баг в пользу фичи. Но это никак не влияет на ответ на
Исправляете ли вы найденные баги?
---------------
Меня спрашивают или я сам предлагаю посмотреть
Не понял. Перечислите пожалуйста «годные компании», стандартная политика.
1) Продукт никому не надо. Нах фиксить баги?
2) Продукт успешный. Тогда фиксить баги прийдетсо.

В любом продукте есть баги, которые нужно как можно скорее пофиксить и баги, которые можно отложить в долгий ящик

В любом продукте есть баги, которые нужно как можно скорее пофиксить и баги, которые можно отложить в долгий ящик
И как это факт влияет на ответ на вопрос:
Исправляете ли вы найденные баги?
Зачем такой вопрос задавать?

Богдан, вот я вас читаю читаю... скажите, сколько раз вы были на собеседованиях и когда в последний раз?

сколько раз вы были на собеседованиях и когда в последний раз?
Надо обяснять почему этот вопрос не корректный?

Если вы не можете ответить на вопрос, то можно вообще больше ничего не объяснять .

можно вообще больше ничего не объяснять .
Доверюсь вашей фантазии :)

Всё равно пытаетесь объяснять, хотя ответить на мой тривиальный вопрос так и не смогли :)

Если уж, кстати, «тряхнуть Джоелем», то я бы лучше порекомендовал вот эту статью — «Абсолютный Минимум, который Каждый Разработчик Программного Обеспечения Обязательно Должен Знать о Unicode и Наборах Символов» (local.joelonsoftware.com/...аборах_Символов)

Куда полезнее, а то фиг кто на собеседовании может сказать, сколько байт занимает символ в UTF-8. Все вроде пользуются, а сути никто не понимает.

Я бы добавил:
1. Пишут ли разработчики Unit\Regression тесты.
2. Пркактикуется ли XP, например pair programming, peer review.
3. Выделяется ли сотрудникам время на open source, есть ли продукты компании отданые в open-source.
4. Разрешает ли компания работать из дома.
5. Сколько дней отпуска? Есть ли мед. страховка?
6. По какому рейту оплачивается overtime?
7. 501manifesto.org или programming-motherfucker.com ?
8. Оплачивает ли компания расходы на конференции.

Ещё хорошим показателем является количество\качество мониторов и мебели.

Все звучит отлично, только я бы переформулировал несколько вопросов:

3. Выделяется ли у Вас в планах отдельное время на исправление багов?
Т.к. и так понятно, что баги кто-то фиксит, другое дело выделенно на это время, или придется сидеть на работе до ночи, перед очередным апдейтом.

6. Не могли бы Вы показать мне рабочее место, где мне возможно придется работать?
Т.к. всегда лучше все самому увидеть и оценить.

9. Как часто Вы выкатываете билды?
Т.к. специфика нашего рынка такова, что и так заказчики постоянно мониторят процессы, другой вопрос — на сколько часто?

Исправление багов — львиная доля работы. Я одного понять не могу — исправление бага занимает от 5-10 минут (если проект сейчас в работе) до 1 часа если в стабильной эксплутатации (но окончен менее полугода назад). Поддержка существующего бага стоит куда дороже. Спросите у тех.поддержки, чем они занимаются — будете удивлены.

О рабочем месте лучше говорить когда УЖЕ получили согласие. Причина — рекрутер подержав в руках бонус, не захочет его отдавать. И поможет поторговаться за рабочее место. А торг уместен!

Как часто делать билды — не имеет значения. Асболютно никакого! Новый проект может просуществовать полгода без единого билда, новая фича — пару месяцев. А после каждого выставления следует некислая волна исправленых билдов. И горе вам, если этой волны нет [сознательно гасится], или есть запрет на правку версии с ярлычком «Final retail».

Билд человека занимает 9 месяцев, после чего несколько лет настройки и подгонки. А курица сначала выдаёт билд, после чего тратит некисло времени на его высиживание, а финальная версия в доработке уже не нуждается. Жизненный цикл — разный! И горе тому, кто попытается его править «по образу и подобию» чужого успеха (баловать ребёнка, или обучать курицу).

«Тесту Джоеля» в этом году будет 13 лет...

Підписатись на коментарі