-
Что такое RAML и как он помогает проекту
Расскажу об интересной штуке под названием RAML. Использую в текущем проекте и очень доволен. Технология молодая, информации в сети мало, на русском вообще не попадалось.
Предположим, несколько сервисов сообщаются по HTTP API. Авторизация, история операций, бизнес-транзакции. Сервисы принимают и отдают JSON, сигнализируют об ошибках правильными статусами ответа. Нет пользователя – 404, нет прав – 403, кривые данные – 400. Классический рест.
Как составить документацию? Нужно перечислить все урлы. Указать правила авторизации, заголовки, как правильно их составить. Для каждого урла перечислить методы GET, POST, etc. Описать структуру входных данных. Структуру ошибочных ответов. Добавить человеческое описание каждого метода. И все это поддерживать в актуальном состоянии.
Возможно, есть специалисты, которые ведут документацию правильно, чтобы все было описано по пунктам и ничего не расползалось. Не нужно уточнять детали, ответ сервера в точности такой, как написано. И группа людей соблюдает все соглашения о ведении документации.
На практике я вижу обратное. Документация отстает от разработки. Текст пишут в вики в ужасной разметке. Каждый человек придерживается особых правил. На ретроспективе холиварят о том, как документировать правильно.
RAML решает эти проблемы. Название означает REST API Markup Language. Технически это YAML-документ с набором фич. Стандарт задает жесткую структуру для описания рестовых апих. Разработчики держат этот файл в гите и наполняют вместе с кодом. Во время билда особая утилита переводит документ в формат HTML.
Перечислю достоинста технологии:
-
Структура. RAML – это стандарт, поэтому отсебятены в документе быть не может. В группе разработчиков не будет конфликтов, как описать схему запроса или входные параметры.
-
Формат YAML. Это лучший формат для конфигураций. Краток, удобен для чтения. Поддерживает основные типы. Имеет списки, словари. Поддерживает многострочные данные. Разрешает комментарии. Не падает из-за лишней запятой на конце, как JSON.
-
Поддержка markdown. Описание к каждой сущности пишется в маркдауне. Это самый простой язык разметки. Очень подходит для вставки кода, простейшей структуры (заголовки, подзаголовки).
-
Инклуды. Большой файл легко декомпозировать на составные части и подключать по частям директивой
include. Более того, инклуд поощрается стандартом, чтобы не дублировать сущности. Например, любойlist-метод (список сущностей методомGET) принимает параметрыlimitиoffset. Создаем отдельный файл с их описанием, примерами. Подключаем к нужным методам инклуд, компилируем. На выходе у каждого метода идентичное описание этих параметров.Инклуды позволяют комбинировать документацию для разных целей. Например, есть публичные апи, а есть внутренние. Описываем каждую в отдельном файле. Создаем два документа. Первый для заказчика, с инклудами только публичных апих. Второй для внутренних нужд – только с инклудами внутренних.
-
Утилиты и экспорт. Документацию в RAML легко обрабатывать машинным способом, потому что это стандарт, протокол. Уже существует пачка утилит для работы с форматом. Визуальные редакторы, генерация кода по заданным урлам, плагины к редакторам и ИДЕ, и конечно, тулза для экспорта в markdown и HTML.
-
JSON-схемы. Схема – лучший способ описать структуру данных. Она заменит долгие списки и абзацы человеческого языка. Схема декларативна – сложные структуры могут быть представлены как ссылки на схемы проще. RAML поддерживает инклуд схем.
-
Поддержка HTTP/REST. Стандарт знает все о заголовках и статусах ответа. Красиво, когда документация покажет не только тело ответа, но и статус с описанием, примеры заголовков.
Существует два версии формата: 0.8 и 1.0. Вторая предлагает больше полей и возможностей для описания. Я пока что пользуюсь 0.8.
Рассмотрим простой пример. Пусть есть простая апиха. Вот что мы напишем в заголовке файла
example.raml:#%RAML 0.8 title: Some Title version: v3 baseUri: https://example.com/api/v1/Добавим вводную документацию. Для каждого раздела укажем подзаголовок. Ниже:
documentation: - title: Main Title content: | common notes on this document. - title: Authorization content: | Some text to describe HTTP headers to access data. ~~~ code goes here... ~~~Задекларируем правила авторизации. У нас в проекте это обычная базовая авторизация по протоколу HTTPS. Стандарт RAML знает, что это такое:
securitySchemes: - Basic Authentication: type: Basic AuthenticationТеперь, описывая урл, можем просто состаться на этот тип авторизации. В скомпилированном HTML-документе напротив урла будет стоять замочек, а по клику откроется окошко с описанием правил авторизации.
Начнем описывать урлы:
/api/v1/user: securedBy: [Basic Authentication] get: description: | Retrieves a list of users. ### Syntax ~~~ GET /api/v1/user/ Host: {host} Authorization: {authorization} ~~~ queryParameters: !include user_list_params.raml responses: 200: body: application/json: example: !include examples/user_list_response.json schema: !include schemas/user_list_response.jsonВсе просто. Мы декларируем апиху, которая отдает список юзеров. Доступ защищен базовой авторизацией. В описании пример запроса. Файл
user_list_params.ramlсодержит парамеры командной строки: лимит, смещение, сортировка.Схема ответа может быть большой, поэтому инклуд. В файле
examples/user_list_response.jsonлежит схема, примерно такая:{ "$schema": "http://json-schema.org/draft-04/schema#", "additionalProperties": false, "definitions": { "item": { "additionalProperties": false, "properties": { "id": { "minimum": 0, "type": "integer" }, "name": { "maxLength": 64, "type": "string" } }, "required": [ "id", "name" ], "type": "object" } }, "properties": { "count": { "minimum": 0, "type": "integer" }, "results": { "items": { "$ref": "#/definitions/item" }, "type": "array" } }, "required": [ "count", "results" ], "type": "object" }Смотрите, как удобно: в начале схемы декларируется тип юзера. Конечный ответ – это массив таких сущностей.
Дальше документ очень удобно развивать. Добавлять методы (POST, PUT, DELETE), ссылаться на уже определенные структуры, выносить повторы в инклуды.
Скомпилируем документ в файл. Утилита raml2html написана на node.js и ставиться через npm. Компилим:
raml2html example.raml > example.htmlНе нравится дефолтный шаблон? Можно передать свой:
raml2html -t custom-templates/template.nunjucks -i example.raml -o example.htmlВ результате получим HTML-документ (UPD документ по ссылке удалили).
RAML действительно экономит время на составление документации. Технология молода, но очень перспективна. Советую использовать уже сейчас.
-
-
Третья встреча любителей глобоко порефакторить
Состоялась третья встреча!
Денис Ковалев дал вредные советы программистам. С комментариями, почему это вредно.
Наш гость Евгений Рыжков поведал о спорных моментах в манифесте аджайла.
Напомню, что мы тусим в группе в Фейсбуке. Во Вконтакте осталась легаси-группа, в нее валим только видосы и анонсы.
Планируем четвертую встречу. Хотите выступить? Шлите запрос в ФБ мне, Денису или Юре.
-
Как проходить собеседование
В первой части я рассказал, как проводить собеседования. Теперь разберемся, что требуется от кандидата.
Текст о себе
В резюме должен быть сопроводительный текст. Не голая табличка с местами работы, а параграф связного текста о том, кто вы, что умеете и каким образом полезны компании.
Кандидаты думают, что в таблице все понятно. Увы. За таблицей не видно человека. По короткому абзацу текста можно сказать о человеке больше, чем по огромной таблице.
Не нужно воспринимать текст о себе как момент славы. Иные кандидаты пишут чуть ли не родословную: когда родился, женился. Пишите только по делу, о том, что важно работодателю. А ему важно одно – какая от вас польза.
В резюме не должно быть табличек, болдов, италиков. Просто текст. Отправляйте письмом без вложений. Нулевые года прошли.
Протоколы, алгоритмы, БД
При подготовке к техническуому собеседованию обязательно повторите сетевые протоколы, алгоритмы сортировки. Освежите в голове, как работают основные структуры данных. Какие операции хороши для массива, какие для связного списка? Почитайте базы данных, транзакции, индексы.
В больших проектах решают не конкретные языки, а архитектура и инструменты. Кандидат, который превосходно знает протокол HTTP и средне Питон, лучше кандидата, у которого ситуация наоборот.
Не опаздывать
Опоздание – тягчайший грех. Никому не интересно, что у вас заболел попугайчик, потерялись ключи, заболели родственники. Про дорожные пробки даже не заикайтесь. Это неотъемлемая часть городской жизни.
Однажды кандидат опоздал на час и рассказал, что, оказывается, на дороге пробки. ВНЕЗАПНО, да. Выглядел он как школьник, который прогулял диктант и говорит, что болела рука. Собеседование не прошел.
Если что-то случилось, звоните. У вас должны быть телефоны кадровиков или менеджеров. У опоздавшего кандидата был телефон размером с лопату со всеми мыслимыми мессанджерами. Предупредить об опоздании он не посчитал нужным.
Подготовьте окружение
Если проходите собеседование удаленно, подготовьте рабочее место.
Камеру и гарнитуру проверьте заранее. Страшно бесит, когда кандидат калибрует девайсы в счет вашего времени. Вы видели, чтобы в передаче по телевизору оператор выставлял фокус, а диктор проверял микрофон?
Запустите тормозную ИДЕ заранее, чтобы не тратить 20 секунд впустую.
Собеседование не должно проходить на вашей текущей работе. Придется убегать от коллег и прятаться по переговоркам. Окружающие все сразу поймут. Берите отгул.
Отгородитесь от домашних, в том числе животных. Отключите телефон и нотификации в ноутбуке.
Не перебивать, не холиварить
Категорически запрещено перебивать того, кто задает и принимает ответ. И точка.
Избегайте негативных оценок. Не озывайтесь плохо о технологиях, тем более о людях. По несчастливой случайности, собеседник напротив обязательно окажется экспертом в ПХП, про который вы сказали, что это говно. Спорить будет песполезно, только провалите собеседование.
Опытный переговорщик может поиграть в адвоката дьявола и закинуть похожую мысль. Например, мы же на Эрланге пишем, а не на быдло-руби. Не соглашайтесь на это, спокойно отвечайте, что у каждой технологии свои плюсы и минусы.
В конце концов, ваше мнение о ПХП, Хаскеле и ООП ничего не меняет.
Будьте на равных с собеседником
Собеседование – это переговоры. В переговорах стороны по определению равны. Это значит каждая сторона имеет право задавать вопросы и говорить “нет”.
Ваша беседа должна быть на равных. Случается, кандидата задавливают, дают понять, что беседа протекает в одностороннем режиме. Но бывает и так, что кандидат сознательно становится на ступеньку ниже, проявляет пассивность.
Обязательно спрашивайте ответ, если не смогли ответить. Все мы люди, и в волнении можем забыть то, что твердо знали. По первым словам собеседника вы вспомните то, что забыли. Конечно, такой вопрос пойдет в зачет.
Топорное “не знаю” с последующей паузой разражает. Я вижу, что не знаешь, но как ты будешь действовать? Какие задашь вопросы? Или будешь тупить за компом, молча срывая сроки?
Нет ничего плохого в том, чтобы отвечать вопросом. Предположим, ответ на вопрос получился весьма скромным. Тогда попросите собеседника пояснить неясные моменты. Работает это безотказно. Собеседник не сможет проигнорировать внимание к своей персоне. Кандидат получит знания и очки за внимание.
Не болтайте лишнего
На собеседовании следите за языком, чтобы не выдать важных сведений. Как при задержании – все, что скажете, может быть использовано против вас.
Не отзывайтесь плохо о бывших коллегах. Собеседник автоматиески примерит это на себя. “Наверное, на новом месте он тоже расскажет, какой я мудак” – вот что он подумает.
Эйчары падки на скандальные истории. На каждый ответ про конфликты вы получите три новых вопроса. Неужели начальник действительно был неправ? Как пытались разрешить конфликт? Допускаете, что были правы не вы? Вскоре с удивлением вы обнаружите, что обсуждаете не техническую часть, а отношения на прошлой работе, и ситуация не в вашу пользу.
Это похоже на то, как девушка выпытывает у парня, сколько других было до нее. Самый худший вариант – ответить правду. Будь то одна, десять или сто девушек. Дайте собеседнику понять – вы настроены на сотрудничество с новой компанией. Прошлые конфликты улажены, нет смысла к ним возвращаться.
Если вы без опыта
Особенно трудно собеседование дается тем, у кого нет опыта по специальности. Здесь есть одна хитрость. Когда проходит человек без опыта, работодатель решает вопрос – стоит ли вообще связываться с этим человеком? Насколько он адекватен, внимателен? Можно ли его чему-то обучить?
Задача кандидата-новичка в том, чтобы продемонстрировать адекватность и восприятие. Поэтому не перебивайте, слушайте, задавайте вопросы. Не стесняйтесь отказывать. Не думайте об этом месте работы как о единственно возможном.
Вот и все, что нужно кандидату для успешного прохождения интервью!
-
Проект "Собеседование"
Прерываю череду постов о собеседованиях практической вещью. Рад представить коллегам проект “Собеседование”. Это база технических вопросов с ответами для проведения интервью и подготовки к нему.
Кандидаты найдут в документе список вопросов на самую обширную тематику. К каждому вопросу приведен короткий ответ. Так вы сразу поймете, верны ли ваши познания в конкретной области.
Опытные коллеги, которые проводят собеседования, получат хороший план. Нередко случалось со мной такое, что забывал спросить кандидата что-то важное. Заговорились, то-се. Но когда перед глазами оглавление, осечки быть не может.
Кандидаты должны работать с документом так. Смотрите содержание, выбираете вопрос. Мысленно спрашиваете себя или коллегу, отвечаете. По клику перематываетесь к ответу. Проверяете, правильно ответили или нет. Не согласны с ответом? Пишите на почту или в комментарии.
Расскажу историю этого документа. Я начал записывать вопросы для собеседования в приватный Гугл-док. Сперва это были вопросы исключительно про Питон. Постепенно я добавлял базовые вещи. Алгоритмы, безопасность и даже практику. Несколько раз я шарил его с коллегами, но актуальная версия была только у меня. Несколько раз я передавал вопросы коллегам из других айтишных компаний.
Вполне возможно, что на собеседовании вас спросят кое-что из моего списка. А если претендуете на Питон – вероятность стремится к единице.
Кто-то может подумать, что шарить вопросы, да еще с ответами нехорошо – ведь можно заранее подготовиться. Знаете, я только об этом и мечтаю! Чтобы пришел человек, по пунктам разобравший каждый вопрос. Потому что зубрить бесполезно. И еще потому что знания должны быть открыты и бесплатны.
В документе до сих пор есть дыры, которые мне предстоит заполнить. Напомню, проект лежит в Гитхабе, и любая помощь приветствуется. Уже нашлись добрые люди, которые поправили опечатки.
У меня строгое видение работы по этому документу. Он не должен быть учебником, и отдельно взятый вопрос не должен занимать больше трех абзацев. Цель – быстро понять, знает ли кандидат ответ на вопрос или нет. К короткому изложению можно только приложить ссылки на подробные ресурсы. И конечно, когда-нибудь перевести это добро на английский.
Если кто-то хочет принять участие в наполнении документа, свяжитесь со мной заранее, чтобы согласовать план работ.
Искренне надеюсь, что кому-то этот труд окажется полезным. Всячески приветствую использование этого документа в образовательных и бизнес-целях. Пожалуйста, делитесь ссылкой на оригинал, чтобы видеть актуальную версию.
-
Итоги 2015 года
Подвожу итоги 2015 года. С опозданием пишу о главных событиях, которые произошли со мной в ушедшем году.
Начну с плохого. Весной я тяжело переболел гриппом. Произошло это в командировке. Был очень плох, думал, помру. По счастливому совпадению ехал в поезде отдельно от коллег. А дома – беременная жена. Две недели жили по разным комнатам, общались по скайпу и записками. Обошлось.
Осенью мне попала вожжа под хвост. Я поступил в магистратуру ВГУ. ПММ, ФИИТ, все дела. Совершенно глупый поступок. Бессмысленность затеи стала очевидна быстро. На тему обучения я напишу отдельный пост, а пока думаю над тем, бросать или нет. Не привык бросать начатое дело, фрустрирую.
Хорошего больше. У нас родилась дочь, сын пошел в школу. Я люто-бешено горжусь тем, что мы с женой разруливаем дела без бабушек, дедушек и нянь по найму. Хотя год назад я не представлял, как это хотя бы физически возможно.
Ездили с сыном в отпуск. Прочел Дейла Карнеги и Джима Кемпа. Теперь эти книги помогают мне каждый день. Читать их было праздником, а пользу вообще невозможно оценить.
1 декабря я вышел на новую работу. Теперь я удаленщик, работаю на небольшую фирму в Лондоне. Открыл ИП, плачу налоги, отчитиваюсь государству. Уходить из Датаарта было мучительно тяжело: хороший проект, классные коллеги, с финансами все ок. И все же вырвал себя с мясом из уютного мирка.
С уходом из Датаарта я стал чаще писать в блог. А чтобы не было дефицита общения, организовал айти-сообщество “Глубокий рефакторинг”. Каждый месяц проводим встречи с докладами. И это супер, скажу я вам. Не в кабак всем проектом ходить. Приятно видеть, как оживляются другие фирмы, видя нашу актвность.
31 декабря мне стукнуло 30 лет. Может, именно в этот момент понимаешь, что жизнь не вечна? Теперь я стараюсь записать все, что знаю, в документы и блог. И вообще понял, что жизнь коротка и знания должны быть открыты и бесплатны.
Вот что случилось со мной в 2015 году. Написал пост с задержкой в месяц, но очень рад, что руки долши. Обязательно прочту в перед Новым годом. Всем удачи!
-
Вторая встреча любителей глобоко порефакторить
Провели вторую встречу. Два доклада.
Ваш покорный слуга рассказал про собеседования:
Юра Хрусталев поведал, как собирать проект в Докере:
Группа переехала в Фейсбук. Во Вконтакте мы только дублируем записи из Фейсбука. Тем временем уже есть доклады на третью встречу. Ждем всех ровно через месяц!
-
Не спрашивайте про люки
В предыдущем посте о собеседовании забыл дописать еще один пункт, который, впрочем, тянет на отдельный пост.
Не спрашивайте, почему люки круглые, сколько настройщиков пианино в Сан-Франциско и сколько мячей для гольфа влезет в школьный автобус.
Маленькая историческая справка. Эти вопросы задавали в Гугле на собеседованиях. Руководство компании верило, что существует связь между умением отвечать на эти вопросы и навыками решать инженерные задачи.
Со временем, вопросы стали особой фишкой айти-собеседований и перекочевали в другие компании. Так, Джоел Спольски пишет в очерке о найме:
Третьим в списке идет вопрос на засыпку. Это забавно. Смысл в том, чтобы задать вопрос, на который у человека не найдется ответа — просто чтобы посмотреть, что он будут делать. Сколько окулистов в Сиэтле? Сколько тонн весит Вашингтонский Монумент? Сколько бензоколонок в Лос-Анджелесе? Сколько настройщиков роялей в Нью-Йорке?
Как всегда с опозданием, тренд докатился до России. Теперь даже адекватные на первый взгляд фирмы задают вопросы о люках.
В интернете есть хорошая подборка вопросов на тему круглых люков. Некоторые ответы отличаются хорошей аргументацией и чувством юмора. Это похоже на сборник красивых афоризмов. Приятная игра слов и смысла. Редко применимая к реальности, к сожалению.
В одном из вебинаров я узнал задачку на сообразительность, которую ведущий задавал кандидатам. Представьте механические часы со стрелками. Ход стрелок непрерывный. Часы показывают 15:15. Каков угол между часовой и минутной стрелками?
Из интереса я задавал ее коллегам и кондидатам. В результате не нашел никакой закономерности между правильным ответом и инженерными навыками. Так, один коллега, хороший разработчик, на голубом глазу ответил “Ноль!” и лишь по моему взгляду понял, что в задаче подвох. Кандидат почти сразу дал ответ в радианах, но техническое собеседование провалил.
Исходя из моего опыта (сарказм), Гугл объявил об отмене этих вопросов на собеседовании. Корпорация не нашла связи между задачками на сообразительность и инженерными навыками. Не нашла, потому что ее никогда и не было. Ждем, пока решение Гугла дойдет по России.
Мы выяснили, что головоломки — пустая трата времени. Они не могут ничего предсказать, и в процесс собеседования включены только для того, чтобы дать возможность интервьюеру почувствовать себя умнее.
– Ласло Бок, вице-президент компании по работе с персоналом.
Не задавайте таких вопросов и вы. В собеседовании должен быть вопрос, который требует размышления и развернутого ответа. Предложите кандидату что-то полезное:
-
Извлечь элементы массива в случайном порядке. Удалять элементы нельзя, только передвигать.
-
Смерджить два словаря со вложенной структурой.
-
Развернуть связный список.
-
Обойти бинарное дерево.
Каждый из этих вопросов требует бумажки, схем и рассуждений вслух. Польза выше, чем от настройщиков пианино в Детройте.
Чтобы два раза не вставать, разберемся с люками.
Вопрос “почему люки круглые” стал особым мемом, подобно вопросу “Чем ворон похож на конторку”. Некоторые приводят логические обоснования:
-
Круглая крышка люка не провалится в шахту, в отличии от квадратной или треугольной.
-
Круг обладает наименьшей площадью поверхности из всех фигур с заданным минимальным попереным сечением. Экономия металла.
Эти аргументы никуда не годятся, потому что:
-
Крышки люков бывают самых разных форм и размеров.
-
К круглой крышке невозможно приделать шарнир. Точка касания будет ничтожно мала, и его легко выломать за счет массы крышки. Поэтому круглые крышки не закреплены, и их воруют.
Итак, ни слова про люки на собеседованиях, договорились?
-
-
Безопасность в банке
Я хочу, чтобы вы знали, как работает один банк, где я храню деньги.
Началось все с того, что поменял в личном кабинете логин и пароль. Вышел, чтобы зайти под новыми. Не могу залогиниться, пароль не подходит. Ясно видел зеленую плашку, что пароль изменен. Последовательность генерил программой 1Password и вставлял копипастой, так что ошибки быть не может.
Звоню на бесплатный номер банка. Девушка включает тупняк и уверяет, что виноват я. Пароль сбросят только при личном обращении в банк. На крайний случай предлагает поговорить с техподдержкой. Хорошо, давайте.
– Здравствуйте, я такой-то, поменял логин и пароль, не могу зайти под новыми.
– Назовите ИНН.
Удивляюсь, но диктую цифры. Для идентификации больше ничего не потребовалось, что очень странно, ведь ИНН везде публикуется открыто. Девушка на саппорте спрашивала все реквизиты паспорта вплоть до кода отделения. Ну да ладно. Пауза, клацает по клавашам.
– Ого, ну и пароль у вас!
Чел видит мой пароль. Все 32 символа с решетками, подчеркиваниями. Безопасность на высоте. Боюсь спугнуть невежливым вопросом.
– Да, он не подходит.
Клацает, подозреваю, что ломится с моими кредами в интернет-банк.
– Действительно… А у вас сколько символов в пароле?
– 32.
– А у меня 26. Ваш пароль усечен, вы вводите лишние символы.
Вставляю в поле пароль, стираю 6 последних символов. Попадаю в личный кабинет.
– Почему система позволила сменить пароль, не выдав ошибку?
– Ошибки не было, в поле ввода лимит на число символов, браузер их автоматом отбросил.
– Хорошо, почему над полем не написан лимит на длину?
– Эти претензии не ко мне, оформляйте жалобу.
– Хорошо, позвольте нескромный вопрос. Как вы увидели мой пароль? Разве он не должен хешироваться?
– Я смотрю в логах.
– То есть в логах фигурирует мой пароль?
– Да, написано, с какого на какой вы поменяли.
– Превосходно. А что если логи утекут? Я доверяю вам деньги, подбираю сложный пароль, а вы пишете пароли в лог.
– Слушайте, до свидания…
– До cвидания.
Вот так работают банки. Право, лучше этого не видеть и не слышать. Сразу после звонка поделился рассказом с коллегой, который пользуется услугами того же банка. Диалог получился следующий.
– …то есть пароли у них открытые, понимаешь?
– Блин, вот отстой. Пойду пароль сменю.
– =)
– Бля-я-я-я…
Занавес.
-
Как собеседовать
UPD продолжение, часть вторая.
На предыдущей работе я проводил собеседования. В этом посте хочу обобщить полученный опыт. Это первая часть двулогии о собеседованиях. Сначала я расскажу с позиции того, кто его проводит. Представителя заказчика, другими словами. В следующей части о том, как подготовиться и какие шаги предпринять соискателю.
Чтобы хорошо провести собеседование, я следую этим принципам.
Требуйте сопроводительный текст
Кто изучал английский, знает, что в западной системе трудоустройства недостаточно прислать резюме. Потребуется еще и Covering Letter, оно же CL, по-русски – сопроводительное письмо. В нескольких абзацах кандидат пишет о себе, опыте работы и как он может быть полезен работодателю.
Оговорюсь, что не люблю подобострастие, и, как правило, такие письма исполнены унижения и нужды. Но! Текст о себе необходим. Вы не представляете, как много можно сказать о человеке, прочитав пару связных абзацев.
Текст о себе говорит о том, что кандидата волнует, как его воспримут. Случалось так, что резюме ничего не говорило и я требовал кандидата прислать текст. И даже отказывал в собеседовании исходя из его анализа.
Как составить текст о себе рассмотрим во второй части. Пока что зафиксируйте: связный, грамотный текст кандидата о себе – очень хороший признак.
Ничто не должно мешать
Кандидат волнуется, поэтому сведите сторонние раздражители к минимуму. Никто не должен заглядывать в переговорку. Отключите звук в телефоне, нотификации в ноутбуке. Все внимание направьте на кандидата – вы договаривались, он пришел, теперь его законное время.
Я делал тестовое задание в одной фирме. Меня посадили в самом проходном месте, куда сотрудники выходили развеяться. Рядом стояла дверь, которая ужасно хлопала, а открывали ее постоянно. Я просидел рядом с ней 6 часов. Думаю, понятно в каком состоянии я вышел из здания вечером.
Тогда мне очень была нужна эта работа, и, возможно, вашему кандидату тоже. Но не испытывайте границы терпения.
Не собеседуйте толпой
Cобеседуйте один на один. Когда с вашей стороны больше людей, имеете моральное преимущество и давите на кандидата. Если приглашаете коллегу, расписываесь в некомпетентности. Со стороны это выглядит жалко. Кандидат смотрит и думает “блин, а кто здесь главный? За кем решающее слово?” Вы и должны быть тем единственным человеком с полной компетенцией – знать и целевую технологию, и управление командой, и фронтенд, и базы данных.
Допускаю, что руководитель фирмы захочет быть с вами. В этом случае предупредите, что начальник будет сидеть в режиме read-only и задаст вопросы в конце. Я бы предпочел разделить разговор на два. Сначала со мной, потом с руководством.
Садитесь рядом
Картинки по слову “собеседование” показывают людей по разные стороны стола. Очень грубая ошибка. Вы должны сидеть рядом: кандидат по правую руку. На то две причины.
Первая. Вы не враги, а потенциальные коллеги. Ваша задача определить, подойдет ли кандидат кампании и компания кандидату (оба факта, а не только первый). Решать ее нужно сообща, за одним столом, как коллегам. Это разрушает эмоциональный барьер “свой-чужой”.
Вторая причина практическая. Вы просите написать на бумажке код. Когда кандидат сидит напротив, вы гоняете листочек туда-сюда и не видите, что он пишет. Листок по отношению к вам вверх ногами. Возникают паузы, растет напряжение. Если кандидат подвис на тривиальной вещи, не сможете подсказать.
Просите написать код
Собеседование без кода – время на ветер. Удивляюсь, как некоторые вообще ставят вопрос – давать код на собеседовании или нет?
Обязательно давать. Задача должна быть несложной с короткой однозначной формулировкой. Что-то отсортировать, составить список или несложное дерево. Задача не должна требовать подключения библиотек.
Не должно быть скрытого подвоха. Например, потребовать что-то невозможное, ждать 10 минут, а потом торжественно объявить кандидату, что зря старался – свинство.
Я оцениваю решение задачи в целом. Важна не только оскорость, но и оформление, именование переменных. Почти всегда в решении будут неточности: пропущенные аргументы, запятые. Попросите кандидата найти огрехи самостоятельно.
Обычно даю задачу на написание декоратора или составление словаря. Еще люблю задачу на ОРМ. Примеры рассморим ниже в следущих пунктах.
Задайте точечный вопрос
Порой может не хватить времени, чтобы пройтись по всем разделам языка или технологии. Я считаю безумным опрос по длинному списку: “списки, словари, классы, дескрипторы, …”. А впереди еще фронтенд, базы, алгоритмы…
Задайте один-два вопроса, которые максимально полно охватывают целевую технологию. Я называю эти вопросы точечными. Перед ними делаю разведку. Например, задаю вопрос о словарях. Если ответил хорошо, сразу точечный вопрос: опишите типичный декоратор?
Почему декоратор, а не метакласс или дескриптор? Последние два используются редко и только в тяжелых фреймворках. Из практики я вынес правило: если человек знает декораторы, можно брать в проект. В каждом языке есть такой вопрос-индикатор.
Вопросы должны быть глубокими
Вопрос должен иметь потенциал для следующего вопроса. Я называю такие вопросы глубокими. Составление словаря – неглубокий вопрос, потому что после решение неясно, что спрашивать дальше. А с декоратором можно спрашивать бесконечно:
- Что кроме функции может быть декоратором?
- Если экземпляр класса, то какой метод нужно реализовать?
- Что будет, если декоратор ничего не вернет?
- Что такое
@wraps? - Что такое параметрический декоратор, как реализовать?
Другой глубокий вопрос про ОРМ. Есть две таблицы, люди и города. Каждый человек живет в городе. Вывести список людей и городов, где они живут.
Главный момент задачи в том, догадается ли кандидат задействовать оператор
join. Если нет, о сеньоре не может быть и речи, но продолжаем. Решаем вопрос с джоином. Какие бывают джоины? Что будет, если у человека в таблице не указан город? С каким джоином мы его увидим, а с каким нет? Чем джоин отличается от юниона? Сможет ли кандидат написать сыройsql?Разобравшись, кандидат проделает большую работу, а вы увидете, каков он с деле, доводит ли задачу до конца.
Спрашивайте общие вопросы
Старайтесь побольше расспросить о протоколах, базах, транзакциях, алгоритмах. Спросите про функциональное программирование, замыкания и хвостовую рекурсию. Фиксируйте ответы в духе “ФП гавно, все пишут на ООП” – это признак незрелости.
Спрашивайте хотя бы немного о фронтенде, куках, основных видах уязвимости и средств защиты. Как вставить в запрос данные от пользователя? Как валидировать входящий json-документ? Что делать, если тормозит база?
Эти вопросы показывают общий уровень кандидата. Если ответил хорошо, можно брать и не спрашиввать про Питон, ПХП или что там у него. Например, я ничего не понимаю в Руби, но благодаря общим вопросам выясню, что из себя представляет веб-разработчик. Конкретно про Руби я проконсультируюсь у коллег, какой точечный вопрос задать.
Не вынуждайте кандидата лгать
На эту тему я написал отдельный пост: о чем не спрашивать на собеседовании. Коротко – не склоняйте кандидата ко лжи.
Всегда давайте возможность кандидату сохранить лицо
Редко, но бывает, в случае провала кандидат ведет себя безобразно. Пишет обидные письма, обвиняет, грозит опубликовать переписку на тематических сайтах. На том же Хабре ой как любят поныть на тему жадных кровавых корпораций.
Самое худшее, что можно предпринять – отвечать на такие письма, доказывать по пунктам, где кандидат был неправ. В этом случае переписка гарантированно будет опубликована, а ваши слова вырвут из контекста и обернут против.
Если кандидат троллит и ведет себя вызывающе, вежливо предупредите, что разговор закончится преждевременно. Более худшей рекомендации представить трудно. Оборванное обеседование – гвоздь в крышку карьерного гроба.
Предложите задать вопросы
Сколько бы времени вы ни потратили, позвольте кандидату задать его вопросы. Грамотно поставленный вопрос иной раз даст больше информации, чем ответ на него.
Пожелайте удачи
Банально, но даже если кандидат провалился, опишите основные ошибки, подскажите литературу и ресурсы. Обязательно пожелайте удачи, чтобы кандидат ушел без обид. Мир очень тесен.
Итак, шпаргалка
- Требуйте сопроводительный текст
- Устраните шум и помехи
- Чем меньше людей, тем лучше
- Садитесь рядом
- Дайте задание написать код
- Задайте один емкий вопрос вместо нескольких мелких
- Стройте следующий вопрос на основе предыдущего
- Уделите алгоритмам и протоколам не меньше времени, чем языку
- Не вынуждайте кандидата лгать
- Не опускайтесь до выяснения отношений с кандидатом
- Предложите задать вопрос
- Разберите ошибки и пожелайте удачи
В следующей части посмотрим на процесс глазами соискателя.
-
Почему Емакс?
Недавно участвовал в дискуссии о Емаксе и понял: даже опытные разработчики не понимают, что такое Емакс и зачем он нужен. Наверное, и ваш знакомый травит байки про сломанные руки и скобочки? Кидайте ему этот линк.
Выложим багаж: Емакс – мощнейший тексовый редактор. В пользу Емакса говорят несколько факторов. Наверное, вы ждете чего-то в духе “вот этой фичи в ИДЕ нет, или она требует на два клика больше”. Нет, список ниже – фундаментальные вещи.
Все известные программисты работают либо Емаксе, либо в Виме. Линус Торвальдс, Гвидо ван Россум, Армин Ронахер, Джо Армстронг и другие. Согласитесь, у них должны быть деньги на покупку самых крутых ИДЕ. Почему один человек пишет в Емаксе интерпретатор языка или ОС, а другой не может пофиксить в Эклипсе глючный интернет-магазин? Что вынудило профессионалов использовать бородатое поделие вместо передовых средств?
Гомогенность. Про нее я рассказывал в докладе про Кложу. (Не нравится слово – подойдет “мономорфность”). Гомогенность означает единообразие интерфейса на всех уровнях системы. Под интерфейсом понимаем не отображение окошка, а соглашение о том, как взаимодействуют уровни системы.
Лисп – гомогенный язык. Любая конструкция лиспа – S-выражение, и ничто другое. Интерпретатор Лиспа на Лиспе занимает 15 строк. Это важно для дальнейшего объяснения.
Емакс – это рантайм старенького Лиспа, поэтому перенимает черты языка. В Емаксе есть только буферы. Буфер может быть связан с файлом, а может и нет. Буфер может выводить текст, а может и считывать. В буфере может быть файл, терминал, список процессов, результат поиска (find, grep). Однако, каждый буфер подчиняется единым правилам. Перемещение по тексту, навигация по семанической структуре, выделение, копирование и вставка работают для буферов одинаково.
Гомогенность в корне отличает Емакс от классических ИДЕ типа Пайчарма и Идеи. В них много окошек, и каждое живет своей жизнью, подчиняется своим правилам. Скажем, в Емаксе результат поиска – это текстовый буфер, и я могу искать в нем же встроенным поиском по
C-s. Я могу настроить подсветку по регулярному выражению для любого буфера – потому что с точки зрения Емакса нет разницы, подсвечивать код, маркдаун или шелл.Гомогенность упрощает. Я не должен знать, как работает то или иное окно, я просто работаю. Растущая сложность систем – главная проблема разработчика. Мы используем сто утилит для написания кода, дебага, деплоя. У каждой свои параметры и баги. Так пусть хоть что-то из окружения работает просто, не выкручивая мозг.
Емакс и Вим заставляют отказаться от мышки. Задумывались ли вы, как неэффективно использовать аналоговый манипулятор для работы с цифровым устройством? Мышка удобна для игр и оконного интерфейса, когда элементы расположены в пространстве. Емакс ожидает от пользователя ввод команд, которые не зависят от положения курсора или разрешения экрана. Представьте, что у вас экран размером со стадион, а значимые элементы интерфейса в накрест лежащих углах. На перемещение курсора уйдет 10 минут, а на ввод команды – доли, как и прежде.
Конечно, это экстраполяция. И все же работа с мышью очень неэффективна. ИДЕ не поощрают отказываться от мыши. Видел сто раз, как программист водит мышкой по ниспадающим менюшкам вместо того, чтобы выучить команду.
Емакс – это очередной рубеж в карьере разработчика. И не потому что освоить Емакс сложно (на мой взгляд, намного легче Вима). Начать работать в этих двух редакторах означает настроить мозг на определенный лад, впитать ту философию, что заложили ученые бородачи 40 лет назад. Инструмент не сделает из новичка мастера. Но точно уверен, что с Емаксом я стал работать гораздо продуктивней.
Современные ИДЕ – это бизнес. Со всех сторон я слышу, что они помогают, улучшают. Их пропихивают в образовательные учреждения (Пайчарм со своим edu-project), чтобы юные умы не видели терминалов, а сразу писали код. Бизнес-адепты ИДЕ с пеной у рта докажут, что писать без коммерческого пакета нельзя и убыточно для бизнеса. Я думаю, понятно почему?
Хорошо, в одном из прошлых проектов я писал в Емаксе, коллега - в Саблайме. Проект – огромный и сложный. И мы были на равных с теми, кто использовал Пайчарм. Как так могло получиться?
Много фишек Емакса могут работать хуже, чем отточеные аналоги в ИДЕ. И автокомплит, и индексирование, и эвристическое обнаружение ошибок. Вот только правда жизни в том, что голова и профессиональное чутье со временем вытесняет эти прибамбасы. Со временем видишь ляпы в коде без подсказок машины, автокомплит становится не нужен, отключаешь то, что так долго настраивал.
Емакс – лучшее средство для тех, кто пишет на разных языках. Я много программирую на Питоне, правлю Js, зависаю в маркдауне, балуюсть Кложей и Гоу. Есть ли ИДЕ с поддержкой всех этих технологий одновременно? Могу ли я настроить поведение системы для каждого языка?
Емакс ускоряет процесс и упрощает работу. В том и парадокс, что система 40-летней давности делает это лучше коммерческих ИДЕ. Жаль, что многие разработчики понимают это поверхностно.
Ivan Grishaev's blog
Writing on programming, education, books and negotiations.