В июле и августе 2020 года я, с подачи Григория Петрова, проводил для компании Evrone технические интервью на позицию Senior Golang Backend developer. И, видимо, буду вынужден продолжать проводить, о чём ниже.
Задача формулировалась как «найти человека, который сможет задать и поддерживать высокий уровень профессионализма в применении языка Go». То есть, сформулирована она была по-человечески, перевод на канцелярит — мой. Под эту задачу я сформировал новый опросник вместо того, которым пользовался несколько лет — старый был с жестким закосом под DevOps. Методику, которой я пользуюсь для создания опросников и количественной оценки соответствия кандидатов, я излагал в своем докладе «Техническое интервью как инженерная задача» на конференции Saint TeamLead 2019.
И вот что я хочу сказать вам, коллеги: вы меня огорчаете.
Благодаря усилиям хэдхантеров Evrone Екатерины Тхоржевской и Анны Кудряшовой — спасибо им! — до меня добираются только резюме интересных кандидатов. Я их читаю и вижу вполне релевантный, а зачастую интересный профессиональный путь. Сложные и интересные проекты, ответственные должности. Слушая обязательный «Расскажите о себе» этап интервью, я вижу упорную и плодотворную работу. Прям бери и нанимай!
Но когда дело доходит до технической части и опросника, перспективы найма начинают выглядеть уже не так радужно. Кисло они начинают выглядеть, честно говоря! Смотрите: средний балл по опроснику — 3.3 по шкале 0-9. 3.3, Карл! 3.3 — это, с моей точки зрения, уровень junior. Middle должен набирать, я считаю, 5+. Senior — 8+.
Почему так? Почему опытные, квалифицированные разработчики набирают такой низкий балл? У меня есть, конечно, предположение, и я им поделюсь в конце статьи. А пока вернемся к тому, о чем я хочу с вами поговорить — к моему огорчению. Эта статья имеет своей целью ни много ни мало, — исправить ситуацию. Я хочу пройтись по своему опроснику и рассказать, какие именно неправильные ответы мне приходится выслушивать, а после этого задать вам наводящие вопросы, поиск ответов на которые поможет вам в следующий раз получить на моем интервью 9.
Нет, я не дам вам правильных ответов. Во-первых, потому, что правильных ответов на большинство этих вопросов не существует. Во-вторых, цель моего интервью — оценить глубину системы знаний кандидата, а не его умение выдать ответы, которые понравятся интервьюеру. И я уверен — знания, полученные в процессе поиска ответов на наводящие вопросы, позволят вам продвинуться, как профессионалам и гоферам. Иначе я не стал бы писать эту статью, пережил бы свое огорчение тихо в уголке.
Итак, опросник:
1. Go — императивный или декларативный? А в чем разница?
2. Что такое type switch?
3. Как сообщить компилятору, что наш тип реализует интерфейс?
4. Как работает append?
5. Какое у slice zero value? Какие операции над ним возможны?
6. Как устроен тип map?
7. Каков порядок перебора map?
8. Что будет, если читать из закрытого канала?
9. Что будет, если писать в закрытый канал?
10. Как вы отсортируете массив структур по алфавиту по полю Name?
11. Что такое сериализация? Зачем она нужна?
12. Сколько времени в минутах займет у вас написание процедуры обращения односвязного списка?
13. Где следует поместить описание интерфейса: в пакете с реализацией или в пакете, где этот интерфейс используется? Почему?
14. Предположим, ваша функция должна возвращать детализированные Recoverable и Fatal ошибки. Как это реализовано в пакете net? Как это надо делать в современном Go?
15. Главный недостаток стандартного логгера?
16. Есть ли для Go хороший orm? Ответ обоснуйте.
17. Какой у вас любимый линтер?
18. Можно ли использовать один и тот же буфер []byte в нескольких горутинах?
19. Какие типы мьютексов предоставляет stdlib?
20. Что такое lock-free структуры данных, и есть ли в Go такие?
21. Способы поиска проблем производительности на проде?
22. Стандартный набор метрик prometheus в Go -программе?
23. Как встроить стандартный профайлер в свое приложение?
24. Overhead от стандартного профайлера?
25. Почему встраивание — не наследование?
26. Какие средства обобщенного программирования есть в Go?
27. Какие технологические преимущества языка Go вы можете назвать?
28. Какие технологические недостатки языка Go вы можете назвать?
Всего 28 вопросов, но сколько боли и недоумения они мне принесли! Но и не задавать их я не могу — это моя работа. Эта статья — попытка исправить ситуацию. Возможно, она поможет вам лучше подготовиться следующему собеседованию. Не обязательно по моему опроснику — так или иначе поднятые здесь темы будут затронуты на любом техническом интервью. Спасибо за внимание
Напоследок — обещанное предположение о том, как и почему сложилась эта печальная ситуация. Наша индустрия, как бы мы это ни оценивали, уже давно живет по закону «fail early, fail often, but always fail forward». Для нас это означает, что мы должны делать свою работу как можно… хуже! Мы должны потратить как можно меньше сил, средств и времени, — особенно времени! — на предложенную задачу, ибо никто не знает, имеет ли текущая задача практический смысл. Собственно, большую часть задач мы решаем в режиме разведки, проверяя чужие смелые бизнес-гипотезы.
В результате лучшие кадры приучаются делать только то, что им поручено, ничего, кроме того, что им поручено, и необходимый минимум того, что им поручено. И этот подход, я предполагаю, незаметно и неосознанно эти кадры распространяют и на свое обучение. Разработчик изучает только то, что ему нужно по текущей задаче: ничего, кроме этого, и ограничивается минимально возможным набором знаний.
Моё скромное мнение — так нельзя! Образование — это игра в долгую, и подходить к нему надо с другими критериями, нежели к очередному «Проверим идейку MVP».
Задача формулировалась как «найти человека, который сможет задать и поддерживать высокий уровень профессионализма в применении языка Go». То есть, сформулирована она была по-человечески, перевод на канцелярит — мой. Под эту задачу я сформировал новый опросник вместо того, которым пользовался несколько лет — старый был с жестким закосом под DevOps. Методику, которой я пользуюсь для создания опросников и количественной оценки соответствия кандидатов, я излагал в своем докладе «Техническое интервью как инженерная задача» на конференции Saint TeamLead 2019.
И вот что я хочу сказать вам, коллеги: вы меня огорчаете.
Благодаря усилиям хэдхантеров Evrone Екатерины Тхоржевской и Анны Кудряшовой — спасибо им! — до меня добираются только резюме интересных кандидатов. Я их читаю и вижу вполне релевантный, а зачастую интересный профессиональный путь. Сложные и интересные проекты, ответственные должности. Слушая обязательный «Расскажите о себе» этап интервью, я вижу упорную и плодотворную работу. Прям бери и нанимай!
Но когда дело доходит до технической части и опросника, перспективы найма начинают выглядеть уже не так радужно. Кисло они начинают выглядеть, честно говоря! Смотрите: средний балл по опроснику — 3.3 по шкале 0-9. 3.3, Карл! 3.3 — это, с моей точки зрения, уровень junior. Middle должен набирать, я считаю, 5+. Senior — 8+.
Почему так? Почему опытные, квалифицированные разработчики набирают такой низкий балл? У меня есть, конечно, предположение, и я им поделюсь в конце статьи. А пока вернемся к тому, о чем я хочу с вами поговорить — к моему огорчению. Эта статья имеет своей целью ни много ни мало, — исправить ситуацию. Я хочу пройтись по своему опроснику и рассказать, какие именно неправильные ответы мне приходится выслушивать, а после этого задать вам наводящие вопросы, поиск ответов на которые поможет вам в следующий раз получить на моем интервью 9.
Нет, я не дам вам правильных ответов. Во-первых, потому, что правильных ответов на большинство этих вопросов не существует. Во-вторых, цель моего интервью — оценить глубину системы знаний кандидата, а не его умение выдать ответы, которые понравятся интервьюеру. И я уверен — знания, полученные в процессе поиска ответов на наводящие вопросы, позволят вам продвинуться, как профессионалам и гоферам. Иначе я не стал бы писать эту статью, пережил бы свое огорчение тихо в уголке.
Итак, опросник:
1. Go — императивный или декларативный? А в чем разница?
- Что я хочу оценить: знакомство с разными подходами к реализации бизнес-логики.
- Самый популярный неправильный ответ: «Я не силен в теории». Очень жаль, что ты не силен в этой теории, %USERNAME%. Если бы ты был в ней силен, ты бы знал, почему некоторые вещи на Go получаются очень легко и хорошо, а некоторые надо прям вымучивать.
- Наводящие вопросы: SQL — императивный или декларативный? А Dockerfile? А файл настройки github actions?
2. Что такое type switch?
- Что я хочу оценить: знакомство с нашим (скудным) инструментарием работы с системой типов в runtime.
- Самый популярный неправильный ответ: «Я не знаю». Очень странно — информация о type switch есть даже в Go tour.
- Наводящие вопросы: как реализовать в Go тип-сумму, который может содержать в себе значения int64|float64|complex? Как реализовать для такого типа метод Add(int64)?
3. Как сообщить компилятору, что наш тип реализует интерфейс?
- Что я хочу оценить: хорошо ли кандидат понимает, на чем основана концепция интерфейсов в Go.
- Самый популярный неправильный ответ: «Я не знаю». Справедливости ради, именно этот вопрос редко вызывает затруднения. А когда вызывает, сам кандидат весьма этим удивлен: «Я же миллион интерфейсов написал. Как компилятор понимает, что именно я реализовал?...» Ну — он умный, компилятор. И внимательный.
- Наводящие вопросы: что такое duck typing? К чему он применяется в Go?
4. Как работает append?
- Что я хочу оценить: знаком ли кандидат с базовыми концепциями управления памятью в Go. Самыми базовыми.
- Самый популярный неправильный ответ: «Он увеличивает capacity». Если продолжать настойчиво спрашивать: «Как он это делает?», — кандидат довольно быстро приходит к правильному ответу. Видимо, эти подробности настолько шокирующие, что забыть их трудно.
- Наводящие вопросы: как бы вы реализовали разреженный массив в Go? А без использования map?
5. Какое у slice zero value? Какие операции над ним возможны?
- Что я хочу оценить: помнит ли кандидат, что вообще можно делать со слайсом, и как ведут себя операции на граничных значениях. Почему это важно? «Почему это важно?» — был бы отличный вопрос для интервью, если бы я придумал, как его корректно задавать.
- Самый популярный неправильный ответ: «Можно делать len ()… и cap ()… наверное…» Операций со слайсами существенно меньше 10. И мы все — 100% — применяем их в своей повседневной работе. Надо просто пересчитать их в уме...
- Наводящие вопросы: каков будет результат append([]string(nil), "")? А append([]string(nil), []string(nil)...)? А почему? А range append([]string(nil), []string(nil)...) как отработает?
6. Как устроен тип map?
- Что я хочу оценить: насколько интересно кандидату, как именно ложатся в память наши байтики. Map, возможно, самая важная из стандартных структур данных, и весьма замысловато устроенная. Она сложная, она эффективная, она обладает встроенным race condition детектором… Неужели не любопытно?!
- Самый популярный неправильный ответ: «Это хеш-таблица». Да, это хеш-таблица. Как устроена хеш-таблица?
- Наводящие вопросы: какая hash-функция используется в map в Go? Что такое bucket?
7. Каков порядок перебора map?
- Что я хочу оценить: понимает ли кандидат, как отражается устройство структуры данных на ее свойствах. Ну или — читал ли кандидат документацию на базовые типы и запомнил ли неочевидно-важное из нее…
- Самый популярный неправильный ответ: «В порядке вставки». Хеш-таблица, которая сортирует элементы в порядке вставки, ага. А как в ней происходит выборка по ключу в таком случае?
- Наводящие вопросы: как получить одно случайное значение из map?
8. Что будет, если читать из закрытого канала?
- Что я хочу оценить: читал ли кандидат документацию или сразу бросился кодить. Если читал — запомнил ли очевидно-важное.
- Самый популярный неправильный ответ: «Вернется ошибка». Ну да, ну да… Вы помните синтаксис чтения из канала? Интересно, что синтаксис помнят почти все, но вопрос: «И как вернется ошибка?», — зачастую вводит кандидата в ступор.
- Наводящие вопросы: сколько значений возвращает одно чтение из канала? А почему range-чтение из канала возвращает одно?
9. Что будет, если писать в закрытый канал?
- Что я хочу оценить: читал ли кандидат документацию или сразу бросился кодить. Если читал — запомнил ли очевидно-важное.
- Самый популярный неправильный ответ: «Вернется ошибка». Да, вернется. Как она это сделает?
- Наводящие вопросы: можно ли закрывать канал со стороны читателя? А если очень надо — как быть?
10. Как вы отсортируете массив структур по алфавиту по полю Name?
- Что я хочу оценить: насколько кандидат склонен к написанию «велосипедов».
- Самый популярный неправильный ответ: «Методом пузырька». Пузырек — прекрасный алгоритм, но есть сегодня и поэффективнее. Например — quicksort. Не можете с ходу имплементировать quicksort? Так ведь и не надо!
- Наводящие вопросы: какой стандартный пакет предназначен для сортировки любых слайсов? И заодно — как сделать из массива слайс? Отсортируется ли массив при сортировке слайса?
11. Что такое сериализация? Зачем она нужна?
- Что я хочу оценить: глубину осознания связи простых повседневно используемых приемов с глобальными задачами разработки.
- Самый популярный неправильный ответ: «Для превращения бинарных данных в текстовые». Строго говоря, не всегда этот процесс можно считать сериализацией, и уж точно это не единственное её применение.
- Наводящие вопросы: почему нельзя для сериализации какой-либо переменной просто взять дамп занимаемой ею памяти?
12. Сколько времени в минутах займет у вас написание процедуры обращения односвязного списка?
- Что я хочу оценить: помнит ли кандидат институтский курс информатики. А если серьезно — это золотой вопрос программистского собеседования. Если бы мне позволили, я бы задавал его первым, и 70% интервью можно было бы на этом месте заканчивать. Один мой друг, который работает в JetBrains, так и поступает, кстати. Так вот, связанный список — это один из базовых элементов computer science, и один раз узнав, как он устроен, забыть это невозможно. Если «программист» не может развернуть односвязанный список, это свидетельствует о серьёзных пробелах в базовых знаниях. И это повод насторожиться — а что еще из базового он пропустил?.
- Самый популярный неправильный ответ: «А что такое односвязанный список?». Это такая структура данных...
- Наводящие вопросы: какие тесты вы бы написали для своей процедуры разворачивания односвязного списка?
13. Где следует поместить описание интерфейса: в пакете с реализацией или в пакете, где этот интерфейс используется? Почему?
- Что я хочу оценить: степень готовности кандидата использовать средства реализации модульной архитектуры, предлагаемые Go.
- Самый популярный неправильный ответ: «Рядом с реализацией». Вариантов 2, и кандидаты выбирают, похоже, наугад. На вопрос: «Почему?» — ответить затрудняются.
- Наводящие вопросы: что такое tight coupling? Почему это плохо? В каком варианте связанность слабее?
14. Предположим, ваша функция должна возвращать детализированные Recoverable и Fatal ошибки. Как это реализовано в пакете net? Как это надо делать в современном Go?
- Что я хочу оценить: насколько глубоко кандидат осмыслил эту непростую тему — обработку ошибок в Go.
- Самый популярный неправильный ответ: «Я не знаю». Обработка ошибок в Go одновременно и проста, и сложна. Проста потому, что в крайней степени тупа. Сложна потому, что — до недавнего времени, — любая дифференцированная обработка ошибок не была стандартизована, и каждый справлялся, как мог. Ситуация изменилась, и знать об этом — прямая обязанность ответственного разработчика.
- Наводящие вопросы: что нового и важного в плане обработки ошибок появилось в Go 1.13? А чего не появилось, хоть мы и ждали?
15. Главный недостаток стандартного логгера?
- Что я хочу оценить: критерии выбора кандидатом 3-party зависимостей для проекта. Логгер — просто самый одиозный случай, когда стандартная библиотека не предоставляет нам необходимой функциональности.
- Самый популярный неправильный ответ: «Я не пользуюсь стандартным логгером». И никто не пользуется, сюрприз! Но почему?
- Наводящие вопросы: каково основное применение информации из логов?
16. Есть ли для Go хороший orm? Ответ обоснуйте.
- Что я хочу оценить: количество и качество усилий, которые кандидат приложил к выбору инструментов, ускоряющих и облегчающих повседневную деятельность.
- Самый популярный неправильный ответ: «Gorm, вроде, неплох». Конкурирует с ответом «Я всё пишу руками». Я даже согласен с обоими ответами, но давайте обсудим подробнее — как устроен gorm, и почему вдруг руками.
- Наводящие вопросы: что означает буква M в аббревиатуре ORM? Что на эту букву M есть в gorm? А что такое DAL и зачем он нужен?
17. Какой у вас любимый линтер?
- Что я хочу оценить: уровень знакомства с современными практиками поддержки разработки.
- Самый популярный неправильный ответ: «Встроенный в Goland». Come on!, там нет линтера, там — тривиальный syntax checker!
- Наводящие вопросы: какое отношение линтеры имеют к CI? Зачем нужен CI в процессе разработки?
18. Можно ли использовать один и тот же буфер []byte в нескольких горутинах?
- Что я хочу оценить: понимает ли кандидат принципы, по которым мы выбираем использовать общую структуру данных или локальную для горутин.
- Самый популярный неправильный ответ: «Можно, если защитить его мьютексом». Я признаю, это плохой вопрос, недостаточно показательный. Но зачем же давать на него хоть и формально правильный, но бесполезный ответ? К сожалению, в рабочей обстановке нам тоже прилетают плохие задачи, но надо уметь адекватно на них реагировать. Адекватно — это не «Что за чушь?!», а «Сформулируйте, пожалуйста, цель», кстати.
- Наводящие вопросы: а зачем и правда может понадобиться использовать один и тот же буфер []byte в нескольких горутинах параллельно? Что именно мы будем в нем защищать мьютексом?
19. Какие типы мьютексов предоставляет stdlib?
- Что я хочу оценить: насколько глубоко кандидат разобрался в теме конкурентного доступа к данным. Да, по второму разу, но это ключевая тема. На этот раз я захожу со стороны практики.
- Самый популярный неправильный ответ: «Не помню». На самом деле, это ответ: «Не считаю это важным». Ну и зря!
- Наводящие вопросы: что именно и от чего защищает мьютекс?
20. Что такое lock-free структуры данных, и есть ли в Go такие?
- Что я хочу оценить: насколько глубоко кандидат разобрался в теме конкурентного доступа к данным.
- Самый популярный неправильный ответ: «Нет».
- Наводящие вопросы: что такое atomic? А что такое sync.Map? Sync.Map — lockfree или нет?
21. Способы поиска проблем производительности на проде?
- Что я хочу оценить: степень знакомства с этой малоприятной, но постоянно возникающей задачей.
- Самый популярный неправильный ответ: «Пишу в логи». Коллеги, да такие логи сами по себе создают проблемы производительности!
- Наводящие вопросы: какие проблемы производительности вы знаете? Может ли быть так, что потребление ресурсов (CPU, RAM, disk/net bandwidth) вполне умеренное, а пользователи жалуются на «тормоза»? А на что, собственно, жалуются пользователи, и как это связано с тем, что вы видите в системе?
22. Стандартный набор метрик prometheus в Go -программе?
- Что я хочу оценить: степень готовности использовать лучшие практики современной разработки. И дело тут не столько в самом прометее, сколько в готовности следовать за тенденциями в индустрии. Это, как ни странно, важно — сохранять тесную связь с мейнстримом.
- Самый популярный неправильный ответ: «Я не пользуюсь прометеем». А пора бы, уже несколько лет как пора!
- Наводящие вопросы: оставив прометей в стороне — что вообще Go-программа способна о себе рассказать? Метрики runtime — что это, и откуда берется?
23. Как встроить стандартный профайлер в свое приложение?
- Что я хочу оценить: на каком уровне кандидату приходилось решать проблемы недостаточной производительности.
- Самый популярный неправильный ответ: «Я не пользуюсь профайлером». Два варианта: или вы никогда не сталкивались с проблемами производительности, или вы по неизвестным причинам игнорируете одно из самых мощных средств борьбы с такими проблемами. И то, и другое снижает вашу ценность как кандидата, и второе сильнее первого.
- Наводящие вопросы: а он нужен, профайлер? Что там есть вообще полезного? И почему его надо встраивать, а не запускать из-под него приложение?
24. Overhead от стандартного профайлера?
- Что я хочу оценить: тупо — читал ли кандидат документацию. И, если читал, — что понял?
- Самый популярный неправильный ответ: «Ну, заметный».
- Наводящие вопросы: что такое «семплирующий профайлер» и почему это хорошо?
25. Почему встраивание — не наследование?
- Что я хочу оценить: общее знакомство с ООП-парадигмой и границами ее применения в Go.
- Самый популярный неправильный ответ: «Наследование позволяет переопределять методы». Но, коллеги, встраивание — тоже, тоже!
- Наводящие вопросы: Что означает буква L в аббревиатуре SOLID?
26. Какие средства обобщенного программирования есть в Go?
- Что я хочу оценить: знакомство с основными парадигмами современного программирования и границами их применимости в Go.
- Самый популярный неправильный ответ: «Интерфейсы». Коллеги, интерфейсы ничего не обобщают (внезапно). Однако программисты, пришедшие в Go с других языков, имеющих развитые средства обобщенного программирования, сильно тоскуют по ним и пытаются эмулировать эти самые средства с помощью интерфейсов. Создают при этом, простите за правду, кошмарных уродцев.
- Наводящие вопросы: что такое map-reduce? Как его реализовать в Go? А без interface{}? А что такое кодогенерация и как ее можно использовать в этой задаче?
27. Какие технологические преимущества языка Go вы можете назвать?
- Что я хочу оценить: глубину осознания кандидатом места языка Go в современной разработке. Для каких задач Go подходит идеально? Для каких не очень, но будет полезен? Преимущества существуют не сами по себе, а только в контексте задачи!
- Самый популярный неправильный ответ: «Читабельность». Коллеги, читабельность — субъективная категория, она не может быть технологическим преимуществом. Это раз. Два — читабельность Go довольно относительна. Килотонны boilerplate обработки ошибок и ручной раскрутки стека читабельность ни в коем разе не увеличивают!
- Наводящие вопросы: чем отличается goroutine от OS thread? Как устроен сетевой ввод-вывод в Go?
28. Какие технологические недостатки языка Go вы можете назвать?
- Что я хочу оценить: глубину осознания кандидатом места языка Go в современной разработке. Для каких задач Go совершенно не подходит?
- Самый популярный неправильный ответ: «Отсутствие generic types». Я пробовал спрашивать на этом месте: «Для каких ваших текущих задач были бы полезны генерики?», — и ни разу не услышал ничего внятного. И не услышу — генерики критически важны для функциональных языков, а Go… Об этом ниже.
- Наводящие вопросы: их миллион, но я задам один. Как превратить []io.ReadWriter в []io.Reader?
Всего 28 вопросов, но сколько боли и недоумения они мне принесли! Но и не задавать их я не могу — это моя работа. Эта статья — попытка исправить ситуацию. Возможно, она поможет вам лучше подготовиться следующему собеседованию. Не обязательно по моему опроснику — так или иначе поднятые здесь темы будут затронуты на любом техническом интервью. Спасибо за внимание
Напоследок — обещанное предположение о том, как и почему сложилась эта печальная ситуация. Наша индустрия, как бы мы это ни оценивали, уже давно живет по закону «fail early, fail often, but always fail forward». Для нас это означает, что мы должны делать свою работу как можно… хуже! Мы должны потратить как можно меньше сил, средств и времени, — особенно времени! — на предложенную задачу, ибо никто не знает, имеет ли текущая задача практический смысл. Собственно, большую часть задач мы решаем в режиме разведки, проверяя чужие смелые бизнес-гипотезы.
В результате лучшие кадры приучаются делать только то, что им поручено, ничего, кроме того, что им поручено, и необходимый минимум того, что им поручено. И этот подход, я предполагаю, незаметно и неосознанно эти кадры распространяют и на свое обучение. Разработчик изучает только то, что ему нужно по текущей задаче: ничего, кроме этого, и ограничивается минимально возможным набором знаний.
Моё скромное мнение — так нельзя! Образование — это игра в долгую, и подходить к нему надо с другими критериями, нежели к очередному «Проверим идейку MVP».
Конференция Golang Live 2020 пройдёт онлайн 14–17 октября. И в этом есть свои плюсы: нам не придётся вводить ограничения на количество гостей, и участником сможет стать каждый желающий. Забронировать билеты можно на все дни конференции, а благодаря генеральному партнеру — компании Юла, — первый день открыт для всех желающих. Смотрите расписание здесь.
Программа конференции раскроет главную тему — «Продуктовая разработка на Gо». Так вы сможете увидеть цельную картину и понять, как Gо работает на реальных (часто высоконагруженных) проектах. А тестирование в случае Go становится ещё интереснее. Сложную бизнес-логику, как правило, нам приходится реализовывать нетривиальным способом, поэтому и писать интеграционные тесты для неё сложно. Что с этим можно сделать и нужно ли все обкладывать интерфейсами и моками, мы и поговорим при встрече.
Пообщаться, задать вопросы (и ответить на вопросы других) вы можете в этом telegram-канале. Посмотреть новости о конференции — в другом, или на выбор: Facebook, VKontakte, Twitter, Youtube, — если вы предпочитаете именно их.
До встречи на Golang Live 2020!
Aushilfskraft
Делает по решениям, подставляя код, а не разбираясь в принципах. Вот в памяти
и не остается.
28 вопросов на самом деле очень легких. Широта знаний и практический опыт.
Большего от кандидатов не требуется, но они и этого не предоставляют.
Зачем тогда идут? Неужели не стыдно отвечать «не знаю» на собеседовании
себя, как специалиста
ar2rsoft
А как узнать знаю или не знаю, пока не видел вопроса?
Я вот с более чем 10 летним опытом, но на собесах иногда на очень простые вещи могу не ответить. А где-то прохожу собес в легкую и потом никого не разочаровываю (вроде). В примерно одинаковых по запросам вакансиях
Aushilfskraft
Учить, повторять, использовать знания на практике. 10-летний опыт при белых пятнах,
видимо, в теории? Меня бы не впечатлило
Rive
1. Вероятность полного совпадения опыта случайно взятого специалиста и интервьюера (или составителя чек-листа) довольно низка. Если взять список из 28 вопросов, не дать к ним подготовиться и предположить, что шанс знания любого из них составляет 95%, то шанс безошибочного ответа по всему чек-листу составляет 23%. При этом специалист с опытом умудрялся как-то находить работу и приносить ощущение пользы, раз его оттуда не выгоняли.
2. Теоретические знания помогут на практике только чтобы осадить ретивых коллег в комментах к пулл-реквесту или надуть щёки на собеседовании, чтобы лягушка показалась больше, опаснее и увесистее. Ну, наверное эти слои брони хороши для кандидата, раз он их на себя навешивает. Только вы нанимаете писателя кода руками или говорителя ртом университетских лекций?
Знания per se, на мой взгляд, в решениях проблем имеют более низкий приоритет перед умением своевременно их отыскивать и применять.
Aushilfskraft
Опыт это знания и навыки. Практическое применение знаний.
Не снимаю вину с интервьюера и вопросов по конкретным
методикам — логичнее выглядит поставка формальной задачи для
оценки хода рассуждений кандидата.
Но при собеседовании сеньора ни один работодатель не будет
готов услышать «не знаю». Понятно, что узнает, разок прочитав.
Но реноме по первому впечатлению в глазах руководства
будет не очень
DMGarikk
вы переоцениваете и работодателей и соискателей и ситуацию на рынке, чтобы так считать
ne_kotin
а что, сеньор обязан в голове держать весь scope сабжевого стека, которым он пользуется?
я вот, например, пересеньор Java, но нюансы Core Java — такие как JMM, ассортимент GC, и подход к реализации compare-and-set навскидку не помню, потому что давно не сталкивался с performance issues. И я спокойно отвечаю на подобные вопросы — «не помню». Но столкнувшись с проблемой и легонько погуглив — вспомню. В том числе, и что я делал, и как решал. Просто некоторый опыт лежит в cold storage и без нужного количества ассоциаций из глубин памяти не поднимается.
А если зарплатодатель хочет пафосного решения задачек на вайтборде/листочке — это без меня, пожалуйста. Я пришел участвовать в решении реальных проблем, а не академических коней в вакууме.
anonymous
Вы в вакансии видите список скиллов требуемых для работы. Видите в вакансии описание обязанностей. Ну сложите паззл в голове перед собеседованием. Подумайте что вам понадобится знать. Освежите память. Че вы прям на собеседование без подготовки идете даже описаниемвакансии не прочитав?
ne_kotin
Да. Знаете почему? Чтобы на испытательном не выглядеть бледно. Можно пройти любой собес задрочив теорию. А испытательный слить, столкнувшись с задачами, которые превышают ваши скиллы.
Ну, почему же. Прочитав. И даже часто погуглив отзывы кандидатов. Но когда речь заходит «давайте нарисуйте на листочке» — говорю, что мне это неинтересно. Дальше — по обстоятельствам.
Обычно крупноблочного разбора близких к бизнесовым кейсов на уровне сеньора/лида/архитекта хватает.
gecube
А разве не нужно брать задачи, которые чуточку выше твоего уровня, но по силам? Иначе утонешь в рутине и будешь без развития?
0xd34df00d
А это я предпочту, чтобы решал работодатель. Если ему нужен чувак, стабильно выполняющий задачи, а тут нарисуюсь я такой с развитием и чуточку-выше-уровня, то это будет как-то нечестно. Пусть работодатель представляет мой честный текущий уровень и моё желание или нежелание расти в разных областях, а дальше там пусть решает, нужен ему такой человек или нет.
ne_kotin
Зависит. Но не вижу связи с моей предыдущей репликой. Детализируйте?
amofon
Это не школа и не ВУЗ. Где можно выучить перед экзаменом за день-два, а потом благополучно забыть навечно.
Вас нанимают как профессионала в какой-то сфере.
Стать профессионалом, прочитав за день перед этим «билеты по экзамену» невозможно.
Что-то можно освежить в голове. Но не более.
А львиная часть профессиональных познаний и навыков при вас всегда, пока вы работаете в этой сфере.
anonymous
Простите но вы ерунду какуюто говорите я не о том чтобы выучить а о том чтобы осведить в памяти. Идя на турник вы же мышцы разминаете как оо связки готовите к нагрузке? Или рвете 20 раз без разминки и подготовки?
amofon
Сравнивать умственную деятельность, которой вы занимаетесь как профессионал ежедневно полный день?
С физической деятельностью, которой вы занимаетесь через день в течение пары часов?
И после этого ерунду говорю я?
anonymous
> Сравнивать умственную деятельность, которой вы занимаетесь как профессионал ежедневно полный день?
простите, но даже как профессионал занимаясь этми каждый день мне нужн овремя на раскачку подготовку концентрацию и освежить в памяти что вчера было. так что вы тут зря пытаетесь натянуть сову на глобус
amofon
Не прощаю.
Разве речь шла о том, что с вами будут проводить 5-ти минутое блиц-интервью, где вам нужно показать всё, что вы умеете?
Напротив, если вы читали статью — речь о довольно обстоятельной неспешной беседе.
anonymous
Значит и подготовиться к ней надо обстоятельно и серьезно
Koneru
Да, 20 раз без разминки сделаю и не замечу. А вот условно уже 40 вряд-ли, но подготовив мыщцы(около недели-двух) смогу сделать без проблем. Именно подготовив конкретные мыщцы(ака конкретный навык). Для этого необходим бэкграунд.
anonymous
> Да, 20 раз без разминки сделаю и не замечу.
травма вам обеспечена. я вас честно говорю. как потерпевший
titsi
Кмк на турнике(просто подтягиваясь) сложно травму получить. А вот со штангой запросто.
Koneru
Абсолютно верно. При работе со своим весом и обычных нагрузках все будет нормально. За 8 лет регулярных занятий я думаю мог уже получить необходимых знания. То что вы повредились и сделали неправильные выводы экстраполировав их на всех, конечно, печально. Да, разогреваться нужно, если идешь на свой рекорд. А для рутины не стоит тратить время.
Пысы я это писал к тому, что если ты привык к определенной комфортной нагрузке, то и готовится нет смысла. А то дальше нужно будет постоянно рекорды ставить, можешь ты это или нет. Лучше расширять границы рутины, чем делать до предела. И это не важно, спорт или работа.
Пысы 2. пересмотрел профиль, за время вашего опыта у вас наверняка были какие-то личные нюансы, которые повлияли на получение травмы.
anonymous
А че так со штпнгой? Подошел и 100 раз раанул. Без разминки и подготовки. Ну как на собеседовании.
0xd34df00d
Если меня на собеседовании просят 100 раз рвануть штангу, то, если это адекватная контора, в реальной жизни я тоже буду минимум 100 раз штангу тягать на регулярной основе, а если я этого сейчас сделать не могу, то, вероятно, мне туда идти не стоит.
Koneru
Ну вот и я о том же, но видно не понимают аналогии. Если это обыденность, то не будет проблемы без подготовки это сделать, а рекорды ставить на исключительной основе, когда это действительно нужно и посильно. Лучше показывать ожидаемый или выше ожидаемого уровень навыков, чем тратить время на звезды с неба, до которых еще не дорос.
anonymous
чтобы даже ожидаемый уровень показать, нужно подготовиться
VolCh
Не поверите, но когда перестал готовиться к собеседованиям лет 10-15 назад, то их качество резко возросло.
anonymous
Да я тоже когда перестал готовиться к соревнованиям по маоафону стал выигрывать только первые места. Не поверите?
VolCh
Нет
anonymous
Вот и я в такой же ситуации
ilya_fm
Он не говорил, что он не работал над собой вообще.
Aushilfskraft
Не знаю, не помню, не пробовал — три огромные разницы. :)
Качественные
Paskin
Соглашусь. Только что проходил интервью в одну из «большой тройки» компаний — публичных облаков. Не знаю, это политика местного отделения или глобальная — но интервью вертятся вокруг знания тонких деталей их сервисов. Сталкиваясь же с их архитекторами по предыдущей работе — я ни разу не получил никаких ответов по собственно архитектуре, кроме советов погуглить руководство.
Aushilfskraft
Прошу извинить, теперь без словесного мусора:
Не готовый услышать «не знаю» работодатель в интервью
спрашивает про задачи, которые решал соискатель, а не
углублялся в детали определенных методов, которыми мог быть
не ограничен соискатель.
Подобная ограниченность вопросов на собеседованиях высокого
уровня снимает абсолютно все претензии.
Еще раз извините, не посмотрел на себя со стороны
yks
1.
во-первых, нет такой величины как "шанс знания", если ты работаешь с этим инструментом, то объём знаний зависит не от шанса, а от опыта работы. Да, ты можешь не использовать какую-то часть языка, но как раз именно объём (и глубина) знаний и отличает например сеньора от джуна. Если бы у сеньора был такой же "шанс знаний", как и у джуна, наверно, никому не требовались бы сеньоры.
Во-вторых, знать — это не обязательно в 100%-ном объёме помнить все детали. Знать — значит понимать и быть способным аргументировать (подразумевается, верно). Если человек может и не "знать", почему (к примеру) поиск в линейном массиве менее эффективен, чем в хэшированном дереве, то один может это вывести на ходу, а для другого разницы никакой нет — и это тоже один из факторов, которые проверяются на собеседовании.
Не нужно знать ответы на 100% вопросов, но уровень знания и понимания технологии коррелирует с уровнем ответов. Поэтому и спрашивают.
2.
Это либо наивность, либо провокация. Если бы было так, наверно сеньорам платили бы 23% от джунов (типа сеньор больше знает и поэтому будет злоупотреблять знаниями?)
Знания, конечно, можно и найти. Но представьте себе, если ваш сотрудник вместо "писания кода руками" только и делает что ищет эти "знания" в интернете? Знание, в том числе теоретическое, абсолютно необходимо для писания кода руками. Потому что каждый раз, при написании кода, вы принимаете решение. Если у вас нет знания за этим, то ваше решение — буллшит. И совершенно оправдано будет "осадить ретивого коллегу в комментах", если он не понимает, что — и почему — он наваял.
А умение отыскивать и применять, если за этим не стоит фундаментального знания и понимания технологии, приводит к такому:
https://habr.com/ru/post/521104/
VolCh
А если эти решения принимаются уже над подсознательном уровне? Например, много лет назад были все эти знания, перед принятием решения анализировались все варианты, но постепенно это стало потерей времени с одной стороны, первое пришедшее в голову решение в итоге оказалось тем же, что и выбранное по результатам анализа. Ну и анализ с использованием знаний проводился всё реже в виду бессмысленной потери времени и неиспользуемые знания утратились.
yks
Я не очень понял предпосылку. Таки знания были? Таки можно аргументировать или нет?
Скажем, из последних примеров, пришёл программист на РНР в питон и пишет:
Да, он пишет на подсознательном уровне потому, что
isset()в питоне нет. Если я ему в ревью напишу, что в питоне есть оператор"x" in the_dict, это кому-то повредит? Ущемит эго похаписта? Может он как-то аргументировать в свою пользу или нет?Или вариант 2: в Python 3.7 добавили функцию
datetime.fromisoformat(). Да, раньше приходилось либо писать в каждом проекте это заново, т.е. просто копипастить ("на подсознательном уровне"), либо использовать какую-то библиотеку. Если я в ревью напишу автору кода, что "в 3.7 это уже встроено", это кому-то как-то повредит? Ущемит эго?Я же не буду, в обоих случаях, орать и материться "вы тупые свиньи, тупой похапист и идиот, который за 3 года не удосужился в релиз ноты глянуть". Больше того, то, что я могу дать им новые знания, мне гораздо важнее того, что код в данном конкретном месте будет лучше (мне было бы быстрее и проще самому взять и поправить). Это как дать рыбу чтобы утолить голод, или научить рыбачить.
Но знания устаревают, и если ты считаешь себя пригодным для работы в современных условиях, твои знания должны быть современны. А если ты считаешь обновления знаний "бессмысленной потерей времени", ну будешь через 10 лет как те, кто сейчас на дельфи ваяют монохромные ГУИ под виндовс 98 для кассовых компов в Нигерии. Хотя возможно, это и было нормой 20 лет назад.
Поэтому да, если вы не можете аргументировать ваши решения, которые вы принимаете здесь и сейчас, то это буллшит.
VolCh
Знания были и я не про миграцию с языка на язык или даже с версии на версию. Сходу аргументировать не получится, время на повторный рисерч нужно будет. Результаты которого, да, могут быть сюрпризом, если версия сменилась. Вот, например, для многих пэхепэшников сюрприз, что true и false с некоторых пор занимают столько же места как null. По факту нисколько, типы с одним значение и значение не хранит, а bool = true|false под капотом, и теперь чаще всего лучше писать
['val1' => true, 'val2' => true]вместо['val1' => null, 'val2' => null]: затраты памяти те же, а работать удобнее чаще всего.yks
ну я собственно говорил
так что видимо это не тот случай. :)
VolCh
"Были и утрачены" для меня равносильно "нет"
PsyHaSTe
Пишу на питоне раз в 100 лет, обрадовался как-то что наконец затащаили в стд работу с датами… А потом оказалось, что нет, не затащили
dominigato
Z это таймзон
Может стоит чаще заглядывать…
PsyHaSTe
Все правильно, таймзон. Мне и нужно таймзон. Например так работает:
А если заменить +00:00 на эквивлентный Z то уже нет.
dovg
безотносительно проблемы: +00:00 и Z не совсем эквивалентны. Вернее в случае с Z они эквивалентны, но +00:00 — это смещение, а буква — это указание на таймзону, которое в разное время может иметь разное смещение: переход на летнее/зимнее время или политика может на это влиять.
nin-jin
Учитывая, что все смещения отсчитываются от зоны Z, то 00:00 ему эквивалентно.
yks
вместо Z —
+00:00хотя согласен, Z это практически стандарт. Сам немного напрягался по этому поводу.
PsyHaSTe
Да не "практически", а стандарт и есть.
yks
Спасибо :) как раз к вопросу о пользе знаний.
У питона правда несколько другой подход к реализации данной функции:
https://docs.python.org/3/library/datetime.html#datetime.datetime.fromisoformat
что, конечно, немного удивительно.
0xd34df00d
Даты — это сложно. Скорее было бы удивительно встретить библиотеку для работы с датами, где всё сделано разумно, удобно и безопасно.
PsyHaSTe
Сложность с датами обычно начинается в районе "сложить-вычесть". Но хотя бы распарсить по ISO-то можно наверное… Функцией fromisoformat :)
Rive
Это мода.
Мода диктуется в первую очередь не удобством или прагматичностью, а укоренённостью среди активных приверженцев, которые распространяют её с помощью широкого спектра механик отторжения (включая насмешки, отказ в приёме на работу, обширные атаки репутации других стэков etc).
Совсем нежизнеспособная мода в высококонкурентных областях может вымереть (потому что бизнес иногда подсчитывает деньги и увольняет / не нанимает модников, следующих стэкам, которые не обладают достаточно весомой репутацией в требуемой области). Из-за этого отсева модные стэки как-то решают свои задачи помимо обычной для себя генерации сопутствующего инфомусора, который станет бессмысленным через несколько лет.
Мода оперирует абстрактными параметрами привлекательности («лучший», «современный», «престижный»), которые лишены другого внутреннего содержания, кроме маркировки апологетов моды и тех, кто не успел или не захотел перейти на сторону этого агрессивного меньшинства.
Мода, безусловно, является подмножеством знания, однако её конечной целью не является решение задачи бизнеса, а извлечение для своей ядерной группы некоторого количества престижа, способного удовлетворить их человеческие потребности.
Согласно этой трактовке, «сеньорность» как признак сводится к совпадению модных фетишей у двух охотников из техно-варварских племён, один из которых оценивает, а другой — оценивается; при этом набор паролей и ответов постоянно меняется. Что ж… Раз это даёт какие-то результаты, которые можно зримо оценить, это иногда работает. Но меня смущает в этом механизме то, что если сотрудник умеет очень хорошо проходить собеседования (то есть обладает большим количеством паролей от них), значит он часто по ним ходит, а следовательно не занят производительной деятельностью и/или может обладать другими качественными недостатками, которые не может вскрыть система чеклистов.
Среди всех возражений, которые я получал когда-либо на код-ревью, я встречал следующие виды:
1. Структурно значимые (решение задачи является неверным во всех случаях, в некоторых случаях или выполнено неоптимально по некоторым метрикам, например время выполнения или потребляемая память в высоконагруженном участке кода).
2. Сепульки (задача формально решена, но ход её решения оскорбляет глаза ревьюера, который придерживается определённых взглядов — или наоборот игнорирует — цикломатическую сложность, среднюю длину метода, нейминг переменных, включает в себя изменение написанных лично ревьюером методов etc). Заметная часть сепулек можно автоматизировать однажды настроенным линтером, остальные запоминаются как больные мозоли ревьюера, на которые лишний раз наступать нежелательно.
3. Неверные (предлагаемое и подразумеваемое ревьюером решение в принципе не будет работать в силу специфики кодовой базы, при этом ревьюер может ухитриться проигнорировать даже поясняющий комментарий в коде, в котором прямо упоминается об этом нюансе).
Поэтому любое собеседование в сущности сводится к двум вещам:
1. к тестированию, насколько велик запас терпения
миссионератимлида квводимому в лоно истинной веры кающемуся язычникунанимаемому сотруднику после чтения имместного извода Кахетезисамодных цитат про паттерны программирования, KISS, SOLID, модели OSI, количество бакетов на острие хэш-таблицы, местонахождение мяуколки у кошки, дефолтный способ вычисления хэша для объектов в данном ЯП и прочие вещи, которые было бы слишком оскорбительно использовать для решения приземленных задач вроде катания круглых апи и таскания квадратных крудов.2. и насколько хорошо тимлид умеет обучать новоприобретённого серва прыгать на минах своего собственного ОКР (потому что вполне возможно, что нанимаемый гребец может не подавать сигналы желания пройти очередной этап дрессуры, а следовательно бесполезен для дрессировщика).
Если проблемы проекта обычно невозможно решить пятью минутами гуглежа, значит у него есть проблемы (для разработчика или для бизнеса). Например, отсутствие архитектора. Или бас-фактор, стремящийся к единице. Или есть велосипеды. Или высокая сложность, которая приводит к отваливанию кусков при попытке добавить к этому дирижаблю новую фабрику бассейнов.
Я однажды участвовал в проекте, который включал в себя редкоиспользуемый диалект скриптового языка, который почти нигде не используется (и следовательно, невозможно нагуглить решение типовых задач, посмотреть лучшие практики организации кода и т. п. — по сути, были доступны только кодовая база, доставшаяся от предыдущего поколения разработчиков, и исходники компилятора вместо документации). Для доступа к статистике использовалась самописная база данных, которая не справлялась с выросшим за годы объёмом данных. Что ж… После этого проекта мне пришлось заливать в себя уйму инфотрэша перед тем, как я снова смог ходить по собеседованиям и не просыпаться после них утром с ощущением, что мои глаза сейчас взорвутся.
Я согласен, что слепая вставка нагугленного кода без подгонки к реалиям проекта (хотя бы обычного форматирования под его стандарты или проверки, что эта штука решает задачу слишком избыточно и неоптимально) — порочная практика, которая ведёт к усложнению чтения проекта (а следовательно, и удлиннения времени выполнения задач, поскольку большую часть жизни программист проводит за чтением, немного времени пишет код, а остаток времени кричит). Тем не менее, где ещё программист наберётся модных техник, как не изучая то, что используют другие модники?
JPEG
Вроде верно говорите, но мне кажется что «знания» это не список, это граф. И некоторый вершины имеют резко более высокую центральность. Отсюда вероятность совпадения возрастает многократно если взять вопросы по самым центральным «знаниям».
AllexIn
Ой, ну я считаю себя неплохим специалистом по написанию низкоуровневой графики.
Вчера проходил собеседование на другую должность в своей же фирме.
Поплыл на двух простейших вопросах:
1. Поплыл на порядке вызовов виртуальных деструкторов в С++. Как работают конструкторы и деструкторы в нормальной ситуации я прекрасно помню. Как ведет себя всё это если делать не правильно — я с трудом осознавал в процессе собеса. Потому что в жизни я когда-то прочитал про то, как работают виртуальные деструкторы, какие могут быть проблемы. И просто пишу правильно всегда. Вспомнить порядок вызовов(вернее даже не вспомнить, а попытаться воспроизвести на основе знаний о внутренностях С++, вот что я пытался сделать). Хотя вопрос просто стыдный, даже для моей текущей должности.
2. Поплыл на левосторонних и правосторонних системах координат. Хотя казалось бы, куда проще вопрос то для программиста графики?
3. Не смог сформулировать факт, что в матрице трансофрмации подматрица 3х3 это просто три вектора базиса. Вместо этого пытался рассказать что там углы наклона векторов.
Это я всё к чему: ответы на вопросы не обязательно напрямую показываются уровень. На собесе достаточно часто поплыть в вопросах которые ты знаешь очень даже неплохо. Это же не расслабленный разговор с другом за компотом.
Aushilfskraft
Нет, это интервьюер поплыл. Если сам составлял анкету — слишком
болезненный удар по самолюбию.
Слишком простой, из подкорки долго доставать. :D
Это вопросы его показывают, верно. Которые помогают кандидату
почувствовать себя уверенно, а не интервьюеру тешить свои знания
в узких областях до запятой
ncr
AllexIn
Просто предлагал написать что будет если в одном месте virtual поставить, что будет если в другом месте virtual поставить.
ozonar
У меня друг, который решил уйти в программирование, сидит дома второй год. Он не ходит на собеседования, не ищет себе ментора, не сидит на смежных форумах.
Почему? Ему стыдно.
И на мой взгляд это неправильно — нет ничего постыдного, если ты чего-то не знаешь. Стыдно, если не хочешь узнать.
onokonem Автор
мне вот совершенно не стыдно отвечать «не знаю»
даже не знать мне не стыдно — все знать все равно не получится
стыдно мне было бы рассказывать окружающим, что чего я не знаю, того и знать не надо :)