69

Собеседования

Недавно мне нужно было найти себе в команду middle backend разработчика. Я провёл собеседования с двумя десятками человек и сказать, что я в ахуе - это ничего не сказать. Контора у нас софтверная, поэтому есть во-первых свои люди, которые сидят в ожидании проектов (на так называемом бенче), а во-вторых, которые у нас сейчас не работают, но с ними уже поговорил HR и направил на техническое собеседование. То есть у первых мидл вроде как подтверждённый, а вторые
заявляют, что на него претендуют.
Я в курсе, что сейчас уровень упал, поэтому решил не упарываться и не валить какими-то хитровыделанными вопросами. Был буквально один вопрос что такое SOLID, пару вопросов по специфике языка, пару вопросов по базам (что такое индексы). И небольшое тестовое задание: реализовать метод для подсчёта рабочих дней между двумя заданными датами.
Итог:
- никто не ответил ни на один вопрос по базам.
- никто не рассказал про SOLID в лучшем случае помнят что такое S.
- язык половина не знает и не понимает.
- тестовое задание "сделали" 2 из 20. Хоть в каком-то примерно работающем виде. Двое отказались даже начинать, когда узнали, что нужно делать в браузере и без гугления.
Я ещё могу понять, что со стороны может приходить кто угодно, но блин там половина была наших, которые имеют этот уровень и получают соответствующую зарплату.

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

Лига программистов

2.1K постов11.9K подписчиков

Правила сообщества

- Будьте взаимовежливы, аргументируйте критику

- Приветствуются любые посты по тематике программирования

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

Вы смотрите срез комментариев. Показать все
21
Автор поста оценил этот комментарий

Конечно разумно искать толкового. Но как на собеседовании найти ту грань? Понятно что мы изучаем хитрые алгоритмы. Но вот положа руку на сердце, скажите как часто на практике вы используете например алгоритм Грима для поиска по графу? Ну или сортировку пирамидальную?

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

раскрыть ветку (18)
4
Автор поста оценил этот комментарий

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

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

Параметры надо валидировать до вызова метода, за редким исключением, вроде проверки деления на 0. Если же метод теоретически может вызвать исключение, то и перехватывать его нужно при вызове метода, а не внутри. Иначе метод должен возвращать какое то значение. Глушить исключение внутри метода нельзя. За такое надо руки отрубать по самую футболку.

Или я вас не так понял?

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

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

раскрыть ветку (15)
2
Автор поста оценил этот комментарий

+++

Порядок должен быть :))

Даже в математике, в школе этому учат.

Сначало ставят границы иследуемой области. А после уже решают задачу.

А в конце сравнивают решение с условиями этих границ. А то в ответе можем много интересного получить:))


А то начинают мешать всё в кучу. А потом ищут долго то почему этот Франкенштейн очень странно работает . И как его заставить работать правильно. Спустя полгода/ год вылезла проблема, а там чёрт ногу сломит :)))

Автор поста оценил этот комментарий
Наверно вы меня не так поняли.
раскрыть ветку (13)
16
Автор поста оценил этот комментарий

Да все поняли, что ты очередной мудак

ещё комментарии
Автор поста оценил этот комментарий

Из моего опыта собеседования Джуна:

- Почему ты в цикле использовал int а не например byte?

- эм...ну обычно используют int. В учебниках так

- ок. А чем int отличается от byte?

- эм... ну... я не знаю

А потом пришла его мама, и орала что мы не взяли сыночка потому что он не русский. :)

раскрыть ветку (6)
0
Автор поста оценил этот комментарий
Да, это что я и писал. Язык не знают и не понимают. Хорошо ещё не спросили зачем нужен struct, если все используют class.
0
Автор поста оценил этот комментарий

* что если мы точно не знаем, что переменная может выйти за границы byte, но точно знаем, что за int она не вылезет. (например)

* int и byte - не гуд.
int32_t и uint8_t - гуд.

* совсем на крайняк, можно юзать auto

раскрыть ветку (4)
0
Автор поста оценил этот комментарий

В этом и смысл вопроса. Если у тебя статический массив, размером 20 элементов (как и было в задаче) - int избыточен. С точки зрения оптимизации лучше использовать именно byte. С технической, с учетом объемов оперативки нынешних компьютеров - разницы нет.

uint8_t - гуд. - Серьезно? Покажи пример на беззнаковом for от -100500 до +100500.
auto - на тот момент вообще не было. Но если бы это было, тогда второй вопрос бы касался его - как оно работает и чем отличается. Суть в том что программист должен понимать что он делает. И уж ответы на базовые вопросы точно должен занть.

раскрыть ветку (3)
0
Автор поста оценил этот комментарий

С точки зрения оптимизации - не факт. Есть нюансы с тем, как адресуется память. Лично мне больше всего size_t нравится. Как-то более описательно. что ли. Ну и auto от size() контейнера тебе как раз size_t и вернет

раскрыть ветку (2)
1
Автор поста оценил этот комментарий

А это смотря какая оптимизация. Я имел.ввиду не адресацию а sizeof. Можно и int64 использовать для итерации 20 значений и современное железо это простит. Но вот в случае с микроконтроллером уже не факт. А на highload задачах вы получите значительный перерасход памяти. И да, тут уже адресацию по полной проявится. Ибо даже порядок объявления полей по типам в структуре имеет значение из-за выравнивания.

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

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

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

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку