company_banner

Коллеги, вы меня огорчаете

    В июле и августе 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 — императивный или декларативный? А в чем разница?

    • Что я хочу оценить: знакомство с разными подходами к реализации бизнес-логики.
    • Самый популярный неправильный ответ: «Я не силен в теории». Очень жаль, что ты не силен в этой теории, %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.Maplockfree или нет?

    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 октября. И в этом есть свои плюсы: нам не придётся вводить ограничения на количество гостей, и участником сможет стать каждый желающий. Забронировать билеты можно на все дни конференции, а благодаря генеральному партнеру — компании Юла, — первый день открыт для всех желающих. Смотрите расписание здесь.

    Программа конференции раскроет главную тему — «Продуктовая разработка на ». Так вы сможете увидеть цельную картину и понять, как работает на реальных (часто высоконагруженных) проектах. А тестирование в случае Go становится ещё интереснее. Сложную бизнес-логику, как правило, нам приходится реализовывать нетривиальным способом, поэтому и писать интеграционные тесты для неё сложно. Что с этим можно сделать и нужно ли все обкладывать интерфейсами и моками, мы и поговорим при встрече.

    Пообщаться, задать вопросы (и ответить на вопросы других) вы можете в этом telegram-канале. Посмотреть новости о конференции — в другом, или на выбор: Facebook, VKontakte, Twitter, Youtube, — если вы предпочитаете именно их.

    До встречи на Golang Live 2020!
    Конференции Олега Бунина (Онтико)
    Конференции Олега Бунина

    Комментарии 1090

      +2
      Разработчик изучает только то, что ему нужно по текущей задаче: ничего, кроме этого, и ограничивается минимально возможным набором знаний.


      Делает по решениям, подставляя код, а не разбираясь в принципах. Вот в памяти
      и не остается.

      28 вопросов на самом деле очень легких. Широта знаний и практический опыт.
      Большего от кандидатов не требуется, но они и этого не предоставляют.
      Зачем тогда идут? Неужели не стыдно отвечать «не знаю» на собеседовании
      себя, как специалиста
        +31

        А как узнать знаю или не знаю, пока не видел вопроса?
        Я вот с более чем 10 летним опытом, но на собесах иногда на очень простые вещи могу не ответить. А где-то прохожу собес в легкую и потом никого не разочаровываю (вроде). В примерно одинаковых по запросам вакансиях

          –20
          А как узнать знаю или не знаю, пока не видел вопроса?

          Я вот с более чем 10 летним опытом, но на собесах иногда на очень простые вещи могу не ответить.

          Учить, повторять, использовать знания на практике. 10-летний опыт при белых пятнах,
          видимо, в теории? Меня бы не впечатлило
            +65
            1. Вероятность полного совпадения опыта случайно взятого специалиста и интервьюера (или составителя чек-листа) довольно низка. Если взять список из 28 вопросов, не дать к ним подготовиться и предположить, что шанс знания любого из них составляет 95%, то шанс безошибочного ответа по всему чек-листу составляет 23%. При этом специалист с опытом умудрялся как-то находить работу и приносить ощущение пользы, раз его оттуда не выгоняли.
            2. Теоретические знания помогут на практике только чтобы осадить ретивых коллег в комментах к пулл-реквесту или надуть щёки на собеседовании, чтобы лягушка показалась больше, опаснее и увесистее. Ну, наверное эти слои брони хороши для кандидата, раз он их на себя навешивает. Только вы нанимаете писателя кода руками или говорителя ртом университетских лекций?

            Знания per se, на мой взгляд, в решениях проблем имеют более низкий приоритет перед умением своевременно их отыскивать и применять.
              –10
              Опыт это знания и навыки. Практическое применение знаний.
              Не снимаю вину с интервьюера и вопросов по конкретным
              методикам — логичнее выглядит поставка формальной задачи для
              оценки хода рассуждений кандидата.
              Но при собеседовании сеньора ни один работодатель не будет
              готов услышать «не знаю». Понятно, что узнает, разок прочитав.
              Но реноме по первому впечатлению в глазах руководства
              будет не очень
                +26
                Но при собеседовании сеньора ни один работодатель не будет
                готов услышать «не знаю»

                вы переоцениваете и работодателей и соискателей и ситуацию на рынке, чтобы так считать
                  +28
                  при собеседовании сеньора ни один работодатель не будет
                  готов услышать «не знаю»

                  а что, сеньор обязан в голове держать весь scope сабжевого стека, которым он пользуется?

                  я вот, например, пересеньор Java, но нюансы Core Java — такие как JMM, ассортимент GC, и подход к реализации compare-and-set навскидку не помню, потому что давно не сталкивался с performance issues. И я спокойно отвечаю на подобные вопросы — «не помню». Но столкнувшись с проблемой и легонько погуглив — вспомню. В том числе, и что я делал, и как решал. Просто некоторый опыт лежит в cold storage и без нужного количества ассоциаций из глубин памяти не поднимается.

                  А если зарплатодатель хочет пафосного решения задачек на вайтборде/листочке — это без меня, пожалуйста. Я пришел участвовать в решении реальных проблем, а не академических коней в вакууме.
                    –8

                    Вы в вакансии видите список скиллов требуемых для работы. Видите в вакансии описание обязанностей. Ну сложите паззл в голове перед собеседованием. Подумайте что вам понадобится знать. Освежите память. Че вы прям на собеседование без подготовки идете даже описаниемвакансии не прочитав?

                      +7
                      Че вы прям на собеседование без подготовки идете

                      Да. Знаете почему? Чтобы на испытательном не выглядеть бледно. Можно пройти любой собес задрочив теорию. А испытательный слить, столкнувшись с задачами, которые превышают ваши скиллы.

                      даже описаниемвакансии не прочитав?

                      Ну, почему же. Прочитав. И даже часто погуглив отзывы кандидатов. Но когда речь заходит «давайте нарисуйте на листочке» — говорю, что мне это неинтересно. Дальше — по обстоятельствам.

                      Обычно крупноблочного разбора близких к бизнесовым кейсов на уровне сеньора/лида/архитекта хватает.
                        +1

                        А разве не нужно брать задачи, которые чуточку выше твоего уровня, но по силам? Иначе утонешь в рутине и будешь без развития?

                          +3

                          А это я предпочту, чтобы решал работодатель. Если ему нужен чувак, стабильно выполняющий задачи, а тут нарисуюсь я такой с развитием и чуточку-выше-уровня, то это будет как-то нечестно. Пусть работодатель представляет мой честный текущий уровень и моё желание или нежелание расти в разных областях, а дальше там пусть решает, нужен ему такой человек или нет.

                            0
                            Зависит. Но не вижу связи с моей предыдущей репликой. Детализируйте?
                          0
                          Че вы прям на собеседование без подготовки идете


                          Это не школа и не ВУЗ. Где можно выучить перед экзаменом за день-два, а потом благополучно забыть навечно.

                          Вас нанимают как профессионала в какой-то сфере.

                          Стать профессионалом, прочитав за день перед этим «билеты по экзамену» невозможно.

                          Что-то можно освежить в голове. Но не более.

                          А львиная часть профессиональных познаний и навыков при вас всегда, пока вы работаете в этой сфере.
                            –1
                            Стать профессионалом, прочитав за день перед этим «билеты по экзамену» невозможно.

                            Простите но вы ерунду какуюто говорите я не о том чтобы выучить а о том чтобы осведить в памяти. Идя на турник вы же мышцы разминаете как оо связки готовите к нагрузке? Или рвете 20 раз без разминки и подготовки?

                              +5
                              Простите но вы ерунду какуюто говорите я не о том чтобы выучить а о том чтобы осведить в памяти. Идя на турник вы же мышцы разминаете как оо связки готовите к нагрузке? Или рвете 20 раз без разминки и подготовки?


                              Сравнивать умственную деятельность, которой вы занимаетесь как профессионал ежедневно полный день?
                              С физической деятельностью, которой вы занимаетесь через день в течение пары часов?
                              И после этого ерунду говорю я?

                                0
                                > Сравнивать умственную деятельность, которой вы занимаетесь как профессионал ежедневно полный день?

                                простите, но даже как профессионал занимаясь этми каждый день мне нужн овремя на раскачку подготовку концентрацию и освежить в памяти что вчера было. так что вы тут зря пытаетесь натянуть сову на глобус
                                  0
                                  простите, но даже как профессионал занимаясь этми каждый день мне нужн овремя на раскачку подготовку концентрацию и освежить в памяти что вчера было. так что вы тут зря пытаетесь натянуть сову на глобус


                                  Не прощаю.
                                  Разве речь шла о том, что с вами будут проводить 5-ти минутое блиц-интервью, где вам нужно показать всё, что вы умеете?
                                  Напротив, если вы читали статью — речь о довольно обстоятельной неспешной беседе.
                                    0

                                    Значит и подготовиться к ней надо обстоятельно и серьезно

                                +1
                                Рвете 20 раз без разминки и подготовки?

                                Да, 20 раз без разминки сделаю и не замечу. А вот условно уже 40 вряд-ли, но подготовив мыщцы(около недели-двух) смогу сделать без проблем. Именно подготовив конкретные мыщцы(ака конкретный навык). Для этого необходим бэкграунд.
                                  +1
                                  > Да, 20 раз без разминки сделаю и не замечу.
                                  травма вам обеспечена. я вас честно говорю. как потерпевший
                                    0
                                    травма вам обеспечена. я вас честно говорю

                                    Кмк на турнике(просто подтягиваясь) сложно травму получить. А вот со штангой запросто.
                                      0
                                      Абсолютно верно. При работе со своим весом и обычных нагрузках все будет нормально. За 8 лет регулярных занятий я думаю мог уже получить необходимых знания. То что вы повредились и сделали неправильные выводы экстраполировав их на всех, конечно, печально. Да, разогреваться нужно, если идешь на свой рекорд. А для рутины не стоит тратить время.

                                      Пысы я это писал к тому, что если ты привык к определенной комфортной нагрузке, то и готовится нет смысла. А то дальше нужно будет постоянно рекорды ставить, можешь ты это или нет. Лучше расширять границы рутины, чем делать до предела. И это не важно, спорт или работа.

                                      Пысы 2. пересмотрел профиль, за время вашего опыта у вас наверняка были какие-то личные нюансы, которые повлияли на получение травмы.
                                        0

                                        А че так со штпнгой? Подошел и 100 раз раанул. Без разминки и подготовки. Ну как на собеседовании.

                                          0

                                          Если меня на собеседовании просят 100 раз рвануть штангу, то, если это адекватная контора, в реальной жизни я тоже буду минимум 100 раз штангу тягать на регулярной основе, а если я этого сейчас сделать не могу, то, вероятно, мне туда идти не стоит.

                                            0
                                            Ну вот и я о том же, но видно не понимают аналогии. Если это обыденность, то не будет проблемы без подготовки это сделать, а рекорды ставить на исключительной основе, когда это действительно нужно и посильно. Лучше показывать ожидаемый или выше ожидаемого уровень навыков, чем тратить время на звезды с неба, до которых еще не дорос.
                                              0
                                              чтобы даже ожидаемый уровень показать, нужно подготовиться
                                +2

                                Не поверите, но когда перестал готовиться к собеседованиям лет 10-15 назад, то их качество резко возросло.

                                  –7

                                  Да я тоже когда перестал готовиться к соревнованиям по маоафону стал выигрывать только первые места. Не поверите?

                                    +1

                                    Нет

                                      0

                                      Вот и я в такой же ситуации

                                      +1
                                      Он не говорил, что он не работал над собой вообще.
                                  +5
                                  И я спокойно отвечаю на подобные вопросы — «не помню»

                                  Не знаю, не помню, не пробовал — три огромные разницы. :)
                                  Качественные
                                    0
                                    Соглашусь. Только что проходил интервью в одну из «большой тройки» компаний — публичных облаков. Не знаю, это политика местного отделения или глобальная — но интервью вертятся вокруг знания тонких деталей их сервисов. Сталкиваясь же с их архитекторами по предыдущей работе — я ни разу не получил никаких ответов по собственно архитектуре, кроме советов погуглить руководство.
                                  +3
                                  Прошу извинить, теперь без словесного мусора:
                                  Не готовый услышать «не знаю» работодатель в интервью
                                  спрашивает про задачи, которые решал соискатель, а не
                                  углублялся в детали определенных методов, которыми мог быть
                                  не ограничен соискатель.
                                  Подобная ограниченность вопросов на собеседованиях высокого
                                  уровня снимает абсолютно все претензии.
                                  Еще раз извините, не посмотрел на себя со стороны
                                    0

                                    1.


                                    шанс знания любого из них составляет 95%, то шанс безошибочного ответа по всему чек-листу составляет 23%

                                    во-первых, нет такой величины как "шанс знания", если ты работаешь с этим инструментом, то объём знаний зависит не от шанса, а от опыта работы. Да, ты можешь не использовать какую-то часть языка, но как раз именно объём (и глубина) знаний и отличает например сеньора от джуна. Если бы у сеньора был такой же "шанс знаний", как и у джуна, наверно, никому не требовались бы сеньоры.
                                    Во-вторых, знать — это не обязательно в 100%-ном объёме помнить все детали. Знать — значит понимать и быть способным аргументировать (подразумевается, верно). Если человек может и не "знать", почему (к примеру) поиск в линейном массиве менее эффективен, чем в хэшированном дереве, то один может это вывести на ходу, а для другого разницы никакой нет — и это тоже один из факторов, которые проверяются на собеседовании.


                                    Не нужно знать ответы на 100% вопросов, но уровень знания и понимания технологии коррелирует с уровнем ответов. Поэтому и спрашивают.


                                    2.


                                    Теоретические знания помогут на практике только чтобы осадить ретивых коллег

                                    Это либо наивность, либо провокация. Если бы было так, наверно сеньорам платили бы 23% от джунов (типа сеньор больше знает и поэтому будет злоупотреблять знаниями?)


                                    Знания, конечно, можно и найти. Но представьте себе, если ваш сотрудник вместо "писания кода руками" только и делает что ищет эти "знания" в интернете? Знание, в том числе теоретическое, абсолютно необходимо для писания кода руками. Потому что каждый раз, при написании кода, вы принимаете решение. Если у вас нет знания за этим, то ваше решение — буллшит. И совершенно оправдано будет "осадить ретивого коллегу в комментах", если он не понимает, что — и почему — он наваял.


                                    А умение отыскивать и применять, если за этим не стоит фундаментального знания и понимания технологии, приводит к такому:
                                    https://habr.com/ru/post/521104/

                                      +1
                                      Если у вас нет знания за этим, то ваше решение — буллшит.

                                      А если эти решения принимаются уже над подсознательном уровне? Например, много лет назад были все эти знания, перед принятием решения анализировались все варианты, но постепенно это стало потерей времени с одной стороны, первое пришедшее в голову решение в итоге оказалось тем же, что и выбранное по результатам анализа. Ну и анализ с использованием знаний проводился всё реже в виду бессмысленной потери времени и неиспользуемые знания утратились.

                                        +3
                                        А если эти решения принимаются уже над подсознательном уровне? Например, много лет назад были все эти знания, ...

                                        Я не очень понял предпосылку. Таки знания были? Таки можно аргументировать или нет?


                                        Скажем, из последних примеров, пришёл программист на РНР в питон и пишет:


                                        if "x" in the_dict.keys(): ...

                                        Да, он пишет на подсознательном уровне потому, что isset() в питоне нет. Если я ему в ревью напишу, что в питоне есть оператор "x" in the_dict, это кому-то повредит? Ущемит эго похаписта? Может он как-то аргументировать в свою пользу или нет?


                                        Или вариант 2: в Python 3.7 добавили функцию datetime.fromisoformat(). Да, раньше приходилось либо писать в каждом проекте это заново, т.е. просто копипастить ("на подсознательном уровне"), либо использовать какую-то библиотеку. Если я в ревью напишу автору кода, что "в 3.7 это уже встроено", это кому-то как-то повредит? Ущемит эго?


                                        Я же не буду, в обоих случаях, орать и материться "вы тупые свиньи, тупой похапист и идиот, который за 3 года не удосужился в релиз ноты глянуть". Больше того, то, что я могу дать им новые знания, мне гораздо важнее того, что код в данном конкретном месте будет лучше (мне было бы быстрее и проще самому взять и поправить). Это как дать рыбу чтобы утолить голод, или научить рыбачить.


                                        Но знания устаревают, и если ты считаешь себя пригодным для работы в современных условиях, твои знания должны быть современны. А если ты считаешь обновления знаний "бессмысленной потерей времени", ну будешь через 10 лет как те, кто сейчас на дельфи ваяют монохромные ГУИ под виндовс 98 для кассовых компов в Нигерии. Хотя возможно, это и было нормой 20 лет назад.


                                        Поэтому да, если вы не можете аргументировать ваши решения, которые вы принимаете здесь и сейчас, то это буллшит.

                                          0

                                          Знания были и я не про миграцию с языка на язык или даже с версии на версию. Сходу аргументировать не получится, время на повторный рисерч нужно будет. Результаты которого, да, могут быть сюрпризом, если версия сменилась. Вот, например, для многих пэхепэшников сюрприз, что true и false с некоторых пор занимают столько же места как null. По факту нисколько, типы с одним значение и значение не хранит, а bool = true|false под капотом, и теперь чаще всего лучше писать ['val1' => true, 'val2' => true] вместо ['val1' => null, 'val2' => null]: затраты памяти те же, а работать удобнее чаще всего.

                                            0
                                            Знания были

                                            ну я собственно говорил


                                            Если у вас нет знания за этим, то ваше решение — буллшит.

                                            так что видимо это не тот случай. :)

                                              +1

                                              "Были и утрачены" для меня равносильно "нет"

                                            0
                                            datetime.fromisoformat()

                                            Пишу на питоне раз в 100 лет, обрадовался как-то что наконец затащаили в стд работу с датами… А потом оказалось, что нет, не затащили


                                            from datetime import datetime
                                            print(datetime.fromisoformat("2020-10-03T11:39:26.084730Z"))
                                            # ValueError: Invalid isoformat string: '2020-10-03T11:39:26.084730Z'
                                              +1
                                              Z это таймзон
                                              from datetime import datetime
                                              print(datetime.fromisoformat("2020-10-03T11:39:26.084730"))
                                              2020-10-03 11:39:26.084730

                                              Может стоит чаще заглядывать…
                                                +2

                                                Все правильно, таймзон. Мне и нужно таймзон. Например так работает:


                                                from datetime import datetime
                                                print(datetime.fromisoformat("2020-10-03T11:39:26.084730+00:00"))

                                                А если заменить +00:00 на эквивлентный Z то уже нет.

                                                  0
                                                  безотносительно проблемы: +00:00 и Z не совсем эквивалентны. Вернее в случае с Z они эквивалентны, но +00:00 — это смещение, а буква — это указание на таймзону, которое в разное время может иметь разное смещение: переход на летнее/зимнее время или политика может на это влиять.
                                                    +2

                                                    Учитывая, что все смещения отсчитываются от зоны Z, то 00:00 ему эквивалентно.

                                                      +1

                                                      Никакая из однобуквенных таймзон не подвержена политике или летнему времени.

                                                  +1

                                                  вместо Z — +00:00


                                                  хотя согласен, Z это практически стандарт. Сам немного напрягался по этому поводу.

                                                    +2

                                                    Да не "практически", а стандарт и есть.


                                                    img

                                                      +4

                                                      Спасибо :) как раз к вопросу о пользе знаний.


                                                      У питона правда несколько другой подход к реализации данной функции:


                                                      Caution This does not support parsing arbitrary ISO 8601 strings — it is only intended as the inverse operation of datetime.isoformat(). A more full-featured ISO 8601 parser, dateutil.parser.isoparse is available in the third-party package dateutil.

                                                      https://docs.python.org/3/library/datetime.html#datetime.datetime.fromisoformat


                                                      что, конечно, немного удивительно.

                                                        +3

                                                        Даты — это сложно. Скорее было бы удивительно встретить библиотеку для работы с датами, где всё сделано разумно, удобно и безопасно.

                                                          +3

                                                          Сложность с датами обычно начинается в районе "сложить-вычесть". Но хотя бы распарсить по ISO-то можно наверное… Функцией fromisoformat :)

                                                  +4
                                                  Больше того, то, что я могу дать им новые знания, мне гораздо важнее того, что код в данном конкретном месте будет лучше


                                                  Это мода.
                                                  Мода диктуется в первую очередь не удобством или прагматичностью, а укоренённостью среди активных приверженцев, которые распространяют её с помощью широкого спектра механик отторжения (включая насмешки, отказ в приёме на работу, обширные атаки репутации других стэков etc).
                                                  Совсем нежизнеспособная мода в высококонкурентных областях может вымереть (потому что бизнес иногда подсчитывает деньги и увольняет / не нанимает модников, следующих стэкам, которые не обладают достаточно весомой репутацией в требуемой области). Из-за этого отсева модные стэки как-то решают свои задачи помимо обычной для себя генерации сопутствующего инфомусора, который станет бессмысленным через несколько лет.
                                                  Мода оперирует абстрактными параметрами привлекательности («лучший», «современный», «престижный»), которые лишены другого внутреннего содержания, кроме маркировки апологетов моды и тех, кто не успел или не захотел перейти на сторону этого агрессивного меньшинства.

                                                  Мода, безусловно, является подмножеством знания, однако её конечной целью не является решение задачи бизнеса, а извлечение для своей ядерной группы некоторого количества престижа, способного удовлетворить их человеческие потребности.

                                                  Согласно этой трактовке, «сеньорность» как признак сводится к совпадению модных фетишей у двух охотников из техно-варварских племён, один из которых оценивает, а другой — оценивается; при этом набор паролей и ответов постоянно меняется. Что ж… Раз это даёт какие-то результаты, которые можно зримо оценить, это иногда работает. Но меня смущает в этом механизме то, что если сотрудник умеет очень хорошо проходить собеседования (то есть обладает большим количеством паролей от них), значит он часто по ним ходит, а следовательно не занят производительной деятельностью и/или может обладать другими качественными недостатками, которые не может вскрыть система чеклистов.

                                                  Поэтому да, если вы не можете аргументировать ваши решения, которые вы принимаете здесь и сейчас, то это буллшит.

                                                  Среди всех возражений, которые я получал когда-либо на код-ревью, я встречал следующие виды:
                                                  1. Структурно значимые (решение задачи является неверным во всех случаях, в некоторых случаях или выполнено неоптимально по некоторым метрикам, например время выполнения или потребляемая память в высоконагруженном участке кода).
                                                  2. Сепульки (задача формально решена, но ход её решения оскорбляет глаза ревьюера, который придерживается определённых взглядов — или наоборот игнорирует — цикломатическую сложность, среднюю длину метода, нейминг переменных, включает в себя изменение написанных лично ревьюером методов etc). Заметная часть сепулек можно автоматизировать однажды настроенным линтером, остальные запоминаются как больные мозоли ревьюера, на которые лишний раз наступать нежелательно.
                                                  3. Неверные (предлагаемое и подразумеваемое ревьюером решение в принципе не будет работать в силу специфики кодовой базы, при этом ревьюер может ухитриться проигнорировать даже поясняющий комментарий в коде, в котором прямо упоминается об этом нюансе).

                                                  Поэтому любое собеседование в сущности сводится к двум вещам:
                                                  1. к тестированию, насколько велик запас терпения миссионера тимлида к вводимому в лоно истинной веры кающемуся язычнику нанимаемому сотруднику после чтения им местного извода Кахетезиса модных цитат про паттерны программирования, KISS, SOLID, модели OSI, количество бакетов на острие хэш-таблицы, местонахождение мяуколки у кошки, дефолтный способ вычисления хэша для объектов в данном ЯП и прочие вещи, которые было бы слишком оскорбительно использовать для решения приземленных задач вроде катания круглых апи и таскания квадратных крудов.
                                                  2. и насколько хорошо тимлид умеет обучать новоприобретённого серва прыгать на минах своего собственного ОКР (потому что вполне возможно, что нанимаемый гребец может не подавать сигналы желания пройти очередной этап дрессуры, а следовательно бесполезен для дрессировщика).

                                                  А умение отыскивать и применять, если за этим не стоит фундаментального знания и понимания технологии, приводит к такому:

                                                  Если проблемы проекта обычно невозможно решить пятью минутами гуглежа, значит у него есть проблемы (для разработчика или для бизнеса). Например, отсутствие архитектора. Или бас-фактор, стремящийся к единице. Или есть велосипеды. Или высокая сложность, которая приводит к отваливанию кусков при попытке добавить к этому дирижаблю новую фабрику бассейнов.
                                                  Я однажды участвовал в проекте, который включал в себя редкоиспользуемый диалект скриптового языка, который почти нигде не используется (и следовательно, невозможно нагуглить решение типовых задач, посмотреть лучшие практики организации кода и т. п. — по сути, были доступны только кодовая база, доставшаяся от предыдущего поколения разработчиков, и исходники компилятора вместо документации). Для доступа к статистике использовалась самописная база данных, которая не справлялась с выросшим за годы объёмом данных. Что ж… После этого проекта мне пришлось заливать в себя уйму инфотрэша перед тем, как я снова смог ходить по собеседованиям и не просыпаться после них утром с ощущением, что мои глаза сейчас взорвутся.

                                                  Я согласен, что слепая вставка нагугленного кода без подгонки к реалиям проекта (хотя бы обычного форматирования под его стандарты или проверки, что эта штука решает задачу слишком избыточно и неоптимально) — порочная практика, которая ведёт к усложнению чтения проекта (а следовательно, и удлиннения времени выполнения задач, поскольку большую часть жизни программист проводит за чтением, немного времени пишет код, а остаток времени кричит). Тем не менее, где ещё программист наберётся модных техник, как не изучая то, что используют другие модники?
                                              0

                                              Вроде верно говорите, но мне кажется что «знания» это не список, это граф. И некоторый вершины имеют резко более высокую центральность. Отсюда вероятность совпадения возрастает многократно если взять вопросы по самым центральным «знаниям».

                                                0
                                                Хотя я немного иначе смотрю на этот процесс, но ваше мнение прям вот, что называется, «по земле ходит».
                                                Иначе — потому, что я уверен, что хорошему разработчику нужно уделять время не только обучению, но и, в идеале, преподаванию. Немного, но надо.
                                            +12
                                            Ой, ну я считаю себя неплохим специалистом по написанию низкоуровневой графики.
                                            Вчера проходил собеседование на другую должность в своей же фирме.
                                            Поплыл на двух простейших вопросах:
                                            1. Поплыл на порядке вызовов виртуальных деструкторов в С++. Как работают конструкторы и деструкторы в нормальной ситуации я прекрасно помню. Как ведет себя всё это если делать не правильно — я с трудом осознавал в процессе собеса. Потому что в жизни я когда-то прочитал про то, как работают виртуальные деструкторы, какие могут быть проблемы. И просто пишу правильно всегда. Вспомнить порядок вызовов(вернее даже не вспомнить, а попытаться воспроизвести на основе знаний о внутренностях С++, вот что я пытался сделать). Хотя вопрос просто стыдный, даже для моей текущей должности.

                                            2. Поплыл на левосторонних и правосторонних системах координат. Хотя казалось бы, куда проще вопрос то для программиста графики?

                                            3. Не смог сформулировать факт, что в матрице трансофрмации подматрица 3х3 это просто три вектора базиса. Вместо этого пытался рассказать что там углы наклона векторов.

                                            Это я всё к чему: ответы на вопросы не обязательно напрямую показываются уровень. На собесе достаточно часто поплыть в вопросах которые ты знаешь очень даже неплохо. Это же не расслабленный разговор с другом за компотом.
                                              +5
                                              Потому что в жизни я когда-то прочитал про то, как работают виртуальные деструкторы, какие могут быть проблемы. И просто пишу правильно всегда.

                                              Нет, это интервьюер поплыл. Если сам составлял анкету — слишком
                                              болезненный удар по самолюбию.
                                              Поплыл на левосторонних и правосторонних системах координат. Хотя казалось бы, куда проще вопрос то для программиста графики?

                                              Слишком простой, из подкорки долго доставать. :D
                                              Это я всё к чему: ответы на вопросы не обязательно напрямую показываются уровень.

                                              Это вопросы его показывают, верно. Которые помогают кандидату
                                              почувствовать себя уверенно, а не интервьюеру тешить свои знания
                                              в узких областях до запятой
                                                0
                                                Поплыл на порядке вызовов виртуальных деструкторов в С++
                                                Заинтриговали. И что же хотел услышать интервьюер?
                                                  0
                                                  Просто предлагал написать что будет если в одном месте virtual поставить, что будет если в другом месте virtual поставить.
                                                0
                                                Неужели не стыдно отвечать «не знаю» на собеседовании

                                                У меня друг, который решил уйти в программирование, сидит дома второй год. Он не ходит на собеседования, не ищет себе ментора, не сидит на смежных форумах.

                                                Почему? Ему стыдно.

                                                И на мой взгляд это неправильно — нет ничего постыдного, если ты чего-то не знаешь. Стыдно, если не хочешь узнать.
                                                  +2
                                                  мне вот совершенно не стыдно отвечать «не знаю»

                                                  даже не знать мне не стыдно — все знать все равно не получится

                                                  стыдно мне было бы рассказывать окружающим, что чего я не знаю, того и знать не надо :)
                                                +39
                                                Не так давно на хабре были несколько постов, именно что ругающих подобный подход к собеседованиям.

                                                6. Как устроен тип map?

                                                Самый популярный неправильный ответ: «то хеш-таблица». Да, это хеш-таблица. Как устроена хеш-таблица?
                                                Наводящие вопросы: какая hash-функция используется в map в Go? Что такое bucket?


                                                -_\ это вы серьезно сейчас? Ну т.е. какая *реальная* польза от того, что чел будет знать, какая там хэш-функция используется? Если хотите спросить про хэш-таблицы — ну так и спросите без применения к языку «Какие хэш-таблицы вы знаете?». А считать первый ответ «хэш-таблица» неправильным на вопрос «Как устроен тип map» — ну, такое.

                                                12. Сколько времени в минутах займет у вас написание процедуры обращения односвязного списка?

                                                Самый популярный неправильный ответ: «А что такое односвязанный список?». Это такая структура данных...

                                                Благодаря усилиям хэдхантеров Evrone Екатерины Тхоржевской и Анны Кудряшовой — спасибо им! — до меня добираются только резюме интересных кандидатов


                                                А на этом моменте закралось подозрение, что ваш «базовый фильтр» кандидатов вообще работает. И, наверное, стоит или посмотреть повнимательнее на ваших «хэдхантеров» или, по крайней мере, этот вопрос делегировать им — во время первого телефонного созвона должно быть достаточно просто и понятно.

                                                Подобная задача это же абсолютно типичная задачка на кодинг почти в любом языке и любой человек, оценивающий это больше чем в 5 минут должен вызывать подозрения (ну или по крайней мере уточнить, вдруг вы спрашиваете про «тупокод», а кандидат ответил «час», имея в виду полный процесс от кода, до тестов, документации, упаковки в реюзабельный пакет и всего прочего)

                                                P.S. Ну и да, кажется подозрительным, что у вас большинство кандидатов знает слово «хэш-таблица», но не знает слова «односвязный список».
                                                  +4
                                                  я ничего не выдумал.

                                                  про хеш-таблицу — люди знают словосочетание, но не знают, что за ним скрывается.

                                                  про список — я сам сначала не поверил, стал на собесах задавать вопрос на собесах.
                                                    +8
                                                    А поясните для не-сварщиков на go: так и какая же функция хеширования используется? А где это специфицировано? А что менялось с версии 1.10 до 1.13+ в этой части?
                                                      –18
                                                      это вопрос с подвохом. там под разные типы разные функции. для int, например, он сам :)
                                                        +44
                                                        Я не стану повторять вопрос, но вы на него не ответили в полном объеме, а он (ответ) потянет на весьма немаленькое исследование и копания в сорцах, а если наложить ещё и версии...

                                                        это плохой вопрос и вот почему: 1) без спецификации там может быть что-угодно, да ещё и зависящее от платформы, runtime окружения, «времени суток и уровня воды на берегу» 2) код подобных типов склонен меняться и, зачастую, в более сложный мутировать, так что сегодняшнее представление о map может быть совсем неверным завтра (например — обрастать условиями на количество элементов в map-е или runtime эвристиками).

                                                        Вот вы сами рассуждаете о императивности и декларативности — и тут же просите от кандиата того, что в общем-то не декларируется нигде и никем (ну, исключая исходники, конечно). Реальность же такова, что ответ «там бакеты» вполне годный — это как минимум говорит о том, что человек где-то что-то слышал или имеет базовые (академические) представления о реализации подобных структур. А вот момент когда ему действительно понадобится лазить «в кишки» может и не настать вовсе, а когда настанет — добро пожаловать в мир профилирования…
                                                          –6
                                                          коллега, возможно, вы правы. возможно, про устройство стандартных структур данных в go можно мпросить как-то иначе, с большей эффективностью.

                                                          или, возможно, про их устройство не надо спрашивать вообще. я, конечно, думаю, что надо.

                                                          если у вас есть идеи, что спрашивать на этом месте — предлагайте!
                                                            +15
                                                            Надо спрашивать о свойствах map/хеш-таблицы. Какое (асимптотическое) время операций, какие накладные расходы, какие требования к ключам. Чем эта структура хуже и лучше сбалансированных деревьев. Защищает ли стандартная реализация от DoS атак и что это такое. Если защищает – что это означает с точки зрения воспроизводимости поведения структуры, если нет – в каких случаях ее нельзя использовать. Что с потокобезопасностью?

                                                            Я не написал ни строки но Go, но я сильно сомневаюсь, что используемая хеш-функция в стандартной библиотеке специфицирована и ее неизменность гарантируется от версии к версии. Как и внутренние детали реализации.

                                                            Гораздо важнее, чтобы разработчик понимал свойства и гарантии используемых инструментов, а не внутренюю реализацию. Я вот знаю как устроен HashMap в Rust, но лучше бы не знал – там столько SIMD и черной магии, что можно засмущать любого интервьювера на собеседовании.

                                                            Аналогичный вопрос: как работет динамический массив? Вы вот точно знаете все ньюнсы его реализации? Сколько будет по факту выделено памяти в каждом случае инициализации и релокации?
                                                              +1
                                                              и ее неизменность гарантируется от версии к версии

                                                              Не гарантируется. Надо следить. Это тоже один из факторов опыта. Тоже самое с массивом. Go кстати редкий удивительный язык, который интересен внутри. В доках 30 летней давности они даже так и писали: "Ну вы там в реализацию такой-то либы взгляните"

                                                                +2
                                                                В доках 30 летней давности они даже так и писали
                                                                Ему 11
                                                                  0

                                                                  Ему 11 только в последнем издании. А так — больше 30

                                                                    0

                                                                    В контексте разговора — нет, далеко не 11

                                                              +3
                                                              Только программистов могут так собеседовать. Представляю себе собеседование на должность строителя, которого сначала расспрашивают какой фирмы обмотка в дрели Макита, технические характеристики цемента, виды кирпичей, диаметры патрубков. Или просят построить «тестовый» дом. Или приводят к кривой и косой избе и просят рассказать что в ней не так, и как это пофиксить.
                                                              Причем ладно бы это имело какой смысл и было бы что предложить кандидату, но 95% российских компаний ничего не могут предложить разработчику, кроме ежедневной рутины за копейки. Но собеседования с таким выпендрёжем смеху подобно. Вместо того, чтобы брать с запада зарплаты и условия труда, берут подобные фильтры отсева. Но раз это хавают, то что поделаешь.
                                                                +1
                                                                технические характеристики цемента, виды кирпичей, диаметры патрубков

                                                                а вот это прораб должен знать, хотя бы в общих чертах
                                                                  +1

                                                                  У меня все-таки вопрос — зачем вам нужен прораб? И как вы жили без него до сего момента? Смайлик.

                                                                    –1
                                                                    ну вот эта должность была — прорабская
                                                                      0
                                                                      У меня все-таки вопрос — зачем вам нужен прораб? И как вы жили без него до сего момента? Смайлик.


                                                                      У меня всё таки вопрос:
                                                                      Зачем вы инженерную специальность (software engeneer) сравниваете с рабочим?
                                                                      Но отказываетесь принять тот факт, что она по уровню, всё же, ближе к должности прораба.
                                                                      Тот факт, что в ИТ нет такого количества простых рабочих, а все разработчики, по сути, инженеры — ну вот так это в ИТ. Полной аналогии со строительством нет.

                                                                      P.S.:
                                                                      Когда я получал разряд простого слесаря в прошлом веке — на экзамене меня гоняли по видам резьб и особенностям обработки металла. И это нормально.
                                                                        +1
                                                                        P.S.:
                                                                        Когда я получал разряд простого слесаря в прошлом веке — на экзамене меня гоняли по видам резьб и особенностям обработки металла. И это нормально.

                                                                        а вас не гоняли по особенностям устройства токарного станка? насколько микрон отклонение у него при определенных оборотах? а какая зависимость от того 220 или 380 у него напряжение питания? а как масса шпинделя влияет на качество обработки? обоснуйте, и в микронах.
                                                                        а теперь тоже самое но со сверлильным станком
                                                                          0
                                                                          а вас не гоняли по особенностям устройства токарного станка?


                                                                          Да, были несколько вопросов по форме резцов токарного станка.

                                                                          а какая зависимость от того 220 или 380 у него напряжение питания

                                                                          В приведенном в статье выше никаких настолько абсурдных вопросов, как вы приводите в пример нет.
                                                                            0
                                                                            Почему сразу абсурдных (хотя некоторые вопросы я могу посчитать из того списка абсурдными)
                                                                            потому что есть влияние от напряжения питания как минимум на мощность станка и на особенности его работы.
                                                                            И вы, если хотите считать себя сеньором-токарем, должны хотябы образно знать его устройство, принципы работы привода (асинхронный, обычный_, люфты в КПП их влияние на качество обработки.
                                                                            (сарказм конечно, но в теме статьи и вполне может быть правдой если совсем упарыватся теорией)
                                                                              –1
                                                                              И вы, если хотите считать себя сеньором-токарем, должны хотябы образно знать его устройство, принципы работы привода (асинхронный, обычный_, люфты в КПП их влияние на качество обработки.


                                                                              1) Я писал о слесаре. Не токаре.
                                                                              2) Про высокий разряд ни словом ни обмолвился. Там ни о каком сеньоре-слесаре и речи ни шло.
                                                                              3) Вы серьезно считает что опросник из статьи предназначен для тестирования сеньоров?

                                                                                0
                                                                                1) Я писал о слесаре. Не токаре.

                                                                                Пфф… я вам могу придумать кучу вопросов по кувалде (состав стали? влияние веса и состава на максимальную температуру детали по которой вы бъете, ухудшаются и насколько характеристики металла при ударе и почему)

                                                                                3) Вы серьезно считает что опросник из статьи предназначен для тестирования сеньоров?

                                                                                Я серьезно? так там в статье написано что автор считает что по данному опроснику сеньор должен набирать +8 баллов, а джун 3+
                                                                                и мой опыт собеседований на сеньора (не golang) подсказывает что такие опросники действительно поляризуются популярностью
                                                                            0
                                                                            гоняли, конечно. я тоже в прошлом веке получал разряд токаря :)
                                                                      +10
                                                                      Интервьюер: Итак, вы считаете себя плотником?
                                                                      Плотник: Всё верно. Это именно то, чем я занимаюсь.

                                                                      Интервьюер: Как долго вы занимаетесь этим?
                                                                      Плотник: Десять лет.

                                                                      Интервьюер: Очень хорошо. А теперь я бы хотел задать вам несколько технических вопросов, чтобы оценить, насколько вы впишетесь в нашу команду. Договорились?
                                                                      Плотник: Конечно, было бы неплохо.

                                                                      Интервьюер: Должен вам сказать, что мы работаем в подразделении, занимающимся постройкой большого количества коричневых домов. Доводилось ли вам строить множество коричневых домов?
                                                                      Плотник: Ну, я же плотник — я строю дома, а люди уже красят их так, как пожелают.

                                                                      Интервьюер: Да, я понимаю, но не могли бы вы подсказать мне, сколько у вас опыта именно с коричневыми? Ну, плюс-минус.
                                                                      Плотник: Я действительно понятия не имею. С того момента, как дом построен, меня не волнует, в какой цвет его покрасят. Может, шесть месяцев?

                                                                      Интервьюер: Шесть месяцев? Вообще-то мы ищем кого-нибудь с гораздо большим опытом коричневого, но позвольте мне задать вам ещё несколько вопросов.
                                                                      Плотник: Ладно. Но, знаете, покраска — это покраска.

                                                                      Интервьюер: Да-да, хорошо. Что насчёт Ореха?
                                                                      Плотник: А что с ним?

                                                                      Интервьюер: Много ли вы работали с ореховым деревом?
                                                                      Плотник: Конечно. Ореховое дерево, сосна, дуб, красное дерево — всё, что угодно.

                                                                      Интервьюер: Но сколько лет вы работали с Орехом?
                                                                      Плотник: Да не знаю я, чёрт возьми. Я что, должен считать каждую доску?

                                                                      Интервьюер: Ну хотя бы примерно?
                                                                      Плотник: Хорошо, тогда я бы сказал, что у меня есть полтора года опыта работы с ореховым деревом.

                                                                      Интервьюер: Но вы не ореховый гуру?
                                                                      Плотник: Ну, я же плотник — я работаю с любыми типами дерева, которые, конечно, имеют некоторые отличия, но я считаю, что если ты хороший плотник…

                                                                      Интервьюер: Да, да, но мы используем ореховое дерево. Это нормально?
                                                                      Плотник: Ореховое дерево — это прекрасно! Всё, чего пожелаете — я же плотник.

                                                                      Интервьюер: Что насчёт чёрного Ореха?
                                                                      Плотник: А с ним что?

                                                                      Интервьюер: У нас было несколько ореховых плотников, но потом случайно выяснилось, что они не были плотниками по чёрному Ореху. Имеется ли у вас опыт с ним?
                                                                      Плотник: Конечно, немного. Полагаю, было бы хорошо иметь больше опыта для моего резюме.

                                                                      Интервьюер: Ладно. Позвольте мне свериться со списком вопросов.
                                                                      Плотник: Да пожалуйста.

                                                                      Интервьюер: Итак, последний вопрос на сегодня. Мы используем Камень 5.1 для забивания гвоздей. Использовали ли вы Камень 5.1?
                                                                      Плотник: [становясь белым...] Ну, я знаю, что множество плотников начали использовать камни, чтобы забивать гвозди, когда Craftsman купил каменоломню, но, вы знаете, честно говоря, у меня это получается гораздо лучше с моим гвоздомётом. Или молотком, если хотите. Мне кажется, что, когда я использую камень, то слишком часто ударяю себя по пальцам, и моя рука сильно болит, потому что камень очень большой.

                                                                      Интервьюер: Но другие компании используют камни. Вы хотите сказать, что камни не работают?
                                                                      Плотник: Нет, я вообще-то не говорю, что камни не работают. Я лишь считаю, что гвоздомёты работают лучше.

                                                                      Интервьюер: Все наши архитекторы начинали использовать камни и им понравилось.
                                                                      Плотник: Конечно они это делали, но я забиваю гвозди целый день и — ладно, слушайте, мне нужна работа, так что я определённо готов к использованию камней, если вы захотите. Я стараюсь сохранить объективность.

                                                                      Интервьюер: Ок. У нас есть ещё несколько кандидатов; мы свяжемся с вами, когда примем решение.
                                                                      Плотник: Что ж, спасибо за ваше время. Было приятно поговорить.

                                                                      СЛЕДУЮЩИЙ ДЕНЬ

                                                                      Звонок…

                                                                      Интервьюер: Алло?
                                                                      Плотник: Здравствуйте! Помните меня? Я тот плотник, которого вы собеседовали для работы с чёрным ореховым деревом. Хотел лишь узнать, приняли ли вы решение.

                                                                      Интервьюер: Вообще-то приняли. В целом, нам нравится ваш опыт, но мы решили взять кого-то, кто больше работал с коричневыми.
                                                                      Плотник: Правда? И это всё? Меня не взяли на работу, потому что у меня недостаточно коричневых?

                                                                      Интервьюер: Ну, это только частично правда, но частично, мы взяли другого парня, потому что он намного дешевле.
                                                                      Плотник: Серьёзно? И сколько же у него опыта?

                                                                      Интервьюер: Ладно, он не совсем плотник, он продавец машин. Однако он продал много коричневых машин и работал с отделкой из орехового дерева.
                                                                      Плотник: [короткие гудки]
                                                                        0
                                                                        Забрал в закладки
                                                                          0
                                                                          Это великолепно!
                                                                            0
                                                                            Не по теме, но ситуация с камнями мне напоминает ситуацию с redux во фронтенде) Есть гвоздомёты, молотки для забивания гвоздей, но стандарт — камень.
                                                                        +1

                                                                        Там не просто разные функции, там разные реализации(map_fast32.go, map_fast64.go, map_faststr)?

                                                                      +9
                                                                      про хеш-таблицу — люди знают словосочетание, но не знают, что за ним скрывается.


                                                                      Ну так повторюсь — спрашивайте тогда без контекста в виде языка. Потому что надо быть достаточно упоротым, чтобы навскидку знать, какая хэш-функция используется в конкретном языке для конкретного типа данных, но при этом слова «метод цепочек» и «открытая адресация» (а в упоротых случаях еще и какой-нибудь «Cuckoo hashing» можно вспомнить) вполне можно знать, особенно если недавно открывал Кормена (что, конечно, в реальной работе особо не поможет, да и «вы не гугл» (с))

                                                                      И да, забыл еще это упомнянуть:
                                                                      10. Как вы отсортируете массив структур по алфавиту по полю Name?

                                                                      Самый популярный неправильный ответ: «Методом пузырька». Пузырек — прекрасный алгоритм, но есть сегодня и поэффективнее. Например — quicksort. Не можете с ходу имплементировать quicksort? Так ведь и не надо!


                                                                      Я допускаю этот ответ в контексте «пошутить». Т.е. это просто самое первое, что ты говоришь с улыбкой, но через две секунды следует уточнение «но, конечно, так в жизни делать не надо, в реальности я бы сделал так и так». Если же вам кандидат в синьоры (да что там, даже кандидат в джуны такую ересь не должен пороть) прямо всерьез без шуток говорит и предлагает «пузырьком» — я бы сразу пожал руки и пожелал удачного дня, сохранив и ваше время, и время кандидата.

                                                                      Собственно, поставьте этот и вопрос про список двумя первыми и сэкономьте свое время.
                                                                        +8
                                                                        Мне кажется, если программисту надо имплементировать (в очередной раз) метод сортировки и при этом он не разработчик ядерных библиотек языка, то в используемом им стэке что-то очень сильно не так.
                                                                          –3
                                                                          так в том и point, что не надо, надо знать стандартную библиотеку.
                                                                            +5
                                                                            А что, в Go реализован ванильный quicksort? Сильно в этом сомневаюсь.

                                                                            Я вот не могу сходу правильно реализовать quicksort, потому что не помню как эфективно выбирать медиану, чтобы побороть деградацию производительности к O(n^2). Я плохой разработчик? А вы помните?

                                                                            Если вам правда нужно реализовать свою сортировку – использование quicksort скорее всего плохая идея. Большинство стандартных библиотек полагаются на mergesort, как основной алгоритм, реализуя поверх него гибридные схемы (timsort и другие). Гораздо важнее знать эту информацию, чем помнить наизусть школьный алгоритм.
                                                                              +3
                                                                              В Go есть пакет sort, который содержит в себе набор функций для сортировки. В этом и вопрос: вы будете quicksort писать сами или воспользуетесь стандартной библиотекой? В которой реализовано всё минимально необходимое как для сортировки слайсов int, float, string, так и для сортировки структур. Там даже два разных алгоритма есть (в коде один называется stable, другой quickSort). Для каждого указано даже O(...log(n)...) вызовов и для одного указано, что-то типа «not guaranteed to be stable» — интересно для которого? =) Было бы интересно поговорить не только про библиотеку, но и про сам алгоритма quicksort. Прям открыть код и поговорить — почему оно реализовано так и какие проблемы они пытаются решить.
                                                                              0

                                                                              Или вопросы ставить нормально. Вы же не даёте синьорам-помидорам задачи не на сортировку массивов.
                                                                              Если это список пользователей, почему, к примеру, order by в SQL запрос не добавить?


                                                                              Можно не использовать sort в течение длительного времени (да и любой другой частный пакет) и просто забыть о его существовании, и нормально использовать когда появляется кейс. Нормальный рабочий кейс, я имею в виду, а не дядек, которые умные вопросы задают.

                                                                            0
                                                                            Потому что надо быть достаточно упоротым

                                                                            Это Go, детка :) Прошу прощения за фамильярность, но это передаёт суть

                                                                              +8
                                                                              А потом на практике окажется что метод пузырьком будет быстрее на малом объеме данных, потому-что кеш.
                                                                                +1
                                                                                А потом на практике окажется что метод пузырьком будет быстрее на малом объеме данных, потому-что кеш.


                                                                                А потом окажется, что время, бездарно потраченное потраченное на множество оптимизаций до таких незначительных мелочей, превращает изначально коммерчески перспективный проект в убыточный.

                                                                                Вы уверены, что на нынешнем железе стоит тратить на это время?

                                                                                При том, что львиная затрата времени вашей программы идет вовсе не на сортировку в кэше или не в кэше, а на совсем иные вещи:

                                                                                Задержки по сети, задержки на диске, ожидание ввода пользователя.
                                                                                  +4

                                                                                  Не распространяйте свой опыт на всех остальных, не все пишут круды.

                                                                                    0
                                                                                    Вы уверены, что на нынешнем железе стоит тратить на это время?

                                                                                    Зависит. Когда я писал всякое HFT на плюсах, мы не то что думали, что там с кешем, а думали, в каком порядке условия ставить в некоторых функциях самописного вектора на не-более-чем-N-элементов.


                                                                                    Да, задержки по сети у нас были, но если мы отвечаем на событие за 500 наносекунд, а кто-то — за 450, то мы проиграли.

                                                                                      0
                                                                                      Ну так и вопросы тогда нужно задавать не про сортировки, а про то, как оптимизировать сеть, бд, итд.
                                                                                      +1
                                                                                      А потом окажется, что всё уже пооптимизировано за вас и в стандартной библиотеке при малых объёмах используется какая-нибудь сортировка вставками.
                                                                                        0
                                                                                        Может и такое быть, так и не нужно ничего оптимизировать предварительно не замерив и не зафиксровав факт наличия проблемы с производительностью.
                                                                                        0

                                                                                        Метод пузырьком нахрен не нужен, потому что Шелл лучше всегда

                                                                                          0

                                                                                          Нет, Шелл неустойчив, в отличие от.

                                                                                          +2

                                                                                          … а потом окажется, что 99% времени приложение проводит в IO, на ожидании сетевых/дисковых ресурсов. и эти микрооптимизации никому не впились, потому что один умник решил в цикле запрашивать базу/rest-сервис на каждый элемент.
                                                                                          зато про сортировку знал!

                                                                                            +1
                                                                                            Я согласен, поэтому и считаю, что если берешь на работу человека, где в основном нужно писать круды, то нужно и на собеседованиях спрашивать про работу сети, бд, инедексацию итд. Если же человек идет разрабатывать бд, то знать про сортировку полезно.
                                                                                              0

                                                                                              "Разрабатывать БД" обычно входит в "писать круды", редко бывает выделеный DBA или типа того.

                                                                                                0
                                                                                                Я согласен, поэтому и считаю, что если берешь на работу человека, где в основном нужно писать круды, то нужно и на собеседованиях спрашивать про работу сети, бд, инедексацию итд. Если же человек идет разрабатывать бд, то знать про сортировку полезно.


                                                                                                В наше время работа с СУБД встречается на каждом шагу.
                                                                                                Не нужно быть выделенным DBA чтобы тебя это коснулось.
                                                                                          +1
                                                                                          Может и к лучшему, что молодежь не знает про списки. Для небольшого набора данных лучше использовать массив, для большого — хеш-таблицы или деревья. Почти никогда за тридцатилетнюю практику не использовал списки.
                                                                                          +2

                                                                                          Да фиг с ним с самим списком. Что такое его обращение? Что такое его разворачивание или развёртывание? Операция обратная свёртке? Как это будет по-английски?

                                                                                            +3
                                                                                            single linked list reverse algorithm
                                                                                              +6

                                                                                              Ещё можно поиграться и попросить сформулировать определение разворота списка — каким условиям должен удовлетворять reverse(xs).

                                                                                                +4

                                                                                                I see what you did here! :)

                                                                                                  –5
                                                                                                  обычно и интервьер и интервьюируемый дорошат своим временем, и в такого рода игры не играют.
                                                                                                    +9

                                                                                                    А зря (настолько же зря, насколько «зря» неумение перевернуть список), потому что перед тем, как что-то делать, стоит понимать, что именно нужно сделать. Да и разговор это интересный, о формулировке ТЗ и контрпримерах, ИМХО куда интереснее, чем ещё один цикл или рекурсивную функцию написать.

                                                                                                      +1

                                                                                                      Не нужно думать, нужно — делать!)

                                                                                                    +1

                                                                                                    А какие тут могут быть разные формулировки?

                                                                                                      +1

                                                                                                      Ну вот я много лет был уверен, что разворот списка это что-то из функционального анализа, операция в чём-то обратная свёртке, например.

                                                                                                        +1

                                                                                                        Даже если высасывать из пальца, то это была бы "развёртка в список", а не "разворачивание списка".

                                                                                                          0

                                                                                                          Вопрос все равно не праздный. Люди которые проверяют разворот чуть надежнее чем тестом rev [1,2,3] == [3,2,1] требуют понимания, когда мы считаем что разворот успешно завершен. Формальный критерий.

                                                                                                            0

                                                                                                            Формальные критерии — это точно не про мейнстримные языки. Тут максимум — тесты. Впрочем, их писать тоже мало кто умеет. Вон, автор статьи даже не задаёт вопросов на эту тему.

                                                                                                              0
                                                                                                              просто не знаю, как об этом спрашивать без написания собственно тестов.

                                                                                                              но тестовые задания батхертят аудиторию еще сильнее, чем мой опросник :)

                                                                                                                0
                                                                                                                Как вы протестировали бы Х (например метод для деления целых чисел). Какие граничные случаи тут есть. Моки чем от стабов отличаются. Какие библиотеки для тестирования, для геренерации тестовых данных использовали. Ну вот в общем.
                                                                                                                +1

                                                                                                                Ну можно property test'ы написать, например. Это уже чуть ближе к требованию формальных критериев.

                                                                                                              0

                                                                                                              Я про свои ассоциации при чтении холиваров о "правильных" собесах и тестовых, где задача "развернуть/обратить/… список" регулярно упоминается. Звучит как задача из предметной области высшей математики, на уровне "эффективно отсортировать массив"

                                                                                                            0

                                                                                                            Предложите какой-нибудь, а мы и обсудим. А то вдруг вы предложите то же, что и я.

                                                                                                      +51
                                                                                                      Это игра, в которую могут играть двое.

                                                                                                      Интервьюерам выгодно придумывать чеклисты, нанимать по гороскопу и строить как можно более высокий барьер при собеседовании. Это экономит ресурсы компании и позволяет нанять каких-то кандидатов (не совсем обязательно лучших, но достаточно сервильных, чтобы впитать весь не имеющий отношения к самому труду инфомусор, который от них требуется усвоить). Опять же, можно прогнуть по зарплате, пользуясь тем что кандидат что-то не знает (а он гарантированно чего-то не знает).
                                                                                                      Работникам выгодно минимизировать затраты на собеседование и не хранить в голове знания, которые они не используют каждый день. Благодаря чрезвычайно мощным средствам поиска информации такое в наше время уже возможно: умение искать и адаптировать информацию может быть ценнее, чем хранение информации у себя в кэше.

                                                                                                      > Ну т.е. какая *реальная* польза от того, что чел будет знать, какая там хэш-функция используется?

                                                                                                      Я однажды заморочился и откопал типовой комплект ответов на вопросы по Java, залил себе в мозг эту мусорную инфу по хэш-таблицам и потом пугал ею интервьюеров на собеседованиях, которые спрашивали что такое hash index в MySQL. Думаю, они ожидали менее развёрнутый ответ, который и приличествовал программисту LAMP-стэка. Такие знания — это сила. Это мощь паровоза, который несётся по болотам, распугивая квакающих лягушек. Это булава интеллектуальной битвы, это боевой клич берсерка из драккара компьютерных наук, обожравшегося пшеницы со спорыньей и прочих некачественных продуктов.
                                                                                                      Практически неприменимо в быту, но вы же не станете требовать, чтобы руны образовывали вокруг голого торса огненный щит? Один покарает вас за такое желание облегчить свою участь инфоберсерка.
                                                                                                        –19
                                                                                                        можно прогнуть по зарплате — это хорошая шутка, смешная.
                                                                                                          +2
                                                                                                          Ну т.е. какая *реальная* польза от того, что чел будет знать, какая там хэш-функция используется?

                                                                                                          Менее 10%. А вот чистый код намного важнее. Но эти споры будут вечными. Интервьеверы хотят нанять богов программирования.
                                                                                                          Такие знания — это сила. Это мощь паровоза, который несётся по болотам, распугивая квакающих лягушек.

                                                                                                          Юмор отличный )))
                                                                                                            +1

                                                                                                            Интервьюверы часто просто не знают, что спрашивать. Вот и составляют "чеклисты", а потом делают оффер, тому кто, больше всех ответил, например 15 из 100, когда остальные 6-12

                                                                                                              0

                                                                                                              На самом деле нет. Тут нельзя посчитать сколько ответил из скольки. Это чеклист для спрашивающего, чтобы не забыть спросить эти темы. Это не вопросы — это темы. На собеседовании ты прощупываешь насколько хорошо человек знает рабочий инструмент.
                                                                                                              Если видишь, что он ответил, но сказал неуместное слово, то уточняешь, чтобы проверить что он оговорился, а не зазубрил и на самом деле не понимает. И т.д.

                                                                                                                0

                                                                                                                У разных людей/компаний разные подходы. Видел изнутри как именно так набирали. Да, одна из оценок, но чёткий выход в баллах от интервьювера плюс комментарий устный

                                                                                                                  0

                                                                                                                  У разных людей/компаний разные подходы. Видел изнутри как именно набирали. Никаких чеклистов и списка из 100 ответил 67.

                                                                                                            0
                                                                                                            Лучший комментарий :)
                                                                                                              0

                                                                                                              Хоть и согласен с комментарием, всё равно поспорю с аргументом про необходимость знать функцию хэширования по умолчанию конкретно в Java (в java.lang.Object) Это нужно знать, иначе рискуешь встретить коллегу, который вставит ключ в HashMap или элемент в HashSet, не переопределив hashCode(), и потом не может найти его снова. У меня такие коллеги были, как и те, кто пытался массив сделать ключом в HashMap.

                                                                                                                +1
                                                                                                                Ну это проблема Java и C#, которые почему-то решили что любой объект должен уметь хэшироваться, преобразовываться в строку (даже если это бесполезный неймспейс.класснейм) и т.п. Не думаю, что тут стоит сильно винить разработчиков.
                                                                                                                  0
                                                                                                                  Ну это проблема Java и C#

                                                                                                                  Чисто теоретически если порасуждать то убрать это из языка уже крайне тяжело.
                                                                                                                    0

                                                                                                                    Понятное дело, то что написано пером и попало в язык уже не вырубишь топором. Но рассуждать что это ошибка из разряда "One Billion Mistake" это не мешает. Даже если очевидно, что ничего особо поделать с ней уже не выйдет.

                                                                                                              +28
                                                                                                              Подобная задача это же абсолютно типичная задачка на кодинг почти в любом языке и любой человек, оценивающий это больше чем в 5 минут должен вызывать подозрения
                                                                                                              Ну не знаю. Например я односвязные списки в последний раз писал лет 10 назад, на Си. Разворот списка не писал ни разу в жизни, о такой задаче читал только в статьях о собеседованиях.

                                                                                                              Ну то есть у меня нет никаких сомнений, что я этот разворот напишу (когда мне расскажут что это именно значит). Но так сходу сказать, что напишу за 5 мин… За 5 мин. пишутся только вещи, которые «на кончике пера», которые используются постоянно. А на кой черт мне, простите, разворот односвязного списка? Ощущение, что эта задача показывает только то, что ты в клубе. Клубе любителей ходить по собеседованиям.

                                                                                                              upd. Проясню. Против самой задачи я ничего против не имею. В целом такие простые задачи неплохой способ отсеять совсем слабых программистов. Но требовать, чтобы их знали, держали в пальцах, да ещё допытывать время выполнения. Возможно я в чем-то не прав (я все-таки не лид и сам собеседования не проводил ещё), но мне это кажется сильно странным.
                                                                                                                0
                                                                                                                Идея была в том, что для данной задачи вообще ничего знать не нужно, кроме, собственно, определения списка (если с этим проблемы, то это *уже* значит, что задача достаточно показательна и полезна). Алгоритм соображается на пальцах за пару минут и быстренько пишется на том языке, на котором вы собеседуетесь. Естественно, при уточнениях возможны усложнения — тут проверку, там проверку, а тут вообще в хитром случае упасть может, но я считаю, что на обычном собесе это не суть критично, вы не Яндекс, где вам дают задачу, вы молча 10 минут кодите, потом так же молча собеседующий вам ответит «неверно» и сиди думай, что не так.

                                                                                                                И, в отличие от возможных способов построения хэш-таблиц, само знание о том, что есть такая структура — список и чем она отличается от массива и хэш-таблицы — это, на мой взгляд, обязательно знать каждому девелоперу. Не обязательно знать детали, можно загуглить. Но банальный факт, что операция «remove» в массиве будет занимать дольше, чем в хэш-таблице или что поиск элемента в списке будет долгим — это же из разряда знаний на подкорке, как можно писать что угодно сложнее хелловорлда без этого знания? Я так в коде нашего сеньора как-то увидел очевидно квадратичную конструкцию, где на каждой итерации довольно длинного цикла вызывался поиск по списку вместо того, чтобы сделать некий препроцессинг в хэш-таблицу сначала. Так и тут — если человек не понимает, какие вообще основные структуры есть (для реальной жизни достаточно знать три: массив, список, хэш-таблица) — к такому чуваку могут быть вопросы. У Гугла будут вопросы, если чувак не может хотя бы три вида самобалансирующихся деревьев назвать, но вы не гугл, достаточно базы. А базу стыдно не знать имхо.

                                                                                                                Это не задача на графы, не задача на хитрые алгоритмы, не задача на что-то, что нельзя сообразить на пальцах. Это как fizzbuzz, я не знаю. Вы же не будете говорить, что на физзбазз вам нужно больше 5 минут?
                                                                                                                  0

                                                                                                                  Нужно ещё знать, что такое "развернуть", "обратить" и прочее что в голове у постановщика. Вот из всех этих собеседеных холиварах я вынес просписки, что есть набор каких-то "магических" операций над списками типа функции свёртки, но более сложное. И при просьбе оценит время написания функции разворачивания списка я б сказал что-то вроде "минимум час на гугление рисёч и минимум час на реализацию — очень оптимистичная оценка, я матан совсем не помню"

                                                                                                                    0
                                                                                                                    банальный факт, что операция «remove» в массиве будет занимать дольше, чем в хэш-таблице или что поиск элемента в списке будет долгим

                                                                                                                    Не факт, всё это зависит от реализации и контекста использования.

                                                                                                                      +1
                                                                                                                      Но банальный факт, что операция «remove» в массиве будет занимать дольше, чем в хэш-таблице или что поиск элемента в списке будет долгим

                                                                                                                      Но ведь если брать в общем, то это не так. Удаление последнего элемента
                                                                                                                      в массиве точно быстрее удаления в сложной структуре, нужно же всего лишь размер на единицу уменьшить. И скорее всего удаление нескольких последних элементов тоже может быть быстрее чем удаление в хэш таблице, хотя за счет кэшей процессора.


                                                                                                                      Ну и например если массив небольшой, то поиск в нем вполне может быть быстрее,
                                                                                                                      конечно все зависит еще от типов данных в массиве и хэш-таблице.

                                                                                                                      0

                                                                                                                      зависит от языка же. Например я не писал разваороты на хаскелле, но могу написать его думаю секунд за 30


                                                                                                                      rev :: [a] -> [a]
                                                                                                                      rev [] = []
                                                                                                                      rev (x : xs) = rev xs ++ [x]

                                                                                                                      затем можно заметить что он неоптимален (аллоцирует много) и заменить на аккумулятор который работает по принципу стека, на которорый уже пара минут нужна (проверить правильность рекурсии):


                                                                                                                      rev :: [a] -> [a]
                                                                                                                      rev = revInner [] where
                                                                                                                        revInner acc [] = acc
                                                                                                                        revInner acc (x : xs) = revInner (x : acc) xs 

                                                                                                                      Как мне кажется, достсаточно простой вопрос, чуть сложнее fizzbuzz. С другой стороны, ни разу не писал функции разворота списка на практике. Самое близкое — stateful fmap.

                                                                                                                        +1
                                                                                                                        Я так понимаю на хаскеле проблема вообще теряет свой смысл. Важное свойство списков — при добавлении / удаления из него элемента, указатели (в широком смысле) на другие элементы продолжают указывать на те же данные. Я мало знаком с хаскелем, но кажется, что такая абстракция в него не вписывается. У вас же написан скорее разворот массива.
                                                                                                                          +1

                                                                                                                          С чего бы это? Вот определение списка:


                                                                                                                          data List a = [] | (a :: List a)

                                                                                                                          Это не очень похоже на массив, зато очень похоже на список. Чем и является. Не дайте себя запутать тем, что для списков в хаскелле используются квадратные скобочки.


                                                                                                                          Ну а персистентные структуры возможны везде, в том же компиляторе сишарпа везде используются исключительно персистентные массивы/списки/..., никаких изменяемых. Потому что перфоманс нужен.

                                                                                                                            +1
                                                                                                                            Не буду спорить, все-таки в хаскеле я не силен =)
                                                                                                                              0

                                                                                                                              Ну, тут всё просто. data обозначает АДТ, то есть тип-сумму, то есть энум на который можно дополнительные данные прицепить. Соответственно список либо является [] (он же Nil, он же пустой список), либо (::) (он же Cons) состоящий из элемента типа a и хвоста. Варианты удобно перечисляются через |.


                                                                                                                              Сначала немного непривычно, что конструктор это не слово а какой-нибудь оператор (например :: вместо Cons), но потом начинаешь ценить подобное удобство. Если не ударяться в крайности, то читаемость ощутимо выигрывает.

                                                                                                                              0
                                                                                                                              С чего бы это? Вот определение списка:

                                                                                                                              Ну вся соль задачи что аллокаций памяти в куче не производится,
                                                                                                                              и используется O(1) доп. памяти. Такое возможно реализовать на хаскелле?

                                                                                                                                0

                                                                                                                                Ну если вы старой версией не пользуетесь то компилято вполне вероятно соптимизирует это в мутабельную игру указателями. Но если пользуетесь, то без доп. памяти офк никак. Реверс в данном случае это List Reverse(List) а не void Reverse(List). С ситуацией когда оптимизатор может вернуть аргумент в качестве результата.

                                                                                                                                  0
                                                                                                                                  Такое возможно реализовать на хаскелле?

                                                                                                                                  Такое тоже можно (и в явном виде), но вам не понравится. А компилятор версию выше вполне может свернуть (и сворачивает) в O(1) по памяти и без лишних аллокаций — я ниже пример вчера приводил, и там получается такой дизасм, в котором аллокаций я не нашёл, даже когда ещё сегодня посмотрел на него свежими глазами.

                                                                                                                          +1
                                                                                                                          А считать первый ответ «хэш-таблица» неправильным на вопрос «Как устроен тип map» — ну, такое.

                                                                                                                          Ну вообще вопрос понятен и такой ответ говорит о том, что человек не знает, что там под капотом. Почему это важно? Наводящий вопрос: map[int]TStruct или map[int]*TStruct? Почему? В если их миллион? Почему? Правильного ответа нет. Но выбрать без понимания — ударить себя лопатой (я самоударенный, я туповат и учусь прыгая с разбегу на грабли)

                                                                                                                            +1

                                                                                                                            Для питон разработчиков я обычно задавал вопрос "допустим мы храним телефоны как строки (а если это плохо, то как раз можно объяснить, почему), причем храним только телефоны 8-800 и 8-499. Лучше использовать хэшмап или массив, и почему тот или иной вариант".

                                                                                                                              0

                                                                                                                              Опечатался, имел в виду "телефоны как числа" наоборот, в противовес обычному "как строки".

                                                                                                                                0

                                                                                                                                Для хранения лучше массив — меньше памяти займёт. А других задач не обозначено :)

                                                                                                                                  0

                                                                                                                                  Если хранить как массив то диапазон от 0 до 8-800 будут содержать нуллы. Не очень-то хорошо получается.

                                                                                                                                    +1

                                                                                                                                    В смысле? Как-то непонятна задача. для меня хранить телефоны в массиве значит:


                                                                                                                                    [
                                                                                                                                    88001234567,
                                                                                                                                    88007654321,
                                                                                                                                    84991234567,
                                                                                                                                    84997654321,
                                                                                                                                    ]

                                                                                                                                    какие нуллы в каком диапазоне?

                                                                                                                                      0

                                                                                                                                      Сори, я на память задачу вспоминал, криво назвал. См. ниже, суть в том, чтобы хранить список номер телефона-имя пользователя, и иметь О(1) доступ к этому самому имени. То есть


                                                                                                                                      phones = [...., "VolCh", "PsyHaSTe", ....]
                                                                                                                                      volchPhone = phones[88001234567]
                                                                                                                                      psyPhone = phones[88001234568]

                                                                                                                                      В изначальной формулировке офк этого косяка нет, это я когда по памяти писал выше неправильно вспомнил точную постановку.

                                                                                                                                        0

                                                                                                                                        Теперь понятно. В такой постановке классический массив сложно представить когда оптимальным выбором будет, а реализациях разряженных в которые вникал под капотом хэшмапа была и на этих языках классических массивов толком и нет в принципе.

                                                                                                                                          0

                                                                                                                                          Собственно я не просил про разреженные массивы ничего знать, ответ в принципе должен показать, понимает ли человек если не внутреннюю структуру базовых типов, то хотя бы их ключевые характеристики.

                                                                                                                                  +1

                                                                                                                                  чисто любопытства ради.


                                                                                                                                  • хранится список номеров телефонов или номер телефона это ключ к записи? в чём вообще суть задачи?
                                                                                                                                  • "хэшмап или массив" если бы мне на собесе про питон упомянули что-то такое, я бы сказал "пардон, я кажется ошибся адресом", развернулся и ушёл. Как бы есть словарь и список (ну может быть дикт и лист), но хешмап и массив, это какие-то дельфи или я не знаю. Если человек не использует привычную терминологию, что-то значит не то в конторе.
                                                                                                                                    +1
                                                                                                                                    хранится список номеров телефонов или номер телефона это ключ к записи? в чём вообще суть задачи?

                                                                                                                                    Суть задачи — как лучше хранить привязку номер телефона — имя пользователя. Или Map<Int, String> или просто String[]


                                                                                                                                    "хэшмап или массив" если бы мне на собесе про питон упомянули что-то такое, я бы сказал "пардон, я кажется ошибся адресом", развернулся и ушёл. Как бы есть словарь и список (ну может быть дикт и лист), но хешмап и массив, это какие-то дельфи или я не знаю. Если человек не использует привычную терминологию, что-то значит не то в конторе.

                                                                                                                                    Ну если вы не знаете что такое хэшмап то наверное действительно стоит развернуться и уйти. Если вопрос "хэшмапа… В смысле дикт?" То можно просто получить утвердительный ответ и пойти дальше. Знакомые программисты вообще в одном предложении могут использовать оба термина, все же понимают, что речь об одном и том же. "Какие-то дельфи" — да нет, ваще-то почти во всех языках принято так называть. Кругозор "знаю больше 1 языка" тоже приветствуется и является бонусом.

                                                                                                                                      0
                                                                                                                                      "Какие-то дельфи" — да нет, ваще-то почти во всех языках принято так называть

                                                                                                                                      Скажем так, во многих языках они так называются, если называются явно, хотя могут быть нюансы. Вон вы же пишите Map<Int, String>, а не HashMap<Int, String> :)

                                                                                                                                        +1
                                                                                                                                        Суть задачи — как лучше хранить привязку номер телефона — имя пользователя. Или Map<Int, String> или просто String[]

                                                                                                                                        очевидно зависит от того — какие операции потом будут производиться? Например, поиск имени по номеру телефона (строим какой-нибудь АОН) или наоборот — по ФИО ищем телефон (как в какой-нибудь адресной базе)

                                                                                                                                          –3
                                                                                                                                          Суть задачи — как лучше хранить привязку номер телефона — имя пользователя. Или Map<Int, String> или просто String[]

                                                                                                                                          тогда не очень понятно, в чём заключается доп.условие что номера только 8-800 и 8-499. Если мы храним номер как 10-значный int, то это одно. Если мы храним его как 7-значный инт плюс префикс 800/499 (может быть и бред, но мало ли кому что в голову взбредёт) то одним интом не отделаешься.


                                                                                                                                          если вы не знаете что такое хэшмап

                                                                                                                                          я знаю, что такое хэшмап. Но если вы называете тип данных dict хэшмапом, то я очень сомневаюсь, что вы знаете, где вы находитесь. Если вы используете in для проверки наличия ключа в питоновском дикте так:


                                                                                                                                          if "x" in the_dict.keys()

                                                                                                                                          то да, так можно делать. Но если вы мне предлагаете должность сеньора и при этом утверждаете, что так правильно делать, то извините.


                                                                                                                                          Map<Int, String> или просто String[]

                                                                                                                                          вот о чём я и говорил, к питону это не имеет никакого отношения.


                                                                                                                                          "Какие-то дельфи" — да нет, ваще-то почти во всех языках принято так называть.

                                                                                                                                          если вы считаете, что жавовская термонология уместна во всех языках, я не думаю, что мне с вами по пути, потому что в таком случае с вероятностью 100% вы будете использовать и другие жавовские приёмы. Если вы пишете на жаве, пишите на жаве. Не надо писать жавовскими идиомами ни на питоне ни на дельфях. Вы же не говорите по-английски, используя дословный перевод с русского.


                                                                                                                                          Так вот, в питоне нет типа данных "хэшмап". И если вы имеете в виду дикт, то я развернусь и уйду. Если же это какой-то самописный class HashMap, то возможно ещё подумаю, хотя необходимость такого в питоне сомнительна.


                                                                                                                                          Кругозор "знаю больше 1 языка" тоже приветствуется и является бонусом.

                                                                                                                                          Я знаю довольно много языков, как ЯП, так и человеческих. И именно поэтому, для меня важна точность терминологии. Называть хэшмапом дикт в питоне, это то же самое, что называть машину в английском "machine". Да, формально "car" и "auto" это тоже machine, но люди так не говорят. Просто сразу видно, что вы не местный. Ничего личного, но если вы при этом работаете в фирме переводов, то досвидос. Так же и со словарями и списками в питоне. Ничего личного, я уважаю Жаву как язык. Но работаю на питоне.

                                                                                                                                            +1
                                                                                                                                            тогда не очень понятно, в чём заключается доп.условие что номера только 8-800 и 8-499. Если мы храним номер как 10-значный int, то это одно. Если мы храним его как 7-значный инт плюс префикс 800/499 (может быть и бред, но мало ли кому что в голову взбредёт) то одним интом не отделаешься.

                                                                                                                                            Храним как 10-значный инт


                                                                                                                                            я знаю, что такое хэшмап. Но если вы называете тип данных dict хэшмапом, то я очень сомневаюсь, что вы знаете, где вы находитесь.

                                                                                                                                            Не понимаю, почему это должно кого-то смущать. Если знаете > 1 языка то точно проблем никаких не будет. Если не знаете — не беда, переформулирую.


                                                                                                                                            Если вы используете in для проверки наличия ключа в питоновском дикте так:

                                                                                                                                            if "x" in the_dict.keys()ё

                                                                                                                                            то да, так можно делать. Но если вы мне предлагаете должность сеньора и при этом утверждаете, что так правильно делать, то извините.

                                                                                                                                            Я никакой x in dict.keys() нигде даже близко не писал. Вы точно на тот комментарий отвечаете?


                                                                                                                                            вот о чём я и говорил, к питону это не имеет никакого отношения.

                                                                                                                                            Конкретно к питону офк не имеет, но обычно срашиваю на япе который собеседуемый знает.


                                                                                                                                            если вы считаете, что жавовская термонология уместна во всех языках, я не думаю, что мне с вами по пути, потому что в таком случае с вероятностью 100% вы будете использовать и другие жавовские приёмы. Если вы пишете на жаве, пишите на жаве. Не надо писать жавовскими идиомами ни на питоне ни на дельфях.

                                                                                                                                            Логика уровня /b/. Впрочем, склонен согласиться, что не по пути))


                                                                                                                                            Вы же не говорите по-английски, используя дословный перевод с русского.

                                                                                                                                            Конечно говорю. Трейт, тайпкласс, имплементировать, инвестигейт, багтрекер,… Как и большинство коллег, с которыми общаюсь.


                                                                                                                                            Я знаю довольно много языков, как ЯП, так и человеческих. И именно поэтому, для меня важна точность терминологии. Называть хэшмапом дикт в питоне, это то же самое, что называть машину в английском "machine". Да, формально "car" и "auto" это тоже machine, но люди так не говорят. Просто сразу видно, что вы не местный. Ничего личного, но если вы при этом работаете в фирме переводов, то досвидос. Так же и со словарями и списками в питоне. Ничего личного, я уважаю Жаву как язык. Но работаю на питоне.

                                                                                                                                            Ну значит вы "питон разработчик". Ничего личного, но в моей личной системе координат это уровень ниже нежели просто "разработчик", наравне с "сишарп разработчик", "раст разработчик" и так далее.

                                                                                                                                              0
                                                                                                                                              Я никакой x in dict.keys() нигде даже близко не писал

                                                                                                                                              а что, примеры уже нельзя приводить? :) я просто хочу показать, что идиомы из одних мест они не всегда уместны в других.


                                                                                                                                              Логика уровня /b/.

                                                                                                                                              скажите, что не так в этой логике. Иначе, это выглядит как логика уровня 0. Я хотя бы аргументировал, вы же просто ляпнули.


                                                                                                                                              Вы же не говорите по-английски, используя дословный перевод с русского.
                                                                                                                                              Конечно говорю. Трейт, тайпкласс, имплементировать, инвестигейт, багтрекер

                                                                                                                                              пардон вы ошиблись — во-первых, здесь нет перевода. Трейт — это англоязычный термин, который не переведён, а взят как есть, перевод был бы "особенность", "черта". Во-вторых, это общепринятая практика, например слово "танк" это тоже заимствование из английского, без перевода (перевод — "бочка"). Впрочем, кому я объясняю, вы это и сам прекрасно знаете. И либо вы понимаете ошибку в вашей логике и намеренно её делаете, либо не понимаете, тогда увы о чём разговор про логику уровня /b/.


                                                                                                                                              Ну значит вы "питон разработчик".

                                                                                                                                              Да, когда работаешь на питоне, наиболее эффективно работать используя подходы, принятые в питоне. Пиша на Жаве — подходы, принятые в Жаве. Если вы считаете, что на всех языках одинаковые идиомы одинаково эффективны, вы не "просто разработчик", а просто не разработчик. (Не имея в виду лично вас.)


                                                                                                                                              Я не хочу вас оскорблять, я вас не знаю, вы меня не знаете. Кто и что в вашей системе координат на каком уровне, меня также не оскорбляет. Я просто указываю вам на те вещи, в которых, на мой взгляд, вы ошибаетесь. А уж как вам к этому относиться, я на это никак повлиять не могу.

                                                                                                                                                0
                                                                                                                                                а что, примеры уже нельзя приводить? :) я просто хочу показать, что идиомы из одних мест они не всегда уместны в других.

                                                                                                                                                И откуда эта идиома?


                                                                                                                                                скажите, что не так в этой логике. Иначе, это выглядит как логика уровня 0. Я хотя бы аргументировал, вы же просто ляпнули.

                                                                                                                                                Если я использую распространенную терминологию это не значит что я на питоне пишу как на джаве. Я на каждом языке собственно пишу так, как в нем принято. В чужой монастырь, как говорится.


                                                                                                                                                пардон вы ошиблись — во-первых, здесь нет перевода. Трейт — это англоязычный термин, который не переведён, а взят как есть, перевод был бы "особенность", "черта". Во-вторых, это общепринятая практика, например слово "танк" это тоже заимствование из английского, без перевода (перевод — "бочка"). Впрочем, кому я объясняю, вы это и сам прекрасно знаете. И либо вы понимаете ошибку в вашей логике и намеренно её делаете, либо не понимаете, тогда увы о чём разговор про логику уровня /b/.

                                                                                                                                                А "хэшмап" — это перевод какого слова?


                                                                                                                                                Да, когда работаешь на питоне, наиболее эффективно работать используя подходы, принятые в питоне. Пиша на Жаве — подходы, принятые в Жаве. Если вы считаете, что на всех языках одинаковые идиомы одинаково эффективны, вы не "просто разработчик", а просто не разработчик. (Не имея в виду лично вас.)

                                                                                                                                                Но есть общие вещи. Например "хэшмап" реализован +- одинаково и в питоне, и в жабе, и в расте, и где угодно ещё. От того что где-то его называют "словарём" (как в моем основном сишарпе, к примеру) ничего не меняет. А если вы так прикипели к конкретной терминологии, это как раз скорее для меня сигнал про неготовность к развитию. Для человека по-хорошему должно быть неважно даже на каком языке писать, не то, что какими синонимами описывать происходящее в ней.

                                                                                                                                                  0
                                                                                                                                                  И откуда эта идиома?

                                                                                                                                                  да, подумав, пожалуй не в тему =)


                                                                                                                                                  Если я использую распространенную терминологию

                                                                                                                                                  я не соглашусь, что она распространённая. Конкретно HashMap, Array — типы данных из Жавы. Честно, за 11 лет работы ни разу не слышал слова "хэшмап" в контексте питона. Map, Mapping может быть ещё более-менее, хотя в первом случае путается с функцией map(), а во втором — с collections.abc.Mapping. Конечно, я пойму, о чём идёт речь, если кто вдруг выскажется, но всё-таки предпочитаю называть лопату лопатой (call a spade a spade) :)


                                                                                                                                                  С другой стороны YMMV — я не работал везде, и сказать что никто не использует слова "хэшмап" вместо дикта/словаря и "массив" (прям-таки Pascal :)) вместо листа/списка, тоже не могу.


                                                                                                                                                  В чужой монастырь, как говорится.

                                                                                                                                                  вот и я о том же, просто терминология для меня показатель. На чём пишешь, так и говоришь ...


                                                                                                                                                  А "хэшмап" — это перевод какого слова?

                                                                                                                                                  HashMap как тип в Жаве соответствует dict как типу в питоне. Т.е. перевод HashMap на язык питона — dict. :) В примере с языками я всего лишь хотел подчеркнуть, что если речь идёт о питоне, то пользоваться стоит питоновскими терминами.


                                                                                                                                                  От того что где-то его называют "словарём" (как в моем основном сишарпе, к примеру) ничего не меняет

                                                                                                                                                  Окей, обратный пример. Я прихожу на собеседование Java Senior Dev и говорю, если ключик в словаре ("in") is None..., или напишем лямбда функцию возвращающую списочек ...


                                                                                                                                                  Есть ли вероятность, что я бы прошёл собеседование дальше этих фраз? Даже если я бы мог написать код на жаве правильно, это всё равно выдаёт человека, которому Жава не настолько близка, чтобы он выражался принятой в ней терминологией. Ибо поработав с языком -дцать лет, ты уже не думаешь, что в теории дикт и хэшмап это одно и то же, а говоришь то, что видишь чаще всего. С другой стороны, мне вряд ли вообще пришло бы в голову назвать java.util.HashMap диктом — просто потому, что он называется HashMap, а дикт, это вроде вполне конкретный тип в питоне...


                                                                                                                                                  Хотя возможно я и переоцениваю влияние языка (ЯП) на язык (которым выражаешься) и обратно.

                                                                                                                                                    0
                                                                                                                                                    я не соглашусь, что она распространённая. Конкретно HashMap, Array — типы данных из Жавы.

                                                                                                                                                    А ещё из хаскеля. И из С++. И из раста. И из котлина. И из дарта. И из ...


                                                                                                                                                    Почему сразу считаете, что это "тип из джавы"?


                                                                                                                                                    Окей, обратный пример. Я прихожу на собеседование Java Senior Dev и говорю, если ключик в словаре ("in") is None..., или напишем лямбда функцию возвращающую списочек ...

                                                                                                                                                    Ну и нормально, говорите :)


                                                                                                                                                    Хотя возможно я и переоцениваю влияние языка (ЯП) на язык (которым выражаешься) и обратно.

                                                                                                                                                    Вот. Именно это я и хотел донести.

                                                                                                                                                    +3

                                                                                                                                                    Я не уверен, о чём тут дискуссия, но при прочих равных я бы предпочёл термины «хешмапа» и «tree map» — у них разные характеристики сложности, разные требования к данным и разные юзкейсы. А дикт… Ну словарь можно и поверх обычного массива сделать (и так иногда даже делают в некоторых приложениях).

                                                                                                                                            –5
                                                                                                                                            . хранится список номеров телефонов или номер телефона это ключ к записи? в чём вообще суть задачи?



                                                                                                                                            Оооо. Дружище, задав такой вопрос вы вот прям вот без штанов вот вышли в публичное место. Прям вот камиинг аут

                                                                                                                                      0

                                                                                                                                      Было похожее собеседование недавно на senior php.


                                                                                                                                      • паттерны проектирования знаем? — нет
                                                                                                                                      • explain в sql для чего нужен? — не знаю
                                                                                                                                      • какие виды архитектуры знаем? — не силен в теории
                                                                                                                                      • как работает DI? — человек плавает, говорит какую-то чушь про service provider
                                                                                                                                      • как с docker? — никак использую vagrant
                                                                                                                                      • с *nix как? — только основы

                                                                                                                                      После чего у человека уточняют на какую сумму он рассчитывает и он называет медиану по рынку для сеньора…
                                                                                                                                      На что спрашивается рассчитывал ?


                                                                                                                                      В php в этом вообще печаль-беда — куча web мастеров с портфолио на 50+ проектов на готовых движках, но задашь что-нибудь не стандартное и все человек выпучил глаза и тупит. Я лучше еще одного junior возьму и буду обучать...

                                                                                                                                        –1
                                                                                                                                        Вот я всё это знаю, а толку, код писать не помогает…
                                                                                                                                          +4
                                                                                                                                          Давайте только без сказок, как вы возьмете джуна и будете всему этому обучать ))) В реальности и на позицию джуна вы озвучите те же вопросы, ну может за исключением парочки из них и не услышав внятного ответа, пошлете и джуна лесом. Реалии рынка таковы, что джунов сейчас хотят по зарплате, а по требованиям это далеко не так. Часто читаю вакансии и возникает вопрос — ребята, а речь точно о джуне? Ведь по мнению сегодняшних работодателей джун должен уже все знать и уметь, но просто стоить куда дешевле человека с опытом. Я бы сам рад куда-нибудь джуном пойти. Размер зарплаты при этом не важен, пусть он будет минимальным, чтобы с голода не помереть ))) Но нет, никому такие джуны не нужны. Никому не интересно никого учить. Надо, чтобы человек пришел и просто начал работать.
                                                                                                                                          Не так давно отправил запрос на вакансию с зарплатой 15 или 17 тысяч, не помню уже. Ну просто предполагая, что за такие деньги можно вообще ничего не знать, но начать получать какой-то опыт. Но нет, даже похоже там нужен готовый специалист ))) Вот только интересно, где они найдут такого на такую ЗП.