Get that job at Google - очень интересная статья с советами по поводу того, как проходить собеседование в Гугле. И она не зря такая популярная, она действительно очень хорошо и вдумчиво написана. Там рассматривается процесс собеседования в принципе, и даются советы, которые подойдут для прохождения собеседования в любых программерских компаниях.

Компании наподобие Гугла ставят высокий барьер, при отборе кандидатов. Лучше отказать квалифицированному кандидату, чем взять на работу неквалифицированного.

Спорный вопрос, но думаю, Гуглу виднее.

Не стоит переживать, если вас не взяли на работу. Причинами для этого могут быть:

1. у вас был просто неудачный день
2. у вашего интервьювера был просто неудачный день
3. вы просто не поняли друг друга (вас и интервьювера) на собеседовании
4. вам не повезло и вы попали на Interview Anti-Loop

Полностью согласен с автором. Не стоит волноваться и во время собеседования – это может понизить ваши шансы на успех.

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

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

На собеседование необходимо всегда приходить подготовленным.

Даже если вы лучший программист в своей компании, если вы уже долгое время успешно пишите крупный и сложный проект, это вовсе не значит, что вы сможете ответить на все вопросы интервьювера. Ведь удержать в голове знания всех алгоритмов, технологий и подходов с которыми вы сталкивались невозможно. А если на каждый второй вопрос вы будете отвечать: “Да я сталкивался с этим, но это было очень давно и сейчас я не могу ответить на ваш вопрос.”, – то у интервьювера сложится впечатление, что вы самоуверенный, высокомерный и ничего не умеющий джуниор. Поэтому необходимо освежить память перед собеседованием.

Шаг 1 – Изучить теорию алгоритмов и структур данных . Зачем? Потому что это поможет вам распознать проблему, которую вам предлагают решить на собеседовании. Большинство интервьюверов любят, когда их вопрос понимают без дополнительных пояснений. К примеру, если вас попросили разукрасить флаг Штатов, то вашим большим плюсом, будет увидеть в этом вопросе проблему раскрашивания графа. А если вы еще вспомните и решение данной проблемы, то ваши шансы пройти собеседование резко повысятся.

Основные вещи, которые должен знать и понимать любой программист: оценка сложности алгоритмов, различные алгоритмы сортировки, хэш-таблицы, деревья, графы (поиск в ширину, поиск в глубину), NP-полные задачи. Вам необязательно реализовывать все это в повседневной работе (реализация этих вещей уже есть в большинстве фреймворков), но понимать как это работает просто необходимо.

Автор рекомендует две книги для подготовки в области теории алгоритмов и структур данных: The Algorithm Design Manual Стивена Скинса и Introduction to Algorithms Томаса Кормена. От себя порекомендую Алгоритмические трюки для программистов Генри Уоренна и Алгоритмы: построение и анализ того же Т. Кормана. В свое время эти книги помогли мне занимать призовые места на национальных соревнованих по программированию.

Шаг 2 – Попросите товарища прособеседовать вас. Друг должен задавать вопросы из различных областей. И вы должны отвечать на них, не важно насколько вы устали или просто ленитесь на них отвечать.

Это не только поможет вам освежить память в тех областях, с которыми вы работали давно, но и позволит вам научиться формировать точный и ясный ответ. Мне часто приходится видеть на собеседованиях, что человек понимает о чем идет речь и даже знает ответ на мой вопрос, но он попросту не может внятно сформировать свой ответ. Возможно это издержки технической профессии – недостаток повседневного общения.

Не ведите себя высокомерно на собеседовании. Лучший способ показать свое высокомерие – поставить под сомнение профессионализм собеседника, поэтому никогда не спрашивайте: “Вы действительно считаете, что все эти алгоритмы важны? Вы полагаете их стоит использовать в реальной жизни? Никогда не слышал о подобном подходе…”. Лучше просто признаться, что вы не знаете или не помните ответ на этот вопрос. Также, не бойтесь попросить подсказку или помощь при ответе на вопрос – некоторые интервьюверы любят, когда их талант признают и просят у них помощи.

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

Некоторые интервьюверы не просят написать кусочек кода, но в вопросе подразумевают, что это было бы лучшим ответом. В этом случае, лучше спросить. Также можно поинтересоваться отношением интервьювера к коду – будет ли он переживать по поводу того, что синтаксис не везде будет соблюдаться? Некоторые интервьюверы равнодушны к синтаксису, полагая, что главное это общее понимание решения и алгоритм. Другие же, напротив – придираются к пропущенной точке с запятой или незакрытой скобке. Но не стоит и сразу бросаться в бой, писать код, даже если вы знаете правильный ответ. О вас может сложиться мнение, что вы сразу беретесь за реализацию, игнорируя этап проектирования. Лучше спросить.

В качестве одного из советов для технической подготовки к собеседованию, автор далее дает совет получить техническое образование. Я, как человек обладающий подобным образованием, могу с уверенностью заявить – в нашей стране это вовсе необязательная вещь. Еще ни на одном из собеседований, на которых мне довелось побывать (а их уже наберется с два десятка), меня не спросили о моем высшем образовании. Единственный раз меня спросили пару лет назад – не являюсь ли я студентом и если да, то буду ли брать отпуск на время сессии… Все.

Интересным и несколько необычным мне показалось еще и то, что в Гугле проверяют базовые знания математики. Вообще-то не только в Гугле, но и в Мелкософте такое практикуют, просто я никогда не слышал о подобных вопросах при приеме на работу в украинские ИТ-компании.

Операционные системы. Большинство интервьюверов спрашивают в основном фундаментальные вещи: что такое процесс, потоки, какие ресурсы им необходимы, как работает переключение контекста, как происходит инициализация операционной системы и подключенного оборудования, что такое concurrency issues и т.п. Также вы должны знать, что такое locks, симафоры и мониторы и как они работают. Могут спросить, что такое deadlocks и livelocks и как их избегать.

Лучшая книга, которую я прочитал на эту тему – Concurrent Programming in Java Дуга Ли.

В некоторых компаниях меня спрашивали не только о различных семействах операционных систем(MacOS, Linux, Windows), но и отличия версий в одном семействе (Windows XP и Windows Server 2003).

Языки программирования. Вы должны знать хотя бы один язык программирования хорошо и лучше всего, если это будет С++ или Java. С# тоже подойдет, так как он похож на Java. И вы должны быть готовы написать идеальный кусок кода на этом языке.

Честно говоря, я думал, что к этому списку еще добавиться Perl. Но автор оставил его почему-то без внимания.

Итак, предупрежден – значит, вооружен! Но даже если после такой подготовки вы не прошли собеседование – не расстраивайтесь, ведь всегда можно попробовать еще раз (…через полгода).

Ссылки по теме

Одна история неудачного собеседования в Гугл

Записки русского программера из Гугля

How I Blew My Google Interview

My interview experience with Google

My interview at Google

Google's Interview Questions

Google Top Interview Questions ( around 30 With Solutions)

Google Interview for Freshers

    Вы собеседуете кандидатов на одну из вакансий в вашей компании. Кого вы пытаетесь разглядеть в этих людях? Большинство менеджеров на подобный вопрос отвечают: трудолюбивого, настойчивого, уверенного в своих знаниях и ответственного. Замечательные слова! И как после такого набора характеристик можно взять не того человека? А ведь умудряются… Дело в том, что все эти черты, вовсе не являются гарантом хорошей производительности сотрудника.

    Мы знаем, что люди ведут себя по-разному в различных ситуациях, и мы склонны разделять людей по их характерным особенностям и способам поведения. Во время собеседования менеджер/технический специалист слушают и наблюдают за кандидатом, чтобы определить обладает ли он необходимым набором знаний или нет, уверенно ли он отвечает на вопросы, как будет вести себя в различных ситуациях.

- Проект имеет старую и громоздкую архитектуру. У вас есть задача, вы можете написать красивый код за 40 часов (придется переписать плохие участки старого кода), либо написать коряво (но работать будет) за 15 часов. Как бы вы поступили?

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

- Я пишу код всегда правильно и красиво, ведь дурно «пахнущий» код – источник багов.  – скажет вам кандидат, пытаясь произвести на вас впечатление правильного сотрудника. В чем-то он прав, но вы-то не это хотели от него услышать, верно?

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

    Так как же оценить кандидата? Попробуйте дать оценку не тому, как бы он поступил, а тому, как он поступал в различных ситуациях. Расспрашивая о прошлом кандидата, вы возвращаете его в старый, привычный для него офис, усаживаете в любимое кресло, с отломанной левой ручкой и «подаете» горячий, пусть и дешевый, ароматный кофе. И кандидату уже не нужно напрягаться, придумывать, как бы выкрутиться из вновь сложившейся ситуации. Он просто рассказывает вам о своем опыте и говорит, как было. Только выводы вам теперь сделать сложнее – приходится читать между строк, но это уже тема другой статьи…

    Таким образом, вопросы ориентированные на прошлое кандидата расскажут вам больше, чем искусственная, смоделированная ситуация на собеседовании.

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

Факт #1: При взлете с воды, каждый гусь бьет крыльями по поверхности воды, таким образом стая формирует воздушный поток, который облегчает взлет отдельно взятой особи на 71%.

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

У меня был опыт работы в нескольких командах разработчиков. Опишу лишь две из них:

1. Первая команда состояла всего из 3–х участников. Это неплохие, умные и скромные ребята. У каждого участника был огромный опыт работы с необходимыми технологиями. Но прежде эти люди вместе никогда не работали.

2. Вторая команда состояла уже из 4–х участников-новичков, и о них можно было сказать следующее: настоящие товарищи, хотя раньше им вместе работать также не приходилось. Работа в этой команде всегда была оживлена беседами “не по работе” и в компании этих людей было просто приятно находиться.

Артем Попов. © «Ашманов и Партнеры»

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

Вторая команда своей цели тоже не достигла, но причины для этого у нее были другие: продукт, который она выпустила, кстати сказать всрок и с оговоренным функционалом – было невозможно продать т.к. мы выбрали неверную модель продаж.

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

Факт #2: Гуси никогда не нарушают строя во время полета, потому что знают – в противном случае, сопротивление воздуха на каждую особь увеличится и стая скорее всего не долетит до цели – сил не хватит.

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

Приведу еще один пример из своего личного опыта. В то время жизнь казалось трудной, но и захватывающе интересной, впереди было много тяжёлой работы и грандиозных задач. Перед нашей командой была поставлена цель – реализовать модуль одного большого проекта, причем в срок. В моей команде тогда работали два программиста. У каждого из них были цели, о которых я даже и не подозревал. Целью первого, назовем его Богач, было заработать как можно больше денег, поэтому он с удовольствием соглашался на работу в овертайм. Целью же второго – Идеалиста, было написание совершенного кода, этот человек всегда и во всем стремился к идеалу. Моей же целью было – выполнить проект в срок. События развивались далее следующим образом: Богач делал работу неспеша и к идеалу в коде особо не стремился – а зачем? за это больше не платят… Идеалист же наоборот – переписывал свой код по-нескольку раз, вызвая задержки со сдачей своих задач. Я, не подозревая о целях каждого, старался сделать каждую задачу как можно быстрее и по-возможности без багов . Как вы понимаете, сроки мы сорвали.

Опыт опять отрицательный, но все же опыт. Если бы я знал о целях каждого из участников и имел возможность распоряжаться бюджетом проекта, то в качестве одного из вариантов решения этой задачи можно рассмотреть следующее: уменьшить ставки разработчиков и ввести премиальную систему с идеологией – чем быстрее сделал(с определенным процентом багов), тем больше заработал. Этим можно было бы достичь большей производительности от Богача и пересмотра своих амбиций у Идеалиста.

Факт #3: Когда гусь-лидер устает(он ощущает наибольшее сопротивление воздуха), то он занимает место в конце строя, а на его место становится другой.

Вывод: Имеет смысл разделять любую трудную/нудную работу между всеми учатниками команды. Также полезно разделять и лидерство.

Артем Попов. © «Ашманов и Партнеры»

Компания, где наша команда работает в данный момент занимается самыми различными проектами. В том числе и проектами на старых технологиях. Конечно же никому не хочется вспоминать ASP.NET 1.1 и разбираться в багах старого проекта. Но эффективная командая работа – это постоянное динамическое равновесие между общими потребностями команды и личными потребностями ее учатсников. Быть среди людей и работать вместе с ними – здорово. Но все мы, каждый из нас, все равно хотим быть Номером Один. Забудьте обо всех этих киношных сценах, где солдаты бросаются грудью на амбразуру, чтобы защитить своих товарищей. В реальной жизни мы сотрудничаем с другими в первую очередь ради того, чтобы удовлетворить свобственные потребности. Люди соглашаются работать в команде только при словии, что в первую очередь это поможет им удовлетворить собственные потребности.

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

Факт #4: Гуси, летящие в строе, всегда кричат, если впереди летящие сбавляют скорость. Таким образом поддерживается строй во время полета.

Вывод: Участники команды должны прислушиваться друг к другу, чтобы знать что они двигаются в правильном направлении.

В одной из компаний, где мне довелось работать раньше, был такой случай. Стоял теплый июнь месяц, все прятались за плотными жалюзями и в обществе кондиционеров. Вот только комната, где сидела наша команда, располагалась таким образом, что солнце никогда не скрывалось у нас из виду, раньше чем наступала ночь… Именно тогда нам и пришла в голову мысль, попросить у руководства денег на жалюзи и кондиционер. Это происходило примерно следующим образом:

– Нам жарко, поставьте нам кондиционер и повесьте жалюзи. 

– Эмм, а у нас не жарко. Да и зачем вам сразу жалюзи и кондиционер? Выберите что-то одно.

– Жалюзи спасут нас от бликов на мониторах и мы сможем видеть, что кодим. А кондиционеры позволят нам соображать быстрее.

– Хм, мы вас конечно понимаем, но деньги кончились…

(тем временем наступил знойный июль и мы заклеили окна газетной бумагой).

– Как там с деньгами? Появились? У нас техника отказывает, но коллектив – держится.

– Денег по-прежнему нет. Молодцы, что держитесь. А тяжелые времена пройдут. (хотя жалюзи нам, после приезда одного из менеджеров, всеже повесили)

Казалось бы, условия труда – это то, на что большие компании(а компания была ооочень большая) тратят деньги легко и всегда, но нет – компания предпочла выкупить еще два соседних помещения на “перспективу”…

(прошел июль, а за ним и август. Наступила ласковая осень)

– Ха! Просили кондер – а мы вам никогда не откажем. Нате – получите.

– ???

– Все ради сотрудников, все ради вас.

Хоть наши просьбы в конечном счете были выполнены, но авторитет руководства уже был ниже ватер-линии и один сотрудник успел покинуть нашу команду.

Факт #5: Когда один гусь заболевает или получает ранение, еще двое его товарищей покидают строй и следуют за ним, чтобы помочь или защитить раненного. Они находятся с ним до тех пор пока он либо не умрет, либо не выздоровет. После чего они либо присоединяются к следующей стае, либо догоняют свою.

Вывод: Друг познается в беде…

Артем Попов. © «Ашманов и Партнеры»

P.S.

Иллюстрации к данной статье были скромно позаимствованы у Артема Попова из книги Ашманова “Жизнь внутри пузыря”. Кто еще не читал – настоятельно рекомендую. Книга будет очень полезна менеджерам, да и просто участникам каких-либо сообществ. Одним словом – всем.

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

• Первое и самое главное - это безусловно опыт, потому что если вы уже реализовывали подобное в ваших предыдущих проектах, то вероятность того что ваша оценка совпадет с реальностью увеличивается.
• Далее необходимо  разбить будующий функционал на как можно более независимые блоки их можно разрабатывать в различных фазах проекта.
• Затем каждый блок разбивается на функционал, время реализации котрого не более 3х часов.
• Если какие-либо части настолько сложны или новы для вас, что вы не представляете себе как их реализовывать, то лучше потратить час-два на изучение/поиск подобных решений в гугле. Кстати,забыл сказать, что прежде чем вообще садиться оценивать проект, можно посмотреть не реализовывал ли кто-то другой, то что вы сейчас пытаетесь создать. Свой опыт ценне всего, но если есть чужой, то почему бы им не воспользоваться?
• Еще один момент - оценивать проект лучше не в одиночку(какой бы вы гуру ни были), а небольшой группой в 2-3 человека. Если количество людей будет больше, то будет слишком много мнений и тяжело будет быстро прийти к компромиссу, а следовательно быстро оценить проект (за оценку проекта заказчик как правило не платит...). Если людей будет меньше, а именно вы один, то есть риск переоценить или недооценить собственные силы.
• Но даже разбив проект на мелкие части и оценив каждую из них, мы не сможем получить точную оценку проекта(честно говоря получить точную оценку проекта невозможно в принципе), так как еще необходимо учесть человеческий фактор, а он предполагает чтот в рабочем 8ми часовом дне вовсе не 8 часов отдается работе:

  - Чтение блогов и новостей, разгребание почты по утрам. (15 минут в день)

  - Перерывы на кофе/чай. (2-3 в течении дня 10 минут на каждый)

  - Различного рода собрания. Проектные собрания для решения текущих вопросов. (дважды в неделю 3 часа)

  - Решение проблем с железом, не работает комп или сеть или нет тока. (раз в две недели пол дня)

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

  - Заполнение time journal-ов и других формальных документов. (15 минут каждый день)

  - Походы в WC. Да, это тоже занимает время. (10 минут в день. В дни когда селедку запиваешь с молоком 10 минут каждый час ;)

  - Написание необходимых емейлов (4 часа в неделю)

  - Написание ненужных емейлов (4 часа в неделю)

  - Удаление спама (30 минут в неделю)

  - Болезни, прочие личные причины отсутсвия на работе (1 день в месяц)

  - 8 минут - одна сигарета

• Для подсчета времени на вышеупомянутые радости жизни можно либо подсчитать в столбик либо воспользоваться принципом трех четвертей: берем четверть времени от общей оценки проекта и прибавляем ее к оценке - таким образом закладываем время на разработку новых или измененных заказчиком требований. Затем от этой четверти считаем четверть и опять прибавляем к общей оценке(убираем риск преодоления "подводных" камней в проекте) и наконец от последней четверти прибавляем четверть и таким образом закладываем время на все те радости жизни, что я описал пунктом выше.