В последнее время на меня свалилась радость поиска программистов в нашу небольшую команду. Начинают приходить резюме, делают тестовое задание, общаются… иногда бывает хорошо, чаще плохо.
Собрал пару советов тем, кто собирается сменить работу или искать новую.
Приведите в порядок ваше резюме
Обязательно должно быть в резюме:
- ваши контакты
- ваше место проживания
- ссылки на код (например, Github с открытыми проектами)
- где работали, какие задачи выполняли, какие технологии использовали для этих задач
- образование (важно, если это нужно для получения визы)
Часто бывает так, что времени на вклад в open-source, домашние проекты или какой-то интересный код, который можно было бы оставить в Github как пример, нет. Тогда на Github можно выложить тестовые задания, которые вы уже сделали. Конечно, уточните у компании, можно ли будет выложить код в открытый доступ, перед тем, как открывать код. Как правило, компаниям без разницы, и можно смело это делать. Если компания будет против, я бы подумал дважды, прежде чем туда идти.
Тестовое задание
Я не люблю делать тестовые задания, чаще всего это однотипные 2–5 часовые приложения, которые будут выброшены на свалку. Поэтому лучше иметь код, который можно показать заранее, тем самым исключив тестовое задание.
Тестовое задание стоит выполнять так, как будто это лучший код в вашей жизни. Причем такой код вы пишите каждый день. Не нужно делать тестовое задание просто, чтобы отстали, не тратьте своё и чужое время.
При выполнении тестового задания обратите внимание на:
- стиль кода (для всех языков есть code style, есть linter практически для всего)
- инструменты/библиотеки, которые используете, нужна ли каждая библиотека в проекте?
- организация кода (какой код идет в 1 git commit)
- commit message в git
- тесты
Цель тестового задания — узнать, как вы пишите код и как вы его организуете. Никогда бы не подумал, что кто-то может элементарно не следить за стилем кода, пока не увидел это в живую.
В компаниях, которые не ценят эти пункты, я бы не стал работать.
Собеседование
Обычно собеседование строится по принципу: работодатель хочет узнать, что вы можете сделать, вы узнаете у работодателя, как и что вы будете делать. Работодателю нужно ваше CV, чтобы можно было предметно говорить про ваш опыт. Тестовое задание тоже будет использоваться при разговоре, всегда интересно узнать у потенциального работника, как он делал и почему принял такие решения, а не другие.
Cоветую записать все интересующие вас вопросы про рабочее место: где находится офис, как добираться, какие условия труда (обидно приехать на работу, а там старый ПК) и так далее. И пройтись по вопросам, отмечая у себя, что понравилось, что нет. Собеседование — это процесс оценки 2х сторон, не только вас. Вы точно будете нервничать, запишите вопросы, по себе знаю.
Сроки, ответы, молчание
Сроки — одна из слабых сторон программистов. Когда выполняете тестовое задание, давайте реальные сроки, а не те, которые вы думаете (например: вы думаете * 2). Если не будет хватать времени, может случиться что-то непредвиденное, сразу сообщите о сдвиге сроков. Не надо тянуть резину.
Посмотрели тестовое задание и решили не делать его? Напишите, что вы передумали. Не тяните резину и не тратьте время.
Часто бывает, что недобросовестные HR’ы и/или компании не отвечают и просто пропадают. Не думайте, что они козлы и специально молчат, бывает большой поток людей, могут перепутать что-то и не отправить письмо. Напишите через неделю-две и спросите, что с вашей заявкой. В 99% вам ответят. Если не ответят, я бы не хотел идти в такую компанию.
Книги
Хочу посоветовать 2 книги, которые позволили мне взглянуть на “карьеру” программиста с другой стороны:
- “Программист-фанатик”, Чед Фаулер
- “Жизнь как стартап. Строй карьеру по законам Кремниевой долины”, Рид Хоффман, Бен Касноча
Резюме
- Экспорт из linkedin/headhunder — тревожный звоночек (может означать, что кандидат просто решил пособеседоваться, не вложив в это ни минуты подготовки, etc.) . Это должная быть аккуратно сверстанная pdf или google doc
- на примере iOS: не стоит писать под каждым проектом базворды типа ARC, CoreData или ReactiveCocoa. Если слово часто мелькает, интервьюер может предположить что вы глубоко знакомы с технологией и будет спрашивать соответственно
- никогда, никогда не пишите в резюме вещи, о которых вы имеете очень поверхностное представление. Пример: несколько кандидатов с “strong architecture skills” не знали, что такое SOLID (не могли расшифровать акроним)
Тестовое задание
- код тестового задания всегда должен выглядеть лучше, чем в продакшене (мы все программисты и знаем, что менеджер не разрешает вам писать тесты и делать красиво, так вот в тестовом можно и нужно делать красиво, на всех уровнях).
- если у вас возникают вопросы по тестовому заданию — не уточняйте, делайте так, как считаете нужным. Вы (как правило) идете на позицию middle / senior, а это человек, который может и должен анализировать существующий контекст и принимать решения. Важно: все ваши assumptions нужно детально описать в приложенном README. Не устно на следующем этапе собеседования (его может не быть) и не в письме через HR (он может не полностью его перенаправить). README. Рядом с вашим кодом.
- если на задание отводится 5 часов, а вы сделали его за 2: у вас обязательно должен возникнуть вопрос “где подвох?”. Оставшиеся 3 часа можно всегда найти куда инвестировать — напишите тесты, обработайте ВСЕ ошибки и т. д.
Источник: medium.com
Спасибо за прочтение! Подписывайтесь и ставьте лайк. Этим Вы очень поможете в развитии блога!
