Комментарии 22
Курс «Мидл Python-разработчик»За 6 месяцев освоите навыки, которые отличают мидл разработчика от новичка
А как Вы считаете, это возможно, за 6 месяцев стать мидлом на пайтоне?
А как Вы считаете, это возможно, за 6 месяцев стать мидлом на пайтоне?
Если коротко ответить на вопрос именно в такой формулировке: нет.
Если всё же раскрыть мысль, то: нарастить навыки, подтянуть недостающие компетенции, набить руку уверенному джуну так, что б рынок (или текущий работодатель) воспринимал его мидлом - запросто, но придётся пахать. Прям очень много работать, что б уложится в отведённый срок. Мы говорим о 4-6 часах личного времени потраченного на обучение каждый день минимум. Крайне желательно при этом работать в отрасли и применять полученные навыки.
Опять же понятие и разграничение джуна/мидла очень разнятся в отрасли, я говорю лишь о тех критериях, которые я выработал для себя в рамках рабочей практики.
Уверенный джун ==новичок?
Я вот вижу слово новичок и воображение рисует того кто не знает типы переменных и циклы например.
Это в целом придирка в каком то смысле, просто тезис выглядит в духе С++ за 21 день xd
В моей картине мира джун действительно == новичок. Он только научился писать код, что-то может, что-то умеет, но специалистом его ещё рано называть.
Курс именно для них, там чуть ниже есть блок этому посвящённый как раз:
Программа рассчитана на тех, кто знаком с основами Python, базами данных и API. Будет большим плюсом, если вы прошли курс Практикума «Python-разработчик» или уже работаете по специальности.
А ещё чуть ниже про вступительный тест:
Вступительный тест. Это курс для разработчиков с опытом, поэтому вначале будет вступительный тест. Он будет полезен и вам, и нам. Вы — сможете убедиться в том, что курс будет оптимален по сложности. Мы — будем уверены, что наши студенты обладают достаточными навыками для прохождения курса.
В целом тезис взят с промо страницы курса, а не из статьи, потому предлагаю оставить эту дилемму автору лендинга. Со своей стороны лишь добавлю, что C++ за 21 день действительно не изучить, но, справедливости ради, статья посвящена другой теме и данный вопрос вообще никак не затрагивается :)
Я на последних интервью стал задавать вопросы - как устроена команда? кто, как и где ставит задачи? кто и как определяет время на выполнение задач или их приоритет? кто и как контролирует их выполнение? как проводится кодревью? сколько времени команда выделяет на закрытие техдолга/рефакторинг?
Как мне кажется, это очень важные вопросы, которые раскрывают всю степень жести в которой вам предстоит работать, а печеньки в наше удаленное время на 90% бессмыслены, особенно если вы в разных странах работаете.
Полностью согласен. Лично я воспринимаю процесс интервью двусторонним: не только меня интервьюируют, но и я. Не только работодатель выбирает соискателя, но и соискатель работодателя. Поэтому вопросы можно и нужно задавать, что б принять обоснованное решение.
Речь в статье скорее про прохождение технического интервью, а в рамках его не всегда есть возможность задать все интересующие вопросы, да и вы всё ещё находитесь на стадии когда интервьюируют вас в большей мере. На моей практике обычно это чаще происходит именно после оффера или на отдельных сессиях, так называемых "финалах", но минимальный набор информации можно получить и уже в рамках технособеса.
Меня после таких вопросов обычно сразу разворачивали
Так отлично, что рано выявили несовместимость
Но по итогу так везде
Это очень странно, что везде. На моей практике интервьюеры крайне положительно относятся к вопросам. А можете дать больше контекста с примерами дать. Какие вопросы и как задавались, какой был ответ, с какой формулировкой разворачивали?
— У вас приходится перерабатывать? Участвует ли разработчик в согласовании сроков на задачи?
— Переработки есть, они не оплачиваются. И вы должны быть on-call 24/7. Мнение разработчика о сроках никто не спрашивает
— Меня не устраивает такой расклад
— До свидания
Звучит как галера, если честно. Я пару раз из интереса собеседовался в такие конторы, но быстро понял, что это не моё, потому начал избегать подобное ещё на просмотре вакансии или разговора с эйчаром, если меня где-то нашли. Благо их не сложно отфильтровать в общем потоке. Опять же, отрасль большая, конечно зависит от вашей специальности (какая если не секрет?) и квалификации, может где и более высокая плотность и они лучше мимикрируют под адекватного работодателя.
В любом случае, если мы говорим именно о вышеописанном диалоге, то всецело присоединяюсь к @ValeryGL. Отлично, что узнали это на собеседовании, а не в процессе работы. Я бы считал это скорее успехом и тем, что вы смогли избежать проблем, а не тем, что вас развернули.
Я собеседовался в крупняк, на продукт. Я понял, что размер компании, её брэнд и т.д. не значат ну вот вообще ничего. По специальности и квалификации я middle backend. Ну, был. Я решил уйти из IT. В нём теперь слишком много дерьма, с которым я справиться не в состоянии. Собеседования с неадекватными техническими вопросами вида "какую ассемблерную инструкцию сгенерирует компилятор Go для инкремента", LeetCode-задачами на роль перегонщика JSON'ов (а ещё всё это в кучу этапов на месяц, если не больше, лол), урезанные сроки, переработки, отсутствие уверенности в завтрашнем дне, постоянный стресс. Всё это совсем не стоит любой зарплаты
Крупняк бывает разный. Собеседовался/работал в разных отделах/департаментах казалось бы одной и той же кампании и всегда было по разному, часто всё в итоге зависит не от конкретной кампании, а людей, с которыми предстоит работать, хотя корпоративная культура тоже имеет свою долю влияния.
Я видимо с годами перестал близко к сердцу воспринимать что и как меня спрашивают на собеседованиях, а спрашивают действительно разное, порой крайне странное, от вопросов как именно поведёт себя интерпретатор в случаях, когда это явно UB, но этого ответа недостаточно и интервьюер ждёт конкретного поведения зависящего от версии, OS, фазы луны и бог знает чего ещё, вплоть до "а вы не читали вот эту конкретную не самую популярную статью по теме, хотелось бы услышать мнение" когда ответ "нет, не читал" недостаточен и вопросы на тему продолжаются. На фоне этого алгоритмические и system design собесы меньше всего смущают, даже скорее уже стали одной из самых комфортных и спокойных из возможных опций, потому что просто знаешь что ждать, даже если в конечном итоге будешь перекладывать json'ы или ковырять инфру :)
По поводу стресса, полностью соглашусь, за деньги здоровье и нервы потраченные на работе потом не купить. Могу лишь пожелать удачи и успехов на новом поприще!
хорошие вопросы, я как тех.интервьюер отвечаю на подобные вопросы и встречный интерес проявляю - как работал кандидат.
Очередная статья о том, как соискатель должен выполнить всю работу за рекрутёра, потому что резюме читать лень, подготовить речь о своей компании/команде в голову не приходит.
Есть хорошие рекрутёры, есть плохие. Есть подготовленные соискатели, есть пофигисты. В моей картине мира из того что есть плохие интервьюеры, которые некачественно выполняют свою работу, совершенно не следует, что нужно относиться к процессу собеседования на авось со стороны соискателя.
Хотя опять же, как вы правильно сказали, соискатель никому ничего не должен. Кликбейтного посыла "Ты должен следовать этим 10 простым правилам, и получишь 100 из 100 офферов с ЗП 300к/с" я специально старался избегать. Это лишь мой личный опыт консолидированный в статью поскольку у меня несколько раз конкретно этой темой интересовались начинающие специалисты и для них ряд нюансов как оказалось был неочевиден.
Если будет кому-то интересно могу написать идентичную статью, где соберу своё сугубо личное мнение по процессу и подготовке к собеседованию со стороны интервьюера.
А был тут на хабре хоть один хороший? Который бы написал не как программистам под эйчаров подстраиваться, а как эйчарам искать программистов без всего этого безумия?
Напишите, сделайте одолжение, я думаю ваша карма в небеса улетит, и статья станет статьёй года.
Подожду под вашим постом лайков хоть немного, а то, что-то мне подсказывает, что это крайне непопулярная, а главное холиварная тема :)
я думаю ваша карма в небеса улетит
Я думаю тут много читает и тех кто собеседует или работодателей, но молчат, чтобы карма не улетела ↓ как-раз )
Собственно продолжение: https://habr.com/ru/companies/yandex_praktikum/articles/783212/
Уже заминусовано слегка :D
Всю статью не буду делить и комментировать отдельно, но сделаю ремарку на тезис с начала статьи.
...это страх отказа. <...> Отказ — это не приговор, а возможность сделать вывод, поднять навык и двинуться дальше.
Страх отказа связан не с тем, что могут отказать. Страх отказа появляется из-за того, что непонятно что нужно компании. Приходя на собеседовании совершенно невозможно предугадать результат. Даже не смотря на то, что есть вакансия и в ней описание задач. Соискатель может быть готов к этим задачам. А тех.специалист этого не видит. Потому что само собеседование идёт другим путём. Потому и отказ может быть любым. По любой причине. И понять этого нельзя, если интервьюер сам не скажет правдивую причину.
Почти два года назад я менял работу. В период начала СВО. Я, за почти полгода, прошел около 50 собеседований. Может быть больше, я не считал детально. И могу просто по опыту написать, что нет чётких критериев отказа. Вообще. За все время у меня были разные собеседования, которые в чём-то отличались друг от друга. И потому знать что будет по итогу прохождения собеседований невозможно.
Но сама рекомендация правильная, что отказ - это не конец. Только лишь потраченное время на собеседование. Издержки поиска работы в IT. Это то, что нужно учитывать
Техсобесы — это просто, но есть нюанс…