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

Структура резюме

Обычно резюме состоит из следующих основных элементов:

1. Контактная информация: ваше ФИО, адрес, номер телефона, адрес электронной почты (обязательно поднимите этот блок на самый верх)

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

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

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

4. Опыт работы: перечислите все места работы, начав с последнего. Укажите название компании, должность и сроки работы.

5. Навыки и качества: здесь вы перечисляете свои ключевые навыки, релевантные для должности, на которую претендуете.

6. Дополнительная информация: в этом разделе можно указать любую дополнительную информацию, которая может быть полезна работодателю, например, знание иностранных языков, сертификаты, участие в профессиональных сообществах, проекты или достижения.

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

Отличия между резюме начинающего специалиста и опытного инженера

Резюме молодого специалиста и опытного работника имеют свои особенности. Акцентируем на них внимание:

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

2. Опыт работы: молодой специалист может упомянуть стажировки, фриланс-проекты или волонтерскую деятельность, чтобы показать свои навыки и опыт работы. Опытный работник, в свою очередь, подразумевает достаточно подробное описание своего опыта работы с разделением на обязанности, достижения и результаты. Старайтесь в описание упоминать названия конкретных технологий, с которыми вы работаете и которые необходимы организации, в которую вы подаете резюме.

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

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

Перевод одноименной статьи Marek Kirejczyk из daftcode.pl.

Команды разработчиков программного обеспечения часто принимают решения о программной архитектуре или базовом технологическом стеке на основе спорных мнений из социальных медиа, да и в целом выбирая то, что считается «горяченьким», вместо того, чтобы провести скрупулезное исследование и серьезно рассмотреть возможный эффект от их применения на своих проектах. Я называю эту тенденцию Hype Driven Development (прим. разработка управляемая беззастенчивой рекламой или обманом, но обман… в общем я склонен считать что хайп это хайп, но в переводе иногда буду использовать другие слова), считаю ее вредной и выступаю за более профессиональный подход, который называю «Solid Software Enginering». Приглашаю узнать больше о том, как это работает, и выяснить, что можно сделать вместо этого [HDD].

Новая технология — новая надежда

Сталкивались с этим? Команда выбирает новейшие, самые горячие технологии, чтобы использовать их в своем проекте. Кто-то читает сообщения в блогах, кто-то видит в трендах на Twitter, а еще мы только что вернулись с конференции, на которой много говорили о новой технологии. Вскоре после того, как команда начинает использовать эту восхитительную новейшую технологию, можно наблюдать неожиданный эффект. Вместо того, чтобы решать задачи быстрее (как и обещалось) и создавать более совершенный продукт они сталкиваются с проблемами. Они замедляются, теряют мотивацию. Возникают новые проблемы, которые делают сложным или невозможным поставку следующей версии. Некоторые команды продолжают исправлять ошибки, вместо того, чтобы работать над новыми возможностями. Им нужно «просто еще несколько дней», чтобы все разобрать.

Hype Driven Development

Hype Driven Development (HDD) имеет множество оттенков и может коснуться вашего проекта по-разному:

Reddit Driven Development — когда команда или кто-то конкретный принимает решение по технологии / архитектуре / дизайну, основываясь на том, что об этом написал популярный блоггер, или это очень жарко обсуждается на Reddit, hackernews, Twitter, facebook, GitHub или других социальных медиа.

Conference Driven Development — присмотритесь к тому, что происходит после того, как люди вернулись с конференции. Люди вдохновляются. И это палка о двух концах. Переходя на новейшие «горячие» библиотеки/фреймворки/архитектурные парадигмы без должного их исследования можно попасть прямиком на шоссе из песни AC/DC (прим. Highway to hell).

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

Loudest guy driven decisions —  это когда у нас есть один парень, который все время говорит об этой клевой новой штуке, в которой у него нет никакого опыта, но говорит он безостановочно и в итоге команда принимает решение использовать её.

Gem/lib/plugin driven development —  особенно сильна в комьюнити Ruby On Rails, где время от времени я могу встретить такой длинный Gemfile, что длиннее будет только загрузка приложения. Это явление происходит от идем о том, что каждая проблема в Rail должна быть решена с помощью gem’а. Иногда самостоятельное решение стоило бы всего нескольких строк кода. Но мы просто решаем проблемы добавлением библиотек, плагинов, гемов или фреймфорков.

Что-то похожее встречается при работе со сборщиками в «новых» концепциях asp.net и т.п. В общем подобную историю можно встретить довольно часто, а временами, кроме прочего еще и наткнуться на Dependency Hell, в общем путей в ад много.

И, пожалуй, я хотел бы упомянуть здесь поведение, популярное среди HDD-разработчиков —  Stack Overflow driven development  —  когда разработчики копипастят решения со Stackoverflow (или в принципе откуда-то с просторов интернета) без реального понимания их сути.

HDD это о том, как команды несут погибель сами себе

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

Корнем всех зол, видятся, социальные медиа — где новые идеи распространяются гораздо быстрее, чем они тестируются и гораздо быстрее, чем люди в состоянии оценить их плюсы и минусы.

Анатомия обмана

Большая часть хайпа имеет сходую структуру. Она на картинке:

Шаг 1: Реальная проблема и решение

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

Шаг 2: Презентация, шумиха и «ключевые слова»

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

Шаг 3: Мания

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

прим. Я лично неоднократно сталкивался с подобным. А вы?

Шаг 4: Разочарование

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

Шаг 5: Осознание!

Наконец, команда делает ретроспективу и понимает, что именно несет новая технология и с какой целью ее использование было бы более уместным. Они становятся мудрее … ну, по крайней мере до следующего хайпа. ^_^

Примеры хайпов:

Давайте исследуем некоторые примеры хайпов и посмотрим как это было.

Пример 1: React.js

Шаг 1: У Facebook была проблема — сложные одностраничные веб-приложения, каким является Facebook, имеют множество различных событий изменяющих состояние в следствии чего становится сложно отслеживать происходящее и последовательно изменять состояние.

Шаг 2: Facebook представил новую парадигму с шумихой вокруг ключевых слов: functional, virtual DOM, components.

Шаг 3: Мания: Facebook создал фреймворк переднего-конца будущего (прим. простите, «front-end framework»)! Давайте всё писать на React!

Шаг 4: Погодите ка, работы много, но возврат инвестиций совсем не быстрый.

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

Пример 2: TDD мертв благодаря DHH

Шаг 1: David Heinemeier Hansson (DHH, создатель фремворка Ruby on Rails)  осознает что трудно использовать TDD с Rails поскольку этот фреймворк не поддерживает в должной мере OOP. Делает прагматичный выбор — не писать тестов заранее.

Шаг 2: Хайп начинается с сообщения в блоге DHH blog post и разговора на конференции conference talk. Ключевые слова: TDD мертв.

Шаг 3: Давайте пропустим тесты. Наш Гуру так сказал. Мы все равно их не писали, теперь мы по крайней мере не делаем вид, мы наконец-то честны.

Шаг 4: Подождите! Намного меньше вещей стало работать по сравнению с тем что было раньше. Мы написали какой-то очень глючный код!

Шаг 5: “TDD не жив или мертв. TDD зависит от принимаемых компромиссов, например риск изменения API, навыки участников и существующий дизайн” — Кент Бек.

Пример 3: Микросервисы

Шаг 1: Большие монолитные приложение сложно масштабируемы. Вот почему наступает момент когда мы разбиваем их на сервисы. Так будет легче масштабировать с точки зрения количества запросов в секунду и разделения зоны ответственности между несколькими командами.

Шаг 2: Ключевые слова: масштабируемость, слабосвязность, монолит.

Шаг 3: Давайте перепишем все на сервисы! У нас тут «спагетти код» потому что у нас монолитная архитектура! Мы должны переписать все на микросервисы!

Шаг 4: Дерьмо! Теперь мы разрабатываем медленнее, у нас сложности с развертыванием и мы тратим массу времени на отслеживание багов между несколькими системами.

Шаг 5: Микросервисы требуют серьезных навыков DevOps у команды и с правильными подходом могут окупиться как вариант масштабирования система и команды. Пока вас не коснулись серьезные проблемы масштабируемости использовать такой подход — лишние издержки. Микросервисы извлекаются, а не пишутся.

Пример 4: NoSQL

Шаг 1: SQL базы данных имеют большие проблемы с высокой загрузкой и неструктурированными данными. Команды по всему миру начинают разрабатывать новое поколение баз данных.

Шаг 2: Ключевые слова: масштабируемость, BigData, высокая производительность.

Шаг 3: Наши базы данных слишком медленным и не недостаточно вместительны! Нам нужен NoSql!

Шаг 4: Нам нужно связать таблицы? Ну нет. Простые SQL операции становятся все более сложными. Разработка замедляется, а ключевые проблемы так и не решены.

Шаг 5: NoSql это иструмент для решения очень специфичных проблем (чрезвычайно большие объемы данных, неструктурированные данные или очень высокая нагрузка). SQL на самом деле является отличным инструментом и справляется с высокой нагрузкой и огромными объемам данных, если его использовать с умом. Варианты для NoSQL по прежнему крайне редки в 2016 году.

Пример 5: Elixir and Phoenix (или поставьте сюда пару своих любимых языков/фреймворков)

Шаг 1: Веб-фреймворки типа Ruby On Rails плохо справляются в случаях когда нужно иметь дело с высоконагруженными приложениями, распределенными приложениями или веб-сокетами.

Шаг 2: Ключевые слова: масштабирумость, высоконагруженные, распределенные, отказоустойчивость.

Шаг 3: О, мой хороший, (прим. я почти уверен, что у автора опечатки и он имел ввиду О боже мой!) наше приложение медленное и наш чат не масштабируется!

Шаг 4: Ничего себе, изучение функционального программирования и распределенного подхода не так просто. Мы двигаемся очень медленно.

Шаг 5: Эликсир и Феникс великолепные фреймворки, но требует значительных усилий на изучение. Они окупаются в долгосрочной перспективе, если вам нужно дейтвительно специфическое высоконагруженное приложение.

Можно продолжать и продолжать:

В JavaScript новые фреймворки рождаются каждый день. Node.js (ключевые слова: программирование событий), реактивное программирование, Meteor.js (ключевые слова: shared state), передний конец MVC, React.js. В программной инженерии рождаются новые архитектуры: Domain Driven Development, Hexagon, DCI. А какой хайп предпочитаете вы?

Хорошие практики

Итак, если не стоит полагаться на мнения высказанные другими людьми в интернетах, то как принять разумное решение? Здесь несколько хороших практик:

Тестируй и исследуй до принятия решения:

• Spikes  — узнавайте интересующую вас технологию не из блогов, а лично, на своем опыте. Возьмите пару дней, чтобы создать прототип новой функциональности в новой технологии, прежде чем принять решение. Пусть команда проанализирует плюсы и минусы. Возьмите несколько конкурирующих технологий и пусть разные части команды создают свои прототипы.
• Hackathon — отличный способ для повышения уровня информированности команды о разных технологиях. Выберите пару дней для всей команды, чтобы пощупать все технологии, которые находятся на подъеме и заманчиво выглядят для использования. Это позволит членам команды сделать своё осознанное решение.

Когда?

• В принципе, когда ожидается значительная отдача от инвестиций. Большинство технологий создаются для решения конкретной задачи. Есть ли проблема? Это большая проблема? Будет ли сэкономлено много времени? Окупится ли использование новой технологии с учетом входа в нее и переписывания кода? Что делать, если мы изначально замедлились в два раза? А если четыре? Является ли она по-прежнему стоящей?
• Великим командам разрешено больше — некоторые команды просто быстрее чем другие приносят ценность. Им становится скучно с тем, что им дается очень легко. Эти команды могут внедрять новые технологии все чаще. Это не повод, чтобы не использовать Spikes и не делать Хакатоны. С другой стороны, если у команды есть проблемы  — действовать с осторожностью.

Нанимайте на работу правильных людей:

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

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

Терапевт послушал меня, посмотрел, говорит ну это печень, вот вам направление на УЗИ и всякие анализы, и чуть ли не на гастроскопию меня запихнул в общем (благо я до нее таки не дошел).

В общем надо лечить ваш желчный и селезенку и бла бла бла.

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

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

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

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

Посмотрел он на меня и говорит — вот тебе контакт остеопата в СПб, он поможет тебе лучше. Даже денег за совет не взял.

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

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

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

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

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

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

А напоследок прекрасное фото из Санкт-Петербурга.