Могу лапши навешать. Потому и говорю, что к интервью надо готовиться. И про компанию потрудись разузнать коль уж собираешься все же прийти на собеседование и вопросы подготовь к работодателю. Я, например, всегда оставляю время для ответов на вопросы соискателя.
То, что Вы написали во второй части показывает, что Вы уже давно не программист. Архитектор, проектировщик, тим лид — как угодно, но не программист.
По первой части приведу простой пример плохого кода, вызванного тем, что человек не понимает структуру хранения данных. Надо провести итерацию по парам key-value в HashMap. Делаем цикл по ключам и достаем внутри цикла значение get-ом. Дурное абсолютно решение и все равно так пишут.
Другой пример — надо осуществить поиск в неупорядоченном массиве. Можно написать в две строчки — sort и binarySearch, а можно подумать правильно ли это. А еще можно подумать если надо осуществлять поиск, то может надо как-то перепроектировать, чтобы поиск делать по чему-то более быстрому.
И вы хотите сказать, что тут не нужно знание в базовых алгоритмах?
Именно поэтому к собеседованию надо готовиться, а не считать, что вас возьмут за ваше резюме или красивые глаза и умный вид. Конечно мне не все равно в каком виде ко мне придет кандидат. Если, пардон, от него воняет БОМЖом, то вот как он будет на работу ходить? А вот в джинсах ли, в костюме ли — мне все равно. Манера общения тоже важна, т.к. если кандидат не сдержан и всех посылает при первой же проблеме — он работать в команде не сможет.
Реальная разработка в разы сложнее чем прохождение интервью. Именно поэтому у меня нет четкого алгоритма проведения интервью. С каждым кандидатом все с чистого листа. Вариант с хорошо проходящими интервью у меня не проходит.
Поскольку я нанимаю для себя, то мне как раз не все равно. Потому и заморачиваюсь.
Это не переговоры — и это базовая ошибка в вашей логике. Это интервью. Во всяком случае на первом этапе. Один спрашивает — другой отвечает. На этом этапе мне, как работодателю, важно понять как вы мыслите, что знаете, что умеете, сможете ли работать в команде, как вы работаете в стрессе (читай в критической ситуации) и даже ваша обидчивость мне также важна.
Мы с вами не работали. Я вас не знаю. Написать в резюме Вы можете все, что угодно. Собственно многие так и делают. То один директор ИТ (!) со штатом в 2 человека (директор и его зам :-)). По сути админ. То другой с опытом в Oracle в 10 лет не знает, что такое 3-я нормальная форма. Следующий типа писал высокопроизводительные программы, что такое Mutex и семафор не знает — копаем глубже вообще про синхронизации ничего не знает. Другой говорит Hadoop знаю, опыт 2 года. Ок, говорю нарисуйте (не напишите!) как устроено преобразование MapReduce. Такой бред начинается.
Так что я лучше пару вопросов по базовым вещам задам, а то может «До свидание!» — чего время терять.
Приходят разные. И на сеньора часто приходят с малыми знаниями, но с большими амбициями. Резюме — это только повод начать разговор. Гитхаб — спорно. Или вы считаете, что любой программер должен быть там? Конечно я немного утрирую… Но кандидаты у меня и LRU кэш пишут, и очереди реализуют, и Thread пулы делают, и много еще чего интересного, включая алгоритмические задачки.
Я же хитрый. :-) Откуда мне знать уровень человека, который ко мне пришел? У меня же нет ментальных способностей. Поэтому я попрошу написать факториал. Если напишет через цикл, спрошу написать через рекурсию. И вот тут то и узнаю знает ли он что это.
Проверял и буду проверять базовые знания у программиста любого уровня на собеседовании. Уровень кандидатов с каждым годом только падает. Сейчас нормального senior можно найти отсмотрев человек 20, лет 10 назад хватало и 10. Сортировку пузырьком не можешь написать? Факториал циклом и рекурсией не можешь написать? Не знаешь как устроен linked list, array list и когда надо использовать один, а когда второй? Не знаешь, как реализована hash таблица? Если ты говоришь, что знаешь БД и SQL и не знаешь LEFT JOIN и как устроен индекс, то какой ты на хрен программист. Двоечник ты — только и всего. Разработчик ДОЛЖЕН знать базовые структуры данных и базовые алгоритмы, ДОЛЖЕН знать детали языка программирования, ДОЛЖЕН знать ООП/ООД если язык объектно-ориентированный, должен знать многопоточность и основы синхронизации если позиция об этом. Если он при написании Java программы на листочке пропустит точку с запятой в конце — мне все равно, а вот если он спрашивает, что такое рекурсия — извини — до свидания!
Кстати, время (читай деньги) компании вы тоже потратили.
По первой части приведу простой пример плохого кода, вызванного тем, что человек не понимает структуру хранения данных. Надо провести итерацию по парам key-value в HashMap. Делаем цикл по ключам и достаем внутри цикла значение get-ом. Дурное абсолютно решение и все равно так пишут.
Другой пример — надо осуществить поиск в неупорядоченном массиве. Можно написать в две строчки — sort и binarySearch, а можно подумать правильно ли это. А еще можно подумать если надо осуществлять поиск, то может надо как-то перепроектировать, чтобы поиск делать по чему-то более быстрому.
И вы хотите сказать, что тут не нужно знание в базовых алгоритмах?
Реальная разработка в разы сложнее чем прохождение интервью. Именно поэтому у меня нет четкого алгоритма проведения интервью. С каждым кандидатом все с чистого листа. Вариант с хорошо проходящими интервью у меня не проходит.
Поскольку я нанимаю для себя, то мне как раз не все равно. Потому и заморачиваюсь.
Так что я лучше пару вопросов по базовым вещам задам, а то может «До свидание!» — чего время терять.