Как пройти собеседование?

[Stoic]

Ох ! а я и не понял, что там про Москву.
Тогда вообще все просто. Никакое резюме ненужно вообще, а нужны знакомые....

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

На постоянке тоже самое, может только другие занкомые нужны

[OtherSide]

На постоянке тоже самое, может только другие занкомые нужны

Понятно, что наличие рекомендаций устройство на работу упрощает (думаю везде, и в США тоже), но не так что бы без них нельзя было обойтись.. По крайней мере так было 5-6 лет назад, когда последний раз работу менял. Вообще, привтовская традиция пихать рефренсы "как хорошо, что я вовремя свалил" куда не попадя, очень раздражает.

[Dweller]

Вполне себе нормальные и достаточно простые вопросы если компания хочет найти гика который каждый день начинает с разминки в С++ на топкодере

[Dweller]

a* prt;
ptr++;

- выдаст ошибку т.к. переменная ptr не объявлена.
- если все же prt++ то формально указатель сдвинется вперед на размер типа а - но проблема в том что в prt лежит мусор и сдвиг может увести указатель куда-нибудь не туда, вызвав exception

[Medium-rare]

На постоянке тоже самое, может только другие занкомые нужны

Понятно, что наличие рекомендаций устройство на работу упрощает (думаю везде, и в США тоже), но не так что бы без них нельзя было обойтись.. По крайней мере так было 5-6 лет назад, когда последний раз работу менял. Вообще, привтовская традиция пихать рефренсы "как хорошо, что я вовремя свалил" куда не попадя, очень раздражает.

Не обращайте внимание на сисадмина. У него знания об устройстве на работу совершенно перпендикулярные, как и собственно его работа к нашей.

[OtherSide]

a* prt;
ptr++;

1) выдаст ошибку т.к. переменная ptr не объявлена.
2) если все же prt++ то формально указатель сдвинется вперед на размер типа а - но проблема в том что в prt лежит мусор и сдвиг может увести указатель куда-нибудь не туда, вызвав exception

1) Вы же видите, что это описка..
2) Никакого эксепшина не произойдет, с чего бы, мы же его не разименовываем

[Dweller]

a* prt;
ptr++;
1) выдаст ошибку т.к. переменная ptr не объявлена.
2) если все же prt++ то формально указатель сдвинется вперед на размер типа а - но проблема в том что в prt лежит мусор и сдвиг может увести указатель куда-нибудь не туда, вызвав exception

1) Вы же видите, что это описка..
2) Никакого эксепшина не произойдет, с чего бы, мы же его не разименовываем

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

Не вижу подвоха в задачке. Скорее всего там была еще одна описка, т.е.
a* prt;
*prt++;

(С++ последний раз я использовал очень давно)

[OtherSide]

Не вижу подвоха в задачке. Скорее всего там была еще одна описка, т.е.
a* prt;
*prt++;

(С++ последний раз я использовал очень давно)

Вот задача целиком:

class A {
public:
A operator++(int) {
cout << "2" << endl;
return A();
}
void method() {
cout << "1" << endl;
}
};

int main(int argc, char** argv) {
A* obj;
obj->method();
obj++;
}

Сказать что будет на экране, и доказать что не упадет. Отдельным вопросом было на сколько увеличится obj

[Medium-rare]

Что называется "поведение не определено", главное зло от неинициализированных переменных.

[Boriskin]

Имхо, в релизе может упасть, а может и не упасть; в дебаге упадет...

[OtherSide]

Имхо, в релизе может упасть, а может и не упасть; в дебаге упадет...

Ну я так и ответил, что упадет и ошибка. Когда спросили почему - ответить не смог, по логике причин для падения нет, т.к. вызов метода берется не из указателя. Оно так и есть - по опыту - падает, но падение искуственное, форсированное самой Студией.
Зачем знать такие подробности для реальной работы - не понимаю. На интервью экзаменаторы всем своим видом показали, что 10 лет опыта я себе приписал или занимался неизвестно чем.

[Dweller]

Наверное это тонкий способ понять приходилось ли за 10 лет фиксить разнообразный чужой код в С++.
Плохой чужой код - рассадник подобных задач.

[Medium-rare]

Имхо, в релизе может упасть, а может и не упасть; в дебаге упадет...

Ну я так и ответил, что упадет и ошибка. Когда спросили почему - ответить не смог, по логике причин для падения нет, т.к. вызов метода берется не из указателя. Оно так и есть - по опыту - падает, но падение искуственное, форсированное самой Студией.
Зачем знать такие подробности для реальной работы - не понимаю. На интервью экзаменаторы всем своим видом показали, что 10 лет опыта я себе приписал или занимался неизвестно чем.

Зачем знать и уметь рассказать, "почему оно упадёт" на интервью? О! Вначале казалось, что они к вам несправедливы. Конечно, когда точно неизвестно почему именно упадёт, то вопрос как-бы тухлый. Но имея в виду, что отвечаешь тоже человеку, а не роботу, можно версий накидать.

Как-то, Unitialized variable causes non-deterministic program code behavior.
1) If the garbage pointer variable points to the memory mapped for this process (in the OS), we can never know what type of data there, so we don't know how the code behaves when it accesses the data by that address.

2) If the garbage pointer variable does not point to the memory mapped for this process and the code accesses the data by that address we have some Page Exception Fault or General Protection Fault, that executes standard OS process crash procedure.

Тут можно порассуждать, как возбуждается GPF в OS, как Kernel вступает. Это всё очень прямые свидетельства качества системного программиста. C/C++ программеры должны это знать и понимать.

[OtherSide]

Зачем знать и уметь рассказать, "почему оно упадёт" на интервью? О! Вначале казалось, что они к вам несправедливы. Конечно, когда точно неизвестно почему именно упадёт, то вопрос как-бы тухлый. Но имея в виду, что отвечаешь тоже человеку, а не роботу, можно версий накидать.

Как-то, Unitialized variable causes non-deterministic program code behavior.
1) If the garbage pointer variable points to the memory mapped for this process (in the OS), we can never know what type of data there, so we don't know how the code behaves.

2) If the garbage pointer variable does not point to the memory mapped for this process we have some Page Exception Fault or General Protection Fault, that executes standard OS process crash procedure.

Тут можно порассуждать, как возбуждается GPF в OS, как Kernel вступает. Это всё очень прямые свидетельства качества системного программиста. C/C++ программеры должны это знать и понимать.

Типа отбрехаться знанием страшных слов? Меня попросили по шагам рассказать что происходит при запуске функции, откуда берется ее адрес, и откуда она берет доступ к данным. Действительно, падать не должно. Но по опыту-то падало!
Опыт работы с чужим кодом такой пример не раскрывает нисколько: если я увижу такой код, я уже на уровне рефлекса распознаю ошибку, а не буду рассуждать: один фиг оно не упадет, т.к. функция не виртуальная, пойдет и так.

Вообще же поднатаскатся на таких задачах проблем не вижу - кол-во каверзных вопросов ограниченно, и еще чуть подготовившись можно быстро отвечать на все. Но что же делать с MFC, COM, WinAPI и прочим? Каждая из книг по этим технологиям занимает страниц 900. И если к кавернзным вопросам по С++ еще можно подготовится, то от мысли о том, что нужно зубрить эти фолианты мне становится совсем дурно.

[Medium-rare]

Типа отбрехаться знанием страшных слов?

У вас неправильное отношение к интервью. Это практический вполне вопрос. Если бы вы имели опыт написания, скажем, драйверов, или работы с железками то "отбрехаться знанием страшных слов" звучало бы просто как ответ сисадмина на серьёзный вопрос низкоуровневого программирования. Потому надо понимать, что там физически происходит.

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

[OtherSide]

Плюс еще вопрос мотивации: когда в 17 лет я писал утилиты, которая ворует кнопочки из MS WORD - то чувствовал себя кул хацкером. Сейчас же уже подобные эксперименты не являются для меня столь захватывающими и учебник по MFC уже не читается захватывающе.

[Medium-rare]

Сейчас всё больше сокращется для нас рынок, C/C++, если про Windу. Есть более менее стабильные области за пределами Windы и кросс-платформенное либо железячное программирование. Все области, где надо хорошо понимать связь между архитектурой процессора / ОS / вашего кода.

[OtherSide]

Типа отбрехаться знанием страшных слов?

У вас неправильное отношение к интервью. Это практический вполне вопрос. Если бы вы имели опыт написания, скажем, драйверов, или работы с железками то "отбрехаться знанием страшных слов" звучало бы просто как ответ сисадмина на серьёзный вопрос низкоуровневого программирования. Потому надо понимать, что там физически происходит.

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

Ну знаете, это как то несерьезно на вопрос почему упадет, говорить что упадет из-за GPF. Это-то понятно.

[Medium-rare]

:смайлик, стучащийся лбом об стену:

[OtherSide]

Сейчас всё больше сокращется для нас рынок, C/C++, если про Windу. Есть более менее стабильные области за пределами Windы и кросс-платформенное либо железячное программирование. Все области, где надо хорошо понимать связь между архитектурой процессора / ОS / вашего кода.

Честно говоря, последние 5 лет я вовсе писал библиотеку для обработки изображений, там взаимодействие с железом минимально.

[Medium-rare]

Честно говоря, последние 5 лет я вовсе писал библиотеку для обработки изображений, там взаимодействие с железом минимально.

Ну а писал бы тоже для graphic accelerator и интеграцию оного в OS, просёк бы. Open your mind.

[Dweller]

Плюс еще вопрос мотивации: когда в 17 лет я писал утилиты, которая ворует кнопочки из MS WORD - то чувствовал себя кул хацкером. Сейчас же уже подобные эксперименты не являются для меня столь захватывающими и учебник по MFC уже не читается захватывающе.

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

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

[OtherSide]

:смайлик, стучащийся лбом об стену:

По контексту разговора было понятно что так отбрехаться нельзя. Было видно что требуются конкретные и четкие ответы. Не смотря на то, что я показал понимание (объяснил в какой ассемблерный код все собралось), ответ не засчитали. Вопрос был поставлен прямо - а какого размера объект данного класса должен был в памяти занимать? Вы лично знали, сколько именно? Конечно, можно логически дойти, но на ответ давалось секунд 10-15. Логически - понятно что либо 0, либо 1. С одной стороны переменных размером 0 я не встречал. С другой - а что же будет хранится в этом единственном байте?

[Boriskin]

:смайлик, стучащийся лбом об стену:

I feel your pain.

[OtherSide]

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

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

В том и дело, что сложно понять чего они ищут. 5-7 лет назад был кадровый голод, и я спокойно шел на собеседование, зная что не подхожу по половине пунктов (остальные можно подтянуть). На собеседовании были задачи на знание С++ (не столь искуственные), общие вопросы на алгоритмическое мышление и тестовое задание.
Сейчас я сталкиваюсь с тем, что предложение огромно; некогда ни учить, ни собеседовать. Есть список требований, к которым кандидат должен подходить сразу. Для меня нет проблемы вспомнить MFC и WINAPI. Если бы я получил реальный оффер, то я бы вспомнил все за неделю-две. Но в том и дело, что требуются они далеко не везде. В одном месте хотят MFC, в другом WinForms, в третьем - WPF. Все это держать в голове в идеальном состоянии одновременно - сложно. .