Комментарии 30
В статье несколько раз упоминается проверка кандидатов «безопасниками». Мне интересно, что может проверять аудит безопасности частной компании в отношении программистов? Не сидели ли за тяжкие преступления? Не участвовали ли в акциях протеста? Просто непонятно, откуда такой акцент на проверку «безопасниками» категории населения, которая, в принципе, редко занимается чем-то криминальным.
Уголовные и административные наказания, причины ухода с предыдущих мест работы и пр.
Интересное перечисление…
Насчет причин ухода с предыдущих мест работы согласен, но это же может сделать и HR по своим каналам. И, возможно, даже быстрее и эффективнее. Насчет уголовных преступлений… Вы серьезно думаете, что существует так много программистов с уголовным прошлым, что стоит ради них держать целый отдел безопасности? Насчет административных правонарушений… Думаю, «административка» в отношении работников IT-сферы будет касаться превышения скорости, нарушений правил парковки и прочих малозначимых для IT-компании вещей. Ради проверки этих фактов опять-таки, по моему мнению, не стоит держать целый отдел безопасности.
Только если всплывет, что вы не взяли человека из-за судимости, которая погашена, вам влетит. У нас конечно не Европа, но прециденты судебных разбирательств были, поэтому говорить о таких вещах на Хабре не самая умная идея.
а вот не признаются безопасники, на что и как они проверяют кандидата(( говорят, мы к вам в работу не лезем и вы к нам тоже не лезьте. а если твой подчиненный займется промышленным шпионажем или начнет обмазывать фекалиями стенки туалета в офисе (реальная история), то разгребать придется не только уборщице
Насколько помню — Техносерв активно работает на госсектор. Лет десять назад — всех разработчиков поголовно проверяли на полиграфе, а рабочие помещения батюшка освящал :)
«Тестами покрываем сами, но тестирование фич типа где и что в интерфейсах отдаём наружу.»
Можно подробнее описать процесс тестирования?
Можно подробнее описать процесс тестирования?
hosher, процесс такой: пишем автотесты, когда все тесты проходят, разворачиваем новую версию на тестовом стенде. Там уже новые «фичи» тестирует вручную аналитик, а бизнес-заказчики вносят дополнения. Перед релизом новую версию всегда проверяет служба эксплуатации.
Там уже новые «фичи» тестирует вручную аналитик— тестировщики-то у вас есть? Если да — то как разделяете: что именно должен тестировать аналитик, а что тестировщики? Если нет — то по какой причине?
Тестировщиков у нас нет, в этой роли попеременно выступают разработчик фронта, тимлид (Петр), аналитик и коллеги из службы эксплуатации. Аналитик делает первичную приемку по use-кейсам, которые он для нас разработал, после него или вместе с ним бизнес-заказчики тестируют то, что поменялось. Еще мы запускаем selenium-тесты интерфейса основных сценариев.
Поэтому пока все эти специалисты тестируют, разработчики получают от мониторинга «алерты» и логи ошибок (от фронта и от бекенда), и видят, «падает» что-то или нет, даже если это незаметно для тестирующих
Поэтому пока все эти специалисты тестируют, разработчики получают от мониторинга «алерты» и логи ошибок (от фронта и от бекенда), и видят, «падает» что-то или нет, даже если это незаметно для тестирующих
Добротная обзорная статья, особо без деталей, но все же, правильная.
А это, наверное, самый интересный вопрос на собеседованиях.
Ещё спрашивал, какая была самая сложная задача, как решал, с чем приходилось сталкиваться. Во-первых, интересно, какие хоть у настоящих профессионалов задачи бывают, и потом интересно посмотреть — человеку самому-то это все интересно или как-то уже не очень.
А это, наверное, самый интересный вопрос на собеседованиях.
Вот вы так все расписали хорошо. Так все у вас проверяется тщательно. Захотел зайти на главную вашего сайта и прямо расстроился…
Картинка не грузится
Что я дал HR:
Стек: Уверенное владение javascript (vanillaJS) и HTML5\CSS3, понимание базовых принципов UX или желание их изучить, способность запилить кроссбраузерное решение, MobileFirst, Responsive design...
Вот прямо такими словами и дали? А они знают все эти слова?
ко мне как-то приходили с описанием вакансии:
орфография оригинала сохранена :)
Design Patterns — singltone, chain of responsebility, factoty, facade, circuit bracker и future and promises, etc
орфография оригинала сохранена :)
Да, прям так и дали. Да, понимали почти всё — задавали уточняющие вопросы, где неясно. Судя по подобранным резюме, всё поняли хорошо: по фронтендщикам совершенно левых резюме не было. А сами кандидаты всё понимали, мы проверили.
Можете привести размер зарплаты для ваших вакансий и город.
Что то за большие требования наверное из за переизбытка разработчиков можно ставить космическую планку, какую зарплату предлагали кандидатам?
спасибо за интересную статью. В процессе прочтения я проникся азартом организаторского духа тимлида, который собирает всех вместе, налаживает сотрудничество и при этом с уверенностью ведёт команду к цели.
в статье озвучен интересный вопрос — как нам сделать вот такой набор фич, чтобы потом на поддержке не погибнуть? Я добавил его 4-м в коллекцию своих вопросов:
- как нам организовать наше дело так, что-бы его результаты были не хуже планов, ожиданий?
- для лидов/менеджеров — что можно сделать в текущей ситуации, что-бы приблизиться к релизу проекта?
- для девов — как реализовать запрошенное, выполнить поставленную техническую задачу?
Любого кандидата когда проверяют, это норма, я считаю.
В статьях вроде "Быть %должность% — это..." интересны цифры по распределению времени — на оперативные, стратегические задачи, пятое, десятое. Даёт неплохое представление о трудовых реалиях.
С другой стороны — хотелось бы понять, например. Вот продажник — это драйв, энергия, азарт! А Тимлид? Это больше про лидерство или системность? Про взвешенные решения или грамотно выстроенные коммуникации? Больше абстрактных материй, в общем. Спасибо!
Тимлид это вообще одна только голая системность. В смысле, способность справляться со сложностями, которые все время экспоненциально растут. Когда ты программист, ты пишешь код, когда ты тимлид, приходится подбирать людей, смиряться с разными способами мышления, выстраивать коммуникацию внутри команды, параллельно «обрастая» трекерами, вики, досками и CI. Если это не драйв, то что же тогда? Вообще, спасибо вам за хорошую мысль! Чуть позже мы соберем побольше материала и постараемся рассказать обо всех трудовых реалиях в предложенном разрезе.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как быть тимлидом — моя версия