Комментарии 225
Ещё спрашивали, какая сейчас самая мощная видеокарта. Я тогда хотел админом временно устроиться в сеть кофеен — ОЧЕНЬ ВАЖНО знать название самой мощной видеокарты, ценой в половину месячног ооборота этих кофеен. Снихсодительно рпиняли, но я отказался у них работать. После подобных вопросов лучше разворачиваться и скорее бежать подальше.
Плюс пост можно расшарить пост в ВК или скинуть ссылку знакомым, чтобы поднять общую планку наших HR-ов ;-)
К тому же нельзя недооценивать непонимание многими людьми прописных истин. Что очевидно для разработчиков далеко не всегда очевидно для менеджеров или кадровиков.
Технические специалисты тоже тупые вопросы задают, как раз как автор писал, ньюансы, которые не используются никогда или несущественны. Например, «что будет, если в PHP обьявить функцию внутри другой функции». Не могу даже представить, где такое можно использовать.
А вообще тема непрофессионализма HR-ов в последнее время становится все актуальное, в последний месяц вижу много постов и тут, и на доу, и в линкедине, но их это ничему не учит.
А выдернуть какие то написанные модули, оформить и залить код в свой гитхаб не всегда время есть.
Но как вариант можно попросить перед собеседованием накидать пару модульков, которые что то делают и обсудить этот код. Главное не переборщить, типа — напишите нам CRM систему с блокчейном и ML, а мы подумаем собеседовать Вас или нет.
Проблема в том, что не всегда можно показывать код с предыдущих проектов. Конфиденциальность, все дела.
Я всегда считаю, что это отмазка. У программиста не может не быть возможности показать код. Не нужно гитхабов, я прошу просто один файлик, даже одной функции достаточно. И, да, тестовое задание обычно предлагается, но не все готовы его выполнять. А если человек не готов делать ни то, ни другое — тут медицина, как говорится, бессильна. Но лично я считаю глупостью выполнять тестовое задание, если у меня куча написанного кода, который можно просто показать. К тому же ни одна компания из тех, с которыми я имел дело, так кропотливо не проверяет и не анализирует тестовые задания, как это делаю я, поэтому смысла не вижу тратить время.
Но как вариант можно попросить перед собеседованием накидать пару модульков, которые что то делают и обсудить этот код.
Да, я так делал. Но обычно половина программистов из тех, которые не могут писать код, легко отвечают на такие вопросы (теоретики), а половина из тех, которые реально успешно работают, не могут, например, потому что волнуются. А когда человек комментирует свой код, он точно про него все знает. Тут важно в первую очередь понять, его ли это код (бывали и такие случаи).
Тут важно в первую очеред понять, его ли это код (бывали и такие случаи).
Ели он чужой код может адекватно прокомментировать, есть ли разница его ли это код?
Проблема не в копировании со stackoverflow, а в понимании как скопированный код работает. Если понимает и умеет применять, то пусть копирует.
Увы, я порой не могу вспомнить как работает то, что писалось еще позавчера — работать мне не мешает это, задачи выполняю.
Объяснить не очень могу, если «логика» с «изюмом»… но обычно только такие задачи и приходится решать.
P.S. Вот нет в webDriver какого-то функционала… и тут приходится уже и сам «драйвер» патчить/кастомить — да я такое никогда потом толком не смогу объяснить.
Поддерживать != помнить «как и что работает».
Если вы не понимаете таких прописных истин — о чем вести диалог то?
У человека есть ресурс «оперативной памяти» — вместо забивания своего кэша ненужным хламом предпочитаю хорошо понимать то, чем занимаюсь в данный момент. Это на тяжелых задачах требует колоссального внимания и концентрации.
— Тот, который «написать и забыть» т.к. это прямое его назначение (ну там фикс чего-то мало-значительного в SCSS, либо прикрутить календарь bootstrap-compatibility)… такое при всем желании даже не смогу «ни вспомнить, ни описать нюансы». Лишь знаю, что такое делать приходится.
— Тот, который трогается очень медленно, больно, в нем нет unit-tests ибо ковыряния — это реверс-инжиниринг… в таких местах всегда любое изменение «потом» будет требовать самого тщятельного рассмотрения со всех сторон (мы ведь не хотим решения «тяп-ляп, у себя починили, у остальных сломали»?). Такое и не показать (ибо пол проекта тащить надо — задача сугубо прикладная, в «контексте»), и не объяснить человеку со стороны. Скажем даже если будем обсуждать мои правки webDriver, вы, как человек вне «темы» ничего не поймете.
— Что-то, что относительно автономно, изолированно. К таким задачам я делаю отдельные микро-репозитории с кодом «только по задаче» и пишу README.MD
Так вот, если будет по задаче нужно разобраться в модуле/подсистеме/проекте — я сяду и разберусь. Смогу ли я объяснить? Это зависит от собеседника. Т.е. №2 — под вопросом. №1 просто отпадает автоматом (но я могу в целом поговорить абстрактно о подобном, без перехода к тому, что делал конкретно в том случае)
№3 обсудить всегда смогу — ман самописный прочесть я способен, быстро вникнуть и понять так же.
При этом, если речь идет о собеседовании, то это тоже как бы «задача» (найти работу/проект) — значит даже на №2 можно и поговорить, но нужен глубоко понимающий нюансы собеседник + мне надо конкретно знать, что стоит в голове себе же освежить (иначе не отвечу почему «тут идет переписывание функционала библиотеки»).
И да, я от тестового задания как раз таки не отказываюсь.
Выводы? На мой взгляд они такие — у вас, исходя из нашего диалога, весьма резкое суждение по малому набору критериев и поспешные выводы.
P.S. Я в жизни не знаю людей, что пишут на связке Java+PHP+JS с тонной обвеса (всевозможные системы сборок, фреймворки, библиотеки, суб-задачи) и еще при этом помнят «что писали вчера». Тут не свихнуться бы.
Проблема не в копировании со stackoverflow, а в понимании как скопированный код работает. Если понимает и умеет применять, то пусть копирует.Вот уже не первый раз читаю такие комментарии, и я не могу представить, как можно не понимать как какой-то код работает. Ну т.е. да, можно не знать какую-то библиотеку или фреймворк на основе которого написан этот код, но можно просто посидеть, поразбираться и понять, что тут происходит.
Ну а если уж в данном участке используется какая-то ну суперзапутанная логика, с которой очень долго разбираться, ну так мы же говорим про код для собеседования, ну ненужно копировать такие сложные куски.
Просто они достаточно сложные чтобы через пол-года после написания помнить детали логики. А читается такой код плохо.
Пример — реализация универсального логирования на С++. Сложность в большом количестве интерфейсов внутри и хитрой логике добавления информации, вплоть до трассировки стека для фаталов.
Другой пример — реализация на С++ максимально совместимого с QT функционала сигнал/слот (была задача с минимальным вмешательством в код позволить механизму сигнал/слот работать как с использованием QT (когда есть UI), так и на чистых C++ (в качестве библиотеки) без использования внешних препроцессоров и кодогенераторов). Сложность в большой вложенности вариативных шаблонов (variadic templates)
P.S. Только не стоит говорить что такой код нельзя использовать в продакшн :).
Проблема в том, что не всегда можно показывать код с предыдущих проектов.
Когда устраивался на первую работу, принес дискету со своими программами, написанными в студенчестве, они её скопировали и взяли 3 дня на изучение. Судя по тому, что меня приняли, код им понравился. Я ещё в школьные годы писал 2D-игры just for fun.
Если у программиста нет своих программ, это значит, что он не увлечен всерьез программированием, такого рискованно брать — скорей всего, он будет работать безынициативно и с малой мотивацией.
И да, я был не против, если там будут только зубы, а не мои паспортные данные.
Так что попробовав «довести ситуацию до абсурда» вы, вместо этого, показали что FadeToBlack действует правильно и грамотно.
Когда не перерабатываю, я человек семейный и мне надо уделить время семье + домашние дела, что-то прибить, что-то поменять. Да и отдохнуть хочется. И в таком режиме я уделяю 1 час в день на изучение новых инструментов, погружение и расширение знаний по уже изученным технологиям.
Это я к тому, что я предпочитаю развивать после работы, а не писать код для собеседований. А код, который я когда-то писал 2-3 года назад, стыдно показать :)
Но соглашусь с вами, когда я буду искать новую работу, тогда да, я сяду и напишу код, который будет отражать мои реальные знания на данный момент.
У меня просто свой список технологий, которыми я должен овладеть и подтянуть. Как-то только этот список иссякнет, тогда уже в качестве закрепления изученного, буду писать небольшие проекты. И тогда буду их сохранять, чтобы можно было показать.
По NDA я не могу показать то, что делаю по работе.
А то, что я пишу сам для себя дома — совсем далеко от типичных вакансий.
— позиция по PL/SQL
— а код внерабочее время написан на C++? (или вовсе на экзотическом языке)
Как вы не ответили как по коду на C++ сможете оценить способности по написанию кода на PL/SQL?
habr.com/post/424569/#comment_19169069
FadeToBlack: Лично мне без разницы, далеко или близко от вакансии. Важно посмотреть на ваш код и понять, на что вы способны.
— ваши слова!
1. Берем код на С++
2. Смотрим его
3. Если он в порядке
4. Спрашиваем про знание PL/SQL
5. Если ответ утвердительный, берем на работу
6. Если нет, спрашиваем про желание изучать эти технологии
7. Если ответ утвердительный, берем на работу
8. Если предоставленный код на С++ не в порядке
9. Тут можно думать, спрашивать, собеседовать
10. Но мала вероятность того, что человека можно будет взять на работу.
Почему? Да потому, что профессионал никогда не будет присылать фиговый код. И даже не потому, что он умеет. А потому, что он знает, что он умеет, а что нет. И зная, что он не умеет с++, он его присылать не будет. А если прислал — значит толком он ни в чем не разбирается. Выводы могут показаться сомнительными.
За совет спасибо, попробую сохранять весь код, который я пишу в нерабочее время. На собеседованиях периодически просили посмотреть код, не важно где и какой.
но кадров жестко не хватает
Я это писал в плане того что сейчас очень много вакансий и каждый день открываются всё новые…
Вот это кстати отличный показатель — стоит ли вообще идти на собеседование
Не соглашусь. Вот например искали разработчика с опытом, ЗП выше среднего по рынку, условия стандартные, компания довольно известная. Приходит много народа, но совсем зеленые, а там нужно чтобы пришел человек и с минимум вопросов смог начать что то делать.
Мне кажется сейчас обилие программистов только на уровне джуна. А если брать планку чуть выше, то идет жесткий дефицит.
Поясню: ничего не имею против джунов, просто специфика вакансии требовала кого-то по опытнее.
По моим наблюдениям большинство не парятся и в описании вакансии включают все знакомые им страшные слова. Отсюда и кажущаяся видимость множества серьезных вакансий.
В регионах все намного хуже.
Не соглашусь. Вот например искали разработчика с опытом, ЗП выше среднего по рынку, условия стандартные, компания довольно известная. Приходит много народа, но совсем зеленые, а там нужно чтобы пришел человек и с минимум вопросов смог начать что то делать.
Мне кажется сейчас обилие программистов только на уровне джуна. А если брать планку чуть выше, то идет жесткий дефицит.
Если брать планку чуть выше — то и денег нужно предлагать чуть больше. Глупо предлагать условные 2-3 тысячи в месяц, а потом удивляться: «Ой, как так? Интересно, где опытный человек, способный придти и с минимумом вопросов начать что-то делать?»
ЗП выше среднего по рынку
ЗП выше среднего по рынку
Не бывает такой заработной платы. Бывает только в виде цифр и валют. Например: от 360 тыс. рублей в месяц. Или £50k — 90k в год.
Мы ставили 80к+.
Выше среднего по рынку…
IT рынок глобализован, поэтому среднее по региону слабо волнует людей с опытом. Судя по текущим раскладам, мидл с опытом не будет рад з/п меньше 90 т.р., а если у него ещё и с английским всё хорошо, то умножайте на 1.5.
Всё что ниже, можно считать ниже среднего по рынку, вне зависимости от региона.
То есть да, можно найти удаленную вакансию, хотя их и в разы меньше, но так делает очень маленький процент разработчиков. Все в офисы рвутся. Во первых потому что у нас менталитет такой, ещё не привыкли работать удаленно. Ну а вторая очень веская причина — у нас компании не умеют с удалёнщиками работать.
Вы сами сейчас работаете удаленно?
На западе да, это нормальная практика. Но со знанием английского лучше сразу переехать за рубеж.
То есть да, можно найти удаленную вакансию, хотя их и в разы меньше, но так делает очень маленький процент разработчиков.
В разы меньше, чем где? Вы же сами написали, что не из Москвы, поэтому я сильно сомневаюсь, что кол-во вакансий в вашем городе может сравниться с кол-вом вакансий на удалёнку. В большинстве региональных центров по конкретному профилю редко бывает более 5-7 компаний, ещё реже бывает, чтобы они все одновременно имели открытые вакансии.
Ну а вторая очень веская причина — у нас компании не умеют с удалёнщиками работать.
Даже в России есть которые умеют, но необязательно себя российскими компаниями ограничивать.
Вы сами сейчас работаете удаленно?
Буквально в этом месяце переключился на офис для разнообразия, до этого 7 лет удалённо работал.
Но со знанием английского лучше сразу переехать за рубеж.
Кому лучше и зачем? У меня, например, никогда такой цели не было, хотя почти каждый месяц приглашают куда-то переехать.
Вы поймите одно: с одной стороны, Вы хотите найти высококвалифицированных специалистов, а с другой — считаете, что они не способны удалённо работать. Это противоречащие требования. Те, кто развивается, за редким исключением личных обстоятельств, способны работать на любой рынок. А те, кто "я могу только из офиса, даже если из дома будут в 2 раза больше платить и проекты будут поинтереснее" — они почти все вечные джуны или максимум мидлы, если с офисами повезло.
В разы меньше, чем где?
Чем в городе с количеством жителей миллион+.
В большинстве региональных центров по конкретному профилю редко бывает более 5-7 компаний
На чем основаны данные?
Буквально в этом месяце переключился на офис для разнообразия
Что значит для разнообразия? Если удаленка так прекрасна и универсальна, почему не устроиться на другую удаленную работу? Рынок же глобализирован…
Даже в России есть которые умеют, но необязательно себя российскими компаниями ограничивать.
Я то говорил конкретно о нас. Мы не умеем с удаленщиками работать. А так как выстраивать процесс работы с удаленщиками — дело не простое, то мы искали человека в офис.
Если же говорить о том, что все местные хорошие разработчики работают удаленно, то сильно сомневаюсь, всё по тем же причинам, о которых писал выше.
Ну и опять, если удалёнка так хороша, то почему у одних и тех же компаний вакансии висят очень долго? Ведь если по Вашему, к ним всё СНГ должно проситься и от резюме не должно быть отбоя.
Кому лучше и зачем? У меня, например, никогда такой цели не было, хотя почти каждый месяц приглашают куда-то переехать.
Ну и Вы по себе всех судите…
На чем основаны данные?
На многолетних наблюдениях за локальным рынком. Ну ладно, в миллионниках может быть 10-15 более-менее серьёзных компаний в одном сегменте. Существенно больше только в Москве и Питере. Но всё равно это странно сравнивать с сотнями remote-вакансий.
Что значит для разнообразия?
Есть должности, на которых удалёнка проблематична. Решил поработать техническим директором и посмотреть насколько мне будет интересно в этой роли.
Ну и опять, если удалёнка так хороша, то почему у одних и тех же компаний вакансии висят очень долго?
Это Вы про кого? Какие-нибудь Crossover или Toptal? Это не конечные компании, а прослойки, поэтому у них постоянный найм.
А так как выстраивать процесс работы с удаленщиками— дело не простое
Это, кстати, заблуждение. Никаких кардинальных сложностей в этом нет. Просто удалёнщики должны быть способны к самоорганизации.
Ну и Вы по себе всех судите…
Ну а Вы по себе, поэтому я Вам и показываю альтернативный взгляд. И объясняю, почему к вам не ломанулась куча специалистов, когда вы чуть выше среднего по региону з/п поставили. Ваше право сомневаться в моём объяснении, но более правдоподобного у Вас ведь всё равно нет.
которые простой код на 10 строк не могут написать за 15-20 минут.
А какой код, можно узнать? Просто на том же LeetCode есть сложные задачи на 5-8 строк, которые без умения решать такие задачи, минут за 15-20 не написать.
Но в коде интересно посмотреть.
!* Возможно Я не прав… =)
Хорошая задачка на «поговорить» для собеседования, не очень хорошая, если у вас есть только код.
А если несколько млрдов?
А если слова лежат на ленте?
А набор букв очень большой?
;) ну и т.д.
Если человек задает уточняющие вопросы, пытается выяснить окружение, и прочие детали, то возможно он лучше подходит для проектирования.
В целом нужны и те, и те, но образ мысли кандидата помогает понять к чему склонен кандидат.
auto regroup(std::vector<std::string> words) {
std::map<std::set<char>, std::vector<std::string>> set;
for (const auto& word : words) {
const auto& key = std::set<char>(begin(word), end(word));
set[key].push_back(std::move(word));
}
std::vector<std::vector<std::string>> groups;
for (const auto& group : set) {
groups.push_back(std::move(group.second));
}
return groups;
}
int main() {
std::vector<std::string> input = { "ab", "xy", "ba", "yx" };
const auto& output = regroup(input);
for (const auto& group : output) {
std::cout << "[" << std::endl;
for (const auto& word : group) {
std::cout << word << std::endl;
}
std::cout << "]" << std::endl;
}
}
Но тут эффективность… так себе. Памяти много тратится и всё такое… Но чтобы сделать лучше нужно больше информации про задачу…
На многоядерной системе можно устраивать разного рода параллелизацию.
И прочее, прочее, прочее.
Если вы хотите вместо чётких математических терминов использовать свои изобретения — то не удивляйтесь, если вас неправильно поймут.
У вас реально в компании сеньоры такими задачами занимаются? Или вы просто чтобы джуниоров подбодрить называете их сеньорами?
Вы, вроде, начали с "Причем, вакансия на сеньора".
У нас 3 задачи, но мы не ищем всезнаек, ищем тех, кто умеет думать. Для этого не обязательно давать сложные задачи на 3-4 часа, достаточно парочки совсем простых.
Имхо, для сеньоров — это не простая задача, а тупая. И единственный ответ, который я бы от сеньора принял как правильный, — назначить этот таск джуниору или стажёру.
Вопросы, которые Вам выше писали тоже уместны, т.к. люди хотя бы пытаются понять с какого перепуга им прилетела эта задача, где в ней сложность, с которой не справился стажёр.
Если человек начинает решать такую задачу, то на должность сеньора он не подходит, т.к. не имеет навыков делегирования и проактивного подхода к задачам.
Ну, поэтому я и уточнил, какими задачами сеньоры в этой компании занимаются… Уже сотни раз писали, что обсуждать на собеседовании что-то вне контекста практической области деятельности, под которую вы ищете сотрудника, — это скорее вредно, чем полезно. Ну а если в некой компании сеньоры преимущественно занимаются тем, что группируют массивы не важно с какой эффективностью, лишь бы работало, то вопросов нет.
Уже сотни раз писали, что обсуждать на собеседовании что-то вне контекста практической области деятельности, под которую вы ищете сотрудника, — это скорее вредно, чем полезно.И уже сто раз же отвечали, что для многих компаний искать сотрудника под конкретную практическую область — бессмысленно. Ибо проекты расширяются и сокращаются часто и работать в течении 10 лет в одной предметной области не получится.
Ну а если в некой компании сеньоры преимущественно занимаются тем, что группируют массивы не важно с какой эффективностью, лишь бы работало, то вопросов нет.«Лишь бы работало» — это первый шаг, как я понял. Чтобы вот того самого «мееенеджера, который в программирование вообще не умеет» не нанять. А дальше — да, набросав за 10-15 минут какое-нибудь решение сеньор должен уметь о нём ещё и поговорить (чем и будет отличаться от джуна).
Ну, поэтому я и уточнил, какими задачами сеньоры в этой компании занимаются…Ну давайте. Возьмём конкретный пример:
1. Год — работа надо локализацией UI катологизатора (что-то типа всем известного DMOZа)
2. Пара лет — работа с Big Data (терабайтные базы и выискивание полезной информации в них)
3. Потом — плагины для браузера и разработка sandbox'а, который должен был обеспечивать безопасность модулям, которые грузились в этот плагин.
4. Ну и вишенка на тортике — JIT-комплятор для специфического байткода (текущий проект).
Просто потому что там менялись задачи в том офисе, где он работал.
Какие конкретно вопросы вы задали бы такому человеку с учётом того, что каждый из проектов он начинал с нуля в одиночку (фаза технико-экономическое обоснования) и получал своих джунов и стажёров уже после демонстрации прототипа?
У меня есть ощущение, что вы вообще путаете сеньоров и менеджеров. Почему-то частая проблема в России вообще — где люди гордяться тем, что не умеют писать код.
Просишь написать какую-нибудь вот такую простейшую задачку — а в ответ получаешь заявление, что он же сеньор, он кода уже три года не писал… какой же он, нафиг, сеньор тогда? В лучшем случае — Product Manager… тоже полезная и нужная профессия, но… она немного о другом! И критерии там — другие!
искать сотрудника под конкретную практическую область — бессмысленно
Причём тут предметная область? Сравните 2 вопроса:
1) напишите алгоритм группировки списка слов по таким-то условиям.
2) как бы вы начали проектировать систему, помогающую разгадывать кроссворды, подбирая слова по известным буквам?
Оба вопроса из одной предметной области, но при этом совершенно для разных вакансий. На первый вопрос адекватный сеньор (если уж ему такой вопрос всё-таки задали) сначала спросит "для чего?". Знаете в каком коде не бывает багов?
А дальше — да, набросав за 10-15 минут какое-нибудь решение сеньор должен уметь о нём ещё и поговорить (чем и будет отличаться от джуна).
Бред. Если человек сразу кидается писать код — это не сеньор. Сеньор из вас сначала всю душу вытрясет, проясняя требования и зачем это вообще вам. Потому что 80-90% работы сеньоров состоит в том, чтобы думать, а не код в редакторе набирать.
Какие конкретно вопросы вы задали бы такому человеку с учётом того, что каждый из проектов он начинал с нуля в одиночку
Это уже фриланс какой-то, а не командная работа…
Так что я бы спросил о том, как строилась работа после стадии прототипа, если такое вообще было. Какова была его роль в команде? Как строилась работа по проекту в целом? Как происходила декомпозиция и оценка задач? Как был построен каждый проект с точки зрения архитектуры?
У меня есть ощущение, что вы вообще путаете сеньоров и менеджеров.
Только вот путаете Вы… Сеньор — это одна из ведущих ролей, а в случае с вышеописанной микро-компанией вообще единственная ведущая роль в команде. Сеньор — это не тот, кто пишет код от забора и до обеда так, как сказал менеджер. Он обязан занимать проактивную позицию и докапываться до сути того, что надо сделать, в том числе предлагая решения, о которых менеджеры с заказчиком никогда бы не додумались. А также участвовать в разработке архитектурных решений, распределять задачи между другими программистами, способствовать их росту, следить за соблюдением сроков и т.д.
Потому что 80-90% работы сеньоров состоит в том, чтобы думать, а не код в редакторе набирать.Верно — но если мне сложнее такому сеньору объяснить задачу, чем решить её самому — то нафиг он, такой красивый, нужен?
Это уже фриланс какой-то, а не командная работа…Почему фриланс? Обычная ситуация для крупных компаний типа Фейсбука или Майкрософта.
Так что я бы спросил о том, как строилась работа после стадии прототипа, если такое вообще было. Какова была его роль в команде? Как строилась работа по проекту в целом? Как происходила декомпозиция и оценка задач? Как был построен каждый проект с точки зрения архитектуры?И нафига всё это если он стадию прототипа завалит?
Сеньор — это одна из ведущих ролей, а в случае с вышеописанной микро-компанией вообще единственная ведущая роль в команде.Просто для справки: в вышеупомянутой компании на сегодня числится более пятидесяти тысяч сотрудников (не считая контракторов). Если это для вас «микро» — то что для вас будет «макро»?
Сеньор — это не тот, кто пишет код от забора и до обеда так, как сказал менеджер.Верно. Это тот, кто пишет код так, как он его видит — а потом, если убедит менеджеров, получает штат на то, чтобы превратить имеющийся прототип в что-то работающее.
А также участвовать в разработке архитектурных решений, распределять задачи между другими программистами, способствовать их росту, следить за соблюдением сроков и т.д.Да, конечно. Но это всё — потом. Когда вы убедите менеджеров в том, что ваша идея, собственно, вообще имеет смысл и что её реализация сможет кому-то улучшить жизнь.
Ну и как ваш сеньор должен пройти начальный этап, если он программировать разучился?
Почему фриланс?
Потому что в одиночку. Для разработки прототипа можно выделить 2-3 человек и это будет гораздо эффективнее, если этот прототип для кому-то нужной задачи вообще делается, а не от нечего делать.
а потом, если убедит менеджеров, получает штат на то, чтобы превратить имеющийся прототип в что-то работающее.
Другими словами, речь идёт об изначально никому ненужных проектах? Ну ok. Большинство компаний заказной разработкой занимаются, а не тем, что Вы описали. Может Facebook и может себе позволить нанять людей просто про запас и дать им хобби-проектами под крылом компании заниматься. Но это просто индикатор, что до основных проектов вас пока не готовы допустить, даже в роли мидла.
Ну и как ваш сеньор должен пройти начальный этап, если он программировать разучился?
С чего Вы это взяли? Уметь программировать и кидаться программировать не разобравшись в задаче — это не одно и то же.
Для разработки прототипа можно выделить 2-3 человек и это будет гораздо эффективнее, если этот прототип для кому-то нужной задачи вообще делается, а не от нечего делать.Нет, это не будет эффективнее. Команда из 2-3 человек — это вообще страшно неэффективное расходование ресурсов. Просто потому что когда у вас появляется команда — тут же появляются затраты на взаимодествие, нужно создавать внутренние документы какие-то описания, согласования и прочее. Потому скорость команды в два человека хорошо если превышает скорость работы одного, а три человека — дадут весьма небольшой выигрыш.
Вот когда вы уже решили выделить на проект ресурсы — тогда можно уже создавать минимально осмыслленную команду в 5-7 человек (или в 50-70 человек — всё зависит от задачи, конечно), которая реально может дать прирост. Эффективность упадёт ещё больше, конечно, но тут уж ничего не поделать — один человек многие вещи будет доводить до релиза десятилетия, когда они уже окажутся никому не нужными.
Другими словами, речь идёт об изначально никому ненужных проектах?С чего вы решили, что они «никому не нужны»? Часть выкидывается, часть превращается во что-то большое.
Нормальная ситуация, когда ваша конпания не sweatshop, выполняющий задачи «для дяди» под заранее согласованное ТЗ в какой-то освоенной области, а разрабатывает новые вещи — и заранее не знает будет ли от реализации той или иной идеи польза.
Большинство компаний заказной разработкой занимаются, а не тем, что Вы описали.Пресловутые пять миров? Да, очень на то похоже. Но суть тут в том, что «большинство компаний» быть может и занимается заказной разработкой — но я, конкретно, ни разу в подобных компаниях не работал и не собираюсь. Потому я сужу с точки зрение другого мира — где зарание никаких ТЗ нету, его нужно придумать — ну а после запуска оценить: взлетело или нет. Если за пару лет пользователей не больше 5-10 миллионов — значит «не взлетело», проект пора закрывать.
И вот тут сеньор, умеющий только управлять джунами — нафиг никому не нужен, потому что он тупо экономически неэффективен.
Уметь программировать и кидаться программировать не разобравшись в задаче — это не одно и то же.А как вы разберётесь в задаче не набросав прототип и не повертев его по-всякому? Картинки на бумажке (или на доске) могут вылядеть очень красиво, но часто попытка хотя бы примерно прикинуть в коде — всё ставит «с ног на голову».
нужно создавать внутренние документы какие-то описания, согласования и прочее
Это уже от степени бюрократии зависит, а не от кол-ва людей.
С чего вы решили, что они «никому не нужны»? Часть выкидывается, часть превращается во что-то большое.
С того, что Вы не описали проблематику, а указали конкретные проекты, которые при этом делали в одиночку. Если бы там была ситуация в формате "есть такая-то проблема, давайте запустим R&D и несколько человек предоставят прототипы разного варианта решения" — это бы я понял. А с ваших слов получается, что-то в формате: "сидел я как-то без дела, ну и говорят мне: займись уж хоть чем-нибудь… если что-нибудь путное придумаешь, то может мы потом займёмся развитием этой темы".
Пресловутые пять миров?
Возможно. Хотя классификация уже давно устарела. Но безусловно у разных компаний разная специфика.
разрабатывает новые вещи
Новые вещи разрабатываются крайне редко. Везде сплошная адаптация уже известных концептов под нужды бизнеса или пользователей. Ваши 4 проекта тут ни разу не исключение. Ни идея песочницы, ни идея JIT-компилятора не принадлежат лично Вам, остальное так вообще банальщина. Никаких концептуально новых вещей Вы не делаете. Единственное что непонятно из ваших сообщений — от кого исходит идея что-то начать писать.
У нас тоже ТЗ нет никаких, но есть те самые нужды бизнеса, которые обсуждаются и под них разрабатывается решение. Причём это не в статике, нужды бизнеса меняются и решение должно легко адаптироваться.
И вот тут сеньор, умеющий только управлять джунами
С чего Вы взяли, что он только это умеет? Вот тут как раз в тему статья вышла. Способности программиста — это одна из 4 характеристик сеньора, само собой она важна и обязательна. Но тут надо учитывать, что не весь код одинаково сложный, поэтому важно чтобы сеньор не тратил время зря на простые вещи, а занимался в первую очередь тем, что остальные члены команды реализуют в 5-10 раз медленнее, если вообще смогут. Вы же считаете, что кроме написания кода от сеньора вообще ничего не требуется, но тогда это по сути мидл.
часто попытка хотя бы примерно прикинуть в коде — всё ставит «с ног на голову».
Может просто стоило картинки чуть дольше покрутить? Реализация может вносить коррективы, но ситуация «с ног на голову» — это фейл этапа проектирования.
Если вы делаете прототип, не имея жёсткой постановки задачи? Как все ваши джуниоры и миддлы должны будут догадаться что вам делать? Путём телепатического заглядывания к вам в мозг?нужно создавать внутренние документы какие-то описания, согласования и прочее
Это уже от степени бюрократии зависит, а не от кол-ва людей.
Знаете сколько человек делали, скажем, прототип Colossus'а? Двое. Но не потому что сеньор 10го или 14го или какого уж там уровня получил джуна «в подмастерья». А потому что Jeff и Sanjay работали вдвоём годами и понимают друг друга буквально с полуслова.
А это, на минуточку, разработка с нуля компонента, над которым вся серверная экосистема Гугла построена. Казалось бы — куда уж важнее. Но нет — никаких джунов и «архитекторов». Потому что они только мешают на этом этапе.
С того, что Вы не описали проблематику, а указали конкретные проекты, которые при этом делали в одиночку.Во-первых — с чего вы решили, что речь шла обо мне. Во-вторых — с чего вы решили, что эти проекты писались в одиночку? Прототип делается в одиночку (редко — два-три человека, очень долго работавших вместе), а уж потом в проекте может быть и под 100 человек.
А с ваших слов получается, что-то в формате: «сидел я как-то без дела, ну и говорят мне: займись уж хоть чем-нибудь… если что-нибудь путное придумаешь, то может мы потом займёмся развитием этой темы».Ну не так всё жестоко. Когда какой-нибудь Inbox закрывается, то у вас, обычно, есть год или даже чуть больше, чтобы придумать что-то или найти другой проект, куда вас примут. Внутри-то информация про закрытие раньше появляется, чем снаружи.
Ни идея песочницы, ни идея JIT-компилятора не принадлежат лично Вам, остальное так вообще банальщина.Так мы дойдём до того, что в компюьютерах вообще всё — сплошная банальщина, нолики и единички, что может быть проще.
Единственное что непонятно из ваших сообщений — от кого исходит идея что-то начать писать.С разных сторон. Что-то вы можете вообще в коридоре услышать. Но в общем и целом… это ваша задача как сеньора — обосновать ценность и полезность той или иной разработки.
С чего Вы взяли, что он только это умеет?Ну раз вы на собеседовании только это и спрашиваете — то, скорее всего, наберёте людей, которые только это и умеют…
Но тут надо учитывать, что не весь код одинаково сложный, поэтому важно чтобы сеньор не тратил время зря на простые вещи, а занимался в первую очередь тем, что остальные члены команды реализуют в 5-10 раз медленнее, если вообще смогут.Это всё прекрасно, но, извините, я не видел людей, которые могли бы реализовать что-то сложное, а вот простую задачу — ну никак. И есть у меня подозрение, что такие в природе не встречаются.
Увидите — покажите. До тех пор предположение о том, что человек, предлагающий в ответ на простейшую задачу на собеседовании «делегировать это джунам» сеньором, по большому счёту, не является и, соотвественно, нам не подходит — является достаточно разумным.
Вы же считаете, что кроме написания кода от сеньора вообще ничего не требуется, но тогда это по сути мидл.С чего вы решили? Я всё отдельно озвучил даже. Проверка умения решать простейшие задачи — это первая стадия при найме сеньора. Ибо крайне большой количество людей, искренне считающих себя сеньорами, настолько долго «делегировали задачи», что не «реализуют в 5-10 раз быстрее то, что другие не могут», а, наоборот, «не могут вообще ничего реализовать, так как код не писали годами».
Вот их — и нужно максимально быстро отсеять. Потому что они вообще не программисты уже. А уже потом уже разбираться — тянет человек на уровень сеньора или нет.
Как все ваши джуниоры и миддлы должны будут догадаться что вам делать? Путём телепатического заглядывания к вам в мозг?
А кроме регламентных документов и телепатии Вы других способов общения не знаете?
Ну раз вы на собеседовании только это и спрашиваете — то, скорее всего, наберёте людей, которые только это и умеют…
Да бросьте, я спокойно доверяю людям в этом отношении. И не сомневаюсь, что отработав многие годы программистами они могут набрать код. Меня больше интересует, чтобы сеньор вёл себя согласно своей роли, а не как мега-опытный джуниор.
Знаю — но все они выбивают человека «из колеи». Разные замеры показывали разное время, но в среднем — если ответ на вопрос занимает 1 минуту, то потери производительности, у человека, пишущего код — 15-30 минут.Как все ваши джуниоры и миддлы должны будут догадаться что вам делать? Путём телепатического заглядывания к вам в мозг?А кроме регламентных документов и телепатии Вы других способов общения не знаете?
Потому попытка обойтись без документации в проекте, где новые идеи всё ещё появляются раз в 2-3 дня — приводит, опять-таки, только к замедлению.
Да бросьте, я спокойно доверяю людям в этом отношении.А сколько людей вы на работу опросили и наняли, позвольте спросить?
И не сомневаюсь, что отработав многие годы программистами они могут набрать код.А вот я — сомневаюсь. И не напрасно. Потому что бо́льшая часть «сеньоров» код писать не умеет. Небольшая часть — просто об этом заявляет после попытки что-нибудь написать (часть с грустью, час — даже с гордостью какой-то… ага, придти на вакансию, где это — необходимое требование и мурыжить людям мозги… это же так почётно), большая часть делает вид, что вообще — они ого-го… просто сейчас не в духе.
Меня больше интересует, чтобы сеньор вёл себя согласно своей роли, а не как мега-опытный джуниор.Ok. Вы проверили что сеньор может общаться с джунами, строить разного рода космические архитектурные замки на листе бумаги… написать три строчки кода — не может (это вы не проверили, но вероятность — больше 50%). Взяли его такого на работу. Что дальше?
если ответ на вопрос занимает 1 минуту, то потери производительности, у человека, пишущего код — 15-30 минут.
Это всё так, но вас послушать так программисты только и делают, что код пишут. Обсуждать идеи прежде, чем переводить их в код — очень даже полезно. И уж хватает методологий как это делать, чтобы не вызывать проблему постоянных отвлечений.
А сколько людей вы на работу опросили и наняли, позвольте спросить?
Не так много, нанимал около десятка, опрашивал соответственно в разы больше.
Потому что бо́льшая часть «сеньоров» код писать не умеет.
Тут если только вам поверить, я ни одного такого сеньора вживую не видел. Я допускаю, что есть куча сеньоров, которые не напишут на бумажке QuickSort, потому что в прошлый раз они этим интересовались 10-15 лет назад, или вообще на бумажке ничего не напишут, т.к. давным давно переложили автодополнение на IDE. Но вот чтобы они не могли код написать в обычных условиях на своём компе, такого я не встречал.
Тут если только вам поверить, я ни одного такого сеньора вживую не видел.Только это не только моё мнение. Я уж не знаю как вам удавалось отсеять людей, которые когда-то были программистами не задавая их вопросов по программированию — но почему-то всем другим, кто реально занимался наймом, люди способные что-то написать встречаются куда реже, чем хочется.
На собеседованиях, конечно, в реальной-то работе их не так много… именно потому что их много на собеседованиях!
Но вот чтобы они не могли код написать в обычных условиях на своём компе, такого я не встречал.То есть печально известный подход если достаточно долго месить чан с перловой кашей, в синтаксическом мусоре можно рано или поздно узреть лик Ларри Уолла вас устраивает? Меня — нет. Особенно если речь идёт от синьоре.
Ибо шансы на то, что джун просто «ещё не умеет прогрммировать, но со временем научится» — довольны высоки. А у «сеньора» это, почти наверняка, стадия «уже разучился программировать и, соответственно, учиться не будет».
Да дебилизм полнейший все эти задания написать какой-то код на бумажке или в GoogleDocs. По факту вы просто отсеиваете людей, которые не умеют писать код на бумажке. Мне такой навык от сотрудников нафиг не нужен.
Ну а разучиться программировать — это из серии разучиться на велосипеде кататься.
Сравните 2 вопроса:Я бы сказал, что они для одной вакансии, но для разных стадий интервью. Если человек не может решить первую — то это вообще не программист и дальнейшие разговоры бессмысленны. А вот если он первую уже умеет решать и мы про это знаем — тогда можно поговорить и о том, можно ли или нельзя ли её применить к решению кроссвордов (ответ, кстати — нельзя, это скорее чуть-чуть похоже на игру в «слова», но при всей внешней похожести реально это — совсем разные задачи).
1) напишите алгоритм группировки списка слов по таким-то условиям.
2) как бы вы начали проектировать систему, помогающую разгадывать кроссворды, подбирая слова по известным буквам?
Оба вопроса из одной предметной области, но при этом совершенно для разных вакансий.
Самый правильный ответ во всей ветке. Спасибо.
можно ли или нельзя ли её применить к решению кроссвордов (ответ, кстати — нельзя, это скорее чуть-чуть похоже на игру в «слова», но при всей внешней похожести реально это — совсем разные задачи).
И Вас даже не смутило, что в формулировке не указаны конкретные условия? А если Вы имели в виду формулировку от kruslan, то там никакой схожестью с кроссвордами вообще не пахнет. Рано Вам в сеньоры...
Он обязан занимать проактивную позицию и докапываться до сути того, что надо сделать, в том числе предлагая решения, о которых менеджеры с заказчиком никогда бы не додумались. А также участвовать в разработке архитектурных решений, распределять задачи между другими программистами, способствовать их росту, следить за соблюдением сроков и т.д.
Ну вот я понял вашу позицию. Такие «сеньоры» действительно не нужны в нашей компании. Да и «сеньорами», если честно, я их назвать не могу.
Правильно, судя по всему, вам и не нужны сеньоры в компанию, вам нужны линейные исполнители — нормальные джуниоры и начинающие мидлы. Для некоторых проектов этого вполне достаточно.
Команда должна работать как команда, а не как испорченный телефон, когда продакт поговорил с заказчиком, архитектор поговорил с продактом, спустил архитектуру команде разработке и они начали фигачить, не вдаваясь в суть.
Кто по вашему должен сообщить продакту заранее, что всплыли непредвиденные сложности в какой-то задаче? Кто должен на этапе реализации не хуже архитектора понимать почему приняты определённые архитектурные решения? На кого должны равняться мидлы и джуниоры? Кто code review должен делать?
В большой команде разработки эти обязанности размажутся между тим-лидом и несколькими сеньорами. В небольшой — это всё задачи сеньора.
Команда должна работать как команда, а не как испорченный телефон, когда продакт поговорил с заказчиком, архитектор поговорил с продактом, спустил архитектуру команде разработке и они начали фигачить, не вдаваясь в суть.А кто вам сказал, что у вас есть заказчик? Нет его. Вон пользователи бегают. Миллиарды. И чего хотят — они сами не знают. И не узнают — пока вы не придумаете чего бы такого сделать и как бы это реализовать.
Да пусть даже упростим задачу — пусть вы пишите не что-то для пользователей, а какую-то промежуточную библиотеку для других разработчиков… у вас ведь тоже нет одного заказчика — вам нужно придумать что-то, что потом окажется для какой-нибудь команды полезным (лучше, конечно — для нескольких команд).
В большой команде разработки эти обязанности размажутся между тим-лидом и несколькими сеньорами. В небольшой — это всё задачи сеньора.Это всё верно. Но это всё — потом. Когда вы убедили кого-то, что то, что вы задумали вообще имеет смысл делать!
В том-то и дело, что наличие всемогущего «заказчика» кардинально меняет всю картину! Из неё полностью выпадает «нулевой этап»: слепить что-то из гавна и палок так, чтобы на это можно было посмотреть и принять решение — нужно это вообще развивать или нет!
А если у вас нет заказчика — то это, собственно, самый важный этап.
А кто вам сказал, что у вас есть заказчик? Нет его. Вон пользователи бегают. Миллиарды. И чего хотят — они сами не знают. И не узнают — пока вы не придумаете чего бы такого сделать и как бы это реализовать.
В таком случае пользователи — это и есть заказчик и кто-то должен провести исследования, проанализировать их потребности и т.д., иначе это какая-то артель "напрасный труд". Сеньор чаще всего даже в ЦА не входит, но у вас получается именно он берёт с потолка гипотезу, что нужно пользователям. По описанию фигня какая-то выходит… Я честно скажу, что не понимаю чем вы там вообще занимаетесь и зачем, с моей перспективы это выглядит как работа ради работы. Возможно, Вы просто пропустили описание самого начала: откуда вообще приходят идеи делать прототип для чего-то конкретного?
В таком случае пользователи — это и есть заказчик и кто-то должен провести исследования, проанализировать их потребности и т.д., иначе это какая-то артель «напрасный труд».Помните гениальную фразу Генри Форда если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь? Вот и в программировании — та же история. Люди не знают, на самом деле, что им нужно.
Да, конечно, исследования. Да, разумеется, анализ. Но дальше — любом случае нужно делать что-то новое, чего никто явно не просит, но что на самом деле всем и нужно. Иначе вы попадёте в ситуация Nokia, которая годами проводила исследования на тему «а что нужно пользователям смартфонов», а потом пришли новички, предложили то, о чём ни один опрос им не сказал (возможность тыкать в экран пальцами, а не палочкой) — и вынесли лидера рынка (без кавычек, заметим!) «вперёд ногами».
Сеньор чаще всего даже в ЦА не входит, но у вас получается именно он берёт с потолка гипотезу, что нужно пользователям.Таки да. И они часто срутся на эту тему с UX-исследователями и продакт менеджерами, которые объясняют сеньору, что их предложения кажутся ему дикими, но «надо попробовать».
Возможно, Вы просто пропустили описание самого начала: откуда вообще приходят идеи делать прототип для чего-то конкретного?Откуда угодно. Что-то «спускают сверху» (что, кстати, вовсе не гарантия того, что это что-то имеет смысл и это нужно делать — и, кстати, самое важное отличие сеньора от джуна в том, что он умеет обосновать варианты, когда начальство хочет, а делать это не нужно), что-то придумывает сеньор, что-то придумывают UX'ы и продакт менеджеры, что-то вообще откуда-нибудь из какого-нибудь фанфика или аниме выдёргивается.
Вопрос «кто придумал» — не так важен, как раз. Важна проверка и принятие или выбрасывание идеи.
Всё, о чём Вы говорите, затрагивает только R&D.
И в данном контексте речь идёт по сути не о сеньорах, а об исследователях. Т.е. с одной стороны — да, человек, имеющий квалификацию сеньора, может выступать в роли исследователя. Но с другой стороны, в рамках всей индустрии, кейс когда сеньор что-то пилит в одиночку, опираясь только на своё видение проекта, — не такой уж частый. Поэтому я не понимаю, почему Вы так упорно пытаетесь натянуть сову на свой глобус, при всей очевидности, что так устроена работа в очень малом кол-ве компаний, а ещё точнее только в 1 департаменте этих компаний.
Но с другой стороны, в рамках всей индустрии, кейс когда сеньор что-то пилит в одиночку, опираясь только на своё видение проекта, — не такой уж частый.Я не нанимаю сотрудников «для всей индустрии».
Поэтому я не понимаю, почему Вы так упорно пытаетесь натянуть сову на свой глобус, при всей очевидности, что так устроена работа в очень малом кол-ве компаний, а ещё точнее только в 1 департаменте этих компаний.Я не знаю в сколько компаниях работали вы — но во всех, где работал я подавляющее большинство сеньоров работали именно в этом режиме. Хотя это были разные компании — от стартапов в 5-10 человек до монстров в десятки тысяч.
И да, я знаю, что «в рамках всей индустрии» — это редкость. Но это не редкость у нас! И вы уж как-нибудь определитесь с вашей позицией: либо у вас «во всей индустрии» сеньоры пишут код (что как-то ну вот совсем не согласуется с тем, что мы видим на собеседовании), либо — наличие этого навыка нужно проверять на собеседовании.
Команда должна работать как команда, а не как испорченный телефон, когда продакт поговорил с заказчиком, архитектор поговорил с продактом, спустил архитектуру команде разработке и они начали фигачить, не вдаваясь в суть.
Команда должна участвовать в обсуждении задач и проблем, здесь я полностью согласен. Но, основное слово в «senior developer» именно «developer» и зона ответственности — качественный код.
Кто по вашему должен сообщить продакту заранее, что всплыли непредвиденные сложности в какой-то задаче?
Team Lead, Tech Lead, аналитики, QA и пр. Куча вариантов. Но среди них точно нет разработчиков.
Кто должен на этапе реализации не хуже архитектора понимать почему приняты определённые архитектурные решения?
CTO, Tech Lead, Team Lead.
На кого должны равняться мидлы и джуниоры?
Ни на кого. Серьезно.
Кто code review должен делать?
Team Lead, Tech Lead, ментор, отдельный человек/команда в конце-концов. У нас, кстати, такое практикуется.
В небольшой — это всё задачи сеньора.
Нет. Задача сеньора — качественный код. Если еще и быстро реализованный — вообще отлично. А если сеньор, вместо прямых обязанностей, занимается чем угодно другим — надо переводить его на другую должность/в другой отдел.
Tech Lead, Lead Developer, ведущий программист — это просто альтернативные названия для Senior Developer.
И это не только моё частное мнение… Почти никто не разделяет эти роли. Вот для примера: What Defines a “Senior Developer?”
Имхо, Вы переусложняете классификацию… Если tech lead больше архитектор, то чем он отличается от архитектора?
Вот тут немножко про ведущего программиста.
Я бы даже не стал строгой границы между тимлидом и сеньором проводить. Да, не каждый сеньор может выполнять роль тимлида, в силу особенностей характера, но каждый тимлид — это сеньор по квалификации, который в силу роли просто несколько больше управленческой работы выполняет, чем обычный сеньор.
Если tech lead больше архитектор, то чем он отличается от архитектора?
Тем, что архитектура у архитектора основная работа и код он почти не трогает и обратная ситуация у тех.лида — он больше по коду, но участвует в формировании архитектуры. Как-то так, если упрощенно.
Да, не каждый сеньор может выполнять роль тимлида, в силу особенностей характера, но каждый тимлид — это сеньор по квалификации
Так вот-же провели границу. Да, тим.лид — чаще всего сеньор (хотя я видел, когда тим.лидом был мидл). И работа тим.лида — уже не код, а управление и оптимизация работы разработчиков. А девелопера (и тем более, сеньор девелопера) — код и только код.
Конечно, у каждой роли есть своя основная зона ответственности. Но на практике все эти границы размываются… И архитектор и тимлид могут сделать что-то в коде, а сеньоры обсудить архитектуру.
Если разделять прям строго, то всё закончится фигнёй типа "это не по моей части" и чехардой перекидывания ответственности друг на друга. Вот вы пишете "код и только код", т.е. такой сеньор в любой момент времени может сказать "я так сделал, потому что мне так сказали"… такой формализованный подход, без вникания в суть.
Если разделять прям строго, то всё закончится фигнёй типа «это не по моей части»
Лучше так — это хоть поправить можно. А вот если «сеньор» начинает делать работу продакта/тим.лида/бухгалтера и уборщицы — беда. Мало того, что он свою работу не делает, так еще, скорее всего, тормозит чужую.
Поверьте, я видел такое в живую и даже врагу такого не пожелаю. Из последнего (с месяц назад): один из «сеньоров», "что-бы разобраться", решил выяснить как работают менеджеры и бухгалтерия у наших клиентов. Итог: таск на 2-3 часа он делал 2 недели, да и то только потому, что уже CTO велел перестать заниматься херней.
Если у программиста нет своих программ, это значит, что он не увлечен всерьез программированиемЗолотые слова!
Написан на TP7. Не прошел по скорости. Критические секции переписаны на ассемблере. Скорость выросла в 15 раз. Самое смешное, что через 25 лет я смогу его прокоментировать. Потому, что очень хотелось понять, что же в компиляторе TP7 настолько не оптимизировано.
kolkoni, у меня два вопроса:
- А кого вы нанимаете?
- Почему, с Вашей точки зрения, задаются странные вопросы на собеседовании?
=====
Как Вы и сами замечали, есть разные типы людей. Я приведу только несколько очень сокращенных примеров:
- Фанат vs линейный программист. Первый будет за open source в свободное время, он будет готов перерабатывать, будет знать новейшие технологии и т.д. Однако второй сможет аккуратно поддерживать legacy проект без мысли его переписать (это особенно важно, если проект будет остановлен через год, так что надо всего лишь продержаться). С другой стороны, если будет задача "сделать быстрее выше сильнее", то фанат с радостью возьмется за задачу, сделает быстрее и лучше отстраненного "линейного программиста". Еще типы можно посмотреть тут, хабре.
- Тактик vs стратег. Первый может быстро и решительно исправить баг в момент релиза, он не впадет в ступор (в том числе и в случае автоаварии, это же личность такая). Однако он будет смотреть на проект как на два спринта, не будет хотеть делать тесты, улучшать environment (это стереотипно, однако идея понятна). Стратег напротив может впасть в ступор при фиксе строчной и критической ошибки, однако он уже рассматривает проект как будто он на кучу лет. Потому тут будут и тесты, и улучшение environment и своевременное обновление зависимостей.
Это стереотипные примеры, в реальной жизни крайних случаев мало. Однако даже на них вы сходу сможете представить, какие задачи давать этим разным людям.
=====
По поводу второго вопроса — если принять за аксиому, что HR не дегенерат, а напротив — опытный сотрудник, который получает бонусы на хороший найм, то почему же он задает идиотские вопросы? Вот несколько ответов (оба мне рассказал HR по опыту работы в США, я не поддерживаю их, однако по ним можно объяснить, почему люди задают "тупые вопросы")
- Экзамен на устойчивость к стрессам. Да, может быть в компании работается спокойно, однако кто захочет нанимать человека, который размякнет при первом же нажиме?
- Проверка на то, что человек действительно хочет здесь работать (сюда можно отнести кучу тупых задач на логику). В крупной компании сложно уволить (по моему опыту), а потому лучше сразу нанять тех, кто действительно хочет здесь работать. А сеньоры с задранными носами пусть идут к конкуренту, правильно ведь?
- Проверка soft skills. Не каждая компания хочет раздувать штат разными сотрудниками. Зачастую есть желание взять не просто кодера по спецификации, а специалиста, которые сможет говорить с бизнесом. Мало кто хочет в будущем получать ответы в стиле "у меня синус равен пяти, потому что в спеке так написано. И вообще, я программист, а не математик".
Важно: в разных компаниях разные требования. Я не говорю, что вопросы выше правильные. Однако зачастую и в них может быть смысл.
Далее вопрос: как вы считаете, насколько хорошо сможет наладить диалог человек, который на вопрос про полюс и медведей начинает отвечать "любой медведь, какого поставили, такой и будет"? Не будет ли он и заказчикам отвечать в стиле "что значит, чему у нас равна пи? Что введете, то и будет, хоть 10". И другой вопрос: он точно хочет здесь работать? Или просто пришел пощекотать эго?
=====
И еще раз повторю мои вопросы к статье:
- А кого вы нанимаете?
- Почему, с Вашей точки зрения, задаются странные вопросы на собеседовании?
А кого вы нанимаете?
Я сам нанимал исключительно линейных программистов, если брать типажи из ссылки.
По типу мышления предпочитаю стратегов. Потому как ошибки лучше вообще не допускать, нежели быстро на них реагировать, плюс умение продумывать и предвидеть очень экономит время в будущем.
Но т.к. выбор не так велик, как хотелось бы, брал людей, которые могут писать адекватный код, могут находить решения и могут делать то что от них требуют. А гигиена кода, принципы построения приложения, тестирование, безопасность и т.п. придет со временем при правильном руководстве.
Почему, с Вашей точки зрения, задаются странные вопросы на собеседовании?
К сожалению ситуация когда HR не дегенерат далеко не аксиома и очень часто тупые вопросы задаются именно поэтому.
Если же брать ситуацию с адекватным HR-ом, то тупые вопросы, на мой взгляд, рождаются из-за 2 основных причин.
1. В крупных компаниях из за бюрократии. Потому что на совещании где участвовало 100500 человек (половина из которых вообще не относятся к программированию) они решили что нужно спрашивать это, то и вот это.
2. И бывает такие вопросы появляются из-за нежелания конкретных сотрудников брать кого то на работу. Например тех.дир. хочет взять своего племянника на должность и начинает у всех приходящих спрашивать какую нибудь муть, а потом такой — а вот у меня есть племянник, он в 100 раз лучше всех этих обормотов.
Важно: в разных компаниях разные требования. Я не говорю, что вопросы выше правильные. Однако зачастую и в них может быть смысл.
Если в них есть смысл, то тогда почему бы hr-ам не озвучивать его? Просто когда меня тупыми вопросами заваливали, никто не объяснял зачем они задаются. И даже если спрашиваешь "зачем Вам это" они не могли нормально ответить, просто потому что сами не знают.
Не будет ли он и заказчикам отвечать в стиле «что значит, чему у нас равна пи? Что введете, то и будет, хоть 10»
Я считаю что между разработчиком и заказчиком обязательно должно быть промежуточное звено, а лучше 2 — те кто понимает заказчика и те кто понимает разработчика (типа product owner и scrum master).
Он точно хочет здесь работать? Или просто пришел пощекотать эго?
Тут уже вопрос о мотивации этого человека и эту самую мотивацию надо знать…
HR не дегенерат далеко не аксиома
Т.е. человек делает свою работу достаточно хорошо, чтобы начальники отделов не жаловались (я не могу ответить за все компании, однако там где я работаю, feedback дойдет крайне быстро), однако при этом он плохой HR, верно? По мне так это нетипичная ситуация. Более того: решение о найме-то (опять говорю о своей среде обитания) принимает команда (вместе с начальником отдела), так что HR'у даже отсеять будет непросто, если уже было техническое интервью.
на совещании <..> 100500 человек <...> решили что нужно спрашивать <...>
Опять-таки, по моему опыту это не так. HR задает одни вопросы (и описывает своё видение). Технари задают свои вопросы (и описывают видение). Потом решение принимает начальник отдела, как я говорил. И вопросы придумываются небольшой группой энтузиастов (просто потому что они нашли время). А далее каждый в команде может предложить свой вопрос (или выкинуть неправильный). А сам список является публичным и исключительно рекомендательным, к тому же он разный для разных отделов. Вот такой вот опыт большой компании, вот такая бюрократия.
тех.дир. хочет взять своего племянника на должность
Вы хоть раз встречали такое в IT? Я вот лишь слышал о подобном. Сейчас же в нашей сфере дикий запад и конкуренция, к тому же в IT работать придется.
Далее: если мы говорим про большую западную компанию, то там существует конфликт интересов (едва ли не на законодательном уровне). Так что техдиру просто не получится взять племянника в свой отдел. Подобное практикуется только в мелком семейном бизнесе, но уж ни как не в крупном. Однако, как я сказал, это реалии западной крупной компании.
между разработчиком и заказчиком обязательно должно быть промежуточное звено, а лучше 2
Он, тут будет только моё мнение. Однако я вот считаю, что хоть кто-то из команды обязан вникать в предметную область. А лучше, чтобы все вникали. Дело в том, что тогда программы делаются действительно для заказчика, а не для спецификации. Разработчик, который изучил материалы по экономике, быстро поймет, что с программой что-то не так, если волатильность доллара стала больше волатильности рубля. И к тому же это никак ему не помешает и знать про Spring, и понимать про виртуальные функции, и осознавать, чем отличается virtual метода от не-virtual.
Просто для сравнения: а сколько должно быть людей-посредников между таксистом и пассажиром?
однако при этом он плохой HR, верно
Не совсем понял как Вы пришли к такому умозаключению.
Я просто констатировал свой опыт общения с 50+ hr-ами разных компаний на разные позиции.
Проблемы такие:
- задают вопросы, которые нашли в интернете или которым их обучили на курсе, но при этом не понимают зачем они их задают, просто потому что «так надо».
- задают технические вопросы, в которых не разбираются, только потому что техспец не захотел на это тратить время и передал список вопрос-ответ hr-у. Как быть? Можно просто не идти на поводу, можно игнорировать и не спрашивать, можно сказать что на всё ответили. В общем при желании поступить правильно можно.
- задают вопросы исходя из своих, зачастую ошибочных, представлений о специалисте
HR'у даже отсеять будет непросто, если уже было техническое интервью
Как мне кажется, hr должен искать кандидатов и среди них отсеивать неадекватных или неподходящих по опыту (не в техническом плане, а в профессиональном).
Вот такой вот опыт большой компании, вот такая бюрократия.
У нас согласованный список обязательных вопросов приходил из головного отделения в Москве.
А у Вас в компании задают на собеседованиях тупые вопросы?
HR задает одни вопросы
Вот к этим вопросам относилось это: 100500 человек <...> решили что нужно спрашивать.
Технари задают свои вопросы
К этим перцам относится эта рекомендация из статьи: НЕ НАДО СПРАШИВАТЬ ТЕОРИЮ вне контекста практического опыта конкретного разработчика!
Вы хоть раз встречали такое в IT?
Да, встречал…
к тому же в IT работать придется.
Как Вы думаете откуда столько сырых, кривых и недоработанных продуктов например в гос секторе?
это реалии западной крупной компании
К сожалению в крупных западных не работал, пишу о реалиях СНГ.
А лучше, чтобы все вникали.
Не многие на это способны, поэтому есть всякие UX дизайнеры например. Все люди думают по разному поэтому лучше чтобы был более компетентный сотрудник, который будет давать четкие указания, тогда будет меньше брака. А дай волю программисту, он сделает что то вроде «Что введете, то и будет, хоть 10».
быстро поймет, что с программой что-то не так
Я не спорю что было бы хорошо. Но большинству программистов, которых Я знаю, не интересно вникать в дебри, при этом это не мешает им писать хороший рабочий код.
а сколько должно быть людей-посредников между таксистом и пассажиром?
Можно и без них, но один бы не помешал (диспетчер).
Нельзя юзверям к разрабам доступ давать…
Самовлюблённые фуллстэки на проверку зачастую оказываются закомплексованными профанами, ставащими энциклопедическое выше человеческого. Где-то тут было про virtual на собеседовании, от не-эйчара, как раз этот случай.
Плох тот разработчик, который не умеет общаться с пользователями
Вот тут Я в корне не согласен. Большинство моих друзей программистов — интроверты и чуть ли не социопаты. Но при этом приложения пишут лучше, чем кто бы то ни было.
Самовлюблённые фуллстэки на проверку зачастую оказываются закомплексованными профанами
Цитируя Ваши же слова: Вы на столько у верены в сво ей не отразимости, что позволяете себе оскорбления широкого круга людей?
Вы выступаете или в роли буфера между разработчиком и «я хочу тут синенькую кнопочку» или сами являетесь генератором такого. Вам кажется что это хорошо, но это не обязательно так.
> ставащими энциклопедическое выше человеческого.
Энцеклопедическое — решение проблемы, а что такое «человеческое»? Жилетку пользователю подставить? Судя по всему у вас просто сэкономили на постановщике задач. Коммуникативным навыкам без компетенции цена не грош, к сожалению, на них зачастую выезжают те, кто не умеет ничего (ещё и горядся этим, считая решающих проблемы ничтожными).
лох тот разработчик, который не умеет общаться с пользователями.
РМ, Бизнес аналитик — это не про нас, так?
С одной стороны пользователи имеющие доступ к разработчикам своими требованиями и претензиями превращают жизнь в ад.
А с другой стороны разработчики, которые не имеют представления для кого они пишут очень быстро отрываются от реальности и перестают понимать ради чего они пишут код.
Почему-то считается, что в hr-рных делах любой итшник разбирается лучше, чем любой hr-щик.
Это не означает, что нет бездарных hr-щиков. Они есть, как и есть бездарные итшники, и любые другие бездарные… (вставить по вкусу).
Плюс, все забывают, что цели у всех разные. Соответственно и действуют по разному.
Не всегда же любой код нужно писать строго по Макконеллу.
Вот у вас 100 бумажных резюме? Разноформатных очевидно. Дальше?
мы же начали обсуждать некого сферического hr'а, который по определению мартышка, потому что не фильтрует, а просматривает.
вот, у hr'а на руках 100 бумажных резюме, дальше то, что ему делать чтобы не быть мартышкой? чего и как фильтровать?
Вот у вас 100 бумажных резюме? Разноформатных очевидно. Дальше?
Половину сразу в мусор не читая. Неудачники в нашей конторе не нужны ;) (ц)
Если на 1 вакансию 100 резюме — значит, требования непрофессионально составлены.
Я повторюсь — я не поддерживаю такой алгоритм найма, просто пересказываю идею. Мб кому-нибудь пригодится.
А зачем хотеть работать здесь?
Во-первых компании выгодно забирать с рынка людей, которые лояльны ей. Собственно, для этого и может использоваться подобный фильтр.
Во-вторых, способов "работы в большой компании" тоже немало, однако интересны вот эти:
- Просто работа от звонка до звонка. И не забываем про "почитать статьи в интернете" и пр.
- Активная работа, вписывание в новые задачи, которые предполагают ответственность.
Далее идея следующая: лояльные грамотные сотрудники выбирают пункт "2" чаще, чем те, которые "просто так пришли". Зачастую у них глаза будут гореть изучать новое и улучшать существующее.
Подобная же тактика (отбор лояльных людей) используется и в маркетинге, с очевидной выгодой. Про макетинг — см. ссылку, там интересна фраза "отсеивать клиентов, которые имеют особо неблагожелательное отношение к компании".
Если контора ищет лояльных работников, это значит что ей нечего предложить в плане мотивации, а потому сотрудники должны быть самомотивированны. В условиях современного ИТ мира эту контору надо обходить по большой дуге.
Это не имеет никакого отношения к лояльным работникам. Я встречал много таких людей, кто с легкостью пойдет работать в любую компанию если ему предложат интересную с его точки зрения задачу. И так-же легко уйдет из этой компании дальше.
Случается и обратная ситуация — человек максимально лоялен к компании т.к. тут можно «от звонка до звонка и не забыть почитать статьи».
С «мега» боссом, с которым ты работать не будешь, и будешь видеть его максимум раз в неделю, но ты ему должен понравиться.
Получилось так — перезвонила HR, сказала что шефу Я понравился, но чтобы меня проверить, он сказал что Я должен поработать пару месяцев с ЗП в 2 раза ниже запрашиваемой и если Я докажу что действительно специалист, то поставят полную ЗП.
Учитывая, что в тот момент в другой конторе мне предлагали выйти сразу, без испытательного срока, то говорить не нужно на какое из предложений Я согласился.
Другая контора нашла сама. Называть не буду, но известная на всю страну. HR только организовали собеседование и провели на место. На самом собеседовании не присутствовали. Только несколько человек из тех с кем сейчас непосредственно работаю и руководитель направления в качестве начальства по видеоканалу.
Все вопросы были общего характера — навыки работы с большими проектами, кто тз ставит, насколь детально прописывалось тз и какова доля самостоятельной разработки. Т.е. определяли кто перед ними — разработчик или кодер.
В целом беседа была непринужденной и располагающей. Хотя не верилось что подойду — совершенно незнакомая предметная область (до этого работал в промавтоматизации, весьма специфическое направление) и абсолютно незнакомая и нечасто встречающаяся у нас платформа IBM i.
Расстались обычным «мы вам сообщим».
На следующий день опять HR — «выслала вам анкету для СБ, заполните и отпрвьте мне».
Дальше 3 месяца «испытательный срок». Но это больше время на обучение (первые два месяца очень тяжелые) и приглядывание к человеку «сработаемся или нет».
Потом узнал что вакансии размещают архитекторы или руководители направлений. Они же выискивают резюме и выставляют на голосование в команде «собеседуем или нет». Если команда решила собеседовать, уже дают задание HR организовать встречу. После всьречи опять голосуют командой — «понравился или нет». Если да — заявка HR на организацию трудоустройства.
Т.о. кадровая служба решает только процедурные вопросы в рамках своей компетенции. А все остально решеается теми, с кем потом придется работать. И, честно скажу, схема видится очень разумной и среди людей, с кем работаю пока не встретил ни одного, кто бы отказал в помощи или консультации. Народа много, но обстановка дружелюбно рабочая.
Виктор, ведущий разработчик, back-end, IBM i.
Тут ведь дело в том, как организован процесс в целом и как в нем распределены роли.
Еще зависит от того, кого именно ищут — человека, который с первого дня (условно) начнет гнать код, или разработчика, с опытом и определнным кругозором, которого придется обучить конкретной специфике, но от которого потом можно ожидать каких-то новых в данной области решений, привнесенных и адаптированных «из прошлой жизни».
У нас, например, поощряется работа «на себя». Немв смысле налево, а в смысле до 20% (негласный порог) времни работаешь не над текущими задачами (при всем их обилии и жесткости сроков), а над какими-то общими библиотеками, которые могут потом эффективно применяться всеми, инструментарием, облегчающим дальнеюшую разработку, нестандартными алгоритмами, повышающми эффективность и т.п. Т.е. поощряется творчество, которое может быть полезно для выполнения текущей работы.
Думаете поможет? :-)
У меня в плане негативного опыта общения с HR, которые начитались вредных советов, сформировалось желание хоть как-то им насолить. Так что если не поможет, то хоть как-то их позлит. :-)
… которого придется обучить конкретной специфике ..
Вот это какая-то болезнь HR-ов «специфика», некоторые этим просто отмазаться от кандидата хотят, сказав что «у нас тут своя специфика, вы нам не подходите».
В остальном, я даже в свое время попал в такую команду, где написал целый движек, который пошел от меня по рукам. В результате, я с начало условно остался без работы, а потом фактически. Ну и команде досталось, теперь каждый по разным фирмам. В общем «все сложно».
Вопросы были больше стратегического характера, никаких тестовых заданий. В основном насколько велики были проекты, насколько велик уровень самостоятельности в принятии решений и т.п.
Ну а без работы тут не останешься. Невпроворот. Есть текучка, есть исправление дефектов с боя, есть достаточно интересные задачи, где решение в лоб по тзине проходит по эффективности и надо придумывать хитрые алгоритмы…
"НЕ НАДО СПРАШИВАТЬ ТЕОРИЮ вне контекста практического опыта конкретного разработчика!"
Конечно, лучше взять дебила!
Как человек может писать на нормальном уровне если он не имеет хотя бы базовое представление о том как работает его экосистема начиная от процессора и памяти, операционная система, виртуальная машина, и до фреймворка???
Также, нормальный кандидат обязан иметь хотя бы общее представление об архитектуре.
А вот практические вопросы можно задавать уже по теме будущего проекта.
В итоге, статья больше вредная, чем полезная!
Как человек может писать на нормальном уровне если он не имеет хотя бы базовое представление о том как работает его экосистема начиная от процессора и памяти, операционная система, виртуальная машина, и до фреймворка???Задайте сеньорам от вебразработки (не важно на каком языке/платформе) простой вопрос:
Как вы понимаете открытое соединение на сервере?
Будете очень удивлены — большинство из них не скажет ничего внятного, но при этом они сайты и веб-приложения делают!
большинство из них не скажет ничего внятного, но при этом они сайты и веб-приложения делают!
Потом те сайты невозможно открыть на плохом соединении. Из старого браузера. На мобильном устройстве…
Как человек может писать на нормальном уровне если он не имеет хотя бы базовое представление о том как работает его экосистема начиная от процессора и памяти, операционная система, виртуальная машина, и до фреймворка???
Да спокойно может. Я даже могу доказать что можно сложный фронтенд писать без знания что такое HTTP/s. Я не говорю что это правильно, но утверждаю что это возможно.
Также, нормальный кандидат обязан иметь хотя бы общее представление об архитектуре.
Начнём с того, что кандидат Вам ничем не обязан.
О как Я люблю таких напыщенных
В итоге, статья больше вредная, чем полезная!
С собеседований, где сидели такие умники как Вы, Я просто вставал и уходил. Вы либо не очень дальновидный, либо не понимаете, что ситуация на рынке такова, что сейчас программисты выбирают компанию в которой работать, а не наоборот.
С Вашим характером могу только пожелать удачи в найме персонала…
Мне не так давно одна относительно известная фирма предлагала чуть ли не топ-зарплату для локального рынка Томска. Однако когда я увидел в каком курятнике они держат своих разработчиков, отсутствие мощных стационарников, хороших кресел.
Я им даже предложил «Приобрету все себе сам (мебель/железо), как я люблю, принести сюда смогу?» — получил отказ.
К таким пойду только если станут последними работодателями для меня.
0. Херы собирают анкеты для первичного отбора
1. Тестовая задача на поиск косяка.
2. тестовая задача на решение.
3. совместный разбор результатов с соискателем.
… и больше интересуют «деловые качества» — остальному можно научиться.
4. далее испытательный срок на реальных задачах.
Собеседования тестируют только навык прохождения собеседований. И придумать какой-то формализованный процесс, который покажет реальную квалификацию практически невозможно. Лучшее что можно сделать, это расспросить о предыдущем опыте, какие задачи приходилось решать, какие задачи нравится решать, какие области интересны. А потом сопоставить это с задачами и областями деятельности компании. Всё остальное от лукавого.
Статья отзывается очень сильно)
Я был начинающим angular разработчиком, проходил собеседование куда-то и общался с hr.
Описал текущий проект, какие бизнес задачи он решает. А она у меня спрашивает - ну вы MVC уже сделали? Каак у меня полыхнуууло. Я блин ангулярщик, какой ещё MVC туды её в качель?! Но думаю, если сказать что она дура - так ведь на следующий этап не пройду. Ну начинаю говорить что-то типа, ну вы знаете, эмвиси архитектура не очень хорошо подходит для ангуляра, у нас сервисы всякие. Она кивает с серьёзным видом, поддакивает.
А через полгода я узнаю, что есть такое понятие MVP))) Вот до сих пор думаю что это было - она сказала MVP а я неправильно распарсил (и тогда я дурак), или она подразумевала MVP а сказала MVC (и тогда она точно дура, хотя может оговорилась просто), или ещё что...
Как вспомню, так смех разбирает :)
Найм программистов. Советы от программиста