На просторах сети, да и на dev.by, всегда много говорили об отборе сотрудников. Как не надо проводить собеседования, чем не довольны кандидаты, об унижениях на интервью. С этим столкнулся и я в своё время. Сейчас я помогаю принимать на работу новых сотрудников, и хочу поделится своей методикой.
Кто пишет: В этом разделе принято писать ни о том. Живу в такой-то долине, веду такой-то телеграмм канал. О себе проще. 20+ лет опыт непосредственно разработки, это всегда был embedded и различные *nix системы. Живу там, где тихо. Никаких каналов не веду. Тихо и спокойно занимаюсь парой открытых проектов помимо работы. Предпочитаю технику людям. Сейчас являюсь tech lead и senior architect. Активный участник коммьюнити dev.by, который пожелал сохранить анонимность.
Я не HR, я не менеджер. Я не люблю людей и общение. Но на технические части собеседований таскают меня. Потому здесь я постараюсь рассказать весь процесс поиска новых сотрудников: от отсева резюме до принятия решений.
Компания продуктовая. И software — только часть продукта. Порог вхождения очень высокий даже для людей с опытом. Ищем тех, кому интересна отрасль и кто готов стать самостоятельным членом команды, способным вести проект от начала до конца.
Очень разнообразное оборудование, с которым в области приходиться работать, и подход порой может меняться. Мы в команде работаем с C и С++. Это то, что называется true embedded.
Мы вполне охотно берём студентов, и только закончивших в том числе. Я лично в своё время взял на работу двоих. Очень талантливые и быстро учатся.
Какое резюме нам подойдет
Задача — отсеять неподходящих кандидатов ещё на этом этапе. Кстати, cover letter я никогда не читаю — оставьте это для HR. Но, совет молодым, — делайте направленное резюме (target resume). Так я увижу, что кандидату интересна область смежная с нашей работой
Несовместимые технологии (лучше не указывайте их в CV)
Это мнение моё, не претендует ни на что. Опыт из собственных ошибок, за которые потом пришлось отвечать.
- JavaScript и С\С++ — не совместимы.
Человек в итоге не будет знать ни то, ни другое, и постоянно путать подходы. А подходы JavaScript не работают от слова вообще. Многие компании даже делают трансляторы в C++ и потом компиляцию, просто потому что не могут найти специалистов.
- Опыт в web не совместим.
Человек понимает API как REST, и чтобы объяснить, что такое чистый TCP или UDP (не говоря уже о CAN bus), уйдёт слишком много времени. У них часто не укладывается в голове что такое raw data. Кругом json и REST. Просто трата времени. Если кандидат гипотетически попадет на проект с пользовательским интерфейсом — будут проблемы. Используя свой web подход и отдав им под самостоятельный контроль проект, мы получим крайне медлительную поделку, потребляющую кучу ресурсов. Мы занимаемся true embedded.
- Rust.
Практика показала, что пишущие на Rust — крайне токсичные люди. Постоянная беготня с нытьём, что надо срочно всё переписать на rust, иначе мы все умрём. Если вы не дружите с памятью вам, делать в отрасли нечего. И да, в true embedded ни в C ни в C++ проблем этих нет. Динамической памяти нет вообще. Хотя в C++ их вообще нет уже давно. Читайте стандарты.
Как представить свой опыт и проекты
Я не хочу читать про ваш опыт управления, я не хочу читать про DevOps, про базы данный и про то, какая у вас каша в голове. GitHub это не технология, это просто ресурс. Если мы говорим о контроле версий, то это git, не GitHub. VS code это не технология, это редактор текста, не умеющий ничего без плагинов кроме наверное подсветки синтаксиса.
Мне совершенно плевать, что вы знаете Microsoft Word. Вся эта мелочь говорит, что вы просто не знаете, что написать, и спамите своим резюме без разбора.
Потом эта каша будет расти. Информации в области много, использование неправильных терминов может порой остановить работу на целый день, пока разберешься. А через неделю снова?
Если вы указали какие-то проекты или работы в том же GitHub, ну, ребята, потрудитесь привести их хоть в кокой-то порядок. Я не поленюсь и зайду посмотреть. И часто видишь, когда даже в рамках одного файла разные стили.
Ну что можно сказать? Copy-paste проект? И время размещения за пару дней до отправки резюме?
Итого по резюме:
- Делайте target resume. Шансы возрастают.
- Не указывайте нерелевантные проекты, и несовместимые технологии. Нету релевантных — может это не ваше, не ваша отрасль, это нормально.
- Потратьте время, сделайте хоть один простой домашний проект. Всякие штуки вроде arduino пачками валяются.
Легко узнаю копипаст из Stack Overflow
Много пишется о том, как на технических интервью любят вгонять в стресс и дают задания прямо на собеседованиях. Но собеседование всегда само по себе стресс, а мне не нужны нервные люди. Поэтому я высылаю задания по почте, и даю столько времени, сколько кандидату понадобится.
Задания эти простые и легко находятся в Google. Мне интересно, как человек подойдёт к таким, казалось бы, совсем несложным задачам.
Встречались и такие, которые даже Google не использовали, чтобы их найти. Это, отчасти, моя цель — я знаю что их легко найти и решений куча. Начиная от стандартных и банальных, заканчивая высоко оптимизированными. Все их я знаю, могу без подсказки узнать copypaste прямо из Stack Overflow.
Как собеседует техлид
- Пока HR и менеджер задают общие вопросы, я просматриваю решение задач.
- Нормально чего-то не знать. Призываю быть честным и не выдумывать ответы. Иногда человек не зная начинает придумывать такую инопланетную ерунду, что собеседование превращается в «поставь диагноз этому расстройству». И с пеной из рта доказывают, что эта инопланетная технология существует.
- Я не гоняю по конструкциям языка, куче библиотек, API и т. д. Если человек понимает основы — это видно и достаточно. Остальное он найдёт.
- Не проверяю знания алгоритмов. Всё, что можно придумать, уже реализовали или как минимум можно найти. Нет смысла всё это заучивать — важно понимание.
- Если кандидат просто напутал что-то, но где-то рядом (не откровенная чушь) — это видно. В таких случаях я всегда даю правильный ответ. Так человек, мне кажется, чувствует себя спокойнее и уверенней.
- Если задание не просто copypaste, я подсказываю, какое решение будет лучше и/или проще. Кто знает, может кандидату пригодится у нас в команде, может где-то в другом месте. Пусть время собеседования будет пользой.
- Всегда спрашиваю, какой из языков программирования человек знает лучше, и начинаю с этого языка. Спрашиваю понимание основных конструкций. Только если вижу глубокое понимание, тогда начинаю спрашивать более детально.
- Задаю общие вопросы на разных уровнях: коммуникации, отладка, работа с памятью, многопоточность, сборка, операционные системы.
- Все вопросы начинаются от основ, нет основ — пропускаю тему. Углубляемся в детали если есть, что спрашивать.
Заключение
Просто пара тезисов, которые помогли бы успешно пройти собеседование у нас в компании.
- Target resume.
- Хоть какие-то релевантные проекты.
- Не поленитесь взять нужное вам время и подумать над простыми задачами. Не делайте copy-paste
- Не выдумывайте, будьте честны если чего-то не знаете.
Мнение автора может не совпадать с мнением редакции.
Вы потратили на этот материал две минуты. Потратьте ещё 15 секунд, пожалуйста.
dev.by, как и другим честным медиа, сегодня очень сложно: редакция работает за пределами страны, а наши рекламные доходы сократились в несколько раз.Но мы справляемся — с вашей помощью.
Это вы делитесь с нами инфоповодами, мнениями, опытом, временем и вниманием. А 170 читателей поддерживают нас донатами. В 2023 году мы хотим собрать 1000 читателей-подписчиков. Помочь нам можно через Patreon. Сейчас средний чек — около 10$, но мы рады любой сумме. В Беларуси Patreon заблокирован. Мы будем добавлять другие способы.
Спасибо, что прочитали это сообщение.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.
Tech lead с 20+ годами обычно в течение первых пяти минут разговора с кандидатом на позицию уже принимает решение подходит он ему или нет.
Важно не ЧТО кандидат говорит, а КАК он это говорит.
Вся остальная часть интервью для того чтобы обосновать своё решение. И показать это претенденту на позицию.
Именно так и есть. Ну ещё не мешает понять уже во время собеседования в какую часть команды лучше поставить этого человека, где ему будет проще влиться и больше пользы. Не тратить на это уже рабочее время а подготовить рабочее место.
Пользователь отредактировал комментарий 19 апреля 2023, 18:17
поскольку эта статья уже в вебе, и уже отображается с помощью джава скрипта, нужно срочно её переписать на Rust иначе у автора будут проблемы с памятью, а комментаторы так и вообще все умрут.
А после смерти нам напишут некролог из одного TCP пакета и отправят по ModbusTCP.
О чём и речь. Токсичность.
Ребята не выкупили твой сарказм)
заголовок статьи был прям кликбейтный своей кажущейся адекватностью
самое полезное это заключение :)
а по содержимому какое-то высокомерие сквозит - "плевать", "легко опознаю stackoverflow"
бро молодец, техлид с 20 годами, вопросов нет
но мб с софт скиллами есть сложности? с той самой токсичностью
хотя, если сейчас кризис, в компанию пытаются попасть вообще все подряд, то может быть и оправдано
Вырвано из контекста. Ответь самому себе честно на вопрос. Было такое что вот читаешь резюме и понимаешь, вот гениальный опыт, всем хорош, но вот нет у него microsoft word - всё, не беру. Серьёзно?
Вырвано из контекста. Это в ключе именно тех задач которые я рассылаю и которые хорошо известны и да, что такого что я их все решения в своё время протестировал вдоль и поперёк чтобы найти оптимальное для наших условий?
А с этим никто не спорит. Они есть. Но нужны ли они? Нужно ли что-то с этим делать? Ведь если внимательнее посмотреть то: "Предпочитаю технику людям" и никаким менеджером я становиться не собираюсь. Оставьте это для человеколюбов.
Подмена понятий. Если в общих чертах рассмотреть что такое токсин то это получится нечто что на протяжении длительного времени деструктивно влияет на систему. В случае разработки - антипродуктивно.
так это у вас же какая-то подмена понятий и противоречие самому же себе
то софт скиллы не нужны, то все вокруг токсики и нервные не нужны
или это позиция "мне софт-скиллы не нужны, я всех ненавижу, но вы должны быть милыми терпеливыми котиками и соответствовать моим представлениям о прекрасном"? я правильно понял? )
зачем нужны софт скиллы? ну, например, я с подобных интервью сам ухожу) за 20 лет опыта его более чем достаточно для большинства проектов, найду себе не хамящих клиентов и техлидов
но есть существенный нюанс - я свои 20 лет работаю на западных клиентов, а вот русскоговорящих избегаю. и вот именно западным клиентам чаще всего важны софт скиллы. ты можешь быть офигенным специалистом, но ты не нужен, если из-за тебя разбежится команда.
а вы, судя по манере общения, привыкли и освоились именно в постсовковой токсичной парадигме)
надеюсь, хоть не для военки пилите
Пользователь отредактировал комментарий 27 апреля 2023, 14:34
Совершенно НЕ правильно. Всё в одну кучу.
Тут может и у меня не правильное понимание что такое софт скилы. Мне просто не интересно. А может они у меня просто есть но я не думал об этом никогда, не думал потому что мне не интересно. Как говорится не задумывался потому что не было проблем. Но так как я не уверен что такое софт скилы до конца потому и изложу как это вижу.
Просто сразу ассоциация с надоедливостью экстровертов в противовес интровертам.
Я вполне спокойный и добрый человек. За всю карьеру у меня не было ни одного конфликта ни с одним из коллег, ни даже с плохим начальством. Но я для этого ничего не делал, просто был собой.
Правильно будет так:
Мне всё равно на то что обо мне думают окружающие (но это не значит что я хам или неопрятный человек), при этом я не нарушаю норм поведения в обществе. Мне просто всё равно. Окружающему так-же должно быть плевать что я о них думаю. Это моё мнение и оно может быть каким угодно, оно моё, вас это не касается и вы о моём мнении на свой счёт никогда не узнаете. Мне совершенно плевать на ваши софт скилы, я не дружбу пришёл строить в компанию а заниматься разработкой. Оставьте это себе, за вас скажет качество вашей работы. Мне всё равно какие у меня софт. Я не собираюсь быть менеджером, я не собираюсь быть team lead, tech lead меня вполне устраивает. Я собираюсь расти как специалист а не менеджер. Вы можете от меня месяцами ничего не слышать, ни слова, кроме доброе утро и хороших выходных. Но при этом работа будет сделана в срок и качественно. Общения в рамках e-mail и обсуждения в bag tracking системе для этого достаточно. Да, я не пойду ни на какие team building, не потому что я хамло неотёсанное, грубиян всех ненавидящий, нет. Мне просто не интересно. Я лучше книжку почитаю.
Вот ответь на вопросы самому себе. Что плохого если человеку не интересны люди? Если интереснее с книжкой или с техникой чем с людьми. Это делает его ненавидящим всех? Разве обязательно человек должен быть грубым и хамом? Практика показала что какраз наоборот такие люди намного вежливее и спокойнее. Или по твоему все вокруг должны сбиваться в кучу, друг друга лапать (как тут статья была про целый бизнес на обнимашках), делится ничего не значащими историями про котов, собак, детей, или не дай бог ныть как всё кругом плохо. Так чтоли?
Всё это как влияет на мои софт скилы? Да без разницы но что-то подсказывает что никак. Это называется интроверт до мозга костей.
И наоборот, часто черезмерное общение с людьми приводит к необратимому нарушению психики и стойкому желанию убивать.
Если вас волнуют вас волнуют все эти софт скилы, куча общения и людей, ну может вам дорога в team lead или даже в менеджера. И может из вас хороший получиться, кто знает. Лично мне это просто не интересно.
С каких таких? Я привёл пример интервью? Нет. Я обозначил ключевые моменты. Хочется увидеть протокол интервью? Можно об этом подумать, до тех пор "с таких" - голословно и означает только что вы уходите с с тех интервью которые сами себе нарисовали в голове. Хм.... т.е. бежите от самого себя? А вот то что уходите с тех интервью где не понравилось сразу - респект и уважение. И своё время не потратили и людям сэкономили. Это честно и правильно.
Где вы увидели про хамство в этой заметке? Можно цитату?
Здесь ты не выделился. Я тоже. Всю свою карьеру на западных.
Вот где вышло недопонимание. В ключевой момент КЛИЕНТАМ. И тут я полностью согласен. Западным КЛИЕНТАМ это очень важно. Но я не работаю с клиентами непосредственно. Ни с клиентами, ни с поддержкой.
Софт скил всегда в помощь, тут я не спорю. Но если мне не интересно с людьми и я не люблю общение это никак не влияет на мои софт скилы. А если и влияет то нет разницы. Я делаю работу за сценой, а на сцену пусть выходят те у кого лучше получается, я не обижусь если 90% моей работы человек присвоит себе. Кто реально делал commit будет видно в системе контроля версий. Нужно ли мне их улучшать? Ну может и нужно. Но для чего? Работать с клиентами? - не интересно. Стать менеджером - не интересно. Так что нужно наверное, но нет мотива. А вот расковырять что-то новое, протоколы, железо, где-то reverse engineering - вот интересно.
Именно так. Именно поэтому я писал про токсичность у Rust.
ох, текст длинный
не буду вникать и по пунктам отвечать с цитированием, сорри
если совсем кратко - да, у нас различия в терминологии. и разные точки зрения на одни и те же вещи - вероятно, потому что обычно оказывались в разных ситуациях. (и я даже догадываюсь, в каких именно и почему все обстоит именно так, но это слишком долго обсуждать, тем более письменно)
я могу ошибаться, все может быть совсем не так и т.д.
но позволю себе обратить внимание на некоторые вещи и на то, как они выглядят со стороны. (хотя на самом деле, повторюсь, все может быть не так)
софт-скиллы это, в каком-то смысле, умение находить компромиссы, идти навстречу и слышать - умение работать в команде. иногда сюда еще относят т.н. problem solver attitude - т.е. чтобы максимально самостоятельно решал проблему, а не просто код говнякал.
вероятно, определение не совсем точно, но это то, что представляю я. и я не раз встречал мнение о том, что хард-скиллы(умение кодить, новый язык или фреймворк) можно натаскать за пару месяцев, а вот с софт-скиллами сложнее, так не получится, хотя они не менее важны. при условии, что речь идет о работе в команде, конечно - одиночке-то все равно.
у вас ушло в какую-то другую крайность - обнимашки, треп о собачках, нытьё - вечный треск болтовни, которая мешает сосредоточиться. это не софт-скиллы, это, хз, какое-то другое мировоззрение. тоже имеет место быть, каждому своё.
я в целом тоже интроверт. но так сложилось, что прошлый год просидел дома с неизменным кругом общения довольно близких людей - ну человек мб 10. под конец года захотел куда-нибудь на офис, социализироваться. какие-то грубоватые мужские шутейки, подъ**ы - по большому счету, все те же самые small talks, но с подходящими людьми.
общение с людьми отличных взглядов помогает "не сбиваться с курса", лучше представлять, что вообще в мире происходит, да и полезно свои взгляды иногда проверять - вполне могут устареть и оказаться неактуальными.
заходы, как были поначалу, я часто замечал именно у тех, у кого с софт-скиллами все не слишком хорошо - об этом косвенно намекает категоричность утверждений, обороты типа того же "плевать", "не нравится - мне все равно". они обесценивают собеседника(или собеседников) и ставят на ступеньку ниже. какая может быть дискуссия после таких ответов? разве что поссориться
но, раз мнение высказал, значит, зачем-то это было надо? а зачем? ЧСВ пощекотать? или одобрения поискать? или накопилось раздражение от пребывания в некомфортной среде?
в целом, тему коммуникации и ее важности я могу разгонять долго, немало разных наблюдений и выводов накопилось. но надо меру знать, да и не слишком удобно здесь.
Пользователь отредактировал комментарий 01 мая 2023, 22:06
разгоняя тему софт скиллов и их важности - это еще и об отношениях с детьми и родителями. очень мало тех, кто может похвастаться взаимопониманием с родителями, но почти всем хотелось бы, чтобы родители их одобряли(обычно они остаются крайне значимыми фигурами всю жизнь). и с детьми(если они есть - должны быть, раз 20 лет в сфере) - не хочется повторить ошибок своих родителей.
т.е. даже отбросив рабочий коллектив, умение коммуницировать, слышать других, но при этом отстаивать свои интересы - важная часть жизни и комфорта в ней
Пожалуй во многом соглашусь. Очень похоже что моё понимание софт-скилов ушло куда-то не туда.
Имхо. Определение выглядит хорошо в теории, но есть один нюанс. На практике всё это реализуется как что-то вроде "умение делать вид, что слушаешь и согласен со скрам-мастером, умение в обязательном порядке придумать компромисс на то, что вбрасывает скрам-мастер".
Я вообще не знаю, как оно должно разрешаться. Вот автор говорит "не хочу, не буду, не считаю нужным разбираться в теме софт-скилов и что-то там повышать у себя на эту тему, не для этого я технарём становился". А скрам считает, что повышать нужно многое, и в обязательном порядке - вот список (убедительный для менеджмента) и вот даже реальные ситуации, к которым приводило отсутствие подобных скилов.
И вот что будем делать? Точки зрения очень противолежащие.
Теоретически наш технарь может подчитать книжек, как побеждать в дискуссиях, и на каждый пункт скрам-мастера выдвинуть уничтожающий контр-аргумент. В свободное от работы время. Скраму же за эту работу платят (не может же он написать в отчёте для каждого члена команды "просто пообщались, жалоб, замечаний и предложений нет").
Так как обычно никто этим не заморачивается, потому что свободной энергии и времени нету, - люди просто натягивают лицемерненькую улыбочку "спасибо за обратную связь" и начинают "работать" над софт-скилами.
(Я знаю, у вас всё не так, как я описал :) ).
Я бы лично выбросил эту риторику с софт-скилами и оставил бы просто токсичность - этого имхо достаточно. Дополнительное приводит технаря к дополнительному стрессу и работе после работы.
Но это я как бы сделал. А реалии такие, что инглиш лэнгуаге и сфот-скилы будут активно проталкиваться менеджменту как крайне важныекритерии отбора кандидатов - и всё будут активно работать на этим. Потому если не научишься "находить компромиссы" (ведь из же надо находить в обязательном порядке, не так ли?), то тебя просто не возьмут на многие работы.
"но мб с софт скиллами есть сложности?"
Если человек пришел на собес не воровать время, а реально приложил усилия и в какой-то степени соответствует требованиям, то независимо от того подойдет он или нет собес для него пройдет познавательно.
Никто его не будет гнобить за неточность или не правильный ответ, если нужно подскажут укажут на ошибки, направят в нужном направлении, поделятся опытом
Если же это кандидат с "фейк" резюме, копипастой в тестовом задании, набором названий технологий в голове в лучшем случае с понимаем на уровне туториала....
Ему просто будут заданы вопросы, без углубления в детали, он на них ответит неверно и всё
Где тут проблемы с софт скилами? Как по мне с софт скилами все очень даже ок.
А в чем причина ненависти к стековерфлоу? Если есть готовое решение, которое хорошо написано и хорошо работает, то зачем писать новое?
Пользователь отредактировал комментарий 22 апреля 2023, 08:23
Есть готовое решение - согласен. Хорошо написано - допустим, верно. Хорошо работает - как вы это проверите ?
Пользователь отредактировал комментарий 22 апреля 2023, 10:00
Сообщением ниже я ответил. Одно дело когда у тебя допустим ну даже 20 подобных операций, но их тысячи. copy-paste с заменой magic numbers приводят к ошибкам. Невнимательность приводит к ошибкам. Код не читается когда у тебя подобные операции тысячами. К счастью есть другой подход. Он описан в литературе очень скудно и как его реально применить не все видят. А работать именно с таким подходом надо. Поэтому и смотрю, владеет ли человек или просто будет копировать.
да, понятно. я пытался донести автору предыдущего комментария, что лучше разобраться самому , чем копировать то что кажется на первый взгляд вполне подходщим. как компромисс я допускаю использование опенсорсных решений. но, в этом случае надо быть очень избирательным.
Нет к нему ненависти. Просто люди часто копируют не задумываясь а первое попавшееся. Задача идёт в контексте области, и к сожалению эти стандартные решения просто не подходят. Оно работает и не плохо. Но эта операция настолько частая что нужен немного другой подход. Нужно сократить время и при этом улучшить читаемость кода. Таких операций очень много, год должен интуитивно читаться.
По сути это и смотрится. Захочет ли человек подумать за рамками стандартного решения из учебников или нет.
Я сталкивался с обратным, когда люди вместо того, чтобы использовать хорошее, уже написанное, начинали изобретать свой велосипед и проект катился куда-то не туда.
И такое есть. Но если уж так интересно то можем обсудить на конкретных примера. Может так будет понятнее что имелось в виду.
Что касается Rust - сама по себе задумка неплохая. Возникают новые языки, цель создания которых - устранить недостатки предыдущих. Иногда успешно, иногда нет. И это нормальный процесс. Даже Торвальдс одобрил добавление поддержки Rust в ядро. Проблема скорее в тех, кто считает его "серебряной пулей". Тут я полностью поддерживаю автора - если человек не понимает как это работает "под капотом", то ему какой язык не дай, он все равно накосячит.
Пользователь отредактировал комментарий 22 апреля 2023, 10:16
сектанты, они всегда появляются )
по моим наблюдения это обусловлено или личными проблемами, что не излечимо,
или недостатком опыта и кругозора, в процессе обретения опыта проходит
Статья на столько субъективна что практически бесполезна.
Если вы хотите работать в западной продуктовой компании то многое из того что автор советует вам не делать вам очень даже надо будет делать.
Автор вообще не учитывает интересы компании в статье. Просто хочет чтоб ему удобно было, а в идеале вообще чтоб его перестали "таскать на технические части интервью". Ему бы паяльник новенький и не трогать неделю, а не эти все люди, ведь автор "не любит людей и общение".
И такие вот дедовские ворчания "я не хочу" практически вся статья.
Не верьте автору, он потерпит ваши две строки про опыт управления, а менеджеру стоящему над ним ваш опыт может приглянуться.
Вы статью внимательно читали ?
То что советует автор не делать, не нужно именно для тех позиций, на которые он собеседует. Если вы претендуете на должность embedded developer, а у вас 10 лет опыта в devops, то не надо расписывать все ваши скилы в этой области.
Почему он не учитывает интересы компании по вашему мнению ? Он отсеивает нерелевантных кандидатов, чтобы меньше затрат было на переобучение новичков в его сфере.
Ваши домыслы про новый паяльник - это как раз таки ваша субъективная оценка статьи. То что он хочет чтобы его меньше дергали - это нормально для технического специалиста. Все что он хочет - это чтобы новые сотрудники как можно быстрее стали самостоятельными единицами и не бегал за ним с просьбами поправить слюнявчик и вытереть нос.
Потому что сегодня для компании скиллы на DevOps не релевантны, а завтра релевантны. Автор оценивает всего лишь один из аспектов кандидата, а рассказывает что ничего кроме этого аспекта кандидату писать не надо.
Все что вы полезное в профессии умеете то и пишите. Если техлид такая неженка что не может вычленить нужное ему из резюме - пусть HR выделяет "target resume" для каждого собеседующего. Техлиду одно, CTO другое, менеджменту третье.
Я автора не виню и уважаю, 20 лет опыта, true embedded и т.д. никаких вопросов. Вопрос только на кой ляд нужна статья уровня разговора на курилке:
-- я хотел бы читать target resume. А теперь о наболевшем... ненавижу сссска JavaScript, web, Rust, GitHub, VS Code, MS Word, stack overflow.
-- ну да...(тушит бычок), пошли дальше грести.
Пользователь отредактировал комментарий 23 апреля 2023, 19:24
Embedded мне кажется чаще либо продукт либо long-term аутсорс. И там девопс - всегда девопс, пока не уволиться, embedded - всегда такой, пока не уволиться. Человек оркестр чаще нужен аутстафу, вроде ТехАрт у которых больше коротких проектов и надо сотрудника продавать снова, а с узким направлением это сложнее.
Это именно продукт. И это техника.
Нет не релеванты. И не будут. Специфика продукта.
О чём было сказано в самых первых строчках.
Менеджеры себе менеджеров без меня найдут, тут я не нужен.
Пользователь отредактировал комментарий 24 апреля 2023, 17:33
Возможно, это лично мое впечатление, но мне показалось статья больше для кандидатов
Автор описывает свои советы кандидатам, как делать не стоит, чтобы не испортить о себе впечатление и на что стоит обратить внимание, чтобы лучше себя преподнести
Несовместимые технологии - это что-то новенькое. Можно пойти дальше и просто не брать никого, кто в школе имел по русскому и истории выше трех баллов - из этих гуманитариев ничего путного уже не выйдет
Это как-раз старо как мир. Примеры:
В устройство с крайне ограниченными ресурсами пихают mysql, apache, php, и java script просто для того чтобы передать 10 значений на клиентское приложение с пользовательским интерфейсом через REST попутно бернув всё это в json.
По шине с крайне ограниченной пропускной способностью (250000 а то меньше бывает) гоняют завёрнутые в json бинарные данные.
Делают trace бинарного трафика в виде 0xNN - на каждый байт тратят 4 байта. Потом гигабайт этого добра пытаются слить на localhost у чёрта на куличиках.
И делают это именно те люди о которых я говорил.
Я не говорил что их знания не нужны. Просто в моей области они будут мешать и тормозить тех кто умеет и хочет с этим работать.
Очередной заносчивый славяноид в вакууме. Любо дорого посмотреть.
Кто ясно мыслит — ясно излагает. И объяснить что такое ТСР для человека, который знает только REST не заставит 10 минут. Real world analogy как метод разъяснения экосистемы.
Точно так же на аналогиях можно объяснить человеку что такое SIMD на примере MapReduce о котором он может знать.
Как там твой zero cost VPN поживает, [censored - П. 4.1.2. Пользовательского соглашения — https://dev.by/pages/agreement]?
Ой ну вот с умничал так с умничал. Прямо любо дорого посмотреть. Выдумывание новых ругательств в адрес оппонента в надежде показать свою якобы умность, придать не имеющим веса высказыванием мнимую величину. Верный признак отклонения в развитии и острой нехватки йода.
Когда со своей колокольни ты знаешь и то и другое, тебе всё кажется простым. Но если опыт человека это дёрганье обёрнутых в функции на питончике или попаскрипте REST запросов - ну удачи. Объясняй. Ты жешь великий учитель не вайтишник.
Прикинь. Работает
А как там удой с баранов?
Ты туннелишься по ssh на халяву к мозолееду что ли идейному?
Потому что на zero cost vpn можно не только руки погреть но еще и показать какой талант тракторист потерял. Так то, я тоже могу корпоративный VPN превратить в личный и объявить что не это ничего не стоит, особенно если у меня хватит прав свои правила в iptables нарезать.
Тебе виднее, генацвале.
Кто тебе сказал такую чушь? Ваша осведомлённость просто поражает своей безрадностью. А ещё инженер. Мда, вот такие нынче пошли инженеры. Тяжело будет взрослеть.
Ну молодец что хоть так можешь. Возьми ещё пирожок корпоративный с полочки. Не плачь потом что за использовании ресурсов компании в личных целях тебя вытурили.
Даже так можешь????? Ну ты вааааащееее ПАЦАН теперь. Все девушки на селе теперь точно твои.
Вообще эти угадашки бегающие из темы в тему уже даже забавляют. Эко у тебя подгорает эта задачка с zero cost vpn. Всё никак не можешь разгадать.
Не напрягайся сильно, а то ещё взорвёшься, всё не сложно, правда. И это не какая-то супер технология. Постарайся подумать за рамками своего серого, грубого восприятия. Всё гораздо проще.
В мире много прекрасного и интересного, не будь таким злюком.
Ну и удачи в поисках. С нетерпением жду следующего гениального предположения как же это мне удалось 🤣
Пользователь отредактировал комментарий 27 апреля 2023, 21:33
Если вы не ищете джуна после 3 месячных онлайн курсов?
То на***а вам кандидат, которому нужно объяснять что такое ТСР/UDP сокеты? даже за 10 минут!
И тратить ещё 10 минут, чтобы втолковать разницу между git и github?
Если требования к вакансии выше, чем "ищем junior разработчка после курсов", то описанные выше вопросы вообще не должны возникать ))
Но к сожалению они появляются, даже с ребятами имеющими профильное образование ((( и это говорит о их низкой квалификации
Второй вопрос к тебе — credibility. Откуда нам всем тут знать, что ты на самом деле — тех лид. На Западе принято вести блоги от своего лица, тем самым подтверждается proved track record опыта в отрасли.
То что тут размещено:
а) кликбейт
б) достойно аудитории двача-харкача а не "профессионального" ресурса
Работал с "true embedded" парнями раньше в компании со стороны бизнеса. Даже кажется, что автор - бывший коллега ))
Специфика отрасли накладывает свои требования и это нормально.
По тексту - все по делу. Интересно другое, взяли бы вы на работу самого себя 20 лет назад с такими требованиями?! Или с тех времен не сильно что-то изменилось в embedded-найме?
А оно примерно так и было, примерно в таком ключе как я описал меня и собеседовали. Когда начинал работать уже на полную ставку, именно в подобном ключе и было собеседование. Хотя тут может сыграло что косвенном с менеджером был знаком. open source сообщество в РБ не очень огромное было. И так или иначе люди друг друга либо знали лично, либо по открытым проектам.
Комментарий скрыт за нарушение правил комментирования.
[censored - П. 4.1.2. Пользовательского соглашения — https://dev.by/pages/agreement]
Ну куда им до инженера ассенизатора.
Трахтер-с-прицепом-фикалий.jpg
Бросай пить. Пока весь йод не вымыл. Или что ты там принимаешь.
Пользователь отредактировал комментарий 27 апреля 2023, 20:42
Автор - токсичный дед
Т.е. опыт на расте нерелевантен, в отличии от проектов на ардуино?
Интересно куда заведут индустрию такие подходы
Я не гоняю по конструкциям языка.
Спрашиваю понимание основных конструкций [языка].
Мне показалось или подозрительно странная несогласованность изложения мыслей?
Пользователь отредактировал комментарий 18 июля 2023, 12:38