leo_sosnine | Вопросы на энторвью

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

Скилл прохождения интервью это отдельный скилл от работания работы. На интервью нужно знать ответы на типовые вопросы и выглядеть уверенно и внушать доверие. Ну а на работе нужно работать. Разные довольно вещи.

Если собеседую йа, то обычно понижаю внутренне оценку резюме, если оно содержит много шлака типа "95% история успешного завершения проектов в срок". Это непроверяемые на интервью утверждения, зачем их делать? Пишущий этого не понимает?

Типовой процесс интервью ущербен, но лучше ничего нет. На интервью нужно в ограниченное время (1-2 часа) принять решение, основываясь на неполной информации. У интервьюеров нет времени гонять кандидата на симуляциях или примерах реальных задач. У интервьюируемого тоже нет времени решать серьёзные задачи для каждого эмплойера забесплатно. Это делать можно было бы для каких-то элитных позиций, но нужно понимать, что значительный процент соискателей просто пройдёт мимо -- им больше делать нехрен как решать time consuming задачи забесплатно и проходить унизительные тесты, когда предложений и так полно.

Поэтому неизбежно интервью это тестирование знаний, а не скиллов. Всё строится на допущении, что тестируемые знания являются продуктом работы, в процессе которой человек проводил исследования, решал задачи и т.п.

Ближе к делу, вот ответ:

But usually when I was interviewed it was on general things, like how Kerberos works, what NTLM flaws are, how network access control works, how email flow works, what is the attack cycle and how it develops. Also basic things like what is a threat, what is a risk, what is a vulnerability, how do you approach to defend your typical enterprise from threats on this or that front. What to look for in security audits. What was the last architectural decision you've made.

Obviously know your resume and be able to give a short speech on each and every claim you make in your resume. This can go down to very specific things, very detailed if anyone from the board of interviewers is good at this field as well. The last time I was interviewed by 15 people for almost two hours, oh did they grill me on everything. Never lie on a resume, if hesitant you'd better drop it.

Be able to draw pretty much anything on a white board. DMZ design, SSL/TLS handshake, ADDS multi-domain forest with all 7 (or 6? forgot) types of trusts what pros/contras of different type of trusts. NTFRS vs DFS-R pros/contras. PKI. Everything, how it works, in detail, what happens step-by-step when you open a web-site in a browser. Cross certification, x.509 vs web of trust, pros/contras. Crypto, just basic things, nobody ever grilled me on let's say AES phases and possible ways to break it. But basic things should be known, like key lengths, general process, one-time pad, substitution/transposition, etc, performance impact, cipher selection considerations -- which is better in this or that scenario, cipher modes and their flaws, like why not to use CBC in TLS, etc.

DLP, pros/contras, how it works, typical problems, how to solve.

Forensics, basic OS design, basic memory usage by OS and apps, how it works, limitations, disk artifacts, event logs, bit copies, chain of custody, investigation scenarios.

Mergers/acquisitons, what to look for from a security perspective, how do you consume them, do you join them to your domain or set up trusts, pros/contras and how you do that if you do.

IR, like a scenario in which you are fighting a malware that noone from ~55 AV vendors on VT can detect, what you do.

Password best practices, what is a hash, how to make it harder to crack, how do you mitigate stealing user hashes (Yahoo breaches, etc), how do you crack it. Two-factor, pros/contras.

What is a typical app development stack, frontend-middleware-backend, how it works in conjunction, what are typical design flaws here, what are typical software development mistakes are and how to prevent/detect/mitigate them, what programming languages you are familiar with, write a code sample (usually cycles, conditions, etc), basic algorithms.

Basic project management, phases, solve this or that scenario managing employees, etc.

Хорошо иметь ещё аккаунт на гитхабе с внятными и инетерсными примерами кода. Что проблематично для энтерпрайза, т.к. весь исходный кот принадлежит компании, поэтому нужно как-то изворачиваться и как-то абстрагировать и этот абстрактный код класть на гитхаб чиста для рекламы. У меня увы аккаунта нет, а нужно сделать, держу пари, что я теряю некий процент зарплаты от того, что недостаточно продавабелен в этом плане, нуна на ближайший год себе поставить соотв. задачу и забить гитхаб аккаунт примерами кода

Flat | Top-Level Comments Only

From:

malobukov

Проверить знания на собеседовании тоже нереально. Знаний слишком много для короткого интервью, поэтому проверка получается выборочная с очень небольшим размером выборки (пара вопросов), то есть лотерея. Кроме того, у людей очень разные представления о том, что должен знать "каждый образованный человек" / "любой толковый инженер" / "всякий уважающий себя архитектор". Меня, например, валили на незнании синтаксиса if first.group в SAS, потому что "каждый программист должен это знать".

Полезнее проверять соответствие написанного в резюме реальности. Раз кандидат пришёл на собеседование, значит его опыт по резюме соотвествует позиции (про интернов и выпускников пока для простоты забудем). Остаётся выяснить, насколько он преувеличил свои знания и заслуги.

Это решается тестированием вглубь. Тыкаем пальцем наугад в резюме, читаем, что в этом месте написано, и спрашиваем "Вот вы работали в example.com над повышением производительности сепуляторов, что такое сепулятор?" Потом делаем то же самое с ответом, рекурсивно. И так несколько раз. К тестированию вглубь сложно подготовиться зубрёжкой.

From:

Вопросы на энторвью

Page Summary

Style Credit

Expand Cut Tags