Comments 324
Достаточно долго я думал, что когда нибудь я буду знать всё, что нужно. Я приходил собеседоваться на позицию мидла, а сам думал, что недотягиваю. У них так много всего в требованиях, я не знаю все эти вещи на хорошем уровне. Меня брали, но само интервью только подтверждало мои мысли. Ребята с обратной стороны скайпа — очень крутые люди. Я не знаю как, но за часовой разговор они успевают глубоко засунуть в мою голову мысль, что их умения — недостижимая величина.
Открою секрет — тут дело не в ребятах по ту сторону скайпа, а в вас.
К собеседованиям можно относиться, как к экзамену со строгим преподом, который вас ни за что не допустит к дальнейшей учебе, и вся ваша жизнь пойдет под откос.
Или можно относиться к ним в разы проще.
Даже собеседование в условный гугл — это не экзамен со светилами мирового программирования, а задача вида «бежать быстрее другого» со странными и отчасти бессмысленными критериями для этого «быстрее»; и только из-за того, что и без вас очередь большая. А там, где очередей нет — всё гораздо более по-человечески, или, если не по-человечески — это место можно немедленно покидать.
Я часто спрашиваю вопросы на которые не знаю ответа или понимаю, что правильного ответа нет.
Обычно вопрос начинается с "как бы вы решили такую проблему...".
Я просто любое собеседование и любые вопросы изначально рассматриваю не как тест, а как дискуссию/обмен мнениями. И даже если меня спрашивают про "сортировку пузырьком", то я не начинаю сразу строчить решение, а сначала просто немного "общаюсь" и задаю вопросы. И иногда получается так что и решение уже никому не нужно.
П.С. Но естественно надо понимать что это всё хорошо работает в нынешней ситуации на рынке труда, когда я могу спокойно развернутся и уйти практически с любого собеседования. Ну потому что вакансий полно и я знаю что без работы не останусь. То есть если утрировать, то я пожалуй немного "зажрался" :)
Тогда у вас действительно другая ситуация и вам пожалуй стоит проигнорировать мой совет :)
Да, можно предположить что знание внутреннего устройства неких вещей из стандартной библиотеки позволит «более правильно» эти вещи использовать — так в чём проблема именно эти кейсы и спрашивать?!
Я вот в упор не вижу проблемы подбора специалистов и определения планки ЗП для них, всё же просто как Евклидово пространство: у тебя (работодателя) есть задачи, для выполнения которых текущего персонала не хватает, и у тебя есть бюджет — размещаешь вакансию(ии) и начинаешь сортировать пришедших на собеседование кандидатов по их пригодности для решения твоей конкретной задачи, затем пропорционально этой «пригодности» высчитываешь им ЗП (берёшь 80-90%% своего бюджета и делишь на количество людей учитывая их скилы, чтобы этот коллектив сумел в имеющиеся сроки решить имеющуюся задачу) и делаешь офферы, затем ждёшь ответом и далее уже корректируешь эту «систему кандидатов» исходя из реалий. Это «база». А дальше можно учитывать «перспективу»: оценить пригодность каждого кандидата для наиболее вероятных будущих задач и учитывать этот параметр тоже (с пониженным приоритетом, разумеется). А вместо этого на собесах спрашивают малоизвестные вещи, которые, в случае надобности, найдутся на первой странице результатов поиска в гуглу.
Ещё очень сильно бомбит порой от того что всем нужны мартышки, которые будут клепать шаблонный код по чёткой указке тимлида, а ты, блин, так не можешь — тебе надо шевелить мозгами больше чем пальцами, каждый пункт ТЗ обсыпать вопросами чтобы понять зачем оно именно так, ведь можно же и иначе, ну и так далее…
Упрощенный случай: одна вакансия. Кандидатов довольно много откликнулось. Как вообще понять подходит хоть кто-то из них для предполагаемых задач?
Ваша система хороша при условии, что у вас бесконечное время, бесконечный поток вменяемых и честных людей и машина для чтения мыслей. Гм, не, даже этого не хватит, как же вы будете создавать задачи на собесе на основе боевых задач? У вас есть для этого метод?
Та самая очередь в виде сотен присылаемых резюме — это не очередь, это инфошум.
Чем компания крупнее, тем чаще туда отправляют резюме условные «случайные» люди, которые просто видят название компании и отправляют туда CV на удачу.
В итоге, на многие позиции действительно попадают люди, которые произвели «благоприятное впечатление» и просто умеют хорошо проходить интервью. Или просто уже нужен «хоть кто-то, а потом разберемся».
За десять лет у меня набралось собеседований 7 (о которых помню), ну может о 2-3 забыл.
А на людей, которые раз в полгода-год меняют работу я, будучи собеседующим, относился с большой осторожностью.
Каждый раз меняя работу я стараюсь пройти 5 — 10 собесов. Чтобы с веером офферов на руках выбирать спокойно
Как вы это перевариваете?
Кроме того если собеседование успешного, то работодатель обычно хочет чтоб ты вышел как можно быстрее и главное ждёт твоего твёрдого да (или обоснованного нет). Что вы делали в такой ситуации, говорили мне нужно месяц подумать? Или у вас было иначе?
Опять же лично мой модус операнди.
Во первых фирмы, с тестовыми заданиями до(а вообще-то даже просто не во время) интервью, я обычно просто игнорирую. По моему опыту это либо огромные, либо просто неадекватные фирмы. И в таких лично я всё равно работать не хочу.
А во вторых после успешного собеседования можно спокойно сказать что ты получил лучшие условия в другой фирме или "апгрейд" на старом месте. Это если начнут спрашивать. Но обычно даже и не спрашивают и хватает простой формулировки вроде "я подумал и решил всё-таки к вам не идти".
Компания набирала большое количество монтажников, и для ускорения процесса привлекли НРов с биржи труда и одного популярного сайта вакансий.
Надо понимать, что запросы к монтажнику, в общем-то, невысокие: уметь пользоваться электроинструментом, бить трубу/кидать кабель, читать планы. Ну и к качеству работы у нас высокие запросы, всё прямое должно быть ровненько, всё изогнутое — либо аккуратной дугой, либо строго под 90 град.
Итак, начали к нам на собеседования приходить люди от этих НРов и задавать оччень странные вопросы, показывая свою полную неосведомлённость о условиях работы, уровне зарплаты и предъявляемых требованиях.
В качестве «не предвзятого эксперта» привлекли меня, с заданием создать себе максимально подходящее резюме и попытаться пообщаться и выяснить, какие же такие сладкие песни поют нашим кандидатам.
Резюме создал и пару недель ждал заветного звонка, попутно отбиваясь от всех прочих предложений. Так пару раз сталкивался с возмущенными криками «Как это вы не хотите у нас работать?!?», прям необычный такой экспериенс…
Может локальные особенности, но большинство не требует тестовое задание. А их тех, кто требует часто удовлетворяются сделанным для кого-то другого. Делаю только реально интересные мне.
Подумать время, да, неохотно выделяют больше пары дней, если вакансия конкретная, одно место, а не просто прочесывают рынок по принципу "был бы разработчик, а задачи найдём". А вот ждать после принятия офера могут и два месяца, когда объясняешь, что месяц нужно отработать и хотелось бы в отпуск сходить.
Итого месяц ожидания работодателя.
Я, получается ретроспективно, взял за основное правило просто отдыхать между работами с недельку.
В Швейцарии отработка у предыдущего работодателя 3 месяца, ну и потом никто косо не посмотрит, если ты ещё месяцок балду попинаешь, прежде чем впрячься в новую работу
Но ведь большинство собеседований предполагают тестовое задание… Как вы это перевариваете?
Лично я не делаю больше тестовых заданий.
Два раза делал. Моё поделие, слепленное на коленке за один вечер, более-менее решало задачу и не дохло без особых на то причин. Но людям с той стороны скайпа никогда не нравился метод решения. Как только я замечаю, что решение оценивают исходя из субъективной правильности метода — делаю ноги.
Моё поделие, слепленное на коленке за один вечер, более-менее решало задачу и не дохло без особых на то причин. Но людям с той стороны скайпа никогда не нравился метод решения. Как только я замечаю, что решение оценивают исходя из субъективной правильности метода — делаю ноги.
Но это же наоборот хорошо.
Вы получаете дополнительные критерии вменяемости потенциального работодателя. Более того, вы их начинаете получать еще до того, как возьметесь делать тестовое задание — потому что по самому заданию тоже многое можно сказать о конторе.
Если что-то не нравится в задании — это повод развернуться и уйти, да. Если что-то не нравится в последующем разборе полётов — аналогично. И это очень даже здорово, на мой взгляд. Лучше, чем наняться в контору, и обнаружить, что в процессах и в общей адекватности у них полный швах.
1) Вкусная вакансия(вкусной вакансии вообще можно очень многое простить)
2) ТЗ оплачивается
Когда ищу работу, я составляю табличку со списком компаний и их характеристиками. Те компании, которых требуют выполнить тестовое задание, отправляются вниз таблички и имеют минимальный приоритет.
Стоит ли говорить, что еще ни разу до них очередь не дошла...
P/S Хотя я все-таки пару раз сделал тестовое задание, потому что посчитал его полезным для саморазвития. То есть я отказался выполнять задание в поставленные сроки, а потом, как появилось время, выполнил "для себя".
Чего не могу понять в таких рассказах, так откуда у людей такой опыт собеседований. Особенно при большом голоде на кадры в индустрии. Выбрал пару контор, в которых хочешь и можешь работать, пособеседовался и работай года три в выбранной, пока всё не надоест.Голод все же не такой, что бы брать человека на любых заявленных им условиях:) Условия не всегда будут интересными, а полностью это выясняется только на собеседовании или даже после него.
Вот смотрите. Вы свою карьеру начали в каком-то неизвестном минском системном агрегаторе в далёком 2007 году и уже буквально через 2 года ушли оттуда. Затем вы попали в минский же Wargaming, где вы как утверждаете почти единолично сделали на питоне лендинг. И в 2012 уже покинули компанию и с 2012 вы являетесь безработным и делаете свои проекты и свою браузерную игру на деньги от которых вы уже более 6 лет и живёте.
Читая ваше сообщение я ожидал увидеть какого-то прожённого тимлида или супер скилованного руководителя, построившего не 1 очень сильную команду, или же работника 10 лет сидевшего от звонка до звонка в 1 конторе, вот в том же вашем первом системном интеграторе.
Но увидел почему то бизнесмена скорее с несколькими играми и своими проектами. Скажу, что с 2012 года прошло 6 лет и разработка с тех пор изменилась, изменились методологии, процессы, отношение людей и сама разработка.
Предлагаю вам выйти из творческого отпуска и попробовать свои силы в ролях собеседующих, чтобы так сказать писать сообщения более осознанно.
Никогда не думал что мою историю работы можно настолько криво прочитать. Да ещё и не дочитать. Но ваше право, интерпретируйте как душе угодно. Как минимум работодатели платят мне достаточно, чтобы я мог уходить в длительные творческие отпуска.
Последние года два-три я был на стороне собеседующего и все свои утверждения строю на личном опыте.
Если у вас есть какие-то возражение по поводу моих комментариев, вы их высказывайте по существу. Так куда проще общаться, чем пиписьками меряться.
После его публикации в мой профиль и бложик пошли люди с хабра. В моё болотце столько за месяц не приходило, сколько за сегодня :-D
Затем попал в Wargaming, уже не рога и копыта, и вы говорите «в 2012 уже покинули».
Это три года, Карл.
В современных реалиях, если человек меняет работу не каждые 6 месяцев, а раз в 2-3 года, это весьма неплохой показатель надежности.
Вот скорее человек, который отработал 10 лет в одном проекте — будет вызывать вопросы, поскольку крайне редко сейчас можно найти один проект, в котором можно прийти джуниором и 10 лет развиваться только в нем до тимлида. Подавляющее большинство проектов вообще столько не живет.
У вас видимо тот крайне редкий случай. Ну или может подскажете, сколько разработчиков было в вашей компании, и сколько из них прошли путь от джуниора до СТО и партнера/совладельца? =)
А на людей, которые раз в полгода-год меняют работу я, будучи собеседующим, относился с большой осторожностью.
Никак не могу понять одну вещь. В обсуждениях плохих условий работы (низкая зарплата, плохой код, завышенные требования начальников) люди с опытом всегда говорят мол, не надо продолжать там работать, меняйте работу, вакансий много. И те же люди с опытом в другом обсуждении говорят, что смена работы за небольшой промежуток времени это подозрительно. Товарищи, вы определитесь как-нибудь, надо менять или надо минимум 2 года терпеть. Причем для джунов это особенно актуально, их с большой вероятностью как раз в такие конторы и возьмут. И потому что мидлы там не задерживаются, и потому что в нормальное место скорее возьмут нормально пишущего мидла. А еще джуны иногда берутся за всякие мелкие подработки, а так как в резюме больше указать нечего, то указывают их. Вот и получается 3-4 места работы по несколько месяцев. Добавляем еще одно нормальное, и получается мидл с 3-летним опытом и "частой сменой работы".
В таком случае крупно ошибиться несколько раз подряд (попадать в плохие конторы) сложно. Ну 1 раз попал, понял ошибку, ушёл, сделал выводы, нашёл нормальную контору.
Для джуна метаться ещё допустимо (но и то странно, потому что маловероятно что джун может быстро оценить проблемность конторы и уходит именно по этим причинам).
А вот если на собеседование приходит человек с опытом в 5-10 лет, который за последние два года сменил пяток мест работы, то это реально стрёмно.
Рынок анализировать там, друзей опрашивать, интернеты читать.
… на собеседовании спрашивать.
Серьезно, стремную контору в 9 из 10 случаев легко выявить просто по ответам представителя конторы на собеседованиях, неважно, HR или программиста.
Все хорошие ("хорошесть" вещь сугубо субъективная) конторы одинаковы, а "стрёмные" стремны по-своему. Это как "генералы готовятся к прошлой войне".
И сменить пяток мест работы нормально, если на собеседовании обманывали о, например, перспективах.
В таком случае крупно ошибиться несколько раз подряд (попадать в плохие конторы) сложно. Ну 1 раз попал, понял ошибку, ушёл, сделал выводы, нашёл нормальную контору.
Ну вот мои случаи.
Маленькая частная контора с неофициальным трудоустройством. Полгода, в течение которых меня никуда не брали из-за недостатка опыта.
Разовый проект на несколько месяцев у других людей, но по информации от этой конторы.
В это же время вакансия начинающего разработчика с зарплатой аж 3 тысячи рублей, хотя изначально обещали 8, 4 месяца. По-вашему я должен был тут год работать? Нет, не устраиваться не вариант, потому что деньги нужны.
Первая нормальная вакансия, куда меня вообще взяли после собеседования, в основном благодаря опыту на том разовом проекте, 4 месяца, зарплата 15 тысяч рублей, и это было очень неплохо для нашего региона.
Предложили зарплату в 2 раза больше в другом городе. Я должен был оставаться на старой зарплате еще год?
На этом месте я работал 2 года, но и то в первый же день включил вывод всех ошибок и нашел ошибку в фукнции mysql_fetch_assoc(), куда передавалась просто строка запроса. Это к вопросу о том, насколько быстро можно оценить проблемность проекта.
Потом несколько месяцев на фрилансе работал с одной конторой, но проект закрылся. Фриланс это такая штука, что можно просто объединить и написать "фриланс 1.5 года", но они могли и через hh.ru объявление подать.
Да, я всегда пытался найти работу получше, просто не брал никто, обычно объясняли тем, что взяли более опытного разработчика. Если бы не устраивался никуда, то у меня вообще бы опыта не было.
и на вопрос «я должен был работать там год?» ответ в обоих случаях — да
и если бы вы понимали как становиться действительно профессионалом — вы бы поняли что это наиболее выгодное решение, тк разница в 5-10тыс рублей — это мелочи по сравнению с тем что вы будете получать нормально идя по карьере а не метаясь каждые N месяцев, не успев вникнуть в проект и не успев найти развитие для себя.
вообще понятно что джун в этом ничего не понимает и метания поначалу это от непонимания и весьма ожидаемы.
странно что вы это спустя N лет не переосмыслили и не поняли.
тк разница в 5-10тыс рублей — это мелочи
Это мелочи, когда вам уже не нужно выживать, и эти 5-10 тысяч – несколько процентов от дохода, а не половина, а то и она вся.
судя по тому что вы описали — проблема в вас
Я бы может вам что-то ответил по существу, если бы вы пояснили свою точку зрения. А так могу только выразить согласие с минусовым рейтингом вашего комментария.
Но мой вопрос был даже не в этом, а в том, что ваша точка зрения "надо продолжать там работать" противоречит часто высказываемому мнению опытных людей "не надо продолжать там работать".
Спросят почему вы не работали это время.
Ну когда у меня появились нормальные работы и проекты я так и сделал. Просто странно, что один и тот же вопрос с разных точек зрения создает разные мнения.
Однако если мне придётся куда-нибудь устраиваться — отсутствие опыта собеседований здесь огромный минус. Хотя бы даже потому, что при походах по собеседованиям, в голове складывается картина, что людям нужно в данный момент, какие технологии сейчас востребованы и т.д. При редких сменах работы довольно просто оказаться в своём потихоньку устаревающем мирке.
Даже если его специально берут на такие задачи, если это его постоянная специализация? Пришёл, обсудил с архитектором что и как будем делать на высоком уровне, и, собственно начал делать, принимая архитектурные решения более низкого уровня, какие-то апрувя у архитектура, какие-то в рамках обычного код-ревью. Возможно даже делать это не один или в составе команды рефакторинга, а рукводя такой командой хотя бы как техлид.
Я поменял первый раз компанию из-за зарплаты — отказывались повышать
Я правильно понимаю, что вы после пары месяцев работы попросили повышения ЗП?
Спустя 3 года когда я хотела переехать в Питер я прошла точно больше 7 собеседований и это только те, кто согласился на интервью через скайп.
Не знаю как вы это делаете, что за пару собесов находите отличную для вас компанию.
Были люди, которые злились, когда я отклонял оффер.Вместо отказа можно выставить ценник +50..100%, тогда они сами откажутся.
Тогда они не пригласят на собес :)
В таком случае репутация становится самым ценным ресурсом. Гораздо ценнее умения собеседоваться.
Я бы не сказал что за отказ устроиться на работу после успешного собеседования, кто-то сильно обижается или что это портит твою репутацию.
Во всяком случае на повторные собеседования меня без проблем приглашали. И когда потом с людьми на каких-нибудь конференциях/митапах пересекаешься, то спокойно с ними общаешься и тебя даже часто рады видеть и первые к тебе подходят.
На мой взгляд отказ это не такая уж и проблема. Нужно просто вежливо себя вести и всё.
я не хочу именно эту позициюПочему сразу ругаться, ну может не +50%, а +30%, т.е. какая компенсация вас бы устроила именно на эту позицию (на эти условия, все дело в цене), т.е. вы оставляете шанс работодателю, и если согласятся — то все в выигрыше (получается такой баланс).
Но в целом ваш подход хорош.
Как обосновать такой ценник?
Смешно, когда проваливаешь одно собеседование, подтягиваешь вопросы которые были на собесе и на следующем в другой конторе получаешь тот же набор вопросов…
Меня, например, так стабильно спрашивают про new в статической памяти. Нахуа? Нет, серьезно, я лет 15 на плюсах пишу, но знаю что можно через new создавать объекты в статической памяти только потому, что этот вопрос регулярно на собесах всплывает. Причем даже на собесах на UE4 разработчика, где даже в теории эти знания не нужны.
Так что если вы оцениваете человека по тому, как он хорошо проходит собеседования — он будет тренировать собеседования. В том числе за ваш счет.
тратите время других людей на то, чтобы прокачать свое умение собеседоваться?
И что? Автору того комментария должно стыдно стать за то, что пользуется в полную силу данными всем нам возможностями?
Ну, кому-то из них может повезти, и его компания получит толкового разработчика. Рынок работает в обе стороны, приходя на собес никто никому ничего не должен.
Правду, что приходили просто потренироваться или лукавите, что условия не подходят?
Если вы не из столицы, то количество контор не слишком большое. Не боитесь что будет репутация человека, который сам не знает чего хочет, оферы отклоняет и вообще только и делает что ходит на собеседования. ИТ-сообщество всё таки довольно тесное, даже в крупных городах.
Зачастую на этом контакт и заканчивался — почти всегда даже не отвечали (однако иногда был вежливый ответ «нет» и благодарность за честность).
Однако было несколько случаев с мотивацией той стороны «ну время у нас есть, давай пообщаемся, может потом все же и надумаешь к Нам?! :) „
+1.
Мне сильного чувака не жаль отсобеседовать. Глядишь — и переманить получится.
Глядишь — и переманить получится
Причем не всегда «переманить» удается сразу. Бывает у людей получается хорошее взаимо-мнение и сотрудник приходит через пол-года/год.
А бывает что приходит и через месяц.
Грамотные люди понимают важность не только «закрыть позицию», но и иметь на примете определенный пулл
P.S. И сарафанное радио никто не отменял даже в 2019-ом — не сам придешь, так из своего проф-круга кому-то посоветуешь.
Всегда же есть шанс суперпредложения.
Так обычно спрашивают желаемый уровень ЗП. Вы назвали его, прошли собеседование, вам предложили столько, сколько вы хотели. Не очень логично будет при этом сказать, что условия вам не подходят.
Условия – это не только ЗП.
Спрашивают часто до собеседования или в самом его начале. А уровень зарплаты после какого-то предела перестаёт быть одним из самых важных условий (в разумных пределах): +-5% или даже 10 повлияют на выбор компании только при "прочих равных", хотя для кого-то эта будет разница между "работать бесплатно или хорошо получать". Например, окажется, что жёсткий график, или наоборот, что народ приходит как попало и хорошо если 4 часа в сутки вся команда сети, а тебе такое не нравится. Или что обеды компанией не организованы. Или наоборот, организованы и на ходящих в рестораны на весь обеденный переыв смотрят косо. Или подумал и решил, что добираться всё-таки далековато. Особено после собеса поехав домой "гладко было на бумаге..."
Много условий могут всплыть во время и после собеса, которые не компенсируется суммой оффера. Ну и называется часто "от N", что означает (для меня), что на N я соглашусь только при сильно положительном балансе плюсов и минусов условий работы, а на многие минусы готов закрыть глаза только за N+10%.
Редко попадалось, чтоб предлагали меньше названного минимума. Запомнилось пару раз только, один когда честно сказали, что это максимум бюджета на этот год. А второй когда сказал нет, с прямым указанием, что это меньше чем называл минимум — тут же подняли, явно расчёт на "может прокатит". Остальные обычно что-то вроде "мы не увидели что вы стоите этих денег, но даём вам возможность показать себя в деле",
лукавите, что условия не подходят?
Здесь нет лукавства.
Если условия хуже чем на моей текущей работе — зачем мне переходить?
Если условия лучше — то можно подумать о переходе, даже если не собирался.
Даже если обещают условия немного лучше чем на текущей всегда есть риски, что что-то пойдёт не так, что обещания не выполнятся или какие-то "очевидные" ожидания не оправдаются.
Вы знаете, я тоже долгое время боялся "испортить" отношения с потенциальными работодателями. Мол, если сейчас откажусь, то потом не возьмут. Как будто в жизни есть только один шанс попасть в конкретную контору, как будто действует принцип "сейчас или никогда".
Потом с удивлением осознал, что адекватные работодатели вовсе не против повторных попыток трудоустроится. Например, мой коллега 5 раз проходил собеседование в Касперском, из них 3 раза получал оффер.
А я думал, что только у меня так. :-)
Слушал подкасты закрых CS групп с неопубликованными еще алгоритмами.
Приходил на интервью, все перерешивал, рассказывал о алгоритмах которые они не знают — и тоже бывало офер не давали. Никогда не знаешь по какой причине не дают офер.
Если вы вышли на более менее стабильный уровень (сеньор в 3+ компаний и top-10% по зарплате), то просите +25%, будет поле для торгов. В противном случае просите +50%, а то top-10 так и не достигнете.
Человек, достигший очень хорошего уровня, запросто может на следующей работе получать уже меньше, а вовсе не больше. Если не готов пойти на компромиссы, как пример — далеко ездить на работу или т.п.
И если рассуждать абстрактно-математически, то как бы потолка нет, ибо фирм в мире где можно работать множество. Но на практике — не все эти фирмы, дающие еще большую и большую прибавку, для тебя пригодны.
Есть пример из жизни:
Была разработана некая система. Все разработчики уволились после окончания работы. Один остался, поддерживать систему.
Будучи единственным, кто ее знал, этот парень получал больше всех в фирме, даже больше директора.
Но. Прошло 7 лет. И систему вывели из эксплутации. Соответственно, платить там много парню уже никто не захотел.
Предпоследний раз, когда я с ним беседовал — он искал работу уже полгода как. На зарплату, равную хотя бы 50% от предыдущей.
Последний раз, когда я с ним беседовал — он переехал в другой город, ибо в нашем работу уже не смог найти на те деньги, к которым привык.
Так что не все так просто с «просить всегд больше денег». Это работает только до поры до времени.
По сути ваш совет хорош прежде всего для джунов — там зарплаты растут очень быстро, действительно. У миддлов уже не так быстро. А затем можно столкнуться и со снижением.
А вот человек, знающий банковские процессы, прикладную область и владеющий условным коболом — работу долго искать не будет.
Формально — верно. Предприятий много.
Фактически — не всегда. Не ему тебе подходят.
Вот если он готов переехать в другой город (банк вряд ли на удаленку возьмет специалиста под серьезные задачи).
Человек знающий систему одной фирмы на устаревшей технологии и все процессы данной конкретной фирмы действительно будет искать работу хотя бы на 50% от зарплаты.
Нет.
В моем примере была вполне себе современная технология и по сей день широко распространенная. То был не веб, где все быстро меняется.
Такое часто случается, когда люди путают знания конкретного бизнес-процесса в конкретной компании и общие знания в прикладной области и технологии.
В том то и дело, что ты намного более полезен не общими, а максимально конкретными знаниями. Тебе потому на прошлой работе хорошо и платили.
В новую фирму — ты приходишь еще никто и звать тебя никак. Конечно, имея что рассказать про опыт ты можешь рассчитывать на неплохие деньги.
Но это несравнимо с той пользой, что дает предприятию человек, который «знает ядро именно нашей уникальной системы».
Будучи единственным, кто ее знал, этот парень получал больше всех в фирме, даже больше директора.
Поделитесь секретом, как можно убедить директора платить больше чем он сам получает?
Поделитесь секретом, как можно убедить директора платить больше чем он сам получает?
У меня все написано — быть незаменимым специалистом.
Кстати, это не первый случай, о котором я знаю, что директр платит кому-то больше себя.
Быть незаменимым — условие скорее необходимое, чем достаточное. Обычная ситуация: незаменимый человек пашет, как лошадь, получает среднюю (ну или чуть выше средней) зарплату, а бизнес считает что так и должно быть. Не представляю, что нужно предпринимать для того, чтобы получать не просто выше, а сильно выше рынка. Каждый год ходить к директору и требовать +50% ?
Убедить его, что без вас он и этого получать не будет. Полушутка.
А во вторых чтоб не чувствовать не себя самозванцем, синдром самозванца штука не самая приятная.
Ну и кроме того, на сколько я понимаю человеческую природу, для людей характерно стремление проранжировать себя и окружающих в рамках какой-то иерархии.
Ну и кроме того, на сколько я понимаю человеческую природу, для людей характерно стремление проранжировать себя и окружающих в рамках какой-то иерархии.
Вот, вот это и занимает. Природа этого стремления.
Потому что заниматься делом это, по крайней мере мне, не помогает вообще, только мешает. Помогает концентрация на задаче.
А люди от обезьян отличаются ещё сильнее, поэтому такой ответ меня лично не удовлетворяет. Плюс, по моим наблюдениям, многим людям иерархические отношения не интересны от слова совсем.
Вот меня и интересует, почему одни могут в внесоциальные/внеиерархические деятельность и отношения, а другие нет, и наоборот. Я в общем-то от вас однозначного ответа не требую, т.к. с моей точки зрения вопрос сложный.
Ну в плане потребности в иерархии, собаки от волков как раз мало отличаются:)
А собакам вывели необходимость в external validation, желание исполнять человеческие комманды, и желание понравится человеку. У волков этого нет.
Я не понимаю, если человек уже три года работал разработчиком, какие нахрен могут быть с ним проблемы, технически? Будет тормозить команду? Научим. Будет задавать тысячи вопросов — ответим. Будет писать дерьмовый код? Отревьювим.
К счастью существует достаточно много фирм, которые думают примерно так же. И в них обычно приятнее всего работать. Правда и зарплаты там часто немного пониже предлагают. Но на мой взгляд оно того стоит :)
Чувак живёт себе, точно знает что он фронтендер мидл, точно знает что он стоит X в городе Y, и не ведает сомнений и страха. Я не понимаю, как они это делают.
Я делаю очень просто: беру свой стаж и стэк и смотрю среднюю зарплату по региону. И назначаю себе "должность с повышением". То есть если вроде как джуниор, то назначаю себя вроде как миддлом. Если миддл, то заявляю что сениор. Если сениор, то мечу в техлиды/архитекты.
Потом накидываю сверху 30% на среднюю зарплату и озвучиваю эту сумму и свою "должность" на всех собеседованиях. И смотрю прокатит или не прокатит и на чём мы в результате сойдёмся. И походив таким образом на пяток собеседований как минимум понимаешь как тебя видят "со стороны" и сколько ты "стоишь" :)
Имхо, в какой-то момент компании массово решили, что технические вопросы на собеседовании — это все, что нужно. Приходит довольно взрослый человек, он где-то работает, часто не в самой убогой компании. Отлично, давайте зададим несколько теоретических вопросов, а потом дадим 10 задач на то, что выведет код, за который в реальной работе нужно карать. «Ыыыы, лох, неудачник, нет знаний, не знаешь язык, тут должно быть -2, а не -1, все, проваливай, ты даже на джуна не тянешь! Видели, как я его раскусил?» — потом происходит подобное, интервьюер пытается убедить себя и коллег в том, что все программисты тупые и не тянут, но только в этой компании смогли собрать бриллианты. Зачем пытаться понять, в чем силён кандидат, в чем он разбирается, почему он может так, а вот так не может? Собеседующего вырвали из процесса перехода от написанию фичи к полднику, он раскатал более слабого кандидата, либо попытался раздавить более сильного: «У, этот лох пытался показать мне, что я что-то не знаю в языке, но я его подловил вооооон той задачей». При этом в новостях нет историй об умирающих от голода сотнях программистов, значит эти люди смогли найти работу, на которой они работают. Правда ли, что все они не смогли бы работать в этой компании? Не думаю.
Круговая порука внутри компании/команды — вторая важная проблема. Каким бы некомпетентным, грубым и нетактичным собеседующим собеседующий не был, у отвергнутого кандидата нет возможности на это повлиять (а значит, что у компании нет возможности исправить проблемы и сократить расходы, а то и спасти проект). Написать HR? И что произойдёт? На одной чаше весов слово какого-то неудачника, на другой — слово коллеги, сокомандника, человека, от которого частично зависит зарплата и премия. Даже если кандидат прав, сколько процентов рекрутеров готовы устраивать скандалы из-за этого? А если учесть команды, которым не выгодно нанимать людей, работать придётся нормально, не свалишь проблемы на нехватку рук, а вдруг ещё нормальный специалист придёт, будет критиковать Васю, племянничка моего, то шансов ещё меньше.
И существует большое количество курсов, книг и т.п. которые готовят этот шлак как надо прорваться, а не как надо работать. Вот и приходиться придумывать схемы, у кого на что хватает выдумки.И вместо реального определения навыков сотрудники играют в игру «Посмотри, кто пройдет задания с бумажки — тот и будет получать деньги в нашей компании». Мне кажется, что если появилась индустрия прохождения собеседований, то надо вкладываться не в противодействие этой индустрии, а в понимание кандидата и того, что от нее можно ожидать.
Плюс надо понимать что технические специалисты не эксперты в области набора кадров и это не их основная задача. И в большинстве случаев им это глубоко не интересно, поэтому ожидать чудес не стоит.Согласен, что бывает очень скучно. Но, имхо, тут есть довольно забавное противоречие. Вместо реального поиска и найма, который может быть скучным, но не очень долгим, технический специалист пытается унижать и чморить людей, чтобы и завтра, и послезавтра, и через неделю к этому вернуться. Плюс я не уверен, что первый вариант реально глубоко скучный и неинтересный.
Мне еще вот очень нравится что вы разговор сразу перевели в квоты, прям из ниоткуда. Telling, так сказать
Как бы кому не обидно было, есть специалисты получше, похуже и совсем никчёмные. Спросите тех кто проводит интервью, из 10 человек — один более менее, два-три ок, всё остальное шлак.
Вот только от вас услышал слово "шлак" в контексте кандидатов или их резюме. Обычно оценки не несут отрицательных коннотаций, а довольно нейтральны и оперируют какими-то шкалами, хотя бы "джун-миддл-сеньор". Наверное вы, увидев джуна пришедшего на собеседование сеньора, назовете шлаком? Это больше говорит о вас, а не о кандидате.
Соответственно ищем алмаз, довольствуемся железняком, в отвал идет куча шлака. Это отрицательная коннотация не по отношению к человеку, а по отношению к поиску.
И да, джун на собеседовании в поисках сеньора — шлак. Очень нужен именно сеньор — и мидл шлак.
Я обычно на собеседованиях даю кандидату код который без проблем компилится, но в нём огромное количество ошибок, от простых до сложных. Сколько и какие найдёт хорошо показывает и опыт и знания языка. Плюс задачка с дилеммой, где хорошего решения в принципе быть не может, для того чтобы посмотреть как кандидат идёт к решению задачи, как он её обсуждает. Ну и конечно же чисто технические вопросы строго в рамках того что используется на работе. Самая основная проблема, это скорость обучения, и вот как её проверить не понятно.
return result['sum'];
тут написано
return result[ fields[ (bool)result['need_sum'] + offset_sum]];
вы же сами нанимали такого человека :)
по поводу кода с ошибками — найдите их… да еще и на листочке небось? (так джунов норм нанимать — они после института к этому, увы, привыкли) :)
у меня есть IDE — давайте сначала через нее пропустим :)
вот считать ли if (a=true) {...} ошибкой? или это просто предыдущией разраб выпендривается?
или что-то типа: auth==true && sendMoneyToUser(); (без if)
читать тяжело, в ког надо прям вчитываться(!) — у нас за такое ПР не проходят
а вот про решение задачи, а точнее слежение за ходом мысли — это я ЗА. Дает понять как думает человек, как декомпозирует и т.п.
п.с. сам не знаю как лучше оценивать кандидата
по поводу кода с ошибками — найдите их… да еще и на листочке небось? (так джунов норм нанимать — они после института к этому, увы, привыкли) :)К счастью это частично отсевало и тех кто приходил с 10 летним опытом на сеньора.
у меня есть IDE — давайте сначала через нее пропустим :)Как уже сказал IDE этот код сожрёт и не поперхнётся.
вот считать ли if (a=true) {...} ошибкой? или это просто предыдущией разраб выпендривается?Не, имеются ввиду обычные ошибки при кодировании которые без проблем пропустит компилятор (код специально пишется с ошибками, а не берётся из работы), но которые приведут к огромному гемору при дебаге, например
или что-то типа: auth==true && sendMoneyToUser(); (без if)
читать тяжело, в ког надо прям вчитываться(!) — у нас за такое ПР не проходят
class A
{
public:
int* val;
~A()
{
delete val;
}
};
В этом минус этих ваших задачек в вакууме, без контекста не все явно.
Хотя бы потому, что это показывает, что ты знаешь, как писать не надо.
у меня к знанию о том, как писать НЕ надо — двоякое отношение…
с одной стороны, когда ты НЕ знаешь как НАДО, ты не начнешь писать как НЕ НАДО, с другой — когда ты знаешь(!) как НАДО, то знание о том как НЕ НАДО — практически бесполезно (и лучше мозг забить чем-нить более полезным) :)
Каким бы некомпетентным, грубым и нетактичным собеседующим собеседующий не был, у отвергнутого кандидата нет возможности на это повлиять
Помоему вы не правы.
Когда в начале карьеры был в роли собеседующего — был достаточно неадекватным. ТАк меня очень быстро от собеседований отстранили.
Каким бы некомпетентным, грубым и нетактичным собеседующим собеседующий не был, у отвергнутого кандидата нет возможности на это повлиятьочень даже есть, например, у нас в фирме у кандидата всегда спрашивают фидбек по собеседованию. И если N кандидатов говорит, что человек проводивший интервью неадекватен, то это повод задуматься, сделать выводы и принять меры. Что собственно мы и делаем.
Хотя иногда бывают забавные случаи, очень часто при собеседований сисадминов и девопосов я задаю вопросы по ДНС (что такое/как работает/для чего нужна). Так вот многие кандидаты обижаются и не понимают таких вопросов. Это наверное из серии у разработчика (синьйора) спросить про сортировку пузырьком. Тем не менее, это показывает многое о кандидате и уровне его кругозора
Я понимаю что руководитель компании не может сам присутствовать на сабеседованиях и не должен этим заниматься, но у него должны быть какие-то метрики на которые он будет смотреть и понимать насколько у него все хорошо.
Например у него нанимают на работу несколько различных человек и он может посмотреть процент нанятых людей каждым из рекрутеров. Потом посмотреть на какие-то метрики насколько хорошо идут дела на их проектах. И сделать из этого соответствующие выводы.
Отлично, давайте зададим несколько теоретических вопросов, а потом дадим 10 задач на то, что выведет код, за который в реальной работе нужно карать. «Ыыыы, лох, неудачник, нет знаний, не знаешь язык, тут должно быть -2, а не -1, все, проваливай, ты даже на джуна не тянешь!
Вспоминается пара историй из относительно недавних собеседований.
В одном случае потенциальный тимлид спросил что-то вроде «Как сделать на SQL нечто, что ты никогда в жизни с помощью SQL делать не будешь». Я не знал. В конце интервью попросил, чтобы всё-таки объяснили. Тимлид в ответ написал код с ошибкой. Я ему на неё указал. Офер не дали.
Вторая история. Дали лист с задачами и вариантами ответов. Одну из них я не смог решить. Опять же, попросил объяснить. Ни один из тех, кто меня собеседовал, не смог ничего объяснить — они только знали правильный ответ. Один потом всё-таки смог разобраться, но потратил на это минут 20.
«Ыыыы, лох, неудачник, нет знаний, не знаешь язык, тут должно быть -2, а не -1, все, проваливай, ты даже на джуна не тянешь! Видели, как я его раскусил?»Хорошо, если вы столкнулись с такой ситуацией. Это значит, что вы можете выбрать другую компанию, с менее токсичной атмосферой
Нужно следить и убирать за тобой — ты джуниор (до года-двух опыта)
Рабочая лошадка и сам решаешь задачи(без необходимости все проверять за тобой) — мидл (год — четыре опыта)
Можешь следить за джуниором и нарезать задачи мидлу(планируя все целиком) — ты сеньор (от трех опыта, но скорее от 6)
Зарплата привязывается к этому.
А набор скилов и компетенций у каждого свой и особо от них зп не зависит (кроме редких и основных). Возьмут или не возьмут на собеседовании скорее.
Смена стэка вовсе не означает "понижения'
Мидл — тот кто не косячит много, сам работает, но нужно ему ставить задачи сверху и определять как и на чем будет сделано.
У сеньора достаточно опыта, чтобы самому себе как минимум ставить задачи, чтобы добиться нужного результата.
Джуниор по сути не выгоден фирме(так как отвлекает коллег на большую сумму чем сам приносит). Если выгоден, уже мидл.
Как человек имеют опыт управления небольшой программисткой фирмой — поправлю вас.
Когда пишут, что мол «фирмы нанимают копеечных джунов и эксплуатируют их в хвост и гриву наживаясь и через месяц увольняют без зарплаты, мол, не прошёл испытательный срок» — это да, действительности не соответствует. И тут я с вами согласен — в самом начале джун не выгоден. Поэтому брать на месяц и кидать — это абсурд даже с точки зрения экономики (если морально-этическую сторону не рассматривать)
Но потом, когда джун вникает — прибыль уже есть. Разумеется, при этом джуну адекватное предприятие не позволит самостоятельные решения архитектурного свойства принимать. И каждую работу джуна обязательно проверяет более квалифицированный специалист.
Насколько помню, в моей ситуации джун выходит на самоокупаемость (пусть и без прибыли для начала) где-то ко второму-третьему месяцу. И ко второму году уже и окупался и прибыли приносил неплохо.
Но ко второму году всё ещё оставался джуном (по степени ответственности)?
Но ко второму году всё ещё оставался джуном (по степени ответственности)?
Вы как-то чисто математически-абстрактно подходите.
Человек это не схема.
Что за ярлыки?
Что за рамки?
Самостоятельность в работе растет не скачками, а постепенно.
Термин «джун» довольно условный. Нет единого стандарта.
В конторе «Рога и копыта и веб-сайты» вы можете быть супер-сеньор-архитектор, а придя в Гугль становитесь джуном.
Я говорю о вполне конкретной ситуации — моей ситуации.
Когда нанимались нулевые ребята после ВУЗа (это даже не джуны, а т.н. «трейни»).
И в моей ситуации спустя 2 года им можно было доверять в самостоятельную разработку почти любую задачу.
Но это вовсе не означает, что скажем полгода спустя над ними стоял проверяющий и каждая строчка кода контролировалась им.
Но без джунов никуда. Особенно на какой то узкой теме. Внешних специалистов не найдешь, остается только выращивать своих.
Так то конечно сейчас принято джунам платить столько, что многие с них требуют как с мидлов. Я 11 лет назад устроился джуниором на минимальные 6 тысяч. Через месяц уже давал оч хороший результат(была куча задач на мелкие правки) и повысили до 30 сразу и по факту уже работал мидлом. Но меня никто не учил, так что и убытков я не приносил. Во всем самому приходилось разбираться.
Но в крупных фирмах, где цена ошибки может быть очень велика так сейчас не сделаешь.
Средняя зп программиста в сфере тогда была как раз 30-40.
Следить за кем-то и ставить задачи — это же работа менеджера. И почему это связано с опытом работы? Если я несколько лет выполняю задачи, которые даёт менеджер, а он их выбирает под меня (или меня под некоторые задачи), потому что знает, что я могу, и на чём пишу, это же ещё не значит, что я готов начать следить за новичками, пусть за ними менеджеры и следят.
Зарплаты к ним привязываются так.
Джуниору ставят такую минимально заплату — какая позволяет отсеять на собеседованиях адекватных ребят.
Когда джуниор начинает приносить прибыль(за вычетом расходов на него и обучение),
зп повышают.
Когда мидл обретает опыт по проекту и хотя бы на нем становится сеньором(за счет знания местных нюансов). Повышают зп. исходя из того насколько он становится востребованным на внешнем рынке и насколько проект пострадает от ухода. Но если человек и не собирается уходить, то могут и вообще не повышать.
Спрос повышает среднюю зарплату и её можно глянуть на том же исследовании моего круга.
Про менеджера. — Как он отревьюит код и увидит, что через полгода, когда кол во в базе увеличится с сотен до миллионов, код джуниора повесит весь проект?
Никак. Менеджеры задачи джунам вообще не могут поставить. Минимум грамотному мидлу.
И конечно не все сеньоры следят за новичками. но все сеньоры достаточно опытны, чтобы увидеть косяки в коде новичков. И достаточно опытны, чтобы зная что нужно получить решить как это нужно сделать и нарезать на задачи достаточно маленькие, чтобы и джуниор справился.
Знаю одного крутого джава разработчика. Работал на одну фирму 7 лет уже. Повышали зп медленно. Уже стало сильно меньше рынка(100). Лет 5 назад попросил повышения до 130, или в другую уйдет. Отказали. Стал увольняться. Из головного офиса в берлине, местному менеджменту всыпали плетей. Повысили ему зп до 150 и дали троих джуниоров в подчинение. Обучение разбавляет рутину, да и иерархия чсв тешит. Так что большинству знакомых сеньоров поучить в радость.
Менеджер код посмотреть не может, но может следить за сроками работ. Конечно, новички не самостоятельно всё делают, а только часть работ, а менеджеры на то и IT-менеджеры, а не дяди со стороны, чтобы понимать, что могут сделать новички, и что можно им дать. А за кодом следить могут остальные люди, которые работают над проектом. Или могут не следить, смотря насколько это важно и оплачиваемо. И наоборот, если это очень важно, но приходится выходить в выходные и дорабатывать из-за сжатых сроков, то тут уж не до рефакторинга чужого кода.
Еле продрался сквозь большой сплошной текст.
Если бы было разбито на разделы, а не только на абзацы — было бы проще читать.
На самом деле все «просто»:
1) С точки зрения работодателя/тимлида, короче того кто собеседует: ищите те качества которые вам важны, а остальное просто по минимально возможной планке. Есть время на обучение — снизили еще планку. Тут как нигде работает правило «главное чтобы человек был хороший», а что значит хороший — определяете вы, в зависимости от того какую команду дополняете или формируете, на какой проект, и так далее. Где то нужна инициатива, а где-то наоборот просто исполнительность (ну например проект скучный, с плохим менеджментом, но нужный, инициативный просто быстро выгорит). Лично для меня важно как человек думает, как подходит к проблеме, как решает сложную задачу, любит ли он свою работу или просто ради денег пришел, ну и общая экспертиза, опыт, то что поможет ему думать и решать задачи, но именно те которые не получится наработать быстро. А если это какая-то специфическая тема или навыки которым можно обучить за неделю-две (да пусть даже за месяц если он есть) — то смысл из-за этого отказывать, разработчиков мало, хороших еще меньше, те которые сейчас в поиске, подойдут в команду, под проект, вольются в компанию — вообще единицы, искать их можно месяцами, зачем самому себе резать шансы из-за вопроса которому можно научиться за небольшой срок?
2) С точки зрения кандидата: не только вас выбирают, вы выбираете. смотрите, вот этот человек который вас собеседует (если он адекватно следует позиции в пункте 1), вам понравиться с ним работать? А как он рассказывает о проекте, интересно ему? Если не интересно — вас это устраивает или интересный проект у вас в верхнем списке приоритетов. На что делает упор, обладаете вы этими качествами? Если нет может оно того и не стоит? Если не джуниор то вариантов же много, может лучше туда где вы будете «свой» а не пытаться натянуть маску, она же все равно треснет во время испытательного срока. ну и зачем вам терять время? Что-то интересует — спрашивайте. Вопросы, больше вопросов, любых, меня пару раз спрашивали, (когда я собеседовал) «нравится ли мне тут работать и какие минусы есть», отличный вопрос, правда я лично рискну его задать только очень адекватному человеку. Так что смотрим, оцениваем, и спрашиваем все что интересует по ситуации. И главное, помните, это собеседование. Совместная беседа. Вы оба смотрите будет ли вам хорошо работать вместе. В некотором смысле это свидание. Не надо пытаться понравиться, адекватный интервьюер (какое ужасное слово) и так уже занизил планку знаний до минимума, и если вас позвали — велика вероятность что вы проходите по ней, но даже если резуюме не читали — вы либо попали в нужный минимальный набор знаний либо нет. А личностные качества вскроются все равно на испытательном, тут притворятся смысла нет вообще. Короче расслабьтесь и получайте удовольствие от общения с профессионалами, а они с вами. Если этого нет — собеседование можно заканчивать. Общайтесь как будто встретились на конференции и хотите что-то обсудить, решайте предложенные задачи так же как решали бы в рабочем процессе, свободно, с обсуждением, уточнениями, предложениями. Вы равноправны, они так же нуждаются в разработчике (а чаще намного больше) как и вы в хорошей работе.
Я люблю когда кандидаты, которых собеседую я, задают вопросы, даже самые некомфортные. почти любой вопрос это плюс, не факт что отвечу но это плюс.
Я люблю когда люди которые собеседуют меня, дают советы, указывают где мои знания недостаточны, где их можно почерпнуть, это круто, это помогает мне развиваться. Не нужный мне совет я проигнорирую, за нужный скажу спасибо, но это в любом случае плюс. Обожаю развернутые фитбеки, даже те от которых мое внутренее Я испытывает дискомфорт, ничего переболеет, а хороший фидбек указывает где просадки и что доработать.
Я не люблю заносчивость, хамство и ненужную помпезность с обоих сторон, это указывает только на комплексы человека или его непрофессионализм. Очень не люблю когда у собеседующего заготовлены четкие вопросы и он ждет на них ответы которые записаны у него, да этим многие страдают, это признак того что человек не понимает зачем нужно собеседование, его попросили отсобеседовать, он заготовил заковыристые (или не очень) вопросики, пришел, задал, сравнил с ответом. Как плохой преподаватель проверяет не ход решения а совпадает ли ответ с ответами в конце учебника. Совпадет — молодец, нет — плохо, но в любом случае это фикция, формально выполненная работа, огромная вероятность false positive или false negative решений. Да план должен быть, но именно план, а не викторина. Если вам нужен не разработчик а тот кто знает ответы на небольшой список ваших вопросов — напишите скрипт, это проще и быстрее. Будете писать ему вопрос, он вам идеальный ответ, вы радуетесь и все, зачем вам разработчики. В любом случае не обижайтесь когда кто-то вроде меня постоянно сбивает вас с плана и отвечает правильно но не так как вы задумали, или заканчивает собеседование а потом у hr-а или ЛПР просит другого человека для собеседования, потому что тот не справляется. Что-то увлекся, уже на статью потянет а не на комментарий, заканчиваю.
Почему бы не брать в соотношении 80 (свои) / 20 (с рынка). Я говорил скорее общем соотношении.
Мне кажется до сеньора шкала более менее линейная и известная на рынке, а после начинается привязка к бизнес-оппортьюнити.
Условно в Мск сеньор «про запас в организацию аля крупный банк с тысячей таких же программистов» получает в диапазоне 250-400к. Сеньор ищущий возможности и имеющий некоторую склонность к бизнесу вполне может получать в районе 400-1кк. Обычно вакансии по возможностям не особо публикуют публично на чем то типа хх и заполняют через нетворкинг, они не такие стабильные (условно сеньор в банк после устройства может быть уверен что у него джоб секурити лет на 5 теперь)
Что означает "вакансия по возможностям"?
Возможности=оппортьюнити 2мя преложениями выше. Условно одним конторам нужен запас сеньоров так сказать для релайабилити — если одного автобус собьёт там или рейдж квит у кого случится. Таким конторам зачастую нужны сеньоры со знаниями вглубь доменов чем в техническую глубь и в идеале с семьей и ипотекой чтобы не дергался. Это в основном банки или какие нибудь крупные стабильные сервисы. Там платят +- одинаково и эти цифры довольно часто циркулируют в статьях или каких нибудь ресерчах по зарплатам и это то что называют «в среднем по рынку»
Другие конторы / проекты фокусируются на развивающихся нишах на рынках где временные рамки для профитов очень ограничены. Вот там нужны программеры зачастую с бизнес скиллами, которым не нужен разжевывающий почти до кода требования за тебя. Это конторы типа слизывающие взлетевшие в США стартапы пока их в Россию не завезли например.
Ну и ещё есть ниши где нужны несколько разных сложных вышек (на ум приходит фин трейдинг или разработка чего нить нового типа первого ифона, гугл очков или хололенса, хбоха или пс4)
Да не известная эта шкала, у каждой компании своя. Джун, получающий больше миддла "по рынку", но не проходящий в миддлы по каким-то внутренним критериям типа "не может учить других джунов" — вполне может быть.
ну вот например нашел за 2 минуты на хабре:
https://hh.ru/vacancy/33435377
вот тут просто список где это более менее прямо указано (прямо сеньор девелопер там не так много, но они есть ~ 1 на страницу)
https://hh.ru/search/vacancy?L_is_autosearch=false&area=1&clusters=true&enable_snippets=true&no_magic=true&only_with_salary=true&salary=250000&specialization=1&page=2
Ну и всё ещё по каким-то неведомым мне причинам распространено указывать "зп не указана" и поэтому приходится просить эти суммы самому, чтобы их получить.
Судя по количеству упоминаний "несправедливости рынка" автор хотел бы, чтобы ему какой-нибудь чиновник выдал бы корочку программиста 3го разряда, с подписями и печатями. Ведь чиновник то точно знает, что нужно от программиста.
синьор — опыт работы не менее 5 лет в области разработки бизнес-логики, знание наизусть алгоритмов сортировки «пузырьком», реализация не менее 10 архитектурных паттернов, обучение не менее 3-х джунов, опыт применения не менее 3-х ЯП (за исключением PHP и 1С)…
и т.д.
Ну что-то подобное есть, просто синьор = старший инженер-программист вроде
А разве дело не в реализации интерфейса?
Адаптер оборачивает один интерфейс, а реализует другой (чтобы всунуть треугольник в круглую дырку)
Декоратор реализует тот же интерфейс который оборачивает добавляя функциональность (классические примеры — логгирование вызовов и мемоизация)
Фасад оборачивает чужой интерфейс не интерфейса ради а удобства для.
Я не понимаю, если человек уже три года работал разработчиком, какие нахрен могут быть с ним проблемы, технически? Будет тормозить команду? Научим. Будет задавать тысячи вопросов — ответим. Будет писать дерьмовый код? Отревьювим.
Хе, люди разные.
Есть более обучаемые, есть более глупые, есть более ленивые и т.п.
Ваша позиция льстит нанимаемому, да.
И если выбора кого нанимать нет — нанимателю приходится смириться и думать так как вы и написали.
Однако, если выбор кого нанимать есть? Почему бы не взять того, кто получше? Конечно нужно взять именно того кто получше.
Проблема только как его по краткому собеседованию выбрать из нескольких кандидатов и не ошибиться.
Давайте не сводить всех под одни рамки.
Я могу написать целый МВП за день, но поддерживать этот кошмар потом я не хочу.
Или я могу этот МВП написать за неделю, включая тесты и документацию, а потом это можно развить до полноценной системы.
И в какой список мне себя, по вашей логике зачислить? Ведь это зависит от требований фирмы.
1) Дать доступ к коду и документам, но избежать промышленного шпионажа.
2) Заплатить человеку за день, но не устраивать его как постоянного работника
Ну и т.д. Не знаю как это решить, но была одна фирма которая такое мне предложила как последний этап интервью.
— А что это ты, мил друг, за последний месяц 5 испытательных дней сменил? Неужто настолько ленивый, что нигде тебя не берут?
Нет, открыл их код и он мне не понравился, а отрефакторить не дали :)
А еще сильно влияет мотивация. К примеру я отношу себя к «быстрым» разработчикам. Но почти нигде это не ценится. В итоге работать быстро становится крайне не выгодно — это оценивается слабо(самая большая премия мне была со словами «не думай, что мы не видим. мы видим и ценим» в размере половины зарплаты. Даже не 13 зарплата, а половина), при этом задач пихают столько, сколько можешь унести. Ну и зачем? В итоге работаю на половине «мощности», остается больше сил и физически и эмоционально.
Та же ситуация. Поначалу старался очень сильно, но премия — 10% от ЗП. И точно так же не дадут простаивать. Ну и нафига оно нужно, так запариваться.
Оплата труда вообще бредовый показатель. Жил в одной стране, спокойно получал 8к евро, живу в другой а тут 4к это нереальная высота, а требования такие же. Ну и причём тут мои навыки?
чень тяжело во всем этом разобраться, оценить себя, насколько ты готов к работе вообще.
Как мне кажется это довольно просто на самом деле. Берёшь незнакомую тебе технологию, которая лежит в ветке твоего профессионального направления и пытаешься сделать задачу с использованием этой технологии. Если чувствуешь что тормозишь, значит выявляешь базовые причины торможения и пытаешься их компенсировать (зачастую не понимания архитектуры, или причин почему так а не этак), если справляешься быстро, значит у тебя уже есть достаточная база и определённый опыт. В современном мире главное то с какой скоростью ты можешь разобраться в новом, правда это напрямую зависит от того что ты уже знаешь и умеешь.
и отправляешь штук 10-15 откликов… потом ходишь на собеседования… и вот после 3-5 «позорных» собеседований, ты поймешь ЧТО от тебя нужно работодателю, чтоб взять тебя на работу.
Часто от джуна ждут только адекватности и умения понимать что нужно сделать в задаче
п.с. на моем собеседовании на джуна php мы решали логические задачки про горящие веревки, монетки и лодки… ну и попытались спроектировать базу данных для мессенджера… с задачками все было хорошо, за БД было стыдно… на работу в итоге взяли — через месяц подняли зп
Да, почему я на такие мелочи обращаю внимание?
Когда ищешь человека к себе в команду, есть хороший шанс что наймешь того, кто будет создавать проблем больше, чем решать.
Тестировщик, нет?
Я всю карьеру пытался понять, кто я есть
Забавно, но у вас уже есть ответ на этот вопрос
Philipp Ranzhin fillpackart
Король разработки
Хорошая статья. Спасибо.
Я считаю, что они ошибаются, но доказать ничего не могу, мой потенциал в работе с Xamarin — неизмеримая штука. Опыт, раз его можно посчитать в годах, слишком часто вводит в заблуждение.
Я как-то посчитал свой опыт в годах. Поделюсь не выпендрежа ради, а просто как интересную находку:
Входные данные:
Реальный опыт всегда приходит первые пол года — новые технологии, новые привычки команды. Потом он тоже растет, но в разы медленнее.
Я привык менять работы раз в полтора года (нормальная цифра для нон-конформиста, погрязшего в войнах за ненужные идеалы). Мои знакомые разработчики меняют в среднем через 4-5 лет.
Считаем:
То есть за каждые полтора года я получаю полугодовой опыт. А мои усредненные друзья — за каждые 4.5 года получают. То есть у меня уже в 3 раза больше опыта и на каждые их 10 лет у меня багаж на 30 лет.
Едем дальше. Я работаю на нескольких проектах 6 дней в неделю. За последние несколько месяцев мой средний "счет" работодателю на 250 часов. Усредненный коллега выдает в районе 160. То есть коэффициент 1.5. Теперь на каждые их 10 лет у меня уже 45 лет опыта, а не 30.
А теперь наступает самое интересное. Кругозор то выше получился. Теперь ты часто разговариваешь с менеджерами, архитекторами. У тебя развиваются скилзы общения, появляется вера в свой авторитет, связи. В добавок к кругозору с диким коэффициентом, ты научился продавать себя и свои идеи.
И вот уже ты единственный в команде, задачи которого перебрать десяток новых технологий, найти подходящую и ее имплементировать. То есть, условно, я поработал с Consul, etcd, ZooKeeper и еще несколькими технологиями — это всё мой багаж теперь, а пацанам в команду спустил только Consul, как победителя — это их багаж. И код ревью ты теперь проводишь чаще, как авторитет. Видишь разные подходы, взвешиваешь их — все это садится в твой багаж кругозора. Тут коэффициент минимум 5. Вот уже против их 10-ти лет опыта у меня есть 225 лет :-D
Итого при моих 17 годах в резюме у меня по факту 380 лет опыта. Это еще по сравнению с теми, кто работает на работе, а не штаны протирает.
А еще я опустил момент, что самые сложные задачи по траблшутингу всегда сливаются на самого авторитетного, когда остальные сдались, а у авторитета уже никого за спиной и придется решать. То есть рост опыта и за свой счет и за счет коллег, в то время как они не растут практически.
Поэтому, когда спрашивают сколько лет опыта, я перед ответом оглядываюсь, нет ли рядом санитаров :-D
Как у вас с опытом долгосрочного развития проектов (и разработки и планирования и поддержки)?
В моей картине мира при таких скачках его получить нереально, так как многие решения имеют последствия на интервале времени от года и далее. То есть либо ты не видишь всех последствий своих решений либо не знаешь причин сложившейся на проекте ситуации.
Кроме того, это ж плучается: 3-6 месяцев въезжаешь в проект, 1-3 месяца передаёшь дела. А работать когда? :-D
Как у вас с опытом долгосрочного развития проектов (и разработки и планирования и поддержки)?
Ну вот вам стандартный сценарий. Приходишь весь такой опытный, все в жизни повидал, знаешь от чего загинаются проекты — ты видел не мало этого дерьма. Смотришь на проект, который обслуживали те, кто по долгу работают, и кровь из глаз течет.
Приходишь со списком технических долгов, которые срочно надо исправить. И тут тебе прилетает ответ от менеджера, который 10 лет уже там работает: у нас нет времени, делай фичу!
Кто тут стратег?
Люди только на входе стратеги. Потом их сжирает система и стратегические ценности притупляются. На Хабре очень много статей на эту тему.
То есть либо ты не видишь всех последствий своих решений либо не знаешь причин сложившейся на проекте ситуации.
Ты приходишь уже в компанию, где уже это случилось. И все это сделали "стратеги"))) Ничего не пропустишь. Более того, чем больше работ сменишь, тем больше стратегических ошибок увидишь. Опыт будет богаче.
Кроме того, это ж получается: 3-6 месяцев въезжаешь в проект, 1-3 месяца передаёшь дела. А работать когда?
Никто никогда не занимается отдельно "въездом в проект". Просто получаешь задачи, задаешь вопросы попутно, что-то из кода понимаешь. Нет никаких 1-3 месяца. Просто первые месяцы чуть подтупливаешь.
Передавать ничего не надо. Надо писать код так, чтобы человек открыл и все было понятно сразу — побольше декларативности + комментишь сложные моменты. В конце концов все работают над тем же кодом. Все с ним знакомы. А если видишь ситуацию, что каждый как ковбой работает над своим и не знает ничего вокруг, то с этим надо начинать работать с первого дня, а не перед выходом (что мы там о стратегии говорили выше?).
Бывает, что получаешь фидбэки со старой работы и через годы после ухода.
Никак не могу привыкнуть, что у меня восемь лет опыта и я видел некоторое дерьмо в больших количествах, принимал глобальные решения в рамках крупного проекта самостоятельно, руководил разработчиками, и когда я чего-то не помню — это потому что более важные для текущей работы вещи вытеснили из мозговой оперативки менее важные данные.
Это реально проблема иногда, из-за этого мне сложно просить прибавку к зарплате. Хз как с этим справляться, нет у меня уверенности в своем опыте и способностях.
Просто помните что большинство программистов в этом плане от вас не особо то и отличаются :)
У меня стаж 15+, но это просто означает что я, по сравнению с собой восемь лет назад, просто видел в два раза больше бардака и наступил на большее количество граблей. Ну и несколько новых технологий в стэк добавил, куда же без этого.
Но особо умнее я за это время не стал, а зарплату всё равно прошу заметно больше :)
Понравился основной посыл, про скилы и людей.
Успехов Вам!
Будет тормозить команду? Научим.
Будет задавать тысячи вопросов — ответим.
Будет писать дерьмовый код? Отревьювим.
Но зачем, если можно взять человека, который ничего этого делать не будет, а будет выдавать хорошие инженерные решения, не требуя дополнительных ресурсов со стороны команды?
Нет, это не так. В основном это зависит от команды, принятых в ней процессов и методологий. При чистой кодбазе, хорошей документации и покрытии тестами, соблюдении гайдлайнов и ключевых правил разработки ПО человек, владеющий этими инструментами, может начать контрибутить полезный код решающий небольшие задачи (которые хороший лид всегда имеет в отдельном уголке бэклога с тэгом for-beginners
) в первую же неделю, попутно вкатываясь в кодбазу и архитектуру.
Соответственно владение инструментарием и методологиями и нужно проверять на интервью, наравне с софтскиллами и соответствием ценностям команды.
При чистой кодбазе, хорошей документации и покрытии тестами, соблюдении гайдлайнов и ключевых правил разработки ПО
Интересно, такое хоть где-то бывает? Обычно более-менее хорошо дела обстоят в относительно свежих проектах. То что пилят больше года обычно обрастает проблемами, странным кодом, тестами покрыто все так реденько и не всегда актуально, про документацию даже говорить не хочется, что-бы не напрашиваться на воспитательные меры от модераторов.
Вы знаете, я регулярно слышу такие вот вопросы: "а разве бывают проекты с нормальным покрытием тестами?" "а разве можно писать всё время по SOLID?"
Пока мы будем это спрашивать, ответ всегда будет "нет, не бывает". Надо ставить вопрос по другому: "почему у нас на проекте нет тестов? почему мы не соблюдаем методологии, придуманные не самыми глупыми людьми? почему мы используем общеизвестные антипаттерны?" А ещё лучше: "почему я молчу на код-ревью, когда я вижу спагетти-код? почему я не прошу звать меня на собеседования с потенциальными новыми людьми в команде?"
В одном я готов дать слабину — документация в динамично развивающемся проекте как правило фатально отстаёт от функционала, поэтому надо или автоматом генерировать спеку на API, или наоборот — спеку писать руками, а из неё — генерировать boilerplate кода, контроллеры, DTO и вот это всё.
Надо ставить вопрос по другому: «почему у нас на проекте нет тестов? „
Ну они как-бы есть, но уже все устарели и в основном отключены. Нет времени с ними возиться, да и желающих это делать нет, всем интереснее пилить новый функционал чем разгребать тонны воняющего древнего кода. Хорошо что ты об этом беспокоишься, вот ты и займешься тестами. (Далее следует многодневное “наказание тестами», когда все делают что-то интересное, а ты работаешь ассенизатором, пока на тебя не свалится какая-либо более срочная и интересная задача)
почему мы не соблюдаем методологии, придуманные не самыми глупыми людьми?
А мы их соблюдаем… вот у нас митинги по утрам — отчитываемся «нащальниге» о том что запилили вчера, вот у нас тут модный дизайнерский опенспейс, на котором мы весело и задорно болтаем по пол дня с коллегами из смежных отделов. Некоторые из нас даже на конфы когда-то ходили, о чем у них над столами почетные грамоты есть, вот!
почему мы используем общеизвестные антипаттерны?"
Защем ругаешься нащальниге?
А ещё лучше: «почему я молчу на код-ревью, когда я вижу спагетти-код?
Вот лично я никогда не молчу и апрувы не ставлю (впрочем на нынешнем месте работы с этим все ОК)
почему я не прошу звать меня на собеседования с потенциальными новыми людьми в команде?
Наверное потому что я разработчик а не НР, мне это просто не интересно (да, я по возможности предпочитаю заниматься интересным)
Я понимаю к чему вы клоните — мол проблемы вашего бизнеса в вас самих. Как мне кажется главный изъян такого подхода состоит в том, что это не мой бизнес, и мое слово в управлении им практически ничего не стоит. И я даже понимаю владельцев этого бизнеса, потому что по своему они правы. Избавление от говнокода не несет им прибыли, до определенного предела и убытков так-же не приносит. А к моменту когда код протухнет настолько, что это начнет сказываться на прибыли, обычно сам продукт уже можно выбрасывать на помойку и пилить что-то новое, потому что он уже неактуален.
Конечно кошерный код, на 100% покрытый тестами, идеально написанный, со спеками и доками, это все классно, но владельцам бизнеса как правило на это начхать, им как и любому другому капиталисту важна в первую очередь прибыль. Если забив на тесты и красоту кода можно сократить время и стоимость разработки в разы, то так оно и будет сделано (и оно так и делается).
Не скажу что мне это доставляет удовольствие, но так оно и есть в реальности. Редкие исключения только подтверждают правило.
Слова, которые я сейчас напишу, я пишу так часто, что надо уже их в отдельную заметку в Evernote положить и копипастить оттуда.
Мы живём в уникальном отрезке времени, когда инженер-разработчик ПО является самым востребованным массовым наёмным работником в мире. На наши головы официально не закрывается сезон охоты) Наш труд высоко или очень высоко оплачивается.
Одновременно у нас имеются безграничные возможности для профессионального роста, стоит только протянуть руку. SO, статьи, книги, митапы, конференции, онлайн-курсы, open source проекты, которые можно изучать и в которые можно даже контрибутить.
На собеседовании нам позволяют по полчаса задавать любые вопросы о компании: какой у вас график работы? Какую технику предоставляете? Как проходит код-ревью? Какое у вас покрытие тестами? Какие методологии вы используете? Какой возраст кодбазы? Как вы управляете техническим долгом? Выделяется ли время на рефакторинг?
Как в этой ситуации мы можем говорить, что дело в ком-то ещё, кроме нас?)
Когда готовишься к собесу на высокий уровень, ты уже даже не говоришь себе, что врать не нужно. Ещё как нужно. Они бы не наняли тебя, если бы всё точно про тебя знали, потому что они сами себе ещё не признались, что нихера не знают. Ты принимаешь правила дурацкой игры, и выпендриваешься на собесе в ответ на их выпендрёж, они врут про свою крутость — а ты врешь ещё круче. Дальше вы знаете, что будет. Они тоже тупые, как и ты.
Поначалу примерно так-же думал, отчего все собеседования были диким стрессом, да и успешных среди них было немного.
Все сильно изменилось когда я начал относится к ним именно как к беседе (на что само название — [со]беседование недвусмысленно намекает) Если что-то не знаю или основательно забыл — просто говорю об этом, прошу пояснить, возможно вспоминаю или понимаю о чем речь (иногда вопрос так задают что не сходу получается понять).
Пример 1:
Пускай есть хорошая компания X, которая платить ЗП Y и в которой работает много разработчиков.
В это же время на рынок мечтает выйти компания Z, которой нужны разработчики, но, например, она и сравниться не может по уровню внутренней технической экспертизы, она пуста и чиста, и очень хочет наполниться, вот только кем? Тогда компания умеренно будет платить абсолютно по всем позициям выше рынка (выше компании X), т.е. Y + 20%.
Ведь только так она сможет перетянуть специалистов.
И рынок исказится, в компании X сениоры будут получать столько же, сколько в компании Z мидлы. Таковы реалии и никакого отношения к количеству прочитанных книг, выигранных олимпиад по программированию или просто уровню личной задроченности эти предложения по ЗП не имеют.
Пример 2:
Вы СТО из той самой компании Z (сами придумайте откуда вы там взялись :) ), вам нужно нанять и построить команду, вы дали все ЦУ своему коллеге-HR, она принялась добывать вам кандидитов, причем, как вы помните, компания заведомо согласна платить чуть выше рынка.
И тут вы заметите, какой же поток шлака приходит на собеседования, они не просто про SOLID не слышали, они не знают как подключаться по VPN, не понимают чем они будут отправлять http запросы и то, что они бывают разных методов, не понимают где вообще можно применить NOSQL базы данных и т.п. А вы в свою очередь уже хотите, чтобы ваш новый коллега вас хотя-бы не раздражал. И не понимаете, «почему еще вчера этот тип водил маршрутку, а сегодня вдруг решил, что он разработчик?!», и «почему, оказывается, так можно было?»
Уровень ваших скилов и ЗП определяется только тем насколько сильная у компании нехватка кадров. Если, например, это mail.ru, у них всегда есть резерв по более-менее нормальным кандидатам, и они не предлагают ЗП выше рынка, но они предлагают компанию с большой технической экспертизой внутри.
А вообще, безусловно, оценка и привязка знаний и опыта к уровню ЗП сильно не справедлива на рынке IT, как в России, так и вообще везде.
Как и сама жизнь.
Разработчики в среднем норм.
В рамку и повесить над входом в офис.
Мне кажется, что можно проще: критерий — насколько кандидат подходит команде и насколько команда подходит кандидату. Обоюдное приятие и дальнейшее сотрудничество.
Я пришел к выводу уже давно — вообще не важно сколько человек получает или получал денег — это слабо связанно со скидками и реальным велосити его как спеца на проекте.
Самый адекватный найм людей по моему мнению — брать тех, кто прошел проверку на солидность, на неделю на испыталку с заранее оговоренной таксой/час.
Спустя неделю станет ясно сколько он делает велью и как это велью (конкретно для твоего проекта) соответствует его ожиданиям по зп
Конкретно мне проверять людей на собеседованиях часто — не приходиться, было пару раз, не более. Мне не нравится процесс найма людей — это ответственность, риски и грусняшки.
Но если бы (да кабы) я в одно лицо принимал все решения в команде, и передо мной был бы нерешенный вопрос найма — делал бы так, как отписал.
Когда я был джуном, если не хуже пошел на собеседование в одну маленькую фирму которая занималась веб разработкой. Поговорили, и мне дали просто консоль с базой прода и попросили выполнять запросы. Задачи ставили абстрактно, типа выбери все продукты с ценой больше чем 10, сгрупируй товары и т.д. Отвечали на вопросы про структуру базы, понятно что я не все связи мог сходу уловить. Вообщем тупил я жестко, ошибался в запросах, перепроверял по много раз чтобы ничего не сломать. Но офер получил сразу.
Аналогичная история была у знакомого, пошел он на собеседование к одному крупному провайдеру на должность сисадмина. Ему дали консоль рутовую и попросили обновить почтовый сервер, корпоративный. Он просто взял и обновил все что надо. Офер тоже получил сразу.
Тут ты или умеешь делать, или не умеешь. Разговоры не особо помогут в этом случае.
В итоге я оттуда сбежал и до сих пор жалею что зачем-то мучился там почти год, надо было еще с испытательного уйти.
Иногда даже после испыталки в 3 месяца человек на сеньорской позиции не может ещё делать то, что нужно организации, никого не дёргая, и это нормально считается. А тут за час надо понять...
Хнык, я тоже неудачник. Мне тоже отказывали на собесдованиях.
Из последнего опыта найма на удалёнку в достаточно крупную компанию, называть не буду, но она есть на Хабре — работа удаленная, без тестового задания не обошлось. Моё решение раскритиковали, не раскрывая деталей и в работе отказали. Ну, казалось бы, бывает, да и фиг с ними. Но не тут-то было, вместе с отказом прислали ссылку на главу учебника по паттернам из платной книжки по паттернам, написанной людьми из той компании.
Аха, перечитав после отказа условия задачи, я вник в намёки и понял что нужно было использовать другой паттерн. Хотя учебники в этой ситуации рекомендуют делать так, как сделал я, и как я делаю в текущих проектах. Бывает ....
Вот и думай, тебе всерьёз давали тестовое задание, или изначально имели в виду рекламу той книги.
Вы поймите: IT не уникально. Так же трудно оценить, насколько хорош будет врач, учитель, топ-менеджер или даже боец в бандитскую бригаду. И всё-равно люди как-то оценивают друг друга, берут и потом дальше вместе работают.
Люди не поддаются точным оценкам, в этом наша слабость, но и сила. Мы так или иначе можем выйти за границы обычного, устроиться лучше или проиграть. И это normalno. Оставьте уже пустые мечтания о причёсывании всех по одному стандарту
Я взял все качества, которые лично мне кажутся важными, и каждое из них оценил по шкале плохо/хорошо/отлично.
До недавнего времени в компании, где я работаю не было лычек jun/mid/sr, хотя ребята есть разные. Каждый случай был особенным (продуктовая компания, всего 60 человек, из которых около 25 инженеры). Но потом появились косяки когда тот, кто хорошо показал себя на собесе и зп получал сеньорскую, не оправдал сеньорских ожиданий. И узнал об этом слишком поздно, потому что ожидания эти никогда не были оглашены, как и уровни разработчиков. Так что теперь решили все-таки как-то все формализировать, чтобы было понятно где ты сейчас и как получить рейз на следующий год. Долго не думая, взяли progression framework от Monzo и чуть подогнали под себя. После этого все заполнили self-assessment по всем пунктам выбирая между none/learning/profficien/expert и тимлиды заполнили аналогичные анкеты для инженеров в своих командах. Уже неплохо было увидеть разницу между тем как оцениваешь себя сам, и как видят тебя другие. Потом был интересный митинг по сведению этих двух таблиц между лидами и инженерами 1:1.
Мне собственно интересно что в свой список включил fillpackart. Если у кто-то еще может расшарить метрики с которыми встречались – буду весьма благодарен.
Когда из команды уходит человек, было бы неплохо понимать какого человека искать на его место. Как минимум какими качествами и свойствами его замене нужно обладать чтобы делать аналогичную работу на аналогичном уровне.
Как бы то ни было, мне нравится идея сведения двух и более субъективных оценок по одним и тем же критериям. Где результатом является не оценка общего уровня от 0 до 10, а скорее сравнение того как ты видишь себя и как тебя видит твой тим лид. Это очень помогает в управлении ожиданиями с обеих сторон.
я как то пришёл устраиваться на вакансию «Проектировщик электрик», у меня спросили первым вопросом «какой программой вы будете рассчитывать уровень освещенности в помещениях» я говорю не знаю. И мне тут же сказали «вы нам мне подходите», я говорю ну в Яндексе я название программки и саму программку за 1 секунду найду. Дальше то что. Давайте на понимание предмета поговорим. «нет» сказали и всё. В свою защиту скажу я тогда не работал никогда электриком, проектировал только связь и ЛВС.
Хотя не раз я общался с успешными электриками проектировщиками и реальными электриками, которые всерьёз смотрели ролики на Ютубе и обсуждали методы получения свободной энергии, типа крутануть генератор, запитать от него мотор, который будет крутить генератор…
Вот чудесный вопрос пришёл в голову. Сколько книг собеседующие читают о том, как правильно собеседовать? Сколько таких книг написано? Сколько часов практики им требуется для того, чтобы стать хорошими собеседующими? Как анализируются ошибки при найме вида «мы думали, что он умный и добрый, а он оказался своевольным и деревянным по пояс»?
Сколько книг собеседующие читают о том, как правильно собеседовать? Сколько таких книг написано?У нас в компании читают лекцию о том, как правильно собеседовать. Насчет книг не знаю, но вряд ли в них есть острая необходимость.
Сколько часов практики им требуется для того, чтобы стать хорошими собеседующими?Два часа. Сотрудник, прошедший лекцию, присутствует на собеседовании, но молчит, и в конце с тем, кто собеседование проводил, обсуждает, как прошло (shadow interview), потом на собеседовании сотрудника присутствует ментор, и молчит, и тоже в конце обсуждают, как прошло (reverse shadow interview).
Из вашей статьи я узнал, что в JavaScript можно ставить подчерк (_
) посреди числа. Занимаюсь разработкой на JS уже много лет.
Как разработчик, я никогда не знаю себе цену, потому что её нет. Но вся система построена так, как будто она есть