Популярные вопросы на собеседовании по C++ и ответы на них
Те, кто занимается программированием рано или поздно сталкивается с необходимостью прохождения технического собеседования у потенциального работодателя.
О том, что спрашивают на собеседовании у C++ программистов, а также об ответах на эти вопросы и пойдет речь в данном посте.
Предисловие
Небольшая вводная часть в виде вопрос-ответ, чтобы разъяснить некоторые моменты и постараться ответить на возможные вопросы по этому посту.
Зачем все это?
Хочется собрать реальные вопросы и ответы на них в одном посте. Т.к. меня не устраивают те, что я вижу в интернете, они порой слишком размазанные (например, 75 страниц на геймдеве), или рассматривающие всего несколько примеров, или с ошибками, которые уже никто не исправит, или с ссылками на уже мертвые топики, или какие-то надуманные,… список можно продолжать.
В общем хочется иметь список с самыми популярными вопросами по данной теме, и если, вдруг, понадобится освежить знания, чтобы не приходилось лезть в какие-то записки, запускать IDE или гуглить, а можно было открыть одно место и там все прочитать.
Наиболее интересной данная тема должна показаться тем, кто еще только начинает свои шаги в этом безграничном море под названием C++.
Откуда будут вопросы?
Из небольшого моего опыта, опыта людей, которых я знаю, а также, я надеюсь, что много интересного предложите вы, из своего опыта или опыта ваших знакомых.
Какая будет структура этих вопросов?
Линейный список. Вопросы будут добавляться по мере поступления, я постараюсь не забрасывать данный раздел и обновлять его. В конце я буду ставить дату последнего обновления, чтобы было понятно когда список меняли последний раз.
Сейчас я планирую написать первые 20 вопросов, а если эта тема будет востребована, то буду постепенно добавлять новые.
У вас ошибка в коде, как вы ее проглядели?
Людям свойственно ошибаться и я не считаю себя гуру способному писать безошибочно. И это C++, здесь вероятность ошибиться еще больше.
Если вы видите ошибку, напишите о ней, и я обязательно ее исправлю.
1. Зачем нужен виртуальный деструктор?
Ответ: Чтобы избежать возможной утечки ресурсов или другого неконтролируемого поведения объекта, в логику работы которого включен вызов деструктора.
Пример:
Derived()
Hello from
Без ключевого слова virtual у родительского класса Base деструктор порожденного класса не был бы вызван. Т.е. вызвался бы только
Более подробно об этом написал GooRoo здесь. Наглядный пример возможной утечки в следующем вопросе.
2. Что стоит помнить при использовании исключений в конструкторе объекта?
Ответ: Если исключение не обработано, то c логической точки зрения разрушается объект, который еще не создан, а с технической, так как он еще не создан, то и деструктор этого объекта не будет вызван.
Пример:
Output:
Hello from Base()
Exception message: Something failed
Я немного модифицировал предыдущий пример, чтобы проблема была наглядней. Здесь объект m_hFile (если был открыт) утечет т.к. до CloseHandle() выполнение не дойдет. Т.е. имеем такие же проблемы как в первом примере: возможная утечка ресурсов или другие проблемы из-за нарушения логики работы класса.
Здесь могут спросить: «Как бы вы поступили при подобной ситуации». Правильный ответ: «Воспользовался бы умными указателями». Простой пример умного указателя:
Теперь и без вызова деструктора Base хэндл будет закрыт, т.к. при уничтожении класса Base будет уничтожен объект m_hFile класса CHandle, в деструкторе которого и будет закрыт хэндл.
Изобретать велосипед, конечно, не надо, все уже написано до нас, это пример который можно написать на бумажке при соответствующем вопросе. А так есть boost, Loki, ATL и т.п., где это уже реализовано.
3. Для каких целей применяется ключевое слово const?
Пример 2. Не можем изменить указатель на объект:
Пример 3. Не можем изменить члены класса:
Дополнение: константный метод может изменять члены класса, если они объявлены как mutable. Подробнее про mutable можно прочитать у Алены CPP здесь.
4. Можете ли вы написать пример какого-нибудь алгоритма сортировки?
Ответ: Пузырьковая сортировка, для контейнеров, без временных переменных:
5. Можете ли вы написать код для переворота строки?
Ответ: Код переворота строки для контейнеров, без временных переменных, не осуществляющий прохода по всей строке:
6. Как защитить объект от копирования?
Ответ: Сделать private конструктор копирования и оператор =.
Пример:
7. В чем разница между struct и class?
Ответ: Практически ни в чем. В struct модификаторы доступа по умолчанию public, в class private. Также отличается и наследование по умолчанию, у struct — public, у class — private.
Пример:
Проблемы в собеседовании на позицию программиста
Мне так сильно понравилось ваша вакансия и ваша компания и ваши идеалы корпоративной культуры, что я решил предложить вам мою скромную кандидатуру. Вот моё супер-уникальное резюме, пришлите тестовое, а еще мы можем пообщаться час-два для того чтобы мы примерно поняли хотим ли мы друг друга.
Преамбула
Я работаю программистом давно. Так сложилось что мне довелось оказаться по обе стороны «баррикад»: я проходил не менее сотни собеседований, чаще получая отказ и проводил не менее пятидесяти собеседований, чаще отказывая.
Обычно меня собеседовали два человека: менеджер\босс и программист\технарь. Реже — один, еще реже — трое и более. Задают вопросы они, как правило, из совершенно разных областей, поэтому разделим условно собеседование на тестовое задание, инспектирование софт скиллов и инспектирование технических скиллов.
Тестовое задание
Вряд ли я отправлю обратно решение к тестовому заданию, если не проверю что оно рабочее и выполняет поставленную задачу. Соответственно на проверку другому программисту приходят, в основном, только рабочие решения, среди которых он должен выбрать те, которые по его оценке (мнению) являются достаточно подходящими. Поработав со множеством программистов в команде я не по наслышке знаю об их лютой нетерпимости к чужому коду, к чужому ходу мысли. Поэтому даже если вы предложите им решение лучшее, чем могло бы созреть у них в голове, вы сильно рискуете нарваться на непонимание и отказ. При этом на просьбу расписать причины, можно получить как совершенно левую ахинею (однажды мне в укор поставили то что я выслал задание в архиве, а не опубликовал его на своём гитхабе, конечно, буду я пачкать своё пространство), так и полный игнор. Поэтому игра в тестовое задание это на самом деле игра в «понравься другому технарю, о котором ты не знаешь ничего», то есть великий рандом.
Кстати, по очередности тестового задания и собеседования вы можете уловить отношения в фирме между менеджером и программистом. Если вам предлагают решать тестовое задание до собеседования, значит менеджер себя считает более загруженным, чем своих подчиненных, пытается сэкономить своё время по максимуму, делегируя базовую проверку. Если же тестовое задание вам предлагают решить уже после собеседования, значит у программистов в фирме в текущее время настолько большая нагрузка, что их даже не отвлекают на проверку тестовых заданий случайных людей. Еще больше отношений вы можете уловить, если собеседование проходит поэтапно, сперва с одними людьми, затем с другими. Надеюсь вы уцепились за суть.
Проверка софт скиллов
«Расскажите о себе?» — вопрос, вводящий в ступор человека с глубоко-техническим складом ума (будем в дальнейшем называть его конструктор). Конструктор может немного покопавшись в памяти вывалить своё имя, возраст, рост и вес, национальность и цвет глаз, но при этом не поймет какое это все имеет отношение к делу, ведь он пришел продавать свой технический скилл, а не себя. «Что конкретно вы хотите обо мне узнать?» — обычно отвечаю я и наблюдаю разочарование в глазах босса, босс редко любит когда ему отвечают вопросом на вопрос, ведь теперь мячик на его стороне и думать приходится ему. Если бы я мыслил по другому, то конечно, я бы вывалил на него заранее подготовленную смачную историю меня любимого с детальными подробностями того насколько я клёвый, классный и, что самое главное, лучше чем остальные. Но если бы я мыслил по другому, я вряд ли стал бы программистом. Поэтому на ответ «что хотите то и рассказывайте» я начинаю тупо перечислять где я работал и какими проектами занимался, плюс какие технологии использовал, чем совершаю очередную ошибку, поскольку всё это уже расписано в резюме и не вызывает ничего кроме скуки. Ведь словами невозможно донести тот объем, вес и значимость, которые я ощущаю в своей голове.
И здесь я делаю допущение: допустим, что программист НЕ ДОЛЖЕН обладать сильными софт-скиллами.
Пойдем от обратного: допустим, что программист ДОЛЖЕН обладать сильными софт-скиллами, тогда — зачем нужен менеджер? Зачем тогда вообще нужна фирма, если я могу пойти на биржу фриланса и найти себе там самостоятельно заказчика? Господин Форд — великий изобретатель прошлого века, он изобрел конвеер, невероятно эффективную вещь, которую, видимо, еще не все научились использовать. В некоторых фирмах просекли эту фишку и вставили между программистами и заказчиками особое звено — менеджеров, по сути являющихся переводчиками с «человеческого» на «программисткий». Задача менеджера — договориться с программистом и заказчиком, задача программиста — «договориться» с кодом. Ожидая от программиста дополнительного повышенного скилла договариваться и коммуницировать, вы отсекаете тех программистов, которые за счет отсутствия этих софт-скиллов освободили в своей голове достаточно места чтобы прокачать скилл разработки гораздо глубже.
Представим себе что мы попали на собеседование в фирму, которая понимает эту идею. Тем не менее оценить общую коммуникабельность она всё равно желает, просто для того чтобы отсеять совершенно неспособных к командной работе людей. Каким образом это можно сделать эффективно за 1-2 часа разговора? Никаким. Я не видел ни одного человека на собеседовании, который вел бы себя распутно, неуважительно или неприемлемо выражался, и это естественно, ведь на собеседовании мы все максимально открыты, дружелюбны и адекватны. Поэтому, пропустив через себя тысячи собеседующихся, собеседующий начинает больше обращать внимание на другие детали: как человек одет, какая у него прическа, как от него пахнет, какие гримасы строит, какие эмоции проявляет, какие жесты использует, как долго смотрит в глаза, как часто отводит взгляд, как быстро отвечает на вопросы. И формирует своё заключительное «экспертное» решение, по сути, на голой интуиции. Ведь перед ним стоит задача «выбрать лучшего на текущий момент», а не «отсеять подходящих от неподходящих», и он не может пойти против этой задачи.
Оценка быстроты реакции — отдельная ошибка. Мгновенно отвечающие люди на самом деле даже не успевают подумать. Люди же тормозящие с ответом, напротив, погружаются в чертоги разума, тщательно взвешивая все возможные варианты, пока чувствуют что было бы уместно еще немного подумать. Даже если у них сразу появляется подходящий ответ.
Проверка технических скиллов
Казалось бы что техническая подкованность на порядки более значима, чем способности к коммуникации, но по факту редко какая фирма устраивает собеседование таким образом, что техническая часть превосходит социальную. Бывают, конечно, исключения, однажды мне довелось 4 часа общаться с очень дружелюбным технарём, от которого я узнал множество интересных, но бесполезных в моей реальной жизни фишек.
Так что же, реально за 1-2 часа разговоров оценить человека достаточно хорошо чтобы принять правильное решение? Конечно же нет. Самая главная ошибка здесь — точно такая же как и в предыдущей части — задача найти лучшего, а не отсеять подходящих от неподходящих. В результате собеседование превращается из поиска знаний в поиск пробелов, ведь чем больше пробелов найдет собеседующий, тем менее подходит кандидат и тем проще сложить-вычесть-посчитать виртуальные очки. Дополнительная ошибка в том что мы проверяем у кандидата наличие лишь тех знаний, которые знаем сами, полностью упуская из виду те знания, которых не знаем, которые могли бы быть намного более полезными в фирме, чем очередная копия меня.
Особенно скользкое в происходящем то, что превращенное в экзамен инспектирование проверяет не способность кандидата программировать, а его способность объяснить, донести, научить, то есть по сути та же самая проверка коммуникативных способностей в иной плоскости. Я, например, могу быстро и качественно спроектировать нормализованную структуру базы данных или нормализовать уже имеющуюся, но совершенно не в состоянии объяснить словами другому человеку как это делать, потому что когда я нормализую, я не использую русские слова, я использую внутренние знания, приобретенные не на парах в университете, а на «боевом» опыте. Эту разницу скиллов между исполнителем и учителем понимают не все. Другой каноничный пример — путаница в шаблонах проектирования. Я быть может и знаю тот шаблон что вы у меня спрашиваете, но в моей голове он называется по другому и его реализация может немного отличаться.
Особенно мной нелюбимое — инспектирование очень мелких и сверх-специфичных деталей, место которым в Гугле, а не в моей голове. За что отвечает третий параметр в функции пузырьковой сортировки? Организуйте очередь двумя стеками. Как сделать выборку так чтобы не так, а вот так? Конечно, хорошо когда эти детали находятся в голове, программист экономит время, а фирма экономит деньги. Но чего вы никогда не узнаете задавая подобные вопросы — это что лежит у кандидата в голове ВМЕСТО этих знаний, знаний такой низкой ценности. Быть может там глубокое понимание асинхронности, а может навык подката к девочкам на вечеринках, но вопрос задан, время потрачено, собеседование на очередной шаг приблизилось к своему завершению, а вы разведали мало значимого.
Про просьбы скомпилировать с бумаги код в голове даже говорить не хочется. Вы на позицию ищите программиста или компилятор\интерпретатор? В повседневной рабочей рутине программист привык полагаться на среду, использовать ее возможности по максимуму, экономя своё «процессорное» время там, где это возможно. Поэтому неудивительно что такого рода задания выполняются медленно и часто не правильно. Вместо них было бы лучше спросить какими средами он пользуется и что ему в них нравится, быть может найдете для себя что-то новое, вкусное.
Есть ли выход?
Если вы вознамерились экономить на мозгах, извините, вы будете продолжать пропускать нужные кадры в погоне за лучшими. Могу лишь обратить ваше внимание на то, что хорошие мозги почти постоянно находятся в поиске места лучше, чем их текущее, поэтому потерять «лучший» мозг так же легко как и «найти».
Если же у вас достаточно бюджета, вы можете попробовать следующий трюк: предложите 1 испытательный месяц работы всем желающим за пол ставки и принимайте решение по результатам работы. Его можно скомбинировать с предварительными собеседованиями, если задачу переключить с поиска лучшего на поиск подходящих, но стоит помнить о том что собеседования такого рода практически бесполезны и лишь отнимают время.
Собеседование на позицию разработчика, как оно есть
Доброго времени суток. На данный момент я занимаю должность Senior/Team Lead IOS Developer. Так вышло, что за последний год мне довелось побывать на огромном количестве собеседований, так сказать, по обе стороны баррикад. Поэтому мне бы хотелось поделиться своим опытом и поговорить о том, как, на мой взгляд, надо проводить собеседование, ведь в общей суматохе можно упустить ряд важных моментов, что, впоследствии, может негативно отразиться на качестве собеседования.
Данная статья будет полезна людям, которые волею судьбы вынуждены проводить собеседования, но при этом не имеют необходимого опыта и плана, как и я когда-то. Все, что описано ниже, является выводами из большого количества проведенных собеседований. Но, как говорится, любое совпадение имен или событий с реальными являются случайностью.
Заповеди
Заповедь номер раз
Ваша задача – определить, что человек знает, а не показать, что вы знаете больше.
С этим сталкивается любой человек, который проводит собеседование впервые. Он воспринимает его как некоторого рода соревнование, где он должен, как и собеседуемый, показать класс. Это не так. Нет сомнений, что Вы, как человек задающий вопросы, сможете изыскать в глубинах интернета и на тайных страницах мануалов вопрос, на который собеседуемый ответить не сможет. Но ведь Ваша задача состоит не в этом.
Заповедь номер два
Ваша задача – выяснить, что данный человек может сделать для Вашей фирмы сейчас и через три месяца, а не то, что он мог сделать год назад.
Мне не раз приходилось проводить собеседование с людьми, которые имели больший опыт, чем я. В первый раз меня это ввело в ступор, было как-то неловко задавать вопросы человеку, который старше тебя, да и в области программирования работает дольше. Но вся неловкость улетучилась, как только он не смог дать внятный ответ на элементарные принципы работы с многопоточностью. Хотя портфолио было внушительным, реальные знания оказались неглубокими. Вы нанимаете человека, который будет работать с вами в будущем, а не того, кем он был 2 года назад.
Заповедь номер три
Ваша задача – определить сможет ли человек влиться в команду.
Вне зависимости от уровня собеседуемого попытайтесь определить для себя, сможете ли вы работать с этим человеком в команде, даже если вы знаете, что делать этого не придется. Однажды на собеседование приходил товарищ, который в течение первых 5 минут умудрился съязвить HR-менеджеру и на протяжении всего собеседования был далек от делового тона, хотя некоторыми знаниями обладал. После собеседования его кандидатура более не рассматривалась, так как никто работать с ним в одной команде не хотел. В свою очередь Вы, как бы вам не нравился человек, должны быть сдержаны и приветливы, так как Вы представляете всю фирму, а он только себя.
То, на что надо обратить внимание
Я работаю на небольшой фирме, и у меня нет в распоряжении толпы HR менеджеров, которые организуют все на высшем уровне, поэтому я опишу некоторые моменты, за которыми необходимо следить.
Собеседование на junior программиста
Цель – выяснить обучаемость собеседуемого.
Для начала выясните, где человек учился или учится (я сторонник того, что для работы программистом необходимо иметь инженерное образование, так как это позволит вам говорить на одном языке). Бог свидетель, ко мне на собеседование приходили люди из музыкальной консерватории, которые прошли 2-месячные курсы по программированию.
Обучаемость может частично компенсироваться усердием. И тут на помощь приходит система образования. Выясните какой у претендента средний балл, учится он платно или бесплатно. Квадратный зад в программировании пригодится.
Для меня наибольшую сложность представляло формирование списка вопросов, так как многие за исключением создания класса или массива вообще ничего не знают.
Вот к чему я пришел в результате экспериментов. Можно пройтись по стандартным вопросам: ООП с примерами, области видимости переменных, переопределение и перегрузка методов, виртуальные функции. Это позволит соискателю понять, что его планируют взять программистом, а не преподавателем младших классов для решения задач про переправу волка и зайчика через мост.
Собеседование на middle/senior программиста
Тут дела обстоят лучше. Перед вами человек с опытом и вам есть о чем поговорить. Если у вас достаточно опыта, вы можете использовать то, что изложено ниже, если нет, то заготовленный список интересных вопросов — отличный вариант. Спустя два десятка собеседований я понял, что вытягивать из человека информацию посредством сухого допроса сложно и скучно. Пусть лучше он расскажет сам.
Начните собеседование издалека. Выясните, чем человек занимался на прошлой работе, какую роль в команде он занимал, доводилось ли ему участвовать в проектировании ПО. Все любят говорить о себе, а еще больше любят, когда их слушают, таким образом, вы превращаете допрос в беседу и снимаете некоторую напряженность с собеседуемого.
Спокойно выслушайте его до тех пор, пока он не упомянёт технологию, которая вас интересует. И вот тут вы начинаете задавать вопросы, даже лучше сказать интересоваться, как бы он, как весьма серьёзный инженер, решил бы некоторую задачу.
Разумеется, надо иметь в голове список вопросов, которых вы бы хотели коснуться, чтобы направлять беседу в нужное русло. Такой тип собеседования позволит проверить очень важное качество человека – его честность. Был следующий случай. Пришел на собеседование человек, который рассказал, что работал на проекте на ведущих ролях, а также что в его проекте было более 50 таблиц в базе данных, не один десяток миграций и обращения к базе идут в разных потоках и много чего еще. Однако при вопросе, как была организована работа с базой из многих потоков, внятного ответа не последовало (см. заповедь 2). Думаю, всем понятно, что место в нашей компании этот человек не получил.
После беседы переходим в наступление. Больше всего я люблю задачи типа «а если». Начинаются такие задачи очень просто, например, «переопределить сеттер для свойства». После чего задача обрастает разного рода дополнительными условиями, классами и ограничениями.
Для сеттера следующим этапом может быть возможность обращения к свойству из многих потоков. Заодно будет повод поговорить о многопоточности в целом, если это не было сделано по «воле» собеседуемого в самом начале.
Во что бы-то ни стало избегайте вопросов типа «знаю/не знаю», ответ на которые можно дать, только если читал об этом. Примером такого плохого вопроса может служить вопрос о внутреннем устройстве узкоспециализированного класса.
Вы должны найти границу знаний собеседуемого, если пробел обнаружен не стоит тратить 10 минут на добивание, лучше двигайтесь дальше. Такой вариант будет приятнее для собеседуемого и продуктивнее для вас. (см заповедь 1).
Если в результате собеседования были даны ответы на все вопросы – грош цена такому собеседованию. Вы не дали собеседуемому в полной мере раскрыть свой потенциал.
Напоследок, коснусь спорного для многих вопроса.«Стоит ли объяснять правильный ответ на вопрос?». На мой взгляд, если человек был близок к решению задачи, ответ может быть оглашен. Однако, если к решению задачи человек не приблизился ни на йоту – смысла что-то ему объяснять я не вижу.
Как вести себя на собеседовании
Заключение
Помните: даже самое хорошо организованное собеседование может провалиться из-за полной бездарности собеседуемого ровно, как и кандидатура лучшего претендента может быть отметена из-за недостаточного опыта собеседующего.
Всем удачный поисков и высококлассных специалистов.
Как проходит собеседование у программистов, что спрашивают
Конкретные знания и способность показать их на интервью – две совершенно разные вещи. Первое собеседование на должность программиста – источник постоянного стресса независимо от возраста. Во время собеседования начинают забываться элементарные вещи, а некоторые вопросы ставят в тупик.
Совсем убрать волнение невозможно, но подготовка к интервью может его уменьшить. В этом гайде мы разберем как лучше готовиться к собеседованию.
Учтите, что само интервью может длиться не один час. В некоторые компании нужно пройти 2 и более раундов. Иногда они идут подряд, превращаясь в многочасовой марафон, иногда разбиты на несколько дней.
Двух одинаковых интервью не бывает. Одни и те же люди, проводят каждое собеседование немного по разному. Очень многое зависит от того, в какую сторону пойдет диалог, какие ошибки совершит собеседующийся и куда приведут его размышления. Более того, даже в рамках одной специализации, разные компании могут спрашивать абсолютно разные вещи. Чем сильнее компания, тем больше фундаментальных вопросов и меньше прикладных. И наоборот. В совсем простых ситуациях, интересуются исключительно прикладными навыками, которые нужны конкретно на этой должности.
Процесс собеседования зависит от вашего предыдущего опыта. Если с вами можно поговорить о прошлых проектах, то, скорее всего, вас начнут расспрашивать про них. Если нет, то тогда пойдут в ход тесты на общую сообразительность.
Ключевые темы
О себе. Прошлый опыт.
Обычно собеседование начинается со знакомства. На этом этапе к вам присматриваются, оценивают общую адекватность и ищут зацепки для дальнейшего разговора. В идеале нужно иметь за плечами реальные проекты с вашим участием. Подойдут и учебные проекты, код которых выложен на гитхабе.
На этом этапе будьте готовы ответить на следующие вопросы:
Задачи
Задачки на эврику или воображение
Существует категория задач, которые было модным задавать на собеседованиях раньше. Первыми, такое стали спрашивать в Microsoft, затем подтянулись и многие другие. Вот несколько примеров:
Сами по себе вопросы интересные. Над ними стоит поломать голову в кругу друзей. Проблема в том, что они слабо коррелируют с уровнем разработчика. Эти вопросы не являются логическими в строгом смысле, они больше опираются на воображение и “эврику”, такое состояние, когда вы внезапно догадались до ответа. Правда ответов обычно больше чем один.
Считается что сам процесс рассуждения над этими вопросами, показывает как у человека работает мозг. С одной стороны показывает, но с другой, состояние стресса и внезапность таких вопросов обескураживает. Более того, интервьюируемый скорее всего не поймет что от него хотят услышать.
Крупные компании отказались от этих вопросов, но никто не застрахован. Всегда есть вероятность, что вас спросят про люки. Поэтому имеет смысл подготовиться заранее. Посмотреть список наиболее распространенных и порассуждать над ними в домашнем кругу или, например, в сообществе Хекслета.
Задачки на логику
Это другой тип задач. Они имеют вполне конкретные ответы и опираются на формальную логику. Например:
Последняя задачка очень сильная и ее часто задают. Хотя она и выглядит мультяшно, внутри нее классная алгоритмическая задача.
Периодическое решение таких задач прокачивает алгоритмические навыки, работу с системами счисления, логическими операциями и математикой.
Алгоритмы и структуры данных
На этом этапе могут попросить реализовать переворот односвязного списка или выполнить сортировку пузырьком. Более сложные вещи писать не просят, их могут спросить устно. Например:
Этого раздела не стоит пугаться, никто не требует от вас глубокого знания алгоритмов и всего прочитанного Кнута. Достаточно прочитать одну книгу и немного попрактиковаться. В любом случае этот опыт не будет лишним, правильно выбранная структура данных в коде, сделает вашу жизнь значительно легче.
Операционные системы и сети
Сюда входит огромный перечень тем, например, владение командной строкой, понимание tcp/ip, http, dns, event loop и многое другое.
Как правило, эти вопросы не задают напрямую. В основном придумывают различные истории или ситуации. Примеры вопросов:
Операции с числами
Популярные задачи на системы счисления и битовые операции.
Problem-Solving задачи
Самый интересный тип задач. В этих задача моделируется реальная ситуация. Вам предстоит придумать способ решения в рамках каких-то ограничений. Например:
Написание кода
Чем меньше у вас опыта, тем выше вероятность того, что вас попросят написать код. Обычно просят написать его на листочке или в среде подобной repl.it. На задачу дают 10-20 минут. Пара примеров:
Во время решения могут попросить рассуждать над задачей вслух. Собеседующий хочет проследить за вашим ходом мыслей.
Эти задачи показывают насколько у интервьюируемого хорошо с логикой, алгоритмическим мышлением, как он владеет базовыми конструкциями языка. Они позволяют отсеять слабых кандидатов, но не помогают определить сильных.
В интернете созданы десятки сервисов, специализирующихся на подобных задачах. Обязательно включите их в свой список для подготовки. Научитесь проходить задачи уровня easy с закрытыми глазами. Этот навык поможет не только для прохождения собеседований, но и в реальном программировании.
Прикладные знания
Сюда входит большая группа вопросов, по тем технологиям с которыми вам придется работать.
Общие
Специфичные
Здесь проверяется знание библиотек, фреймворков, каких-то особенностей языков. В интернете, особенно на гитхабе, созданы списки по каждому возможному стеку.