Экстраполяция IT

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

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

И тут есть несколько правил.

1. У задачи должно быть больше одного решения. Даже самый умный человек в мире не всегда приходит к решению за короткое время. А если решение всего одно, то ответ «решил/не решил» выдаёт очень много ложноотрицательных результатов. Ещё лучше, если задачу можно решить достаточно большим количеством способов, чтобы сформировать градиент качества решений. Чтобы хоть как-то можно было бы сравнить два разных решения.

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

3. Задача должна быть максимально абстрактна. Это менее очевидно, но тестовые задачи, сформулированные на языке рабочих задач начинают решаться не тестовым способом, а рабочим. «Перебрать юзеров, чтобы отсеять лишних» с помощью чистых алгоритмов пытливым и ленивым мозгом очень быстро решается парочкой запросов в базу данных, а вот «найти числа из последовательности, удовлетворяющие условию» уже достаточно абстрактна, чтобы рефлексы не тянулись к SQL.

4. Ничего другого, кроме пытливости ума такой тип задач проверить не в состоянии. Не надо искать подтекстов и проверять что-то ещё. Решения одной задачи не достаточно, чтобы определить насколько хорошо испытуемый пишет тесты, задаёт вопросы, называет переменные или что-то там ещё. Тем более если добавить к этому лёгкое ощущение экзамена или собеседования. Сейчас такие задачи стали чем-то вроде культа Карго и перешли совершенно в другую категорию собеседований. Проверяют скорость написания кода, оптимальность решения, чистоту кода и написание, простигосподи, тестов. Это настолько же тупо, как отсеивать козерогов и водолеев на основании совместимости гороскопов.

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

Дано: массив случайных натуральных чисел X в случайном порядке, среди которых могут быть дубликаты. И целое число C.
Вопрос: может ли число C быть сформировано суммой двух элементов массива? Другими словами, существуют ли такие i, j, что X[i] + X[j] == C?
Ответ нужно только true или false, сами числа знать не обязательно.
Если захотите вдруг решить эту задачу — вот вам специальных гист, чтобы проверить решение.

www.tgoop.com/itextrapolation/493

1.7K viewsSep 20, 2021 at 08:01

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

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

И тут есть несколько правил.

1. У задачи должно быть больше одного решения. Даже самый умный человек в мире не всегда приходит к решению за короткое время. А если решение всего одно, то ответ «решил/не решил» выдаёт очень много ложноотрицательных результатов. Ещё лучше, если задачу можно решить достаточно большим количеством способов, чтобы сформировать градиент качества решений. Чтобы хоть как-то можно было бы сравнить два разных решения.

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

3. Задача должна быть максимально абстрактна. Это менее очевидно, но тестовые задачи, сформулированные на языке рабочих задач начинают решаться не тестовым способом, а рабочим. «Перебрать юзеров, чтобы отсеять лишних» с помощью чистых алгоритмов пытливым и ленивым мозгом очень быстро решается парочкой запросов в базу данных, а вот «найти числа из последовательности, удовлетворяющие условию» уже достаточно абстрактна, чтобы рефлексы не тянулись к SQL.

4. Ничего другого, кроме пытливости ума такой тип задач проверить не в состоянии. Не надо искать подтекстов и проверять что-то ещё. Решения одной задачи не достаточно, чтобы определить насколько хорошо испытуемый пишет тесты, задаёт вопросы, называет переменные или что-то там ещё. Тем более если добавить к этому лёгкое ощущение экзамена или собеседования. Сейчас такие задачи стали чем-то вроде культа Карго и перешли совершенно в другую категорию собеседований. Проверяют скорость написания кода, оптимальность решения, чистоту кода и написание, простигосподи, тестов. Это настолько же тупо, как отсеивать козерогов и водолеев на основании совместимости гороскопов.

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

Дано: массив случайных натуральных чисел X в случайном порядке, среди которых могут быть дубликаты. И целое число C.
Вопрос: может ли число C быть сформировано суммой двух элементов массива? Другими словами, существуют ли такие i, j, что X[i] + X[j] == C?
Ответ нужно только true или false, сами числа знать не обязательно.
Если захотите вдруг решить эту задачу — вот вам специальных гист, чтобы проверить решение.

BY Экстраполяция IT