Comments 64
За все то время что мне приходится нанимать людей, я выяснил для себя одну весьма важную вещь. Есть кодеры, а есть программисты. И те и другие нужны в команде. Различаю я их так: кодеры, это люди, которые хорошо знают язык, могут ориентироваться в коде, даже, применять какие-то паттерны и методики, а программисты — это люди, которых отличает системный подход к задаче, для них это не только набор классов, они понимают как их код впишется в общую архитектуру, зачем и для чего пишется документация. Программисты, в отличие от кодеров, могут разрабатывать архитектуру, для весьма крупных модулей и прогнозировать интеграцию этих модулей между собой.
Так вот, начинающие программисты, как правило это кодеры среднего (middle) уровня, т.е. это люди, которые могут решать задачи, а не кодировать «отправку мыла с сайта в несколько потоков». И если в начале все начинают с уровня джуниора кодера, то некоторые могут вырасти в программиста, а некоторые так и остаются кодерами. Повторюсь, кодеры тоже нужны, но вот решение крупных комплексных задач, мы будет не под силу, даже несмотря на то, что они могут знать несколько фреймворков и неплохо знать сам язык.
Поэтому я бы различал затраты на джуниора программиста и джуниора кодера. Вторых не очень любят, т.к. затраты на них не отбиваются, либо отбиваются очень долго. Просто различить их на начальном этапе не все могут.
Так вот, начинающие программисты, как правило это кодеры среднего (middle) уровня, т.е. это люди, которые могут решать задачи, а не кодировать «отправку мыла с сайта в несколько потоков». И если в начале все начинают с уровня джуниора кодера, то некоторые могут вырасти в программиста, а некоторые так и остаются кодерами. Повторюсь, кодеры тоже нужны, но вот решение крупных комплексных задач, мы будет не под силу, даже несмотря на то, что они могут знать несколько фреймворков и неплохо знать сам язык.
Поэтому я бы различал затраты на джуниора программиста и джуниора кодера. Вторых не очень любят, т.к. затраты на них не отбиваются, либо отбиваются очень долго. Просто различить их на начальном этапе не все могут.
Это точно. Джуны джунам рознь. Редко, но встречаются такие отвественные, проницательные, любопытные и понимающие потребности пользователей.
Они довольно быстро становятся ведущими, а затем и руководителями и часть из них потом открывают своё дело.
И вот сижу я и думаю: где бы мне найти и как опознать такого джуна для своей компании?
Они довольно быстро становятся ведущими, а затем и руководителями и часть из них потом открывают своё дело.
И вот сижу я и думаю: где бы мне найти и как опознать такого джуна для своей компании?
Я для выявления такого типа джунов предлагаю решить несложную задачку на псевдо-коде. И, глядя, как человек рассуждает в процессе ее решения можно судить в какую сторону больше склоняется. Задачка, естественно, должна быть на подумать, а не на знание вызубренных методов, классов и пр. Ну и плюс ворох различных вопросов.
Кстати, такие вот ответственные, проницательные и любопытные хуже решают задачи поддержки (исправление багов в имеющейся системе). Какое-то время они там роются, что-то улучшают, меняют, но, в конечном итоге, если задачи не усложняются, ответственность не растет, то интерес быстро гаснет. В то же время «кодеры» могут прекрасно справляться с повседневной рутиной, причем, зачастую даже лучше, если речь идет о поддержке.
Кстати, такие вот ответственные, проницательные и любопытные хуже решают задачи поддержки (исправление багов в имеющейся системе). Какое-то время они там роются, что-то улучшают, меняют, но, в конечном итоге, если задачи не усложняются, ответственность не растет, то интерес быстро гаснет. В то же время «кодеры» могут прекрасно справляться с повседневной рутиной, причем, зачастую даже лучше, если речь идет о поддержке.
А как бы вы подошли к найму джуниора в свою компанию? Джуниоры с начальным знание какого языка вас интересуют?
Ещё бы научиться отличать джуниор программиста от ленивого джуниор программиста :)
А так-то в целом % попаданий по тестам с заданиями на мышление, а не специфику языка, достаточно высок.
А так-то в целом % попаданий по тестам с заданиями на мышление, а не специфику языка, достаточно высок.
Мой личный опыт говорит, что единственный способ кардинально поменять зарплату — это сменить работу. Я четыре раза менял работу с удвоением, и сейчас делаю это пятый раз. В то же время рост на одном месте за 4 года — максимум 30%
Мне сложно представить компанию, которая может взять junior и вырастить его сама, адекватно повышая з/пл. По той же причине, что и всегда — «нет пророка в своём отечестве»
Мне сложно представить компанию, которая может взять junior и вырастить его сама, адекватно повышая з/пл. По той же причине, что и всегда — «нет пророка в своём отечестве»
Чтобы повышение зарплат адекватно работало, нужно чтобы в компании были более менее фиксированные категории программистов. С определенными диапазонами зарплат. И если человек дорос из категории «junior», до категории «middle», то это надо оформлять официальным повышением в должности, с соответствующим повышением зарплаты. В итоге компания имеет нового «middle» разработчика, а на освободившееся место «junior», найти нового сотрудника всяко проще, чем нового «middle». Единственное существенное ограничение здесь, это ситуация, когда компании не нужен новый «middle». Но это, чаще всего, означает стагнацию в компании, и тут есть о чем задуматься. Для подросшего программиста это действительно повод уйти в другую компанию. А компания просто найдет себе нового «junior», раз их устраивает разработчик именно такого уровня. Это, кстати, возможность для бывшего «junior» самому побыть в роли наставника, подготовив себе замену, а потом уже уйти. Таким образом он и сам наберется дополнительного опыта, и заодно отдаст свой «долг» компании, которая помогла ему сделать первые шаги.
И еще, на мой взгляд, тут главное не искать себе «junior» разработчика только ради того, чтобы воспитать из него «middle»/«senior». Если вам нужен именно «middle»/«senior», то скорее всего он нужен вам прямо сейчас, а не через полтора-два года. Так что первое, что нужно сделать, прежде чем начать нанимать новичков — выстроить процесс разработки таким образом, чтобы появились задачи, которые можно доверить именно новичкам. Если в компании каждый разработчик ведет свой проект от и до, то нанять новичка будет пустой тратой времени и денег. Да и новичку будет тяжело. Все будут пытаться отбрыкаться от него. Будут те самые вздохи и закатывание глаз, как описано в статье.
И еще, на мой взгляд, тут главное не искать себе «junior» разработчика только ради того, чтобы воспитать из него «middle»/«senior». Если вам нужен именно «middle»/«senior», то скорее всего он нужен вам прямо сейчас, а не через полтора-два года. Так что первое, что нужно сделать, прежде чем начать нанимать новичков — выстроить процесс разработки таким образом, чтобы появились задачи, которые можно доверить именно новичкам. Если в компании каждый разработчик ведет свой проект от и до, то нанять новичка будет пустой тратой времени и денег. Да и новичку будет тяжело. Все будут пытаться отбрыкаться от него. Будут те самые вздохи и закатывание глаз, как описано в статье.
за два с половиной года моя зп увеличилась почти в 4 раза. пришел джуниором.
А бывало так, что находишь новую работу, приходишь к директору с заявлением по собственному желанию, и вдруг выясняется, что тебе очень хотели повысить зарплату раза в 2 или 1.5, но просто не успели об этом сказать. И так несколько раз.
За 10 лет работы, мне ВСЕГДА поднимали зарплату только таким образом.
Плюсую, то же самое. Только формулировка другая — «что мы можем сделать, чтобы ты остался». А ответ обычно «уже ничего», т.к. если уже решил уходить, значит что-то уже нашел.
Имея возможность уйти куда-то на бóльшую зарплату, я бы пришел к начальству и сообщил об этом как можно заранее. Так и дела закрыть комфортно время есть, и сторговаться. А если тебе и здесь предложат больше — еще и профит неслабый.
Зачем так подставлять и нынешнего босса — он явно не ожидал ухода, это может навредить проекту, и себе — потенциальная возможность остаться там, где к тебе лояльны, за те же деньги?
Зачем так подставлять и нынешнего босса — он явно не ожидал ухода, это может навредить проекту, и себе — потенциальная возможность остаться там, где к тебе лояльны, за те же деньги?
Звучит по-рыцарски конечно, но на второй итерации (а вторая итерация будет, т.к. после повышения начальство будет думать еще лет 5 что «тебе недавно повышали») это будет выглядеть как шантаж. Ваши действия?
«Это будет выглядеть как шантаж» – это ваши предрасскудки или неадекватность начальства. Если вы понимаете, что стоите больше (например, вас оценила другая компания), почему бы не прийти и не поговорить об этом честно со своим текущим начальником?
Еще раз — ваши действия на второй итерации? Вы пришли, сказали что уходите, вам подняли ЗП до ожидаемого уровня, вы ушли, вам опять 3-5 лет не поднимают ЗП (это не фантазии, если вы дошли до увольнения в первый раз, скорее всего дойдете и второй), вы нашли другое место работы — ваши действия в этот момент?
Если вам 3-5 лет не поднимают зарплату, то это повод прийти к начальству и потребовать пересмотра как минимум потому, что за 5 лет часть вашей зарплаты съест инфляция.
Мои действия на второй итерации? Точно такие же. Если я знаю, что могу получать значительно больше, и нет ничего такого, что оправдывало бы более низкую зарплату на текущем месте работы, то что зазорного в том, чтобы прийти и сказать: поднимите мне ЗП или я уйду к другому работодателю, потому что мне не комфортно получать значительно меньше, чем я мог бы получать на аналогичной должности в аналогичной компании? Не обязательно конечно говорить так ультимативно, но ведь суть от этого не меняется.
Мои действия на второй итерации? Точно такие же. Если я знаю, что могу получать значительно больше, и нет ничего такого, что оправдывало бы более низкую зарплату на текущем месте работы, то что зазорного в том, чтобы прийти и сказать: поднимите мне ЗП или я уйду к другому работодателю, потому что мне не комфортно получать значительно меньше, чем я мог бы получать на аналогичной должности в аналогичной компании? Не обязательно конечно говорить так ультимативно, но ведь суть от этого не меняется.
"Тебе подняли ЗП, теперь ты обязан не возникать по поводу её роста n лет" — это обыкновенная манипуляция над работниками, которые плохо понимают, что такое бизнес-риски.
"на сколько тебе поднять зп, чтобы ты не ушел" и "на сколько тебе поднять зп, чтобы ты покрыл риск того, что твоя стоимость значительно вырастет, а ты обязался работать за фиксированную зп ближайшие 2 года" — это совершенно разные вещи.
1. Пойти просить надбавку может быть дискомфортно, т.к. мало кто любит быть «просящим»;
2. Лояльность к работодателю уже отсутствует, т.к. работник ощущает, что его интересами пренебрегли, когда рынок зарплат вырос, а его оплата труда не растет. Из-за этого возникает ощущение «ненужности», кажется, что не ценят;
3. Как следствие п.2, если есть предложение от другой фирмы, то возникает как раз ощущение «нужности» другой фирме, а еще и платят больше;
4. Если босс не ожидал ухода, то это в какой-то степени проблема босса, т.к. не платил в рамках рынка или не обезопасил себя от раннего рассторжения трудового договора, если человека сманили. В любом случае, это рынок, управляющий персонал должен учитывать эти риски. К тому же, 2 недели никто не отменял для закрытия всех тех самых дел и найма человека на должность или передачи дел.
Это не истина в последней инстанции, и, судя о всему, у вас другие взаимоотношения с начальством. И по совести, да, я бы тоже предупредил заранее. Но я понимаю и тех людей, кто так не делает.
2. Лояльность к работодателю уже отсутствует, т.к. работник ощущает, что его интересами пренебрегли, когда рынок зарплат вырос, а его оплата труда не растет. Из-за этого возникает ощущение «ненужности», кажется, что не ценят;
3. Как следствие п.2, если есть предложение от другой фирмы, то возникает как раз ощущение «нужности» другой фирме, а еще и платят больше;
4. Если босс не ожидал ухода, то это в какой-то степени проблема босса, т.к. не платил в рамках рынка или не обезопасил себя от раннего рассторжения трудового договора, если человека сманили. В любом случае, это рынок, управляющий персонал должен учитывать эти риски. К тому же, 2 недели никто не отменял для закрытия всех тех самых дел и найма человека на должность или передачи дел.
Это не истина в последней инстанции, и, судя о всему, у вас другие взаимоотношения с начальством. И по совести, да, я бы тоже предупредил заранее. Но я понимаю и тех людей, кто так не делает.
5 удвоений зарплат, это повышение зарплаты в 32 раза. Может конечно я отстал от жизни, но это значит, если бы ты ты начинал карьеру джуном за 300 $/мес. то сейчас ты будешь получать сейчас около 10000 $/мес.
К сожалению, джуны сейчас за 300 долларов не сильно хотят работать, да и сеньорам мало где 10000 долларов в месяц готовы платить.
К сожалению, джуны сейчас за 300 долларов не сильно хотят работать, да и сеньорам мало где 10000 долларов в месяц готовы платить.
Подозреваю, что человек имел в виду в рублях. Так что можете смело делать на 2, получится в 5 раз, т.е. с условных 300$ до $1500. Даже если с 1000$ до $5000 — вариант не невозможный.
Ну так не монотонно. То я дауншифтил 4 года, то рубль. Не всем же з/пл в баксах считают.
И начинал в 1998 с $100, кстати. Потом за 3 года $800.
И начинал в 1998 с $100, кстати. Потом за 3 года $800.
Не совсем понимаю, почему автор говорит о наставничестве джуниоров в побудительной манере и в будущем времени. Неужели у них, на Западе, такого ещё нет? У нас это давно внедрено. Лично я свои первые три года отработал в НИИ практически без денег. Зато у людей, которые там работали, было полно свободного времени, чтобы заниматься со мной. Они научили меня практически всему, что нужно в жизни — SQL, UNIX, Perl и т.д. В общем, уберегли от виндовой ловушки, в которую попадают все новички. Вообще я думаю, что это общий принцип: джуниоры подходят тем, у кого мало денег, но много времени… а сеньоры — тем, у кого наоборот.
Вот я тоже начинал с НИИ, но у них есть очень важная характеристика: качество кода и зачастую работа программы глубоко вторичны. Наличие в организации бардака и в то же время относительная финансовая стабильность дает синьорам возможность создавать внутри нее свои царства, в которых можно в том числе и обучать новичков. Думаю, что в рабовладельческом мире Новой Англии такое может не прокатить, потому что за эффективностью следят.
Эффективность ведь бывает разная. Смотря как её измерять. В бизнесе эффективность, естественно, измеряется в деньгах и зависит от издержек, выручки и рисков. Поэтому в бизнесе джуниорам есть место только там, где они могут помочь снизить издержки за счёт почти бесплатного труда над тупыми и однообразными задачами, которые им можно доверить. Это так и в Новой Англии, и где угодно ещё. Вряд ли джуниоры смогут поднять выручку или снизить риски. Но ведь существует не только бизнес. В мире полно работы по разработке софта, которую так или иначе необходимо делать, но для которой не существует никакой бизнес-схемы. Эффективность такой работы можно измерять не в деньгах. С точки зрения тех, кто делает на софте бизнес, выполнение такой работы за счёт государственных денег будет выглядеть как «распил» бюджета. Но при взгляде под немного другим углом в такой деятельности можно увидеть нечто общественно полезное.
Лол. «Внедрено». В том и суть этого длинного, между прочим, повествования, что подразумевается «брать на работу, на которойПЛАТЯТ». Причем платят, как всем. Там же целые абзацы есть про окупаемость!
Ну, в этой части текст просто неверен. Сама по себе окупаемость, безусловно, возможна. На длинном временном интервале. Но никакого длинного интервала не будет, поскольку нет надёжных инструментов принуждения к лояльности. Там об этом вскользь тоже сказано. Но как-то невнятно. Предлагается задать себе вопрос: «Почему обучившись джуниоры сразу уходят?» Однако не приведён очевидный ответ на этот вопрос, который состоит в том, что обученные джуниоры уходят ровно потому, что компания начинает им недоплачивать в попытке окупить первоначальные вложения в их обучение. Одно с другим связано. Если платить обученным джуниорам, как всем, то не будет желаемой окупаемости. А если им недоплачивать, то никакая корпоративная культура не поможет.
Строго зависит от людей. Работал я как-то с тех лидом у которого был феноменальный нюх на «молодых и голодных». Он умел за 10 минут понять какая мотивация у человека, что им движет и выбирал тех, кто очень хотел пролезть из говна к солнцу и при этом «котелок варит». После наема никаких «сюсюканий»: на тебе рабочий ноут, сам поставь и сконфигурируй себе БД под хранилище данных, BI систему с репортингом, настрой ETL скрипты и залей себе тестовые данные для работы. (и ты сидишь и делаешь это, спрашиваешь, куришь мануалы, набиваешь шишки) Справился? Оке, вот твоя первая тех спека, дедлайн — конец следующей недели, вперед. Ах да, а вот тебе доки (у него была база почти всех «закрытых» документов из дорогих курсов для сертификаций).
И ты опять сидишь и лабаешь.
В итоге, уже через год его «джуны» умели то, что некоторые «синьоры» не научились делать за 10 лет своего опыта. Но надо сказать что и зп повышал он соответственно и регулярно и не было ощущения что ты за 700 баксов делаешь то что обычно делают за 2500.
Конечно, такой метод строго зависит от людей: надо найти того самого молодого и перспективного из хорошего вуза с хорошими мозгами, но при этом амбициозного и готового пахать, но оно того стоило.
Самая большая проблема в его «школе» была только в том, что через 3-4 года, когда приходил момент расти дальше, ты выходишь на рынок и понимаешь что тебе никто не верит, что за свою карьеру ты проработал с таким огромным стеком технологий, умеешь все это делать и готов быть условным Senior/Tech Lead на равне с тем кто «7+ years of solid experience».
И ты опять сидишь и лабаешь.
В итоге, уже через год его «джуны» умели то, что некоторые «синьоры» не научились делать за 10 лет своего опыта. Но надо сказать что и зп повышал он соответственно и регулярно и не было ощущения что ты за 700 баксов делаешь то что обычно делают за 2500.
Конечно, такой метод строго зависит от людей: надо найти того самого молодого и перспективного из хорошего вуза с хорошими мозгами, но при этом амбициозного и готового пахать, но оно того стоило.
Самая большая проблема в его «школе» была только в том, что через 3-4 года, когда приходил момент расти дальше, ты выходишь на рынок и понимаешь что тебе никто не верит, что за свою карьеру ты проработал с таким огромным стеком технологий, умеешь все это делать и готов быть условным Senior/Tech Lead на равне с тем кто «7+ years of solid experience».
Это известная стратегия. Никогда раньше не слышал, чтобы её применяли при подборе персонала, но её очень активно применяют женщины при выборе мужа. Мудрая женщина старается выйти не за того, кто уже состоялся в жизни, а за того, кто «имеет хорошие перспективы». Если сама не уверена в выборе, то показывает потенциального жениха маме, чтобы получить более компетентную оценку. Смысл стратегии в том, что если построить семью с перспективным мужем на том этапе, когда он ещё ничего из себя не представляет, то к тому моменту, когда он полностью раскроет весь свой потенциал, тебя с ним уже будет связывать очень многое. Он уже привыкнет к тому, что его место здесь… с тобой. И это будет фактором, существенно ограничивающим его свободу манёвра в новой ситуации, когда он уже хорошо котируется на рынке. Недостаток у этой стратегии только один. Чтобы успешно её применять, нужна хорошая интуиция, позволяющая не только видеть уже имеющиеся достижения, а ещё и чувствовать потенциал будущего развития. У женщин такая интуиция есть.
Так вот почему среди рекрутеров — одни девчонки.
Скорее всего причина не в этом, а в том, что девчонки дешевле обходятся. За одну и ту же работу им, как правило, можно платить меньше. Ведь им обычно не нужно содержать семью, поскольку они и есть та самая семья, которую кому-то нужно содержать. Насколько я понимаю, девчонки-рекрутёры не участвуют в процессе принятия решений. Они лишь выполняют функции коммуникационного посредника и проводят самый первичный грубый отсев. Хотя, конечно, бывают и исключения. Но я знаю только одно такое. Когда-то давным-давно в КРОКе меня собеседовала женщина. Причём уже после технического интервью. Да и по вопросам было понятно, что это более важный этап в процессе принятия решения.
Shamov, если возможно, расскажите про виндовую ловушку, что это и почему плохо?
Винда, как и любой инструмент, имеет свою область применения. Когда ты владеешь одним инструментом существенно лучше, чем другими, тебе начинает казаться, что всё проще делать этим инструментом. Пока область применения инструмента и область решаемых задач совпадают, проблем нет. Но если вдруг возникнет задача, выходящая за область применения инструмента, ты всё равно начинаешь решать её этим инструментом. По отдельности возникающие задачи очень редко бывают такими, что ради них имеет смысл осваивать принципиально иной инструмент. Всегда кажется, что проще сделать их с помощью хорошо освоенного инструмента. Точнее, даже не кажется… это реально так и есть. Инструмент к задаче совершенно не подходит. Но и другого человека, который бы владел подходящим инструментом, в данном конкретном месте и в данное конкретное время нет. Поэтому, как правило, принимается решение делать так, как умеешь и как проще. Это к вопросу о том, почему это плохо.
А ловушкой эта ситуация является потому, что новичку очень легко попасть в неё неосознанно. Обычно все начинают знакомство с компьютером с игр, т.е. с винды. При переходе к программированию комфортнее делать это в знакомой среде. Обычно говорят, что развитие происходит в тот момент, когда выходишь из зоны комфорта. Но кот Матроскин сказал бы, что для того, чтобы выйти из зоны комфорта, нужно сначала войти в зону комфорта. Это в полной мере относится к новичку, желающему научиться программировать. Он изначально находится не в зоне комфорта и стремится сначала в неё войти. Ближайшая к нему зона называется «программирование под винду». Именно в неё новичок и устремляется. Для него это развитие. Однако далеко не каждому потом удаётся накопить достаточный импульс мотивации, чтобы покинуть эту зону комфорта и продолжить своё развитие. Очень многие остаются на виндовой орбите на всю жизнь. И с каждым годом покинуть эту орбиту всё сложнее. Масса накопленного виндового опыта со временем только растёт. И сила гравитации притягивает к винде всё сильнее.
А ловушкой эта ситуация является потому, что новичку очень легко попасть в неё неосознанно. Обычно все начинают знакомство с компьютером с игр, т.е. с винды. При переходе к программированию комфортнее делать это в знакомой среде. Обычно говорят, что развитие происходит в тот момент, когда выходишь из зоны комфорта. Но кот Матроскин сказал бы, что для того, чтобы выйти из зоны комфорта, нужно сначала войти в зону комфорта. Это в полной мере относится к новичку, желающему научиться программировать. Он изначально находится не в зоне комфорта и стремится сначала в неё войти. Ближайшая к нему зона называется «программирование под винду». Именно в неё новичок и устремляется. Для него это развитие. Однако далеко не каждому потом удаётся накопить достаточный импульс мотивации, чтобы покинуть эту зону комфорта и продолжить своё развитие. Очень многие остаются на виндовой орбите на всю жизнь. И с каждым годом покинуть эту орбиту всё сложнее. Масса накопленного виндового опыта со временем только растёт. И сила гравитации притягивает к винде всё сильнее.
Я вот только одного не понял — почему проблема относится именно к винде?
Судя по написанному, винда — первое, с чем, скорее всего, встретится новичок-разработчик. Но, скажем, если тот же новичок (с теми же скиллами) встретится в начале не с виндой, а, скажем, с разработкой под Mac? Ну, скажем, будет у него хорошее место джуниора в хорошей компании под такой проект.
Так вот, — после этого, какая вероятность что этот новичок будет активно смотреть по сторонами (как разработчик), пробовать новые технологии и пр., а не закопается только в проприетарных решениях?
Вот у меня ощущение, что любознательность и желание развиваться в профессиональной области не зависят (ну, не сильно зависят) конкретно от того, что на первом компьютере была винда. Как то так)
Судя по написанному, винда — первое, с чем, скорее всего, встретится новичок-разработчик. Но, скажем, если тот же новичок (с теми же скиллами) встретится в начале не с виндой, а, скажем, с разработкой под Mac? Ну, скажем, будет у него хорошее место джуниора в хорошей компании под такой проект.
Так вот, — после этого, какая вероятность что этот новичок будет активно смотреть по сторонами (как разработчик), пробовать новые технологии и пр., а не закопается только в проприетарных решениях?
Вот у меня ощущение, что любознательность и желание развиваться в профессиональной области не зависят (ну, не сильно зависят) конкретно от того, что на первом компьютере была винда. Как то так)
Если новичок изначально встретится с разработкой под Мак, то это будет очень редкий случай. Это тоже плохо. Но эта проблема не имеет столь массового характера.
Разумеется, любознательность не зависит от того, что на первом компьютере была винда. Но если любознательности нет, то от того, что на первом компьютере была винда, зависит то, кем человек в итоге станет. А у большинства её нет. По крайней мере, её нет в количестве достаточном для того, чтобы вырваться из виндовой ловушки самостоятельно. И спасти в этом случае может только опытный наставник.
Разумеется, любознательность не зависит от того, что на первом компьютере была винда. Но если любознательности нет, то от того, что на первом компьютере была винда, зависит то, кем человек в итоге станет. А у большинства её нет. По крайней мере, её нет в количестве достаточном для того, чтобы вырваться из виндовой ловушки самостоятельно. И спасти в этом случае может только опытный наставник.
Я вроде как и не джун но работу в компании один фиг найти не могу. Сейчас начал фрилансить. Думаю собрать много отзывов положительных и тогда будет проще устроится хотя бы джуниором
Общий совет, надеюсь, что будет полезным. Подойди к вопросу поиска работы серьезно. Часть материалов (linkedin-аккаунт, резюме, отзывы) должны быть заточены на девочек-HR-очек. Другая часть (сделанные проекты, вклад в opensource и самое главное github-аккаунт) должны быть заточены на мощных бородатых тимлидов или тимлидерш, которым девочки-HR-очки дадут резюме после предварительной фильтрации.
Работаю уже 4й месяц Junior Java Developer'ом, очень повезло с компанией, у меня хороший наставник
меня наймите джуниором уже который месяц ищу на разраба C++
Я бы разделил звание старший/рядовой/младший разработчик на несколько составляющих: экспертная, кругозор, интеллект.
• Экспертная составляющая отражает глубину знаний конкретных технологий. На сколько человек точно и досканально представлет внутренее устройство и принцип работы технологии или инструмента.
• Кругозор говорит о том, какие смежные технологии/области изучал человек при решении проблемы.
• Интеллект говорит о способе и эфективности мышления: человек в состоянии выявить проблему, изучить инструменты для её решения и выбрать наиболее подходящие.
В российской практике очень часто на позицию старшего разработчика отбирают только по экспертным знаниям. На собсеседовании спрашивают лютейшие тонкости, кандидат все отвечает, но когда сталкивается с задачей в которой нет опыта, то возникают проблемы, потому как не хватает кругозора и умственных способностей для её решения.
Ошибка заключается в том, что его не спрашивали, а как бы он решал новую задачу, по которой читал только теорию и давно. И вот тут срабатывает кругозор и интеллект, благодаря которым и формируются экспертные знания.
Понятным становится недовольство способными младшими разработчиками: «Мол я не знаю, но вот изучил и применил бы так и так», и его решение имеет верное направление. Т.к. интеллект на уровне, а тонкости и кругозор он получает в процессе.
При устройстве на работу выбирайте те компании, которые ищут умных людей, готовых развиваться и умеющих двигаться в верном направлении. На моей практике таких компаний было две, где на собеседовании выявляли уровень по трем составлящим.
А способному младшему всегда найдется работа, при условии, что в старшем и рядовых составляющие сбалансированы.
• Экспертная составляющая отражает глубину знаний конкретных технологий. На сколько человек точно и досканально представлет внутренее устройство и принцип работы технологии или инструмента.
• Кругозор говорит о том, какие смежные технологии/области изучал человек при решении проблемы.
• Интеллект говорит о способе и эфективности мышления: человек в состоянии выявить проблему, изучить инструменты для её решения и выбрать наиболее подходящие.
В российской практике очень часто на позицию старшего разработчика отбирают только по экспертным знаниям. На собсеседовании спрашивают лютейшие тонкости, кандидат все отвечает, но когда сталкивается с задачей в которой нет опыта, то возникают проблемы, потому как не хватает кругозора и умственных способностей для её решения.
Ошибка заключается в том, что его не спрашивали, а как бы он решал новую задачу, по которой читал только теорию и давно. И вот тут срабатывает кругозор и интеллект, благодаря которым и формируются экспертные знания.
Понятным становится недовольство способными младшими разработчиками: «Мол я не знаю, но вот изучил и применил бы так и так», и его решение имеет верное направление. Т.к. интеллект на уровне, а тонкости и кругозор он получает в процессе.
При устройстве на работу выбирайте те компании, которые ищут умных людей, готовых развиваться и умеющих двигаться в верном направлении. На моей практике таких компаний было две, где на собеседовании выявляли уровень по трем составлящим.
А способному младшему всегда найдется работа, при условии, что в старшем и рядовых составляющие сбалансированы.
Для тех, кто рассуждает «сложно найти хорошего, целеустремлённого...»:
1. Мотивация, горбатого исправит.
2. Пробные пару месяцев никто не отменял.
3. Собеседование — отсортировка.
4. При качественном подходе к собеседованию, проверке знаний и отбору сотрудников, максимум что можно потерять: одну месячную зарплату
1. Мотивация, горбатого исправит.
2. Пробные пару месяцев никто не отменял.
3. Собеседование — отсортировка.
4. При качественном подходе к собеседованию, проверке знаний и отбору сотрудников, максимум что можно потерять: одну месячную зарплату
Данная статья задела меня за живое, т.к. в какой-то мере я нахожусь в том самом состоянии, которое описывает автор, а часть вещей ещё предстоит преодолеть.
Кратко: Наставничество — это отличный вариант обучения программистов даже с нуля (как в моем случае), вещи, указанные автором, работают, я проверил на себе.
Подробно:
В силу обстоятельств 10 лет тому назад я не стал программистом, занялся армией (или она мной), а потом продажами в строительном бизнесе. Но примерно полгода тому назад (спустя 5 лет успешной работы) пришло ощущение бессмысленности ежедневной деятельности, а также появилось желание что-то изменить. И я выбрал RubyOnRails. Вот об этом выборе я хочу чуть подробнее рассказать. Мне повезло, что один из моих друзей работает в этой области и был готов мне помочь начать этот путь.
На начальном этапе было изучение Ruby при помощи Codecademy. Это мог был быть любой другой сайт, как указывает также автор статьи, но у меня был этот. И для изучения базовых основ мне он очень пригодился.
На следующем этапе лично для меня было открытие мира Linux-систем, с которыми я был знаком лишь чуть. Так что установленная Ubuntu сначала на виртуальную машину, а спустя три месяца — на ноутбук, здорово помогла размять мозги. В это же время происходило знакомство с Git. Всё это мне помог осознать и в какой-то степени установить (нет-нет, кнопку «Далее» за меня никто не жал, сам справился) мой друг (наставник). Он предоставил мне для ознакомления наиболее свежие, полные и полезные (на его взгляд) туториалы и гайды.
Третий этап — написание бота для Телеграм, который работал с API вконтакте.
Четвертый — знакомство с Rails.
Пятый — написание блога (тот самый, что за 15 минут, который я делал день).
Шестой — написание своей альтернативы фотохостинга (крайне схематичного, конечно).
Седьмой — работа над реальным проектом сайта, где на текущий момент я реализую самостоятельно небольшие части функционала.
Параллельно я делал каты по Ruby на Codewars (настоятельно советую подобный формат, это отличная подготовка к собеседованию для уже знающих и великолепный способ потренировать разнообразные фундаментальные аспекты языка для тех, кто только учится).
Это все подпадает под тот стиль наставничества, который описывает автор статьи, с разбивкой на небольшие задачи, отслеживанием прогресса, постепенным увеличением сложности (хотя на мой взгляд с Rails переходы по сложности довольно резкие в рамках решаемых задач). Важный аспект, о котором в статье упоминается, это психологический комфорт работы. Например, чтобы не было стыдно за тот код, который ты пишешь. Мой наставник на 7 лет младше меня. Думаю, вы понимаете, насколько важно в таком случае не отбить желание работать совместно резкой критикой тех или иных вещей. Как говорил один умный товарищ из Яндекса в своем выступлении, чем старше становишься, тем более стыдно бывает обратиться за помощью к молодым (которые быстрее и вообще выносливее), но нужно себя перебарывать. Мне повезло с наставником и он оказался способен к такой деятельности: направлять, критикуя профессионально. К нему хочется обращаться за советом. Однако много ли таких людей? На мой взгляд также тяжело найти (в рамках фирмы) человека, который был бы способен являться для Junior-разработчика эффективным наставником, как и для фирмы тяжело найти перспективного разработчика, который будет гореть желанием развиваться и не уйдет в другую фирму через полгода (да, это вопрос корпоративной политики и уровня зарплат, но всё же).
Как итог могу сказать, формат наставничества действительно работает, как минимум на мне.
Кратко: Наставничество — это отличный вариант обучения программистов даже с нуля (как в моем случае), вещи, указанные автором, работают, я проверил на себе.
Подробно:
В силу обстоятельств 10 лет тому назад я не стал программистом, занялся армией (или она мной), а потом продажами в строительном бизнесе. Но примерно полгода тому назад (спустя 5 лет успешной работы) пришло ощущение бессмысленности ежедневной деятельности, а также появилось желание что-то изменить. И я выбрал RubyOnRails. Вот об этом выборе я хочу чуть подробнее рассказать. Мне повезло, что один из моих друзей работает в этой области и был готов мне помочь начать этот путь.
На начальном этапе было изучение Ruby при помощи Codecademy. Это мог был быть любой другой сайт, как указывает также автор статьи, но у меня был этот. И для изучения базовых основ мне он очень пригодился.
На следующем этапе лично для меня было открытие мира Linux-систем, с которыми я был знаком лишь чуть. Так что установленная Ubuntu сначала на виртуальную машину, а спустя три месяца — на ноутбук, здорово помогла размять мозги. В это же время происходило знакомство с Git. Всё это мне помог осознать и в какой-то степени установить (нет-нет, кнопку «Далее» за меня никто не жал, сам справился) мой друг (наставник). Он предоставил мне для ознакомления наиболее свежие, полные и полезные (на его взгляд) туториалы и гайды.
Третий этап — написание бота для Телеграм, который работал с API вконтакте.
Четвертый — знакомство с Rails.
Пятый — написание блога (тот самый, что за 15 минут, который я делал день).
Шестой — написание своей альтернативы фотохостинга (крайне схематичного, конечно).
Седьмой — работа над реальным проектом сайта, где на текущий момент я реализую самостоятельно небольшие части функционала.
Параллельно я делал каты по Ruby на Codewars (настоятельно советую подобный формат, это отличная подготовка к собеседованию для уже знающих и великолепный способ потренировать разнообразные фундаментальные аспекты языка для тех, кто только учится).
Это все подпадает под тот стиль наставничества, который описывает автор статьи, с разбивкой на небольшие задачи, отслеживанием прогресса, постепенным увеличением сложности (хотя на мой взгляд с Rails переходы по сложности довольно резкие в рамках решаемых задач). Важный аспект, о котором в статье упоминается, это психологический комфорт работы. Например, чтобы не было стыдно за тот код, который ты пишешь. Мой наставник на 7 лет младше меня. Думаю, вы понимаете, насколько важно в таком случае не отбить желание работать совместно резкой критикой тех или иных вещей. Как говорил один умный товарищ из Яндекса в своем выступлении, чем старше становишься, тем более стыдно бывает обратиться за помощью к молодым (которые быстрее и вообще выносливее), но нужно себя перебарывать. Мне повезло с наставником и он оказался способен к такой деятельности: направлять, критикуя профессионально. К нему хочется обращаться за советом. Однако много ли таких людей? На мой взгляд также тяжело найти (в рамках фирмы) человека, который был бы способен являться для Junior-разработчика эффективным наставником, как и для фирмы тяжело найти перспективного разработчика, который будет гореть желанием развиваться и не уйдет в другую фирму через полгода (да, это вопрос корпоративной политики и уровня зарплат, но всё же).
Как итог могу сказать, формат наставничества действительно работает, как минимум на мне.
Нужно просто понимать, что ситуации бывают разные. Подход, который советует автор статьи, очень хорошо подходит для больших состоявшихся компаний с готовым продуктом, кучей legacy-кода и неприоритетных задач. Если же у вас команда из пяти человек, жесткие сроки и 85% времени пишется новый функционал, то нанимать джуниоров вместо миддлов и сеньоров будет провальной стратегией. Потому что в данном случае, найми ты хоть трех джуниоров с зарплатой 40к — они не дадут такой эффективности, какую бы дал один сильный миддл или сеньор за 150к.
Доводилось нанимать недавно довольно приличное количество народа. Зачастую сеньоры знают увы меньше джуниоров, хотя и стоят при этом больше. Но хороший сеньор, которого да, не просто найти, может влиться в разработку сразу через пару недель, а вот джуниор даже хороший будет разгоняться с месяц. Опять же долгосрочно джуниор, конечно хорошо, особенно если не убежит через годик обучения но вот краткосрочно один джуниор и один синьор в комманде — это 1.25 производительности синьора.
Будучи на практике знакомым с php около 8 лет и имея за плечами большое кол-во своего кода, несколько крупных проектов, кучи оптимизаций, поиска багов, дыр и тд рутины в режиме фултайм загрузки — никуда не собираюсь устраиваться по этому направлению НЕСМОТРЯ на реальную нужду («в бизнесе случилось за руль такси сесть»).
И объясню почему: если опустить банальные личные потребности в уважении, то я считаю, IT-компании (большинство, исходя из текста вакансий) не дают ощущения «Ай молодца, так держать». Имею в виду те компании, которые вот также ищут программистов с какими-то своими размышлениями о профитах и прочем денежном. Только контроль, контроль, один контроль на этих лицах.
Такие предпочитают нанять милых девочек-рекрутеров и, простите, маркетолога-начальника с общими вопросами и нулем заинтересованности в деле. Возможно таких начальников и самих жизнь за щеки треплет, но им не место среди программистов.
Я к чему это написал. Если вам встречается Джуниор с маломальским опытом, который загорается от загадки эйнштейна про дома — это ценнейший актив, если вы этого не понимаете — то увы и ах. Если не можете найти ему подходящей работы — увы и ах. Если не можете организовать ему практику — увы и ах.
Увы и ах — это не он 0.01% работы выполняет за 30к, а это у вас нет достаточной компетенции для организации работы. Ищите верстальщиков, пусть они вам программы верстают, а вы их на 3d-принтере в виде 3d-открыток и в бухгалтерию.
Абсолютно все программисты были когда-то новичками, но только лучшие из нас — навсегда новички.
?>
И объясню почему: если опустить банальные личные потребности в уважении, то я считаю, IT-компании (большинство, исходя из текста вакансий) не дают ощущения «Ай молодца, так держать». Имею в виду те компании, которые вот также ищут программистов с какими-то своими размышлениями о профитах и прочем денежном. Только контроль, контроль, один контроль на этих лицах.
Такие предпочитают нанять милых девочек-рекрутеров и, простите, маркетолога-начальника с общими вопросами и нулем заинтересованности в деле. Возможно таких начальников и самих жизнь за щеки треплет, но им не место среди программистов.
Я к чему это написал. Если вам встречается Джуниор с маломальским опытом, который загорается от загадки эйнштейна про дома — это ценнейший актив, если вы этого не понимаете — то увы и ах. Если не можете найти ему подходящей работы — увы и ах. Если не можете организовать ему практику — увы и ах.
Увы и ах — это не он 0.01% работы выполняет за 30к, а это у вас нет достаточной компетенции для организации работы. Ищите верстальщиков, пусть они вам программы верстают, а вы их на 3d-принтере в виде 3d-открыток и в бухгалтерию.
Абсолютно все программисты были когда-то новичками, но только лучшие из нас — навсегда новички.
?>
Все так. И то, что работу найти — это задача руководства, и то что джуниор со взглядом горящим — это актив. Только работаем мы не просто, чтобы работать; а зарабатываем деньги для себя, компании и инвесторов.
А дальше у нас есть бюджет, с помощью которого надо сделать то, что маркетинг уже пообещал месяц назад клиентам. И джуниор, конечно, сможет принести кучу пользы, но когда-то потом и хорошо если у нас есть некоторый диапазон значений, куда его можно воткнуть подвинув все остальное. А если нет — то все то же самое. Мир полон нереализованых возможностей и действительно хороших, но не нужных или нужных, но не сейчас вещей.
Но это мы говорим о джуниорах звездах, которые согласно нормальному распределению встречаются так же часто как и сеньоры звезды.
А дальше у нас есть бюджет, с помощью которого надо сделать то, что маркетинг уже пообещал месяц назад клиентам. И джуниор, конечно, сможет принести кучу пользы, но когда-то потом и хорошо если у нас есть некоторый диапазон значений, куда его можно воткнуть подвинув все остальное. А если нет — то все то же самое. Мир полон нереализованых возможностей и действительно хороших, но не нужных или нужных, но не сейчас вещей.
Но это мы говорим о джуниорах звездах, которые согласно нормальному распределению встречаются так же часто как и сеньоры звезды.
Да, вы верно подметили, что речь идет только о звездных джуниорах. Тех, которые могут сделать в приемлемом качестве от 50% работы самостоятельно, а остальные 50% с небольшими подсказками, наводками, но сделать.
Тех, кто просто сидит и «учится» месяцами, я не могу даже джунами назвать. Речь только о тех, кто уже может работать.
Тех, кто просто сидит и «учится» месяцами, я не могу даже джунами назвать. Речь только о тех, кто уже может работать.
Я считаю, что основная причина не нанимать джуниоров — это тот факт, что качество проекта получается как среднее арифметическое навыков всех его участников, несмотря на всё лидерство тимлида. Так что джунов берут:
- компании, ориентированные на минимальную стоимость в ущерб качеству — т.н. заказная разработка
- достаточно крупные компании, где всегда есть низкоквалифицированная работа без особых требований к качеству
- крупные компании, которые могут позволить себе отобрать многообещающих студентов, вырастить их и удержать их. У Яндекса и Дойчебанка, например, такие программы есть.
Основная причина не нанимать джунов, это то, что далеко не все компании могут себе такое позволить.
Что я вижу вокруг, так это то, что джунов нанимают либо очень маленькие компании, у которых мало денег и несложные задачи, либо непрофильные компании, например отделения банков. Мидл или сеньор для них во-первых дорогой и во вторых он там на долго не задержится, потому, что ему будет неинтересно.
Также, джунов нанимают большие профильные компании, у которых достаточно большие команды работают над проектом и джуны для них достаточно выгодны. Во-первых, им можно поручать работу, которую не любят выполнять синьоры, они дешевы, ну и когда он учится, он вникает в специфику компании, и потом, даже если уйдет, то большая вероятность, что он вернется назад еще более заматерев.
А вот для средних компаний джуны могут быть в тягость. Да, им можно мало платить, но когда у тебя над проектом работает всего два человека, то валить всю работу на сеньора… знаете, ну он просто уйдет. Во-вторых, если джун толковый, то рано или поздно, ему просто станет скучно, и он уйдет. Вероятность возвращения его назад в стеднюю компанию довольно мала. И получается, что ты взял человека, обучил, и только он стал пригодным к работе — ты его потерял. А бестолковых джунов держать, смысла мало.
Вот и получается, что имеем то, что имеем.
P.S. Да и еще, у больших, профильных компаний, очень пользуется популярностью брать студентов, пока те еще учатся. Это выходит еще дешевле, и быстре толковые от бестолковых отсеиваются.
Что я вижу вокруг, так это то, что джунов нанимают либо очень маленькие компании, у которых мало денег и несложные задачи, либо непрофильные компании, например отделения банков. Мидл или сеньор для них во-первых дорогой и во вторых он там на долго не задержится, потому, что ему будет неинтересно.
Также, джунов нанимают большие профильные компании, у которых достаточно большие команды работают над проектом и джуны для них достаточно выгодны. Во-первых, им можно поручать работу, которую не любят выполнять синьоры, они дешевы, ну и когда он учится, он вникает в специфику компании, и потом, даже если уйдет, то большая вероятность, что он вернется назад еще более заматерев.
А вот для средних компаний джуны могут быть в тягость. Да, им можно мало платить, но когда у тебя над проектом работает всего два человека, то валить всю работу на сеньора… знаете, ну он просто уйдет. Во-вторых, если джун толковый, то рано или поздно, ему просто станет скучно, и он уйдет. Вероятность возвращения его назад в стеднюю компанию довольно мала. И получается, что ты взял человека, обучил, и только он стал пригодным к работе — ты его потерял. А бестолковых джунов держать, смысла мало.
Вот и получается, что имеем то, что имеем.
P.S. Да и еще, у больших, профильных компаний, очень пользуется популярностью брать студентов, пока те еще учатся. Это выходит еще дешевле, и быстре толковые от бестолковых отсеиваются.
— Вы не боитесь что вы обучите вашего работника и он от Вас уйдёт?
— Я больше боюсь что я его не обучу и он останется
— Я больше боюсь что я его не обучу и он останется
Это все лирика. Берут тех, кто приносит бизнесу максимальную отдачу
Очень в тему статья. Достаточно посмотреть вакансии для NY. Одни синьеры и лиды нужны, даже мидлов редко встретишь, чего уж говорить про новичков.
Sign up to leave a comment.
Почему стоит нанимать джуниоров