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

Уважаемый Архитектор,

Пожалуйста спланируте и построте мне дом. Я не совсем уверен, что именно мне нужно, поэтому полностью полагаюсь на вас. Тем не менее, у меня есть несколько идей, которые я бы хотел видеть реализованными в моем доме. К примеру, я бы хотел иметь 2 или 44 спальных комнаты. Спланируйте пожалуйста, так чтобы эти комнаты можно было потом легко убрать или добавить, потому что я приму окончательное решение только тогда, когда увижу чертежи. А также оцените финансовые затраты на каждый вариант, чтобы я мог принять правильное решение.

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

Не используйте дорогие материалы (алюминий, медь, и др). Но если нужда в этом все-таки будет, то потрудитесь детально объяснить почему этот материал нельзя заменить на более дешевый.

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

Чтобы быть уверенным, что вы строите то, что я и моя семья хотим, пожалуйста свяжитесь со всеми членами моей семьи (включая 5ти месячную Мэри) и узнайте у них, чего бы они хотели видеть в нашем новом доме. Моя мама, точно знает, как должен выглядеть наш новый дом, так как она часто нас посещает - раз, а то и два в год. Пожалуйста убедитесь, что вы удовлетворили требования всех членов моей семьи и приняли правильное решение. Но, я оставляю за собой право отменить любое ваше решение, если оно мне не понравиться.

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

Сейчас, также не время покупать какие-либо материалы к постройке дома. Этим займемся когда одобрим план. Надеюсь вы успеете возвести дом в течение 48 часов, после одобрения вашего плана...

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

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

Заранее неуверен в успехе,

Заказчик

P.S.

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

P.P.S.

Возможно мне нужен, не дом, а трейлер на колесиках. Пожалуйста ответьте мне, если вы считаете также.

Все вышенаписанное было создано по мотивам схожего романа и моего личного опыта.

Честно говоря играю я редко, а точнее никогда (в последние полгода). Ибо некогда, ибо неинтересно. Но эту игру я не смог пропустить мимо.

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

Обновление: совсем заработался, вот ссылка на игру.

Нашел довольно интересный пост о Психологическом портрете программиста(спасибо Саше Кондуфорову). Пост начинается с народной мудрости(ух, и мудрый же этот народ!):

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

Какой нужно сделать вывод? Что? Писать хороший код? С пляжа! Быстро писать надо, а потому криво. Почему? Потому что бизнес не ждет. Это стремительно развивающаяся среда, не терпящая задержек. Именно поэтому большинство коммерчески успешных проектов, убоги с технической точки зрения. Заказчика никогда не будут интересовать архитектура, стиль написания кода или гибкость вашего решения (речь идет о B2C нише). Заказчика всегда интересуют сроки сдачи проекта, реже внешний вид, еще реже производительность или масштабируемость проекта.

Далее автор рассматривает четыре типа программистов:

• первые, что делают все быстро и хорошо
• вторые, что делают все быстро и плохо
• третьи, что делают все медленно и хорошо
• и четвертые, которые делают все медленно и плохо.

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

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

Поэтому, если вы думаете, что наняли лучшего программиста (за N или даже К тысяц долларов в месяц). То поспешу вас разочаровать - лучший программист давно нанял вас.

Остаются два типа, наиболее распространенных типа(по мнению автора) программистов: те, что делают работу быстро и плохо и те, что делают все медленно, но хорошо. О каждом из них довольно толково написано, советую почитать. Из своего опыта могу сказать, что в каждом проекте есть такой период, когда нужно наложить написать кучу вонючего кода. Для этой задачи лучше всего подойдут быстро-плохо программисты. Но в то же время, обязательно наступит момент, когда заказчик спрашивает своего быстро-плохо программиста: "сделай мне паровую микроволновку инженера Гарина на бобовых косточках". На что программист с полной уверенностью заявляет - это невозможно (кстати, отсюда родился миф о "лени" программистов, мол они все могут, вот только ленятся). К сожалению, данного сорта программист не может построить такую систему. Для таких задач как раз и нужен программист медленно-быстро. Поэтому "смешанные" команды наиболее эффективны в нашей объективно-жестокой экономической действительности. Главное - уметь правильно распределять задачи.

Недавно прочел книгу “Психология влияния” Роберта Чалдини, в которой он рассказывает про достаточно интересный психологический аспект деятельности человека. Этот феномен называется "феномен Армейского приказа" и суть его заключается в том, что даже если офицер отдает заведомо ошибочные команды - в большинстве случаев никто из солдат не воспротивится ему, а отправится их выполнять. Даже если они приведут солдат к верной гибели. Со стратегической точки зрения этот феномен невероятно полезен в боевой ситуации. Допустим противник обнаружил небольшое подразделение солдат на открытой местности и начал вести огонь. В тоже время солдаты отделены от противника, минной полосой. Назад бежать - на открытой местности всех перестреляют, вперед бежать - подорвуться на минах. В такой ситуации легко растеряться и погибнуть. Но если офицер даст приказ бежать вперед и вести огонь, то часть солдат(первые ряды) подорвуться на минах, часть убьет противник, но часть выживет. Ошибочное ли было это решение? Везде ли этот феномен будет полезен?

Интересно, что в бизнесе ситуация очень похожа. Руководители вполне могут совершать ужасные “ошибки”, которые приводят к краху бизнеса. Даже если эти CEO такие звезды, как Стив Джобс или Говард Шульц.

Большинство газет (включая New York Times) еще пару лет назад восторгались стратегией, которую выбрал основатель сети кофеен Starbucks – кофейня на каждом углу. Starbucks появлялся везде, где только можно. USA Today назвала его «кофейным Биллом Гейтсом». Кофеен стало так много, что люди, если и не начали теряться, то, по крайней мере, перестали посещать многие из заведений Говарда Шульца. Сегодня легендарная компания закрывает сотни кофеен, а людей увольняет тысячами. Говард Шульц попал в рейтинг самых худших CEO года по версии журнала Fortune.

А ведь еще недавно его боготворили за те же самые поступки… просто последствия были иными. Но во время успешного периода деятельности компании никто и не подумал возразить основателю Starbucks. Сейчас его поливают грязью бизнес-издания Америки. И это не только проблема Starbucks. Любые руководители ошибаются. Они тоже люди, и имеют на это право. Другой вопрос в том, что сотрудники не должны быть заложниками феномена Армейского приказа. Они всегда должны анализировать ситуацию, и если кто-то понимает, что шеф не прав, то нужно постараться объяснить ему это. Естественно, приведя убедительные доказательства. А слушают ли вообще сотрудников?

Тут, конечно, многое зависит от самой компании. А может ли в ней простой сотрудник сказать старшему менеджеру или даже президенту, что тот совершил ошибку? Послушают ли его вообще? На этот вопрос нет однозначного ответа. Это уже скорее проблема корпоративной культуры. В любом случае, очевидно, что руководство в большинстве нормальных компаний старается выслушивать своих сотрудников. Обычно при помощи электронной почты (если речь идет не о малом бизнесе). Помимо клинических случаев, большинство компаний для связи руководителя и сотрудника используют простую корпоративную почту, или внутреннюю сеть. Правда, достаточно часто письма сначала проходят проверку у секретарей главы компании, которые направляют к нему только самые важные. Например, именно так дела обстоят в компании Microsoft, когда письма идут Биллу Гейтсу. С президентом компании – Стивом Баллмером, ситуация иная. Он сам отвечает на все письма без помощи секретарей. При этом email Баллмера открыт для всех, благодаря чему он получает электронную почту и от клиентов компании, и от простых людей, которые неожиданно решили отправить письмо Стиву.

Возращаясь к примеру Говарда Шульца и феномену Армейского приказа, можно сказать, что Шульц принял ошибочное решение. Хотя в 2006 году, журнал Forbes назвал Говарда Шульца 354-ым наиболее богатым человеком Соединенных Штатов, а его состояние оценивается в 1.1 миллиард долларов. Возможно, это и есть та, часть отряда которая выжила? Мораль такова – не важно кто вы – солдат или разработчик программного обеспечения – всегда старайтесь спасти ваш отряд, или по крайней мере оказаться в той части, которая выживет ;)

Запомните клиент всегда хочет чувствовать себя любимым и быть в центре внимания. Даже если это внимание одного маленького трудяги-программиста. На эту чудо-мысль меня натолкнул недавний случай.

Немного предыстории. Проект, над которым я и моя команда сейчас работаем, имеет богатый функционал и предназначен для проведения маркетинговых исследований. Заказчик, по всей видимости, успешный хозяин своего бизнеса. И постоянно сыпет новыми идеями. Порой случается так, что его новые идеи перекрывают или отменяют прошлые “новые” идеи. И как все нормальные заказчики, он переживает за свой продукт и за свои деньги. Ежедневное общение с ним, стало для нас нормой. Неделю назад мы, как обычно, получили новый список ToDo и приступили к исполнению. Вопросов не было – функционал был предсказуем и даже ожидаем. И тут клиент сменил свою позицию на более пассивную, перестал ежедневно задрачивать интересоваться ходом разработки. Мы были увлечены разработкой и тоже не беспокоили заказчика. И каково же было мое удивление, когда в следующий понедельник я обнаружил у себя в ящике гневное письмо клиента: “Почему вы не выпустили следующую версию продукта? Где новый функционал? Вы что не работали всю эту неделю?”. После недолгих объяснений все стало на свои места, но после этого случая я сделал для себя несколько выводов.

Помнить о клиенте. Даже если у вас нет новостей, то хорошим тоном будет написать письмо, хотя бы с одним словом “Привет(Hello)!”. Тем самым вы покажете заказчику, что вы думаете о нем и “держите” его проект у себя в голове.

Держать клиента в курсе событий. Это хорошая идея – отправлять заказчикам регулярные письма с информацией о прогрессе проекта. Не стоит этого делать часто. Если ваш проект долгоиграющий и изменения в нем происходят медленно, то достаточно будет одного письма в неделю. Хотя на некоторых проектах необходимо оповещать клиента об изменениях по нескольку раз в день. Интересно и то, что если “приучить” клиента к письмам каждую пятницу, то через месяц самое простое пятничное письмо, с текстом “Привет, как дела?” будет означать, что проект двигается по плану и заказчик будет спокоен.

Позвольте клиенту почувствовать вашу проактивность в проекте, даже если вас об этом никто и не просил.

В завершение хочу предложить вам пройти небольшой тест.

У вас появился новый клиент и вот-вот начнется работа по этому проекту. Проект будет длиться два месяца. Ваши действия:

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

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

1. Скажу: “Проблема? Какая проблема? Эти туфли подходят цвету моих глаз, неправда ли?”
2. Позвоню клиенту и назначу встречу, чтобы обсудить текущие задачи по проекту.
3. Позвоню заказчику: “Какого хуя? Где обещанные премиальные?”

День рождения клиента. Ваши действия:

1. Серьезно? У клиентов бывают дни рождения?
2. Пошлю цветы или бутылочку шампанского.
3. Пошлю счет за этот месяц с подписью: “С днем рожденья, сука!”

На встречах с клиентом, вы:

1. Опаздываю на 30 минут. Часто забываю свой ноутбук с последними изменениями дома и приходиться возвращаться.
2. Приезжаю вовремя, предлагаю клиенту кофе и сладкое.
3. Не появляюсь: “Время – деньги, Джонни.”

Термин “шлифовать” для вас:

1. Процедура, которая должна быть выполнена, до того как шкаф покроют лаком.
2. Проверить все ли завершено, согласно проектному договору. Собрать все документы. Проверить еще раз.
3. Поджечь, утопить или съесть все, компроментирующие вас документы.

Если вы выбирали в основном пункт 1, то спешу вас огорчить - вы страдаете от собственной глупости. Если ваш выбор останавливался только на пунктах под номером 2, то вам было никчему читать эту статью - вы и так хороший менеджер. Те кто, выбирал третий вариант ответов, оккупируют Польшу этой зимой.

Subversion всегда был удобен такими фичами как, атомарные commits, версионированные директорий, хорошая поддержка бинарных файлов, быстрое создание бранчей и тагов, поддержка нескольких сетевых протоколов, в том числе и HTTP. Но, чего действительно раньше не хватало в subversion, так это возможности найти какой код был смержен, откуда он мержился и когда это произошло. Отсутствие такой возможности приводило раньше к трудностям при мерже:

К примеру, пользователь не сможет смержить изменения с 11 по 17 ревизию в бранч, если он уже мержил 11 и 13 ревизии в бранч ранее. В новом subversion мержи логируются и нет больше необходимости записывать на листик, какой код, когда и откуда мержился.

Разработчики subversion как будто услышали мои мольбы и добавли change lists –функционал, позволяющий ассоциировать произвольные файлы с неким человекочитаемым именем. К примеру вы работаете над несколькими багами одновременно, и по окончании одного из них хотите залить его в репозиторий. А файлы, относящиеся к другому фиксу – оставить в локальном репозитории. Раньше приходилось прибегать к помощи листика, чтобы разделить эти два набора файлов и залить только нужные файлы. Теперь проассоциировав первый набор файлов с неким именем, вы можете по окончанию работ просто указать имя этой группы файлов и они немедленно попадут в основной репозиторий.

Еще одна полезность, появившаяся в 1.5 subversion – это sparse checkouts, позволяющий выполнять основные операции только над указанными уровнями дерева каталогов. Это удобно, если вы не хотите “слить” только текущий каталог со всеми файлами в нем, но не хотите “сливать” все его поддиректории. 

Также было добавлено интерактивное разрешение конфликтов – теперь svn сам предлагает варианты решения конфликта. Лично для меня эта фича никакой погоды не делает, так как я давно пользуюсь Araxis Merge, чего и вам советую.

Не знаю почему, но большинство GIT’овцев кричат: SVN sucks, попробуйте GIT – у нас проект в жите 2.5 гига и ничего не тормозит. У меня, я вам скажу, есть проект около 4 гигабайтов в архиве. То есть сжатый RAR’ом. И я никаких тормозов не наблюдал еще с версии 1.4.6. А в версии 1.5 ускорена работа из-за простого трюка – они сделали более многовложенную файловую систему, т.е. в одной директории такого дикого количества файлов уже не будет. И это важно, особенно, если ваш сервер хранит репозиторий на Network Attach Storage с не самой продвинутой файловой системой, которая тормозит при 10 000 файлов. Из-за того что в subversion файлы readonly, это позволяет улучшить стратегию кэширования на стороне NAS’ов и других умных файловых систем. Теперь неизменяемые файлы сгруппированны в каталоги, и вашей файловой системе можно сказать: вот эти каталоги неизменяемы (после появления файлов в ней) и ты пожалуйста это учти.

Разработчики клянуться, что теперь заработает CTRL+C!

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

Как мы видим, управлять репозиторием теперь станет легче, работать он будет быстрее, а разработчики перестанут записывать на листике, что и когда они мережили ;)

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

Subversion 1.5 Release Notes

Subversion: чеклист по правильным коммитам

Слияние: Руководство по ежедневному использованию

Merging and branching in Subversion 1.5

Subversion or CVS, Bazaar or Mercurial?

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

Google interview