Comments 45
Андерс Борх, рассказывая о себе и своих методах, забыл добавить, что он всегда работал в паре - хороший интервьюер и плохой интервьюер.
в текущее время всем важнее байтодроч на собесах
-Секретный ингредиент моего секретного ингредиентного супа... не существует!!))) нет его)) никакого секретного ингредиента!!))
-Постой-постой, так мы готовим обычную лапшу,не добавляем ни специй,ни особенного соуса??
-Да не за чем, чтобы сделать что-то особенное, нужно поверить что это особенное!!!!
Так, давайте вы расскажете самое главное: кто это вообще и почему его стратегия проведения собеседований настолько важна?
Плюсую. А то ведь у меня тоже есть какая-то стратегия, идущая вразрез с принятой у технологических гигантов, и я могу о ней рассказать. И у оренбуржского разработчика Василия Помидорова есть. И у саратовского тимлида Николая Главнюкова.... Давайте срочно все выйдем и раскроем свои удивительные стратегии, а то ведь весь мир мучается в догадках и спать не может без этого знания...
Пока из интересного - только обманутые ожидания. Я-то думал, у него фамилия Борщ. А оказалось - просто банальный Борх, вот скукота-то....
Хозяин небольшой компании в Дании, которая судя по их сайту занимается аутсорсом. На датском аналоге САРК есть информация, что их валлвая прибыль за 2022 год 411 тысяч крон, то есть примерно 5.5 млн. рублей. Почему перевели именно его статью, это конечно большой вопрос.
То есть хозяин компании зарабатывает примерно столько же сколько программисты уровня senior+ в финтехах?Вау круто, надеюсь в следующей статье он раскроет секреты заработка
Ну в этом-то как раз ничего удивительного, я тоже зарабатываю сильно меньше разраба из финтеха или любого руководителя из корпорации. В собственной компании есть другие плюсы, если удалось правильно её "приготовить".
Другое дело, что хотелось бы услышать "раскрытие тайных знаний" не от какого-то среднестатистического хрена, а от человека, у которого действительно ПОЛУЧИЛОСЬ, вот прям с большой буквы. Так-то бизнесы открывают и держат на плаву много кто.
А почему Вы думаете что он не вытащил себе на зарплату , например, с 10 этих сумм из общей выручки? Хотя оставшаяся цифра конечно поражает своей незначительностью. Думаю что в Дании даже одного приличного разработчика на эту сумму год не прокормить..
Проблема почти всех таких статей в том, что они описывают очень абстрактные команды без анализа требований к сотрудникам и их результатам.
Где-то можно нанять примерно любого разработчика, и процесс разработки будет идти. Многие, даже очень большие проекты, в реальности очень просты. И там не нужны ни новые технологии (хотя разраб будет с большим удовольствием рассказывать про новейшие находки), ни правильное применение лучших практик (хотя эти же люди будут выступать на конференциях и рассказывать про нюансы проектирования). А где-то не подойдёт прикольный и дружелюбный чувак, там нужен человек, который реально понимает, как и что работает, и что он делает.
Я встречал одну из самых приятных и комфортных команд, где люди реально рассказывали о нюансах технологий, они умело рассуждали почти обо всем в ИТ, но этим не пользовались, и не умели пользоваться. И они годами делали систему, которую потом переписывали полгода, с истериками, конфликтами и взаимными обвинениями, так как она не подходила под формализованные требования заказчика по безопасности и стабильности.
Работаю в Европе, тут через одного такие Борхи. Поэтому тут кучами вьются разработчики из Индии и Пакистана с восхитительными резюме в которых мало правды, и с такими же рассказами о себе.
Да и вообще, извините, что это за хрен с горы, и чем он так знаменит, что мы должны слушать его советы?
В недавнем обзоре на Хабре об изменениях на рынке труда в IT https://habr.com/ru/companies/magnus-tech/articles/782022/ говорилось, что "Ложь — тенденция 2023 года. Раньше не было столько случаев обмана, и поэтому мы даже не проверяли, работал ли человек в указанной им компании. Теперь, видимо, пора снова просить рекомендации... "
Я могу вспомнить только один случай, когда проблема с кодом выявила плохого инженера-программиста, и я определённо мог бы сделать такую же оценку, просто поговорив с ним.
Ну уж нет, точно не мой опыт. Бывало такое что по резюме все очень хорошо, по разговору все базворды знает, думаешь ну просто песня, а не кандидат. Начинать какую-нибудь задачку разбирать ну и сразу все, отказ, слабо. Задачки прям базовые, никаких там реализуйте "merge sort" - кто его помнит этот merge sort. Мне иногда было очень неловко давать такую задачку, мол к пришёл такой умищще, а я у него 2*2 cпрашиваю. И какого же удивление когда видишь что по резюме и разговору я составил неправильное впечатления. Нет базовых навыков кодинга, я не думаю что надо дальше что-то смотреть.
Я вот не так давно, где-то с год, дорос до того, что меня стали звать на собеседования. До сих пор удивляюсь тому, что люди могут годами работать и не знать каких-то даже базовых конструкций языка.
Причём я даже не прошу людей писать код. На собеседовании все задачки или просто на чтение/запуск программы с последующим разбором вывода, или на самый обычный code review, где мы вместе смотрим на код, в котором есть 4 слоя ошибок: проблемы с проектированием, проблемы для новичков, проблемы для матёрых, и неожиданные UB для самых хардкорных.
Так вот на код ревью люди часто вообще не видят какие-то ну совсем базовые проблемы. Например в noexcept-функции на 3 строчки (!) я бросаю исключение. Но оказывается каждый второй "сеньор на бумаге" не знает, что такое noexcept в C++.
Ну а может человек выучил C++ в 1993 году, в 1995 стал в нем экспертом (когда там уже были templates, но ещё не было exceptions), а потом за стандартом не следил, потому что занялся чем-то другим? Этой мой случай. При этом я прекрасно знаю что люди типа вас (я сам такой) могут спросить про фичи C++ после версии стандарта 3.1, поэтому я C++ из своего резюме убрал. А есть люди, которые не убирают. У таких я всегда спрашиваю "на каком уровне вы знаете язык такой-то" прежде чем задать вопрос. И спрашиваю только на темы, в которых сам человек подтвердил словами, что это его актуальное знание. Правда попадаются такие, у которых все резюме - это суп из недознаний и недоумений...
При этом я прекрасно знаю что люди типа вас (я сам такой) могут спросить про фичи C++
Ну, логично, что принимая на работу человека, который должен писать и читать код на С++17, я должен убедиться, что они понимает синтаксис языка. Особенно если он заявляет, что он senior. У программиста синтаксис его основного языка должен быть на уровне разговорного.
Можно не знать каких-то паттернов, можно не знать библиотечных функций, можно не понимать тонкостей работы компилятора, можно даже слегка подзабыть как работает линковщик.
Но синтаксис языка, на котором разработчик планирует писать и читать код, т.е. по сути алфавит, разработчик на конкретном языке обязан знать. Можно забыть как что-то на языке написать (синтаксис С++ довольно обширен и бывает сложно вспомнить как правильно писать шаблонный код), но уж прочитать (а задачка-то по сути на чтение) очевидно надо суметь.
P.S.
Ну и да. Если человек был экспертом в С++ в 1995-м году, то сегодня он уже по сути не знает С++ и его знания где-то на уровне очень сообразительного джуна, потому как несмотря на весь опыт в разработке ПО (читай проектировании), выдать работающее решение без постоянного контроля со стороны он не способен (потому что не может написать хороший код).
выдать работающее решение без постоянного контроля со стороны он не способен
Вот тут не надо выдумывать. Сеньйор на то и сеньйор что гарантированно самостоятельно выдаст рабочее решение. Если он чего-то не знает на этом пути, то узнает, разберётся. Иначе это не сеньйор, и пусть он хоть весь C++ назубок знает, это просто малополезная ходячая энциклопедия.
Вот тут не надо выдумывать. Сеньйор на то и сеньйор что гарантированно самостоятельно выдаст рабочее решение
Каким образом и какого качество решение? Он загрузит в себя за пару месяцев что идет испытательный срок, все современные плюсы? Маловероятно. Скорее всего он очень долгое время будет выдавать код таким, каким его писали в 1995-м году, забив на все современные практики, рекомендованные в том же Core Guidelines.
Работать-то оно будет, вот только этот будет требовать немедленного рефакторинга + непонятно кто и как его будет поддерживать после него. Решив проблему он создаст две и будет продолжать это делать, пока не пройдёт через N итераций "опыта", обладать которым он уже обязан.
Иначе это не сеньйор, и пусть он хоть весь C++ назубок знает, это просто малополезная ходячая энциклопедия
Это правда, но это не отменяет того, что он должен и уметь грамотно код проектировать, и уметь хотя бы читать код на том языке, который мы используем. Я не просил ведь даже ни строчки написать на собесе, просто взглянуть на код и сказать где проблемы.
Он загрузит в себя за пару месяцев что идет испытательный срок, все современные плюсы?
Спору нет, если там такая пропасть, а работодатель не может ждать... Тут уж без обид. Но когда докапываются до хинта компилятору. Который не так уж часто используется, на самом деле. Который почитать-разобраться это дело нескольких минут. Адекватен ли такой работодатель?
Этот хинт компилятору может к чертям на проде вам весь софт уронить. Не такой уж он безобидный. Да и используется довольно часто. Как минимум move конструкторы принято делать noexcept (и не спроста).
Адекватен ли такой работодатель?
Да, адекватен. Адекватен ли человек, заявляющий, что он С++ программист, но неспособный в функции из трёх строчек увидеть очевидную ошибку?
Этот хинт компилятору может к чертям на проде вам весь софт уронить.
К чертям завалить может вообще что угодно. Самая мякота это UB. Но ничего, живём же как-то. Как я уже говорил, грамотный сеньйор протестирует все ветки исполнения. Ещё есть более общие юнит-тесты. Ещё есть статические анализаторы кода. Ещё есть, в конце концов, код-ревью. Где более прошаренные в разных ньюансах товарищи заметят косяк и объяснят так больше не делать. Мне кажется у вас в конторе попросту проблемы с культурой и организацией разработки. Которые вы пытаетесь компенсировать требованием энциклопедических знаний от каждого.
Да, адекватен. Адекватен ли человек, заявляющий, что он С++ программист, но неспособный в функции из трёх строчек увидеть очевидную ошибку?
Absolutely! C++ очень большой, и используется очень по-разному. Более того, проглядеть даже самую очевидную ошибку совершенно в порядке человеческой природы. Все эти "найди ошибку в коде" это тест на внимательность, а не на знание языка.
К чертям завалить может вообще что угодно. Самая мякота это UB. Но ничего, живём же как-то.
Не "как-то", а именно что зная о существовании всех этих "стрёмных" мест. И если С++ программист не знает этих мест, то он в общем-то и профнепригоден (для С++ разработки), потому что породит глючное гавно, а не программу.
Как я уже говорил, грамотный сеньйор протестирует все ветки исполнения.
Чушь петровна. Я в жизни не видел кода со 100% покрытием тестами. Даже код торговых ботов, которые ворочают миллиардами долларов, покрыт юнит-тестами в лучшем случае на 70-75%, а остальное дотестируется интеграционными тестами (но это долго и дорого, на каждый PR не запустишь).
В менее ответственных областях покрытие еще меньше. Единственный раз, когда я видел покрытие >90% - это код криптобиблиотеки, но это слишком маленькая кодовая база. В среднем случае code coverage болтается где-то в районе 40-60%.
Ещё есть, в конце концов, код-ревью. Где более прошаренные в разных ньюансах товарищи заметят косяк и объяснят так больше не делать.
Мы с вами уже сотый комментарий дискутируем на тему проведения кодревью и того, что кандидат на должность "Более прошаренный товарищ" (senior программист) с ним не справился :) Вы наконец-то передумали, и поддерживаете мою позицию?
Мне кажется у вас в конторе попросту проблемы с культурой и организацией разработки.
Мне кажется вы ни разу не проводили собеседование, но когда кажется, что делать и так понятно :)
Я за жизнь сменил 6 работ и могу сказать, что культура разработки у меня в компании вполне себе неплоха. Как всегда не без проблем, но лучше многих. И CI/CD у нас настроен, и статических анализаторов аж 3 штуки, и кодревью, и любые IDE и всякие ReSharper-ы можно, с style guide прибит clang-format-ом гвоздями.
требованием энциклопедических знаний от каждого.
Вы что-то сами себе придумали, и что-то сами себе доказываете. Вы вообще как будто бы о чём-то другом разговариваете. Перечитайте еще раз всю ветку и дайте мне хоть одну цитату, показывающую, что я требую энциклопедических знаний. Если для вас знание того, что такое noexcept и что он делает - это "энциклопедические знания", ну... вряд ли мы когда-нибудь поработаем вместе :)
Все эти "найди ошибку в коде" это тест на внимательность, а не на знание языка.
С++ - это минное поле из UB. Внимательность - это очень важно. Ну и как бы да, это тестовое кодревью. В реальном кодревью тоже внимательность нужна, иначе нафига его проводить? Я вообще работаю в сфере ИБ, у нас внимательность к коду нужна в квадрате и даже в кубе.
И если С++ программист не знает этих мест, то он в общем-то и профнепригоден (для С++ разработки), потому что породит глючное гавно, а не программу.
У человека допустим в анамнезе 5-10 лет работы над сложными проектами. Его код в проде и приносит прибыль бизнесу. Этот человек ТОЧНО породит "глючное гавно"? Или кто-то просто тешит своё самолюбие что он знает про noexcept, а этот кандидат пока нет?
Я в жизни не видел кода со 100% покрытием тестами.
Тесты тут не причём. Сразу под дебаггером эмулируются нужные условия чтобы выполнение пошло по нужной ветке. Не делать этого и пускать такой код в прод... Ну это финиш...
Мы с вами уже сотый комментарий дискутируем на тему проведения кодревью и того, что кандидат на должность "Более прошаренный товарищ"
Он и прошарен в чём-то, если у него 5-10 лет опыта на серьёзных проектах. Именно такой кандидат мне нужен. А не вторая копия меня.
Если для вас знание того, что такое noexcept и что он делает - это "энциклопедические знания", ну... вряд ли мы когда-нибудь поработаем вместе :)
Эти знания получаются в течении 5 минут. В чём их сакральная ценность?
Я вообще работаю в сфере ИБ, у нас внимательность к коду нужна в квадрате и даже в кубе.
При этом не удосуживаетесь хотя баз раз прогнать ветку кода?
Кстати я видел код на C++ размером порядка пары миллионов строк, в котором я вообще не заметил исключений (скорее всего их там нет) несмотря на то, что код написан уже в 21 веке в крутой компании. Это модель крупного аппаратного блока, против которого сравниваются результаты симуляции кода на SystemVerilog, языке описания аппаратуры (я пишу на SystemVerilog, то есть тот код на C++ я видел сбоку).
Если человек работал лет десять с такой code base, он вполне может быть синьор, просто его экспертиза может быть в других местах.
Есть много кода для рилтаймных прошивок по ужесточённому варианту мисры без исключений, динамического выделения памяти и прочих элементарных для сегодняшнего программиста вещей. Работал с таким кодом в машинном зрении автомобилей BMW и Volkswagen Group.
Кстати я видел код на C++ размером порядка пары миллионов строк, в котором я вообще не заметил исключений (скорее всего их там нет)
Ничего удивительного. Тот же Chromium собирается без них. В GCC/Clang даже флаг для этого есть, называется -fno-exceptions. И у нас есть драйвера на С++, которые собираются с этим флагом (а также еще десятком других).
Это вообще не является оправданием для того, чтобы не знать как исключения работают. Я даже более скажу, стандартом отключение исключений вообще не предусмотрено (т.к. в STL очень много на них завязано). Так что код с -fno-exceptions формально даже не является кодом на любом из стандартов С++.
Ну и человек, знающий за каким чёртом в С++ отключают исключения и какие проблемы это за собой несёт, определённо должен быть способен ответить что делает noexcept :)
Если человек работал лет десять с такой code base, он вполне может быть синьор, просто его экспертиза может быть в других местах.
В принципе, этого никто и не отрицал, но собеседование идет на вакансию С++ разработчика :) Очевидно экспертиза нужна в С++.
Я с вами согласен, что если человек пишет в резюме что у него основной язык C++ и идет на работу где основной язык C++, то он должен держать себя в форме относительно стандарта.
Ну и человек, знающий за каким чёртом в С++ отключают исключения и какие проблемы это за собой несёт, определённо должен быть способен ответить что делает
noexcept:)
И кстати, у меня как у человека который не держит себя в форме относительно стандарта C++ с 1995 года, любопытство: насколько я полагаю из общих соображений (я исключениями никогда не пользовался), обработка исключения должна требовать автоматический вызов деструкторов всех объектов, созданных на стеке, начиная от места где произошло throw и везде по пути цепочки вызовов функций наверх, вплоть до вызывающей функции, в которой находится try.
Это что-ли главная проблема - что эти деструкторы не вызываются? Или что-то другое? Типа вместо правильной обработки получается longjmp?
Исключения жрут много ресурсов. Симуляция требует высокой производительности. Складываем одно с другим и получаем, что не нужны исключения в конкретном случае
Но оказывается каждый второй "сеньор на бумаге" не знает, что такое noexcept в C++.
Потому что в реальности это всё это особо не используется. Можно конечно спорить что надо. Ну надо, пользуйтесь. И такой не знающий синьйор за 30 сек разберётся и начнёт использовать у вас в проекте, раз надо. В чём проблема, не понимаю?
Потому что в реальности это всё это особо не используется.
У нас вот используется и вполне активно. Ну и программист, не знающий noexcept, с вероятностью близкой к 100% понятия не имеет как писать код безопасный относительно исключений. А это тоже зачастую требуется.
Можно конечно спорить что надо.
Я конечно может чего-то не понимаю сейчас, но пропускать через ревью код, который гарантированно вызывает std::terminate - это вот 100% не то, что надо в вашей программе. И любой опытный С++ программист просто обязан это уметь замечать.
Ну и программист, не знающий noexcept, с вероятностью близкой к 100% понятия не имеет как писать код безопасный относительно исключений. А это тоже зачастую требуется.
Сегодня не знает, завтра поработает, разберётся, тоже будет знать. В свою очередь, он может развернуть стол на этом собесе и точно так же найти массу пробелов в ваших знаниях.
Я конечно может чего-то не понимаю сейчас, но пропускать через ревью код, который гарантированно вызывает
std::terminate
Тут вопрос к коммятищему этот код. Он его вообще запускал?
В свою очередь, он может развернуть стол на этом собесе и точно так же найти массу пробелов в ваших знаниях.
Конечно, всегда можно найти какой-то пробел, никто не может знать всё, но мы говорим о базовом синтаксисе языка, на котором этот разработчик собирается писать код. Это не какая-то малоизвестная "тонкость" или там закрученный ADL-трюк. Стал бы я брать на работу переводчика, если бы он не мог написать грамотно предложение используя simple tenses? Вряд ли.
Тут вопрос к коммятищему этот код. Он его вообще запускал?
Запускал. Он просто не попал в ту ветку кода, которая всё ломает. И вообще это вчерашний студент-джун, который только и делает, что косячит.
Да фиг с ним с джуном. Это собеседование :) Я даю рядовую задачу - провести код ревью. Тут нельзя отмазаться, мол задача нереалистичная и на работе не встречается. Или что это какое-то надрачивание на алгоритмы. Или задача требующая специфические бизнес знания. Это самая рядовая рутина, которой её придётся заниматься на регулярной основе. Я напрямую заинтересован, чтобы человек мог выполнять эту работу.
Конечно, всегда можно найти какой-то пробел, никто не может знать всё, но мы говорим о базовом синтаксисе языка, на котором этот разработчик собирается писать код.
Уж синтаксис вообще последнее дело спрашивать. Вы ещё порядок аргументов в пятом конструкторе std::string спросите.
Запускал. Он просто не попал в ту ветку кода, которая всё ломает.
Вот двойка ему за это. Все ветки должны быть протестированы. Не задача ревьювера брать на себя функции компилятора и отладчика своего и чужого кода. Он конечно может заметить хрень. А может и просто проглядеть.
Год назад искал джуна на 100к в месяц. Тестовое задание — по координатам двух отрезков определить, параллельны ли они. Сигнатура метода и тесты уже написаны, надо только заменить NotImplementedException на реализацию. Интернетом пользоваться можно.
Из шести пришедших на собеседование кандидатов трое не смогли за полчаса написать ни строчки кода.
Ну если б мне дали "координаты отрезка", я бы тоже затупил чо это ваще такое. гг.
Гуглить ведь никто не запрещал) Могу понять, если геометрией вы никогда не увлекались (как я), то за всё то время, прошедшее со школьной скамьи, реально можно тупо забыть как находить уравнение прямой по координатам двух точек, и можно забыть какой из коэффициентов отвечает за угол наклона этой прямой.
В принципе, это достаточно очевидные вещи, до которых можно додуматься и самостоятельно без гугла, просто "поигравшись" с цифрами. Но в любом случае, даже если не получилось самому придумать решение (стресс, затуп, вообще не знал как это делать), ответ будет ведь по первой ссылке в гугле.
координатам двух точек
Вы б точно не прошли собес :D
Согласен, что формулировка "координаты отрезка" некорректная, но вполне очевидно, что имелось ввиду координаты концов двух отрезков. Устраивать полемику в стиле "я не могу решить задачу из-за некорректной формулировки" - эт явно не будет плюсом в карму на собеседовании. А вот уточняющие вопросы по заданию всегда идут плюсиком в карму.
Хотя с учётом того, что код и тесты уже даны, все входы и выходы определены, можно бы и догадаться что имелось ввиду.
Сомневаюсь, что отметившиеся до сего момента комментаторы данной статьи устроились бы на работу в компанию Андерса Борха, пройдя у него интервью )
Разработчик из Дании Андерс Борх раскрыл свою стратегию по найму инженеров-программистов в команду