[Об авторе: Сергей Королев — управляющий директор в Railsware с более чем 15-летнимопытом работы в ИТ: от стартапов до корпораций. Инженер, продакт-оунер, бизнес-лидер]

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

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

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

Холакратия предусматривает не должности, а роли — то есть сотрудники могут одновременно исполнять несколько ролей в компании, они не привязаны к одной должности. Если возникает необходимость в реорганизации (например, из-за изменения условий рынка), гибкий подход позволяет пройти этот процесс быстрее и без серьезных трудозатрат.

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

Формирование стратегии

Стратегическая сессия на 45 человек и открытая дискуссия — абсолютно неконтролируемый процесс. Поэтому мы организовали сбор и анализ информации в четыре этапа. Для каждого была создана своя инфраструктура, которая на 95% состояла из Google Spreadsheets+Forms, Hangouts. Коммуникацию до и во время сессии вели через BigMarker и Slack.

Этап 1. Опрос

Все сотрудники были распределены в сбалансированные группы. Основные параметры распределения — роль в компании, стаж работы, проект, локация.

Каждый сотрудник (Railswarian) в формате ретроспективы выделил топ-3 «что в компании хорошо» и топ-3 «что улучшить».

Инструменты: Google Forms + Google Spreadsheets.

Пример того, что хорошо

Пример того, что улучшить

Этап 2. Приоритизация

Каждая из групп получила список пунктов «хорошо» + «улучшить» своих участников. Во время сессии в условиях ограниченного времени группе нужно было определить свои топ-5 «хорошо» + топ-5 «улучшить» пунктов. Таким образом, проверяли индивидуальные пункты и выбирали наиболее важные.

Инструменты:

• BigMarker — для проведения крупных удаленных митингов. В сумме получилось 9 локаций по всему миру, 11 подключений.
• Google Spreadsheet — для работы со списками «хорошо» / «улучшить».

Этап 3. Классификация

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

• Необходимо было убедиться, что каждый пункт относится к одному контексту. Поэтому мы разбивали пункты, затрагивающие несколько контекстов, на более атомарные и конкретные.
• Каждому из единичных пунктов был присвоен тег. В итоге получили 33 тега, по каждому из них — от 1 до 6 пунктов.

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

Инструменты: Google Spreadsheets + Google Forms — для голосования и обработки результатов.

Этап 4. Реализация

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

Далее дело за реализацией: определить стратегические цели компании -> тактику -> план действий -> контроль выполнения.

Все топ-пункты с указанием приоритета добавлены в структуру компании. Далее каждый из сотрудников может отметить свою заинтересованность в каждом из направлений работы. Так мы определяем проектные команды.

Итоги

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

Организация процесса:

• Сбор отзывов каждого сотрудника в формате топ-3 «что в компании хорошо» и топ-3 «что улучшить».
• Верификация фидбэка в группах по 5-6человек — выбор топ-5 пунктов «хорошо» и топ-5 «улучшить» от каждой группы.
• Классификация пунктов от команд.
• Определение приоритета по каждому пункту (подход MoSCoW) путем общего голосования.
• Распределение всех пунктов по структуре компании с указанием приоритета.

Инструменты:

• GSuite — сильный акцент на Google Spreadsheets + Google Forms с применением DataBlending подхода.
• BigMarker — для проведения крупных онлайн-митингов.
• Инструмент для фиксации и трекинга прогресса по целям (можно использовать JIRA или другие инструменты, в нашем случае — структура компании).

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

Организационная структура:

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

Подходы к принятию решений:

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

Культура:

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

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

Читайте также:Власть сотрудникам: нужна ли холакратия украинским IT-компаниям

[В серії «Огляд IT-ринку праці»ми розповідаємо про IT-індустрії в різних містах України]

В ІТ-індустрії Рівного зайнято 700-1000 спеціалістів.В місті працює більше 20 ІТ-компаній, а виші щорічно готують понад 400 майбутніх ІТ-фахівців.

Середні зарплати програмістів у Рівному:

• Junior — $300;
• Middle — $1000;
• Senior —$2200.

Тутможна подивитися більш детальну статистику зарплат за мовами програмування та іншими ІТ-спеціальностями.

Компанії

Більшість рівненських ІТ-компанійзаймаються аутсорсингом, але представлено і продуктовий сегмент. Серед найбільших та найвідоміших працедавців міста:

SoftServe

Українська аутсорсингова компанія
240 спеціалістів у Рівному, 4863 в Україні

Компанія займається розробкою ПЗ для клієнтів із США та Європи, серед яких — HomeAway, Vovici, Avery, Cisco, Medhost. Експертні сфери: корпоративний сегмент, охорона здоров’я, фінанси, роздрібна торгівля, медіа.

В Рівному багато проектів на С++, а також на .NET, Python, Java Web UI та Go.

Можливості для початківців:SoftServe IT Academyзапрошує студентів на безкоштовні курси та надає можливість працевлаштуватись після їх закінчення. Навчання триває 2-3 місяці.Відбір проводиться на конкурсній основі. Окрім цього, SoftServe у Рівному започаткував курси англійської мови з акцентом на ІТ.

SoftGroup

Українська аутсорсингова та аутстафінгова компанія
100+ спеціалістів у Рівному, 280+ в Україні

Компанія розробляє ПЗ для клієнтів з Європи та США. Експертні сфери: Business Intelligence, Enterprise Architecture, Mobile Application Services.

Основні технології: .NET, Delphi, PHP, HTML5/CSS3, Python, Perl, iOS/Android.

Можливості для початківців: SoftGroup Academy — безкоштовні курси з можливістю подальшого працевлаштування. Навчають PHP, Drupal, Wordpress, Ruby, Python, Angular/JavaScript, iOS, Java/Android. Щоб стати студентом академії, необхідно володіти базовими технічними знаннями і англійською.

Renome-Smart

Українська продуктова та аутсорсингова компанія
40+ технічних спеціалістів у Рівному

Компанія розробляє та впроваджує Software і Hardware-рішення для банків, логістичних компаній, ритейлу, телеком-операторів, а також надає послуги з повного аутсорсингу операційної діяльності.

Розробками Renome-Smart користуються банки та фінансові організації 15 країн світу. В Україні продукти компанії використовують 26 Центрів надання адміністративних послуг, а також кожен третій АТМ.

HoneyComb

Українська аутсорсингова компанія
30 спеціалістів у Рівному, 40 в Україні

Компанія розробляє ПЗ для клієнтів з США, Канади, Ізраїлю, Швеції, Німеччини та Австралії. Експертні сфери: e-Commerce, транспорт, охорона здоров’я, проекти, пов’язані з благодійністю.

Ноneycomb Software спеціалізується на веб-розробці на платформі .NET. Основні технології: C#, ASP.NET MVC, ASP.NET Core, MS SQL Server, PostgreSQL, MySQL, Angular, ReactJS, Azure, AWS.

Можливості для початківців: компанія надає можливість пройти інтернатуру за детальною програмою з сучасними технологіями. Окрім цього, Ноneycomb Software активно співпрацює з місцевими ВНЗ. Раз на місяць проводить«Годину коду» зі студентами.

Zagrava Games

Українська аутсорсингова та продуктова компанія
30 спеціалістів у Рівному

Студія надає аутсорсингові послуги з розробки ігор, а також створює власні продукти. Команда розробила більше 30 мобільних та веб-ігор, найвідоміші з яких — «The Hunt for Red Panda» та «Chasing Chaster».

Основні технології: C++/C#, Unity 3D, Cocos 2Dx, HTML5, Flash, HAXE, iOS/Android.

Selecto

Українська аутсорсингова компанія
23 спеціалістів у Рівному, 25 в Україні

Компанія займається веб- та мобільною розробкою, а також UI/UX дизайном. Експертні сфери: фінанси, нерухомість (CRM), розваги, соціальні мережі, B2B, охорона здоров’я.

Основні технології: iOS, Android, Python (Django, Flask), NodeJS (Expres, Sails, Adonis), JavaScript, TypeScript, PHP (Symfony, Llaravel), MySQL, MSSQL, MongoDB, PostgreSQL.

Можливості для початківців:в компанії немає спеціальних програм стажування для студентів, але впроваджено менторство для працівників рівня Junior.

Також у Рівному є офіси таких IT-компаній:

• Adyax — створює web-сайти та додатки на базі Drupal для відомих світових брендів і урядових установ. Експертні сфери: корпоративні бізнес-додатки, платформи e-Commerce, ритейл, багатоканальне поширення мультимедіа, сайти на базі платформи Drupal.
• Gekos — створює сайти, займається контекстною рекламою, SEO, SMO, PR кампаніями, консультує щодо становлення бізнесу в інтернеті.
• InternetDevels — займається веб-розробкою на Drupal. Окрім розробок для бізнесу, бере активну участь у технічному розвитку платформи Drupal в цілому.
• QATestLab — надають повний спектр послуг з тестування ПЗ, консультування по якості.
• /shortcute — розробляє UI&UX дизайн веб-, десктоп- та мобільних проектів. Експертні сфери: банківська справа, e-Commerce, e-Learning, інтернет-трансляції, месенджери.
• Testmatick — займається ручним і автоматизованим тестуванням ПЗ. Експертні сфери: фітнес, готельно-ресторанний бізнес, облік витрат, email-маркетинг, подорожі, фінанси.
• Virtuace — розробляє ПЗ, використовуючи Java та PL/SQL. З 19 березня розпочинає програму стажування для нових співробітників.
• Wedes Web Studio — створює мобільні додатки під iOS та Android для клієнтів з Америки та Європи, веб-додатки та сайти для Рівного, України та Європи. Основні технології: JavaScript, MySQL, Node.js, Angular, Ionic, React/Redux, React Native, TypeScript, RESTful, Symfony, Redis. Для новачків можливе стажування з подальшим влаштуванням на роботу.
• ZoomSupport — займається цілодобовою дистанційною підтримкою користувачів продуктів Microsoft та Apple у всьому світі.
• 32×32 — створює сайти, а також займається їхнім просуванням та підтримкою.

Продуктовий сегмент представлено компаніями:

• AB Games — створює ігри для мобільних платформ та соціальних мереж. Найвідоміша розроблена гра — «HiddenCity: Загадка Тіней», в яку грають мільйони гравців у більше, ніж 14 країнах світу. Компанія відкрита для набору початків до відділу розробки: відбір проходить на основі тестового завдання із написання гри, яке потребує базового рівня C++.
• Axxos — розробляє власний продукт для моніторингу виробничих ліній, оцінки ефективності виробництва, аналітики для покращення рівня доступності і продуктивності виробництва.
• Splynx s.r.o.— займається розробкою платформи для білінга та управління ISP. Продукт використовують більш ніж 400 провайдерів по всьому світу.

За вакансіями в місті можна стежити тут.

Спільноти та події

Rivne IT Talks — зустрічі ІТ-спеціалістів міста. Регулярно організовують зустрічі, присвячені різним технологіям та напрямкам в ІТ. Організатор — компанія SoftServe. Учасниками заходів можуть стати всі охочі.

Drupal IT Talks, лютий 2018

IT-Weekend Rivne — найбільша ІТ-конференція регіону від компанії SoftServe. Кожного року захід присвячують різним технологіям: минулого року обговорювали .NET та Project Management.

Слідкувати за подіями у Рівному запрошуємо в Календарі.

Освіта

ІТ-спеціалістів у Рівному готують у чотирьох вишах:

• НУВГП (інститут автоматики, кібернетики та обчислювальної техніки);
• МЕГУ ім. С. Дем’янчука (факультет кібернетики);
• Рівненська філія ЄУ (кафедра інформаційних систем);
• РДГУ (факультет математики та інформатики).

Найбільші ІТ-школи:

• SoftServe IT Academy (.NET, Java, Web UI, C++, DevOps, iOS, QC, ATQC, DataBases, UX);
• SoftGroup Academy (PHP, Drupal, Wordpress, Ruby, Python, Angular/JavaScript, iOS, Java/Android);
• 4WEB (Front-end, Back-end, Mobile, SEO, SMM);
• Kid’IT (Python, Scratch, Tynker, Lego Mindstorm);
• КА «Шаг» (розробка ПЗ, комп’ютерна графіка та дизайн, мережеві технології та системне адміністрування).

Перспективи Рівного як ІТ-регіону

Сергій Сидорчук, директор рівненського офісу SoftServe:

Попри те, що Рівне є досить компактним містом, тут зосереджена низка потужних вищих навчальних закладів, де вчать майбутніх ІТ-спеціалістів. Серед них НУВГП, НУ «Острозька академія», РДГУ, КА «ШАГ». Університети є відкритими для співпраці: минулого року за підтримки SoftServe НУВГП відкрив нову спеціалізацію «Інтернет речей», яка, я впевнений, з кожним роком набиратиме обертів.

Завдяки співпраці з випускниками вишів, а також різноманітним освітнім програмам SoftServe IT Academy ми маємо великий потік Junior-спеціалістів, яких вчимо та розвиваємо завдяки внутрішній навчальній екосистемі. Попри це, у рівненському девцентрі SoftServe працює 60% спеціалістів рівня Middle та Senior.

Ми також активно розвиваємось як ІТ-спільнота, працюючи над створенням необхідної інфраструктури для життя та роботи ІТ-фахівців. Днями були анонсовані плани щодо створення у місті Рівненського ІТ-кластеру. На мою думку, спільна робота ІТ-компаній та місцевої влади над стратегічним розвитком ІТ зроблять Рівне ще більш привабливим містом для талановитих людей, які хочуть поєднати життя у комфортному, затишному і красивому місті з роботою в динамічній, технологічній і конкурентній ІТ-сфері.

Існує думка, що люди хочуть їхати у великі міста, такі як Київ чи Львів. Однак зараз дедалі більше людей переїжджають до Рівного з великих міст та з-за кордону, адже тут затишно, як удома.

Олександр Семенюк, СЕО Honeycomb Software:

Рівне є дуже комфортним для проживання, тут наявна вся необхідна інфраструктура. Місто досить невелике, тому більшість спеціалістів знають один одного особисто. Питання репутації компанії є дуже важливим.

IT в Рівному має ті самі проблеми, що і IT України в цілому:
— відсутність кваліфікованих спеціалістів;
— перегрітий ринок праці;
— відставання освітніх програм від потреб ринку;
— міграція цінних спеціалістів до Києва, Львова, за кордон.

Окремо хочу відмітити цікавий факт, що з ростом кількості IT-компаній до Рівного почали повертатися ІТ-спеціалісти. Погодьтесь, що витрачати 2 години на проїзд у великих містах — нераціонально.

Юрій Мамончук, СЕО Selecto:

Ми помітили, що людині сьогодні не так важливо бути в уже сформованому центрі суспільного життя, як важливо бути його творцем. І на перший план вийшла родина, рідне місто: українці почали цікавитись відродженням своєї маленької батьківщини. Отже, створювати можливості для професійного розвитку в невеликих містах сьогодні варто.

Які тут є перешкоди? Наразі основна проблема не в наявності робочих місць, а у належній підготовці спеціалістів. Перш за все, нам треба забезпечити високоякісну ІТ-освіту у Рівному. Бо погодьтеся, якщо людина поїде навчатися до Львова, Києва чи Харкова, вірогідніше, там вона і лишиться. Статистика показує, що у студентські роки люди здобувають найбільшу кількість контактів і завдяки ним вже обирають роботодавця.

Зі сторони компаній-роботодавців також саме проблема освіти є ключовою при виборі міста для відкриття офісу. Адже спектр кадрів більший у містах, де є відповідні університети та вже згуртовані спеціалісти галузі. Якщо ж говорити про запрошення на роботу працівників з інших міст, то тут мова йтиме не про освіту, а про належну інфраструктуру та розвиток культури. Забезпечивши ці два аспекти в Рівному, ми зможемо побудувати прогресивну ІТ-спільноту міста.

Ми вже почали працювати над цим. Запит від людей на розвиток індустрії є: ми знайшли безліч невеличких команд, які самотужки намагаються будувати ІТ-бізнес. Прогресивні компанії, які представлені в місті, зараз прагнуть об’єднатися для розвитку ІТ-ринку, щоб поділитися вже перевіреним досвідом та застосувати його у цьому місті. Спільними силами ми набагато швидше створимо в Рівному такі умови, щоб таланти не мусили покидати рідне місто, а бачили перспективи тут.

Див. також огляд IT-ринку праці інших міст:
Вінниця, Дніпро, Житомир, Запоріжжя, Івано-Франківськ, Луцьк, Львів, Миколаїв, Одеса, Полтава, Рівне, Суми, Тернопіль, Ужгород, Харків, Херсон, Хмельницький, Черкаси, Чернівці, Чернігів

[Об авторе: Николай Лотоцкий — более 15 лет занимается разработкой программного обеспечения. Знаком со всеми этапами работы на проекте и развил карьеру от должности QA Engineer до Technology Expert. Несколько лет был JavaScript Software Architect и принимал активное участие в разработке сложных масштабируемых приложений. Кроме того, есть опыт работы с PHP, .NET, Python. Более трех лет проводит различные курсы и тренинги]

Как активно практикующий преподаватель я часто сталкиваюсь с жалобами, что в последнее время попасть в IT становится все труднее и труднее. С другой стороны, как человек, активно принимающий участие в разработке, не могу не отметить, что в отрасли есть устойчивый дефицит кадров. Давайте же разберемся, стоит ли начинать изучение IT на курсах и чего от них ожидать.

В данный момент наблюдается огромный наплыв «вайтишников». Понятно дело, экономический кризис — а тут зарплата в долларах, плюс нормальные офисы, обустроенное рабочее место, внятный график работы. Мотивация людей, стремящихся в IT, проста и понятна. Опять же, огромное число курсов с объявлениями в метро, что мол IT-шники на метро не ездят. У среднего индивидуума рождается мысль: «А чо? Чем я хуже?». Ведь я в метро, а они на метро не ездят! Пойду-ка я на курсы!

На курсах их встречает приветливый менеджер и обещает, что вот мы-то вас научим! Только надо оплатить. И тут мы сталкиваемся с первой проблемой. Когда-то в 90-егоды были популярны кассеты «Метод Илоны Давыдовой». Распространители сего метода обещали, что достаточно будет просто прослушать пять или шесть пленок в плейере, и вы заговорите на английском сами по себе. Так вот, в последнее время складывается впечатление, что 75% слушателей курсов желают увидеть этакий вариант «Метода Илоны Давыдовой». Теперь перейдем к проблемам.

«Я же заплатил, меня научат»

Это упорное убеждение есть везде. Я пропустил половину пар — но меня ж научат, я ж заплатил. Я пришел на пару с бодуна и не отстреливал ничего — но я заплатил, меня научат! Я не делаю домашнее задание — но я ж заплатил, меня научат! Я буду просто слушать, ничего не делать — но я ж заплатил, меня научат! Это первый бич слушателей, приходящих на курсы. Они считают, что им кто-то что-то должен. Да, вам должны. Вам должны отчитать нормально курс — и ничего более! За вас не должны делать домашние задания. За вас не должны посещать пары.

IT — это усердие и тяжелый труд

Самое главное, что я говорю студентам: IT — это не легкие деньги. Это 90% попа-часы и 10% понимание. IT — это усердие, это тяжелый труд, это кропотливая работа, которая на первый взгляд кому-то не видна, и на второй, кстати, тоже. Какой бы ни был классный преподаватель, он не сделает за вас главного — надо научиться работать. И если преподавателю не все равно, поверьте, он будет забивать на ленивых студентов и будет пытаться обучить усидчивых. Как по мне, это и есть задача преподавателя — отделять агнцев от козлищ. Давать шанс тем, кто его заслуживает, и предоставлять не заслуживающих его самому себе.

Возможно, программирование — это не ваше

Так бывает. Я, например, всегда хотел уметь лепить из глины. Но годы попыток вылепить что-то более-менее достойное и даже покупка гончарного круга — не дали желаемого результата. Выходили какие-то поделки раннего палеолита. В конце концов я понял, что это не мое. Я продал гончарный круг другому «гончару» и успокоился. Я сказал себе правду: это не мое. Так что будьте честными с самими собой. Это самое главное. Но если программирование это не ваше — это еще не повод не идти в IT. Там есть много различных отраслей и направлений.

Диплом не имеет никакой ценности

С советских времен мы привыкли, что без бумаги человек — не человек. Так вот, диплом, который вам дадут на курсах, не имеет абсолютно никакой ценности при поступлении на работу. Ценность имеют только знания. Диплом курсов — это даже не кусок картона в рамке, хотя рамку потом можно будет использовать, для того чтобы вставить в нее семейное фото. Так вот задумайтесь, стоит ли покупать рамку для семейного фото за такие деньги, если ее можно купить гораздо дешевле в любом переходе метро? Как по мне, не стоит. И опять же, на своем примере скажу, что студентам, которые, на мой взгляд курс, не прошли, я своей подписи на дипломах не ставлю. И обращаюсь к другим преподавателям: не ставьте подписи на дипломах тех людей, которые, на ваш взгляд, не выполнили требований курса. Есть еще опыт советской академической школы, где просто писалось: «Человек прослушал курс».

Выбирайте соответствующий уровень курсов

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

Коммерческие курсы в наше время — это бизнес

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

«А интересно ли мне это вообще?»

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

Так стоит или не стоит?

По окончании коммерческих курсов в отрасль попадает, по моим расчетам, где-то 10% слушателей. Это не повод не идти на курсы. Это повод задать себе вопросы: «Мое ли это?», «Готов ли я работать или только буду имитировать бурную деятельность?». Далее стоит почитать интернет, нет, не отзывы о курсах, а данные о той технологии, которую вы собираетесь там изучать. Может, курсы и не нужны? Может, стоит завести GitHub и просто начать педалить? Может, стоит просто принять участие как падован в опенсорс-проекте? Там вы научитесь гораздо большему, чем смогут вам дать любые курсы. Заодно и сэкономите скудные бюджеты, кризис же в стране все-таки. И несмотря на мрачный тон статьи, пробовать стоит.

Я каждый раз, собираясь забрасывать преподавательскую деятельность, вспоминаю имена Д. Левада, М. Олешко, А. Захаров, Ю. Максимович, И. Сыров и другие. И тогда понимаю, что я должен идти в аудиторию. Должен потому, что хочу дать шанс именно таким ребятам — ребятам, которые хотят и могут, и именно для них, а не для кого-то другого я должен (именно должен) выполнять свой общественный долг. Потому что были люди, научившие меня, и теперь мое время отдавать долги.

P. S. Огромное спасибо моим учителям Андрею Коцарю (девелопмент), Дмитрию Сыркину (QA) и Максиму Кортунову (менеджмент). Именно благодаря вам я стал тем, кем стал.

Я постараюсь описать весь свой опыт и те подводные камни, которые я встретил при подготовке к собеседованию в Google и другие компании Долины (Microsoft, Amazon, Snapchat, Evernote, Cruise Automation, Uber и др.). Я ставил цель получить оффер от Google или Facebook, а еще лучше от обоих, все остальные компании были из разряда «ну если там будет очень интересно, то можно». С первого дня, когда я начал подготовку, до момента, когда я получил оффер от Google, прошло 1 год и 5 месяцев. Первый оффер я получил после 1 года и 2 месяцев подготовки. Всего было 7 онсайтов (интервью в офисе компании), из них 3 оффера (Google, Evernote, Cruise Automation). Итак, начнем.

Предыстория

Я был вендором в Google в Mountain View на протяжении полутора лет. Там же было несколько гуглеров, которые тоже были вендорами до этого. Конечно, мозг постоянно подсказывал, что они «другие», что они «умнее-лучше-круче», чем я. А мой удел — быть вендором. Я даже один раз попробовал решить задачку на LeetCode. Осилить я смог 5-ю easy задачку, которая получилась на 120 строк кода и в результате так и не прошла тесты. На это ушло 5 часов прекрасного субботнего калифорнийского дня. Я окончательно понял, что вот всем вокруг «дано», а мне нет.

Но все же, проводя с друзьями-гуглерами много времени, я понял приблизительный алгоритм — что и как нужно делать. Я сделал в точности, как они сказали, и получил оффер (чему был немало удивлен). Второй нюанс — в Google я делал front-end, все мои друзья были back-end, и подготовку они описывали именно для back-end. Я подумал и решил: «А back-end тоже хорошо (я же когда-то писал на .NET, хотя и давно), буду идти в точности как они, но сделаю больше, чем они, и тогда точно получу оффер».

Мотивация

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

Что я имею ввиду. Подготовка требует много времени: приблизительно 2-3часа каждый рабочий день и каждый выходной полностью. То есть, по сути, все свободное время. Я был без жены и детей, и было проще, с одной стороны, — никто не требует постоянного внимания. С другой — никто и не поддерживает.

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

Кроме того, нужно четко понимать, для чего ты это делаешь и что хочешь получить. И лучше всего, чтобы эта цель была вне тебя, больше, чем ты. Если что-то делаешь только для себя — в трудные периоды можно забить, если для кого-то — мотивация намного выше, и это помогает не остановиться.

Пример 1: «Я хочу в Google, потому что это круто», «Я хочу в Facebook, потому что там много денег» — это для себя. В любой момент можно найти статью о том, что Google — это дерьмо, что денег там дали меньше, чем в другой компании, что там скучно, много политики. И что? И все, мотивация упала, книжки с алгоритмами летят в окно.

Пример 2: «Я хочу в Google, чтобы вывезти свою семью в США и дать детям хорошее образование», «Я смогу, имея деньги от Facebook, сделать это и это». В моем случае мотивация звучала так: «Я хочу быть ближе к дому». Я рассматривал переезд в Лондон либо Цюрих. Когда я начал подготовку, я себе так сказал: «Пацан, ты следующий раз полетишь домой, когда получишь оффер, и только так». Домой хотелось, и это давало энергию. Я думаю, это работает не для всех и не всегда, но для меня сработало.

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

Процесс в общем

Весь путь можно разделить на несколько этапов:

1. Решение задач на LeetCode или InterviewBit.
2. Изучение алгоритмов и структур данных.
3. Повторение решенных задач на LeetCode.
4. Подготовка к дизайн-интервью.
5. Mock-интервью (телефонные и на вайтборде).
6. Реальные интервью.
7. Оффер и алкогольное забвение.

Решение задач

Это самая важная и самая длительная часть подготовки.

Сколько задач нужно решить? Я считаю — 200-250,из которых 40-50% easy, 40-50% medium, 10-20% — hard. Я решил около 300, мои друзья — 120-160.

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

А что если я сначала прочитаю всю книжку «Cracking Coding Interview»с решенными задачками и уже весь подготовленный пойду в бой? Не стоит:) Решение, которое я просто прочитал, я не мог вспомнить даже под конец того же дня, не говоря уже через несколько дней.

Можно прочитать начало «Cracking Coding Interview». Там хорошо описан сам процесс интервью, как общаться, базовые вещи об алгоритмах и структурах данных, как анализировать сложность алгоритмов и т. д. К примеру, как анализировать сложность рекурсивных алгоритмов я понял именно из нее.

Перед тем как начать решать задачки на определенную тему можно прочитать решение схожих задач в «Cracking Coding Interview». Причины тут две:

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

А какие вообще существуют задачи, какие темы нужно покрыть?Понять, какие вообще тематики существуют, можно с InterviewBit. Мне не очень понравилось там решать задачи, но вот общее представление я получил. Ну и кроме того, можно полистать «Cracking Coding Interview».

В какой последовательности стоит решать задачи?Нужно идти от простых тем к сложным (InterviewBit подскажет порядок). В каждой теме решать задачки до тех пор, пока не начнет хоть чуть-чуть получаться, и в этот момент сразу переключиться на следующую тему. Начинать, конечно, с уровня easy. Я пытался решать каждую задачу на протяжении около получаса-часа. Если не смог — шел смотреть решение. На LeetCode к каждой задаче есть форум, где люди постят свои решения, обсуждают, голосуют. Я выбирал топ решений и изучал их, так и учился. Наверное, эти форумы — самое ценное место для обучения. Далеко не все решения просто понять, даже те, под которыми стоят комментарии «This is absolutely awesome!!!».

Например, начал я решать задачи на строки. 1-я —не решил, пошел смотреть решение, 2-я...5-я —то же самое. 6-я,7-я —решил. Значит, пора переключиться на следующую тему. Секрет такой — переключаться между темами нужно как можно чаще, так лучше запоминается. Но если переключиться до того, как начнет получаться, то через несколько тем можно демотивировать себя полостью. Мозг услужливо подскажет: «Ну раз ты ничего не можешь решить — то иди выпей пивка и посмотри футбол, это просто не твое». Нужно быть готовым к тому, что самооценка и настроение будут как американские горки: получается — мы несемся вверх, не получается — унываем и падаем вниз. Просто нужно помнить, что и первое, и второе — это временно, нужно продолжать. Если долго нет результата — брать задачки проще.

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

1. Читаем условие задачи, ни в коем случае не пытаемся придумать решение до того, как условие прочитано до конца. Это важно!!! Мозг пытается найти похожую задачу, решение которой он знает, и выдать за требуемое.
2. Пытаемся придумать уточняющие вопросы. Пример 1: есть задача, в которой нужно как-то трансформировать строку. Что спрашивать? — Какие символы могут быть в строке — ASCII или Unicode? Могут ли рядом стоять несколько пробелов? Могут ли быть пробелы в начале или конце строки? Есть ли спецсимволы типа -,.^/ ? Есть ли разница для анализа между большой и маленькой буквами? Насколько длинная входная строка? Помещается ли она в память машины? Пример 2: есть массив из Integer, в нем нужно что-то найти. Вопросы: есть ли повторяющиеся элементы? Есть ли отрицательные числа? Что если в результате подсчета мы получим больше, чем Integer.MAX_VALUE?
3. Рисуем примеры, лучше парочку — один классический, второй с corner cases. После этого мы +/- должны быть уверены в том, что задачу мы поняли правильно.
4. Придумываем решение «в лоб» и оцениваем его сложность. Сложность решения нужно уметь определить всегда.
5. Придумываем более оптимальное решение, оцениваем его сложность.
6. Разрабатываем API решения — какие будут методы (приватные и публичные).
7. Пишем код в тетрадке.
8. Дебажим код по тетрадке на новом примере. Не нужно брать один из примеров, который мы рисовали в начале. В этом случае очень высока вероятность, что мы написали решение именно для этого случая, а не для всех возможных. Лучше взять новый пример с corner-кейсом, такой, чтобы потенциально мог решение сломать.
9. Перебиваем код в любимую IDE, при этом не смотрим в бумажку. Таким образом, мы повторяем решение два раза.
10. Копируем код из IDE в LeetCode и запускаем. В случае идеального выполнения должно cработать правильно с первого раза. У меня такое получалось в 10% случаев.

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

А что же делать, если задачка не решается?Когда я не смог придумать решение за полчаса-час (сначала бывало, что я по полдня страдал над одной задачей), то шел смотреть лучшие решения на форуме. Разбор решения — почти всегда непростая задача и требует времени: нужно пересмотреть и понять несколько решений, понять сложность, дочитать ссылки на алгоритмы, которые указывают авторы решений. Большинство алгоритмов я нашел и изучил после того, как встретил их в реальных решениях. А что же дальше с этим делать? А дальше нужно повторить с этой задачкой все шаги, которые я привел выше. И куда лучше сделать это на следующий день или как минимум под конец этого дня.

Все свои решения я заливал на GitHub. Хорошо видна статистика, и всегда есть доступ к коду. Это я начал делать после того, как LeetCode затер все мои решения. Так что LeetCode — не лучшее место для хранения своих решений.

Важно вести статистику (вот моя), в которой будет следующее:

• что когда решил;
• Group A — список задач, которые не решил самостоятельно;
• Group B — список задач, которые решил самостоятельно, но при этом очень страдал.

Это я считаю критически важным, так как задачи нужно будет повторить, и в первую очередь нужно повторять A, за ними — B.

Ноу-хау «дверь».После того, как я решил порядка 230 задач (это был мой изначальный план), я переключился на изучение алгоритмов (об этом позже). Когда в алгоритмах я прокачался, что заняло около двух месяцев, пришло время задачи повторять. И вот здесь получилась интересная штука: повторить задачу — по времени не многим меньше, чем решить ее (так как шаги нужно использовать те же, только код из тетрадки не переписывать в IDE). И тут пришла долгожданная демотивация — не чувствует организм, что делает что-то полезное, и все тут. Я стал думать, как проблему решать, понял, что я визуал и мне нужно визуальное подтверждение своей деятельности. И оно нашлось. Каждую задачу, которую повторил, я записывал на стикере: номер задачи, сложность (easy, med, hard), тема и краткое решение. Краткое решение — это не код. Как оказалось, код запомнить почти невозможно, а вот простые шаги типа «1. Создаем мапу с каунтерами, 2. Находим в ней Х ...»- вполне. Задачи из одной темы попадают в один ряд, сложность можно отмечать цветами (это я понял позже).

Цель была следующая — все решенные задачи должны быть повторены и появиться на двери как стикеры. Когда я наклеил первые 10 стикеров и это отняло несколько дней, честно скажу, хотелось плакать. Мозг подсказывал: «До 230 осталась бесконечность».

В результате на моей двери появилось 218 наклеек. Некоторые задачи я так и не успел повторить.

Дверь в начале и дверь в конце

Алгоритмы

Я изучал алгоритмы по курсам дедушки Седжвика на Coursera (Part 1, Part 2). Видео этих курсов можно найти на торрентах.

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

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

Дизайн-интервью

Дизайн-интервью состоит из так называемых открытых вопросов по дизайну, типа «как задизайнить YouTube». По началу я совсем не мог понять, что требуется и как это должно выглядеть. Потом я нашел курс «Grokking the System Design Interview», который мне открыл глаза. Он стоит свои 80 баксов.

Вот еще одно видео от Джексона (Facebook guy), которое даст понимание процесса. Хорошее обсуждение на Quora.

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

Behavioral-интервью

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

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

Mock-интервью

Mock-интервью — это то же самое, что и обычное интервью с той разницей, что его проводят друзья, коллеги или специальные компании. А потом дают свой отзыв — что хорошо, что нужно поправить. Это тоже критически важный шаг, упускать его не стоит. Конечно, будучи в Долине, сделать это в разы проще. Вокруг меня было много друзей гуглеров, действительно клевых ребят, которые мне провели порядка 20-ти mock-интервью. Я был как Том Сойер, который взялся красить забор, а в результате красили забор все. Интервью мы проводили, конечно, на английском на вайтборде со строгим ограничением по времени.

Телефонные mock-интервью (а потом и реальные) я проходил на interviewing.io. Я просто полюбил этот ресурс, ребята реально молодцы. Но они сейчас заточены под США и предоставляют этот сервис по США. Бывали дни, когда у меня в неделю было около 7-8собеседований на interviewing.io.

Сначала было страшно и некомфортно. Но к 10-муразу я привык, и стало нравиться. Первые интервью я валил, потом стало получаться. Средняя конверсия была 50%, то есть половину прошел, половину — нет. Всего телефонных собеседований (реальных и mock) было около 30-35.

Как подаваться

Самый простой и самый малоэффективный метод — заполнить форму на сайте компании. Но иногда и он дает результаты. К примеру, я заполнил форму на сайте Snapchat, и на следующий день со мной связался рекрутер, мы договорились о телефонном интервью. С Google, я думаю, это абсолютно бесполезно, так как эту формочку заполняют тысячи раз в день.

Второй способ — сайты работ типа Hired.com. Ты заполняешь все данные о себе, а потом компании, которым ты подходишь, сами с тобой связываются. Сервис ориентирован на рынок США. Без H1 или грин-карты там делать нечего.

Способ третий — interviewing.io, о котором я упоминал выше, и схожие сервисы. Они работают так: сначала ты проходишь на их платформе телефонные mock-интервью. Как только ты успешно проходишь два, они дают тебе возможность проходить анонимные телефонные интервью с реальными компаниями на их платформе. К примеру, сотрудник Uber и ты заходите в одно и то же время, и он тебя собеседует. Если прошел — дальше онсайт. Mock-телефонное и реальное телефонное интервью не отличаются вовсе. Минусов в interviewing.io несколько. Первый — они больше сотрудничают со стартапами, больших компаний мало. Второй — ориентированы на Штаты (нужна H1 или грин-карта).

Способ последний и самый эффективный — через реферала. Это когда человек, который работает в компании Х, дает референс на тебя рекрутеру. Он должен указать, откуда он тебя знает и почему считает, что ты подходишь + твое резюме. Вероятность, что с тобой после этого свяжутся, очень высока. Если не связались, скорее всего, рекрутер увидел в резюме что-то, что его насторожило.

Резюме

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

Лариса, инженер в Google, много пишет на тему интервью, Google, Долины в своем блоге. У нее есть интересный раздел «Резюме на проверку». Здесь люди открывают доступ к Google doc со своим резюме, Лариса и другие читатели его комментируют и пытаются улучшить.

Телефонное интервью

Стандартное телефонное интервью включает в себя общение голосом (по телефону, скайпу, hangouts и т. д.) и написание кода в shared Google doc или shared online IDE. Занимает по времени 1 час либо 45 минут, это нужно уточнить заранее.

Первые пару минут уходят на знакомство — интервьюер расскажет немного о себе, соискатель в ответ тоже должен рассказать, кто он и что он. У меня сначала с этим было туго, потом я написал и отточил self-presentation на 2 минуты, отрепетировал ее с помощью диктофона. Это, по сути, первое впечатление о тебе, и лучше его не испортить.

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

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

Самый эпический пример этой ошибки у меня случился на онсайт-интервью в Evernote. Задача была следующая — распарсить CSV-файл с расписанием поездов и написать программку, которая будет подбирать оптимальный поезд по определенным условиям. Можно гуглить. Я до этого код для работы с файлами на джаве не писал и растерялся. Решил так, я сейчас быстренько с файлами разберусь, а там уже как-то алгоритм построю. Времени на все — 1 час 15 мин. Я полчаса строил красивые врапперы вокруг чтения из файла, пучок сущностей, описывающих поезда, маршруты и прочий мусор. При этом мало представлял, как алгоритм выбора будет работать. Дальше я понял, что я не успеваю, не понимаю, как строить алгоритм, подступила паника. За 12 минут до конца собеседования я понял, как оно должно быть. За 15 минут (с опозданием в 3 минуты) я написал код (с парой ошибок, правда). Так быстро я не писал код никогда в своей жизни.

Онсайт-интервью

Если телефонное интервью прошло успешно, следующий шаг — онсайт. Компания покупает тебе билеты на самолет, оплачивает отель, и ты летишь к ним в гости. Я так летал в Лос-Анджелес на интервью в Snapchat.

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

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

Классическое техническое интервью с задачами.Тут все относительно понятно — то же самое, что и на телефонном. Нужно держать в голове следующий факт — уложиться нужно в ⅔ времени и ⅓ оставить на непредвиденные обстоятельства, поверьте они будут. В Google одно интервью 45 минут, это означает, что после знакомства у вас есть 25 минут на все. Из них 2-5минут на то, чтобы понять задачу и нарисовать примеры, 2-5 —чтобы придумать решение и 15-20 нанаписание кода и дебаггинг. Во время дебаггинга, конечно, всплывут ошибки, и их нужно быстро и красиво пофиксить. Именно на это и нужна та заветная ⅓.

Нюанс — всегда нужно идти на интервью со своим лэптопом. Первым делом нужно спросить, можно ли кодить на нем. В Facebook меня спросили: есть лептоп? хочешь на нем кодить? Ответ — конечно, да! Это быстрее, и вероятность ошибки в разы ниже. К тому же, переписывать код на вайтборде и в IDE — это две большие разницы. У меня неоднократно была ситуация, когда я исправлял ошибки на вайтборде, в результате чего код становился абсолютно нечитаемым (и, скорее всего, с новыми ошибками). Интервьюеры смотрели на это с грустью и слезами.

На лэптопе должны быть любимая IDE и проектик с типовыми шаблонами:

• работа с файлами;
• парсинг CSV-файлов;
• считывание по http;
• HTML- документ с подключенными стилями.

Еще помните мой печальный опыт с Evernote? Так вот, на следующем онсайте меня тоже попросили распарсить CSV, это заняло 3 минуты. Интервьюеры не против, если ты используешь такие шаблоны — это экономит время, и они понимают, что ты способен нагуглить, как распарсить файл.

Важный момент — нужно всегда контролировать время. На одном из интервью в Google мой интервьюер, парень лет 25-ти,задал мне хитрую задачку на динамическое программирование. Я нашел способ, как ее решить за квадратичное время, на что он спросил: «А лучше можно»? И я начал искать, как это сделать, подступала паника, но решение «лучше» найти я не мог. Наш диалог дальше:

Я: Не могу придумать решение лучше. Может, напишем мое решение и после этого подумаем?
Он: Давай еще 10 мин подумаем. Если не найдешь, напишем твое.
Я: Мне кажется, что времени может быть мало. Давай все же напишем мое сначала.
Он: Ну ок.

Я успел дописать свое решение с опозданием в 5 минут. Если бы послушал его, то не написал бы ничего и провалил интервью на 100%. А после такого в космонавты не берут. Штука в том, что он прикидывал, сколько времени нужно ему для написания задачки на доске, зная решение досконально.

Рассказ о предыдущем проекте.К этому вопросу нужно хорошо подготовиться заранее, продумать, что рассказывать. Можно даже подготовить небольшую презентацию в Google Slides и рассказывать по ней, параллельно рисуя диаграммы на вайтборде. Здесь нужно показать важность решения (для чего все это) и сложность решения.

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

Дизайн-интервью.Это отдельный зверь, не очень страшный, но специфический. Здесь тебе дают очень общие начальные условия типа «Нужно построить Dropbox» и смотрят, как ты продираешься через терновые кусты неопределенности. Какие вопросы ты задаешь, как анализируешь проблему.

Мои выводы по этому типу интервью:

• Первым делом нужно собрать требования. Очень четкие и конкретные требования, которым должна отвечать система. Типовые вопросы, которые можно задать: how many users, active users, time zones (one or few). Acceptance criteria — network bandwidth (in-going/ out-going traffic), RAM, storage, latency, battery life (for mobile) etc.
• Представь, что интервьюер — это твой заказчик (или пользователь), для которого строится система. Что ему нужно? А что можно предложить сверх этого (сбор статистики, админпанель)?
• Какие будут пользователи у этой системы? Часто их несколько — general users и administrators. И требования для них могут быть кардинально разные. Понимая это, нужно собрать все use cases. Один use case будет отвечать одному методу в API.
• Определяем три ключевых элемента — UI (если таковой имеется), API, DB schema. Часто, рисуя UI, можно найти новые use cases и обговорить их.
• Оценить все, что только можно, — number of users, requests (queries) per second (QPS), latency, API latency, disk space you need (for 5 years for instance), cache space, in-going/out-going traffic.
• Отдельно оценить read-write ratio. Наша система read heavy или write heavy? В зависимости от этого, как мы будем писать и читать данные?
• Как будет организовано хранилище данных, кеширование? Возможно, нужна очередь для обработки дорогостоящих операций? Как будут организованы replicas и shards (нужно хорошо понимать различие между этими понятиями)?
• Для упрощения понимания сначала можно построить систему для 100 пользователей. После того как интервьюер согласится с таким дизайном, можно подумать, как будем его масштабировать до тысяч и миллионов пользователей.
• Найти trade-offs и обсудить их. К примеру, это может быть trade-off между consistency и speed. Что важнее в данном контексте? Как этого добиться?
• Когда мы рисуем диаграммы, ни один блок не должен быть в единичном экземпляре, это всегда сет из многих. При падении одного узла его тут же должен заменить его клон. Нужно продумать, какие могут быть аварийные ситуации и как мы будем с ним бороться.
• И самое главное — внимательно слушать интервьюера и никогда-никогда с ним не спорить. Это кажется очевидным, но многие (и я среди них) об этом забывают.

Вопросы интервьюеру

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

Пример плохих вопросов: на каком языке программирования вы пишете? На каком клауде у вас стоит инфраструктура? Какая у вас СУБД? В чем тут проблема — компания нанимает универсального солдата, который за месяц-два должен разобраться в технических деталях. То есть это, по сути, не важно, это как-бы слишком узко.

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

За 10 дней до важного онсайта

У меня было два самых важных онсайта — Google и Facebook. Google был первым, и я достаточно сильно переживал. За 10 дней до онсайта я составил расписание на каждый день, что нужно сделать. Оно содержало следующее: повторение алгоритмов, типовых задач, задач, которые встречались на собеседованиях в Google, вопросы по дизайну. 5 дней до интервью я не ходил на работу и ушел в подготовку с головой.

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

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

Финал

Через несколько дней после онсайта мне позвонил рекрутер. Поздравил, сказал, что я молодец, все прошло хорошо. Мне нашли команду в Швейцарии в Цюрихе. Официальная позиция — Software Engineer. Я выдохнул. Голова была абсолютно пустой, я добежал. Забег в 1 год и 5 месяцев объявляется закрытым.

Привіт, мене звати Євгеній Коваль, я PHP-розробник в компанії Wikr Group. Сьогодні хочу поговорити про наставництво — або, як частіше кажуть в нашій індустрії, менторство.

Протягом всього професійного життя я мав змогу бути наставником для багатьох колег та друзів, які звертались до мене за допомогою. Це були і люди, які тільки ставали на стежку вивчення чогось нового, і спеціалісти, які хотіли покращувати свої знання, розвиватись. Наразі 6 моїх учнів стали професіоналами своєї справи, і я цим дуже пишаюся.

Розкажу детальніше про особливо яскравий випадок. Декілька років тому я працював техніком-програмістом у Coca-Cola та поїхав у відрядження до Нігерії. Нам доручили підвищити професіоналізм місцевих людей та вплинути на ефективність заводу, проте виконувати їхню роботу власноруч забороняли — можна було тільки навчати. Відношення місцевих менеджерів до робочих процесів було далеко не найкращим: вони багато обіцяли, але нічого не робили, а також підвищували голос на співробітників та замість рішень на все шукали виправдання. Працівники постійно жалілись, що не вистачає грошей та мотивації, і відмовлялись вчити щось нове. Виклик для мене як для ментора був у тому, щоб не просто навчити людей, а взагалі змінити їхній світогляд.

Належної ефективності заводу ми так і не досягли, але я зміг виростити чотирьох відмінних спеціалістів. Згодом вони продовжили свій розвиток в інших компаніях, де змогли реалізувати себе. Один з них навіть знайшов роботу в Німеччині. Окрім навчання технічних спеціалістів, мені вдалося переконати одного з менеджерів у тому, що його підхід до роботи не був ефективним, та допомогти йому застосувати правильну тактику управління.

Протягом трьох останніх років я змінив декілька компаній і бачив приклади менторства — як робити не можна. Ці приклади мотивували мене бути кращим і не допускати такого в своїй практиці. Я аналізував дії, поведінку та спілкування людей і вдосконалював свої методики та підходи до наставництва, про які і хочу розповісти у цій статті.

Що таке наставництво

Якщо ви вже давно працюєте за фахом і відчуваєте бажання ділитися своїми знаннями з іншими людьми, то, напевно, вже задавали собі такі питання:

• Чи можу я стати ментором?
• Чи достатньо я володію інформацією щоб бути ментором?
• Чи гарний з мене ментор?

Згідно з Вікіпедією, наставництво — це відносини, в яких більш досвідчена чи обізнана особа допомагає менш досвідченій та обізнаній засвоїти певні компетенції. Тож як визначити, що ти є саме таким обізнаним фахівцем? Дехто вважає, що якщо у нього посада вища, то це значить, що він готовий менторити колег, які займають нижчі позиції. Або ж якщо він просто дізнався щось нове, то може навчати цієї інформації інших.

На мою думку, це неправильнийшлях. А отже, я хочу запропонувати своє бачення, який досвід, знання та навички треба мати, щоб бути хорошим наставником.

Здобувайте практичний досвід

Для того щоб починати когось менторити, потрібно не просто володіти інформацією, а, як кажуть, з’їсти на цьому собаку. Тобто ваш досвід у цій сфері повинен перевищуватизнання, які дають у книжках. В іншому разі це буде марною витратою часу для ваших учнів, адже почитати першоджерело можна і самостійно.

Окрім цього, ментору потрібно постійно вдосконалюватисвої знання й навички, набивати нові шишки, щоб потім ними ділитись.

Отже, основа основ — це практичний досвід у сфері, яку ви намагаєтесь донести менш обізнаній людині. Йдемо далі.

Розберіться в психології

Будь-яке спілкування з людьми потребує розуміння їхнього світогляду, поведінки, переживань, тож гарний ментор зобов’язаний володіти основами психології. Тим більше, коли до вас звертається людина і ставить запитання, в яких вона ще не зовсім компетентна, то в будь-якому разі це для неї стрес — хоча б на підсвідомому рівні. Тому треба вміти бути делікатним.

У мене були учні, які боялися задавати питання. Вони думали, що їхнє питання занадто просте, щоб мене відволікати з такими дрібницями. Відповідно, вони втрачали на вирішення проблеми дуже багато часу.

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

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

Наприклад, щоб обрати правильний спосіб донесення інформації, визначте, ким є ваш співрозмовник за типом сприйняття — візуалом, аудіалом або ж кінестетиком. Не менш важливо, до якої з цих груп належите і ви самі. Розуміння таких особливостей допоможе побудувати правильну комунікацію. Проте пам’ятайте, що чисті типи зустрічаються вкрай рідко, і у більшості випадків можна говорити лише про схильності.

У моїй практиці був випадок, коли учень багато малював, бо не міг пояснити свою думку словами. На малюнки доводилось витрачати багато часу, проте людині так було простіше. Це явна ознака, що людина — чистий візуал. Мені довелось підлаштуватись під учня: взагалі я більше люблю проговорювати інформацію, але задля кращої взаємодії теж почав малювати. Здебільшого я комбінував малюнки зі словами, щоб на асоціативному рівні учень звикав не тільки до візуального представлення, а й вчився слухати. Врешті-решт, я досяг цієї цілі: ми стали більше спілкуватись і добре розуміли один одного навіть без візуалізацій сказаного.

Психологія — досить цікава наука, і наш мозок — це вже далеко не така загадка, якою її вважали раніше. Кожна частинка мозку відповідає за певну поведінку:

Налагоджуйте комунікацію

Не забувайте, що наставництво — це відносини. Людям, які близько знають один одного, простіше порозумітись. Через відсутність комунікації виникає багато конфліктів на рівному місці, тому звертайте на це увагу і не допускайте такого.

Станьте другом для свого учня.За неформальних відносин людина відчуває себе більш комфортно і сміливіше задає питання, адже знає, що її зрозуміють. А чим більше питань задасть учень, тим більше істин йому відкриється. Якщо казати про власний досвід, всі мої успішні відносини з учнями починалися з дружби — це був дуже важливий фактор їхнього швидкого росту.

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

Будь-які питання, що стосуються взаємовідносин, потрібно вирішувати відразу. Якщо затягувати, це впливатиме тільки негативно: маленьке невдоволення декілька разів підряд перетвориться на серйозне обурення.

Ставте складні цілі

Мотивація — це стимул досягати мети та ламати бар’єри. На мою думку, це найважливіший пункт в наставництві, тому зупинимось на ньому більш детально.

Наставник має надихати учня не просто щось робити, а виходити за рамки основ. Покажіть йому світ, про який не пишуть в книгах. Зазвичай, такі кейси дуже цікаві, і відповідно інтерес до сприйняття інформації зростає.

Ставте складні задачі. Якщо виконувати лише прості завдання, шлях до цілі стає передбачуваним і нецікавим, а це погано впливає на мотивацію людини. Звичайно, дехто може зі мною посперечатись і сказати, що ліпше спочатку дуже детально пройтись по всім основам і лише потім плавно-плавно підніматись до складніших речей. Але я вважаю, що ніщо не вчить краще, як щось складне.

Коли учень досягає якоїсь складної цілі, обов’язково його похваліть. Якщо зробите це в присутності інших людей — це подвоїть результат від ваших слів :)

Якщо ж ціль була нескладна, то... стоп. Ніколи не ставте простих цілей!Краще пояснити, як подолати бар’єр і відразу піднятись до висот, аніж бігти до них серпантином. До того ж, в процесі розв’язання складних задач буде безліч дрібних і простих. Якщо ж хвалити людину за вирішення простих задач, то згодом вона не буде мотивована вирішувати складні — а це в свою чергу вплине на швидкість навчання.

З іншої сторони, в процесі розв’язання складної задачі спеціаліст-початківець може зіткнутися з невдачею. Через це також інколи зникає мотивація продовжувати. В таких випадках можна дати учню готовий розв’язок наступного етапу і обговорити, чому саме цей розв’язок має такий вигляд. Наш мозок збуджується, коли бачить розв’язок проблеми, — це задає імпульс рухатись далі. Тож в таких моментах важливо не дати втратити мотивацію.

Якщо ваш учень не зміг розв’язати задачу, в жодному разі не кажіть йому, що він невдаха, навіть у вигляді жарту. Навпаки, згадайте дрібніші завдання, які він подолав, і похваліть його за їх виконання — просто заради збереження мотивації.

Нещодавно мій улюблений актор Уілл Сміт виклав дуже мотивуюче відео, в якому він пояснює, що невдача — це частинка успіху, а тому ніколи не потрібно розцінювати невдачу як щось погане:

Якщо трапилось так, що задача настільки нетривіальна, що і ви самі не знаєте розв’язок і не можете дати конкретну відповідь, то спробуйте прийти до цієї відповіді разом. Такий випадок — це не показник, що ви поганий ментор. Але з подібних ситуацій потрібно якось виходити. Я не зустрічав людини, яка б знала все. Не варто як просто відмахуватись від задачі та пропонувати учню розібратись самостійно, так і впевненим голосом відповідати, якщо ви не знаєте на 100%, що ваша думка правильна. Це демотивує учня звертатись до вас наступного разу. Краще бути чесним та на власному прикладі показувати, як слід мати справу з новими речами. Найкращий варіант у такому випадку — сісти разом і знайти рішення. Тим самим ви дасте учню зрозуміти, що якщо не здаватись — все вийде.

Мотивація повинна бути не тільки в учня, а й в наставника. Спитайте себе: чого я хочу достягти цим менторством? Особисто для мене учень — це моє лице, і я хочу, щоб його цінували і сприймали як гарного спеціаліста. Я прагну не просто ділитись знаннями, а бачити, як ці знання покращують чиєсь життя. І чим краще це буде працювати, тим більше я досягну своєї цілі — стати людиною, яка залишила свій слід в історії людства, яка дала життя чомусь новому. Ми ніколи не знаємо, ким стануть наші учні. Проте ми можемо докласти максимум зусиль, щоб вони стали найкращими в своєму ділі.

Тож ставте свої власні цілі та досягайте їх. Якщо ви просто когось навчатимете без розуміння, чого ви хочете цим досягти, ви не будете задіяні в наставництві на всі 100%. Відповідно, це негативно вплине на передачу знань.

Якщо ви хочете бути гарним наставником, мотивуйте себе ним бути. Робіть все, щоб ви були прикладом для свого учня.

Корегуйте напрямок

Кожному учню через нестачу знань на певному етапі властиво придумувати свій «велосипед». Не давайте йому збитися з курсу. Контролюйте дії людини та вчасно спрямовуйте в правильному напрямку. Для того щоб услідкувати за учнем, якщо у вас ще не достатньо налагоджена комунікація, потрібно призначати чекпоінти — коли ви будете детально проговорювати досягнення, розглядати проблеми. Періодичність чекпоінтів індивідуальна (зазвичай раз в тиждень цілком достатньо). Також залежно від результату ви повинні визначати вектор, в якому рухається учень і корегувати його шляхом пояснення альтернативних рішень тощо.

Проте ні в якому разі не кажіть учню: «Тобі це не потрібно», «Навіщо тобі це, якщо є ось це» тощо. Такі фрази обрізають політ фантазії, ставлячи в рамки креативність. Просто поясніть молодшому колезі, чому ви вважаєте, що він збився з курсу, обговоріть з ним його розуміння завдання та інструментів.

Може бути й таке, що учень знайшов такий розв’язок проблеми, який не збігається з вашими уявленнями, проте також є оптимальним в контексті задачі. Звичайно, інший спосіб розв’язання — це не помилка, адже скільки людей, стільки й ідей. Головне, чи вірно людина розуміє мету своєї роботи — це і задає напрямок руху.

Післямова

Все, що сказано вище, це особисто моє бачення процесів навчання, і, звичайно, що у кожного свої погляди на ті чи інші речі. Якщо у вас є досвід наставництва, розкажіть про нього в коментарях — буду дуже радий почитати ваші думки на цю тему.

Наостанок додам декілька посилань з матеріалами, цікавими для ознайомлення:

• Basics of Communication — дуже цікава стаття про те, як ми говоримо і сприймаємо інформацію;
• What Are the Most Effective Communication Skills to Have?— навички, на які потрібно звернути увагу для побудови ефективної комунікації;
• 3 Psychological Theories To Help You Communicate Better With Anyone — цікаві погляди на комунікацію з точки зору психології та досліджень в цьому напрямку;
• The Most Powerful Motivator You’ll Ever Find — коротко про головне;
• How to Stop Making Excuses — стаття про те, як перестати виправдовуватись і почати діяти.

[Про автора: Зеновій Верес — керівник освітнього напрямку Lviv IT Cluster, Solution Architect в компанії SoftServe, асистент кафедри комп’ютеризованих систем автоматики у Львівській політехніці]

За останні 10 років я провів понад 300 технічних інтерв’ю Java-фахівців — як Intermid, Senior рівнів, так і TechLead/Architect. Існує багато коментарів як кандидатів, які пишуть про неадекватні запитання, так і інтерв’юерів, які нарікають на недостатній рівень кваліфікації спеціалістів.

Хочу поділитися своїм підходом до проведення технічних співбесід, спостереженнями та загальними рекомендаціями, які, на мою думку, можуть допомогти кандидатам справлятися із завданнями успішніше. Звісно, існує багато різних методик та варіантів організації процесу, тому одразу наголошу — все, викладене нижче, є моїм особистим досвідом.

Цілі інтерв’ю та підхід

Перш за все, хочу почати з цілі технічного інтерв’ю. Я завжди ставлю собі завдання виявити сильні сторони фахівця. Згодом на основі цієї інформації рекрутер може пропонувати кандидата на конкретні проекти, які будуть цікаві йому, і де він зможе принести максимальну користь команді та компанії. Я не маю завдання завалити фахівця чи показати, що він чогось не знає. Для мене найважливіше — з’ясувати, що він знає.

Очевидно, що зробити об’єктивну оцінку рівня знань надзвичайно складно за короткий проміжок часу — як правило, технічне інтерв’ю триває близько години, іноді — півтори. Саме тому я готуюсь до інтерв’ю заздалегідь, спершу перечитую резюме та профіль кандидата (Candidate Profile), який він сам заповнює, оцінюючи свій рівень знань (knowledge area) та володіння технологіями. Перший блок співбесіди традиційно ознайомчий — я зазвичай задаю декілька вступних запитань, щоб познайомитися та розрядити атмосферу.

Досвід роботи

На цьому етапі я отримую розуміння про роботу кандидата в команді: як він оцінює свою роль на проекті, як була розподілена команда, яка була взаємодія між учасниками, як відбувалось узгодження вимог до проекту, яким чином команда оцінювала тривалість задач та наскільки мала можливість впливу на процес розробки. Якщо кандидат претендує на лідерську позицію, важливо з’ясувати, як він організовував процес командної роботи над кодом, хто здійснював перегляд коду, оцінював тривалість задач, як проект поділявся на спринти та релізи, як приймалися архітектурні або технічні рішення, які недоліки прийнятих рішень та на основі чого обиралися фреймворки. Також слід очікувати на запитання — що, на вашу думку, варто змінити в проекті, які з прийнятих вами рішень виявились помилковими та чому?

Запитання

Після цієї секції починається власне технічна частина. Я не використовую заготовлених тестових завдань чи запитань — підбираю їх ситуативно, виходячи з результатів першої частини інтерв’ю. Траплялися різні випадки — наприклад, іноді кандидат не вказував у резюме весь свій досвід або оцінював рівень володіння технологіями нижче, ніж є насправді. Бували також випадки, коли людина копіює інформацію з інших резюме, навіть не перевіряючи, чи відповідає це його досвіду, головне, щоб було ближче до вимог вакансії. Саме на цьому етапі я отримую первинне розуміння рівня кандидата, від цього і залежить складність наступних задач.

Зважаючи на те, що я прихильник практичних завдань, то дуже часто описую певну задачу і прошу кандидата розказати, як би він її вирішив. Приклад такої задачі для архітектора/технічного лідера: для описаного вами проекту, яким чином ви б забезпечили підтримку додаткових 5000 користувачів одночасно; яким чином ви б організували заливання 1000 записів у базу даних з використанням Spring/JPA і т. п.

Відштовхуючись від отриманої інформації, я переходжу до запитань по об’єктно-орієнтованому дизайну. Я очікую, що людина із рівнем Intermid і вище знає, для чого слід використовувати шаблони проектування (GoF/GRASP/SOLID/Layered Arcitecture). Від кандидатів Senior-рівня я очікую розуміння, коли і котрий з шаблонів слід застосовувати, а також як виконувати рефакторинг коду із використанням шаблонів (рекомендую книгу Д. Кірієвскі «Рефакторинг з використанням шаблонів»). А також ситуації, коли використання шаблону може мати негативний вплив або бути невиправданим. Також до базового набору я відношу запитання по SQL/DB Design, програмного доступу до бази даних (DB Access), що включає в себе знання JPA/Hibernate. Звісно, від кандидата також очікується і знання мови програмування Java та змін, які були внесені у Java SE 8/9 s Java EE 8 (Jakarta EE). Зауважу, що на даний момент менше уваги приділяється багатопоточності, адже наявність багатьох фреймворків ізолює розробника від потреби створювати та керувати новими потоками.

У випадку наявності досвіду по Spring обов’язково задаю низку питань — перш за все, з якими компонентами цього фреймворка працював кандидат. А також запитання по REST/SOAP сервісах.

А тепер найцікавіше — які саме запитання слід очікувати на інтерв’ю? Я зазвичай починаю зі складніших запитань, але якщо кандидату вони виявляються заскладні, то поступово переходжу до простіших. Для економії часу читачів не буду наводити список стандартних запитань (чому слід перевизначати equals та hashCode, яким чином інтерфейси дозволяють реалізовувати інкапсуляцію та ін.) — по кожній із зазначених вище сфер є достатньо запитань в інтернеті. Зупинюся більше на запитаннях, пов’язаних з архітектурою, та запитаннях «з родзинкою».

Про архітектуру:

1. Опишіть архітектуру проекту — яким чином ви її документували, як вносили зміни, що було причиною внесення змін? Назвіть основні якісні характеристики (quality attributes) системи — яким чином ви їх досягли, чому для системи важливі саме ці атрибути, які у вас є обмеження, які припущення ви зробили при проектуванні системи? Рекомендую почитати книгу Len Bass «Software Architecture in Practice», 3rd Edition.
2. Які фактори вплинули на вибір фреймворків для проекту, які були альтернативи, що було основним фактором відхилити альтернативи? Яким проблеми виникали при виконанні запитів до бази даних, як ви їх вирішували? Як реалізовували REST-сервіси, яку бібліотеку обрали, як реалізовували HATEOAS-принцип?
3. Яку версію Java використовували на проекті? Що для вас є найважливішим у версії Java SE 8/9? Що входить в Java EE, яким чином відбувається реліз Java EE (Jakarta EE)? Що саме з Java EE ви використовували? Чи стикалися ви з out of memory error? Якщо так, то як саме вирішували та відслідковували використання ресурсів? Чи стикалися з memory leak? Якщо так — як шукали причину, як організовували роботу з пам’яттю?

Звісно, це лише декілька запитань з великої кількості можливих, але зазвичай саме вони допомагають зрозуміти рівень знань та досвіду роботи кандидата на проекті. Інколи буває, що людина губиться у відповідях, що, не виключено, є результатом стресу, тому я переключаюся на теоретичні запитання, щоб кандидату було комфортніше і він заспокоївся. А також я не задаю всі ці запитання одночасно :)

Каверзні запитання

Іноді я відходжу від стандартної канви і ставлю запитання зовсім іншого характеру. Роблю це не для того, щоб підловити, а щоб зрозуміти хід думок кандидата. Трапляються випадки, коли людина завчила запитання суто по Java і навіть не хоче подумати, хоча відповідь може бути дуже простенькою. Наприклад, запитання по типах колекцій є достатньо стандартними. А ось запитання на кшталт «при яких операціях відбувається економія часу, коли ми працюємо з HashMap та за рахунок чого відбувається така економія; які операції при цьому відбуваються повільніше, у порівнянні з ArrayList» показує, наскільки кандидат розуміє принципи роботи даної колекції. Крім того, така методика зазвичай використовується саме для того, щоб подивитися, як людина відреагує на такі запитання. Інколи «правильна відповідь» не найважливіше, що ми хочемо почути. Такі завдання дозволяють нам побачити ваші soft skills, глибину мислення та підхід до вирішення непростих завдань.

Поради

• Найголовніша порада — будьте чесними, починаючи з резюме. В ньому варто чесно відобразити технології та фреймворки, з якими працювали саме ви, а не які в цілому використовувалися на проекті. Пам’ятайте, що на початку інтерв’ю кожен кандидат має 100% довіри — з кожною невідповідністю цей кредит падає і з кожним разом все швидше.
• Відображайте в резюме всі проекти, над якими працювали, навіть якщо їх багато. Це дозволить побачити всю картинку розвитку вас як фахівця. Також це дає уявлення, чи неперервний досвід ви мали, чи були перерви, з якими технологіями стикалася.
• Чесно розкажіть про ваше особисте ставлення до проекту — подобався\не подобався, чому зупинилися саме на таких технологіях, чи були виклики і як з ними справлялися, яка була взаємодія команди в таких випадках, як приймали рішення. Це дозволить зрозуміти, наскільки ви були залучені до проекту та жили ним, а також який ви командний гравець.
• Ставте запитання. Переконайтеся, що перед тим, як почнете відповідати чи розв’язувати задачу, ви правильно її розумієте. Не варто часто просити повторити запитання. Якщо хочете дізнатися більше про проект, команду чи компанію — запитуйте. Відсутність запитань може означати, що ви не зацікавлені в компанії чи позиції, на яку проходите співбесіду.
• Зробіть домашнє завдання. Під час інтерв’ю з рекрутером вам надають первинну інформацію про проект — не соромтеся розпитувати та просити трохи більше деталей. Це дозволить вам зрозуміти специфіку проекту та краще підготуватися до технічної співбесіди — освіжити теоретичні знання, заглянути в код, зрозуміти, яка інформація з вашого резюме може бути найактуальнішою.
• Заспокойтеся та не нервуйте. Співбесіди — це стресова ситуація для будь-кого. Можливо, ви подалися на позицію, на яку дещо не вистачає кваліфікації, чи навпаки — здається, що в описі вакансії йдеться саме про вас. В будь-якому випадку ви хвилюєтесь. Важко розкрити всі свої переваги, коли нервуєшся. Тому заспокойтеся, підготуйтеся та розкрийте свої сильні сторони.
• Погугліть перед інтерв’ю. На інтерв’ю задають достатньо стандартні запитання, до яких можна і потрібно підготуватися.
• Запишіть запитання, на які ви не знали відповіді під час співбесіди або незадоволені своєю відповіддю. Потім пошукайте відповіді для себе — це дозволить вам розвиватися.
• Завжди просіть надати інтерв’юера відгук про інтерв’ю — які у вас виявлені сильні сторони, а над чим слід попрацювати.

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

Почитать

12 крупнейшихпрограммных сбоев 2017 года

Шесть вещей, которые не стоит делать, говоря о тестировании

Как не стоит делать важные интерфейсы:гавайская версия

Ничего не забыть: универсальная схема для тестирования веб-приложений

TOП-10. Разбор лучших докладовв свободном доступе. Heisenbug 2017 Moscow

8 способовускорить тестирование

10 причин, почему вы не профессиональный тестировщик. Часть 1. Часть 2.

Объяснение HTTPSна почтовых голубях

Тест-кейсы — это не тестирование: движение к культуре производительности тестирования

Обзор классных лайфхаковдля Windows инструментов

«Конец» ручноготестирования

А вы не слишком много времениуделяете тестированию ПО?

QA Guild — подкасты на тему тестирования и около него

Подробное рассмотрениекаждого уровня пирамиды тестирования

Уроки разработкиполетного софта

Scrum vs Kanban: в чем разница и что выбрать?

Коллективный твиттертестировщиков ПО

Тестирование в продакшене — миф или реальность?

Нагрузочное тестирование «не-HTTP». Ч.2 Gatling

Управление трафикомс использованием Fiddler

Автоматизация

Инструментыдля тестирования JavaScript-проектов

Обзор Javascript тест-фреймворкаот Facebook — Jest

Путеводительпо инструментам автотестирования мобильных приложений

Kukumber — это Cucumber только на Kotlin

Селекторы CSSи их применение в автоматизации тестирования ПО

Инструментыдля тестирования с помощью BDD на C#

Автоматизированное тестированиеи искусственный интеллект

Akita — BDD библиотека шагов для тестирования на основе cucumber и selenide

Разворачиваем автоматизациюза пару часов: PHPUnit, Selenium, Composer

Перевод книги «Node Hero»от RisingStack

Юмор

Самое безопасное приложение на сегодняшний день. Но тоже не идеальное, почитайте Issues и Pull requests.

U — User experience. То чувство, когда ты можешь потратить кучу времени на дизайн, разработку и тестирование системы, но всегда найдется пользователь, который при определенных условиях сможет удивить.

Автотесты старого отлаженного проекта после добавления нового функционала:

И снова рубрика «2 юнит-теста, 0 интеграционных»:

Идеальная интеграция:

Спасибо Егору Муратову за интересные материалы!

Все желающие делиться интересным — пишите на почту salnikov.maksim@gmail.com, обсудим, опубликуем, скажем, спасибо :)

← Предыдущий выпуск: QA дайджест #32

В выпуске: быстрый компилятор подмножества Scala, анонс Scala.js 1.0.0-M3, Scala в Starbucks и Zalando, Akka stream Pitfalls.

В мире компиляторов

Второй пререлиз Dotty.

Твиттер начал делать свой быстрый компилятор подмножества Scala, основанный на идее параллелизации типизации. Кстати, Евгений Бурмако расскажет об этом подробнее на ScalaUA.

Вышла первая версия Hydra — коммерческая версия параллелизированного Scala-компилятора.

Заметки Георгия Косаковского, автора первой параллелизации компилятора подмножества Scala, — Kentucky Mule.

Наконец доступен пререлиз Scala-2.13-M3 с включенной поддержкой литеральных типов. А в M4 обещают новые коллекции.

Новое в языке

O’dersky предложил новый подход к метапрограммированию, объединяющий подход макросов и LMS.

Заметки с митинга Scala Center: сентябрь, декабрь.

Инструменты

Bloop — дополнение к sbt или maven, которое держит компилятор загруженным, для быстрой компиляции.

Mill — альтернатива sbt от Ли Хаоу.

Еще одна альтернатива CBT, про которую мы уже упоминали раньше.

Ну а сам sbt не стоит на месте.

Scala.js

1.0 уже близко.

Импорт typescript типизаций.

Новости из мира Кафки

Главное событие: KSQL.

Cats с reactive-kafka.

Дискуссия о ‘exactly-oncle delivery in Kafka’.

Message queue on top of Kafka.

Фреймворк для локального тестирования kafka топологий.

Lightbendзаопенсорсил свою обертку.

Как Slack использует kafkaдля разгрузки БД.

Akka

Akka stream Pitfalls.

Akka Cluster in Kubernets: traps and pitfalls.

Data Pipeline на основе Akka Streams: шаг за шагом.

Максимизацияпропускной способности Akka Streams.

Scyllaдопилили до возможности запуска с ней Akka persistence.

Индустрия

Scala in Starbucks.

Scala in Zalando.

MakeMyTrip: Personalization User Data Store.

X.ai: Using Scala to Build an AI-Powered Personal Assistant.

Scala in Dwolla.

Разное

Видео с coursera-курса Reactive Programmingдоступно бесплатно.

Ли Хаоу о процессе автоматического тестирования.

Whats made ScalaFiddle so fast.

FP в Scala — стало ли лучше?

Язык математикии язык бизнеса.

2 цента в защиту OOPот автора Monix.

Optic DSL on top of Monocle.

Технічна стаття українською — про Scala UI на Android.

Service discovery with CRDT-s.

Компиляция Scala в CCC.

События

20-21апреля ScalaUA — основная конференция в Украине. Уже известно расписание. В этом году оно довольно плотное, получилось отражение всего спектра современной разработки: от инженерии монад до техник машинного обучения. Жалко, что нельзя присутствовать на двух потоках одновременно ;)

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

← Предыдущий выпуск: Scala дайджест #7.

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

Мы расспросили Senior- и Lead-специалистов украинских IT-компаний о том, какие софт скиллы наиболее важны для успешного профессионального роста и как их развивать.

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

Коммуникабельность

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

Эллина Азадова, Senior QA Engineer в DataArt:

«В моей практике было много случаев, когда люди с более развитыми софт скиллами быстрее продвигались по карьерной лестнице. Важно уметь себя преподнести. В человеке может быть огромный потенциал, прекрасные способности к определенному типу работы, но их невозможно рассмотреть, если он будет старательно прятаться. В результате появляются обиды, люди меняют работу или даже общее направление деятельности. Специалист при этом думает: „Мне не дают реализоваться!“

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

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

Ян Гулай, Senior JavaScript Developer в Brightgrove:

«Будьте хорошим собеседником. Согласитесь, не всем хочется работать со скучным роботом. Для этого повышайте свой общий уровень эрудиции, тренируйте разговорный английский. К примеру, с заказчиками можно разговаривать не только о работе и проектах: я болтаю с ними о путешествиях, истории стран, компьютерных играх, автомобилях. Было интересно узнать побольше о жизни „по ту сторону океана“, выборах в США.

Развивать этот навык легко: общайтесь, социализируйтесь, посещайте разговорные клубы. Только нужно быть осторожным: не поднимайте острые темы. Некоторые люди могут быть весьма консервативными, вы даже не представляете насколько».

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

Ольга Когут, BI Developer & Team Lead у Conscensia:

«Вміння слухати і приймати думку інших, чітко формулювати вимоги і очікування до команди — ці навички допомагають побудувати позитивну атмосферу у команді, поділитись своїм досвідом і почути цікаві ідеї від інших. Я починала свою роботу на позиції SAS developer. На той час ця технологія не була популярна в Україні і знайти спеціалістів було важко. Тому усіх нових працівників потрібно було вчити і готувати до здачі сертифікацій. Я багато разів була ментором. На мою думку, саме це помогло мені розвинути навички у спілкуванні: вміння знайти підхід до людини, зрозуміти хід думок, мотивацію».

Зачем тратить усилия на укрепление отношений, если в это время можно почитать о новом фреймворке? Во-первых, хорошие отношения с коллегами формируют уровень доверия к вам как к техническому профессионалу. Во-вторых, помогают делать свою работу лучше.

Арсений Оганов, Lead Solutions Architect в Netcracker:

«Качественное и конструктивное общение зарабатывает вам „плюс в карму“ как человеку и специалисту. А это позволяет в критической ситуации на проекте, когда надо быстро что-то сделать, просто прийти к разработчикам и сказать: „Сделай вот это“ — и не объяснять почему, так как они уже вам доверяют.

Лучшее, что я могу посоветовать — хорошие книги о воспитании детей. Да-да, именно о воспитании детей: там представлены лучшие практики по коммуникациям. Почитайте, к примеру, Гиппенрейтер».

Семен Котляренко, Head of Web Department KeepSolid:

«Без умения коммуницировать ты не сможешь добиваться многих личных и рабочих целей. Вспомнил один недавний кейс: мы разрабатываем новую архитектуру API для одного из продуктов. Есть очереди сообщений, и я предположил, что и другим продуктам будет важно получать эти сообщения, поэтому нужен удобный и безопасный язык общения. Когда я поговорил с разработчиками из других отделов, оказалось, что для них эта проблема не менее актуальна. Мы ее решили с помощью совершенно другого набора инструментов, чем я планировал изначально. Если бы я не коммуницировал с другими отделами, наша система получилась бы не product-friendly для пользователей».

Умение донести свои мысли

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

Павло Годиш, Competency Manager в ELEKS:

«Правильно побудована комунікація дозволяє поглянути на ситуації та речі під іншим кутом, дізнатись, як люди сприймають ту саму інформацію і особливо — дізнатись чого, на їхню думку, від них очікують. Досить поширена помилка — очікувати, що люди з якими ми спілкуємось по роботі, розуміють все самі або ж розуміють це так само, як і ви. Коли потрібно завершити завдання чи проект, важливо, аби всі в команді розуміли, що саме потрібно зробити і як. Не шкодуйте часу на прояснення деталей: це дозволить виконати роботу якісніше і швидше».

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

Елена Белкина, QA Engineer & Internal SoftSkill Trainer в CoreValue:

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

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

После этого новичок или не обращается за помощью, чтобы не дискредитировать себя, боясь показать свою некомпетентность. Либо обращается, но от него отмахиваются фразами типа „Ну, а что тут может быть неясно?!“. Только после неудачной реализации поставленной задачи человек узнаёт о том, какими были санкции. Ничего из этого кейса, кроме ощущения тотальной несправедливости, такой „подопечный“ не вынесет».

Помимо непосредственно информации, важно подобрать правильный тон общения, интонацию, уровень формальности.

Анна Каплун, Senior Test Engineer в Intellias:

«Приходилось ли вам передавать знания новым членам команды? Делать презентацию продукта заказчику? Уточнять какие-то детали в требованиях? Участвовать в тимбилдингах с людьми из разных команд, говорящими на разных языках? Объяснить свою мысль бывает сложно вне зависимости от собеседника и языка, не говоря уже о трудностях-волнениях, сопряжённых с публичными выступлениями. А выбрать правильный тон (то, что называют „register“ в английском) и того труднее: кто-то не приемлет панибратства, а кого-то коробит обилие формальностей. Это тонкая грань, которую очень важно нащупать, особенно в устной речи».

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

Арсений Оганов, Lead Solutions Architect в Netcracker:

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

Ораторское искусство

Для Senior-специалиста важны навыки публичного выступления. К примеру, для внутренних митингов или презентаций продукта заказчикам.

Артур Мироненко, iOS Tech Lead в UPTech:

«Ораторское искусство пригодится не только для участия в конференциях в качестве спикера, а и для презентации клиенту результатов работы. Банальный пример — процесс демок, когда нужно, грубо говоря, отчитываться продакт оунеру о проделанной за неделю работе. Отличный способ прокачать навыки публичного выступления — участвовать во встречах Toastmasters. Ищите возможности выступать перед публикой и просто тренироваться. Проводите в вашей команде внутренние Tech Talks на актуальные темы. Это отличный шанс научиться выступать: непринужденная атмосфера и знакомая публика — соответственно, меньше переживаний».

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

Людмила Федчук, Lead QA Engineer в Wargaming:

«Для того, чтобы красиво говорить, мало прочитать книгу. Важно прочувствовать свои слабые стороны, осознать проблему, поработать над ошибками, избавиться от слов-паразитов (ну, как бы, эээ и тому подобные). У нас был тренинг, на котором надо было выйти перед коллегами и сделать небольшую презентацию на заданную тему. Задача коллег состояла в том, чтоб указать тебе на твои наиболее часто употребляемые слова-паразиты, а твоя задача — заменить их каким-то смешным словом типа „мяу“, „кукареку“. Было мега-сложно и очень смешно, но помогло осознать свои недостатки и поработать над их исправлением».

Конструктивные переговоры

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

Константин Захаров, Solution Architect в EPAM:

«Когда выходишь за пределы middle-level engineer, требования к навыкам коммуникации становятся выше. Теперь вам уже приходится встречаться с более влиятельными участниками процесса, например, с C-levelменеджментом (CEO, CTO, CIO, CSO, CFO etc). Во время таких переговоров ставки достаточно высоки, и шанса на ошибку нет. Заранее готовьтесь к таким важным встречам, постоянно совершенствуйте Business English и соблюдайте политкорректность. Не забывайте о невербальной коммуникации — то, как мы выглядим, жестикулируем и какие позы занимаем во время общения».

Владимир Гарбар, Team Lead в HYS Enterprise:

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

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

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

Иван Ушаков, Practice Lead QA в Digicode:

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

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

Діана Пекеліс, Senior QA Engineer в DataArt:

«Мені доводилось працювати із замовником, у якого було декілька офшорних команд, тож я можу із впевненістю сказати, що у комунікаціях із людьми з різних культур важливим є не тільки зміст сказаного чи написаного, але і форма. Наприклад „так“ та „звісно“, які ми часто чули від одних із вендорів нашого замовника, далеко не завжди означали саме це. Щоб порозумітись, ми документували всі рішення, які були прийняті під час розмов і обговорень, і надсилали їх на пошту після завершення зустрічі.

Крім того, треба бути вкрай уважним, спілкуючись із колегами та замовниками, які говорять іншою мовою. Варто перевірити зміст ідіом і слів, які ми, можливо, звикли чути й використовувати, але, виявляється, вони підходять лише для більш неформальних обставин та можуть бути сприйняті як фамільярність».

Командная игра

Senior- или Lead-специалисту важно уметь фокусироваться не только на персональном результате, а на эффективности команды. Это может проявляться в правильном распределении задач между командой, своевременной помощи коллегам.

Сергей Козырев, Mobile Team Lead в Lohika:

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

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

Александр Крачун, Full Stack Developer & Team Lead в Adtelligent:

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

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

Стоит сказать, что получение фидбэка — это также и дополнительная мотивация. Рекомендую прочесть „Мифический человеко-месяц, или как создаются программные системы“Фредерика Брукса и „Человеческий фактор: успешные проекты и команды“Тома Демарко и Тимоти Листера».

Менторство

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

Артур Мироненко, iOS Tech Lead в UPTech:

«Важно уметь менторить и учить: каждому Senior-разработчику придется это делать. К примеру, в UPTech я был первым iOS-разработчиком и менторил всех, кто приходил потом — сейчас в нашей команде уже 8 человек. Чтобы менторить других, нужно и самому не стоять на месте, постоянно получать новые знания. Мне очень помог курс Learning how to learn. В нем дельные советы не по тому, как учить, а как учиться и хорошо воспринимать информацию.

Как мне кажется, Senior должен не брать всю власть в коллективе в свои руки, а помогать команде, вдохновлять и учить ее. Самый простой способ научиться этому — отвечать на вопросы на форумах типа Quora, Reddit, Stack Overflow. Это тренирует умение объяснять, а в процессе вы еще лучше понимаете собственный ответ».

Артем Петров, Web department Team Lead в Appus Studio:

«Программисты в основном избегают менторской деятельности, отдавая предпочтение инженерии. Соответственно, разработчиков, которые в себе совмещают одновременно качества инженера и ментора, очень мало. На них есть спрос — особенно в маленьких фирмах, где особо остро стоит проблема нехватки таких людей. Если вы хотите развить навык менторства, устройтесь преподавать на какие-нибудь курсы, сейчас их много. Попробуйте донести свои мысли до людей, которые ничего не понимают в IT».

Эмпатия и эмоциональный интеллект

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

Елена Белкина, QA Engineer & Internal SoftSkill Trainer в CoreValue:

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

Эмпатия — это принятие разнообразия нашего мира. Лучше развивать этот навык с детства, у взрослых людей процесс идёт куда медленнее. Самое элементарное упражнение на развитие эмпатии: просто общайтесь с самыми разными людьми на повседневные темы и не выносите оценочные суждения о собеседнике. Чтобы понимать, что испытывает другой человек, как он видит мир, достаточно принять саму вероятность множественных взглядов на одни и те же вещи — необязательно эти взгляды разделять».

Развитая эмпатия — это один из навыков конфликт-менеджмента и умения решать спорные ситуации, которые возникают в команде.

Константин Захаров, Solution Architect в EPAM:

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

Что ещё почитать о коммуникациях

• Public Speaking — курс о том, как складно формулировать мысли вслух.
• «Superconnector: Stop Networking and Start Building Business Relationships that Matter»Скотта Гербера и Райана По — как забыть о нетворкинге и начать создавать стоящие бизнес-отношения.
• «Hit Refresh»Сатья Наделлы — о принципах лидерства и важности эмпатии.
• «The Art of Asking»Аманды Палмер — как действительно нужно общаться с людьми и почему задавать вопросы — это не тягость, а дар.
• «You Said What? The Biggest Communication Mistakes Professionals Make»Кима Золлера и Кэрри Престон — почему нужно заранее обдумывать все, что вы скажете, а также как исправить 16 наиболее распространенных коммуникативных ошибок.
• «Как говорить с кем угодно и о чем угодно. Навыки успешного общения и технологии эффективных коммуникаций»Лейл Лаундес — как установить контакт с собеседником, научиться завязывать разговор и поддерживать беседу на любую тему.
• «Никогда не ешьте в одиночку и другие правила нетворкинга»Кейт Феррацци — как завести хорошие знакомства и освоить мастерство нетворкинга.
• «Я слышу вас насквозь. Эффективная техника переговоров»Марка Гоулстона — как развить в себе навык слушания и как применять его не только и не столько на работе, но и в жизни вообще.
• «Сначала скажите „нет“. Секреты профессиональных переговорщиков»Джима Кэмпа — как перестать зависеть от результата переговоров, который вы не можете контролировать, и сконцентрироваться на том, чем вы можете управлять, — на собственном поведении.
• «45 татуювань менеджера. Правила керівника»Максима Батырева — как продуктивно работать с коллегами и подчиненными.

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

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

Сам же я студент ХНУРЭ, зовут меня Дима. Учусь на программиста, вследствие чего тема сна для меня интересна не только в качестве увлечения, но и как инструмент повышения собственной эффективности. Именно поэтому я хотел бы поделиться своими знаниями со всеми, кому также интересна эта тема и буду искренне рад, если информация в статье поможет вам спать и жить лучше!

Мы постараемся опровергнуть несколько мифов, поможем разобраться в себе жаворонкам, голубям и совам, а также ответим на вопрос: стоит ли работать ночью?

Почему сон — это важно

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

1. Из-за некачественного сна увеличивается вероятность возникновения инсульта и проблем с сердцем.
2. Сон влияет на вашу продуктивность и концентрацию. Исходя из собственных наблюдений, я бы сказал критически.
3. Если вы неправильно спите, повышаются шансы ожирения. Здоровый отдых напротив позволяет сбросить лишний вес.
4. Плохой сон провоцирует возникновение депрессии.
5. Полноценный отдых улучшает память, а также иммунную систему.

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

Можно ли делить людей на жаворонков и сов?

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

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

Циркадные ритмы не определяются с самого рождения. Мы не рождаемся с генами сов или жаворонков, но мы способны приобретать определенные паттерны поведения. Другими словами, мы обретаем привычки, которые влияют на наш сон.

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

Как сделать из человека сову. Краткое руководство

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

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

Следом за этим он, проснувшись где-то вечером, выпивает кружечку кофе и начинает работать. В 10 ночи самое время сделать перерыв и пойти поесть чего-то вкусненького. Желательно послаще. Сонливость «на удивление» не появляется и он продолжает до 2 часов ночи, пока всё же сон не одолеет его. На следующий день всё по новому кругу.

Что происходит в этот момент:

1. Монитор компьютера, экран телефона и телевизор излучают синий свет, вследствие чего мозг предполагает, что сейчас день. Из-за этого он продолжает активно работать, пока изнеможение таки не вынудит человека пойти спать.
2. Итак, у нас есть недосып. Мозг в любом случае рано или поздно заберет эти часы (отсыпаемся на выходных?). Если человек поспит днём, он окончательно сбивает циркадные ритмы и вводит организм в полное недоумение, когда же ему нужно отдыхать.
3. Кружечка кофе в данном случае — не отсылка к джавистам (как бы сильно этого не хотелось), а фактор, который лишь ухудшит ситуацию. В нашем мозгу выделяется химическое вещество под названием аденозин, которое дает мозгу понять, что он устал. Так вот кофе блокирует поставление этого вещества. И всё бы отлично, но оно накапливается и часов через 8, когда кофе перестает действовать, аденозин приводит к резкому упадку сил.
4. Перекусы перед сном нежелательны по двум причинам: качество сна становится хуже и пропадает аппетит утром, поскольку часть еды переваривается уже после пробуждения. Сладкое повышает уровень глюкозы в крови, и вы чувствуете временный прилив энергии. Потом же возвращаетесь к упадку сил и неспособности полноценно работать. При частом употреблении сахара будьте также готовы встретить ожирение и перевозбуждение дофаминовой системы, что грозит возникновением дополнительных проблем.
5. Если действия человека повторяются, в мозгу в полосатом телеформируется привычка. Такой режим превращается в, условно говоря, зону комфорта человека, и он приучает свой мозг работать ночью.

Это, пожалуй, самый простой способ превратить человека в сову. Именно поэтому я считаю, что деление людей на сов и жаворонков — это глупо и недопустимо, поскольку «тип» формируется самим человеком и его действиями.

Другая точка зрения

Будет уместно узнать, что по этому поводу думают другие люди, ведь так?

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

В то же время некоторые известные доктора из СНГутверждают, что «режим предопределяется генами» и его изменить прямо-таки невозможно. Я, как человек, который раньше был совой, с уверенностью отрицаю это, подкрепляя свою точку зрения всей «сектой» (в положительном смысле этого слова) поклонников «The Miracle Morning».

Более того, обратимся к работам историка Roger Ekirch, которые свидетельствуют, что люди раньше спали фазами, а не одним цельным сном. Это явление описал не только он, и мне очень хотелось бы рассказать об этом большинству отечественных «сомнологов».

Что же говорят программисты

Дмитрий Комисаренко, Web & Android developer, фриланс

Можно сказать, раньше я был «совой» и часто засиживался ночью за кодом. Мне казалось, я был более продуктивным, поскольку тишина ночи только способствовала продуктивному настрою и комфортной работе, однако утром возникали проблемы. Поскольку я просыпался поздно, то садиться за работу во второй половине дня желания не было. Так я пришёл к выводу, что нужно попробовать поменять режим. Теперь я обычно стараюсь ложиться до полуночи и просыпаться как можно раньше. Мне это нравится больше.

Николай Стоев, CEO в Secret Lab

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

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

Олег Заворин, DevOps Engineer в Waverley Software

Долгое время работая в сфере IT, начинаешь замечать, что твой день давно не ограничивается формальными 8 часами. Ты все так же ходишь на работу по графику, но времени за компьютером ты проводишь 10+, как ни крути. Если ничего с этим не делать, то ты будешь постоянно уставшим и не выспавшимся, классическим «красноглазиком». После того как приходит понимание, что происходит, начинаешь искать выход — менять график или стараться больше проводить времени вне консол (желательно без потери производительности).

Перепробовав массу вариантов и поработав один раз с клиентом, которому был более удобен график с 16:00 до 24:00, я начал выбирать дальнейшие проекты исходя из смещенного или свободного графика (фриланс фултайм или сдельная работа).

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

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

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

Сколько часов необходимо человеку для отдыха

Итак, мы приблизились, пожалуй, к самому интересному вопросу: так сколько же действительно часов необходимо для сна? Стоит брать во внимание, что важно не так количество часов, как качество периода отдыха, ибо можно выспаться как за 6 часов, так и за 12. Это обусловлено тем, что сон по большей части зависит от ваших привычек, а точнее от того, чем вы занимаетесь днем. Другая составляющая — периодичность сна. Если ложиться и просыпаться примерно в одно время, то вам будет даваться проще и то, и другое.

Из личного опыта могу смело утверждать: для того, чтобы выспаться и восстановиться, достаточно от 5 до 8 часов (зависит от человека). Таким образом, мы можем получить дополнительные часы в сутках, сэкономив на сне, но только если будем придерживаться так называемой гигиены сна.

Что такое гигиена сна и как улучшить свой сон

Всё очень просто. Наверняка вы где-то читали про синий свет и где-то слышали слово «мелатонин». Так вот, всё это тесно взаимосвязано. Качество нашего сна определяется гормоном мелатонином (не путать с меланином). Его количество и пытаются прибавить большинство препаратов, призванных бороться с бессонницей. Выработка мелатонина зависит от многих условий и тесно связана с циркадными ритмами. Давайте же обсудим те факторы, которые благоприятно влияют на ваш сон:

Днём

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

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

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

Ночью

Меньше света. Перед сном следует затемнить свою комнату, а лучше с вечера постепенно уменьшать количество света. Любителям застрять перед сном в ванной, где преобладает яркий свет, придется несладко.

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

Прохлада. В идеале в комнате должна быть прохлада (около 18° С) с умеренным проветриванием. С этой целью окно у меня открыто практически каждую ночь во все сезоны, кроме зимы.

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

Синий свет. Как упоминалось выше, он отрицательно воздействует на качество сна, так как в большинстве случаев мы с ним контактируем непосредственно перед засыпанием. Выходом из этой ситуации может стать одно из сотен приложений для смартфона, что убавляет синий свет экрана и позволяет дополнительно затемнить его (просто введите «Ночной экран/режим в своём маркете». Для PC можно использовать бесплатную программу f.lux.

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

Больше воды. Мозг в среднем состоит на 80% из воды, в которой также остро нуждается весь организм. Держите бутылку рядом со столом и употребляйте хотя бы 2 литра воды в день для поддержания высокой работоспособности и, в конце концов, чтобы лучше себя чувствовать. Для сна это тоже хорошо.

Спокойствие. Дабы уснуть крепко и быстро, засыпать нужно в состоянии спокойствия. Именно для этого стоит избегать физических нагрузок и перевозбужденности мозга. Снижая активность, вы даете мозгу понять, что самое время уснуть. Если никак не получается успокоиться — попробуйте медитировать.

Как ускорить засыпание

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

• Если долго не можете уснуть, займитесь чем-то нейтральным. Разомнитесь, умойтесь и ложитесь обратно в кровать. Главное, не довести всё до того, что ваша кровать подсознательно будет ассоциироваться у вас со стрессом, поскольку вы регулярно беспокоитесь из-за того, что не можете уснуть.
• Если перед вашим лицом ночью стоит будильник — уберите его. Во-первых, это лишний источник света, а во вторых, он будет вас постоянно будоражить, поскольку «О боже, уже 11 часов, а я всё ещё не сплю». Это только добавляет стресса, и уснуть от этого становится сложнее.
• Чтобы организм схватывал на лету, что вот уже нужно засыпать, можно проделать ритуал засыпания. Перед каждым отходом ко сну вы делаете одну и ту же последовательность действий и заканчиваете всё тем, что ложитесь спать в кровать. Со временем засыпать станет куда проще, и вы будете прямо-таки «отключаться».
• Техника 4-7-8 также позволяет успокоиться и заснуть. Для её выполнения мы 4 секунды вдыхаем, 7 секунд удерживаем воздух и 8 секунд выдыхаем. Это, пожалуй, один из наиболее эффективных способов.

Трактат для сов

Я не говорю, что совы не люди и надо всем вставать в 4:20. Многие не могут позволить себе это по ряду объективных причин, поэтому этот раздел я посвящаю совам.

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

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

Можно также спать 1 фазу после работы/учебы и 2 фазы ночью. Этот метод отлично подойдет студентам с первой сменой и трудягам, которые параллельно делают свой проект и посещают основную работу.

Сложно заставить себя подняться утром?

В таком случае помогут будильники, для выключения которых нужно выполнить определенные задания. Это могут быть математические уравнения, либо же нужно сфотографировать что-то или сделать какие-то упражнения. Я пользуюсь Alarmy, а как альтернативу могу посоветовать Puzzle Alarm Clock.

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

Эффективные методы отдыха

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

Медитация. Нет, вам не нужны специальные подушки, свечки и не нужно с невозмутимым видом проговаривать «Омммммм». Для медитации достаточно просто сесть и глубоко дышать, концентрируясь на вдохе и выдохе. Всё. Таким образом вы возвращаете себе утраченные силы и обретаете осознанность.

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

Вывод

Так полезно ли работать ночью? Относительно. С точки зрения здоровья лучше, если сон будет в один заход, к которому вы готовитесь. Однако если рассматривать вопрос с точки зрения личной эффективности, то порой больше смысла от полифазного подхода, ибо некоторым людям необходимо работать глубокой ночью в связи с разными часовыми поясами и другими обстоятельствами.

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

А какого мнения придерживаетесь вы? Приемлемо ли для вас работать ночью?

Images by Noel De La Mora, Vinay Kumar.

До вашої уваги дайджест навчальних програм для тих, хто починає свою кар’єру в ІТ. У цьому номері зібрані можливості, актуальні у квітні 2018. Усі програми безкоштовні.

Якщо ви маєте інформацію про інші вакансії для початківців, безкоштовні курси/стажування, яких немає в дайджесті, пишіть на alyona@dou.ua, і ми додамо їх до статті.

Підписуйтеся на наш Telegram-канал, щоб дізнаватися про найактуальніші можливості для джуніорів. Туди ми надсилаємо сповіщення про оновлення дайджесту, нові курси, стажування та вакансії.

Binary Studio Academy

Напрям:курси JS, PHP, .NET, QA.
Місто:Київ, Львів, Одеса, Харків, Дніпро, онлайн.
Дедлайн подачі заявок: 27 квітня.

Вимоги до кандидатів:

• знання ООП, досвід з базами даних, початкові знання з JS, .NET, PHP;
• готовність протягом липня — першої половини вересня, приділяти мінімум 6-8годин навчанню;
• не має значення: вік, місце проживання та рівень здобутої освіти (але студентам 3-5курсу технічних спеціальностей легше пройти завдання відбору).

Як потрапити:зареєструватися на сайтідо 27.04. Підготуватися до відбору: у особистому кабінеті є необхідні матеріали, можна пройти демотест, а у телеграм-каналіє додаткові корисні посилання. Пройдіть онлайн-тест у зручний час 28.04 або 02.05, виконайте три завдання по відеолекціях і поспілкуйтеся з HR manager 10-15хвилин у скайпі.

Умови:курс проходить онлайн, повністю безкоштовно. Викладачі — досвідчені програмісти Binary Studio. Перед початком навчання, 30.06, студенти та викладачі зустрічаються в офісі Binary Studio у Львові на першу лекцію, а по завершенні курсу 15.09 презентують там же свої командні проекти на випускному і отримують сертифікати. В липні студенти отримують відеолекції від викладачів і завдання до них (кожних 2-3 дні)та опановують повний стек навичок. В серпні та вересні розробляють під керівництвом коуча повноцінний додаток з нуля. Приклади минулорічних проектів можна побачити тут.

Деталі:на сайтіабо пишіть на пошту academy@binary-studio.com.

EPAM

Тип:курси.
Місто:Львів, Київ, Харків.

Напрями та дедлайни подачі заявок:

Львів:

• Drupal Full-stack — березня;
• Automated testing (Java) — 30 березня;
• Java — 6 квітня.

Київ:

• .NET — 13 квітня;
• QA — 11 травня;
• Java — 4 травня.

Харків:

• Java — 1 липня;
• DevOps — 1 липня;
• .NET — 1 липня;
• Front-end — 1 липня;
• Software Testing Introduction — 1 липня;
• Test Automation — 1 липня.

Як потрапити:зареєструватися на сайтіта пройти тест. Тестування включає технічний комп’ютерний тест та перевірку рівня знань англійської мови. Співбесіда з рекрутером.

Умови:зовнішні заняття (до 3 місяців), Pre-Production лабораторія (від 3 до 6 місяців).

GlobalLogic

Напрям: GL BaseCamp за напрямками С++ та Python QA Automation.
Місто:Львів.
Дедлайн подачі заявок:С++ — 4 квітня, Python QA Automation — 30 березня.

Вимоги до кандидатів:

• базові знання та навички програмування;
• англійська рівня Intermediate і вище.

Як потрапити:пройти тестування на сайті (увійдіть у систему під своїм акаунтом у соцмережах із актуальними контактними даними, у розділі Tests > C/C++ оберіть GL Lviv BaseCamp C++ або у розділі Tests > Python оберіть Python QA Automation GL BaseCamp Lviv 2018). Якщо тест зданий (PASSED), обов’язково заповніть форму реєстрації для C++до 4 квітня, 17:00, для Python QA Automationдо 30 березня. Претендентів з найкращими результатами тестів та CV запросять для проходження відбіркового завдання та інтерв’ю в офісі.

Умови:С++ — заняття кожного дня, Python QA Automation — тричі на тиждень У разі успішного проходження курсів студенти отримають можливість долучитися до проектів компанії.

Деталі:GL BaseCamp C++, Python QA Automationабо пишіть на пошту lviv.basecamp@globallogic.com (будь ласка, вкажіть у темі листа «С++ BaseCamp» або «AQA GL BaseCamp»).

KindGeek

Напрям:курси JavaScript [React].
Місто:Львів.
Дедлайн подачі заявок: 2 квітня.

Вимоги до кандидатів:

• базові знання JavaScript;
• знання СSS, HTML;
• рівень володіння англійською мовою від intermediate.

Як потрапити:надіслати CV на пошту school@kindgeek.com, пройти співбесіду.

Умови:програма спрямована на покращення розуміння мови JavaScript в цілому, а також особливості виконання коду та формування вигляду сторінки безпосередньо у браузері. Курс надасть глибокі теоретичні знання з використання бібліотек React JS та Redux, які будуть закріплені постійними практичними вправами на реальному проекті. Заняття проходять двічі на тиждень (вівторок та четвер після 18.00) у формі інтерактивних лекцій з практичними домашніми завданнями. Курс триватиме 2 місяці. Можливе працевлаштування за умови успішно пройденого курсу та повторної співбесіди.

Деталі:school@kindgeek.com

Netcracker

Напрям:курси QA, CSA.
Місто:Суми.
Дедлайн подачі заявок: QA — реєстрація до 1 квітня, CSA — реєстрація можлива на постійній основі.

Вимоги до кандидатів:
QA

• вища або незакінчена вища освіта;
• розвинена логіка, аналітичні та базові математичні здібності;
• основи SQL;
• основи телекому.

• вища або незакінченна вища освіта;
• розвинена логіка, аналітичні та базові математичні здібності;
• добре володіння англійською мовою.

Як потрапити:заповнити анкету на сайті, пройти технічне тестування та тестування на знання англійської мови. Успішних кандидатів запросять на співбесіду з HR спеціалістами.

Умови:тривалість навчання — від 2 до 3 місяців. Після закінчення можливе працевлаштування в компанії.

Деталі:на сайті.

NIX Solutions Ltd

Напрям:курси.
Місто:Харків.

Вимоги до кандидатів:

• практика .NET;
• практика Android;
• практика iOS;
• навчання Linux Administration / DevOps;
• практика PHP/CMS;
• навчання Ruby;
• навчання Salesforce.

Як потрапити:подати резюме на сайті, пройти тестування в офісі або ВНЗ, пройти співбесіду.

Умови:практики (Android, IOS, .Net, PHP/CMS) тривають 3 тижні в один з літніх місяців у офісі компанії в будні повний робочий день. Навчання Linux Administration/DevOps та Ruby триває від 2 до 5 місяців залежно від напряму у форматі лекцій 2 рази на тиждень. Business Analysis Education проходить протягом 2 місяців повний робочий день з понеділка по п’ятницю в офісі. Дистанційне навчання Salesforce триває 3 місяці з лекціями 1 раз на тиждень в офісі компанії.

Деталі:пишіть на пошту education@nixsolutions.com.

PLVision

Напрям:курси C, Computer Networks, Python, Linux.
Місто:Львів.
Дедлайн подачі заявок: 25 квітня.

Вимоги до кандидатів:

• студенти старших курсів технічних спеціальностей з високою мотивацією навчатися і розвиватися у сфері комп’ютерних мереж (мережевих пристроїв та хмартних технологій);
• досвід роботи з Linux OS на рівні користувача;
• добрі навички програмування на C;
• базові знання комп’ютерних мереж;
• високий рівень англійської (Intermediate і вище).

Як потрапити:зареєструватися за лінком, виконати тестове завдання, пройти вступні співбесіди з hr-менеджером та технічними експертами компанії.

Умови:навчання проводять провідні експерти компанії. Курс триватиме з 2 до 28 травня, лекції відбуватимуся щодня з понеділка по п’ятницю з 9:00 до 16:00 в офісі компанії (вул. Володимира Великого, 2в). Найкращі випускники отримають запрошення приєднатися до команди.

Деталі:на сайтіабо пишіть на пошту learning.center@plvision.eu.

SoftServe

Тип:курси.
Місто:Львів, Київ, Рівне, Харків, Дніпро, Чернівці.

Напрям та дедлайн подачі заявок:

• QC: Львів — 30 квітня, Рівне — 11 квітня;
• WebUI: Київ — 16 квітня, Львів — 23 квітня, Чернівці — 30 квітня;
• GoLang: Харків — 18 квітня, Дніпро — 19 квітня, Львів — 24 травня;
• .NET: Дніпро — 20 квітня, Львів — 8 травня;
• Java : Дніпро — 26 квітня, Львів — 4 травня, Чернівці — 7 травня;
• DevOps: Львів — 3 травня;
• Test Automation QC: Львів — 4 травня, Чернівці — 14 травня, Рівне — 28 травня, Харків — 14 червня;
• Python: Львів — 4 травня;
• Node.js: Рівне — 14 травня, Харків — 18 травня;
• Test Automation: Львів — 4 травня, Чернівці — 14 травня, Рівне — 28 травня, Харків — 14 червня.

Вимоги до кандидатів:

• рівень англійської Intermediate+;
• студенти дотичних напрямків 2-йкурс і вище;
• готовність до кропіткої роботи.

Як потрапити:заповнити заявку на сайті, пройти технічне тестування і тест на знання англійської мови, пройти співбесіду.

Умови:середня тривалість курсу — 2-4 місяців,заняття проходять у неробочий час.

1+1 медіа

Напрям:стажування РНР, QA.
Місто:Київ.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

РНР

• студент (що має можливість стажуватися в офісі компанії від 4 годин на день) або випускник технічного ВНЗ останніх років);
• бажано має досвід в програмуванні від 1-гороку;
• має грамотну письмову і усну мову (українську, російську); рівень володіння англійською мовою intermediate і вище (вміє читати технічну літературу англійською мовою зі словником);
• високий рівень знань ООП, розуміння патернів розробки (MVC);
• має власні напрацьовані завдання/проекти та читабельний код; має досвід розробки веб-сервісів або сайтів;
• має базові знання в HTML, CSS, JS;
• вміє працювати з Git репозиторіями;
• вміє працювати з реляційними базами даних; самостійно може створювати складні запити до MySQL БД проекту;
• вміє читати чужий код;
• розуміє, як працювати з API;
• вміє аналізувати завдання;
• відповідальний та уважний до деталей;
• здатний швидко навчатися;
• орієнтований на результат.

QA

• студент (що має можливість стажуватися в офісі компанії від 4 годин на день) або випускник технічного ВНЗ останніх років;
• має мінімальний досвід роботи;
• закінчив курси по тестуванню ПЗ;
• має початкові навички у програмуванні;
• має грамотну письмову і усну мову (українську, російську), рівень володіння англійською мовою intermediate і вище (вміє читати технічну літературу англійською мовою зі словником);
• вміло володіє теоретичними знанням за своїм фахом;
• вміє аналізувати проблему;
• має високий рівень користування ПК;
• має велике прагнення розвиватися за напрямком тестування;
• відповідальний та уважний до деталей;
• здатний швидко навчатися;
• орієнтований на результат;
• проактивний.

Як потрапити:зняти відеорезюме, заповнити заявку (РНР, QA). Відеорезюме — відео тривалістю 1-2 хвилини,що містить інформацію про навички, досвід, інтереси та переконання кандидата. Відеорезюме дає можливість доповнити стандартне резюме емоціями та показати особистість кандидата, а не лише його освіту та досвід.

Умови:тривалість стажування — 6 місяців: 1-йетап (3 місяці) — завантаження до 20 годин/тиждень (4 год/день, гнучний графік), 2-йетап (3 місяці) — завантаження до 30 годин/тиждень (6 год/день, гнучкий графік), стажер отримує стипендію. За умови успішного завершення стажування можливе працевлаштування в компанії.

AMC Bridge

Напрям:стажування C++, C#, web services, Front-end.
Місто:Дніпро.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:студенти 3-6-го курсів технічних спеціальностей вищих навчальних закладів. Термін стажування повинен збігатися з навчальним планом ВНЗ, у якому навчається студент.

Як потрапити:надіслати резюме на сайті, виконати тестове завдання та пройти співбесіду із HR-менеджером, технічним інтерв’юером та директором дослідницького підрозділу компанії.

Умови:стажування являє собою роботу на одному з проектів у внутрішньому дослідницькому підрозділі компанії строком на 1 місяць з тижневою зайнятістю 40 годин. Залежно від результатів стажування, студента може бути рекомендовано до прийняття на роботу в компанію.

Деталі:на сайті.

Appus Studio

Напрям:стажування Sales Manager.
Місто:Харків.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

• вільна письмова і розмовна англійська (обов’язково);
• навички продажів і ведення переговорів;
• навички ведення ділового листування;
• знання принципів і основ ділової етики;
• буде перевагою досвід у продажах, сертифікат про закінчення Sales-курсів;
• доброзичливість, орієнтованість на результат, проактивність, самомотивація.

Як потрапити:заповнити форму реєстрації, пройти тестування на знання англійської мови, пройти співбесіду.

Умови:стажування передбачає навчання в офсі компанії. Орінтовний початок стажування — наприкінці червня — на початку липня. Тривалість — 3 місяці. Кожен стажер отримуватиме стипендію в розмірі 1000 грн. Навчання проходитиме з понеділка по п’ятницю по 4 години на день. Буде сформовано 2 групи (ранкова та вечірня) по 5 осіб у кожній. За результатами стажування кандидати пройдуть співбесіду з HR-менеджером і найкращим запропонують працевлаштування.

Деталі:на сайтіабо пишіть на пошту cv@appus.com.ua.

CHI Software

Напрям:стажування Ruby on Rails, DevOps.
Місто:Харків.

Вимоги до кандидатів:
Ruby on Rails

• знання хоча б однієї об’єктно-орієнтованої мови програмування та вміння вирішувати найпростіші алгоритмічні завдання з її допомогою;
• основи релятивних БД, SQL;
• добре знання HTTP;
• знання UNIX-like ОС (Ubuntu та ін.);
• базове знання HTML/ CSS/ JS;
• знання англійської мови на рівні intermediate або вище;
• самомотивація.

DevOps

• вища або незакінчена вища профільна освіта;
• знання основ Linux;
• розуміння моделі OSI, стеку TCP/IP та DNS;
• знання принципів веб-серверів;
• знання англійської мови на рівні Intermediate.

Буде плюсом:

• практичний досвід системного адміністрування Linux/Unix;
• розуміння релятивних баз даних;
• досвід системного адміністрування Windows;
• досвід написання прикладних скриптів для автоматизації (Bash, Python etc.);
• досвід роботи з хмарними середовищами (AWS, GC, MS Azure);
• досвід з CI/CD tools;
• досвід з Docker.

Як потрапити:відправити CV на пошту careers@chisw.com, виконати тестове завдання, пройти співбесіду в офісі з технічним фахівцем.

Умови:навчання в інтернатурі відбувається у форматі повноцінної роботи у компанії протягом 3 місяців (повний 8-годиннийробочий день, з понеділка по п’ятницю, гнучкий графік). За період навчання в інтернатурі кандидати будуть отримувати оплату та зможуть брати участь в усіх заходах, що відбуваються у компанії. Кожному інтерну буде виділений ментор, який буде давати йому завдання, слідкувати за прогресом та проводити код рев’ю.

Деталі:пишіть на пошту careers@chisw.com.

JetThoughts

Напрям:стажування Ruby on Rails.
Місто:Львів, remote.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

• студенти 1-4 курсів;
• знання Ruby/Ruby on Rails;
• бажання вчитися і розвиватися;
• наявність домашнього проекту;
• досвід комерційний/некомерційний.

Як потрапити:надіслати резюме на сайті, пройти тестування.

Умови:стажування оплачуване, триває від 3-6 місяців,графік вільний, робота відалено.

Деталі:на сайтіабо пишіть на пошту ivo@jetthoughts.com.

Clockwise Software

Напрям:стажування JavaScript, Project managment.
Місто:Дніпро.

Вимоги до кандидатів:
JavaScript

• вища технічна освіта;
• знання алгоритмів та структур данних;
• знання англійської на рівні Intermediate+.

Project managment

• освіта вища, незакінчена вища;
• рівень англійської Upper-intermediate +;
• досвід управління проектами в суміжних галузях.

Як потрапити:відправити резюме на пошту hr@clockwisesoftware.com, виконати тестове завдання та пройти співбесіду.

Умови:тривалість навчання — 2 місяці. Програма передбачає вивчення теорії та виконання практичних завдань. У кінці кожної теми — тестовий контроль. У разі успішного опанування програми — пропонують працевлаштування в компанії.

Деталі:пишіть на пошту hr@clockwisesoftware.com.

MedeAnalytics

Напрям:стажування Database Development.
Місто:Харків.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

• бажання працювати з базами даних;
• студент 4-5 курсу;
• базове розуміння того, як працюють бази даних;
• базове розуміння SQL ;
• буде плюсом розуміння OLAP/MDX.

Як потрапити:подати резюме на сайті.

Умови:стажування оплачуване, будьте готові приділяти йому 30 годин на тиждень, проходить в офісі компанії, гнучкий графік. Для успішних кандидатів — прцевлаштування.

Деталі:на сайті.

Materialise

Напрям:інтернатура C++, research, algo.
Місто:Київ.
Дедлайн подачі заявок:немає.

Вимоги до кандидатів:

• зацікавленність в research та алгоритмах;
• навички програмування С ++;
• можливість працювати 4-6 годин.

Як потрапити:пройти тестування в онлайн-режимі та написати коротку інформацію про себе.

Умови:Стажування триває 3 місяці, щоквартально. Графік — гнучкий (4-6робочих годин на день, можна працювати віддалено). Ви маєте можливість взяти участь у дослідницьких проектах у трьох різних сферах діяльності компанії: інженерія, програмне забезпечення та 3D друк (Additive виробництво). Стажер працюватиме під керівництвом спеціалістів Materialise.
Деталі:на сайті.

Sigma Software University

Тип:стажування.

Вимоги до кандидатів та дедлайни:

• PHP: Харків — 16 травня;
• PHP/Wordpress: Харків — 16 травня;
• .NET — 1: Харків — 13 квітня;
• .NET — 2: Харків — 13 квітня;
• QA: Харків — 27 квітня;
• JavaScript: Харків — 27 квітня;
• DevOps: Харків — 25 квітня;
• Embedded: Львів — 25 квітня.

Як потрапити:заповнити реєстраційну форму на сайті (у відповідному розділі) та додати резюме.

Умови:тривалість стажування від 3 до 6 місяців залежно від напряму; повний робочий день.

BotsCrew

Напрям:робота Java.
Місто:Львів.

Вимоги до кандидатів:

• добрі знання OOP;
• Java Core;
• реляційні бази даних;
• REST;
• Hibernate/JPA;
• англійська — Upper-Intermediate і вище;
• бажання розвиватися та мотивація;
• вища освіта/курси;
• кандидат може бути студентом.

Як потрапити:подати заявку на сайті, надіслати резюме, виконати тестове завдання, пройти співбесіду та стажування.

Умови:після проходження стажування можливе працевлаштування. На стажуванні за кандидатом буде закріплений ментор.

Деталі:на сайтіабо пишіть на hr@botscrew.com.

Evolvice Team

Напрям:робота Quality Assurance Tester.
Місто:Київ.

Вимоги до кандидатів:

• англійська — upper-intermediate;
• кандидат має бути геймером, у вільний час захоплюватися іграми;

Як потрапити:заповнити заявку на сайті.

Деталі:на сайті.

Expercast

Напрям:робота Javascript, Ruby, QA.
Формат: remote.

Вимоги до кандидатів:

• рівень англійської — не нижче, ніж Upper-intermediate;
• можливість працювати віддалено;
• кмітливість, здатність швидко вчитись, бажання брати на себе виклики ;)
• для JavaScript та Ruby розробників — попередній досвід (можна не комерційний) із технологіями буде плюсом;
• для QA Engineers — буде плюсом знання JavaScript, SQL, HTML/CSS.

Як потрапити:надіслати резюме на jobs@expercast.comта кілька слів англійською мовою про те, саме зацікавило в посаді. Обов’язково вказуйте в темі листа посаду, на яку подаєтесь: [Junior JavaScript], [Junior Ruby], [Junior QA].

Умови:працевлаштування після проходження всіх етапів процесу відбору.

Деталі:на сайтіабо пишіть на пошту jobs@expercast.com.

Intetics

Напрям:робота функціональне програмування.
Місто:Київ, Харків, Львів.

Вимоги до кандидатів:

• вміти виконувати алгоритмічні задачі;
• знати хоча б одну мову програмування;
• любити алгоритми (або нестандартні задачі);
• англійська рівня Intermediate та вище.

Як потрапити:надішліть резюме на пошту fp@intetics.com, отримайте тестове завдання і виконайте його, поспілкуйтеся з рекрутером, виконайте друге тестове завдання в офісі.

Умови:на самому початку роботи у вас буде вступний період, протягом якого ви вивчите нову функціональну мову / нові інструменти та ввійдете в проект. Потім зможете виконувати більш складні задачі. Протягом усього навчання за вами буде закріплений ментор. Пропонуємо гнучкий графік роботи, допомогу та супровід, якщо вам потрібно переїхати в інше місто.

PNN SOFT

Напрям:робота .NET, iOS, Android, QA.
Місто:Київ

Вимоги до кандидатів:

• вища технічна освіта (готові взяти студента);
• мінімальний досвід роботи або спеціалізовані курси;
• рівень англійської — Intermediate.

Як потрапити:надіслати резюме на HR@pnn.in.ua.

Умови:повний робочий день, гнучкий графік, є оплата.
Деталі:.NET, iOS, Android, QA.

У рубриці DOU Проекторвсі охочі можуть презентувати свій продукт (як стартап, так і ламповий pet-проект). Якщо вам є про що розповісти — запрошуємо взяти участь. Якщо ні — можливо, серія надихне на створення власного made in Ukraine продукту. Питання і заявки на участь надсилайте на editors@dou.ua.

Мене звуть Володимир Бондаренко, я співвласник компанії Mauris та один з творців мобільного сервісу Movie Expert. Наш додаток допомагає за 15 хвилин створити список фільмів та серіалів для перегляду на півроку вперед.

Ідея

Напевно, кожному відоме почуття «хочу подивитися щось, не знаю що, і ніхто мені не допоможе». Думка про створення кіносервісу приходила до нас неодноразово, але сформувался остаточно в 2013 році. Трудові будні хотілося скрасити хорошою підбіркою фільмів на вечір, в черговий раз стало зрозуміло: не все те подобається, чому ставлять високі оцінки. Ні рейтинг «Імхонет», ні «КиноПоиск» та IMDb не змогли допомогти в пошуку відповідних фільмів. Кінострічки з високим рейтингом були або переглянуті раніше, або не цікаві, що, власне, ставило в ступор. А фільми із середнім рейтингом було важко оцінити і відібрати. По-перше, коментарі і рецензії ділилися на два повноцінних табори: за і проти. По-друге, сам процес підбору фільмів займав досить багато часу (адже щороку тільки в Голлівуді випускають більше 800 фільмів і серіалів), і в більшості випадків часу на перегляд кінострічки просто не залишалося.

Так і прийшла думка створити сайт зі спеціальним алгоритмом, метою якого є:

• відображення ТОПу класних фільмів згідно з інтересами конкретного користувача, базуючись на оцінках раніше вподобаних фільмів;
• надати можливість ранжування рекомендацій фільмів з огляду на додаткові параметри.

Однак, приступивши до роботи, ми відразу ж зіткнулися з низкою проблем. Те, що зручно розробнику, не завжди комфортно для користувача: програмування зайняло всього 2 дні, а перетворення в зрозумілий для користувача сервіс — більше року.

Спочатку користувачеві необхідно було авторизуватися на сайті за допомогою ВК або ФБ. Далі він бачив сторінку з 9 фільмами, з яких потрібно було обрати ті, які він вже бачив, та оцінити. Якщо користувач відмічав більше 2 фільмів на сторінці, список фільмів для оцінки оновлювався. Із запропонованих фільмів можна було обирати ті, які хочеш подивитися, а також побачити список вже оцінених. На сайті також була доступна функція «подивитися фільм з другом», яка дозволяла визначити фільм, який не дивився ні користувач, ні його друг.

Проблема 1.Розробка зручного і зрозумілого інтерфейсу для користувача.

Спочатку потрібно було відтворити в пам’яті переглянуті фільми. Коли ресурс вимагав ввести в пошуковий рядок 10 улюблених фільмів, половина користувачів впадала в ступор: вони просто не могли їх пригадати.

Рішення.Швидкий хотфікс з постійно оновлюваною підбіркою фільмів з найкращим рейтингом — хороша підказка для забудькуватих.

Проблема 2.Функція «перегляд фільму з другом» не спрацювала: на FB або ВК обиралася сторінка користувача, по ній робився перехресний аналіз — які фільми не дивилися ні ви, ні друг. Сервіс добре підбирав фільми в одиночному режимі, але при перехресному аналізі виникала проблема: система видавала фільми, які в більшості випадків були нецікаві обом користувачам. В результаті комбінацією з двох списків не користувався практично ніхто.

Рішення.Відключили функцію, вирішивши залишити її доопрацювання до кращих часів, коли сервіс матиме постійну аудиторію.

Злет і падіння

Після анонсу про вихід сервісу в закритому співтоваристві результати перевершили всі очікування. За перший тиждень було зібрано більше мільйона оцінок фільмів. Але була й зворотна сторона медалі: наші сервери впали. На той момент у нас не було достатнього досвіду роботи з великою аудиторією: при одночасному заході на сайт більше 500 користувачів скрипт не витримав і впав.

Весь back-end був написаний на PHP, а в якості БД використовували MySQL. Для виправлення ситуації потрібно було максимально прискорити ресурс, тобто:

• оптимізувати запити в БД;
• змінити алгоритм;
• змінити конфігурацію сервера;
• дати можливість використовувати частково попередньо згенеровані дані (batch process) і кеші даних.

... до чого ми і приступили.

Виконану роботу можна розділити на кілька етапів:

1 етап.Сайт був багатомовним: мав російську і англійську локалізації. Нам довелося впровадити Memcached — систему кешування, в якій було закладено переклад контенту, а також інтерфейсу. У підсумку, всі сторінки почали відображатися вдвічі швидше — за рахунок вивантаження з оперативної пам’яті і усунення запитів в БД на переклад інтерфейсу.

2 етап. Об’єднав декілька операцій:

• Зміна алгоритму отримання даних.
• Розбивка складних запитів на підзапити.
• Застосування табличних індексів.
• Оптимізація обробки рядків (якщо просто з’єднати таблиці між собою через JOIN, не факт, що БД обере оптимальний варіант роботи сама).
• Використання memory-таблиць. Щоб з автоматичного JOIN-a таблиць використовувати ручне з’єднання, ми зробили ряд простих запитів — вони отримували ті ж дані, але в певному порядку. Це зменшило кількість оброблюваних даних.

Після цього ми зайнялися перекладом індивідуального рейтингу фільмів зі звичайної таблиці в memory (розташованої в оперативній пам’яті) — в результаті отримали хороший приріст швидкості, з якою працював алгоритм перерахунку рейтингу. Вона збільшилась у 10 разів.

Схема оптимізації була такою: після кожних трьох оцінених фільмів відбувається перерахунок — дані генеруються дуже часто, і в нас немає необхідності їх зберігати. Навіть якщо база обнулиться або щось трапиться з сервером, ми просто заново згенеруємо для користувача ці дані (здебільшого вони є службовими).

Також ми застосували ручне партиціювання БД: зробили розбиття — оцінки фільмів певних груп відвідувачів зберігалися в різних таблицях. Тобто ми горизонтально розбивали оцінки по n-ій кількості таблиць в залежності від зростаючої бази користувачів. Розмір кожної таблиці був обмежений 1 мільйоном записів: це дозволяло виконувати SQL-запити з необхідною нам швидкістю.

3 етап.Оптимізація сервера. На той момент ми використовували VPS, ресурси якого були обмежені, але після конфігурації результат не змусив себе чекати. Ми збільшили кількість одночасних підключень до БД і запитів на сервер.

4 етап.Ми запустили перерахунок оцінок. Після перших днів роботи сервісу стало зрозуміло, що динамічний підрахунок рейтингу фільму уповільнює час завантаження сторінки: моніторились сотні записів і по ним виводилися середні оцінки. Написаний нами новий скрипт щодоби о 2 годині ночі запускав оновлення даних по рейтингах, за рахунок чого час завантаження сторінки скоротився.

Виконання цих робіт зайняло кілька днів. У підсумку, все закінчилося добре: після перезапуску сайту все запрацювало.

Зміна концепції

Веб-сервіс — це не тільки питання розробки та технічної підтримки. З’явилася проблема різкого падіння кількості користувачів. Усе відбувалося так: користувач заходив на сайт, проводив 2-3години за оцінкою фільмів та зникав. У кращому випадку повертався ще кілька разів. Це дало нам привід замислитися над тим, що в такому форматі сервіс себе вичерпав.

Сервіс повинен був стати більш зрозумілим за форматом і мотивувати користувача до наступних відвідувань. Для цього було потрібно:

• оптимізувати шлях користувача при роботі з сервісом (ввести навчання);
• розробити алгоритм по «утриманню» і залученню користувача.

Ми почали роботу, паралельно виконуючи аутсорс-замовленняв інших галузях — а їх було дуже багато. Минуло кілька місяців, потім ще і ще, і через 2 роки ми усвідомили: замовлень стає тільки більше, ми працюємо на піку. Якщо не реалізувати наш власний проект зараз, цього не станеться ніколи.

Отож, у грудні 2016 року ми знову провели перезапуск сервісу, змінивши його формат. Вирішили замість сайту створити додаток під дві платформи — iOSі Android.

Ми бачили, що перспектива розвитку проекту на мобільному пристрої значно вища:

• є можливість нагадати про себе за допомогою push-повідомлень;
• список фільмів завжди в кишені користувача;
• мобільний продукт цілком успішно здатний відучити користувача напружувати пам’ять (за аналогією з Tinder) і спокійно «вести» його.

Принцип роботи програми такий: користувачеві динамічно подаються 10 карток фільмів для оцінки. Після 5 відмічених фільмів йде перерахунок рейтингу і завантажуються наступні 10 карток з урахуванням нових оцінок. Якщо користувач відмічає фільм як «не визначився», кінострічка може бути запропонована повторно для оцінки через кілька тижнів.

Щоб спростити інтерфейс програми, за основу взяли принцип Tinder. На головному екрані користувач повинен оцінювати фільми за допомогою свайпів вправо та вліво. У додатку доступні такі розділи: «Хочу подивитися», у якому зібрані фільми, які планує переглянути користувач; «Ми рекомендуємо» — рекомендації додатка; «Пошук фільмів» — де можна знайти фільми та серіали.

На початковому етапі втіленням в життя своєї ідеї я займався самостійно. Пізніше підключився друг, який налаштовував сервери. Потім у зв’язку з переробкою концепції, переходом від веб-сайту до мобільного додатку і розширенням функціоналу до розробки долучили серверного та мобільних розробників.

Складнощі

Крос-платформа.Одна з проблем полягала в тому, що ми хотіли випустити мінімально життєздатний продукт (MVP) на крос-платформі, щоб протестувати актуальність проекту і перенести його на Native. Тоді, коли почали розробку програми, з’явився React Native. З огляду на те, що хотіли запустити проект в найкоротші терміни, вирішили використовувати Cordova. Після реалізації низки проектів на React, побачили, що ця технологія більш продуктивна.

Зараз ми хочемо домогтися гарної статистики, щоб упевнитися в раціональності перенесення програми на іншу платформу, адже цей процес займе близько 4 місяців. Потрібно буде або заморозити проект, або паралельно розробляти проект на Native.

Інтерфейс.Як поєднати свайпи вліво і вправо з великою кількістю функцій програми (дивився, не дивився, хочу подивитися і т. д.)? Варіант «хочу подивитися — свайп вправо, не хочу — вліво», а внизу «оцінка» не виправдав надій: плей-тест показував, що люди не розуміють, чого від них хочуть. Від бездумних свайпів та оцінок навмання алгоритм починав працювати гірше.

Рішення прийшло тоді, коли ми цього зовсім не очікували. Влаштувавши виїзні корпоративні канікули з катанням на лижах в австрійських Альпах, ми, 3 кіномани, підключивши дизайнера і пляшку віскі, знайшли рішення.

Концепт став трохи складнішим, але можливість зробити помилку була зведена до мінімуму. Свайп вправо — користувач позначає, що фільм вже дивився, і йому пропонують поставити оцінку за десятибальною шкалою. Свайп вліво — фільм не був переглянутий раніше, тому потрібно вибрати один з 3 пунктів («не хочу дивитися», «хочу подивитися», «не визначився»). Ми пожертвували зручністю інтерфейсу заради того, щоб відсоток нерозуміння механіки звівся до нуля. У підсумку, користувач став розуміти, що і навіщо він робить, більш усвідомлено приймати рішення, після чого алгоритм видавав йому відповідні фільми.

Розчарування у фільмах.Перша підбірка для оцінки складалася з фільмів з високими балами топових рейтингів — і при цьому більшість з них люди просто не дивилися. Після 3 свайпів «не дивився» вони розчаровувалися і закривали додаток. Спочатку для вирішення проблеми просто поставили фільтри (стали показувати фільми останніх 10 років), але це не допомогло.

Проблему довелося вирішувати вручну: зібралися командою розробників і за один вечір сформували перелік з 52 фільмів, які бачила більшість. Саме їх користувачі оцінюють в першій видачі.

Підбірка була складена з фільмів різних жанрів, щоб по їх закінченні в людини сформувалася різнорідна картина, і додаток міг направити її в будь-яке русло, в залежності від уподобань. Після цього кількість користувачів, які «пройшли» перші 5 фільмів, склала 95%.

Зі специфічних проблем:

• У додатку ми використовуємо трейлери фільмів з YouTube. Щомісяця 10% YouTube-роликів стають недоступні, тому довелося розробити алгоритм аналізу і швидкої заміни недоступних відеороликів.
• Однойменні фільми. Як виявилося, їх існує досить багато. Доводиться ретельно аналізувати контент.
• Існує низка трейлерів, які захищені авторськими правами. Вирішуємо проблему автоматичним відсіюванням таких трейлерів.
• Основна частина проблем була юридичного характеру, а саме пов’язана з авторським правом на постери, які використовуються в додатку. Нам довелося витратити багато часу на складання звернення до правовласників, підбір постерів з певним типом ліцензії, а також розробку механізму, який допомагає швидко виключити фільм в разі запиту від правовласника.

Після випуску першого масштабного оновлення аудиторія Movie Expert почала активно зростати (наразі є близько 18 тис. користувачів). Ми ретельно аналізували всі коментарі, а також побажання людей. І тоді побачили, що у деяких користувачів iOS-пристроїв (з Android проблем немає) відбувається автоматичний вихід з облікового запису. Почалася активна робота над пошуком і відтворенням цього бага.

Нам вдалося з’ясувати, що коли пам’ять iPhone переповнена, вночі відбувається очищення всіх локальних даних нашого сервісу. І зайшовши наступного разу, людина бачить порожній додаток. До речі, відтворити таку ситуацію вийшло досить випадково: один з наших співробітників завантажив велику кількість музики, чим заповнив всю пам’ять свого iPhone. А на наступний ранок відкрив Movie Expert і побачив, що не авторизований у додатку. Щоб вирішити цю проблему, ми впровадили перевірку користувача за ідентифікатором пристрою і не показуємо інтро та першу вступну підбірку.

Як виявилося, ця проблема вирішується на старих айфонах, але в останніх версіях операційних систем iOS ввели налаштування відображення рекламного ідентифікатора для додатків (за замовчуванням він прихований). За рахунок цього ми не можемо отримати ідентифікатор пристрою, тому нам доводиться генерувати йому свій ідентифікатор, який зберігається локально. А в разі, якщо iPhone очищає дані, ідентифікатор теж зникає, і для пристрою створюється новий ідентифікатор. Над вирішенням цієї проблеми ми все ще працюємо. В цілому, розробники прагнуть збільшувати пам’ять на нових смартфонах, тому проблеми з авторизацією у користувачів зустрічаються все рідше.

Що в результаті

Перша версія додатку була доступна у липні 2017 року. Ми провели бета-тестування, зібрали фідбек, впровадили ряд доробок і в кінці січня 2018 року випустили оновлену версію, яка вже доступна в Google Play та AppStore. З iOS-версією все виявилося складніше — нам довелося пережити 5 перевірок від прискіпливих модераторів: співробітники компанії Apple ретельно тестують кожен додаток на всіх iOS-гаджетах. Вони змогли відловити баг при запуску iPhone додатку на iPad, який полягав у тому, що при свайпі картка не зникала, її потрібно було вести пальцем до кінця екрану.

Додаток безкоштовний. Можна придбати одну з підписок на 3, 6 або 12 місяців. Вона дає доступ до всіх фільмів без перегляду реклами.

В оновленій версії користувачів очікують такі фічі:

1. Щоденні підбірки фільмів на різноманітні тематики — відмінна альтернатива свайпам і рекомендаціям. Ми очікуємо, що це вмотивує людей частіше користуватися додатком.
2. Розширений профіль зі статистикою за своїми оцінками і визначенням улюблених жанрів, а також система досягнень користувача з бонусами (критик, кіноман, сценарист, експерт).
3. Тепер у видачу можна додати серіали.
4. Пошук фільму: можна відразу знайти кіно і додати його в список «хочу подивитися» або оцінити переглянуті раніше фільми. Додана функція «поділитися фільмом з другом» (посилання, при переході на яке відкривається сторінка фільму).
5. PRO-режим — можливість отримати повний доступ до фільмів зі списку «Рекомендації», які обирає для користувача система на основі його оцінок. Деякі картки фільмів у цьому списку знаходяться під знаком питання. Якщо хочеш дізнатися, який це фільм, можна або подивитися рекламу, або купити один з PRO-режимів, і всі фільми будуть відкриті. Також можна побачити розширену статистику за своїми оцінками.

У найближчих планах:

• випустити оновлення з фільтрацією фільмів по акторах;
• додати можливість коментувати фільми і серіали;
• створити стрічку, в якій можна буде стежити за оновленнями і оцінками друзів.

Завантажуйте додатки в AppStoreі Google Play, оцінюйте, залишайте відгуки. Будемо вдячні за будь-який зворотній зв’язок про виконану нами роботу!

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

Competera была основана в 2014 году. Главный офис находится в Киеве, где сегодня работает более 50-тисотрудников в продуктовых и сервисных командах, из них 20 — технические специалисты.

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

В округе и поблизости

Офис Competera находится на мансардном этаже здания по адресу ул. Артёма, 72а. До ближайшей станции метро «Лукьяновская» — 10 минут спокойным шагом.

С поиском кафе или общепитов поблизости проблем точно не будет. В минуте ходьбы от офиса находятся такие кафе, как «Кухня Полли» (стоимость обеда — около 100 грн), «Канарейка» (средний чек — 100-150 грн),веганское кафе Orang+utan Bar (50-100грн за блюдо), Domino’s Pizza, гастропаб Seven Hills. В близлежащих домах есть различные кофейни, кондитерские и эко-лавки.

Несмотря на изобилие мест, у сотрудников нет острой необходимости выходить на обед за пределы офиса: компания полностью оплачивает обеды для команды. Сейчас специалисты выбирают себе меню на неделю у нескольких поставщиков, и каждый день к 12:00 в офис доставляют комплексные обеды, тем самым снимая проблему готовки еды дома и выбора блюд на ланч. В офисе также стоит автомат с едой от Fred & Fresh.

Возле здания есть отдельная открытая парковка для автомобилей. Говорят, мест пока всем хватает.

Рабочее пространство

Офис Competera — это 500 м²рабочего пространства. Здесь нет больших опенспейс-пространств. Офис поделен на кабинеты, где работают команды по 8-15 человек.

Как для такого офиса и количества людей в нем, здесь проблематично с митинг-румами. Их всего два: Elon Musk с шестью посадочными местами и Steve Jobs, также рассчитан на шесть стульев.

График работы гибкий, офис открыт с 7:30 утра и до последнего человека. «Время пребывания в офисе не трекается, главное — не количество отработанных часов, а результат. У каждой команды есть свои ежедневные ритуалы. Обычно ребята синхронизируются со своей командой и проводят встречи в комфортное для всех время. Некоторые сотрудники приходят в офис в 8:00 утра, чтобы не стоять в пробке, а другие наоборот добираются к 11:00 после часа пик», — утверждает представитель компании.

Количество квадратных метров на человека в рабочем помещении составляет 8 м² (по данным компании).

Отдых и вдохновение

В офисе нет привычной лаунж-зоны или игровой, но есть теннисный стол (куда ж без него ;) ), который в сложенном состоянии находится возле рецепции. В теплое время года его выносят на просторную крытую террасу, попасть на которую можно через митинг-рум Elon Musk или кабинет одной из команд.

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

На стенах офиса Competera много картин современных украинских художников. Они и в коридоре, и в митинг-руме, и в рабочих кабинетах. Это коллекция одного из сооснователей — Александра Сазонова, который находит вдохновение в современном искусстве. В офисе есть оригиналы работ Владимира Кузнецова и Ильи Чичкана.

DOU Ревизор спрашивает

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

Игорь, QA Engineer, 8 месяцев с компанией:

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

Дмитрий, Python Developer, Data Delivery Team Lead, 4 года с компанией:

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

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

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

Дмитрий, Product Designer, 9 месяцев с компанией:

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

Иногда не хватает переговорных. Две комнаты — это хорошо, но когда нужно провести user interview с клиентом, не всегда они свободны. И еще, наверное, можно, чтоб чуть больше места было. Команда растет, есть некая теснота. Но в принципе это не критично сейчас.

Дана, Junior Python Developer, 6 месяцев с компанией:

Подобаються печеньки, фрукти, фреші. Є навіть фрешниця — взагалі круто. Подобається, що всі люди, які працюють в компанії, — вони в одному офісі, просто з ними комунікувати. Тут така атмосфера — всі разом, можна просто вийти на кухню, поспілкуватися, відпочити від роботи. Це допомагає підвищити продуктивність і взагалі комфорт в офісі.

Ідей, що покращити, — в мене немає.

Стас, Python Developer, больше 2 лет с компанией:

В офисе самое важное — команда, как ни странно. Люди, которые тебя вдохновляют, помогают тебе, которым ты помогаешь. Хорошее месторасположение офиса.

Что улучшить? Как такового ничего нет. Тут и так комфортно.

Ну что, мы поехали дальше... А если вы хотите, чтобы DOU Ревизор приехал к вам, пишите нам — revisor@dou.ua

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

Следите за нами на Facebook — www.facebook.com/dourevisor

Смотрите закулисные кадры того, что не проходит нашу цензуру на Instagram — instagram.com/dourevisor

Подписывайтесь на видеоканал DOU Ревизор на YouTube.

[DOU Hobby — рубрика про нетехнічні проекти IT-фахівців: творчість, цікаві хобі та інші lifestyle-досягнення. Якщо вам є про що розповісти — пишіть на valentina@dou.ua]

Ігор Магадапрацює QA-інженером в компанії Astound Commerce в Ужгороді, Павло Генов — Front-end Developer в Svilta. Вже більше 10 років хлопці грають в рок-гурті «Триставісім», який створили з двома іншими айтішниками ще у студентські часи. Ігор грає на барабанах, а Павло — вокаліст та гітарист.

Ми розпитали в Ігоря та Павла, як було засновано гурт, як часто і де колектив виступає сьогодні та як поєднувати музику з роботою в ІТ.

Гурт «Триставісім», Ігор — другий, Павло — п’ятий зліва

— Ігоре, Павле, розкажіть про ваш гурт. Що ви граєте?

«Триставісім» — це рок-гурт з особливою енергетикою і драйвом. Рокову основу ми поєднуємо з напористими колоритними мелодіями, в яких впізнаються карпатсько-балканські мотиви.

Врешті-решт маємо суміш року, панку, дабу, ска, хіп-хопу, каліпсо та сока-ритмів із мелодикою, натхненною східно-європейською традиційною музикою: гуцульською, угорською, балканською, циганською, єврейською.

— Як було створено «Триставісім»? Чому обрали саме таку назву?

Ідея гурту з’явилася у нас та ще двох однокурсників у 2003-2004 роках.В той час ми вчились в Природничо-гуманітарному коледжі в Ужгороді за напрямком «Комп’ютерні науки». А назву ми взяли на честь номеру кабінету заступника директора коледжу і кабінету студради, де проходили перші репетиції — № 308.

Троє з нас продовжують грати в гурті і зараз. Окрім нас двох, барабанщика та вокаліста й гітариста, є бас-гітарист Андрій Шаповалов, який також працює на позиції Front-end Developer в компанії SharpMinds.

Наша історія створення гурту та його ранній період дуже нагадує історію гурту «The Offspring» — з різницею в часі рівно 20 років. І в них, і в нас однокурсники, небайдужі до рок-музики, репетиції поміж навчанням і канікулами, і перший вокаліст залишив гурт, а його місце посів гітарист :)

— З чого ви починали і як змінювалась ваша музика?

На початкових етапах нам вистачало 4 музикантів. Згодом, пишучи нові пісні, ми відчули, що їм не вистачає мелодійного забарвлення, і вирішили, що було б добре додати акордеон та духовий інструмент. Тоді ж гурту пощастило отримати колоритну мелодійну складову в лиці професійних музикантів Вови Щобака (вокал, труба) та Стаса Микульця (акордеон). Це був 2010 рік, який ми офіційно і вважаємо роком створення гурту «Триставісім».

Тоді ж і почалося наше «рок-н-рольне» життя: концерти, гастролі, зйомки, кліпи, запис альбомів :)

Спочатку ми зіграли десятки концертів для друзів і знайомих в рідному Ужгороді. Перший виїзний концерт дали в «Етноклубі» у Львові. Через 3 роки, у 2013, записали перший ЕР альбом «Перча»і з ним об’їздили всі найбільші фестивалі України: ZaxidFest, Faine misto та інші.

«Варошська туса» — живий виступ в клубі клуб «Фантом», Ужгород

Після цього брали участь у телевізійних шоу, відзняли свій перший кліп на пісню «Дислокація», почали їздити на закордонні фестивалі. У цей час зіграли приблизно 50 концертів.

У 2015 записали і видали повноформатний альбом «Лачо»і відправилися в тур Україною з його презентацією. Зняли ще декілька відеокліпів: «Варош банда», «Наша файта», «Рейнджери», «Варошська туса».

В 2017 повернулись в студію для запису другого повноформатного альбому — «Мусай». До нашого основного складу приєднався Dj Vibes.

— Новий альбом уже видано?

Ми вже презентували декілька прем’єрних пісень, але основна робота ще триває. Розраховуємо, що новий альбом побачить світ в цьому році.

«Карпатос» — останній сингл гурту

— Як часто виступаєте зараз? Де?

Для нас найактивнішим є сезон фестивалів: з кінця весни до середини осені. Фестивалі та open-air концерти — це, певно, наша стихія. На таких заходах і людям наша музика ідеально заходить, і в нас з’являється азарт «підірвати» буквально кожного. Напевно, тому нас часто запрошують відкривали головні сцени великих фестивалів, аби зі старту розколихати та розігріти публіку.

— Які найцікавіші виступи можете згадати?

У 2013 році в рамках еко-арт-фестивалю «Карпатський потяг» виступалипрямо у потязі «Івано-Франківськ — Рахів» під час руху. Такий захід протягом декількох років організовували наші друзі, музиканти з франківського гурту «КораЛЛі». Дуже авантюрна і цікава затія була. До того ж, під час нашого виступу пропала електроенергія, і ми вже догравали як могли :)

Були й інші історії з електроенергією в нашому гастрольно-концертному житті. В минулому році ми в черговий раз виступали на дуже класному й атмосферному закарпатському фестивалі Wild Wild Fest, грали на великій сцені з потужним звуковим і світловим забезпеченням. В нас був запланований півторагодинний сет, але з того всього ми повноцінно встигли зіграти всього півтори пісні — після цього через природну стихію у всій окрузі пропало світло. Але ми, в найкращих традиціях «Триставісім», таки зіграли всю програму, правда акустично і майже в повній темноті. Тільки відвідувачі підсвічували сцену телефонами і фарами з машин. І це було дуже душевно!

А ще на одному з байкерських фестивалів в Ужгороді на розігріві в «Триставісім» виступив гурт Rasmus :) Якщо вдаватись в деталі, то ми мали виступити перед ними, але підготовка їх виступу затягнулася. Але в контракті було зазначено конкретний час виступу, тому прийшлося їм виступити першими, а ми вже закрили фестиваль в якості хедлайнерів :)

Взагалі протягом історії гурту ми розділяли сцену з такими колективами, як Enter Shikari, Hollywood Undead, Zdob și Zdub, «Ляпіс Трубецкой», Noize MC, «Скрябін», «Воплі Відоплясова», «Брати Гадюкіни», «Танок на майдані Конґо», «Тартак».

— Як вдається поєднувати хобі з основною роботою в офісі? Чи багато часу займають виступи, репетиції?

Насправді, робота в IT дуже природно поєднується з виступами та музичною діяльністю. Більшість виступів, не важливо чи то клубні, чи фестивальні, зазвичай припадають на кінець тижня — п’ятницю, суботу, неділю. Залишається лише «переключити» режим у голові.

Репетируємо ми зазвичай після роботи двічі на тиждень по 2-3 години.

Звісно, є етапи, коли діяльність гурту потребує більше уваги. Зазвичай це періоди роботи над релізами, де багато часу йде на процес запису пісень, створення обкладинок та іншого графічного контенту та підготовку прес-релізів. А також — період зйомки відеоробіт гурту, в організації якого ми завжди активно задіяні.

«Щастя» — ще один сингл з майбутнього альбому

— Чи впливає якось музика на роботу в ІТ?

Робота в музичному колективі дуже добре вчить працювати і доводити справу до результату в команді людей з різними характерами, темпераментами та цілями. Тут ми додатково прокачуємо ті самі soft skills, які потім допомагають нам бути більш успішними в роботі. Розвиваємо комунікабельність, творче та критичне мислення, робочу етику, вчимось бути гнучкими та вирішувати конфлікти.

— В чому секрет успіху для музикантів? Як вийти на рівень, коли вас починають знати не лише друзі й родичі?

Ми не вважаємо себе тими, хто може давати поради про секрети успіху :) Напевно, варто як мінімум почати ділитися музикою в тих колах, де є й інші люди, окрім друзів та родичів, і робити свою справу якісно та від душі.

— Які у вас плани на майбутнє щодо музики? Чого від вас очікувати?

Плануємо дописати та видати наш другий повноформатний альбом «Мусай» і відіграти його влітку на фестивалях :)

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

Введение

«Тяжела и неказиста жизнь простого программиста»
© Диалог в баре

О программистах знают все. Даже дремучие постсоветские кумушки перестали пихать детей в повара: «Компьютерщиком будешь, в тёплом кабинете бабло зашибать». Но популярность имеет отрицательные стороны. Это на опытных есть спрос. А для начинающих ситуация обратная: на одну должность стажера в EPAM или GlobalLogic приходит до ста резюме. Чтобы попасть туда, нужно пройти семь кругов ада без гарантий дальнейшего трудоустройства. И никого не интересует, что в вузе ты хорошо учился, участвовал в самодеятельности и бегал за факультет в спартакиаде. Что же делать? Остальной текст посвящён тому, как сделать, чтобы «не было мучительно больно за бесцельно прожитые годы». Большую часть ошибок совершил я сам, остальные видел. Да-да, вот такой я дурак. Не будьте как я — учитесь на чужих ошибках.

Зачем учиться

Я спросил одного кадровика, почему все непременно требуют высшего образования.
Он ответил:
«Чтобы была гарантия, что этот человек в состоянии пять лет подряд бесплатно заниматься тупой неинтересной фигнёй».
© Анекдот

Вот ты (или твой ребёнок)... Думаешь надо решать все, когда закончишь школу? А вот фиг — поздно! Поступил в девятый выпускной класс (десятый уже поздновато, но что делать — тоже покатит) — всё, детство кончилось. Нужно думать, куда идти дальше. И, как следствие, возникает вопрос: чего ты хочешь от жизни? Ни родители, ни друзья ответа на самом деле не знают, решение за тобой! Учитывай их мнение, но думай сам.

К чему это я? Да очень просто: высшее образование нужно не всем. Если посмотреть на программу любого отечественного вуза, с удивлением обнаруживаешь: от 30% до 60% дисциплин никак не связаны с будущей специальностью. Не верите? Тогда спросите у опытного программиста: что из необходимого для работы ты изучил в вузе? Часто отвечают: «А ничего, я учился по книгам или статьям в интернете — на пары ходил, чтоб не отчислили».

Но и это «не отчислили» нужно зачастую для получения отсрочки от армии (отношение к воинской службе — это отдельный вопрос, его мы касаться не будем). У работодателей дипломы тоже не котируются. «Приходят дубы — выходит липа» — это про украинские вузы. Приведу цитату от одного из преподавателей:

«По моему опыту, сейчас заканчивают практически все. Действует негласный запрет на отчисления. Так что уходят только те, кому очень нужно (состояние здоровья, выезд на пмж за границу и т. п.) А вот с работой по специальности — сложнее. Процентов 20 — точно работают не по специальности. Остальные — как придется. Именно разработчиками работает процентов 20-25от всех выпускников, остальные — тестировщики, техподдержка и в смежных областях (типа дизайн сайтиков рисуют)».

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

Но для чего всё-таки нужен вуз? «Умение учиться, полезные знакомства» — чушь всё это! Высшее образование направлено на получение фундаментальных знаний:математика, физика, теоретические основы информатики. Далеко не каждая работа требует так углубляться: фундамент — дело хорошее, но для небольшого домика на две комнаты плюс кухня не надо рыть котлован, как для небоскрёба. И польза от котлована будет только, если небоскрёб достроить до конца. В то время как небольшой дом из пеноблока можно возвести за несколько дней и жить всю жизнь. Так и с фундаментальными знаниями — они нужны много погодя начала карьеры. Мне 37 лет, я в индустрии с 2004-гогода, но только сейчас мне понадобилась часть, остальные не нужны до сих пор!

Так что вывод из этой части статьи такой: если вопрос с военкоматом урегулирован (как вариант, собираешься служить — напомню, отношение к армии мы не обсуждаем) и ты не собираешься в околонаучные сферы — высшее образование нафиг не нужно! Вместо него, пойди на Coursera и пройди курсы в рамках какой-то специализации, например, Java, выучи английский и иди устраиваться на работу. К тому времени, как твои более зависимые от общественного мнения одногодки закончат вуз, у тебя будет два года опыта, деньги и уверенность в жизни. Уважаемые родители, убедительная просьба: не заставляйте детей пять лет протирать штаны, получая никчёмноевысшее образование, особенно если у них есть чёткий план в жизни.

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

Как поступить

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

Никаких секретов здесь нет — учиться надо. Пока не поздно браться за ум. Раньше для поступления нужно было сдавать экзамены в вузе и это было нехилым источником дохода для особ, приближённых к императору. Сейчас же вам повезло — введено ВНО. Вполне реально его сдать на 170 баллов. За третье место во всеукраинской олимпиаде дадут 10 дополнительных баллов, за второе 20, за первое 30. Максимальное количество составляет 200, и с ними, как мне шепнули на ушко, можно поступить куда угодно на бюджет. Приёмная комиссия ничего не может сделать, хоть захлебнись слюной — на процесс сдачи ВНО повлиять не в состоянии.

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

Куда поступать

«Не место красит человека»
© Слащавая и ложная поговорка

Определились вы, что институт нужен. Куда? Чем «центрее», тем лучше! Я сейчас скажу вещь, за которую меня некоторые возненавидят: в провинции жизни нет! Не верите? А посмотрите на рейтинг вузов. Образование лучше в центре, имеющий глаза да увидит!

Как вы думаете, где больше возможностей для трудоустройства? Есть ли работа скажем, в Измаиле, особенно для начинающих? Сколько за это платят и каково само качество вакансий: это будет программирование для UBS-банка в Luxoft или «мальчик-компьютерщик» на советском заводе? «Мальчик» — потому что предрассудки сильны, и девочку на завод инженером не возьмут.

Как известно, заказчики в украинском IT сплошь иностранные (местный рынок умер не родившись). Что легче: прилететь в Киев и всё или тащиться потом на поезде в Каменец-Подольский вместе с клиентом, мягко говоря офигевшим от украинского сервиса?

Далее, где больше музеев, спортивных секций, кружков по интересам, достопримечательностей? В конце концов околоайтишные мероприятия проводятся в Киеве или Херсоне? Вот и думайте, куда вам поступать. Можно, конечно, отучиться и в провинциальном универе, если выхода другого нет. Но покорять Олимп будет в разы тяжелее.

Я сам приехал из маленького города в Харьков. В кармане у меня было 100 долларов, в руках одна сумка. Кто думает, что легко начинать с нуля, когда твои одногодки уже два года работают по специальности, пусть подумает ещё раз. Приходилось и комнату с хозяйкой снимать, и брать с работы пакетик чая — булку с утра запить. Самое интересное, что я вроде бы тоже работал два года, но вот беда — уровень, достаточный для николаевских контор, был в Харькове, что называется, ниже плинтуса. Так что не повторяйте моих ошибок — отрываться от мамки гораздо легче в нежном возрасте, чем когда ты уже здоровый дядя.

Что учить, на что забить

«От сессии до сессии живут студенты весело,
а сессия всего два раза в год»
© Поговорка отчисленного из института

Как я уже писал, программа постсоветских вузов далека от совершенства. В нее напихана куча дисциплин, которые нафиг не нужны для дальнейшей работы! Возьмём, например, политологию. Конечно, для будущего программиста очень важно знать, как оно было в Древнем Риме. Или экологию: строительство «биосферы 2» весьма пригодится для программирования банковских транзакций. Постсоветская образовательная система ужасно хочет сделать студента всесторонне развитым. Проблема однако в том, что это за счёт знаний по специальности.

На что обратить внимание? Помните, я писал — вуз нужен для фундаментальных знаний. Для программиста это, во-первых, теоретические основы информатики: языки программирования, теория баз данных, подходы к разработке и так далее. Во-вторых, это разнообразная математика. В-третьих, английский. Я знаю людей, которых брали на работу только потому, что они могли общаться с иностранным заказчиком. Английский — must have!

Но не сделайте ошибку, которая привела многих талантливых людей к отчислению. Они учили только интересные им дисциплины, но сдавать-то нужно всё! Из-за зачёта по истории Украины вылететь можно так же, как из-за теории вероятностей. Вначале экзамен, потом пересдачи, потом вывешивают дацзыбао (последнее китайское предупреждение) — список на отчисление у деканата. И всё, ты уже не студент!

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

Как выбрать специализацию

«Учись студент, или будешь всю жизнь ключи подавать»
© Голос сантехника, вынырнувшего из люка с гавном

Вы, наверное, уже знаете, что программисты бывают разные, более того — в IT есть ещё тестеры, системные аналитики, менеджеры и так далее. Что делать?

В первой частия писал, что свитчерам нужно выбрать специализацию с входным порогом поменьше, чтоб легче было его перепрыгнуть. Так вот, у студента-программиста ситуация другая. Нужно выбирать специализацию с наивысшим порогом. Почему? Вы учились пять лет, потратили на это большую часть молодости. Но какой в этом толк, если работать «эникеем» в фирме «рога и копыта»?! Или вы думаете, разработчику сайтов-визиток нужна математика, знание алгоритмов поиска на графе? Используйте свои знания и выбирайте направления, недоступные простым смертным. Как минимум это должен быть разработка энтерпрайз-систем (для бизнеса) на Java или .NET. Big data (операции с большими объёмами данных) или машинное обучение (раздел искусственного интеллекта) — ещё лучше. Платят за это хорошо, потому что есть спрос и конкуренции мало — нужно много учиться.

Геймдев? Не вляпайтесь!

Есть ещё одна специализация — разработка игр. Хорошо подумайте, прежде чем ее выбирать. С ослиным упорством в игроделы ломится школота. А как же, ещё дети! Там всё блестит и сверкает, да и поиграть хочется.

Поначалу, когда в сердце юношеский максимализм, в голове надежды на светлое будущее, а ниже спины шило — всё неплохо. Но потом упс — проблемы! Работодатели прекрасно секут фишку и выжимают из одержимости вчерашних детей, что могут. Во-первых, зарплаты в играх раза в два ниже, чем в среднем по отрасли. Во-вторых, переработки! Некоторые так и говорят: хотите работать восемь часов в день — уходите из игростроя. Почитайте интервью рекрутеров фирм, которые занимаются играми. У каждого первого красной вязью звучит мысль: «Нам нужны фанаты!» О том, что избавляются от людей, которые хотят чего то ещё, помимо морального удовлетворения, стараются не вспоминать.

«Да, в аутсорсе платят больше, но я — фанат геймдева.
Снимать квартиру, есть не одни только макароны и заниматься играми — что ещё нужно?»
© Владелец игровой студии

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

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

Не витайте в облаках

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

Сейчас я побуду занудой и произнесу фразу: «А вот в наше время». Так вот, теперешним студентам очень повезло — работа в украинском IT есть весьма разнообразная. В моё время выбор был весьма ограничен (можете считать меня дедушкой, но это действительно так), однако я не воспринял этого всерьёз. Вместо изучения Java Enterprise, .NET или ещё чего-то, на что был спрос, я упрямо решал дифференциальные уравнения. В моих розовых мечтах представлялось, что где-то там, в далёком Киеве, Москве или Нью-Йорке знания теории вероятностей или языка пролог будут оценены. Как же, ведь это гораздо сложней, чем делать сайтики или писать. Прошли годы, я вышел на рынок труда и с удивлением увидел, что Common Lisp не нужен, от слова «совсем». В итоге, мне пришлось спешно осваивать что-то, с чем можно получить хоть какую-то работу.

Да, сейчас искусственный интеллект и машинное обучение испытывают подъём, но за 16 лет многое забыто, ведь работать с ними не пришлось. А если бы и пришлось — годы сильно стирают память.

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

Начало рабочей жизни

По-моему, работать по специальности нужно начинать с третьего курса. За любые деньги, пусть даже небольшие — главное опыт. Пусть это будет полдня, пусть зарплаты едва хватает на проезд — не важно! Работая как студент за небольшие деньги, вы имеете право на ошибку. Подрабатывать же начинать нужно буквально с первого курса. Когда это делать? А летом! Время между школой и поступлением будет вашими последними каникулами — вот, пожалуйста, убедитесь. Поэтому дочитавшим до этого места маленький бонус —наслаждайтесь последними каникулами. Больше такого в вашей жизни не будет! Вы уже взрослые и можете задерживаться допоздна, покупать алкоголь и презервативы. С другой стороны, не нужно задумываться о хлебе насущном — родители пока кормят.

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

Привіт! Мене звуть Роман Нога, я працюю Software Engineer у EPAM Ukraine (Львів). Вже не перший рік цікавлюся та слідкую за розробками інженерів Google. Хочу поділитися своїми дослідженнями можливостей Cloud Spanner. Хочу одразу зазначити, що наразі досвіду в продакшені з Cloud Spanner у мене немає. У статті поділюся враженнями від знайомства із сервісом і буду радий коментарям тих, хто має реальний досвід роботи зі Spanner.

Коротко про Google Cloud Spanner

У 2017 році Google анонсував Cloud Spannerяк першу горизонтально масштабовану послідовну реляційну базу даних. Він був розроблений інженерами Google для внутрішніх сервісів корпорації і зараз використовується для Google+ і Gmail. Також заявлено, що Spanner дозволяє системі масштабуватись на мільйони обчислювальних вузлів через сотні дата-центрів і працювати з трильйонами рядків даних. Мене дуже зацікавили такі обіцянки, і я вирішив розібратись трошки глибше. Звісно, я не використовував таких великих обсягів даних, як згадано вище, але результати роботи Spanner мені дуже сподобались. До того ж, як і інші сервіси Google, Spanner має дуже зручну веб-консоль для створення таблиць, надає безліч репортів про використання бази та рекомендацію, коли потрібно маштабуватись. Отже, мені сподобалось експериментувати зі Spanner, тому вирішив написати про нього.

Проблеми скейлінгу

Зазвичай зі зростанням кількості користувачів з’являються проблеми з базою. Кількість запитів зростає, і настає момент, коли збільшується перформанс. Які шляхи вирішення цієї проблеми?

Можна використовувати існуючі технології кластеризації, такі як XtraDB або Vitess для MySQL і CitusDB для Postgres. Це може вирішити проблему, але також може частково не відповідати потребам проекту, принести додаткові складнощі та витрати на підтримку, або взагалі доведеться робити редизайн аплікації.

Також можна використати горизонтальне масштабування NoSQL. Для цього застосовуємо, наприклад, Cassandra, HBase, MongoDB, DynamoDB та BigTable. Тут слід пам’ятати, що ми позбуваємось деяких реляційних функцій, таких як JOIN, які приводять до того, що параметри запиту стають більш обмеженими. База даних, яка розміщена на хості, може бути виграшним рішенням в плані підтримки, однак перехід на NoSQL може бути неможливим через редизайн аплікації із сотнями таблиць і запитів.

Яке рішення пропонує Google

Spanner — горизонтально масштабована послідовна служба реляційних баз даних:

• Повністю керована DBaaS з горизонтальним масштабом та автоматизованим шарінгом даних.
• Традиційна модель реляційної семантики та послідовності: схеми, ACID транзакції, SQL.
• Автоматична синхронна реплікація в межах та між регіонами.
• Стандартний SQL.
• Моніторинг, логування, IAM.
• Клієнтські бібліотеки популярних мов (Java, Python, Go, C#, Node.js тощо).
• JDBC драйвер для підключення до популярних сторонніх інструментів.

Spanner використовує Colossus (GFS нового покоління) як шар зберігання (storage) і алгоритм вирішення колізій Paxos. Дані в Spanner зберігаються в таблицях, які мають схему. Всі дані мають часову мітку (timestamp), що важливо для реалізації підтримки мультиверсійності даних.

Початок роботи зі Spanner

Google надає 300 у. о. на рік під час реєстраціїусім для використання всіх своїх сервісів. Цього насправді більш, ніж достатньо, щоб розібратись і спробувати попрацювати з Spanner-ом та іншими сервісами. Після реєстрації в консолі ми можемо створити наш інстанс, де ми вказуємо ім’я інстансу, ID, регіон та кількість нодів, які ми хочемо.
Після створення інстансу формуємо нашу базу даних. Для цього ми вказуємо ім’я нашої бази та починаємо створювати схему бази.

Перед початком роботи з базою нам необхідно все «засетапити». Google надає туторіалдля різних популярних мов програмуванні. Після сетапу, у випадку .NET, нам необхідно заінсталювати Google.Cloud.Spanner.Data через NuGet.

Далі все просто: створюємо connection string ($"DataSource=projects/{projectId}/instances/{instanceId}"), формуємо SpannerConnection та робимо звернення до бази. Spanner підтримує всі необхідні запити, такі як: SELECT, JOIN, GROUP BY, HAVING.

Cloud Spanner підтримує прості типи даних, такі як INTEGER, а також більш складні типи — ARRAY та STRUCT. Максимальний розмір значення стовпця — 10 Мб.

Нововведеням в Spanner є interleaved table. Interleaved table використовується, коли необхідно мати доступ до рядків двох таблиць для заданого первинного ключа (кожен раз, коли ми отримуємо дані рядка одної таблиці, нам також потрібно отримати доступ до рядків другої таблиці), або іншими словами, це заміна звичайного foreign key. Буде корисним, наприклад, при CASCADE DELETE.

Для створення таких таблиць нам необхідно в таблиці, що наслідується від базової, вказати два PRIMARY KEY, нашої таблиці та батьківської.

CREATE TABLE Singers (
  SingerId   INT64 NOT NULL,
  FirstName  STRING(1024),
  LastName   STRING(1024),
  SingerInfo BYTES(MAX),
) PRIMARY KEY (SingerId);

CREATE TABLE Albums (
  SingerId     INT64 NOT NULL,
  AlbumId      INT64 NOT NULL,
  AlbumTitle   STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId),
  INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

Отримаємо такий вигляд:

Image source

Також Google гарантує, що всі зміни у схемі бази, наприклад, ALTER TABLE Singers ADD COLUMN Age INT64;будуть відбуватися на льоту (zero-downtime).

Такі заяви Google підтверджує тим, що Spanner тестувався більше 5 років на їхніх продуктах (GooglePlay, AdWords).

Як працює Google Spanner

На малюнку зображено інстанс з трьома нодами і трьома репліками в трьох зонах. У кожній зоні є повна копія даних. Кожна Cloud Spanner нода забезпечує 10 тисяч QPS запитів та 2 тисячі QPS записів і має ліміт в 2 TiB/ноду.

Є можливість моніторингу за допомогою Google Stackdriver. Ну і найцікавіше, для масштабування достатньо додати ноду. Як ми знаємо, якщо нода падає, вона піднімається автоматично за лічені секунди. Тому, якщо ми використовуємо більше ніж одну ноду для Spanner, наша база буде завжди онлайн.

Cloud Spanner використовує Data Splits:

Під час звернення до бази даних репліка запитує в лідера, чи має актуальні дані:

SELECT * FROM Table WHERE Name = ‘DOU’;

1. Запит.
2. Чи можна читати?
3. Так.
4. Відповідь.

На малюнку зображено, які кроки будуть відбуватись в типовій ситуації, коли ми щось читаємо, а потім пишемо щось на основі того, що вичитали.

1. Читання.
2. Лок.
3. Відповідь.
4. Запис.
5. Запис в репліки.
6. Підтвердження запису від реплік.
7. Зняття локу.
8. Відповідь.

TrueTime API

Реалізація транзакцій стала можлива завдяки програмному інтерфейсу TrueTime API. TrueTime API надає глобальний час та деяку невизначеність — TTinterval. Для розподілених систем дуже складно гарантувати миттєвість відгуку вузлів, що важливо для забезпечення узгодженості даних у розподіленому сховищі.

Коли замість точного часу повертається деяких часовий інтервал виконання двох конкурентних транзакцій, то порівнюються TTinterval цих транзакцій. Якщо TTinterval транзакцій не перетинаються, то ми можемо точно знати, яка з транзакцій повинна бути виконана перша. Якщо TTinterval перетинається, то визначити, яка транзакція має виконуватись перша, можна з певним ступенем ймовірності.

Рекомендація Google, коли використовувати Spanner

Звісно Google не рекомендує використовувати Spanner для всіх типів проектів. Найкраще використовувати його, якщо у нас є структуровані та реляційні дані та коли нам необхідне горизонтальне масштабування.

Недоліки та обмеження

Cloud Spanner не є дешевим. Очевидно, що через ціну він не підійде на будь-який проект.

Cloud Spanner рекомендує використовувати interleaved table для перформенсу та для каскадного оновлення та видалення. В іншому випадку каскадні операції не будуть виконуватись.

Ключі таблиці не можуть змінюватися. Ми не можемо додавати key column до існуючої таблиці або видалити з існуючої таблиці. Це означає, що якщо ми хочемо змінити PK таблиці, то нам доведеться дропнути та створити заново цю таблицю.

Перенесення ворклоаду, наприклад з MySQL, вимагає великих зусиль, як у дизайні, так і в імплементації, для забезпечення ефективної реалізації. Помилки в дизайні схеми можуть призвести до даунтаймів.

Підсумки

Google Spanner є новим типом БД (NewSQL), який об’єднує в собі два світи SQL та NoSQL. Він надає можливість для обробки величезної кількості транзакцій. При цьому гарантує цілісність даних з можливістю їх розподілення по всьому світі без обмежень розміром сховища, що вражає. Хоча наразі технологія має відносно невеликий список клієнтів та побудованих на її основі сервісів, але вона заслуговує на увагу широкого кола ІТ-спеціалістів.

Корисні посилання

Google Cloud Spanner
Spanner. NewSQL хранилище от Google
Google запустила бета-версию Cloud Spanner — СУБД поколения NewSQL
Работа с временем в Google
Introducing Cloud Spanner: a global database service for mission-critical applications

Привет, меня зовут Андрей, я Data Science инженер в SMART business. В этой статье я расскажу, как мы для сервиса такси Uklon ускорили время подачи машины и оптимизировали расчет стоимости с помощью машинного обучения. Ниже пойдет речь о реальном кейсе применения ML в бизнесе, который показал результаты.

Про конкуренцию и мотивацию

Только в 2016 году в Киеве появилось сразу несколько мощнейших компаний-перевозчиков: сперва американский Uber, за ним — компании из России («Яндекс.Такси»), Словакии (Hopin), Эстонии (Тaxify), а также несколько компаний поменьше (украинских и иностранных), что, естественно, повлекло за собой обострение конкуренции в сегменте вызова такси и закрытие многих традиционных служб.

Жители крупных городов все активнее заказывают такси онлайн. Если в начале 2016 года доля таких заказов была 5-10%из общей массы, то через год их стало уже в два раза больше. Ожидаемо, что доля онлайн-заказов на рынке будет только увеличиваться. Чтобы оставаться на плаву, некоторые традиционные службы такси начали вводить и у себя возможность заказа такси через сайт или мобильное приложение. Первым онлайн-сервисом вызова такси в Киеве стал Uklon. Сегодня компания получает в среднем около 3 тысяч запросов на вызов в день. Главная фишка в том, что цена на поездку — управляемая. То есть ты можешь назначить любую цену заказа и ждать, пока кто-то из водителей подтвердит её.

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

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

Упор был сделан на улучшение двух показателей: ожидаемое время прибытия такси (Estimated Time of Arrival — ETA) и процент выполнения заказа (или так называемый «процент вывоза»). Время прибытия такси влияет на то, будет ли клиент дожидаться подачи машины или отменит заказ и воспользуется другим сервисом. Процент выполнения заказа — это KPI, который в целом характеризует популярность сервиса и влияет на уровень продаж и долю рынка.

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

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

Переходим к решению

Используемые данные для работы модели

Для проверки гипотез и дальнейшего построения модели были использованы наши закрытые данные — таблица с историей заказов и поездок клиентов, размером около 20 Гб. Эта таблица содержала более 20 миллионов записей с 20 характеристиками (полями) поездок, которые в течение работы дополнялись информацией о водителе, автомобиле и клиенте.

Также использовались метеорологические данные, которые мы собирали из двух источников: сайт с открытыми данными от NASA и метеостанции трёх киевских аэропортов.

Описание работы модели (алгоритма)

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

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

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

Для разделения города по регионам вывоза клиентов и точки назначения, а также для сегментации клиентов, мы использовали кластеризацию (k-means алгоритм).

Исходные точки и случайно выбранные начальные точки.	Точки, отнесённые к начальным центрам. Разбиение на плоскости — диаграмма Вороногоотносительно начальных центров.	Вычисление новых центров кластеров (ищем центр масс).	Предыдущие шаги повторяются, пока алгоритм не сойдётся.

Также использовали классификацию и регрессию (Random forest алгоритм) для следующих задач:

• определения новой точки вывоза и точки назначения в созданный ранее городской кластер;
• определения сегмента клиента;
• прогноза цены.

Этапы работы над моделью

Отобрав наборы данных и загрузив их в базу данных в Azure SQL Database service, мы взяли часть данных для тренировки модели в Azure Data Science Virtual Machine. Для разных задач использовали разные модели, например, для кластеризации города или сегментации клиентов использовался k-means алгоритм, для прогнозирования цены — дерево решений (к слову, сейчас дерево решений для определения оптимальной цены содержит около 300 ветвей). После тренировки модели мы взяли стандартные параметры, которые задает модель, и проверили работу модели на определенной выборке данных. Результат был удовлетворительным.

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

Далее полученная в Azure Data Science Virtual Machine модель, которая решает задачи клиента, была развернута в производственной среде в виде веб-сервиса — а именно в Azure Machine Learning web service. Схема работы решения такова: потенциальный пассажир создаёт заказ в мобильном приложении с параметрами точки вывоза и точки назначения, на основе чего рассчитывается стандартная цена поездки по километражу, и эти входные данные отдаются через сервер «Уклона» к развёрнутому веб-сервису. Далее модель просчитывает оптимальную цену для данной поездки, при которой пассажир не будет торговаться, а таксист наиболее вероятно возьмёт заказ. Просчитанная моделью цена возвращается на сервер «Уклон» и уже оттуда — в клиентское приложение, где пассажир может видеть предложенную цену для данной поездки. Скорость просчёта оптимальной цены настолько высока, что пользователь мобильного приложения не замечает никаких задержек.

Изменение модели после первых тестовых запусков

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

• подбор количества кластеров в городе;
• подбор временных интервалов за день и их количество;
• добавление характеристик поездки (за город, в аэропорт);
• добавление классов автомобиля;
• добавление параметров по погоде;
• работа с сегментами клиентов.

Результаты работы модели

Созданная нами модель была запущена в эксплуатацию параллельно с существующим ценообразованием с использованием динамического коэффициента, и заказы клиентов распределялись 50/50 на обе модели.

В результате работы новой модели улучшились показатели выполнения заказов и времени ожидания — собственно, те параметры, на которые мы нацеливались в начале проекта. В сравнении с прошлой моделью эти показатели выше на 5-15%.

При использовании новой модели машина находится на 18 секунд быстрее. При количестве около 3000 заказов в день — это около 15 часов экономии времени для всего города. Если брать в расчёт среднюю семью, которая ездит на такси приблизительно 4 раза в неделю, экономия времени составляет около 1 час в год.

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

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

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

В выпуске: поддержка HTTPS Proxies в Go 1.10, состоялся релиз vim-go 1.17, туториал по multithreading in Go, коллекция бенчмарков производительности Go пакетов и алгоритмов.

Новости

Go 1.10.1 and Go 1.9.5 — изменения коснулись компилятора, runtime, go command, и archive/zip, crypto/tls, crypto/x509, encoding/json, net, net/http, net/http/pprof пакетов.

Поддержка HTTPS Proxies в Go 1.10

Caddy 0.10.11 — теперь с распределенным Auto-HTTPS и Service Discovery.

Новость для тех, кто знает, как выйти из vim. Состоялся релиз vim-go 1.17.

Почитать

Использование Go в качестве скриптового языка в Linux

Туториал по разработке URL Shortener при помощи Go и AWS Lambda

Туториал по разработке Blockchain Mining алгоритма — не пытайтесь на этом разбогатеть)

Интеграция Go Service с systemd

TDD подход при разработке на Go

Коллекция бенчмарков производительности Go пакетов и алгоритмов

Туториал по разработке Amazon Alexa Skills

Туториал по использованию Service Object Pattern

Профилирование Go приложений при помощи Flamegraphs

Immutable структуры данных, реализованные с использованием интерфейсов

Структуры данных: Linked Lists

Multithreading in Go — Туториал

Goroutines, Channels, and WaitGroups

Data Races и как с ними бороться

Туториал по разработке Slack ботов

Все еще недостаточно информации для чтения? Gopher’s Reading List.

Посмотреть

Advanced Testing with Go

Разработка REST API используя ORM

The Basics of Protocol Buffers — взгляд на один из самых основополагающих компонентов gRPC.

Performance and Scaling Techniques using Go Assembly

Инструменты и библиотеки

Goloader — загрузка и выполнение Go кода в runtime.

git-sizer — вычисляет различные показатели размера для git-репозиториев и помечает те, которые могут вызвать проблемы.

GitLeaks — проверяет git-репозитории на содержание секретных ключей.

Skaffold — command line инструмент, который облегчает непрерывную разработку приложений Kubernetes.

chasquid — SMTP Server. Еще в beta, но уже поддерживает TLS, проверку SPF и другие мощные фичи.

one-file-pdf — минималистичный PDF-генератор

Slack-Term:— Terminal-Based клиент для Slack

go-fitz — Обертка для MuPDF, который может извлекать страницы с PDF/EPUB/XPS.

go-mp3 — MP3 decoder

gRPCurl — сommand-line инструмент для коммуникации с gRPC сервером.

git-chglog — сhangelog-генератор.

Guard — высокопроизводительный Circuit Breaker и Proxy сервер. Proxy сервер основан на fasthttp.

Now — Toolkit для работы с временем.

gorush — Push Notification Server поддерживающий APNS и Firebase.

Go Date Parser — парсит даты используя state machine для поиска формата.

Gitkube — инструмент для разработки и развертывания Docker images в Kubernetes при помощи git push.

← Предыдущий выпуск: Go дайджест #1.

У випуску: як використовувати Composer ефективно, curly bracket, PHP 7.2.1, функція monotonic timer.

Статті

Перелік крутих, але маловідомих фіч PhpStorm

Wordpress розробники, перестаньте використовувати старі версії РHP

Перший RFC для PHP 8.0 прийнято

Modern PHP Without a Framework

Перелік крутих статей про DDD:

Domain-Driven Design, part 1 — Language
Domain-Driven Design, part 2 — Model
Domain-Driven Design, part 3 — Simplify Object Model
Domain-Driven Design, part 4 — Implementation
Domain-Driven Design, part 6 — Doctrine Repository
Domain-Driven Design, part 7 — Alternative Relational Database Mapping
Domain-Driven Design, part 8 — Services and Factories

Релізи

PHP 7.2.4 Released

PHP 7.1.16 Released

PHP 5.6.35 Released

Ubuntu 18.04 буде поставлятись з PHP 7.2

PhpStorm 2018.1 is released

Zend Expressive 3

Codeception 2.4 released

Yii обновив сайт

Цікаві бібліотеки, проекти

Таск менеджер (типу Gulp) на PHP reisraff/phulp

Jsfiddle, але для PHP

Різне

Для тих, хто цікавиться вивченням нових технологій та розширенням компетенцій. Тестуємо з топовими українськими розробниками формат онлайн-інтенсиву по Front-end. За 6 тижнів опануємо основи та напишемо зі студентами їх власний чат на React. Doge.codes — тут всі деталі.

Як зруйнувати кар’єру за 10 хвилин

NomadPHP комьюніті розробникив зі всього світу

WordPress is used by 30.4% of all the websites, that is a content management system market share of 60.1%

Drupal core — Highly critical — Remote Code Execution — SA-CORE-2018-002

Laravel is hiring

← Попередній випуск: PHP дайджест #11

Ежегодно мы составляем портрет украинского айтишника — узнаём профессиональный опыт, привычки, образ жизни. Пришло время посмотреть, что изменилось за прошедший год.

Результаты узнаем в мае.

Прямая ссылка на анкету — goo.gl/forms/TIy5P4HQAZGWbr2A3