Две Проблемы Для Собеседований С Разработчиками

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

Этот процесс довольно утомительный, потому что.

Программисты — люди смелые, творческие, любознательные и целеустремленные.

В моей практике возникали разного рода вопросы.

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



Испытания на изобретательность

Вы стоите на крутой горе высотой 100 метров.

У вас есть веревка длиной 80 метров.

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

Как спуститься? Были люди, которые уже знали ответ, но делали вид, что глубоко задумались, и тут, о чудо! породило решение.

Многие честно не справились с задачей.

Но это всё равно было своего рода вводное задание.

Потом я пересмотрел свою точку зрения и отказался от подобных задач.

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



Знание технологий

Второй тип вопросов, которые я задавал, был связан со знанием инструментов, механизмов, технологий, например:
  1. Объясните, что такое инкапсуляция.

  2. Как вызвать функцию на Java из библиотеки DLL, написанной на C++.

  3. Каковы недостатки MS SQL Server и MySQL? В чем их принципиальная разница?
Со временем я тоже отказался от этих вопросов.

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

Да, инкапсуляция — важный инструмент ООП, но если программист всю жизнь писал без ООП, разве он теперь плох? Ему это просто было не нужно.

Зато он может сразу написать эффективный алгоритм сжатия строк или какой-нибудь драйвер.

Про холивары между разными СУБД вообще молчу; всегда можно открыть документацию, форумы и прочитать что и как.

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

Если вы ни разу не вызывали функцию из dll, это не повод не брать вас на работу и никоим образом не характеризует вас как умного или глупого.

Посмотрите, как это делают другие, и у вас все получится.



Практические проблемы

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

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

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

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

Во-вторых, чтобы не было претензий, мол, я там что-то для тебя сделал, ты меня не нанял, а потом ты использовал мой труд себе.

Для этого я показал готовое рабочее приложение, в котором эта функция уже реализована.

Все честно и прозрачно.

И напоследок, если вам интересно попробовать свои силы, как будто вы вдруг попали на те самые собеседования, вот вам две проблемы.



Первая проблема
Есть две таблицы русских слов_1 и слов_2 с полями (слово как VARCHAR, ref как INT), где word - это слово, ref - ссылка (числовой код) на какую-то другую (не важную) таблицу, где все определения этих слова указаны.

В каждой таблице все слова уникальны (без повторов).

В первой таблице есть слова, которых нет во второй, и наоборот, во второй таблице есть слова, которых нет в первой, но большинство слов в обеих таблицах одинаковы.

Вам необходимо получить единую таблицу со всеми словами и соответствующими им ссылками.

Начальные условия/трудности:

  1. Для одних и тех же слов ссылки в разных таблицах могут быть разными, поскольку словари скачивались из разных мест;
  2. количество слов в каждой таблице - сотни тысяч, т.е.

    алгоритм лобового сравнения подходит не всем, ведь 100 тысяч х 100 тысяч дадут как минимум 10 миллиардов сравнений;

  3. если вы разработчик баз данных, то задачу нужно делать на sql.
Исходные таблицы: слова_1 абажур - 1 кинотеатр - 2 самолет - 3 человек – 4 слова_2 кинотеатр - 15 музыка - 16 самолет - 17 Итоговая таблица на основе первой таблицы: all_words_1 абажур - 1 кинотеатр - 2 музыка - 16 самолет - 3 человек – 4 Итоговая таблица на основе второй таблицы: all_words_2 абажур - 1 кинотеатр - 15 музыка - 16 самолет - 17 человек – 4

Вторая проблема
Есть таблица defs с полями (def как ТЕКСТ, ref как INT), где def — определение слова, ref — ссылка (числовой код) на само слово из какой-то другой таблицы (не важно).

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

Начальные условия/трудности:

  1. определения могут быть довольно длинными, несколько тысяч символов;
  2. количество записей в таблице несколько миллионов, если как-то тупо сравнивать между собой полнотекстовые записи, то сервер прогнется;
  3. если вы разработчик баз данных, то задачу нужно делать на sql.
Исходная таблица: ссылки животное с большими ушами – 1 животное с большими ушами и длинным носом — 1 крупное животное с длинным носом - 1 маленькое пушистое животное - 2 маленький пушистый зверек, который грызет орехи – 2 (Обратите внимание: 1 — слон, 2 — белка.

) Итоговая таблица: Clear_refs животное с большими ушами и длинным носом — 1 крупное животное с длинным носом - 1 маленький пушистый зверек, который грызет орехи – 2 Что-то вроде того.

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

Теги: #задача #интервью #вопросы #программирование #sql #Алгоритмы

Вместе с данным постом часто просматривают: