Софт-скиллы нужны менеджерам, а простой разработчик может быть и токсиком. Или нет?
В новом выпуске подкаста «Сегодня на ретро» разбираем горячий вопрос и выясняем, так ли нужно айтишнику владеть навыками лидерства, тайм-менеджмента, общения и культуры обратной связи.
Обмениваться мнениями пригласили тимлидов: Артема Селезнева, CDO в NUUM, MTS Digital, и Максима Тижина, руководителя инженерно-технической группы в Selectel. Смотрите выпуск, чтобы решить, на что делать ставку: только на хард- или еще и на софт-скиллы.
❌ Оказалось, что есть типовые вопросы, которые часто задают на собеседованиях, но к которым я специально не готовился. ООП, SOLID, микросервис vs монолит и подобное — без подготовки ответ выходит путанным. ✅ Подботал типовые вопросы.
❌ В какой-то момент я забывался, что нахожусь на интервью и общался с интервьюером, как с коллегой: рассказывал о каких-то негативных моментах в прошлых проектах, говорил от имени команды в контексте "Мы”. ✅ На интервью должна быть дружеская атмосфера, но не нужно забываться. Интервьюера нужно убедить, что я именно тот специалист, который им нужен. На работу устраиваюсь Я, значит в моих рассказах должно быть побольше Я и поменьше Мы. В эту же сторону, поменьше рассказывать о каких-то проблемных местах, побольше рассказывать о удачно решённых задачах.
❌ Во время рассказа "о себе" уходил в ненужные подробности, из-за чего рассказ получался водянистым и производил скорее негативное впечатление. ✅ Я полностью прописал рассказ "о себе", в несколько заходов вычитал и отрепетировал, чтобы в итоге было недолго и по делу.
❌ Когда интервьюер спрашивал "есть ли у меня вопросы по вакансии и компании", то возникала заминка. Я спрашивал не очень связно и не всё, что действительно хотел узнать о потенциальном работодателе. ✅ Для этого я также составил чеклист со списком интересующих меня вопросов.
Компания Artisan, занимающаяся проектами на базе ИИ, выпустила в Сан-Франциско билборды с надписями «прекратите нанимать людей» и «эра сотрудников ИИ уже здесь» в рамках рекламы своего сервиса «ИИ-сотрудники» или «Ремесленники» (AI Employees или Artisans). В компании утверждают, что её ИИ-работники никогда не жалуются на баланс между работой и личной жизнью, выступают в качестве дополнительных членов команды, легко интегрируются в рабочий коллектив, беря на себя задачи, в которых они преуспевают, и сотрудничают с настоящими людьми, когда это необходимо.
Генеральный директор Artisan Джаспар Кармайкл-Джек в ответ на упрёки сообщества и обвинения в полной киберпанковской антиутопии встал на защиту этого рекламного хода. «Они несколько антиутопичны, но и ИИ тоже. Мир меняется. Мы хотели выдать то, что привлекало бы внимание — скучными сообщениями не привлечь внимание», — пояснил Кармайкл-Джек.
Сотрудник Apple пожаловался, что зарабатывает всего $800 тыс. в год и накопил всего $4.6 млн за 6 лет, а если бы пошёл в Nvidia, то получил бы более $20 млн в виде акций, судя по расчётам супруги. Как заявляет сам сотрудник, в Apple посоветовала устроиться его жена, которая теперь приводит финансовые аргументы против необходимости такого выбора.
Индийская компания YesMadam уволила всех выгоревших сотрудников одним днём, перед этим проведя тест на стресс. Тех, кто рассказал о высоком уровне стресса, просто выкинули с рабочего места, уточнив, что в компании стремятся сохранять «здоровую среду».
На днях выходила статья по собеседованиям на Unity. Вышла уже аж вторая редакция. Первая содержала «контент не для слабонервных». Жаль, что его по итогу вырезали — это был очень полезный опыт из реальной корпоративной практики. Тем не менее, всё полезное для широкого круга читателей осталось. В т. ч. отличные советы, под которыми я ставлю свои «+».
Процессы проведения собеседований — очень индивидуальная штука, и везде всё устроено по-разному. Есть вводные у кандидата, у команды, у проектов, у бюджета и т. д. Между ними приходится как-то балансировать и искать наиболее равновесную точку. Общего рецепта, как это сделать, нет. Только разве что «нормально делай — нормально будет». Поделюсь коротенько тем, как это делаю я.
1️⃣ Я стараюсь проводить собеседования наименее ресурсозатратно и для себя, и для кандидата. Мои целевые показатели — 30 мин на интервью, 30 мин на подготовку (но реальные медианные будут побольше 👺). Подготовка — это осмотр резюме, изучение информации о кандидате и прошлых местах работы в сети, знакомство с проектами и кодом.
2️⃣ Для меня код (если нужен программист) — ключевой и самый говорящий фактор. ТЗ я давать не люблю: стараюсь обходиться петами кандидатов. Но если посмотреть нечего или нет проектов с релевантными технологиями, то выдаю ТЗ на какие-то отдельные конкретные моменты, которые бы мне хотелось прояснить. Или посмотреть, насколько хорошо удастся разобраться с новой технологией.
Правда, если кандидатов много, то всё приходится усреднять и ставить на поток. Иначе основной рабочий процесс будет саботирован. Главное, чтобы на ТЗ уходило минимальное количество времени. В конце концов, и мне же это потом смотреть. Поэтому с каждой новой волной найма я стараюсь оптимизировать коллекцию заданий.
3️⃣ Интервью — самый дорогой этап с точки зрения времени и организации, поэтому он обычно остаётся на самый конец (чтобы оставалась возможность до него не дойти). Но если попадается интересное резюме, то могу сразу и перейти к нему, пропустив или отложив этап «кода».
Я перестал открыто гонять кандидатов по техническим вопросам. Более эффективным нахожу обычное общение про опыт, компетенции, практические кейсы и т. д. И в процессе, если натыкаюсь на что-то значимое и шаткое, начинаю копать глубже.
❗Причём я считаю очень важным давать свои комментарии на темы, в которых кандидат не смог достаточно раскрыться. Пусть он уйдёт, если без оффера, то хотя бы с новыми знаниями.
Из-за специфики разработки мне часто важно, чтобы новые члены команды были заинтересованы в продолжительном сотрудничестве. Поэтому на интервью я стараюсь определить ценности, мотивацию и цели кандидата. Что он понимает, куда и почему собеседуется, а не пытается просто запрыгнуть хоть куда-нибудь на какое-то время. И, со своей стороны, искренне даю все вводные. Для взаимовыгодного и плодотворного сотрудничества нужна обоюдная совместимость 🤝
Рекомендовал вам записать своё собеседование. Поскольку непроверенных советов я не даю, то совет я изначально обкатал на себе, то есть записал и проанализировал свои собеседования. Тезисно изложу свои ошибки, замеченные в результате просмотра собеседований и решения, к которым пришел.
❌ В самом начале собеседования возникала какая-то суета: включена ли камера и звук, открыто ли мое резюме, под рукой ли ручка с блокнотом. ✅ Составил небольшой чеклист, по которому пробегался за пару минут до начала собеседования.
❌ Камера смотрела не на меня, а в сторону, при этом я сам не смотрел в камеру, иногда я говорил не в микрофон и меня было плохо слышно. Да, это тоже очень важно. Собеседнику должно быть комфортно с вами общаться. ✅ Заранее настроил камеру, чтобы по умолчанию смотреть на собеседника, сделал в голове заметку говорить в микрофон.
❌ Я спешил ответить на вопрос интервьюера и начинал отвечать до завершения вопроса. Со стороны выглядело так, будто я просто перебиваю собеседника. Более того, иногда вопрос мог оказаться совсем не таким, как я думал. ✅ Пункт "дослушивать вопрос и не перебивать собеседника" отправился в копилку заметок.
❌ Порой меня спрашивали о технологиях, с которыми я не работал и про которые мало знал. В этот момент я терялся. ✅ При более предметном анализе оказалось, что на любую малознакомую технологию у меня в багаже есть аналогичная, решающая поставленную задачу. Я сделал для себя заметку: если не работал с технологией, не теряйся, подумай, как решить задачу знакомым способом. Более глобальная мысль: стараться минусы обращать в плюсы. И не забывать постоянно изучать разные технологии.
Сколько специалистов накручивают опыт работы в резюме и как это работает на их цели
Привет, меня зовут Настя, я занимаюсь контентом Хабр Карьеры.
Заметили, что в IT-сообществе уже несколько лет остро обсуждают тему накрутки опыта в резюме. Кто-то считает, что накрутка помогает найти первую работу, кто-то — что она искажает представление компаний о реальном опыте кандидатов и порождает завышенные требования к ним, а кто-то — что накрутка в целом подрывает доверие между специалистом и работодателем и «убивает» отрасль.
Вместе с телеграм-каналом Digital Ниндзя и его автором Александром Ильиным — разработчиком, который много и часто рассказывает про работу в IT — захотели разобраться в эффективности накрутки опыта в резюме.
Среди опрошенных, 29% IT-специалистов накручивали опыт работы в своем резюме, 11% из них перестали это делать. Не накручивали опыт подавляющее большинство респондентов — 71%.
Почти половина респондентов (49%) добавляет себе опыт, чтобы найти работу. На втором месте те, кто делает это для более высокого оклада в оффере (17%), еще 15% — чтобы подойти на конкретную вакансию.
Самая частая причина накрутки, которую называли специалисты в категории «другое» —пройти HR-фильтры:
— Обойти худший фильтр из всех. Надеюсь, его удалят и никогда к нему больше не будут возвращаться. Либо просто снизить планку от 0 до 3, от 3 и более лет. Так будет честнее, и смысла накручивать будет меньше.
Digital Ниндзя:«Самое забавное в этом то, как компании решают проблему накрутки. Они просто повышают планку лет опыта. На рынке уже есть джуниорские вакансии с тремя годами опыта. Это абсурд. Некоторые компании требуют столько же лет на сеньорские вакансии. Это вынуждает кандидатов накручивать ещё больше».
Большинство опрошенных (72,5%) достигли своей цели после накрутки, еще 20% сделали это только частично.
В мегапосте много графиков и данных о том, как работодатели вычисляют накрутку, как специалисты планируют работать в компании после трудоустройства с накрученным опытом, как часто бывает, что компания вычислила накрутку после ИС и многое другое.
Современный специалист должен быть в курсе большого количества различных технологий и инструментов. Подобное знание не появляется из ниоткуда и не может быть освоено за выходные. Только процесс постоянного поиска информации и решения прикладных задач может приблизить к умению решать любую проблему за счёт представления места обитания потенциальных источников проблем.
Как организовать процесс постоянного поиска информации? Нужно на постоянной основе (в идеале ежедневно, нормально раз в несколько дней, приемлемо еженедельно) потреблять разнородную информацию как в своей профессиональной области, так и в различных соседних. Это существенно расширяет кругозор и повышает вероятность решения новой задачи впоследствии. Не стоит забывать и про не-технические скиллы, куда входят управление людьми, воспитание детей, истории из жизни — это позволит ориентироваться не только в технологиях, но и в жизни.
Неплохим источником информации для постоянного потребления могут быть проверенные книги, телеграм-каналы, подкасты, хабр, площадки вроде hackernews. Решать прикладные задачи самому тоже не следует забывать.
На хабре каждый день читай топ-3 статьи за сегодня, еженедельно читай лучшие 20 статей за неделю. При этом смотри не только саму статью. Часто более полезным является чтение комментариев, где сторонние люди любыми способами постараются доказать, что автор не прав. Чужие мнения могут развить твоё критическое мышление — умение видеть проблему в предлагаемом способе решения задачи.
В году чуть больше 50 недель. При еженедельном чтении десятка статей за год ты прочитаешь около 500 статей. Эти 500 статей и комментариев с обсуждением пополнят копилку решений и обсуждений. Ещё обсуждая с коллегами очередную задачу, можно приобрести опыт решения 500 других задач. И подойти к следующей задаче во всеоружии.
В сети опубликован шуточный адвент-календарь с увольнениями. Суть календаря проста: каждый день в одной неназванной (вероятно, выдуманной) компании кого-то увольняют, причём «счастливчика» выбирает рандом. И так до Нового года. До праздничной премии доживут не все.
Гость нового выпуска Android Broadcast — Сергей Боиштян, Android-инженер в Авито. Сергей обсуждает профессию билд-инженера с ведущим подкаста Кириллом Розовым. Вот про что говорят:
с какими задачами приходится сталкиваться в практике;
какой прогресс достигнут в Gradle и Android Gradle;
какое будущее нас ждёт в сборках Android и Kotlin Multiplatform-проектах.
Сергей знает, о чем говорит, ведь он из команды Speed: эти ребята у нас занимаются developer experience для Android-разработчиков Авито. Проще говоря — позволяют нашим инженерам сфокусироваться на написании фичей, пока такие богатыри, как Сергей, разбираются с версионированием, библиотеками и прочими штуками.
В подкасте Сергей рассказывает про жизнь билд-инженров, их задачи и историю — откуда они вообще взялись и как эволюционировали до актуального состояния. Настоятельно рекомендуем послушать!
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Пересмотри своё собеседование В статьях про собеседования часто говорят о пользе обратной связи после интервью. Беда в том, что компании нечасто дают обратную связь. Вы получаете либо оффер, либо отписку в духе "извините, но вы нам не подходите".
Вы можете быть отличным специалистом. Вы можете потратить тонну времени на изучение нового материала, щёлкать задачи с leetcode, знать теорию и практику прохождения собесов. Но один небольшой аспект может всё испортить. Держитесь неуверенно? Путано излагаете мысли? Пропускаете ключевые детали, в результате чего изложение выглядит рваным и несвязным? Зависаете при ответе на вопрос?
В случае онлайн-собеседований у вас есть уникальная возможность посмотреть на себя со стороны. Запишите всё: аудио, видео со своей камеры и монитор с собеседником. На Linux для записи экрана удобен Kazam.
По видеозаписи вы сможете выявить свои косяки, которые совершенно не заметны без взгляда "со стороны". Кроме того, вы можете словить реакцию собеседующего на ваши ответы. В процессе интервью сделать это сложно — мозг занят другими вопросами.
После прохождения интервью просмотрите запись и выявите систематические ошибки. Легко сказать — выявить ошибки. На деле совсем не просто найти проблемы в своём же интервью.
Хорошим вариантом будет получить мнение со стороны. Попросите друзей посмотреть вашу запись свежим взглядом и подметить проблемы. Прямо по пунктам, где и что не так.
Все полученные замечания нужно критически обработать. Проанализируйте и проработайте каждый пункт, чтобы не повторить ту же ошибку в будущем. Сформулируйте список проблем, которые нужно поправить.
При анализе следующего интервью сверяйтесь со списком проблем. Всё ли получилось исправить?
По результатам просмотра двух первых интервью мои злые друзья нашли 36 проблемных мест. В результате их проработки я сформулировал десяток конкретных пунктов как надо делать и как делать не надо.
Запишите своё следующее интервью и проработайте его. Вы удивитесь, как много нового можно узнать.
Желательно спросить разрешение противоположной стороны на видеозапись. С другой стороны, если вы не планируете запись публиковать, то требуется ли разрешение?
Про доходы разработчиков, ч.1: зарплаты в "технологических хабах". На реддите кто-то собрал с levels.fyi данные по з/п software engineer в tech hubs после налогов, добавил аренду скромного жилья с numbeo, учел cost of living и rent index.
Можно оценить, как получится копить разработчику в разных городах!
К точности данных могут быть вопросы, многим указанное на levels кажется завышенным. Может и так, но нам важна разница между городами. Выводы актуальны для любых айтишников, просто разработчики - самые горячие пирожки.
Данные хорошо иллюстрируют многие мои тезисы:
1️⃣ В 🇺🇸 США з/п несравнимо выше, чем почти везде. В Европе очень мало городов, где есть что-то близкое. Ну да, 🇨🇭 Швейцария, 🇬🇧 Лондон и 🇮🇪 дублинский фаанг, как я и писал ранее.
2️⃣ Самым амбициозным молодым инженерам нет смысла ехать в 🇪🇺 ЕС: на горизонте 5-10 лет менее талантливые знакомые, уехавшие в США, станут и богаче, и востребованнее (пост про талантов 22-25 лет).
3️⃣ Качество жизни в Западной Европе безусловно выше, чем в США. Но это справедливее для тех, кто зарабатывает немного. А сеньор разработчики могут позволить себе околоевропейский уровень в США. И все равно останется больше денег от зарплаты!
4️⃣ "Europe is the new India for US companies" - отметили на реддите. Я этот тренд тоже вижу: европейский аутсорс становится популярнее. Выводы можете сделать сами 🥲
С венчуром в ЕС становится все грустнее (пост) --> отрыв US-зарплат будет еще больше --> еще больше аутсорса на США из Европы --> повышение конкуренции для ru-аутсорса --> из Сербии и Грузии фрилансить будет сложнее!(статья на хабре про локацию в профиле)
5️⃣ 🇦🇪 Дубай для разработчиков, в контексте накопления капитала, - это "США курильщика". Не сомневаюсь, что почти каждый разработчик в офисах Дубая согласится на оффер из Нью Йорка. И тут важное: окружение в Дубае не очень помогает погрузиться в нюансы западной корп. культуры. А значит условная Канада, Германия, Финляндия с более низкой з/п - стратегически разумнее.
6️⃣ Из всего списка только один европейский город с хорошим климатом - Барселона.
7️⃣ Вот прикольный сайт, где можно сравнить, сколько может накопить разработчик в разных городах мира: codecapitals.com. Поплачьте, неразработчики 🥲
8️⃣ Мой любый коммент:
Can confirm. Moved from EU to USA. Quadrupled my salary. All the issues Europeans think Americans have do not apply to high earners like engineers. Healthcare? My hospital stay cost me $250. Safety? My building has its own 24/7 security. Schools? Who cares— by the time my kids will be ready for college I’ll be sitting on at least $5M conservatively, $8M realistically. And they still have the option of dual citizenship and studying in Europe as a backup plan.
Yes EU>USA for anyone in lower to upper middle class but holy crap if you’re an engineer and you have the option MOVE. Quality of life is great for engineers here: shit delivered to your doorstep at all hours; private pools; private gyms; giant SUV; freaking boat; it’s just such a practical country to live in.
Мы опубликовали новую статью про нашу карту развития для web3 фронтендеров. В статье подробнее рассказываем, как устроена карта, как возникла идея ее создания и какие карты развития у нас еще есть))
Еще мы ведем свой телеграм-канал, где информация из мира разработки и web3 выходит оперативнее всего, переходите почитать авторские посты и мнение нашей команды, а также похоливарить в комментариях:)
Последние 3 года я обучаю английскому ребят из IT. За эти годы у меня скопилось куча материалов, а что самое главное лексики, которую я собирала с каждого мита, письма, переписки. Слова которые используют разработчики, аналитики, продакты, дизайнеры, QA. Используют не в "гугл переводчике", а в реальной ежедневной работе.
Я собрала большой ноушн файл. 100 фраз из лексики DevOps’ов. От простейших фраз, которые вы услышите в диалоге, до спец лексики.
Собрала и поняла: на месте того, кто учит, я бы точно сохранила и забила 😃 А потому ловите не только таблицу, но и все 100 фраз в Quizlet (ссылочка там же в доке ноушна) — так вы точно их выучите.
Надеюсь вам понравится такой формат, если да, сделаю больше таких наборов лексики для других специальностей.
Кто и как создаёт архитектуру программного обеспечения, какими навыками должен обладать такой специалист и каковы его карьерные перспективы? Чему учиться и как развиваться мидлам и синьорам, чтобы начать работать с архитектурой?
Мы в SSP SOFT расширяем предложение сервиса аутстаффинга, предлагая ИТ-персонал по модели занятости Workforce-as-a-service на новый рынок — для производственных компаний.
🙏 Этот пост просто информационный и большая просьба не минусовать без веского повода. Спасибо.
Подробнее по теме — статья на портале Control Engineering Россия, освещающая аутстаффинг ИТ-персонала на промышленных предприятиях. Эта модель управления кадрами, которая в последние годы используется в ИТ-компаниях, теперь расширяется на реальный сектор, также испытывающий сильную потребность в квалифицированных ИТ-кадрах.
А вот список наиболее востребованных ИТ-профессий для аутстаффинга на промышленные предприятиях:
DevOps-инженеры – автоматизация процессов разработки и внедрения, поддержка CI/CD-пайплайнов.
Инженеры AIOps – анализ и оптимизация ИТ-инфраструктуры с использованием искусственного интеллекта.
Разработчики программного обеспечения – создание и адаптация ПО для автоматизации производственных процессов и управления данными.
Системные аналитики – проектирование систем и обеспечение интеграции с корпоративными и производственными решениями.
Сетевые инженеры – настройка и поддержка сетевой инфраструктуры для безопасной и стабильной работы.
Нейротипичные люди обычно испытывают меньше сложностей с такими когнитивными функциями, как контроль импульсов, рабочая память, когнитивная гибкость, регуляция состояния и переносимость ожидания.
Однако для нейроразнообразных (расстройство аутистического спектра, синдром дефицита внимания и гиперактивности, дислексия или диспраксия) участников команды важно адаптировать рабочие процессы, чтобы снизить когнитивную нагрузку и повысить их вовлеченность. В работе дается несколько советов:
Делайте задачи максимально понятными. Разбивайте задачи на более мелкие и четко сформулированные этапы. Это улучшит понимание и повысит вероятность успешного выполнения.
Обозначайте рутинные задачи. Монотонная работа может быть особенно сложной для нейроразнообразных специалистов. Рекомендуется заранее выделять такие задачи и предлагать парное выполнение с коллегой, чтобы поддерживать продуктивность и мотивацию.
Сокращайте продолжительность встреч. Уменьшите время парного программирования, ежедневных стендапов и ретроспектив, чтобы избежать когнитивного истощения участников команды.
Самый простой способ свести человека с ума: Заставить его делать то, что он делает.
Программист. Учился в универе, работал три года. Хорошо программирует на PHP. Прилежно выучил все стандартные фреймворки, знает best practices, понимает как правильно деплоить проекты и докером, и композером. Знает как чистить репы, исправно ведёт коммиты, и пушит всё хорошо и вовремя. Получает зарплату, чуть выше средней, и рад жизни.
Давайте подойдём к этому программисту и скажем “РНР мёртв, мальчик! Тебе надо учить Раст!” И теперь, программист, который последние шесть лет учился программировать начинает думать “Хмм, возможно я не умею программировать”. О, нет, мальчик. Программировать-то ты как раз и умеешь. Ты в состоянии выполнять задания, следить за архитектурой и кодом, делать правильные коммиты и работать в команде. На каком языке ты это делаешь - я плевал с высокой колокольни.
Если бы мне платили по пять центов за каждый раз, когда я слышал о том, что PHP - мертв. Я слушал это в 2004 году, я слушаю это в 2024. Что не мешает некоторым людям деплоить Вордпрессы. (При том, что я не в восторге от PHP, но я отдаю себе отчёт в том, что в 2021 году 80% всех сайтов в интернете написаны на РНР)
Вам не надо учиться программировать, если вы это уже знаете. Вам нужно улучшать свои, и без того хорошие, знания, чтобы становиться ещё круче. Не ведитесь на завывания маркетологов о том, что вы не знаете вещи, которые вам уже известны. Это всё - маркетинговый бред, с целью продажи курсиков.
