По моим впечатлениям очень многих людей интересует тема подготовки к собеседованиям в топ технические компании, поэтому решил вместо личных ответов написать одну статью на которую в дальнейшем буду ссылаться. Всем кому интересен процесс самого собеседования, вещи на которые нужно обращать внимание, как готовиться и к чему готовиться — добро пожаловать под кат.
До начала своей подготовки я решил выработать систему по которой я буду готовиться, а также список ресурсов, которые я буду использовать в процессе подготовки.
Первым шагом было определение того, что потребуется для прохождения собеседования, а для этого соответственно необходимо хорошо представлять какие вопросы встречаются на собеседованиях. После довольно быстрого прохода по результатам поиска гугла я наткнулся на эту книгу, которая является довольно полным сборником полезных советов и примеров заданий на тематику прохождения собеседований.
На данном этапе стоит упомянуть, что код в книге в основном написан на Java/C++, что делает ее довольно хорошо читаемой. Соответственно для более комфортного прохождения собеседования рекомендую решать все задачи на том языке, который планируете использовать во время собеседования.
После прочтения этой книги я смог определить список основных тем для подготовки.
Мой список выглядел примерно так:
Собственно о Big-O рассказывать особо нечего, нужно просто знать и понимать отличие вычислительной сложности разных алгоритмов, понимать как определять рантайм и расход памяти алгоритмов, знать базовые шаги к оптимизации алгоритмов и т. д.
О Big-O написано бесчисленное количество статей и книг, практически в любом входном курсе об алгоритмах есть лекции посвященные данной тематике. На хабре тоже есть цикл статей посвященный данной тематике habr.com/post/196560
Дисклеймер — мне лично пазлы на собеседовании не попадались, но я слышал, что могут попадаться.
То как я видел пазлы в плане подготовки — это фактически такие же алгоритмы, только без привязки к конкретной структуре данных или алгоритмической парадигме. Из-за этого систематизировать подготовку к пазлам довольно сложно. Лучшим решением, к которому я смог прийти — это просто «набить руку», решить 40-60 пазлов и в какой-то мере понять как подходить к решению пазлов. Со временем мозг начинает понимать, на что обращать внимание, а что является просто оформлением задачи: например все числа указанные в пазле как правило не просто так. Это не «просто 2 веревки» и не просто «сгорают за 25 минут». Как правило пазлы не содержат бесполезной количественной информации.
Понимание построение архитектуры приложений приходит с опытом положенным на знания. Довольно сложно стать хорошим архитектором только лишь об архитектуру и довольно неэффективно изучать архитектуру сугубо методом проб и ошибок. По этим причинам к архитектурной части собеседования довольно сложно «подготовиться». В какой-то мере подготовкой к этой части является вся ваша карьера. Но все же будет хорошей идеей освежить некоторые аспекты. Например: репрезентация архитектура. Даже те кто хорошо владеют UML в критический момент могут просто забыть некоторые детали представления или конкретные представления связей. Другим примером могут быть популярные паттерны проектирования. Несмотря на то, что они довольно часто используются, как правило, используются не все сразу и не по требованию предоставить знание о них здесь и сейчас. Постарайтесь выполнить несколько пробных раундов для самих себя и идентифицировать проблемные зоны.
Один из самых важных и самых проблемных моментов в собеседовании. На решение этих задач ставится некий упор и умение решать такие задачи быстро и эффективно — довольно важно.
Для подготовки я составил список структур данных и алгоритмов, которые встречаются наиболее часто и получилось что-то вроде:
В каждом из разделов есть несколько приемов, которыми просто нужно овладеть. Классическим примером такого приема может быть «медленный» и «быстрый» бегунок в Linked List. Не зная или не понимая этот концепт практически невозможно эффективно решать очень многие задачи на связанные списки. Или BFS/DFS алгоритмы поиска в графе. Как правило многие задания на интервью будут или модификаций известных концептов или же комбинацией нескольких. Поэтому очень критично научится самому решать и распознавать базовые задачи в каждой структуре данных/алгоритме.
Лично я посмотрел несколько лекций от Университета Стэнфорда, а после выписал себе ~5-10 заданий из каждой категории и просто набил руку таким образом. Это занимает много времени и сил, но в результате оно того стоит.
Вот несколько ресурсов которые я использовал для подготовки и поиска заданий:
https://www.quora.com — просто список из ~500 заданий на разную тематику, вместе с решениями на C++. Довольно удобно, иногда есть несколько решений, где одно более оптимальнее чем другое.
https://www.hackerrank.com — удобный ресурс с рубриками и тематиками и со встроенным компилятором для 20+ языков. Помогает быстро и эффективно набить руку.
https://www.glassdoor.com — содержит непосредственно вопросы из интервью и иногда ответы от сообщества.
Для меня этих двух было достаточно, но если вам нет — то эти 3 дадут хорошую идею о том где искать дальше.
Помните, что очень важно стараться самому прийти к ответу и решению, прежде чем смотреть подсказки. Таким образом вы на самом деле заставите себя думать и искать решение, т.е. непосредственно симулировать атмосферу интервью.
Не грешите использовать только компьютер для решения задач. Старайтесь тренироваться на доске или бумаге, т.к. многие компании проводят интервью именно так.
Вам может показаться, что это одно и тоже, но на деле практика на бумаге откроет множество сюрпризов, начиная от того что нужно вначале придумать все решение прежде чем писать (delete и backspace тут нет, удалять и перемещать строки очень затратно), а заканчивая тем, что место на листе/доске нужно грамотно экономить, т.к. оно ограниченно.
То на что обращают внимание во время собеседования — это уверенность и темп с которыми вы решаете задачи, продумывание всех возможных вариантов входных данных, обработка ошибок и различных состояний. Поэтому написать просто «рабочее» решение — недостаточно.
Хорошим советом так же будет писать компилируемый код. Да, бесспорно, главное — умение решить проблему и ее вариации и никто не будет обращать слишком много внимания на 1 пропущенную запятую, но это не должно входить в правило. Вы пишите код и реальные решения, не псевдокод и наброски.
Во время самого собеседование — старайтесь не замкнуть свою креативность, многие решения требуют подхода с нестандартного ракурса. Если замкнулись — не стесняйтесь просить помощи — это не сильно улучшит ваши шансы, но и стоять 45 минут молча тоже не стоит.
Возможно эта статья и не будет полным и исчерпывающим гайдом, но она позволит понять в каком направлении двигаться.
Удачи всем в подготовке.
Что есть в этой статье
- Программа подготовки
- Список ресурсов и статей
- Советы прохождения собеседования
До начала своей подготовки я решил выработать систему по которой я буду готовиться, а также список ресурсов, которые я буду использовать в процессе подготовки.
Первым шагом было определение того, что потребуется для прохождения собеседования, а для этого соответственно необходимо хорошо представлять какие вопросы встречаются на собеседованиях. После довольно быстрого прохода по результатам поиска гугла я наткнулся на эту книгу, которая является довольно полным сборником полезных советов и примеров заданий на тематику прохождения собеседований.
На данном этапе стоит упомянуть, что код в книге в основном написан на Java/C++, что делает ее довольно хорошо читаемой. Соответственно для более комфортного прохождения собеседования рекомендую решать все задачи на том языке, который планируете использовать во время собеседования.
После прочтения этой книги я смог определить список основных тем для подготовки.
Мой список выглядел примерно так:
- Big O
- Пазлы
- Архитектура приложений
- Алгоритмы и структуры данных
Big-O
Собственно о Big-O рассказывать особо нечего, нужно просто знать и понимать отличие вычислительной сложности разных алгоритмов, понимать как определять рантайм и расход памяти алгоритмов, знать базовые шаги к оптимизации алгоритмов и т. д.
О Big-O написано бесчисленное количество статей и книг, практически в любом входном курсе об алгоритмах есть лекции посвященные данной тематике. На хабре тоже есть цикл статей посвященный данной тематике habr.com/post/196560
Пазлы
Дисклеймер — мне лично пазлы на собеседовании не попадались, но я слышал, что могут попадаться.
То как я видел пазлы в плане подготовки — это фактически такие же алгоритмы, только без привязки к конкретной структуре данных или алгоритмической парадигме. Из-за этого систематизировать подготовку к пазлам довольно сложно. Лучшим решением, к которому я смог прийти — это просто «набить руку», решить 40-60 пазлов и в какой-то мере понять как подходить к решению пазлов. Со временем мозг начинает понимать, на что обращать внимание, а что является просто оформлением задачи: например все числа указанные в пазле как правило не просто так. Это не «просто 2 веревки» и не просто «сгорают за 25 минут». Как правило пазлы не содержат бесполезной количественной информации.
Архитектура приложений
Понимание построение архитектуры приложений приходит с опытом положенным на знания. Довольно сложно стать хорошим архитектором только лишь об архитектуру и довольно неэффективно изучать архитектуру сугубо методом проб и ошибок. По этим причинам к архитектурной части собеседования довольно сложно «подготовиться». В какой-то мере подготовкой к этой части является вся ваша карьера. Но все же будет хорошей идеей освежить некоторые аспекты. Например: репрезентация архитектура. Даже те кто хорошо владеют UML в критический момент могут просто забыть некоторые детали представления или конкретные представления связей. Другим примером могут быть популярные паттерны проектирования. Несмотря на то, что они довольно часто используются, как правило, используются не все сразу и не по требованию предоставить знание о них здесь и сейчас. Постарайтесь выполнить несколько пробных раундов для самих себя и идентифицировать проблемные зоны.
Алгоритмы и структуры данных
Один из самых важных и самых проблемных моментов в собеседовании. На решение этих задач ставится некий упор и умение решать такие задачи быстро и эффективно — довольно важно.
Для подготовки я составил список структур данных и алгоритмов, которые встречаются наиболее часто и получилось что-то вроде:
- Arrays
- Strings
- Binary Tree
- Binary Search Tree (BST)
- Graphs
- Heaps
- Linked List
- Matrix
- Stack
- Queue
- Trie
- Backtracking
- Divide & Conquer
- Dynamic Programming
- Sorting
- Greedy
В каждом из разделов есть несколько приемов, которыми просто нужно овладеть. Классическим примером такого приема может быть «медленный» и «быстрый» бегунок в Linked List. Не зная или не понимая этот концепт практически невозможно эффективно решать очень многие задачи на связанные списки. Или BFS/DFS алгоритмы поиска в графе. Как правило многие задания на интервью будут или модификаций известных концептов или же комбинацией нескольких. Поэтому очень критично научится самому решать и распознавать базовые задачи в каждой структуре данных/алгоритме.
Лично я посмотрел несколько лекций от Университета Стэнфорда, а после выписал себе ~5-10 заданий из каждой категории и просто набил руку таким образом. Это занимает много времени и сил, но в результате оно того стоит.
Вот несколько ресурсов которые я использовал для подготовки и поиска заданий:
https://www.quora.com — просто список из ~500 заданий на разную тематику, вместе с решениями на C++. Довольно удобно, иногда есть несколько решений, где одно более оптимальнее чем другое.
https://www.hackerrank.com — удобный ресурс с рубриками и тематиками и со встроенным компилятором для 20+ языков. Помогает быстро и эффективно набить руку.
https://www.glassdoor.com — содержит непосредственно вопросы из интервью и иногда ответы от сообщества.
Для меня этих двух было достаточно, но если вам нет — то эти 3 дадут хорошую идею о том где искать дальше.
Помните, что очень важно стараться самому прийти к ответу и решению, прежде чем смотреть подсказки. Таким образом вы на самом деле заставите себя думать и искать решение, т.е. непосредственно симулировать атмосферу интервью.
Не грешите использовать только компьютер для решения задач. Старайтесь тренироваться на доске или бумаге, т.к. многие компании проводят интервью именно так.
Вам может показаться, что это одно и тоже, но на деле практика на бумаге откроет множество сюрпризов, начиная от того что нужно вначале придумать все решение прежде чем писать (delete и backspace тут нет, удалять и перемещать строки очень затратно), а заканчивая тем, что место на листе/доске нужно грамотно экономить, т.к. оно ограниченно.
То на что обращают внимание во время собеседования — это уверенность и темп с которыми вы решаете задачи, продумывание всех возможных вариантов входных данных, обработка ошибок и различных состояний. Поэтому написать просто «рабочее» решение — недостаточно.
Хорошим советом так же будет писать компилируемый код. Да, бесспорно, главное — умение решить проблему и ее вариации и никто не будет обращать слишком много внимания на 1 пропущенную запятую, но это не должно входить в правило. Вы пишите код и реальные решения, не псевдокод и наброски.
Во время самого собеседование — старайтесь не замкнуть свою креативность, многие решения требуют подхода с нестандартного ракурса. Если замкнулись — не стесняйтесь просить помощи — это не сильно улучшит ваши шансы, но и стоять 45 минут молча тоже не стоит.
Возможно эта статья и не будет полным и исчерпывающим гайдом, но она позволит понять в каком направлении двигаться.
Удачи всем в подготовке.
Комментарии (34)
Vahman
02.02.2019 09:35Несмотря на то, что они довольно часто используются, как правило, используются не все сразу и не по требованию предоставить знание о них здесь и сейчас
Во время самого собеседование — старайтесь не замкнуть свою креативность
Какой-то непроверенный автоперевод
PavelGatilov Автор
02.02.2019 10:54+1Это скорее из меня писатель никудышний.
Vahman
02.02.2019 21:08Прошу прощения в таком случае) первую фразу я в итоге смог переварить, но насчёт замыкания креативности — в мемориз))
alaudo
02.02.2019 15:58Из моего опыта проведения собеседований, кандидаты так сильно готовятся и изучают всякие там tries, или red-black trees, что они им потом везде и мерещятся, и на собеседовании вместо того, чтобы использовать что-то простое (обычный hashmap или heap) они начинают писать такое решение, что у интервьюера сначала глаза на лоб лезут, а потом начинается грустная фаза, когда кандидат либо сам запутывается в этом, либо выдает такое запутанное решение, которое потом очень трудно протестировать…
PavelGatilov Автор
02.02.2019 16:25Это сразу сильный минус. Очень большая часть оценка — поиск оптимального решения. Если человек не понимает преимуществ той или иной структуры даных, то он как правило просто зазубрил несколько решений и на деле не понимает что происходит на самом деле.
alaudo
03.02.2019 00:37Ну почему это сразу сильный минус? Человек готовился, видно, прочитал всякие там Cracking the coding interview, потренировался на Leetcode. Если он до этого был адекват, то это только в плюс.А если нет — то, увы, минус. Но обычно после 4-5 проваленного собеседования потихоньку приходит понимание, ну или наконец-то бешенное решение на tries устраивает интервьюера :)
Gorthauer87
Вот они любят задачи на всякие структуры и алгоритмы, а потом вообще ни раз не предлагают ничего близкого к ним в время работы. А вместо этого какая то рутина.
olegshutov
Так в первую очередь проверяют лояльность. Если человек зазубрил всю эту хрень по запросу, то и другой будет заниматься не спрашивая зачем.
Gorthauer87
Тогда очень тяжело быть человеком, которому это все интересно, ты приходишь этот тест на лояльность, а оказываешься не в своей тарелке.
Бред все это, задачи должны быть хотя бы отдаленно похожи на боевые.
PavelGatilov Автор
Никто не проверяет таким образом лояльность, что за глупости.
alaudo
Нет, это не лояльность, это способность человека оценить свое решение и сравнить его с другим решением.
Зачастую для решения проблемы возможно не одно, а десяток возможных решений («в лоб», более закрученное, с экономией памяти и так далее), и умение кандидата оценить «качество» решения и его сильные и слабые стороны потом очень полезно в работе, когда где-то нужно «просто и в лоб», а где-то «как можно оптимальнее».
PavelGatilov Автор
Именно это. Плюс я вижу алгоритмы как базовую способность рационально мыслить. Я никогда не был впечатлен собеседованиями где спрашивается конкретные знания конкретных программных фреймворков. Фрэймворки меняются, приходят новые, забываются старые. То что я хорошо владею конкретным — абсолютно не отражает моих способностей как программиста.
olegshutov
Как уже говорилось, ничем подобным человек на работе не занимается. И в местах, где люди действительно что-то жутко алгоримическое делают, на задачу отводится далеко не 15 минут. Сейчас я оценивая время на нахождение решения одной задачи в два месяца. На решение одной очень сложной задачи у меня ушло 2 года. Пытаться что-то решать на собеседовании и длеть вид, что ты это не по памяти пишешь, это полнейшая хрень.
PavelGatilov Автор
Ну может вы не занимаетесь, а очень много кто — занимается.
Не вижу где вы нашли в статье что-то «жуткое». Там же базовые задачки спрашивают. Никто не будет у вас фибоначчиевы кучи спрашивать. И если вы не можете решить базовую алгоритмы за 15-45 минут значит не готовы работать в компании где эти навыки являются фронтовыми.
Неспорно, сложные и объемные задачи могут занимать много времени, планировки и разработки, но вставка элемента в BST к ним не относится.
PavelGatilov Автор
С чего вы взяли, что не предлагают ничего близкого во время работы? Куча команд которые работают в инфраструктуре и оптимизации различных алгоритмов или создание новых — типичная задача.
А во вторых алгоритмы и структуры данных довольно неплохая область базовых знаний, где можно проверить интеллектуальные способности кандидата.
olegshutov
Вы готовитесь правильно. Но есть одна вещь, которую надо держать в уме… Компании делятся на те, кто проводит собеседования по такому формату «вузовского экзамена» и на те, кто собеседует по-другому. Первая группа делится на старые компании, основанные 20 лет назад и более, где большинство программистов программируют в аутлуке и на совсем новые, где это просто карго-культ подражания первым. Этот формат собеседования появился в 90ых и надо быть очень деревянным, чтобы не адаптировать его к современности. В компании и самые интересные команды для профессионального роста, контор вы таким образом не попадаете. Хотя, в общем, само название статьи и говорит о том, что это собеседовании для старперских контор и команд внутри них, застрявших в прошлом
PavelGatilov Автор
Не знаю, если вы называете Google/Facebook/Amazon/Twitter старперскими, то это конечно ваше право, но по моему опыту работы в этих компаниях впечатление абсолютно противоположное. Есть безумное количество примеров где именно эти компании задают то как индустрия выглядит и в каком направлении развивается.
olegshutov
А, вы эти компании, чтоли называете большой пятеркой. Я думал, это про Россию. Ну, я работал там, куда вы попасть собираетесь, и куда моих друзей там работает. Деньги хорошо платят. Найти нормальный проект сложнее, чем розу в куче гавна, со слов самого же руководителя Микрософта. Конечно, старперские, кто ж сомневается. У меня туда как-то попал друг, который до этого сторожем на консервном заводе работал. Сиди себе на митингах, да письма пиши, вот и вся работа программиста в таких конторах в основном.
Поэтому готовьтесь тщательно, знайте, что будете конкурировать на собеседовании вот с такими вот сторожами с завода, которые выучили все вопросы наизусть. Ну и самое главное — изучайте лояльность и позитив. Правильными ответами вы никого не удивите, они двадцать лет подряд слушают одни и те же ответы на одни и те же вопросы. Это программа-минимум.
PavelGatilov Автор
Мда, я даже не знаю что ответить, даже не знаю с какого предложения начинать, но кроме возможно фразы о Майкрософте абсолютно все на 180 градусов противоположно.
> Конечно, старперские, кто ж сомневается
Я сомневаюсь. Определите старперские. Что конкретно входит в это определение? Мне очень интересно почему вы например Google или FB называете старперскими?
> У меня туда как-то попал друг, который до этого сторожем на консервном заводе работал
А это тут при чем? Я например когда-то работал на мойке машин, и что? Время разное, люди учатся, меняются. Но факт остается фактом в 2017 FB был лучшим местом для работы в мире, Google был в первой 5-ке.
> Сиди себе на митингах, да письма пиши, вот и вся работа программиста в таких конторах в основном.
Абсолютнейший бред.
> Ну и самое главное — изучайте лояльность и позитив.
Да пофиг всем на лояльность, половина разработчиков с кем из FB общался — сделали аккаунт в сети перед началом работы. И никто особо не скрывает этого.
> Правильными ответами вы никого не удивите, они двадцать лет подряд слушают одни и те же ответы на одни и те же вопросы. Это программа-минимум.
То то мы меняем пул вопросов каждые 3 недели, видимо зря.
olegshutov
>>Я сомневаюсь. Определите старперские. Что конкретно входит в это определение? Мне очень интересно почему вы например Google или FB называете старперскими?
ну, в Гугле, например, до сих пор не знают о выходе стандарта С++98. Недостаточно старпески? А в Фейсбуке, например, forced curve, от которой даже мс отказался. Как может быть компания с forced curve лучшим местом для работы в мире? Чего смеяться-то. Эта система всегда создает специфисськую атмосферу в офисе. Как, кстати, в вашей команде идет выполнение норматива по увольнениям и повышения?
Самое неприятное, конечно, в Гугле вас позадят за задачу пофиксить баг с лишним пикселом в отображении какого-нить древнеарабского шрифта в гмейле, а в Фейсбуке кроме работы по втюхиванию рекламы ничего и нет. Кстати, как и в Гугле по большому счету.
>>То то мы меняем пул вопросов каждые 3 недели, видимо зря.
Никогда еще в истории собеседований меня или других в эти конторы не было вопроса, который раньше мы не слышали. Одни и те же вопросы ходят по кругу уже 20 лет минимум, с тех пор как гугловцы сперли их из Стенфордских экзаменов. Формат собеседования фейсбука, кстати, отличаетяс от гугловского и это плюс FB, но не на столько, чтобы это было нельзя обойти просто выучив заранее стандартные ответы.
Из-за этого даже на сеньерских позициях оказываются люди, которые нигде, кроме аутлука на программировали. Недавнаяя совсем история из офис большой пятерки — взяли девушку, она нашла парня в офисе, чтобы он за нее все делал. вообще, при определенных договоренностях с менеджером (откаты, кстати, тоже бывают) можно вообще ничего не делать.
PavelGatilov Автор
> ну, в Гугле, например, до сих пор не знают о выходе стандарта С++98.
Вау, серйозно, упрекание Гугла в использовании C98? Компания которая разработала 2 абсолютно новых языка программирования только в последние 10 лет?
> А в Фейсбуке, например, forced curve, от которой даже мс отказался.
Не натуральная а своя версия, и даже если и была бы оригинальная, то не особо вижу в этом проблему.
> Как может быть компания с forced curve лучшим местом для работы в мире?
По общему голосованию сотрудников. Не думаете что performance management — не является единственным критерием компании?
> Как, кстати, в вашей команде идет выполнение норматива по увольнениям и повышения?
Первый раз об этом слышу. Тяжело находить новых кандидатов — это да, плановые увольнения и повышения — это какой-то неслыханный бред.
Самое неприятное, конечно, в Гугле вас позадят за задачу пофиксить баг с лишним пикселом в отображении какого-нить древнеарабского шрифта в гмейле, а в Фейсбуке кроме работы по втюхиванию рекламы ничего и нет. Кстати, как и в Гугле по большому счету.
> Самое неприятное, конечно, в Гугле вас позадят за задачу пофиксить баг с лишним пикселом в отображении какого-нить древнеарабского шрифта в гмейле, а в Фейсбуке кроме работы по втюхиванию рекламы ничего и нет. Кстати, как и в Гугле по большому счету.
Когда начал работать в ФБ на выбор только в сателитном офисе было более чем 15 команд, сам выбираешь в какую конкретно идти. Да есть команды которые заняты рекламой, но их не более 10-15%.
> Из-за этого даже на сеньерских позициях оказываются люди, которые нигде, кроме аутлука на программировали.
Видел много разных сеньоров и в ФБ и нет, ни разу ни видел тех кто программировал бы только в аутлуке.
olegshutov
>>Вау, серйозно, упрекание Гугла в использовании C98? Компания которая разработала 2 абсолютно новых языка программирования только в последние 10 лет?
они пользуются C++ до 98. У нас в компании старпером могут назвать того, что не принимает С++11. В Гугле не воспринимают С++98. Они старпернее старперов. То есть они как бы молодцы, разработали много нового, хотя, конечно, почти все просто купили, но это не отменяет их старперства.
>>Не натуральная а своя версия, и даже если и была бы оригинальная, то не особо вижу в этом проблему.
оригинальная версия в любой сложившейся комагде (работающей больше 2 лет) приводит к найму людей, чтобы было кого уволить и к договорной очереди на повышение, согласуемой втихаря с начальником. Все это для выполнения плана увольнений и повышений, спускаемых сверху. Действительно, какие тут проблемы можно увидеть.
>>По общему голосованию сотрудников. Не думаете что performance management — не является единственным критерием компании?
В Лондоне — может быть. Может быть альтернатива у вас там гробы копать. Ну и вообще лидер Северной Кореи имеет куда большую поддержку населения, чем любой другой. Не надо доверять голосованиям буквально. Например, очень сложно получить какой-то фидбек от гугловцев, очень мало даже в профилях пишут, что там работают, так как тех увольняют сразу за любой чих неправильно произведенный. Поэтому конечно же разумно при голосовании размахивать флагом и славить компанию.
PavelGatilov Автор
Не вижу с вами смысла спорить дальше. Изначальная статья даже не поднимала половину вопросов которую вы пытаетесь обсудить в дискуссии. Не нравятся топ компании, сложилось у вас о них определенное мнение — ваше право, остальные найдут что-то полезное в этой статье. Не знаю откуда у вас сложившееся впечатления, но из моего личного рабочего опыта в этих компаниях все выглядит совершенно по другому. А после вашего предложения про гробы — вообще смахивает на то что вы просто тупой троль, но кто знает, может действительно считаете, что копать гробы в Лондоне это норма.
olegshutov
Человека может разозлить только вещь, которая хотя бы от части правда. Я никогда не был в Лондоне, я не знаю честно чем еще там можно заниматься, а том и написал. Но, вообще, ИТ там конечно куда более дохлое, чем в Америке, кто ж этим поспорит + непонятная политическая ситуация. И карьера гробокопателя начинает выглядть хорошим и перспективным предложением.
Мой первый коммент был о глубоких причинах, по которой в этой конторах спрашивают всю эту вот фигню. Человек, понимающий эти причины, куда проще пройдет собеседование, что я всем пытающимся это сделать и желаю. На мой было несколько наивных комментов, в духе там, мол, Сталин думает о вас в Кремле, на что я примерами попытался наивность людскую немного пошатнуть. Дед Мороза нет, папа прет маму — такой, детский викиликс.
PavelGatilov Автор
Не особо понял к чему это? Вы предполагаете, что каким-либо образом разозлили меня? ОМГ.
Основанных на неверных предположениях.
roscomtheend
Правда — существует компания "Гугл". Разозлить бездоказательными заявлениями (типа процитированного)? Очень смешно, есть ещё более бредовые заявления и влияющие на жизнь сильнее, чего злиться на чтьи-то фантазии, от которых реальность никак не зависит?
PavelGatilov Автор
Плюс просто для референса, гугл использует С++11 как основную версию С++ для разработки, в данный момент агрессивно проходит адаптация С++14, не то что это было бы сильно важно, но вас видимо С++98 сильно задел
olegshutov
То есть они уже начали использовать STL и исключения? Ничего себе, какой прогресс. А пару лет назад такого не было. Или они называют С++11 нечто без STL и исключений?
alaudo
У вас что ни компания — то какие-то прямо недалекие люди везде, и работы нормальной нет, и вопросы на собеседованиях задают дурацкие (да и те у кого-то украли). Пассаж про «руководителя Майкрософт» вообще непонятен.
Вы там везде поработали и говорите из собственного опыта, или это как в анекдоте «Рабинович напел»?
olegshutov
Я исключительно за то, чтобы больше людей, прочитавших эту статью, прошли собеседование и стали успешно работать в этих компаниях. Но для этого нужно знать не только ту идеализированную картинку, которую пытаются нарисовать эти компании.
При найме в Амазон никто вас не предупредит заранее, что ваш бейджик будет выглядеть, как надробный камень. Думаю, у многих это вызывает шок и даже существуют люди, которые там не хотят работать только из-за этого.
Слова любой компании этой самой большой пятерки часто расходятся с делом. Вот буквально пару недель назад в одной из этих контор внутренний документ об одной полиси каким-то образом попал к рядовым сотрудникам и вызвал бучу на всю контору, мол, почему вы нем врете. Разумеется, ничего из этого в СМИ не попало. А зря.
Не надо идеализировать компанию, или даже буквально воспринимать все, что она говорит официально, изучайте ее сильные и слабые стороны и специфику работы в ней, вот и все.
vassabi
это вы не туда ходите собеседоваться — меня иногда спрашивали небольшие алгоритмы, и везде было что-то алгоритмически интересное (2д — 3д карты, трассировка, сортировка, различные оптимизации БД, сжатие данных. И это НЕ гугл\фб\мс\прочая).
Хотя не спорю — 90% времени на работе тратится на «сделайте кнопку Х на 10 пикселей длиннее» (просто потому, что пользователь это видит, в отличии от алгоритмов внутри).