Tag Archives: interviewing

Links: Nov 8

You know, I’m totally baffled by the contrast in quality of Obama for America 2012 and ObamaCare projects. The first one was top-notch bleeding-edge technology project carried out with gleaming excellence, the second though has been a model failure by all means.

4Gb/s, 10k requests per second, 2,000 nodes, 3 datacenters, 180TB and 8.5 billion requests. Design, deploy, dismantle in 583 days to elect the President. #madops

Tweet above summarises the challenge for OFA2012 project and here are few links about it:

Calamities with HealthCare.gov look like they’ve been using services of the /dev/null-as-a-service kind. Facepalm.

Got an email from google+ telling me I’m eligible for custom URL. Made me even log in, found out it was still as revolting as it had been for a year or so, and on top of it, my very first posts to google+ were missing. Actually, one of the reasons I started to use G+ was to save interesting links I had come across, and as you might imagine, I’m thrilled to discover they wipe my older posts. So expect some flashbacks, as I’m not going to loose interesting stuff and will repost it here.

Continuing to catch-up on links:

Technology

  • The Ars Technica Review of Mac OS X Mavericks, in-depth, long, and interesting reading.
  • Recommended server-side SSL configurations
  • DevOps Look-fors — the way of assessing your processes maturity
  • Beej’s Guide to Network Programming
  • Question asked on many interviews — can root kill init process? It depends.
  • Algorithms part 2 commenced!
  • Boostrap 3 add-ons collection (in Russian).

English

Other

  • Banksy turns 50$ painting into 1M$ treasure
  • How a plan becomes policy:

In the beginning was the plan.
And then came the assumptions.
And the assumptions were without form.
And the plan was without substance.
And darkness was upon the face of the workers.
And they spoke among themselves saying,
“It is a crock of shit and it stinketh.”
And the workers went unto their supervisors and said,
“It is a pale of dung and none may abide the odor thereof.”
And the supervisor went unto their managers and said,
“It is a container of excrement and it is very strong, such that none may abide by it.”
And the managers went unto their directors, saying,
“It is a vessel of fertilizer, and none may abide its strength.”
And the directors spoke among themselves, saying to one another,
“It contains that which aids plant growth and it is very strong.”
And the directors went unto the vice presidents, saying unto them,
“It promotes growth and is very powerful.”
And the vice presidents went unto the president, saying unto him,
“The new plan will promote the growth and vigor of the company, with powerful effects.”
And the president looked upon the plan and saw that it was good.
And the plan became policy.
This is how shit happens.

http://ogun.stanford.edu/~bnayfeh/plan.html

  • Jennifer’s the winner: Six Decades of the Most Popular Names for Girls, State-by-State

Popular Girl’s Names

 

Создание девопс-команды, часть 2

Брайан Генри

Building a DevOps Team, part 2 by Brian Henerey for agilesysadmin.net

Original article: http://agilesysadmin.net/buiding-a-devops-team-part-2
Translated by Ivan Pesin, February 2012

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

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

Критерии успеха

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

  1. Могут ли они выполнять нужную работу?
  2. Станет ли команда с их приходом лучше?
  3. Есть ли чему нам у них поучится?
  4. Могут ли они быстро осваивать новые технологии и языки?
  5. Какая помощь им будет нужна от меня и команды?

Самооценка

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

Руководство по самооценке:

0
Опыта нет.
1
Могу прочесть программу, внести маленькие изменения в существующие программы или изменить настройку уже установленных систем с книгой под рукой.
2
Могу написать «Здравствуй, мир!» без книги, при необходимости попытаться разобраться в том, как работает система.
3
Могу использовать основные средства без особой помощи, полностью управлять небольшим окружением.
4
Могу разрабатывать программы или разворачивать системы среднего размера, используя всю основную функциональность (без книги) и некоторую специфическую (с книгой). Достаточное представление об архитектуре для  решения нетривиальных проблем.
5
Могу разрабатывать программы или разворачивать системы большого масштаба, используя всю основную (без книги) и значительную часть специфической (часть с книгой, часть без) функциональности.
6
Могу разрабатывать программы большого масштаба или разворачивать новые системы с нуля.
7
Представление и умение применить менее известные возможности.
8
Глубокое понимание тонких моментов и малоизвестных возможностей.
9
Мог бы написать книгу, но пока не написал.
10
Написал про это книгу (должна быть такая книга).


____
Сети TCP/IP
____
Архитектура Unix/Linux
____
Системное администрирование Unix/Linux
____
Алгоритмы и структуры данных
____
C
____
C++
____
Java
____
Python
____
Perl
____
Ruby
____
Shell Scripting
____
SQL и/или администрирование БД
____
Скриптовой язык на ваше усмотрение, не перечисленный выше: __________________
____
Сборочные системы и/или непрерывная интеграция
____
Тестирование производительности и/или планирование мощностей
____
Управление проектами и/или ITIL
____
Конфигурационное управление (Puppet, Chef, Cfengine, и т.д.)
____
Поддержка производственных сред или сред высокой доступности
____
Amazon Web Services (или другие «облачные» технологии/сервисы)

Сравнение результатов самооценки

Эта диаграмма оказалась действительно полезной в том смысле, что заставила меня задуматься о том, что же я хочу. Кандидат-8 набрал значительно больше очков, чем Кандидат-1, но значит ли это, что я больше хочу именно его? Например, до того, как я ввел весовые коэффициенты, кто-то, хорошо разбирающийся в Ruby, Python, Perl и Bash, мог набрать очень много очков. Но мне гораздо нужнее был человек, который мог легко учиться, чем разбирающийся во всех этих языках. В конце концов, я объединил эти категории в одну, давая одно-два дополнительных очка за широту знания, чем уменьшил эффект этих технологий на конечный результат.

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

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

Удаленный технический тест

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

  1. iptables фильтровал входящий трафик на 80-м порту внешней сетевой карты.
  2. 80-й порт был уже занят процессом, который нужно было убить.
  3. Этот процесс порождался из бесконечного цикла, так что каждый раз, когда его убивали, он запускался заново.
  4. Конфигурационные файлы Apache уже были в системе, и задавали для него 81-й порт.
  5. Мы не давали root-пароля к MySQL.

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

После первых двух кандидатов я решил, что любой, чье резюме выглядит достаточно хорошо, должен пройти удаленный технический тест до телефонного собеседования. И хотя я потратил несколько часов на написание кукбука для chef, который создавал тестовые инстансы, это оказалось чрезвычайно эффективным средством отбора. Кандидат-3 не смог решить ни одной проблемы из вышеприведенных, хотя оценил свои умения по системному администрированию Linux по шкале на 4, что должно было значить «достаточное представление об архитектуре для решения нетривиальных проблем».

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

Персональные собеседования

  1. Кандидат проводил 30-60 минут, программируя в паре с одним из членов моей команды. Писались простые вещи, обычно на языке, которого кандидат не знал. Если он не знал руби, они писали коаны руби. Основной целью было понять, сможем ли мы проводить много времени в тесной работе с кандидатом.
  2. Мы также проводили несколько вполне стандартных интервью, обсуждая резюме кандидата и рассказывая ему о той роли, которую ему предстояло выполнять в команде. Здесь же проходили теоретические собеседования у доски о программировании и алгоритмах.

Задание по программированию

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

Конец – это начало

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