Подумал я тут. Часто, умные дяденьки, которые собеседуют тебя для приема на работу спрашивают только "основы". И... все, этим ограничиваются.
Лично у меня такое было 2 раза (а всего собеседований в IT конторы было 6): первый раз на разработчика C++, второй раз на разработчика C# / C++. В первой конторе меня поспрашивали про ООП, как устроены основные структуры данных (map, hash_map), какова максимальная сложность быстрой сортировки (подумав с минуту, понял, что O[n²]), пару вопросов по C и т.д. В общем, я на все отвечал достаточно уверенно и в конце собеседования чувак сказал, что хочет взять меня на работу (впоследствии, правда, оказалось, что им сейчас нужны только старшие девелоперы, но факт остается фактом - человек после 45 минут беседы уже готов был принять меня в команду).
Во второй конторе (DataEast) основной уклон уже был больше в пользу ООП и C#: эксепшены, разница между типами значений/ссылочными типами, что такое protected internal (я ответил неправильно, кстати)… Короче, вся такая вот фигня. На работу меня взяли, на этот раз железно. И зарплату обещали высокую. Однако, отработав 8 дней в DataEast, я уволился. Не понравилось. Но не об этом разговор.
Разговор об том, что многие зацикливаются на "основах". Типа, если человек их не знает, то он полный идиот, у него нет будущего, такого дебила нанимать нельзя. С другой стороны, если человек "основы" знает, то он офигенный программист, берем его 100%. Мне кажется, что это, мягко говоря, неправильно.
Во-первых, давайте сначала определимся, а что же такое "основы" вообще? Что такое полиморфизм, хеш-таблица, красно-черное дерево? А с чего вы взяли? Если уж вы настолько фанатеете от "основ", давайте тогда будем копать глубже и спрашивать, как устроен процессор, какие регистры у него есть, зачем нужен кэш 3го уровня и т.д. А хрен с ним, давайте пойдем еще дальше и будем допрашивать соискателя на тему устройства полевого транзистора, D-триггера и двоичного сумматора? А может вообще погонять по устройству полупроводниковых элементов на атомном (квантовом) уровне? Сами понимаете, что смысла никакого в этом нет, потому что человека, способного на собеседовании правильно, подробно и уверенно отвечать на все вышеперечисленные вопросы в природе не существует (хотя кто знает?:) Поэтому, не надо судить о человеке только лишь потому, что он не знает, что такое хеш-таблица. Может, его в вузе вообще не учили этому? Да даже если он не знает, то что? Может, ему просто это не нужно? Вспомните, когда вы последний раз реализовывали свою хеш-таблицу? Я помню - на 1 курсе НГУ на паскале. После этого я велосипед не изобретал, а пользовался уже готовыми реализациями, благо, каждый мэйнстримовый язык программирования имеет нормальную стандартную библиотеку. И признаться, за 6 лет я уже и подзабыл, как эта хеш-таблица устроена. Просто неиспользуемые на практике знания из головы довольно быстро выветриваются. И что, теперь я тупой? Естественно нет. Трудно себе представить человека, который прошел курс квантовой механики в университете и получил по нему 5, но который не сможет разобраться, как устроена хеш-таблица, если появится такая необходимость.
Во-вторых, почему вы решили, что человек знающий "основы", способен работать вообще? Бывают люди, знающие много, но которые неспособны при этом применять полученные знания на практике. И такое часто бывает. Причин может быть несколько.
Например, вспомните, сколько раз вы в жизни изобретали велосипед, потратив кучу времени? Лично я делаю это довольно регулярно. И всему виною знания тех самых "основ". Когда-то я участвовал в одном программистском конкурсе и решил замутить свою собственную реализацию AVL-дерева. Потратил полдня. Зачем, если достаточно было погуглить минут 30 и найти готовую реализацию в Интернете? Т.е. получается, что иногда, когда знаешь много, проще написать свое, потому что ты знаешь, как оно устроено, чем поискать готовое стабильное и протестированное решение. Сегодня вот, например, нашел очень полезную Apache библиотеку commons-lang с полезными методами, которых нет в стандартной библиотеке Java. Глянув внутрь, я понял, что мы у себя в нашем проекте несколько раз изобрели велосипед, хотя могли использовать эту библиотеку. Джуниоры писали, думаете вы? Хрен. Велосипедили как раз те самые умные разработчики, знающие "основы".
Другая причина - это обычная гордость (или гордыня, что еще хуже). Бывало ли с вами такое, что сидишь полдня, втыкаешь чужой код, пытаешься его понять, а подойти к автору кода не позволяет твоя гордость? "Я же умный, я и сам смогу разобраться!". Вот так и тратишь кучу времени. А тем временем, твой коллега-junior, студент НГТУ, увидев тот же самый код, просто подойдет да расспросит автора. И быстро во всем разберется. А если человек еще и ленивый, так это вообще п%#^ец. Такой программист вообще отказывается делать работу, придумывая всякие отмазки типа "Я че быдлокодер вам веб-сервисы делать? Пусть вот студент Петя этим занимается" или "У меня стаж 3 года. Я нанимался тут задачи раздавать, ну на худой конец, архитектуру программы делать, а вы меня тут заставляете какой-то там отчет генерировать".
В общем, мое мнение следующее. Не зацикливайтесь на "основах". Как наличие, так и отсутствие определенных знаний еще ничего не означает. Собеседование должно быть разносторонним (и вообще, оно должно состоять из нескольких этапов, как делают все престижные IT-компании типа Лаборатории Касперского или Гугла). Если человек изучал микроконтроллеры в университете и писал на ассемблере, то уж наверняка он разберется в ООП и C#. Не делайте поспешных выводов. Если человек знает наизусть все паттерны проектирования, то это еще ничего не значит. Дайте ему тестовое задание. Пусть докажет, что сможет применить их на практике. Включите в тестовое задание как можно больше различных технологий. Пусть попыхтит. Когда я устраивался в компанию, в которой я работаю сейчас, для тестового задания мне пришлось разобраться с основами Eclipse, Maven, Tomcat, Struts, Freemarker, jQuery (со всем этим, я столкнулся первый раз). Было трудно, но зато я был уверен, что буду работать в компании, куда не берут всякий шлак (в противоположность DataEast).
