Моя історія переїзду доволі проста. Компанія Conscensia, де я займаю посаду Head of Delivery (львівського офісу), відкрила новий розробницький центр в Румунії, а саме в столиці країни — Бухаресті. Мені випала нагода стати частиною команди, що займалася набором персоналу і налагодженням робочих процесів практично з початкової стадії. Через це і потрібно було переїхати. Забігаючи наперед, скажу, що після року проживання за кордоном я з сім’єю повернулася у Львів, але тепер про все по порядку.

Документи для переїзду і формальності

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

Загалом тема переїзду за кордон є далеко не новою. Я не претендую на оригінальність чи a lot of practical details про те, як отримати відповідні дозволи і всю супутню бюрократію — краще цей процес довірити професіоналам. У моєму випадку це була досить тривала процедура в кілька етапів для мене, чоловіка і дитини. Румунія входить до ЄС, і відповідно всі формальності є подібними до інших країн. Щоб бути працевлаштованим у Румунії, потрібно зібрати стандартний набір супутніх документів, перекладених і проапостильованих, разом з запрошенням (офером) на роботу, візу певного типу (не туристичну), яка дозволяє працевлаштування, і відповідний дозвіл на роботу. Краще користуватися послугами компаній, які допомагають з цим. У нашому випадку це були спеціалісти компанії Deloitte, які не тільки координували весь процес, але й особисто супроводжували в походах в різні державні установи, на кшталт immigration office. Закриттям усіх робочих документів також займалися працівники цієї компанії.

Недаремно бюрократія згадується в більшості джерел про Румунію. Типові труднощі, до яких потрібно бути готовими — це різні затримки при отриманні дозволів, від яких багато чого залежить. Також потрібно брати до увагу типову румунську «розслабленість» працівників певних установ. Наприклад, перша спроба відкрити рахунок в одному з банків, мережа якого поширена по всій Європі і також присутня в Україні, завершилась невдало. У нас взяли всі необхідні документи «для опрацювання» і ввічливо пообіцяли, що зателефонують, коли буде все готово. Звичайно, ніхто нам так і не зателефонував, на всі наші спроби якось дізнатися про статус заяви ми отримували однакову стандартну відповідь: «Your case is in queue for further process at other department, we don’t know when to expect an answer. We’re sorry etc». Після 3-4тижнів очікування рахунок все-таки відкрили, але в іншому банку. Причому там його відкрили за годину, і з відділення ми вийшли гордими власниками іменних visa-карток.

У більшості румунських ІТ-компаній весь штат складають наймані працівники. Це веде за собою всі супутні операційні процедури і практики, які є більш формалізованими, ніж для контракторів.

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

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

Мова

Мова — це окреме питання :) Румунська мова належить до романської групи. Тому тим, хто знає італійську чи іспанську, буде легше зрозуміти румунську на перших порах і вивчити (якщо буде таке бажання). Якщо залишатися жити в Бухаресті довше, то однозначно знати мову — це must. Це актуально і для будь-якої іншої країни. Але загалом у самій столиці у спілкуванні можна обходитися англійською мовою. На відміну від України, тут говорять базовою англійською в магазинах, на заправках тощо. Але, щоправда, цього не скажеш про менші містечка і села.

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

Специфіка ІТ-ринку країни

Румунське ІТ-середовище добре розвинене і продовжує розвиватися шаленими темпами, незважаючи на еміграцію топових румунських розробників в Західну Європу. Міста з найбільшою кількістю ІТ-компаній — це Бухарест, Клуж-Напока (місто з першим ІТ-кластером в країні), Ясси і Тімішоара. В Бухаресті представлені такі гіганти, як Microsoft, Oracle, IBM та ін. З глобальних гравців з ринку аутсорсу є Luxoft та безліч інших сервісних та продуктових компаній.

Середні зарплати в Румунії невисокі, тож оплата праці типового розробника вважається вищою за середню. Загалом вилки приблизно подібні до тих, що є в Україні. Тільки з урахуванням податків сума на руки виходить меншою.

Багато з розробників володіють не тільки англійською, але й однією або двома іншими іноземними мовами — французькою чи німецькою. Італійську румуни розуміють by default. Старше покоління знає ще й російську.

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

• flexible робочі години (у тому числі робота з дому);
• скорочені п’ятниці (привіт, Сonscensia:));
• так звана «13 зарплата»;
• медичне страхування, приватні пенсійні страхування та накопичення, абонементи в зал, басейн, обіди тощо;
• паркомісця — враховуючи, що запаркуватись у центральній частині міста майже нереально, у певних випадках цей бенефіт може бути одним з ключових :)

Погодьтесь, непогано.

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

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

Житло в Бухаресті

Помешкання ми почали шукати наперед, але не дуже задовго до переїзду. За кілька тижнів до узгодженої дати ми приїхали в місто, щоб знайти житло. Ми скористались послугами однієї з місцевих ріелторських агенцій, яка дуже допомогла не тільки з вибором квартири, але й ознайомила з містом, рекомендованими районами для проживання тощо. Загалом пристойні апартаменти можна знайти за сумму починаючи від 400-500 EURза місяць (не враховуючи комунальні). У нашому випадку вийшло трохи дорожче тому, що переїздили з дитиною (4 роки на той час) і собакою. Тому, відповідно, критерії пошуку ускладнювались — важливою була не тільки локація і зручність добирання в офіс, а також наявність парку відносно недалеко, дитячих майданчиків та місць для прогулянок з собакою.

Вид з вікна орендованої квартири

Витрати

Приблизна таблиця типових витрат на сім’ю з трьох людей на місяць виглядає так:

Загалом: 1950-2650 EUR

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

Особливості міста

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

Географічно місто поділене на сектори — всього їх 6. Більшість бізнес-центрів, включаючи офіси багатьох ІТ-компаній, знаходяться в північній і центральній частині міста (Pipera, Floreasca). Тому ці частини міста найбільш популярні, розвинуті і дорогі, якщо порівнювати з іншими. Також це типові райони, де мешкають експати, яких в Бухаресті ой як багато. Вечорами, прогулючись парком Герастрау (найбільший парк міста з озером), можна почути різні мови — англійську, французьку, російську і багато інших. Української майже ніколи не чула за весь час проживання там.

Транспорт

Деколи мені здавалося, що автомобілів у місті більше, ніж людей. Автівок дійсно багато, вони припарковані всюди й іноді абияк. Величезна кількість машин, звичайно, означає довжелезні затори, причому по всьому місті. Особливо страждає центральна частина міста, де трафік напружений цілий день. Ми мали своє авто, але використовували його переважно на вихідних — для поїздок за продуктами або за місто. Протягом тижня на роботу я їздила на метро або ж ішла пішки при хорошій погоді (30-40 хв).

Містом курсують автобуси (переважно великі і комфортні), тролейбуси, трамваї (багато з них ретро). А ще є метро, яке дуже рятує ситуацію. Офісний планктон (такий, як я) переважно добирається на роботу на метро, яке в години пік забите. Є велодоріжки, але далеко не по всьому місту. Найбільше і найкраще покриття в центральній частині міста. Таксі відносно недороге і популярне, але стиль водіння не для людей зі слабкими нервами. Взагалі до манери їзди в Бухаресті треба звикнути. Місцеві мешканці називають цей стиль «defensive driving», я б його віднесла більше до «aggressive driving». Потрібно бути дуже уважним при водінні, адже це повна протилежність спокійній, розміреній їзді, до якої всі звикли в Західній Європі.

Повітряне сполучення доволі хороше. За 15 км від столиці в Отопеніє міжнародний аеропорт Bucharest Henri Coandă. Доступні квитки на найбільш популярні лоукостери Wizz Air, Ryanair. Також присутні інші найбільш поширені авіаперевізники, тому подорожувати досить зручно.

Медицина

Ситуація з державною медициною, як кажуть місцеві мешканці, залишає бажати кращого. Але тут поширені приватні клініки, в яких ситуація дещо ліпша. Медичне страхування (для працівника чи всієї сім’ї) є частиною benefit package, який пропонують більшість компаній. Я з сім’єю користувалася поглугами клінік Medicover. Також рекомендують мережу Regina Maria. Звичайно є ще й інші, але ці дві найбільш поширені.

Клімат і географічні особливості

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

Влітку на вихідних місто стає практично пустим. Це майже традиція — на вихідних вибиратися на Чорне море, до якого близько 230 км від Бухареста по магістралі. Констанца — найбільше місто на узбережжі, туди їдуть переважно з дітьми. Для більш активного відпочинку молодь їде далі на південь. Містечко Вама-Веке, що майже біля кордону з Болгарією, — одна з найпопулярніших локацій для активного пляжного відпочинку та літніх нон-стоп вечірок. До речі, у довшу класичну відпустку «до моря» румуни переважно їдуть у Болгарію або в Грецію.

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

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

Зима схожа на ту, до якої ми звикли в Україні, тільки, мабуть, трішки коротша.

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

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

Висновки

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

Їхати чи не їхати кудись — це справа індивідуальна. Моя історія закінчилася тим, що після року роботи в румунському офісі я повернулася в наш офіс у Львові. Це однозначно цінний досвід, який вплинув не тільки мої погляди на роботу, але й на життя загалом :)

У рубриці DOU Labsми запрошуємо IT-компанії ділитись досвідом власних цікавих розробок та внутрішніх технологічних ініціатив. Питання і заявки на участь надсилайте на editors@dou.ua.

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

Ідея

У рамках проекту MacPaw Labsкожну другу п’ятницю місяця, співробітники компанії можуть присвячувати власним проектам. Один з них, Project Green, функціонує вже протягом року. Завдяки цьому проекту в MacPaw встановили спеціальні сортувальні баки, організували серію прибирань #CleanMyCity та замінили пластикові стаканчики на скляні.

Останнє досягнення проекту — мобільний застосунок «Сортуй», що спрощує сортування. Застосунок підкаже, яке сміття переробляється, а яке ні, та покаже маршрут до найближчих пунктів прийому вторсировини.

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

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

Коли ми спробували знайти подібні застосунки, то виявилося, що вони існують, однак лише для якихось окремих станцій сортування. І розповсюджені вони у США та Європі. Також є ігри для дітей, що показують, який вид сміття до якого ящика кидати. «Іграшки-сортери», іншими словами. До аналогів «Сортуй» в Україні можна віднести мапи на кшталт «Епохи», у яких зібрані мережі та пункти прийому вторсировини, або Львівський проект Garbage31, який розповідає про способи сортування речей, які ми використовуємо щодня.

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

На розробку пішло більше 7 місяців. Складно підрахувати усіх, хто брав участь у створенні «Сортуй». У проекті задіяні четверо розробників (двоє на Android, двоє на iOS), два дизайнери, люди, які займаються наповненням бази, тестуванням, а також усі небайдужі до проблем сортування.

Команда, що працювала над проектом

Реалізація

Android-версія

Android-версію писали на мові Kotlin, а для побудови архітектури обрали шаблон проектування MVVM — цей підхід активно підтримує Google. Він дозволяє зв’язувати елементи View із властивостями та подіями абстракції представлення ViewModel. Характерною рисою шаблону є двостороння комунікація із View.

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

У поточній реалізації в нас немає анімованих переходів між екранами. У майбутньому теж плануємо їх додати.

Під час розробки ми використовували такі засоби:

• Android Architecture Components — Live Data, ViewModel та Room Persistence Libraryвід Google (для роботи із базою даних SQLite);
• Retrofit — для запитів та роботи з HTTP;
• Anko — з цією бібліотекою код виглядає більш декларативно;
• Mixpanel — для збору аналітики про поведінку користувача в застосунку;
• Fabric — для збору аналітики про поведінку самого застосунку: можна дізнатися, скільки нових користувачів, активних користувачів, визначити retention та crash’і;
• Для збору зворотного зв’язку використовували звичайну відправку по email та HockeyApp. Їхня feedback-форма дуже гнучка в кастомізації.

Ідея додати до функціональності мапу виникла під час розробки. У «Сортуй» мапа, на якій відмічені найближчі пункти прийому вторсировини, реалізована з допомогою Google Maps JavaScript API та роздається для обох мобільних платформ із одного сайту. Такий підхід дозволив нам зекономити купу часу на розробку мапи. До того ж він дає можливість оновлювати дані, не оновлюючи сам «Сортуй». Незалежно від того, поставив користувач оновлення чи ні, актуальна мапа завжди буде у застосунку. Звичайно, на більш старих пристроях швидкість роботи не зовсім задовільна: можуть з’являтися помітні підторможування, оскільки браузерна версія Google Maps не так добре оптимізована для мобільних пристроїв, як Google Maps SDK для iOS/Android. Цілком можливо, що згодом ми перейдемо на використання цих засобів.

Для тестування використовували стандартні засоби Google Play та Espresso. Спочатку тестували друзі та колеги у закритій альфі. Далі був короткий етап бета-тестування і реліз.

Зараз у нас два канали поширення — публічний канал та бета-канал, на який користувачу дозволяє підписатися Google Play. У нашому бета-каналі наразі 89 тестувальників. Вони готові до нестабільних версій, тому ми можемо спочатку протестувати оновлення в цьому каналі, а вже потім випускати його публічно.

iOS-версія

На початку розробки ми чітко виділили модельні об’єкти та UI-елементи. Оскільки програма невелика, підійшов класичний MVC. У подальшому це нам дозволило модифікувати структуру бази даних, підправивши лише кілька модельних класів, без впливу на основний інтерфейс.

Сама база даних зберігається у вигляді JSON-файлів. Це дає змогу легко її читати і правити, якщо потрібно. Одна копія БД зберігається всередині застосунка, який розповсюджується через AppStore. Іншу копію час від часу викачуємо з інтернету. Серед даних бази також зберігається її поточна версія та версія сумісності. Версія сумісності потрібна для того, щоб програма знала, чи зможе вона безболісно (без падінь) розпарсити дані. Для зберігання онлайн-копії бази використали системний кеш (NSURLCache клас), який вміє зберігати відповідь сервера на той чи інший запит. Тому логіка роботи з онлайн-базою є простою.

У потрібний момент йде запит на сервер:

• якщо виникла проблема з доступом до інтернету або сервер відповів кодом 304 (Not Modified), використовуємо раніше закешовані дані;
• якщо отримали нові дані, зберігаємо їх для цього запиту.

Усі динамічні ілюстрації, які використовуються в програмі (іконка вигляду сміття, іконка контейнера), зберігаються всередині програми, проте також передбачена можливість завантаження їх з онлайн-ресурсів. Для цього база містить поле iconURL.

Майже вся програма написана на Swift, за виключенням тих Objective-C файлів, які були втягнуті як вже винайдений велосипед, з інших власних або third-party проектів. Для аналітики, збору крешів, фідбеків і т. д. обрали Mixpanel та HockeyApp, оскільки вони підтримують iOS + Android, а також є безкоштовними (хоча б для невеликої кількості даних), оскільки цей проект є некомерційним.

Результати

Наразі «Сортуй» містить правила прийому вторсировини таких операторів, як «Україна без сміття», «Київміськвторресурси» і ТОВ «ВТОРМА ЮА». Їхні пункти розміщені у Києві, Львові, Миколаєві, Херсоні, Чернігові, Білій Церкві, Броварах, Ніжині та Прилуках. Також у застосунку є універсальні правила сортування сміття.

Серед подальших планів:

• додавання нових пунктів прийому вторсировини;
• масштабування на інші міста України;
• наповнення бази новими видами відходів;
• розробка сканеру штрих-кодів.

Завантажуйте застосунок на Apple Storeта Google Play.

В этот раз DOU Ревизорпобывал в одном из трех киевских офисов Intellias — аутсорсинговой компании, основанной 16 лет назад во Львове. Сегодня в Intellias 1140 специалистов во Львове, Киеве, Одессе, Харькове и представительском офисе в Берлине. В частности, киевские офисы насчитывают 305 технических специалистов из 350 человек.

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

Офис компании расположен на 5-7этажах бизнес-центра по адресу ул. Кирилловская, 15, недалеко от станций метро «Контрактовая площадь» (7 мин. пешком) и «Тараса Шевченко» (11 мин. пешком).

Поблизости неплохой выбор мест для обеда:

• Кафе «Picnic», расположенное в здании бизнес-центра. Средний чек ≈ 180 грн. Для специалистов Intellias действует 15% скидка.
• Ресторан «Старий Львів» рядом с БЦ. Средний чек ≈ 150 грн, бизнес-ланч — от 59 грн.
• Кафе «Menya Musashi» — в шести минутах ходьбы от офиса. Средний чек ≈ 250 грн.
• Супермаркеты «Сільпо» и «Billa» находятся в семи минутах ходьбы.

С парковкой здесь не самая лучшая ситуация. В здании бизнес-центра расположен подземный автопаркинг всего на 15 мест. Машину также можно оставить на автостанции «Подол» в шести минутах ходьбы от бизнес-центра или на парковке другого офиса Intellias по адресу Кирилловская, 39. По словам специалистов компании, им часто приходится искать паркоместо на близлежащих улицах. Для велосипедов есть 10 мест на улице и 10 — на крытой парковке.

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

Общая площадь офиса составляет около 1800 м².

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

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

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

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

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

Из дополнительных удобств — «фан-румы» с бильярдными и теннисными столами, музыкальными инструментами, салон красоты, детская комната и массажный кабинет.

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

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

С 15:00 до 19:00 в офисе открыта детская комната с няней. Комната оборудована для детей от 3 до 12 лет. Для малышей — игрушки, наборы для творчества, телевизор с мультфильмами, для ребят постарше — книги, Xboх и «уголок школьника», где дети могут выполнять домашние задания. Также в комнате всегда есть вода, фрукты и печенье для перекуса. В детской установлена камера видеонаблюдения, к которой родители, по запросу, могут получить доступ.

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

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

Анна, Lead Test Engineer, 2 года с компанией:

В офисе мне нравится расположение столов и освещение. Помещение очень светлое, в нем приятно находиться. Столы удобные, да и техника у меня никаких нареканий не вызывает. Удобно, что не нужно никуда бежать за едой, если забыл какой-нибудь судок дома или просто нет настроения выходить на улицу. Хотя мы с командой часто выбираемся куда-нибудь вместе на обед. До офиса легко добраться с Соломенки как на общественном транспорте, так и на машине. Расположение довольно удобное. Единственное, не знаю, как обстоят дела с парковками. Что касается улучшений, то в офисе было бы неплохо добавить туалетов. Людей много, а кабинок мало, как для такого пространства. И няня в детскую комнату приходит только после обеда. Но это уже такие мелочи, как из анекдотов о «зажравшихся айтишниках».

Александр, Lead DevOps Engineer, 1 год с компанией:

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

Евгений, Senior Java Developer, 1 год с компанией:

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

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

Андрей, Senior DevOps Engineer, 2.5 года с компанией:

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

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

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

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

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

Фото: Леся Коверега.

Від редакції: у рубриці DOU Booksспеціалісти розповідають про 5 своїх улюблених книжок — ті, які змінюють світогляд та корисні читачам-колегам.

[Микола Котляренко — бізнес-аналітик за фахом, посадою і покликанням; захоплюється архітектурою, математикою та економікою]

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

• Читати, по можливості, за допомогою електронної книги. Ці пристрої мають спеціальний дисплей, вбудований перекладач, можливості робити виділення та, особливо корисно, підсвітку. Це пришвидшує читання, збільшує кількість присвяченого книгам часу та суттєво зменшує втому очей порівняно зі звичайним монітором.
• Читати декілька книг паралельно. Легше, коли всі вони з різних категорій, наприклад, як з переліку нижче. У результаті менше згаяного часу на прокрастинацію, бо завжди знайдеться щось, що більше цікавить або пасує під настрій саме зараз.
• Сформувати дорожню карту, мій приклад за посиланням. Це допомагає тримати загальний вектор руху, фокусуватися на необхідному, слідкувати за прогресом та розподілити навантаження у часі, читаючи певну категорію у визначений час, наприклад, лишаючи наукову літературу на вихідні.
• Виставляти пріоритети для наукової та навчальної літератури. Починати читати визнані твори майстрів галузі першими, а тільки потім сучасні інтерпретації. Таким чином набуті знання будуть мати міцне підґрунтя, причинно-наслідковий та хронологічний зв’язок. Це також полегшує запам’ятовування асоційованого матеріалу.

Георгій Челпанов «Підручник логіки»

У вільному доступі в оригіналі — Г. Челпанов «Учебник логики»

Категорія:логіка.

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

Цей підручник зберіг свою актуальність ще з позаминулого століття (перше видання у 1897 році), перекладений багатьма мовами та складає сучасний навчальний курс логіки у вишах. Викладений матеріал гарно структурований і ілюстрований прикладами. Читається напрочуд легко.

«Логіка — це наука, яка показує, яким чином повинно здійснюватися мислення, щоб була досягнута істина, або наука про закони правильного мислення. Дехто посилається на так званий здоровий глузд і каже: „Помилки потрібно знаходити без врахування логіки, а лише за допомогою здорового глузду“. Це, звісно, справедливо, але часто буває недостатньо знайти помилку; її потрібно ще пояснити, охарактеризувати та визначити. Хтось знає, що в тому чи іншому висновку є помилка, але не в змозі пояснити, чому цей висновок потрібно вважати помилковим. Це часто можливо зробити лише за допомогою правил логіки». (Мій довільний переклад з Г. Челпанова)

Andrew S. Grove «High Output Management»

Категорія:менеджмент.

Очікуваний результат:настільна книга керівника.

Якби я міг порекомендувати лише одну книгу з менеджменту, то це вона. Ендрю Грув — один зі співзасновників компанії Intel, людина 1997 року за версією журналу Time, викладач комп’ютерних наук та менеджменту більше ніж 25 років в університетах Стенфорду та Берклі, наставник Біла Гейтса, Стіва Джобса, Ларі Елісона та Бена Хоровіца. Книга містить лаконічно викладені практичні поради, базовані на власному досвіді, хоча і з дещо відчутним нахилом у «макіавелівський» підхід до керівництва. Наприклад, що говорити людині, яка запізнилася на мітинг чи організувала його, але прийшла не підготовленою; як будувати діалог зі співробітником, який отримав пропозицію від компанії конкурента; на які види поділяються зустрічі та в чому різниця в їх проведенні; як мотивувати підлеглих, вирішувати конфлікти, делегувати повноваження, проводити оцінку ефективності і т. п.

Hans Rosling «Factfulness»

Категорія:когнітивна психологія, статистика.

Очікуваний результат:критичне уявлення про світ, гарний «інструмент»для статичного аналізу.

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

Ed Catmull «Creativity, Inc.»

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

У російському перекладі — Эд Кэтмелл «Корпорация гениев. Как управлять командой творческих людей»

Категорія:біографія, менеджмент.

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

Історія компанії Pixar про те, як палкий шанувальник мультиплікаційних фільмів Уолта Діснея все життя мріяв продовжити його працю — створювати мультиплікаційні фільми за допомогою найсучасніших технологій. Розповідь починається ще з часів навчання Еда у перших класах комп’ютерної графіки Івана Сазерленда, роботи з Джорджем Лукасом, купівлею компанії Стівом Джобсом. Більшу частину присвячено становленню компанії Pixar та продажу студії Disney.

Автор ділиться багатьма корисними техніками для створення продуктів у галузі кіновиробництва, які цілком можуть бути цікавими ІТ-спеціалістам на етапі збору та аналізу вимог до програмного забезпечення. Особливо цінними будуть його поради з управління креативним середовищем, організації та керування інноваційним процесом, мотивації персоналу, планування простору тощо. Це також скарбниця цікавих деталей сюжетних змін культових робіт компанії, опису розвитку технологій комп’ютерної графіки, і все це на фоні Сан-Франциско 80-хта 90-хроків.

Arthur C. Clarke «Childhood’s End»

У російському перекладі — Артур Кларк «Конец детства»

Категорія:наукова фантастика.

Очікуваний результат:один з перших і найкращих романів про прибульців.

Оверлорди, інопланетні створіння несподіванно з’являються у розпалі холодної війни та вимагають... миру, спокою, рівності, допомагають долати бідність, діляться технологіями з людством... Але є одне «але». Точніше, їх буде цілий калейдоскоп, і він буде швидко еволюціонувати. Це один з перших творів Артура С. Кларка і його найулюбленіший (і мій), був відзначений нагородою ретро Hugo, перший тираж був повністю проданий за два місяці. Цікаво, що Стенлі Кубрик спочатку думав екранізувати саме цю книгу, а не починати спільну роботу над «Космічною Одіссеєю».

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

Мы попросили технических специалистов, которые ответственны за наём и увольнение в своих компаниях, рассказать, из-за чего им приходилось увольнять своих коллег.

Токсичность, отсутствие мотивации и негативизм

Дмитрий Абрамов, Delivery Director, Deputy Head of Kyiv R&D Center в DataArt

Я опишу три случая из личной практики, которые мне запомнились.

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

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

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

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

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

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

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

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

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

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

Плохой код и срыв сроков

Дмитрий Родин, CTO & TechLead в Evergreen

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

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

А также — срыв сроков выполнения.

Тут действует правило РПУ:

• «Р» — рекомендуем, что исправить;
• «П» — делаем предупреждение;
• «У» — если не помогло, увольняем.

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

Например, был у нас один Back-end Laravel разработчик. Он позиционировал себя как Middle. Мы делали проект, в административной панели которого находился дашборд с заказами. Однажды клиент пожаловался на ее производительность. Было непонятно, почему все тормозит, если все данные подтягиваются с одной модели.

Мы провели ревью кода, и оказалось:

1. Разработчик, используя грабли, подключил datatable без органичной имплементации с моделью Laravel. Под это есть готовые решения, но он зачем-то прикрутил свой «велосипед».
2. Он отдавал на Front-end все заказы из базы: там их от 10K, а постраничность реализована уже на фронте. Если бы он порционно реализовал server-side отдачу данных, тогда бы все летало.

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

Неумение работать в команде при удаленной работе

Павел Никиточкин, CTO в JetThoughts

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

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

Единственный случай, когда мы сами уволили сотрудника, был основан на подрыве доверия и лжи с его стороны. Это был Lead Ruby on Rails Engineer, который отвечал за подготовку продукта к выпуску. Для решения этой задачи ему были предоставлены полная свобода и гибкость — ответственность за решения была достаточно серьезной.

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

Спустя неделю человек объявился и представил много мелких правок, сгенерированные автоматическим инструментарием, которые отсутствовали в списке необходимых. Это и послужило переломным моментом.

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

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

Безынициативность, безответственность, саботаж работы

Дмитрий Пискарёв, CEO (ex-CTO) Netpeak Agency

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

За что мы увольняем? Ничего необычного: за безынициативность, безответственность, саботаж работы.

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

Например, была ситуация, когда он открыто начал пропускать daily scrum и ретроспективы. Объяснял свое поведение тем, что и так всё знает, при этом демотивируя всю команду. Иногда это приобретало совсем причудливые формы — он мог брать задачи из бэклога, которые ему интересны, не говорить об этом остальным и создавать конфликтные куски кода.

Я пытался решить проблему в течение года разными способами: встречи в формате one-on-one, смена направлений работы этого специалиста, попытка дистанцировать его от команды. В итоге ничего из перечисленного не помогло. Сейчас я понимаю, что не надо было так долго тянуть и давать третий, четвертый и пятый шансы.

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

Об авторе: Денис Морозов, к.ф.-м.н., работает на должности доцента кафедры математики НаУКМА, также является консультантом компании GlobalLogic. Работает над докторской диссертацией, сфера научных интересов — конечные автоматы и группы автоморфизмов деревьев.

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

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

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

Комбинационно-логические схемы vs нейронные сети

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

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

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

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

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

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

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

Далее рассмотрим пример применения данной техники. Пример придуман и написан мной для одной лекции на данную тему.

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

1. Основные определения

Пусть булевый вектор входных данных структурного блока , — выходных.

Определение 1.Будем обозначать блоккак.

Данный блок можно получить, как декартово произведение блоков :

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

Определение 2.Формализированным требованием к блокубудем называть подмножествопредставим следующей булевой функцией:

Доказательство.Согласно представлению булевой функции в совершенной дизъюнктивной нормальной форме.

Пример.Пусть имеется следующее требование к работе блока:

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

Данное требование имеет следующий формализированный вид:

Согласно лемме 1 работа блока описывается функцией:

3. Оптимизация булевого блока с одним выходом

Пусть блок с одним выходом задается следующей таблицей истинности:

Что соответсвует булевой формуле:

Оставим значащие для ДДНФ строки:

Переставим строки в соответствии с кодом Грея:

Построим граф, соединив пары строк , для которых расстояние Хэмминга :

Выберем множество пар, что покрывают все вершины:

Выбранному множеству пар

(2,3)
(4,5)
(5,7)
(1,6)

соответствует следующая таблица:

Согласно полученной таблице, минимизированная формула примет вид:

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

получим:

Что соответствует булевой формуле:

Данному упрощению соотвествует следующий граф, содержащий 5 отмеченных ребер, накрывающих все вершины:

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

4. Абстрактная схема алгоритмов упрощения

Определение 3.Будем считать, что блок A проще блока B, если:

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

Определение 4.Пусть формула А является дизъюнктивным объединением блоков , а формула B является дизъюнктивным объединением блоков . Будем говорить, что , если:

Определение 5.Для формулы определим как множество эквивалентных F формул над множеством переменных как множество формул:

множеством упрощений формулы F.

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

Выводы

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

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

Предыстория

За 5 лет карьеры Front-end программистом я прошел 80 собеседований. Первые полтора года я работал на фрилансе, опыта в прохождении собеседований не было, поэтому в родном городе Харькове завалил 26 собеседований — это были практически все вакансии из моего раздела. После жесткого фиаско я стал шерстить вакансии Киев и других стран, так меня и занесло в столицу.

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

Почему я решил искать новую работу

Отсчет начался с того момента, когда начальство отказалось повышать мне зарплату. Официально в нашей компании зарплату пересматривали раз в год. Я попросил повышение за 3 месяца до обещанного срока, но мне сказали: «Саня нужно качаться еще полгода, расти. Ты мало сделал для нашей компании, мы не можем поднять тебе зарплату».

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

Поработав в этой компании 9 месяцев, я получил опыт взаимодействия с командой и практический опыт при создании крупного гибридного мобильного приложения для банковского сектора, которое мы делали с командой 5 месяцев. Кстати, разработку этого мобильного приложения начальство забраковало, и проект был выброшен в мусорку. Так его и не увидел ни один пользователь. Обидно.

Какими навыками я обладал на этот момент: 3 года верстки и 1 год на чистом JavaScript, итого 3 года опыта. Немного работал в React и Node.js. Также у меня был хороший опыт работы на фрилансе, который я детально описал в этой статье.

Приняв решение искать новую работу, я начал рассылать резюме на Djinni, DOU и LinkedIn. Писал, что хочу занять позицию Senior JavaScript разработчика. Звучит дерзко, исходя из описанного опыта.

Хорошая подготовка — залог успеха

Опишу, как проходят собеседования в IT-компаниях и как лучше всего к ним подготовиться.

Любое трудоустройство состоит из пяти этапов:

1. Первичный ответ HR на резюме.
2. Проверка кандидата на адекватность.
3. Техническое собеседование.
4. Встреча с ответственным, который принимает окончательное решение насчет кандидата.
5. Оффер и шампанское.

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

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

• Расскажите, что вы знаете о нашей компании?
• Э-э-э... Ну, вы занимаетесь разработкой софта для американцев.
• Не совсем... Вы что, не читали про нас?
• Читал, но совсем поверхностно...

Это полный провал в лице интервьюера, что сразу смахивает на неловкую ситуацию при первом свидании.

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

Как с помощью DOU правильно выбрать работодателя:

1. Читаем отзывы о компании на jobs.dou.ua. Особое внимание уделяем плохим отзывам. При необходимости связываемся с этими специалистами через LinkedIn и узнаем, на каких проектах и с какими людьми в компании плохо обстоят дела.
2. Смотрим фотографии офиса и коллектива на jobs.dou.ua. Возможно, у них даже и офиса нормального нет, а для вас это важно.
   
3. Смотрим публичные показатели в рейтингеили профиле компании на jobs.dou.ua. Если общая оценка 80 — это хорошо. Если хотя бы один показатель меньше 80 — это очевидный минус.
4. Если данных недостаточно, открываем Facebook или LinkedIn и ищем интересующую нас информацию на страницах компании.
5. Когда вся информация собрана, прислушиваемся к интуиции, анализируем данные и принимаем решение о посещении первого собеседования.

Мое рабочее место. Если присмотреться к бумажкам на стене, можно увидеть секреты успешной Scrum-команды

Практически всегда отказы происходят на этапе технического собеседования. Все работодатели хотят найти себе идеального единорога, который умеет не только летать но и программировать. Я пользовался Quizfulи InterviewBit, чтобы подковать себя технически.

Лайфхаки из опыта:

1. Перед тем как идти на собеседование, узнайте у HR, кто именно будет вас собеседовать. Найдите этих людей на LinkedIn, GitHub, Facebook и подробно узнайте, кто они и чего от них стоит ожидать.
2. Когда ответственный принимает окончательное решение о найме кандидата, он задает себе вопрос: «Приятно ли мне было бы выпить с ним вечером в баре?». Если ответ «да», значит у вас высокий шанс получить оффер. Если «нет» — каким бы профессионалом вы ни были, руководителю просто не комфортно будет с вами общаться. Задавайте себе такой же вопрос по отношению к тем, с кем вам придется работать, и принимайте верное решение.
3. Любая компания может позиционировать вакансию Junior, Middle или Senior совсем под другим уровнем в вашем понимании. Будучи Senior, вы приходите к ним и понимаете, что в их глазах вы Junior, а сложность проектов у этой организации совсем не такая, с какой человек работал в прошлой компании.

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

Резюме — ваш букет с цветами

Без хорошо оформленного резюме шансы на ответ от HR крайне малы. Рекомендую писать в резюме лишь правду, приближенные к реальности цифры опыта и технологии, на которых вы сделали больше, чем вывели «Hello World!» в консоль. Если писать грубое вранье, это повлечет проблемы — если не на собеседовании, так на работе.

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

Мне начали поступать предложения из Djinni, DOU и LinkedIn (где-то слышал, что в среднем 70% IT-компаний находят кадров как раз на LinkedIn). За первую неделю я получил около 20-30 откликов.На Djinni даже отвечали компании, в которых я уже работал.

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

Создаем резюме

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

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

Если хотите углубиться в тему карьерного роста, рекомендую пройти курс «Career Hacking»от Davis Jones, в котором все темы расставлены по полочкам. Он стоит своих $10.

Результаты с собеседований за первые две недели.Из 20 откликов я пошел на 15 собеседований и прошел все их на этапе тестирования английского. В большинстве случаев оно проходило по Skype с HR. Редко, но бывало и такое, что тестирование проводил учитель английского.

Из 15 собеседований я получил 2 оффера, но от обоих отказался, потому что проект был скучный либо команда слабая.

Приглянись, нравится ли она тебе

Однажды утром, попивая кофе, я наткнулся на вакансию Middle JavaScript разработчика в одной крупной IT-компании, описание заинтересовало. Требуемый уровень разговорного английского в вакансии стоял Intermediate. Я давно знал о компании, попасть к ним нелегко — подумал я и тут же отправил резюме. HR связалась со мной уже через 2 часа. Девушка рассказала, что первым этапом будет общение с ней на английском. И я успешно прошел его в этот же день. Оно было простым и длилось 7 минут: рассказал на английском о своем опыте в разработке и что меня конкретно интересует.

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

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

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

Несколько слов о двух категориях соискателей:

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

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

Проблемы с английским

На тот момент у меня был недостаточный уровень английского, и я знал, что на собеседовании придется общаться на нем. В резюме я указал, что у меня разговорный Intermediate, но это была неправда. После трудоустройства эксперты сказали, что мой уровень не выше Elementary. Рассказать о себе я мог, но словарный запас был крайне мал. Любой впервые услышанный вопрос зачастую вгонял меня в тупик.

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

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

Список полезных онлайн-сервисов для изучения английского:

1. Preply — цены на уроки опытных учителей от 7$ в час, преподаватели со всего мира, удаленное обучение.
2. Skyeng — цены от $10 в час, русскоязычные и англоязычные преподаватели, удаленное обучение.
3. Puzzle-movies — фильмы, сериалы на английском с двойными субтитрами. (русский, английский). Для непонятных слов есть развернутые видеообъяснения на русском языке. После просмотра сериала предлагают пройти тест, закрепив новые слова.
4. Grammarly — условно бесплатное расширение для браузеров. Когда пишешь текст, Grammarly предлагает исправить орфографические ошибки, указывая правильные варианты.

Я пользовался 3-ми 4-мсервисами. Puzzle-movies помогал тренировать слух и повышать словарный запас при просмотре «Криминального чтива» или сериала «Друзья». Во время серфинга в интернете Grammarly помогал исправлять орфографические ошибки — так я усваивал правильное написание слов.

Столик на троих, пожалуйста

Я ужаснулся, когда услышал от HR: «Собеседование с заказчиком на английском». Взял себе пару дней на подготовку и вновь начал активно зубрить язык.

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

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

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

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

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

К моему удивлению, по словам HR, заказчик сказал, что все прошло на приемлемом уровне, поэтому он одобрил этот этап.

Последние этапы

Техническое интервью. Через день HR пригласила меня на техническое собеседование в компанию. Я повторил все технические термины OOP, JavaScript, HTML, CSS, разные каверзные вопросы и всё, что касалось этой вакансии на позицию Middle JavaScript разработчика.

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

В офисе меня ждали два технических специалиста. Мне удалось ответить на все технические вопросы. Например, какие ты знаешь шаблоны проектирования? С какими типами CSS центрирования элемента ты знаком? Можешь рассказать обо всех способах оптимизации JavaScript-приложений?

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

Вопросы к заказчику.Следующая и последняя встреча была формальным общением с заказчиком. Он рассказал, сколько компания готова платить, все ли меня устраивает, и спросил, когда я готов выйти на работу. Также я задал свои вопросы: как вы развиваете коллективный дух команды, есть ли курсы английского, как устроен бизнес изнутри. Разговор состоялся по Skype, HR была также с нами на связи.

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

Победа

Команда, в которую я попал, состояла из 6 человек и работала по Scrum. Ежедневно у нас проходили митинги в формате 15-минутныхретроспектив, где каждый член команды рассказывал, что он сделал вчера и что будет делать сегодня. Перед каждой встречей я минимум 30 минут выделял на подготовку своей речи, записывал на стикерах, что рассказывать и всевозможные вопросы. Иногда от длинных встреч у меня в голове был шум, как от помех в телевизоре.

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

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

На новом месте работы. В перерыве между тренингом по Scrum

Как пройти испытательный срок:

1. Выполнять все задачи в срок. Если придется, то работать сверхурочно.
2. Стать зависимостью — это когда без тебя команда не сможет функционировать. Для этого нужно брать самые ответственные задачи.
3. Подружиться с командой. Перед тем как окончательно взять кандидата, заказчик спросит у команды: «Ну как он вам, комфортно с ним работать?».

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

Вывод

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

Кстати, загляните на мой блог в Telegram, где рассказываю, как создаю онлайн-школу и пишу про образование, а также канал, где я пишу про Front-end.

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

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

На мій подив, попередня статтяпро співбесіди з рекрутерами та HR викликала неочікуваний інтерес: усього більш, ніж 100 000 переглядів по всіх джерелах. Я отримав купу позитивних відгуків у приватні повідомлення: мені написали колишні колеги, котрих я останній раз бачив 5 років тому; героїні деяких історій зі статті; хлопець, якому я кілька тижнів тому продавав системник через OLX; барабанщик, з яким ми минулого року грали метал у гаражі, та, як це не дивно, дуже багато рекрутерів, які поцікавилися моєю думкою щодо того чи іншого. 250 людей додалися до мене у LinkedIn — не знаю, правда, навіщо :)

Перед тим як перейти до справи, відповім на найпопулярніші запитання з приватних повідомлень та коментарів.

Як домовлятися про зарплату на співбесіді

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

• Как обсуждать деньги на собеседовании: стратегия переговоров для соискателя
• Salary Negotiation: Make More Money, Be More Valued

Рекомендую прочитати перед пошуками роботи.

Кілька думок щодо рекрутингу

Я в жодному разі не даю порад рекрутерам, як їм робити їхню роботу. Я не професійний рекрутер і не знаю, як працює їхня внутрішня кухня. Коли мені доводилося шукати собі персонал (не проводити технічні співбесіди, а саме шукати і наймати — повний цикл), то це були junior-позиції, відповідно, в мене не було особливих проблем.

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

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

Також рекрутинг — це продаж вакансії кандидату. Чим швидше ви це зрозумієте та почнете прокачувати свої навички продажів — тим краще. Ой, я ж казав, що не буду давати порад :)

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

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

Винайматися у компанію чи на проект

На мою думку, у наших реаліях — однозначно на проект. Трішки детальніше про це написав у себе в Telegram-каналі.

Як обирати собі тайтл

Я позиціював себе як кандидат рівня Senior Software Engineer та вище — Team/Tech Lead, Principal Engineer, Software Architect, Project Manager, People/Group Manager і так далі. Саме це «вище» малось на увазі під «+» у Senior+.

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

Отож, пані та панове, перейдемо до технічних співбесід.

Етап другий. Технічні співбесіди

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

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

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

Тестові завдання

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

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

Позиція DevOps Engineer. Мені надіслали завдання зробити Vagrant конфігурацію з декількома інстансами, серед яких мали бути веб-сервери зі статикою, балансер для них і Jenkins. Усе це треба було встановлювати за допомогою Chef. А тепер уявімо: я ніколи не користувався Vagrant, Chef та не налаштовував ті веб-сервери, яких вимагали у тестовому завданні. Я приблизно розбираюся в тому, як воно все працює, мав справу зі схожими інструментами, але ніколи не використовував саме ці конкретні.

Мені довелося за одну ніч сісти, встановити це все, наступити на купу грабель, але врешті-решт виконати завдання. Основна складність полягала в тому, що в мене старий MacBook Pro 15-гороку, який фізично не встигав рестартувати ті контейнери, і в тому, що я не мав досвіду з Vagrant.

На суть задачі — розібратися, як там що встановлювати, — у мене пішло може з півгодини. Решту часу (7 з гаком годин) я витратив на встановлення всього інструментарію, рестарти-ребути, тикання по конфігах в намаганнях зрозуміти, чому воно не працює, і так далі. Те саме на Docker Compose я би зробив, напевне, за годину, може, навіть менше. Чи можна було б у задачі не обмежувати кандидата інструментами? На мою думку, можна.

Чи було це завдання корисним для мене? Однозначно так! Я тепер буду знати, що від Vagrant та Chef треба триматися якомога далі :)

Витрачено часу — 8 годин.

На жаль, більше історій про цей тип завдань у мене немає, тому що тестових давали в цілому не так багато :(

«Ось посилання на сайт з тестами, пройдіть їх» — дуже класний варіант. У чому суть? Є SaaS, які дозволяють сконфігурувати набір практичних та теоретичних питань та для вирішення надають REPL та редактор коду прямо там в них і можливість запустити верифікаційні тести. Далі ви просто йдете по завданнях, фіксите або пишете код, запускаєте його і дивитися результати. Самі тести від вас приховані, ви бачите тільки результат (passed/failed) та короткий опис тесту, який одночасно є підказкою. Чому це варіант мені подобається найбільше? Тому що є однозначний критерій якості виконання завдання і кандидат точно знає, скільки балів він набрав, чи його рішення працюють і так далі. Мені особисто навіть цікаво було проходити ті завдання. Єдине, що я не бачу змісту в теоретичних питаннях типу «що буде, якщо виконати цей код» — вони легко гугляться.

Позиція Ruby Software Engineer (пам’ятаєте історіюпро місяць очікування? Це звідти). Мені присилають лінку на сайт TestDome, звісно, кастомний тест. Я клікаю, потрапляю до власне тестів. Мені дається 2,5 години на проходження всього набору, по 5-20хвилин на кожне питання. Насправді мені дуже сподобалося, я вже давно не проходив такі штуки. Особливо мені сподобався TDD-підхід: закодив, запустив, подивився, що в тебе впало, кодиш далі. Пройшов із великим задоволенням.

Самі задачі були відносно прості: виправити код (Ruby/JS/CSS/HTML), написати якісь валідатори (Ruby), реалізувати структури даних (Ruby), нічого особливого. Але той факт, що ти одразу можеш перевірити, чи рішення працює, дуже допомагає у вирішенні.

Я впорався із завданням на 93/100 балів усього за годинку з гачком. Шкода, що це мені зовсім не знадобилося на подальших етапах. TDD допомагає у вирішенні, не потрібно витрачати час на підйом інфраструктури, репл прямо у браузері — коротше кажучи, дуже круто. Заради такого можна було і місяць почекати — адже я отримав свою порцію допаміну (я круто все зробив!) та адреналіну (таймер працює, часу все менше!).

Витрачено часу — 1 година.

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

«Ось репозиторій, там завдання, надішліть Pull Request з рішенням» — такий варіант мені не траплявся, але його використовували мої колеги. Мені він не дуже подобається, тому що можна подивитися, як виконували те саме завдання інші люди (якщо вони були).

Недоліки такого виду завдань очевидні: треба викачувати код, дивитися, що там — це довго та нудно. Звісно можна подивитися поверху на код у браузері, але навіщо тоді завдання було? Давайте вже на псевдокоді писати.

«Ось репозиторій, там код, відрефакторіть, наскільки зможете» — варіація попереднього. Це вже краще, бо тут з самого початку створюються якісь рамки, у яких можна працювати. Недоліки ті самі: незрозуміло, коли потрібно зупинятися. Як казавЄгор Бугаєнко, будь-яка програма містить нескінченну кількість помилок, і фіксити їх можна теж до нескінченності. Автори завдання мали щось у голові, коли робили його, але швидше за все ми так і не дізнаємося, що саме було б для них основним. Якби завдання мало чіткий критерій, тоді це було б круто. Наприклад, є код, він на такому залізі видає ось такий результат по швидкодії. Порефакторіть, щоб працювало в два рази швидше. Без критерію працювати складно. У реальному житті в реальній роботі ми завжди маємо рамки і шукаємо оптимальне рішення, керуючись цими рамками та здоровим глуздом. І основна робота розробника — якраз відчути цей баланс і підібрати відповідне рішення.

На мій превеликий жаль, ніхто більше не давав тестових завдань, тому статистика у мене зовсім невелика. Хіба що можу згадати ті тестові, які я робив багато років тому. Вони всі були першого типу — потрібно було написати проект. Цікаво, що я їх робив у ті часи, коли GitHub не був таким популярним і треба було пересилати вирішення у zip-архіві поштою :)

Мої рекомендації щодо тестових завдань:

1. Не подобається — не робіть. Якщо завдання, припустимо, заверстати цілий сайт або написати круд — ну його в баню. Завдання мають бути короткими і сфокусованими на створенні контексту для подальшого обговорення, а не просто тестом на те, як ви вмієте скафолдинг робити.
2. Якщо завдання першого типу — додайте до репозиторію readme, де в деталях опишіть інструкцію для запуску, чому ви зробили таке рішення, які ви бачите в ньому недоліки, що вам сподобалося, що не сподобалося, як би ви вирішили завдання, якби у вас було більше часу, і так далі. Не знаю, чи це реально допомагає, але як інтерв’юер я б однозначно звернув увагу на це.
3. Пишіть нормально, але не варто витрачати купу часу на вилизування деталей. Як на мене, достатньо просто перелічити в readme все, що ви б реалізували, якби це був бойовий код.
4. Обов’язково подумайте, які питання до вас можуть виникнути щодо реалізації, та почитайте додатково документацію про те API, яке ви використовували. Припустимо, я давно не працював з concurrency. Одна з задач, яку я вирішував на наступних етапах, була пов’язана с concurrency. Я вже давно не практикувався у цьому, тому після вирішення я швиденько пробігся по всім пов’язаним темам, пригадав усі типові запитання і був готовий до розмови.

Що ж, тестове, ви, сподіваюсь, успішно виконали, передали цю інформацію рекрутеру, і через невизначений час вас запросять поговорити in person.

Технічна співбесіда. Інтро

Почнімо з того, що зараз уже досить рідко запрошують до офісу на технічні співбесіди. В офіс мене запросили тільки декілька разів — для інтерв’ю на позиції Solution Architect, Tech Lead та одного разу — на менеджерську позицію. Усі інші співбесіди проходили по Skype, Zoom, Hangouts. Як і на попередній співбесіді з рекрутером, поради ті самі — хороша камера, хороша гарнітура. До цього обов’язково додамо умову шарити екран. Тому переконайтеся, що ви не маєте відкритих робочих проектів (якщо це важливо) та інших персональних речей, які не потрібно показувати людям з того боку. Майте під рукою чистий браузер без табів та REPL для кодингу про всяк випадок (IDE або відкритий сайт).

З усіх засобів зв’язку мені найбільше подобається Zoom. Власне його найчастіше і використовували.

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

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

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

Якщо все гаразд, пройшли пінги туди-сюди, то розпочнеться розмова. Часто інтерв’юери самі пропонують план розмови. Буває, що в них немає плану, але як мінімум одна тема буде актуальною завжди: «Розкажіть про себе та про свій досвід».

Перед співбесідою обов’язково ще раз пройдіться по вакансії, зауважте вимоги, які пред’являються до кандидата, та підготуйте промову. Я проходив співбесіди на Tech Lead, DevOps/SRE, Ruby/Java Software Engineer і у кожному випадку говорив різні речі, які б, на мою думку, зацікавили інтерв’юерів найбільше. Намагайтеся не заглиблюватися в деталі, а надати ту інформацію, яка створить вектор для подальшої дискусії. Не варто детально говорити про те, що ви робили 5 років тому (якщо це не було щось екстраординарне).

Я казав, наприклад, таке: «8 років працював у ентерпрайз-конторі, в основному з Java. Далі пішов у стартап, там займався інфраструктурою. Останні два роки пишу в основному на Rails». Все, у інтерв’юерів є досить інформації, і вони далі вже будуть розкручувати розмову в тому напрямку, який їх найбільше цікавить.

А тепер несподіваний факт.

Ваше резюме ніхто не читає

Чесно кажучи, це виявилося для мене великим відкриттям. Ну добре, рекрутери не читають профіль у LinkedIn, тому що він може бути не up-to-date, HR має навичку проглядати CV і просто виділяти для себе основне. Але от люди, які проводять співбесіду, вже точно не будуть читати ваше резюме. Жодного, підкреслю, жодного разу я не відчув, що люди хоча б одним оком глянули на те, що я там детально порозписував. Я підозрюю, що, як правило, вони дізнавалися про те, що потрібно проводити технічну співбесіду, попереднього дня, і вирішували почитати CV за 5 хвилин до дзвінка, а там вже буде як буде.

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

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

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

Ви нікому не потрібні

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

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

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

Ви не будете розмовляти зі своїм майбутнім босом чи тімлідом

Це є наслідком з попереднього. На моє глибоке переконання, ви повинні говорити з тим, кому ви потім будете підпорядковуватися, формально чи неформально. В усіх організаціях є якась ієрархія, хоч це Scrum-команда, хоч кривавий ентерпрайз. Усюди є людина, яка буде приглядати за вами (як мінімум на старті).

На жаль, ви нічого не можете з цим зробити. Єгор Бугаєнко у своєму дописі «Why I Don’t Talk to Google Recruiters»дуже добре описав цю ситуацію. Якщо ви будете вимагати розмови зі своїм майбутнім босом — ви просто не підете ні на яке інтерв’ю.

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

Трішки минулого досвіду. Коли я винаймався на поточну роботу, то розмовляв безпосередньо з CTO та CEO. Я повинен був бути першим інженером у стартапі, тому й ставлення до мене було дуже прискіпливе та серйозне. У результаті ми чудово спрацювалися, та й співбесіда була однією з найкращих, що в мене були. Ми обговорювали не тільки технічні деталі, а відразу й перші кроки і плани на декілька місяців наперед. Навіть якщо співбесіду не буде проводити ваш безпосередній керівник, обов’язково вимагайте долива пива после отстояспілкування з ним перед тим, як приймати пропозицію (звісно, якщо вдасться пройти всі етапи).

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

Долучайтеся до мого каналу у Телеграмі, і до наступної статті!

[В рубрике «Как я работаю»мы приглашаем гостя рассказать о своей работе, организации воркспейса, полезных инструментах и лайфхаках]

Богдан Гусев — один из активных участников Ruby-сообщества. Он участвовал в разработке фреймворка Ruby on Rails, а также написал несколько своих библиотек, которые доступны на GitHub.

Более 6 лет Богдан работает в стартапе Talkable. Он управляет командой из 20 человек и старается устранять все технические проблемы еще до того, как они появятся.

О себе

Я начал учить программирование еще в школе. Мне было интересно, но я не выходил за пределы школьной программы. На старших курсах университета выбирал между IT и финансами. Но с финансами не клеилось, эта сфера как-будто выталкивала. И я все больше интересовался программированием. В то время мой сосед по комнате в общежитии работал удаленно в одной IT-компании, и я тоже присоединился к его команде. Затем было еще несколько удаленных проектов в других компаниях: Gera-IT и Hi-Tech.

Первые два года я программировал на Java, но позже увлекся Ruby. Случайно прочитал на каком-то форуме, что вышла новая версия фреймворка Ruby on Rails. И меня заинтересовало, что создатели этого инструмента уже решили многие проблемы, с которыми я только начал сталкиваться при разработке на Java.

Например, в Java на тот момент приходилось прописывать каждый SQL-запрос вручную в XML-файлес большим количеством дублирования кода между запросами (MyBatis, тогда iBATIS). А в Rails уже был продвинутый генератор SQL-запросов и средства повторного использования фрагментов SQL в разных запросах (ActiveRecord).

В 2010 году я пришел работать в компанию Railsware. Сначала мне там нравилось, но затем начали возникать разногласия с коллегами, руководителями проекта и заказчиком — они касались взглядов на разработку. Заказчики требовали реализации максимального количества фич за секунду и постоянно меняли бизнес-модель проекта. Это делало разработку крайне болезненной: когда вещи используются не для того, для чего были изначально сделаны. Я всегда считал, что лучше доводить начатое до результата, будь он хороший или плохой. А если наступило разочарование и пришла новая идея — лучше начать с нуля.

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

Я понял: чтобы работать с профессионалами, мне нужно им соответствовать. Тогда я сам работал на среднем уровне, а хотелось чего-то большего. И я начал усиленно учиться и развиваться. В качестве площадки для практики выбрал опенсорс. Мне всегда нравилась идеология ПО с открытым кодом. Тем более, почти все инструменты, которыми я пользовался, разрабатывались именно open-source.

Open-source и разработка фреймворка Ruby on Rails

Чтобы не размениваться на мелочи, я решил присоединиться к опенсорс-разработке самого фреймворка Ruby on Rails. Было интересно воплотить свои идеи и получить обратную связь о них. Я начал изучать, какие проблемы могу решить. Больше всего меня заинтересовала тема производительности. Если вы предлагаете что-то, что ускорит работу программы, то высока вероятность, что ваше решение примут и не будут спорить, что «раньше было лучше».

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

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

Помимо Diffbench, я написал еще несколько библиотек для Ruby:

• Datagrid — позволяет быстро строить интерфейсы админок для табличных данных.
• Furi — позволяет делать любые манипуляции с URL в одну строчку кода. Обычно у аналогов их всегда 2-3и не все поддерживаются.
• JS-Routes — дает доступ к Ruby on Rails routes в JavaScript.
• accept_values_for — средства быстрого тестирования валидации для Rspec.

После работы над Ruby on Rails на меня посыпались предложения о сотрудничестве — на меня выходили через мой профиль на GitHub. И они были более привлекательны, чем моя текущая работа. После этого я полгода проработал в одной продуктовой компании на позиции СТО, но и там была, по сути, игра в стартап.

А затем, в 2012 году, мне предложили должность СТО в Talkable. В компании был серьезный технический кризис, и я принял вызов улучшить продукт с точки зрения технологий.

О роли СТО в Talkable

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

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

Помню интересный диалог с основателям компании, когда я только приступал к работе:

• Богдан, сколько времени понадобится, чтобы переписать продукт?
• А сколько времени вы его создавали?
• Примерно два года.
• Вот столько же и понадобится, чтобы переписать.

Так оно и вышло, мне понадобилось два года. Одна из самых веселых ситуаций: в проекте была функциональность, реализованная в основном на JavaScript. Данные, которые приходили на Back-end, просто клались в базу — и интерпретировать их без JavaScript и HTML было нереально. Чтобы перевести данные в формат, понимаемый на уровне Back-end, пришлось написать мигратор данных. Он открывал браузер, брал данные оттуда и отправлял их в базу в новом понимаемом формате, о котором до изменений можно было судить только из интерфейса.

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

Мои обязанности как СТО — предвидеть технические проблемы и устранять их до того, как они наступят. Каждый день сам пишу код, но все же примерно половина всего времени уходит на менеджерские задачи. Сейчас в моей команде работает 10 Back-end разработчиков и 3 — Front-end. Все находятся в Киеве.

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

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

Типичный рабочий день

7:00.Просыпаюсь, занимаюсь йогой, завтракаю, занимаюсь домашними делами, собираюсь на работу.

10:00.Выхожу на работу. Иду пешком, мне нравятся утренние прогулки.

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

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

12:30.Провожу стендап Back-end команды, где каждый рассказывает, что сделал вчера и что планирует сделать сегодня. Это единственный ежедневный митинг для разработчиков.

13:00.Двигаюсь по списку своих задач и встреч. В этом плане каждый день не похож на предыдущий — все зависит от текущих приоритетов.

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

18:30.Заканчиваю работу. Вечер, как правило, уделяю семье.

Инструменты и продуктивность

Для разработки я уже много лет использую Vim. Рабочие переписки мы ведем в Slack, почта — Gmail. Я думаю над тем, чтобы проверять почту только в фиксированное время пару раз в день, но пока так не получается: люди ожидают быстрый ответ.

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

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

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

Я не стремлюсь сделать за день как можно больше задач. Делаю упор на качество и долгосрочную перспективу.

Книжки и самообразование

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

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

Сейчас начал читать «Когда невозможное возможно. Приключения в необычных реальностях»Станислава Грофа. На будущее планирую прочитать «Человек и его символы»Карла Юнга и «Игра сознания»Свами Муктананда.

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

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

Ретроспектива и планы на будущее

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

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

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

Думаю, было бы интересно когда-нибудь присоединиться к разработчикам фреймворка Ruby on Rails — не как волонтер в свободное время, а как член основной команды.

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

Евгения Неклонскаяработает рекрутером в харьковском офисе компании Intetics и увлекается движением Zero waste. Его цель — более осознанно подходить к потреблению и уменьшить количество отходов.

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

— Евгения, что такое Zero waste? Почему это актуально сейчас?

Zero waste — это некая философия, образ жизни. Он призывает максимально уменьшить количество отходов, которые каждый из нас оставляет за собой. А оставляем мы очень много чего некрасивого :)

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

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

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

Поэтому и возникло движение Zero waste, ведь каждый из нас может сделать для планеты больше, чем думает. Каждый день мы голосуем своим кошельком. Если представить, что уже завтра внезапно все покупатели откажутся от тех же пакетов — ну какой умалишенный будет продолжать их производить? :)

— Какие главные принципы жизни в стиле Zero waste?

Главные принципы Zero waste описываются как 5R:

• refuse (откажись);
• reduce (сократи потребление);
• reuse + repair (используй повторно или отремонтируй);
• recycle (переработай);
• rot (компостируй).

Все эти принципы очень тесно между собой переплетаются.

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

Многоразовые мешочки для похода в супермаркет

Reduce — сократи потребление, покупай столько, сколько тебе нужно. Лучше меньше, чем больше :) К примеру, среднестатистическая европейская семья выбрасывает четверть купленных продуктов. И если вы думаете: выкинули продукты, они перегнили и все, то все не так просто. Вместе с ними ушли на помойку и выбросы С02 на выращивание и доставку, и тысячи литров воды и удобрений, и время десятков, а то и сотен людей. По-моему, это жуткое расточительство.

Reuse + repair — это про б/у вещи и предметы и про то, что не стоит спешить выбрасывать то, что вышло из строя. Может, эту дырку на любимых джинсах можно как-то украсить? Или если нет, то сшить из них сумку для походов на рынок. Вариантов множество, вспоминаем программу «Очумелые ручки и творим» :)

Recycle — переработай. Здесь, думаю, все понятно: сортируем отходы, сдаем на переработку. К слову, только металл и стекло можно перерабатывать бесконечно, у пластика же и бумаги есть ограничения в несколько циклов. Потому при покупке продуктов отдаем предпочтение стеклянной или металлической таре.

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

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

— Как вы узнали о движении?

Все ругают соцсети, а я их люблю за возможность познавать. Про Zero waste узнала из Instagram. Почти год назад случайно попала на один и понеслась :)

— С чего начинали? К каким результатам пришли сейчас?

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

Конечно, количество мусора у меня сильно сократилось. Один раз в месяц я ношу мусор на сортировку. У нас в Харькове по расписанию работает специальный мобиль, который подъезжает относительно близко к дому. Его график можно посмотреть на страницах сообщества «ЯСОРТУЮ» в Facebookи Instagram.

Также в Харькове есть сортировочный пункт «Прихисти пакет». Они собирают сырье на сортировку как с машиной, так и стационарно в эко-хабе. Анонсы — в Facebookи Instagram.

По Харькову ездит специальный мобиль, который собирает мусор на сортировку

Максимум дважды в неделю выбрасываю органику в простой мусорный бак под домом.

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

— Как к этому движению отнеслись твои знакомые? Удалось ли кого-то мотивировать присоединиться к движению? И есть ли те, кто воспринимает философию Zero waste в штыки?

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

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

В штыки мой подход еще никто не воспринимал, кроме разве что некоторых продавцов в супермаркетах :)

— Что можете посоветовать тем, кто разделяет философию Zero waste? С чего начать? Как безболезненно отказаться от лишних отходов?

Прежде всего — начните :) Медленно ли, быстро — не важно. Главное — осознанно. Начните с матчасти, почитайте блог Беа Джонсон. Потом проанализируйте свой быт — что вы покупаете каждый день, сколько используете одноразовых вещей, пластика, что можно заменить на многоразовые аналоги.

Холодильник зировейстера

Девушкам очень советую внимательно присмотреться к своей косметике. Вы уверены, что вам нужны триста умывалок и пятьсот гелей для душа? Дерматологи — нет :)

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

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

— Какие есть экоальтернативы привычным повседневным бытовым средствам и инструментам?

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

Мусорные пакеты —> разлагаемые пакеты из кукурузного крахмала. Или по старинке, без них :)

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

Пластиковые зубные щетки —> бамбуковые зубные щетки.

Пластиковые ушные палочки —> деревянные ушные палочки.

Скотч, резиновые перчатки, дождевики —> аналоги из кукурузного или картофельного крахмала.

Экологические аналоги привычных продуктов

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

Ватные диски —> многоразовые хлопковые диски.

Бытовая химия —> сода, уксус, лимонная кислота.

Стиральный порошок —> мыльные орехи, органический порошок.

Зубная нить в пластике —> аналоги в стеклянных перерабатываемых контейнерах.

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

Вода в пластике —> многоразовая стеклянная или металлическая бутылка.

Кофе на вынос —> своя многоразовая чашка а-ля KeepCup.

Трубочки для напитков из пластика —> аналоги из металла или бумаги.

Еду на работу носим с собой или покупаем в свою тару. Пластиковые контейнеры, в которые складывают еду большинство доставок или «на вынос», не перерабатываются.

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

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

— С какими трудностями сталкивается зировейстер? Как их решать?

Главная трудность, на мой взгляд, в том, что не всегда просто найти Zero waste аналоги привычных вещей. В обычных магазинах их чаще всего просто не купишь. Я ищу нужные товары в Ozero, goodies.ecoshop, cooleco, Торбинкова Людинка, bezwaste.

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

Кроме того, есть еще и лень :) Лень планировать заранее покупки, чтобы взять с собой все необходимые тары, лень идти на рынок, лень спорить с очередным продавцом в супермаркете.

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

Загрязнения пластиковыми отходами

— Приходится ли вам тратить больше времени на бытовые вопросы?

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

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

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

— Почему это не «модно», а «нормально»? :)

Сейчас популярно говорить на тему экологии. Приставки «эко» можно встретить едва ли не на каждом втором продукте. Понятие «экологичность» добралось даже до ментальных вещей: «А экологично ли будет поступать так в отношении него?».

Zero waste иногда считают едва ли не новым хиппи-течением, и это даже смешно. Часто говорят: «Вот перебеситесь и вернетесь к тому, что было, это просто мода». Мне не хочется так думать.

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

Читайте также:Від збору паперу до сонячної електростанції на терасі. Екоініціативи українських ІТ-компаній

Меня зовут Анна Пономарева, я Game Analyst в Plarium Kharkiv. В этом году наш департамент запустил мобильный RPG-проект Stormfall: Saga of Survival и теперь занимается его поддержкой. Моя задача в проекте — оперативно анализировать игровые процессы и предоставлять отчеты для корректной настройки баланса.

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

Важно не просто показать информацию, а сделать это максимально понятно и прозрачно для заказчика, выделив ключевые показатели. Как именно это сделать, я и постараюсь рассказать в статье.

Как не надо делать

Часто в попытке выжать из имеющейся информации всё мы можем получить нечто несуразное и пугающее.

Или еще хуже.

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

Этапы анализа данных

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

Формулирование цели

Каждое исследование должно отвечать на ряд поставленных вопросов — не нужно плодить исследования для исследований.

Сбор данных

На этом этапе аналитик или работает с уже собранными данными, или участвует в процессе постановки задания на сбор данных (фактически решает, какая информация ему необходима и в каком виде).

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

Подготовка данных

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

Иногда требуется расширение метрик, например добавление вычислительной информации (прирост, ранг, номер и т. п.). Иногда следует сократить количество признаков (переменных) или перейти к вспомогательным переменным, принимающим одно из двух значений: true (1)/false(0).

На этом этапе сырые данные превращаются в полезную входную информацию для моделирования и анализа.

Исследование данных

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

Визуализация и построение выводов

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

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

Необходимо также понимать, что процесс анализа данных имеет итерационный характер и может быть представлен циклом.

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

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

Выбор диаграмм для визуализации

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

Джин Желязны в книге «Говори на языке диаграмм» пишет, что (почти) каждая идея может быть выражена с помощью сравнения. Требуется лишь определить тип сравнения данных:

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

Автор предлагает использовать следующую таблицу для выбора диаграмм:

Если проводить классификацию по объектам, то можно выделить такие типы визуализации:

• детерминированные зависимости: графики, диаграммы, временные ряды;
• статистические распределения: гистограммы, матрицы диаграмм рассеяния, график «ящик с усами»;
• иерархии: диаграммы связей, дендрограммы;
• сети: графы, дуговые диаграммы;
• геовизуализация: карты, картограммы.

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

Оригинальную схему Эндрю Абела можно посмотреть тут.

Выбор диаграммы на конкретном примере

Мне необходимо было создать дашборд для контроля income/outcome-ресурсов, которые игроки добывают, находят или получают в награду. Это была достаточно сложная задача, требующая собрать воедино несколько таблиц, учесть множество нюансов и не упустить из виду ни одного источника/потребителя ресурсов.

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

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

1. Сравниваем 2 признака (количество получаемых и затрачиваемых ресурсов) — значит используем столбчатую диаграмму.
2. У нас несколько источников для получения ресурсов и способов их расхода — поэтому добавляем структуру к столбчатой диаграмме (каждый источник и потребитель обозначаем своим цветом).
3. Отслеживаем, как изменяется приход и расход ресурсов в зависимости от игрового дня, — горизонтальной оси задаем соответствующий параметр.
4. Для удобного чтения все income-действия (приход) отображаем сверху горизонтальной оси, а outcome (расход) — снизу. Это позволяет визуально оценить величину разницы.
5. Чтобы было понятно, в какие периоды жизни игрока возникает профицит, а в какие дефицит того или иного ресурса, накладываем на столбчатую диаграмму линейный график, который визуализирует вычисляемое поле разницы.

Пример выявленного профицита предмета (линейный график выше столбцов).

Пример жизненного цикла ресурса и его перехода из профицитной категории к дефицитной (линейный график ниже горизонтальной оси).

В итоге наша диаграмма показывает приход и расход ресурсов в разные игровые дни и демонстрирует наличие дефицита или профицита ресурсов.

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

Периодичность

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

• требующие непрерывного мониторинга (стандартные показатели retention, конверсии и т. п.);
• данные, динамику которых следует оценивать периодически (результаты А/В-тестов, динамику набора уровней и т. п.).

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

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

Полезные ссылки

Грамотная организация дашбордов

Игровая аналитика

Инструменты визуализации данных

Как выбрать диаграмму

Диаграммы Google

Диаграммы в Tableau

11 правил визуализации данных

Диаграмма Санкей

Книга «Говори на языке диаграмм»

Выводы

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

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

У цьому випуску — розповіді розробників з київського офісу Depositphotos та одеських HYS Enterprise, BeLight Software і Serpstat.

Depositphotos

Евгеній Слюсаренко, Team Lead команди з розробки сайту, Київ


Співробітників на проекті та в компанії: 11/400.
Тип компанії:продуктова.
Кількість деплоїв на день:3-4рази на тиждень, намагаємося не деплоїти в п’ятницю :)
Системна архітектура: API на PHP + MySQL, ізоморфний додаток на JavaScript на Front-end, а також сервіси і мікросервіси.
Операційні системи: Solaris, Linux.
Бази даних: MySQL, PostgreSQL.
Чи можна працювати віддалено:так, іноді можна, але не на постійній основі.

Евгеній Слюсаренко, Team Lead команди з розробки сайту, Київ

— Розкажіть про вашу команду і про те, над чим ви працюєте?

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

Основне завдання нашої команди — розробка сайту Depositphotos. Ми робимо і інтерфейсну частину, і те, що «під капотом». Реалізуємо рішення для корпоративних і бізнес-клієнтів, а також запускаємо нові фічі для звичайних клієнтів — покупців і авторів.

— Які інструменти розробки використовують у вашій компанії?

Для розробки ми використовуємо досить звичайний для 2018-гороку «джентльменський набір». Це Git, Jira, Fisheye, Confluence, Jenkins (CI), Slack і Skype. Для забезпечення розробки ми вирішили не використовувати весь Atlassian stack, тому що Jenkins виявився більш гнучкий, ніж Bamboo.

— На яких мовах програмування пишуть розробники?

Залежить від задач. В основному це JavaScript, PHP і Java.

— Як виглядає процес розробки, життєвий цикл продукту?

Процес розробки у нас проходить по Scrum: функціонал доставляється ітеративно, протягом спринтів. Це дозволяє замовнику реагувати на зміни і вносити коригування в розробку. Звичайні етапи — це планування, розробка, код рев’ю, тестування, переклади (якщо потрібно) і деплой.

— Як прийнято проводити код рев’ю?

Код рев’ю — обов’язковий етап в процесі розробки: код не може бути змержен без рев’ю. Будь-які дефекти коду, знайдені на рев’ю, повинні бути виправлені.

Код рев’ю ми проводимо в Fisheye. Самі рев’ю створюються автоматично після того, як задача готова. Рев’ю розділені по ролям, що дуже зручно. Наприклад, програміст на JavaScript не буде перевіряти код на Java. Якщо, звичайно, сам не захоче :)

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

— Як прийнято проводити тестування, які тести застосовуєте?

У нас є кілька видів автоматичних тестів, які запускаються після того, як задача виконана. Це перевірка стилю коду, юніт-, API- і UI-тести. Ми намагаємося покривати автотестами весь новий функціонал. І обов’язково покриваємо автотестами багфікси: якщо щось зламалося, потрібно бути впевненим, що в наступний раз це не зламається знову.

При розробці задачі, якщо всі автоматичні тести пройдено, до тестування підключаються QA. Їх завдання — перевірити роботу з точки зору користувача і прогнати «хитрі кейси». Часто вони рятують команду і знаходять проблеми, не дозволяючи багам потрапляти в продакшн :)

— Як відбувається розгортання (деплой)?

Ми практикуємо CD, тому деплой проходить кілька разів на тиждень невеликими «порціями». Але для сайту він напівавтоматичний. Є скрипти, які запускаються в продакшн-оточенні. Вони здійснюють збірку проекту і перемикають веб-сервер на нову збірку. Команда розробки не впливає на сам процес деплоя.

— Як проходить типовий робочий день розробника вашої команди?

Ранок починається з розбору повідомлень у пошті і Slack/Skype. Потім у нас проходить daily, на якому команда ділиться своїм прогресом і планами роботи. Далі розробка, тестування, спілкування в месенджерах — і не тільки. Хтось розбавляє роботу грою в теніс або настільний футбол, хтось — перекурами :)

— Скільки годин на день працюєте?

Звичайний робочий день — це 8 годин. З них близько 5-6годин йде на написання коду. Решту часу з’їдають розмови і обговорення :)

— Хто в вашому випадку є замовником, як влаштована комунікація?

Замовники у нас внутрішні. Наприклад, якщо потрібно провести A/B split з продажів, замовником може бути хтось із відділу маркетингу. Якщо потрібно сформувати звіт — то хтось із бухгалтерії. Спілкування завжди відбувається безпосередньо із замовником.

HYS Enterprise

Олександр Пригун, Team Lead C# на проекті з розробки білінгової системи, Одеса


Співробітників на проекті та в компанії: 24/150+.
Тип компанії:аутсорсингова.
Кількість деплоїв на день:до 5.
Системна архітектура:мікросервісна, більше 20 сервісів.
Операційні системи: MS Windows 2016 Server, Ubuntu 16.
Бази даних: MS SQL Server.
Чи можна працювати віддалено:в основному для спрощення комунікацій ми намагаємося працювати в офісі. Дистанційна робота також допускається, але не на регулярній основі.

Олександр Пригун, Team Lead C# на проекті з розробки білінгової системи, Одеса

— Розкажіть про вашу команду і про те, над чим ви працюєте?

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

Команда включає в себе три групи розробників, загалом 15 людей, одну QA команду, з яких 4 manual та 2 автоматизатори, а також 2 бізнес-аналітика та один UI/UX дизайнер.

— Які інструменти розробки використовують у вашій компанії?

Для розробки ми використовуємо MS Visual Studio, MS Management Studio, MS Visual Studio Code, Git. Для тестування — Soap UI, TestRail, SpecFlow. Для білда та деплоймента — TeamCity та Octopus.

Комунікація між компонентами нашої системи відбувається через Virtual Bus, який у свою чергу використовує всередині себе Soap для синхронних викликів і черги для обміну повідомленнями (MSMQ, RabbitMQ) для асинхронних викликів.

Для управління проектом і планування використовуємо Jira та EpicFlow, для комунікацій — Slack, Skype, Gmail.

— На яких мовах програмування пишуть розробники?

Для конекторів до зовнішніх систем ми використовуємо С#. Щодо опису бізнес-логіки, користуємось власною мовою Bella. Для Front-end — Angular 5.

— Як виглядає процес розробки, життєвий цикл продукту?

Розробка проекту розбита на фази, а фази — на спринти. Будь-яка фіча в системі починається зі story в Jira, описаної PO з боку замовника і доведеної до стану Ready For Refinement. Наступний крок — робота бізнес-аналітиків. Вони задають уточнювальні питання PO та вносять правки в story.

Після цього відбувається scrum poker, в результаті якого у story з’являються естімейти і вони переходять до статусу Ready To Start. Далi — планування спринта, на якому PO спільно з тімлідами визначають обсяг наступного спринта. В ході спринта відбувається розробка, тестування і баг-фіксинг згідно з пріоритезованим списком багів.

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

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

На завершальній стадії: end-to-end тестування, dry run тестування, тести продуктивності. Логічним підсумком фази є деплоймент на продакшн-сервери.

— Як прийнято проводити код рев’ю?

Після розробки фічі або виправлення бага розробник робить мердж-реквест в гілку master. Право мерджити в master мають тільки тімліди, які і проводять код рев’ю.

Для мерджа гілки в master досить тільки підтвердження тімліда.

— Як прийнято проводити тестування, які тести застосовуєте?

Протягом спринта виконуються модульні та інтеграційні тести, а також регресійне автоматизоване тестування із затримкою в один спринт.

Також, як я вже казав, на завершальній стадії фази проводиться end-to-end тестування, dry run тестування, тести продуктивності.

— Як відбувається розгортання (деплой)?

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

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

— Як проходить типовий робочий день розробника вашої команди?

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

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

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

— Скільки годин на день працюєте?

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

— Як влаштована комунікація із замовником — безпосередньо або через менеджерів?

Ключові питання із замовником вирішують тімліди та бізнес-аналітики. Проте, щоб уникнути ситуації, коли тімлід є bottleneck, із багатьох питань призначаються відповідальні з команд розробників або QA, які також спілкуються із замовником. Демо по кожній story проводить розробник, виконавець story, який і захищає свою роботу перед замовником. Таким чином, можна говорити про те, що із замовником спілкуються безпосередньо всі члени команди.

BeLight Software

Дмитро Юнчик, Project Manager проекту Live Home 3D


Кількість співробітників на проекті та в компанії: 7/30.
Тип компанії:продуктова.
Кількість деплоїв на день:поставляємо апдейти раз на кілька місяців або негайно, коли щось вкрай необхідне.
Системна архітектура:монолітний застосунок.
Операційні системи: macOS, iOS, Windows 10.
Бази даних: mySQL на веб, безпосередньо у розробці продуктів не використовуємо.
Чи можна працювати віддалено:зазвичай ні, але можливо в окремих випадках.

Дмитро Юнчик, Project Manager проекту Live Home 3D

— Розкажіть про вашу команду і про те, над чим ви працюєте?

У нашій компанії близько 30 людей, які формують декілька команд за продуктами. У нас є проекти в різних сферах: виготовлення друкованої продукції (Swift Publisher, Printworks), графічний дизайн (Art Text, Letters), інтер’єрний дизайн (Live Home 3D — саме в цій команді я є Project-менеджером), створення резервних копій файлів та систем (Get Backup Pro).

У нашій команді працює 7 спеціалістів: 5 розробників, менеджер продукту та 3D-дизайнер. А тестувальники — це окрема команда, яка тестує всі продукти компанії.

— Які інструменти розробки використовують у вашій компанії?

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

Основна робота програмістів проходить у додатку, який є інтегрованим середовищем розробки (IDE). Оскільки ми розробляємо крос-платформні додатки, ми використовуємо одразу два таких додатка: XCode на macOS та MS Visual Studio на Windows 10.

Третім важливим компонентом є система планування завдань та відстеження помилок. Тут ми користуємося відомим web-сервісом Jira.

Четвертим інструментом є сервіс зручної комунікації, ми користуємось чатом Slack. Ці чотири компоненти — основа, але є ще багато інших допоміжних додатків, які наші розробники так чи інакше використовують повсякденно: TextEdit та Preview на Mac, MSPaint та FarManager на Windows та багато інших.

— На яких мовах програмування пишуть розробники?

Усі наші проекти спроектовано із думкою про можливість портування на інші платформи за потреби, тому проекти складаються із двох основних складових: Core та UI.

Core ми кодуємо на C++. UI на Mac та iOS пишемо на Objective-C, UI на Windows — на C++/CX, це трохи модифікований C++ для написання WinRT додатків. На сьогодні це все, якщо не рахувати PHP, яким користується наш веб-програміст.

— Як виглядає процес розробки, життєвий цикл продукту?

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

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

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

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

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

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

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

Коли майже все готове, продукт набуває статусу beta, інколи ми запускаємо публічне бета-тестування. Наприклад, так було нещодавно з Live Home 3D для iOS. За два з половиною місяці до релізу ми випустили TestFlight версію та залучили понад 1000 сторонніх тестувальників. У цей час команда працює над виправленням знайдених проблем, і нові білди публікуються для подальшого тестування.

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

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

— Як прийнято проводити код рев’ю?

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

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

— Як прийнято проводити тестування, які тести застосовуєте?

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

— Як відбувається розгортання (деплой)?

Ми робимо додатки для кінцевих споживачів, тому деплоя як такого немає. Додатки потрапляють на комп’ютери та гаджети наших користувачів найпростішим на сьогодні шляхом — через системний магазин додатків. Це Mac App Store та App Store на macOS та iOS відповідно, Microsoft Store на Windows.

— Як проходить типовий робочий день розробника вашої команди?

Спочатку кава, потім до праці! Починаємо робочий день з отримання в TortoiseHg свіжих комітів своїх колег, зливаємо зі своєю ще не «відпущеною» роботою, компілюємо проект. Паралельно треба перевірити пошту — там вже можуть бути свіжі завдання чи зауваження. У нас немає якихось жорстких правил, чим має займатися програміст. Головне, щоб робота в проекті рухалася вперед.

Зазвичай, основна робота програміста — писати код, але часто треба допомогти колезі. Тут виникають моменти XP програмування. Іноді трапляються обговорення чогось у проекті, і це може затягнутись на кілька годин, але це теж частина роботи розробника.

— Скільки годин на день працюєте?

У нас доволі вільний графік роботи з 10:00 до 19:00 плюс-мінус година. Раніше прийшов — раніше пішов, пізніше прийшов — прибиральниця миє тобі ноги шваброю. Хоча, якщо бути точнішим, програмісти намагаються «дописувати до крапки» — краще сьогодні зупинитись на чомусь логічно завершеному, тоді завтра швидше можна буде продовжувати. Узагалі-то гарний програміст постійно пише код, хоч би й подумки, коли вечеряє вдома чи дивиться новини по телевізору.

— Хто у вашому випадку є замовником, як влаштована комунікація?

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

Serpstat

Александр Майстренко, СТО компанії


Кількість співробітників у компанії: 30/80+.
Тип компанії:продуктова.
Кількість деплоїв на день:раз на два тижні, оскільки в нас CI.
Системна архітектура:сервіс-орієнтована архітектура, де є головний сервіс — Serpstat та декілька мікросервісів, які виконують свої ролі.
Операційні системи: Unix-системи.
Бази даних: MySQL, Elasticsearch, Cassandra.
Чи можна працювати віддалено:ми працюємо з віддаленими Front-end програмістами, але віддаємо їм тільки легкі задачі та ті, що не підлягають під NDA.

Александр Майстренко, СТО компанії

— Розкажіть про вашу команду і про те, над чим ви працюєте?

У нас один продукт — Serpstat. Ми покращуємо ті сервіси, які в нас вже існують, та розробляємо нові інструменти. Останнім вийшов «Перелік завдань» — інструмент, який дозволяє SEO-спеціалістам розуміти, що їм потрібно робити з їхнім проектом. Також ми постійно покращуємо алгоритми парсингу пошукової видачі.

Зараз у нас близько 30 людей у команді розробки. Це Back-end та Front-end розробники, тестувальники, математики-аналітики, дизайнери.

Коли почалося бурхливе зростання продукту, до нас долучилося понад 15 розробників, і ми розділили усю команду на 7 мікрокоманд. Кожна команда відповідальна за окремий набір інструментів або модулей продукту:

• пошукової аналітики та переліку завдань;
• моніторингу позицій, кластеризації та текстової аналiтики;
• демони пробивки та парсингу пошукової видачі;
• аудиту сайту;
• аналізу зворотніх посилань;
• інтеграції та розробки віджетiв;
• міжмодулева команда.

У складі кожної команди є відповідальний проектний менеджер та два-три розробники, один з яких — Developer Master.

— Які інструменти розробки використовують у вашій компанії?

Ми розробляємо на PHP, Python та JavaScript (React). Використовуємо такі технології, як Redis, RabbitMQ, Elasticseacrh, MySQL, Cassandra, будуємо сервіс-орієнтовану архітектуру. У нас вже є декілька мікросервісів, написаних на Symfony 4, PHP 7.2. Ці мікросервіси спілкуються за допомогою внутрiшнього SOA SDK — це наша власна розробка, яка дозволяє всередині одного сервісу звертатися до моделей іншого сервісу так, ніби вони знаходяться тут і зараз. Це можливо завдяки патерну проектування Proxy Object. Тобто це високорівнева абстракція над сервіс-орієнтованою архітектурою.

— Як виглядає процес розробки, життєвий цикл продукту?

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

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

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

— Як прийнято проводити код рев’ю?

Код рев’ю проводиться відразу після завершення технічної роботи над задачею. Розробник створює merge request у репозиторій та переводить задачу на тімліда у Redmine. Тімлід виокремлює деякий час та механічно передивляється кожний коміт кожного розробника. Саме зараз ми впроваджуємо змiни в цьому процесi. Код рев’ю в мiкрокомандi буде проводити Developer Master, а йому код рев’ю буде проводити тімлід.

— Як прийнято проводити тестування, які тести застосовуєте?

Команда тестувальників складається з 9 спеціалістів. Процесс влаштований так: задачі потрапляють на тестування, QA Lead розподіляє їх серед команди для ручного тестування. У кожній задачі є definitions of done — критерії, за якими задача вважається виконаною. Тестувальники перевіряють, чи все виконано згідно з ТЗ постановника, та відмічають галочками definishens. Якщо є невідповідність, задача повертається на доопрацювання.

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

Сервiси, які написані на Symfony, покриваються юніт-тестами. Це тести, якi пишуть самі розробники, коли вносять правки у код чи розробляють нову фічу. Такi тести дозволяють переконатися в атомарнiй цiлiсностi коду до того, як задача потрапить до QA-відділу.

— Як відбувається розгортання (деплой)?

Ми дотримуємось парадигми Continuous Integration (CI), тобто код не потрапляє одразу на продакшн. У нас є буфер, куди складаємо код виконаних задач до релізу. Потім ці задачі викатуються на прод. Для цього в нас є такий інструмент, як Jenkins. У ньому написані джоби, які виливають на прод Back-end, Front-end і мікросервіси нашого продукту.

— Як проходить типовий робочий день розробника вашої команди?

Розробник може прийти з 8-їдо 10-їгодини та вiдмiчається у внутрішній CRM. О 10:30 відбувається Daily Meeting, на якому розробник розповідає, над чим він працював вчора, які труднощі виникали, які таски планує закрити сьогодні. Мітинг проходить у декілька етапів по командам. Після мітингу розробник повертається безпосередньо до написання коду.

Раз на тиждень СЕО проводить загальні збори усієї команди, де презентує визначні результати команд. Також вітають з днем народження, підвищенням коллег, проходженням випробувального терміну або усілякими приємними дрібничками.

Наприкiнцi спринта ми проводимо ретроспективу, на якiй кожен висловлює:

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

— Скільки годин на день працюєте?

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

Можна приходити в офіс хоч о 8-йранку, хоч о 10-йта виходити з офісу 5-йвечора чи працювати скільки заманеться, якщо розробник не хоче кидати незакінчену роботу. У такому випадку цей час рахується як робочий. Проте ми проти овертаймів, бо це погано впливає на зосередженість та продуктивність наступного дня чи цілого тижня. Краще пiти додому та використати вiльний час для саморозвитку.

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

— Хто у вашому випадку є замовником, як влаштована комунікація?

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

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

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

Пишіть у коментарях, про які інші особливості роботи в компаніях ви б хотіли дізнатись у наступних випусках рубрики. Цікаві питання будемо додавати в анкету.

Див. також: Як це — бути розробником в Intellias, Genesis, SimCorp та Splynx.

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

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

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

На практике дискавери-фаза длится до 1 месяца. Почти никто не инвестирует в этот процесс так, чтобы он длился 2-4 месяца.

Хочу отметить, что не всегда дискавери-фаза проводится до подписания контракта. Бывают случаи, когда тендер уже был проведен, контракт подписан, а требований нет. Вот тут и нужно быстро понять, что нужно сделать.

Задача — помочь клиенту

Есть две команды — заказчика и вендора. Со стороны вендора ее состав обычно такой:

• проектный менеджер или человек, который отвечает за продажу;
• бизнес-аналитик;
• дизайнер;
• технический эксперт.

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

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

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

Важен опыт команды

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

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

Возьмем бизнес-аналитика. Если у него мало опыта, то он будет задавать не те вопросы и решать не те проблемы. Когда у бизнес-аналитика за плечами не одна дискавери-фаза и реализованный проект, он уже четко знает, какие вопросы и когда задавать. Поэтому и качество артефактов, которые выйдут в итоге, будет намного выше.

Не скупитесь на профессиональные кадры для продажи и запуска проекта, это поможет команде стартовать с меньшими проблемами.

Слаженность команды

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

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

Ваша задача как профессионала — рассказать последовательность ваших действий, объяснить, какая помощь для этого нужна. То есть разложить клиенту все по полочкам. Для этого и нужны kick-off, где вы представляете свою команду, рассказываете, чем вы будете заниматься, какая дальнейшая работа. Конечно же project manager может рассказать глобально, но за то, как будет проходить процесс сбора требований, ответственны именно вы!

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

Обязанности бизнес-аналитика на дискавери-фазе

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

• Use cases — основные сценарии работы с системой или приложением.
• Бизнес-процессы. Вы должны посмотреть, какие процессы уже есть и попытаться описать, какими они должны быть. Процессы всегда есть, даже если они не описаны. Почитайте про концепт (as is / to be).
• Должностные инструкции. В любой компании, особенно большой, есть такие инструкции. Ознакомьтесь с ними, узнайте, чем занимаются люди и что входит в их обязанности.
• Отчеты. Найдите все отчеты, которые используются внутри компании. Это поможет вам понять структуру данных, что есть на сегодняшний день и чего не хватает для полной картины.
• Скриншоты текущих систем. Делайте скриншоты всего, что только можно — чтобы было с чего начать и не придумывать с нуля.
• User stories — если после дискавери-фазы у вас нет списка user stories с высокоуровневыми описанием требований, значит вы провалили эту фазу!

Если вы крутой бизнес-аналитик, то вы должны с самого начала создавать и структурировать backlog. Рекомендации:

• Будьте проактивными и направляйте клиента, потому что не он делает проект, а именно вы!
• В момент выявления или сбора требований нужно делать assumptions (предположения). Это поможет вам в будущем при оценке проекта и разработке.
• Начинайте думать с самого начала категориями «epic» и «user story» — это поможет вам дальше управлять backlog’ом, который зайдет в проект.
• Перед тем как идти на какие-либо встречи, читайте про доменную область.
• На все встречи ходите с дизайнером, потому что вы должны понимать проект на одном уровне.
• Не бойтесь задавать глупые вопросы. Лучше задать глупые вопросы и выдать хороший результат, чем не спросить ничего и облажаться. Эта мудрость пришла ко мне с годами :)

Обязанности дизайнера

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

Если речь идет о разработке программного обеспечения для внутреннего использования, не придумывайте велосипед. Так и скажите дизайнеру — не нужно изобретать то, что только затруднит работу пользователя внутри организации. Интерфейс должен быть как можно проще, и желательно, чтобы он имел схожие паттерны поведения с глобальными продуктами (MS, SAP, Oracle).

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

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

Задача технического специалиста

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

Результаты дискавери-фазы

Результат работы бизнес-аналитика на дискавери-фазе — всевозможный материал, собранный на стороне клиента: документы, артефакты и понимание, что нужно сделать.

Почему я говорил изначально «думайте через epiс и user story»? Потому что для того, чтобы составить коммерческое предложение, вам нужно создать WBS (work breakdown structure). Каждый кусок информации, который вы получили на дискавери-фазе, поможет sales-команде построить правильное коммерческое предложение.

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

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

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

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

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

Чтобы понять, насколько применимо ДЗ для поиска специалистов, попробуем ответить на 2 вопроса:

• Какие выводы можно сделать из невыполненного задания?
• Какие выводы можно сделать из выполненного задания?

Какие выводы можно сделать из невыполненного задания

Можем ли мы сказать, что кандидат не является хорошим специалистом, если он не выполнил ДЗ? К сожалению, нет. Оказывается, что у людей бывают и другие интересы помимо программирования. И поскольку программированием человек занимается 8 часов (ну или 4-6)на работе, то в свободное время ему логично уделять другим своим интересам. Те же, кому не хватает 8 рабочих часов для любимого занятия, довольно часто имеют свои пет-проекты, и совсем не факт, что ваше ДЗ будет интереснее, чем уже начатые проекты. Бывает и еще одна категория людей — те, у кого не установлено все необходимое для работы на домашнем компьютере. Таким образом, в придачу к тем, кто не может выполнить задание, мы также отсеиваем тех, кто не хочет выполнять или не может выделить достаточно времени на выполнение задания.

Какие выводы можно сделать из выполненного задания

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

Излишне позитивное впечатление от ДЗ может создать похожие проблемы и при найме «не джуниоров». Как-то во время собеседования у меня не спрашивали ни одного вопроса по Spring, потому что «из моего решения было очевидно, что у меня большой опыт с этим фреймворком». На тот момент мой опыт со Spring состоял из 2 просмотренных видосиков и проекта длиной в 3 дня.

Размер и типы заданий

В размере тестового задания как раз и кроется основной фактор, который делает его неэффективным инструментом. Если задание занимает менее часа, то его вполне можно дать во время собеседования. При таком подходе есть возможность проверить те самые «problem solving skills», которые многие путают с алгоритмическими задачками. Как раз благодаря небольшому времени на решение довольно популярны алгоритмические задачи. Из плюсов таких задач можно отметить простоту проверки, ибо если код читабельный (это требование актуально для всех адекватных компаний), то на проверку такой задачи уйдет минут 10-30.А еще есть Codility и другие сервисы, которые позволяют автоматизировать процесс. К сожалению, у этого подхода есть небольшой недостаток: сама алгоритмическая задачка проверяет только знание кандидатом конкретного алгоритма (максимум группы алгоритмов). Многие подсознательно устанавливают порядок между базовыми знаниями CS и всем остальным (работа с БД, корректное применение паттернов, умение писать тесты и т.д.). В реальном мире эти навыки параллельны.

В задание менее 4 часовдовольно сложно впихнуть задачу, требующую большего, чем просто выполнение механических действий. Именно поэтому типовые задачи в диапазоне 2-4часа — это напилить CRUD, разобраться с API или инструментом. С точки зрения проверки такого задания, оно схоже с ревью небольшого незнакомого вам проекта. Если задача — просто быстро понять, нет ли грубых залетов, такое ревью можно и на 15 минут сделать. Но в таком случае зачем было давать тестовое, подобное решение может быть закрыто прочтением резюме и тем же 15-минутнымобщением с кандидатом по телефону (если уж хочется сэкономить время на проведение собеседования). Более же вдумчивое ревью займет минут 30-60,что соизмеримо по времени с общением на интервью, но проверяющий не имеет возможности уточнить, почему были приняты те или иные решения, в отличие от интервью.

Задания от 4 часов до 2-3 дней.Из позитивных моментов, вы сможете проверить насколько кандидат мотивирован получить работу в вашей компании (по крайней мере насколько он прямо сйечас мотивирован). При этом в плане затрат вашего времени на вдумчивую проверку задания уйдут те же 30-60 минут,но уже с большей вероятностью 60, чем 30. На таких заданиях уже можно ожидать какого-то определенного уровня качества. При этом нужно понимать, что любое решение задачи — это всегда trade-off между качеством и скорость выполнения. И вполне может оказаться, что решение было сделано хуже, чем могло бы быть, как раз потому что кандидат не сложен к overengineering. Чтобы узнать, почему было принято определенное решение, нам нужно таки провести собеседование. Таким образом, мы потратили дополнительно час своих работников. Также необходимо понимать, что любое задание, которое занимает больше одного вечера (теоретически вечер — это 4 часа, в реальности — 2), очень существенно уменьшает количество желающих его выполнять.

Идеальное тестовое задание — это испытательный срок (ИС).Практика показывает, что большинство негативных моментов связанных с компетентностью человека и его умением работать в команде, всплывают в первую неделю-две испытательного срока (конечно же, бывают случаи, когда такие моменты проявляются уже после ИС, независимо от его длины :) ). Поэтому некоторые компании практикуют ДЗ на 3-5 дней.За этот период мы можем увидеть, как человек решает достаточно комплексные задачи, насколько качественный код он выдает, как общается с командой (уточняя требования, например). Тут есть 2 проблемы. Первая — затраты времени со стороны компании будут составлять где-то 1 час на день задания. Вторая проблема состоит в том, что множество людей, которые согласятся его выполнять, будет сведено к тем, у кого (на момент решения задания) достаточно свободного времени, чтобы впихнуть в него 24-40рабочих часов, и достаточно денег, чтобы потратить 24-40часов не на работу и не на отдых. Хотя это, наверное, не проблема, а просто новый вызов для ПМов и ХРов: как мотивировать такого человека работать предсказуемо в течение длительного периода времени :)

Ранее были описаны случаи, когда ДЗ идет как этап, предшествующий интервью. Бывают случаи, когда ДЗ дают после интервью.Зачем же? Формулировки бывают разные, но они сводятся к тому, что после интервью наниматель не получил достаточно информации, чтобы принять решение. К сожалению, ДЗ и в этой ситуации не помощник. Тут нужно приводить в порядок процесс самого интервью. Понять, что человек не подходит, можно за 15-45 минут,понять, что человек подходит, можно за 30-60.В этом случае ДЗ — это просто попытка интервьюера снять с себя ответственность.

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

Когда тестовое задание эффективно

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

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

Но я люблю делать тестовые задания

Бывают случаи, когда кандидаты предпочитают делать ДЗ. Наиболее распространены 2 типа мотивации: кандидату интересно делать ДЗ, кандидат предпочитает сделать ДЗ вместо «задачи на бумажке». В первом случае все намного проще: нравится — делайте. Но, возможно, стоит задуматься о более предсказуемых способах получения задач для своего хобби или самообучения. Второй же случай сигнализирует о серьезном пробеле в ваших профессиональных навыках. Ибо, как указывалось ранее, «задачки на листиках» проверяют во многом способность человека получить необходимую для решения информацию и объяснить свой подход другому человеку (интервьюеру или члену команды).

Image by Visual Generation

В этой статье вспомним, что такое Garbage collection (GC), зачем он нужен вообще и какие проблемы решает. Детально рассмотрим режимы работы GC в .NET, поймем, как работает каждый из них, их особенности и различия. Затронем специфику применения некоторых режимов GC в .NET.

Изучим вопрос мониторинга работы GC, какие доступны для этого инструменты и как ими пользоваться.

Введение

Вообще, откуда взялась эта тема? Она появилась из-за поведения наших сервисов, в том числе и на production. Мы увидели, что некоторые приложения начали отнимать 30% CPU. Не могли понять, почему это происходит — ведь по коду все было хорошо. Провели анализ метрик, о которых поговорим позже, и выяснили, что GC потребляет на сборку мусора порядка 30%. И тут возник вопрос — что же с этим делать. Появилось поле для оптимизации. И мы добились хороших результатов, когда после всевозможных манипуляций снизили потребление CPU до 10%, до 5%. Как этого можно добиться, я расскажу ниже.

Когда я задался вопросом и начал готовить эту статью, мне было интересно, а когда у нас появился первый язык, который уже поддерживал сборку мусора. Я даже немного удивился, потому что это был 1964 год. 50 лет назад люди уже задумывались о том, что разработчиков нужно освобождать от занятий с памятью. Это был язык APL. Из языков, которые поддерживают сборку мусора, можно назвать Erlang (1990 год), Eifel, Smalltalk (1972 год), конечно же, C# и любой современный язык, который выходит сейчас, например Go. Это уже must have.

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

Что такое Garbage Collection

GC (Garbage Collection — сборка мусора) — высокоуровневая абстракция, которая избавляет разработчиков от необходимости заботиться об освобождении управляемой памяти.

Давайте вспомним основные тезисы по сборке мусора. В .NET сборка мусора основана на трассировке.

Существует понятие корневых элементов приложения. Корневым элементом (root) называется ячейка в памяти, в которой содержится ссылка на размещаемый в куче объект. Строго говоря, корневыми могут называться такие элементы:

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

Во время процесса сборки мусора исполняющая среда будет исследовать объекты в куче, чтобы определить, являются ли они по-прежнему достижимыми (т. е. корневыми) для приложения. Для этого среда CLR будет создавать графы объектов, представляющие все достижимые для приложения объекты. Кроме того, следует иметь в виду, что сборщик мусора никогда не будет создавать граф для одного и того же объекта дважды, избавляя от необходимости выполнения подсчета циклических ссылок, который характерен для программирования в среде COM.

Фазы сборки мусора:

1. Маркировка (mark phase).
2. Чистка (sweep phase).
3. Сжатие (compact phase).

Поколения объектов: нулевое, первое, второе поколение.

Нулевое и первое поколения еще называют эфемерными поколениями. Они нужны для ускорения отклика нашего приложения.

Для работы приложения CLR инициализирует 2 сегмента виртуального адресного пространства — Small object heap (объекты до 85 КБ) и Large object heap (объекты свыше 85 КБ, в некоторых случаях массивы и связанные списки (linked list), не достигшие данного размера).

Конфигурирование GC довольно простое, что отображено на следующем рисунке:

Рисунок 1. App.config

Конфигурировать режимы работы GC можно путем добавления в app.config секции, показанной на слайде выше, с помощью параметров gcConcurrent, gcServer.

Режим рабочей станции

Рисунок 2. Процесс сборки мусора в режиме рабочей станции

Если мы откроем любую книгу по .NET, любую статью по .NET, где у нас описано, как работает Garbage Collection, обычно это звучит так: работает приложение, не хватает памяти для того, чтобы выделить следующий объект, и происходит запуск GC. При этом все активные потоки приложения приостанавливаются. Это самый простой процесс сборки мусора — workstation non-concurrent mode.

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

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

Параллельная сборка мусора

Рисунок 3. Параллельная сборка мусора

Для этого существует режим параллельной сборки мусора (workstation concurrent GC).

Параллельная сборка мусора в .NET 1.0–3.5

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

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

Как и оптимизация, параллельная сборка мусора позволяла проводить очистку объектов, которые не были обнаружены ни в одном из эфемерных поколений, в отдельном потоке. Это сокращало (но не устраняло) необходимость в приостановке активных потоков исполняющей средой .NET. Тем более, параллельная сборка мусора позволяла размещать объекты в куче во время сборки объектов неэфемерных поколений.

Фоновая сборка мусора

Рисунок 4. Фоновая сборка мусора

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

Механизм сборки мусора в .NET 4.0 был улучшен так, чтобы на приостановку потока, связанного с деталями сбора мусора, требовалось меньше времени. Благодаря этим изменениям процесс очистки неиспользуемых объектов поколения 0 и 1 стал оптимальным. Он позволяет получать более высокий уровень производительности приложений.

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

Режим сервера

Особенности работы GC в режиме сервера.

• Сборка выполняется в нескольких выделенных потоках, выполняемых с приоритетом THREAD_PRIORITY_HIGHEST .
• Для каждого процессора предоставляется куча и выделенный поток, выполняющий сборку мусора, и сборка куч выполняется одновременно. Каждая куча содержит кучу небольших объектов и кучу больших объектов, и все кучи доступны из пользовательского кода. Объекты из различных куч могут ссылаться друг на друга.
• Так как несколько потоков сборки мусора работают совместно, для кучи одного и того же размера сборка мусора сервера выполняется быстрее сборки мусора рабочей станции.
• В сборке мусора сервера часто используются сегменты большего размера. Однако обратите внимание, что это только обобщение: размер сегмента зависит от реализации и может изменяться. При настройке приложения не следует делать никаких предположений относительно размера сегментов, выделенных сборщиком мусора.
• Сборка мусора сервера может оказаться ресурсоемкой операцией. Например, если на компьютере с 4 процессорами выполняется 12 процессов, в каждом из которых применяется сборка мусора сервера, будут использоваться 48 выделенных потоков сборки мусора. В случае высокой загрузки памяти, если все процессы запускают сборку мусора, сборщику мусора понадобится выполнить планирование работы 48 потоков.

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

Рисунок 6. Визуализация работы Garbage Collection в режиме сервера

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

Рисунок 7. Server Background Mode

Начиная с .NET Framework 4.5, фоновая сборка мусора сервера является режимом по умолчанию для сборки мусора сервера. Этот режим функционирует аналогично фоновой сборке мусора рабочей станции, описанной выше, однако с некоторыми отличиями. Для фоновой сборки мусора рабочей станции используется один выделенный поток фоновой сборки мусора, тогда как для фоновой сборки мусора сервера используется несколько потоков — обычно по одному выделенному потоку для каждого логического процессора.

Инструменты мониторинга

GC class

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

Performance Monitor

Одним из самых мощных инструментов для обнаружения проблем с производительностью в Windows являются встроенные счетчики производительности, так называемые Performance counters. Оснастка Performance monitor — основной инструмент для управления ими.

Performance Viewer

Performance Viewer основан на трассировке событий Windows. Чуть позже поговорим о том, что это такое, зачем это нужно и что можно вообще мониторить с его помощью.

SOS Debugging Extension

SOS Debugging Extension стоит отметить, но уже мало кто использует этот инструмент.

dotMemory

Платный представитель от JetBrains. Стоит отметить, что его open source конкуренты на текущий момент мало в чем ему уступают.

Concurrency Vizualizer

Concurrency Vizualizer — расширение для Visual Studio. К мониторингу памяти относится очень косвенно. При этом оно очень информативное, так как позволяет увидеть множество параметров по работе приложения в многопоточной среде. С помощью этой утилиты можно проанализировать, когда потоки приостанавливаются, восстанавливают свою работу и т. д.

Performance Monitor

Рисунок 8. Счетчики Performance Monitor

Какие счетчики (counter) предлагает Performance Monitor? Первый счетчик, на который стоит обратить внимание — это процент времени, которое было потрачено самим GC. Этот счетчик делает замеры между двумя сборками мусора, считает циклы процессора, циклы, которые были потрачены в общем и которые были потрачены на сборку мусора. Например, если между двумя сборками прошел 1 миллион циклов процессора и при этом из них 300 тысяч потрачено на сборку мусора, то, соответственно, наше приложение 30% времени тратит просто для того, чтобы собирать мусор.

На какое значение нужно обращать внимание? Это довольно сложный вопрос. К примеру, мы получили цифру 17. Что мне с этой цифрой делать дальше? Из опыта рекомендую обращать внимание на значение 50%. Если 50% — значит половину времени мы тратим впустую. Если это время тратится еще в дата-центрах, то тратятся деньги. И с этим надо что-то делать. Если мы видим цифру в 10 %, то для того, чтобы опустить ее на 5, нужно потратить столько денег, что даже не стоит в это вкладываться.

Следующий параметр, на который стоит обращать внимание — Allocated bytes/second. Он показывает число байтов в секунду, которые мы можем аллоцировать в памяти. Можем посмотреть, какой размер занимает нулевое поколение, первое, второе поколение, сколько занимает Large Object Heap, как перетекают объекты из нулевого поколения в первое, из первого — во второе, количество выживших объектов и т. д.

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

Пример, как использовать этот инструмент, показан на рисунке 9.

Рисунок 9. Работа с Performance Monitor

Performance Viewer

На мой взгляд, это один из лучших инструментов на текущий момент. Также радует, что производители уже начали задумываться о том, что же делать с Linux, что очень актуально для приложений, написанных под .NET Core. Уже сейчас на их сайте есть небольшой туториал, как снимать метрики с докер хостов. Надеюсь, они будут продолжать развиваться, и мы получим очень хороший инструмент.

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

Рисунок 10. Работа с Performance Viewer

Инструмент довольно простой (см. рисунок 10): нажимаем collect и собираем нужные нам метрики. Совет для тех, кто будет использовать — не собирайте метрики долго. Сделал большую ошибку: собрал метрики за минуту и потом ждал пока распарсится минут семь, потом бросил. Должно хватить 5-10 секунд,чтобы понять, что происходит с вашим приложением и что с ним делать. Инструмент может показать все, что связано с GC. На слайде выделены данные, которые касаются GC-статистики. Показывается режим GC, в котором запущено наше приложение, время, которое было потрачено на паузы GC, процессорное время, которое было потрачено, количество сборок мусора в каждом из поколений, минимальные паузы, пики.

События трассировки

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

Что вообще можно мониторить в .NET в среде CLR? GC, Runtime, Exceptions, Thread pool, Stack и т. д. Детально о всех метриках можно почитать здесь.

Cейчас мы рассмотрим Garbage Collection в событиях (event), и что они нам позволяют мониторить. Они нам позволяют собирать сведения, которые как раз и относятся к сборке мусора: когда она началась, когда закончилась, в каком поколении. Как долго длилась не покажут — нужно вычислять самому, и это нетривиальная задача. Нетривиальная потому, что если мы посмотрим на режим рабочей станции, когда у нас нет никаких конкурентных режимов, то там все просто: потоки остановились, приостановились, возобновились. И эту дельту мы можем словить по разнице. Когда мы вспоминаем высокоприоритетную сборку мусора, то тут уже все далеко не тривиально. Поэтому уже лучше пользоваться теми инструментами, которые у нас есть.

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

На рисунке 11 показан небольшой пример, как можно запустить трассировку событий используя TraceEvent Library.

Рисунок 11. Пример кода

На рисунке 12 происходит магия в части того, как мы собираем все эти счетчики. А вот что из всего этого вышло уже отображено на рисунке 13.

Рисунок 12. Пример кода

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

GC-визуализация

Рисунок 13. Визуализация GC

Есть довольно интересный блог, который ведет Мэт Уоррен. В нем можно найти очень много интересной и полезной информации: как работает Garbage Collection, что же происходит на самом деле «под капотом».

Рисунок 14. Визуализация GC от Мэта Уоррена

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

Рисунок 15. Таблица данных тестирования в разных режимах

В следующей таблице собраны метрики, полученные в результате тестирования одного и того же приложения в разных режимах. Было запущено приложение, основной задачей которого была генерация memory-трафика. Что мы видим? Серверный режим, действительно, уменьшает паузы работы GC, уменьшает количество запусков итераций сборки мусора, но это все делается за счет более интенсивного использования CPU и за счет более интенсивного потребления памяти. Об этом всегда нужно помнить. Если у нас десктопное приложение, в котором нам нужен максимальный отклик, то этот режим явно не для него.

Выводы

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

Полезные ссылки

• Garbage Collection
• Maoni’s WebLog
• The .NET Framework 4.5 includes new garbage collector enhancements for client and server apps
• Visualising the .NET Garbage Collector
• Examples of GC visualization
• PerfView
• CLR ETW Events
• Memory Performance counters

Продовжуємо говорити про технічні співбесіди (якщо не читали — перегляньте і попередні статті про інтерв’ю з HRта технічні). Цього разу ще більше суб’єктивного досвіду, мінімум порад, а також трішки про тестові задачі та теоретичні питання. Поїхали.

Disclaimer: автор — не турбодевелопер, а звичайна веб-макака без претензій. Тому наведені задачі та рішення можуть викликати у вас посмішку, баттхерт та бажання вказати автору на його некомпетентність. З нетерпінням чекаю вас у коментах! :)

Обговорення виконаних тестових завдань

З минулої частини ви пам’ятаєте, що я робив аж два тестові завдання: перше на Devops Engineer, друге — на Ruby Developer. Розкажу, що ж було далі.

Співбесіда на Ruby Developer — інтерв’юер навіть не подивився на моє тестове, не задав по ньому жодних запитань, не зробив мені комплімент (я виконав завдання найкраще з усіх минулих кандидатів, принаймні так мені полестила рекрутер). Таке враження, що він про нього й не знав. Це мене трішки засмутило, адже потім мене почали питати теорію і врешті-решт через теорію і зареджектили.

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

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

Задачі на співбесідах

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

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

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

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

Мав я співбесіду в одну компанію на позицію Java Developer. Компанія робить щось типу CRM-ів та пише купу інтеграцій. Я зв’язався з технічним спеціалістом по Zoom і він каже: «Почнемо з алгоритмічної задачі». Я відповідаю: «Ок, задачу я зроблю, але в мене одне питання: у вас в роботі знадобляться ці знання, вам потрібно вирішувати схожі завдання?». На що отримую феноменальну відповідь: «Ми пишемо рест ендпоїнти і ганяємо туди-сюди json-чики, але ж про це нецікаво говорити,тому давай вирішувати задачу». Тобто сам інтерв’юер зізнався у своїй некомпетентності. Не знаю, як хто, а я вже з цього моменту зрозумів, що мені там ловити буде нічого. Проте зі спортивного інтересу розмова продовжилася.

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

Я повторив умову задачі інтерв’юеру, щоб переконатися, чи правильно я її зрозумів, на що отримав ствердну відповідь і почав працювати. Через 5 хвилин з’ясувалося, що умову я зрозумів неправильно, і потрібно було знайти не сам підрядок, а його довжину (це було простіше). Але я сказав: «Ну раз почали, то давайте вже вирішувати задачу із зірочкою, а не просто так». Інтерв’юер був трішки збентежений, тому що в нього там десь були на готові тести саме для його умови, але я вирішив, що задню давати не буду і спробую зробити, як є. Я запитав, скільки в мене є часу (близько 40 хвилин) і почав кодити. Зауважу, що, хоча я знав, що будуть давати задачі, спеціально я не готувався.

Отож, я відразу написав тести і почав шаманити з i, j та k індексами :) Циклами в циклах і так далі. Десь через 15-20 хвуже мав наполовину робоче рішення, але не проходили едж-кейси, які надав інтерв’юер. Ще 20 хв пішло на едж-кейси, і в результаті, здається, я таки правильно зробив цю задачу. Інтерв’юер ніби задовільнився рішенням і далі запитав мене про структури даних. Виявилося, що для вирішення тієї задачі, яку він планував дати спочатку, можна було б застосувати хешсети чи щось таке, і він ніби очікував такого рішення, але я все зламав.

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

Яку помилку зробив інтерв’юер — він не зафіксував умову задачі в тексті. Коли я проводив такі співбесіди сам, то я просто копіпастив умову задачі у редактор коду, тому в кандидата не лишалося жодних запитань.

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

Ще мав співбесіду на позицію Ruby Developer.Після знайомства і дефолтних питань мені дали завдання написати each_slice метод. Для тих, хто не знає, — це така штука, яка ділить масив на підмасиви заданого розміру і виконує для кожного підмасиву блок, який ми передали, або повертає ітератор. Ну я сів писати, і тут у мене увімкнувся тупінг. Проблема в тому, що на Ruby я досить довго та успішно займався тільки веб-макакінгом і, як еталонний вайтішник, не знав деяких базових конструкцій мови. А саме не знав, що індекс в циклі for є іммутабельним (на відміну від якоїсь Java, де з цим немає проблем).

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

У мене серйозно бомбануло, тому що я не звик так просто програвати. Щоб хоч якось вийти в екзистенціальний плюс, я написав рекрутеру, що зламався на задачі, яка не має стосунку до реальної роботи. Потім я заспокоївся, сів, швиденько затестив, як працюють індекси в циклах. Зрозумів, що я зробив джуніорську помилку, переробив індекс і мав готове рішення. Фактично помилка в мене була в одному рядку. Я це сказав HR і сказав, щоб хлопці подивилися кодерпад, якщо їм цікаво, бо я таки вирішив задачу. Але вона відповіла: «Ви не пройшли далі, тому що не вирішили задачу прощавайте». Я ще трошки понив їй про зламані процеси інтерв’ю, щоб якось себе виправдати, і на тому ми розійшлися.

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

Ще я мав співбесіду на позицію Java Developer.Цього разу вона проходила трішки в інакшому форматі. Ми зв’язалися по Zoom, і інтерв’юєр каже: «Давай свій e-mail, я тобі вишлю задачу, почитаєш, скажеш, чи все зрозуміло. У тебе буде дві години, я буду на м’юті та не буду дивитися, що ти там робиш (екран не шаримо). Через дві години виходимо на зв’язок, шариш екран і дивимося, що ти там зробив. Користуватися можна чим завгодно». Я почитав умову задачі, проговорив її ще раз з інтерв’юером, відключив відео (тому що кодування відео їсть CPU) та став на м’ют. Відкрив IDE та розпочав роботу.

Завдання було пов’язане з I/O — треба було зробити API для запису текстових даних у файл на диску, так, щоб все було thread safe і швидко, і ще написати юніт-тести, які би то все перевіряли. Давно не працював з concurrency та I/O, тому довелось швиденько пробігтися по доках і згадати, що там до чого. У результаті я сів і написав рішення в лоб, перевірив, що воно thread safe і так далі. На все про все в мене пішло десь півтори години. Я пінганув мого інтерв’юера, сказав, що я вже типу готовий. Залишилося тільки всілякі дрібниці доробити, може, будемо дивитися? На що він відповів: «Давай ще півгодинки посиди, дороби все, що не доробив». Ок, я сів і довів до ладу всі дрібнички, дописав джава-доки, ще раз прочитав все, що міг про I/O, і подумав, які недоліки є в мого рішення.

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

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

Чим було хороше це завдання?

• Наближеність до реальної роботи, до того, чим займаються в тій конторі.
• Обмеження за часом.
• Відсутність спостереження.
• Можливість користуватися чим завгодно, а не перевірка пам’яті.
• Створення підґрунтя для подальшої розмови.
• Завдання, як на мене, непогано перевіряло вміння кандидата кодити, користуватися пошуком та IDE та думати в цілому.

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

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

Типові помилки та недоліки таких задач

1. Задача ніяк не стосується реальної роботи. Це мене трафляє найбільше. Дають вирішувати алгоритми, хоча насправді круди клепають. Давайте релевантну задачу, зроблю вам круд! Навіщо вам людина, яка вміє рядки в підрядках шукати?
2. Організаційно — відсутній нормальний інструмент для розв’язання. Один раз мені показували код в google doc, один раз я шарив екран в repl.it. Один раз був кодерпад.
3. Задача не створює контексту для подальшої розмови — це наслідок з першого пункту. Навіщо давати задачу, якщо потім не будемо про неї говорити?
4. Не всі люди можуть впоратися із завданням під наглядом. Відповідно, хороший кандидат відсіюється.

Теоретичні питання

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

Чомусь так сталося, що найбільше в мене теорію питали на позиціях Ruby Engineer. Я знав її найгірше, тому постійно фейлив співбесіди та виглядав якимось джуном, поки не зрозумів, що далі так не годиться. Я сів і почитав підручник з мови, який дозволив мені виступати значно краще і без ниття: «Хлопці, ну навіщо ви в мене то питаєте? Я хороший програміст, яка різниця, який там порядок пошуку методу у тих класах? Кому це треба?».

Перше інтерв’ю, яке я проходив на Ruby Developer, було якраз те, де треба було виконувати тестове завдання, але, як виявилося, нікому воно не було цікавим. Тімлід, який мав зі мною розмовляти, не прийшов (у пробці стояв чи щось таке), тому мені видали іншого. Після знайомства інтерв’юер каже: «У мене є правило — я всі співбесіди проводжу англійською мовою, тому переходимо на англійську». І тут мої вуха скручуються у графенову нанотрубку, бо мій інтерв’юер має потужний акцент. Це мене трошки вибило з колії, але я якось зміг налаштуватися.

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

Потім були питання про конкретні методи, а саме: «Як називається метод, який фільтрує всі ніли в колекції?». Тут я вже увімкнув троля і сказав: «Якщо ви перевіряєте мою пам’ять на ці методи, то я не зможу вам відповісти про те, чого не використовував нещодавно. Я пишу на багатьох мовах та платформах, я не пам’ятаю всі методи SDK». Інтерв’юера це не задовільнило, і наступним питанням було щось типу: «Що таке Enumerable? Назвіть, які там є методи та хто його екстендить». «Дядя, ти шо, не поняв?», — подумав я про себе, але вслух сказав: «Не знаю точно, думаю, що якісь методи типу map/reduce/slice і т. д.». Це йому теж не підійшло, судячи з усього.

Потім він задав мені дефолтне питання з MVC і куди пхати логіку. Я відповів, що в моделі, а якщо в моделі не влазить, то в якісь інакші класи. Виявилося, що правильною відповіддю були так звані Service Objects (невже ця зараза і сюди дісталась). Я щось буркнув у відповідь, типу, ну можна і так назвати, але мені це не подобається.

Далі він мені задав якісь питання ще про SQL, на які я вже грамотно зміг відповісти, потім запитав про RSpec, який я не дуже використовував, та й усе. По Rails (а в них якраз Rails був) жодного питання я не отримав. Про мій попередній досвід теж не було жодного запитання.

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

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

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

Отож, мені відмовили, тому що я не знаю основ мови. Гаразд, їдемо далі.

Ще одна співбесіда на Ruby Developer,уже двоє інтерв’юерів. Добре, що хоч розмовляють один російською, інший — українською, тому не доводилося ламати собі мозок. На диво, починається та сама історія: що таке модулі, що таке блоки. Я тоді ще не прочитав книгу, тому знову плавав у відповідях. Далі запитали про види асоціацій у Rails-моделях. «Нарешті хоч щось», — подумав я і назвав три види з пам’яті. Інтерв’юерам це не сподобалося (бо їх є більше — я всі не пам’ятав), як і те, що я сказав: «За іншими лізу в доку». Далі вони мені дали ту задачу на each_slice, про яку я написав вище. Після цього, як ви вже знаєте, я запропонував закруглятися. Один з інтерв’юерів сказав: «У мене тоді останнє питання, чи ви колись писали Rack middleware?». Я не знаю, що він хотів почути. Я сказав, що не писав, але знаю, що воно таке (типу фільтрів у Java, middleware в Laravel або якомусь Express), та можу швидко розібратися за потреби. І знову це їх не влаштувало, тому наша співбесіда завершилась.

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

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

Третє інтерв’ю на Ruby Developer.Тімлід знову десь у відпустці, тому зі мною говорив просто девелопер з команди. Ті самі питання про модулі та блоки, але я вже підготувався, тому одразу даю коректні відповіді. Інтерв’юер іде далі і питає мене, що таке Proc, але і тут я даю правильну відповідь :) Тоді він вирішує, що час застосовувати важку артилерію і задає питання: «Назвіть порядок пошуку методу для виклику, якщо в нас є клас, він екстендиться від іншого, а ще є модуль і ще щось там». Тут я вже не знав 100% правильної відповіді, тому спробував якось нафантазувати та методом дедукції з’ясувати, який же там порядок. Вгадав половину.

Далі було ще одне питання на зразок цього: яким чином працює require. У цих хлопців уже було не Rails, а Grape, тому, вочевидь, для них це було актуально. Я сказав, що «сходу не знаю, але, напевне, працює воно отак». Здається, не вгадав. Далі ще були якісь питання-пазлери типу: шматочок коду, що тут буде. Потім трішки поговорили про ActiveRecord — я майже на все правильно відповів, крім валідацій, бо ніколи їх не писав, зате з іншим мав хороший досвід.

Потім він мене починає питати про concurrency (тут мені вже смішно стало). Я не знаю точно, яка модель concurrency в Ruby — так йому і сказав. І додав, що я знаю про примітиви синхронізації, атомітки, м’ютекси і т. д. Намагався якось натякнути, що ваше конкаренсі — тухла риба порівняно з Java, і зараз я вам розкажу про моделі пам’яті, різницю між volatile та synchronized і буду цитувати Шипильова, але інтерв’юеру те не зайшло. Крім того, він зізнався, що в проекті вони (та не може бути!) concurrency не використовують. Навіщо тоді питати?

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

Отож, який висновок можна зробити з цих трьох співбесід? Між ними минуло по декілька днів. За цей час я не зробив нового проекту, не набув нових знань або досвіду, не став кращим програмістом. Я яким був, таким і залишився! Знання теорії на практиці не додало мені абсолютно нічого (вибачте за каламбур). Просто замість того, щоб заздалегідь прочитати Cracking Ruby Interview я вирішив наступити на всі граблі сам. Думаю, ще два-три таких інтерв’ю, і моя «сеньорність» не буде викликати ні в кого ніяких сумнівів. Не зважаючи на те, що насправді я якою макакою був, такою і залишився :)

Ще кілька історій, і з чистою теорією будемо зав’язувати.

Мав також інтерв’ю на Fullstack Java Developer.Мене попередили, що воно буде складатися з двох частин: бекенд та фронтенд. Останній я знаю не дуже добре і сказав про це рекрутеру, але вони вирішили йти далі. Ну що ж, зв’язуємося з хлопцями, починаємо з Java.

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

Перейшли до фронта. На тому кінці був чисто фронтендер. Він почав мене питати про минулий досвід, а потім перейшов до пазлерів, типу що буде, якщо undefined порівняти з null, як працюють області видимості. Ще кілька дефолтних питань із JS і знову перейшов на WAT-питання. Я одразу сказав: «Слухайте, я з вашими WAT ніколи в житті не мав справи. Якщо дуже треба буде, то погуглю, але я думаю, що ці знання нема куди застосовувати, окрім як посміятися на мітапчиках». Інтерв’юер зі мною погодився, але все одно продовжив задавати пазл-питання. Урешті-решт він порекомендував мені прочитати книгу «JavaScript: The Good Parts», після чого я ще мав розмову з менеджером і на тому розійшлись.

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

Хоча ці люди теж намагалися з мене витягнути якісь чисто теоретичні знання, сам фронтендер погодився, що таких практичних задач вони не мають. Фронт на jQuery, і треба вміти його. Я сказав, що вмію, і проблем нема :)

І ще я мав співбесіду на DevOps Engineer, де я робив тестове завдання. Перейшли ми до розмови, і тут інтерв’юер питає: «А що таке маска підмережі?». Тут я і посипався :) Сказав, що це кількість циферок, які значать адресу підмережі, а всі інші циферки — то діапазон. Але що з тим треба робити, уже не пам’ятаю, бо давно не налаштовував мереж. Добре, що інтерв’юер виявився адекватним, підвів мене до правильної відповіді і не зважав на те, що на таке просте запитання я не зміг одразу дати вірну відповідь. Далі співбесіда вже проходила без теоретичних питань.

На мій подив, абсолютно перестали задавати питання про патерни проектування, окрім того випадку, коли мене запитали про MVC. Усього (ха-ха) 5-10років тому буквально на кожній співбесіді питали знання патернів. Я з того часу їх майже всі напам’ять знаю та ще й можу реалізувати. Відтак, цього року я не отримав жодного питання по патернам. Ruby-програмістів ще можна зрозуміти — вони, напевне, про них нічого і не знають (у них є патерн MVC та ActiveRecord, і їм того досить). Але відсутність питань з патернів на Java-співбесідах мене дуже здивувала.

Про SOLID запитали, здається, два рази: один раз на Ruby-позицію, іншого разу — на Java. Про DRY не питали :)

Які можна зробити з цього висновки?

1. Теорію досі люблять питати, особливо наші з вами співвітчизники.
2. Знання теорії не гарантує знання практики, тому до теорії люблять долучати задачки.
3. Ні знання теорії, ні здатність вирішити задачку не гарантує, що людина вміє програмувати.
4. Незнання теорії та фейл з вирішенням задачки не значить, що перед вами поганий розробник.

Тому, яким би безглуздим це все не було, але раджу вам:

• Перед співбесідами прочитати типові набори питань з вашої мови/платформи та добряче їх завчити. Знати неоднозначні питання, відповіді на які просто так не виведеш. Моє улюблене: який є недолік використання проксі-AOP порівняно з AspectJ у Spring :) Це потрібно, щоб легко проходити співбесіди з інтерв’юерами, у яких немає фантазії на нормальні запитання.
• Повирішувати типові алгоритмічні задачки на LeetCodeта подібних ресурсах, щоб бути до них готовим.

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

Не забувайте долучатися до мого каналу у Telegram, заходьте почитати мій блог, і до наступної статті!

Попередні частини:

Senior у пошуках роботи. Як я пройшов 20 співбесід з HR і що про це думаю

Senior у пошуках роботи. Як я пройшов 15 технічних співбесід і що про це думаю

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

Я — Роман Гелемб’юк з Івано-Франківська. Уже більше 17 років займаюся програмуванням. Основні технології — PHP та Golang. Як порядний IT-шник я маю свої pet-проекти. Наразі мене цікавлять децентралізовані бази даних та блокчейн-технології.

Хочу розповісти про свій проект OurSQL. Це, свого роду, розширення MySQL, яке дозволяє створити децентралізовану базу даних без вузлів із «особливими» правами.

Ідея

Спочатку була ідея створити децентралізовану платформу для громадянського суспільства. Щось типу соціальної мережі, але децентралізовану, без «адміна», «власника» і модераторів, із можливостями вести конструктивний діалог, водночас.

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

Огляд готових рішень для децентралізованих ДБ не дав результатів, фактично є лише BighainDB (на базі MongoDB). Насправді ж вона не виконує обіцяного, хоч і є розрекламованою та популярною. Слід відзначити проект Hyperledger.org, який у той час видався мені занадто складним для використання. Напевно, для корпорацій він буде найкращим вибором, але не для малих компаній чи одинаків.

Процес розробки

Задача була створити інструмент для реплікації баз SQL-даних повністю децентралізованим способом, без будь-яких master вузлів.

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

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

Далі на базі коду democoin був створений OurSQL — проксі-сервер MySQL, який фільтрує SQL-запити, перевіряє можливість виконання, конвертує SQL у блокчейн-транзакції, будує блоки (для блокчейну), відправляє блоки та транзакції іншим нодам (іншим серверам OurSQL в межах однієї бази даних) і ті, в свою чергу, роблять відповідні оновлення у своїх локальних копіях MySQL-баз.

Назва OurSQL народилася сама собою. MySQL — для моєї бази даних, а OurSQL — для нашої бази даних. У процесі довелося вивчити протокол MySQL клієнта, детально розібратися у всіх нюансах шифрування та електронних підписів у різних мовах програмування та бібліотеках та інше.

OurSQL = MySQL + Blockchain: як це працює

OurSQL — це окремий сервер, який має два основні компоненти: MySQL проксі-сервер та власне Blockchain-сервер.

Кожен екземпляр OurSQL («нода») працює із єдиною базою MySQL. У цій базі одночасно зберігаються дані разом зі спеціальними таблицями, у яких збережено інформацію про сам блокчейн. SQL-запити надходять через проксі-сервер і далі аналізуються. Якщо це Update запит, відбувається перевірка можливості виконання такого запиту. Ця перевірка відбудеться згідно з правилами консенсусу, які діють у цій базі даних.

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

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

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

Сам по собі цей додаток може бути створений із будь-якою технологією, яка вміє зберігати дані в MySQL. Це може бути desktop application чи web application, запущений на локальному сервері.

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

Кожен користувач децентралізованої системи повинен отримати свою копію додатка в «пакеті». Цей пакет включає: MySQL-сервер, OurSQL-сервер, конфігураційний файл із описом правил консенсусу і, власне, сам додаток.

Проте можливим є і створення «легких клієнтів». Тобто додатків, які не містять у собі повноцінної ноди, а працюють із одною із доступних віддалених нод. У цьому випадку доведеться з’єднуватися із віддаленою базою даних. Або робити додатковий «шар» у вигляді REST API.

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

Криптовалюта

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

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

Як OurSQL зв’язаний із bitcoin та ethereum

Ніяк, за винятком використання такої самої технології «блокчейн». Але із конкретними відомими публічними блокчейнами OurSQL ніяк не пов’язаний.

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

Де використовувати OurSQL

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

Приклади:

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

Blockchain consensus

Алгоритм консенсусу є центральним поняттям в технології blockchain. Наразі OurSQL підтримує лише найпопулярніший і найнадійніший підхід — Proof of Work, аналогічний bitcoin та більшості популярних криптовалют. Кожна база даних має спеціальний файл — ConsensusConfig, у якому описано параметри для Proof of Work: складність пошуку хешу блока, кількість транзакцій у блоці, винагорода «майнеру» в монетах внутрішньої криптовалюти та ін.

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

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

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

Як спробувати OurSQL

Інсталяційного пакету поки що немає. Є 2 способи спробувати, як працює цей сервіс: скомпілювати програму або запустити в Docker-контейнері.

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

docker run --name oursql1 -p 9001:8765 -p 9002:8766  -d -it oursql/oursql-server interactiveautocreate -port 9001

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

docker run --name oursql2 -p 9003:8765 -p 9004:8766  -d -it oursql/oursql-server importfromandstart -port 9003 -nodeaddress host.local.address:9001

Використайте MySQL-клієнт, щоб приєднатися до першої ноди на порті 9002 або до другої на порті 9004. База даних має назву BC та користувача blockchain/blockchain. Вносьте зміни в базу даних, використовуючи SQL, і ви побачите, як зміни реплікуються між нодами.

mysql -h 127.0.0.1 -P 9002 -u blockchain -pblockchain BC

mysql -h 127.0.0.1 -P 9004 -u blockchain -pblockchain BC

Також можна підключитися до існуючої демонстраційної бази даних «OurSQL Demo DB».

docker run --name oursql -p 8765:8765 -p 8766:8766 -d -it oursql/oursql-server importandstart -port 8765 -nodeaddress 109.251.62.4:8765
mysql -h 127.0.0.1 -P 8766 -u blockchain -pblockchain BC

Деталі про роботу із цією базою можна знайти в блозі проекту.

Подальші кроки

Перше — додати можливість створення модуля консенсусу для децентралізованої бази. Наразі можна робити лише конфігураційний файл, у якому описано прості правила для Proof of Work консенсусу та правила для роботи із таблицями в базі.

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

Тобто для кожної конкретної децентралізованої бази даних, підтримуваної на OurSQL, можна буде запрограмувати модуль (швидше за все на мові Golang), у якому буде реалізовано логіку роботи і можливих змін у цій базі, рівнів та прав доступу для кожного користувача.

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

Веб-сайт проекту. Нещодавно почав вести блог, щоб розповідати про результати роботи та давати поради.

Контакти:roman@gelembjuk.com, oursql.project@gmail.com.

Продолжаем серию «Карьера в IT»: на этот раз поговорим о позиции Embedded-разработчика. Это специалист, который занимается разработкой встроенного ПО.

По данным DOU, среднему украинскому Embedded-разработчику 30 лет, он имеет опыт работы 5-6лет и получает $880 на уровне Junior, $1750 на уровне Middle и $3500 на уровне Senior. Зарплата тим- и техлидов — около $4200.

Об особенностях своей специальности нам рассказали Embedded-разработчики из компаний Celeno, eZLO Smart Home Automation, GlobalLogic, Ring Ukraine, TowerIQ и Ubiquiti Labs Ukraine.

Задачи и обязанности

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

По сути, эта специальность лежит на стыке программирования и аппаратной инженерии. Задачи бывают разными — от разработки драйвера для какого-то модуля до интеграции кода с существующим ПО. Все зависит от конкретного проекта. Иногда обязанности ограничиваются только работой с платой, а иногда Embedded-разработчики принимают участие в написании бизнес-логики продукта или разработке самого «железа».

«Я адаптирую код к прошивке камеры и улучшаю работу существующего кода. Много общаюсь с коллегами со всего мира, чтобы вместе эффективнее решать задачи». (Александр, Ubiquiti Labs Ukraine)

В отличие от классических Software программистов, Embedded-разработчики работают не только с кодом, но и с «железом».

«Объясню суть своей работы на примере нашего проекта. В Японии выпускают „железо“, которое должно стать частью автомобиля. Наш эксперт едет на завод в Японию и делает все, чтобы Android с периферийной платой заказчика ожил. Дальше „железо“ попадает к нам в офис. Мы занимаемся всем — от момента включения устройства и заканчивая пользовательским интерфейсом. Будь то kernel, драйвер, демон или красивая анимация при нажатии на кнопочку». (Денис Глусский, GlobalLogic)

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

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

«Прежде чем начинать программировать, Embedded-разработчик должен обеспечить себе базовую функциональность. Заставить плату работать, запустить начальный загрузчик, написать или обновить какие-нибудь драйвера. Часто это приходится делать без какой-либо поддержки со стороны софта: для отладки используется не отладчик и даже не серийная консоль, а мигание светодиодом на плате или анализ сигналов осциллографом. Недаром у эмбеддеров „Hello, World!“ — это помигать светодиодом на новой плате». (Андрей Лукин, GlobalLogic)

Примеры Embedded-систем (image source)

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

«В Embedded крайне важно уделять внимание вопросам надежности и долговременной автономности, так как продукт может годами работать без внимания пользователя. Нужно учитывать крэши, пропадания или ослабления питания, перевод дат и прочее. Существенную роль играет автоматическая процедура обновления ПО и его компонентов — например, обновления SSL сертификатов». (Александр С. и Александр Е., Celeno)

«Работая с платами, девайсами, микроконтроллерами, Embedded-разработчик тесно сотрудничает с hardware-командой. Это помощь не только в подборе компонентной базы, но и в принятии архитектурных решений: от того, как спроектировать систему или какие интерфейсы использовать, — и до того, какой сенсор на какую шину посадить». (Вадим Ткачук, Ring Ukraine)

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

Типичный рабочий день Embedded-разработчика включает в себя:

• работу с «железом»;
• работу с кодом;
• отладку;
• тестирование;
• изучение документации;
• митинги и созвоны с коллегами.

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

«В Embedded меньше времени уходит на написание кода и больше, к примеру, на ту же отладку. Вполне привычная ситуация: Embedded-разработчик пишет 10-20строчек кода, а весь оставшийся день тратит на выяснение причин, по которым он не работает. Ведь приходится иметь дело с разными производителями, разными микроконтроллерами, разными чипами — и у каждого своя имплементация. К тому же на некоторые компоненты нет хорошей документации. Приходится искать форумы, узнавать, не сталкивался ли кто-то с аналогичными проблемами. Нередко в таких случаях доходит до подключения более серьезного дебага, осциллографа, логического анализатора. Такой глубокий анализ может занять весь день». (Вадим Ткачук, Ring Ukraine)

«По моему опыту, на написание кода у Embedded-разработчика уходит максимум 30% рабочего времени. До 50% всего времени занимают исследования сути проблемы, которую нужно решить. Остальное — дебаг». (Виктор Семенов, TowerIQ)

«На текущем проекте я занимаюсь интеграцией кода от 5 разных Software house в одно целое. Около 40% времени уходит на на интеграцию, 30% — на код ревью, 20% — на деловую переписку и 10% — на рефакторинг и улучшения. До позиции интегратора 60% времени занимался написанием кода, 20% — интеграцией, 10% — код ревью, 10% — рефакторингом и прочими улучшениями. В любом случае около 4-хчасов в неделю трачу на чтение статей и изучение исходного кода AOSP. Обычно делаю это во время сборки проекта». (Денис Глусский, GlobalLogic)

«Иногда нужно просидеть пару дней в окружении электрических схем, файлов печатных плат и контрольно-измерительного оборудования в поисках неисправности или пути оптимизации работы какого-либо узла. Если аппаратная часть отлажена, можно весь день писать код, прерываясь на разного рода митинги и обсуждения. Также время от времени появляются задачи, связанные с настройкой рабочего окружения и оптимизацией процесса разработки, чтением и написанием документации или тестированием. В среднем по времени 50-60%времени уходит на написание кода, 30-40% —на тестирование и 10% — на различные митинги и обсуждения». (Владимир Свистельников, eZLO Smart Home Automation)

Меняются задачи и на разных стадиях жизненного цикла продукта:

«Чем больше работаешь с устройством, тем больше времени занимает работа, собственно, с кодом. В самом начале вообще вряд ли кодишь, больше разбираешься в документации, читаешь принципиальные схемы, если есть. Уточняешь требования с заказчиком. Потом много времени может уходить на пересборку операционных систем. Под конец проекта больше всего времени, по-хорошему, уходит на тесты». (Андрей Лукин, GlobalLogic)

Иногда Embedded-разработчикам приходится самим брать в руки паяльник — например, если нужно срочно припаять какой-то проводок или кнопку на плату.

Преимущества и недостатки

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

«Мне нравится создавать новые вещи физического мира. К примеру, раньше смартфонов не было, а теперь они есть. Раньше вы платили в метро жетонами, сейчас смартфоном. Еще один плюс профессии — ее востребованность. Принимая участие в найме персонала, я понял, что рынок сильно нуждается в квалифицированных Embedded-разработчиках». (Виктор Семенов, TowerIQ)

«В Embedded меня всегда привлекало „железо“. То, что ты можешь потрогать результат своей работы, а он тебе каким-нибудь диодиком подмигнёт». (Андрей Лукин, GlobalLogic)

«Embedded привлекателен для тех, кто желает видеть результаты своего труда, свой код, оживляющий изначально мертвое, неподвижное железо. Вряд ли эта профессия подойдет любителям высоких объектно-ориентированных абстракций и теоретикам». (Александр С. и Александр Е., Celeno)

«Embedded-разработчик каждый день делает то, что до него никто не делал. Ты приходишь на работу — и завертелось то, что без тебя никогда бы не завертелось. Это довольно круто. Льстит самолюбию. Лично я по образованию радиоинженер, потому писать программы для меня было логичным развитием моих знаний о электронике и радиотехнике». (Максим, Ubiquiti Labs Ukraine)

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

Работа с Embedded-системой (image source)

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

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

«Есть не недостатки, но некоторые сложности. Например, то „железо“, которое вы используете, может быть экспериментальным. Если это engineering-образец, он часто глючит сам по себе — и без вашего кода. Это необходимо учитывать при отладке». (Александр С. и Александр Е., Celeno)

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

«Embedded-разработчику, который занимается низкоуровневой разработкой под микроконтроллеры, практически невозможно работать удалённо. При большом желании такую работу найти можно, но вам всё равно нужно будет обустроить рабочее место дома или ещё где-то. А также придется самостоятельно снабжать себя вспомогательными инструментами: отладочными платами, кабелями, переходниками, принадлежностями для пайки. Так что работать с ноутбуком сидя на пляже — не получится». (Виктор Семенов, TowerIQ)

Как стать и куда двигаться дальше

Чтобы стать Embedded-разработчиком, необходимо быть знакомым с базовыми понятиями электроники и электротехники, иметь хорошие знания аппаратной части, понимать работу сетей. Понадобятся знания схемотехники, теории обработки сигналов, математики, алгоритмов, Linux OS и языков программирования С и С++.

Начать изучение специальности можно с книг «Искусство схемотехники» Хоровица и Хилла, «Архитектура компьютера», «Компьютерные сети» и «Операционные системы» Эндрю Таненбаума. В Embedded-разработке не обойтись без фундаментальных знаний по компьютерным наукам.

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

«Документация — наше всё, если она есть :) Например, руководство Programmers Guide для процессора ARMv8-A занимает 296 страниц и описывает лишь основы. А Architecture Reference Manual для него же — уже 6354 страниц». (Андрей Лукин, GlobalLogic)

«Обязательно стоит посвящать время изучению форумов и community-порталов. По возможности посещайте различного рода ивенты, смотрите вебинары, следите за трендами». (Владимир Свистельников, eZLO Smart Home Automation)

Чтобы закрепить знания на практике, Embedded-разработчики советуют придумывать и разрабатывать собственные проекты:

«Для получения опыта и знаний я рекомендую сделать собственный сложный проект, включающий разработку платы, программирование, дебаг и калибровку. К примеру, я делал самодельный квадрокоптер. Во время разработки узнал множество фундаментальных вещей. После того, как он полетел, уже ничего не страшно :)» (Виктор Семенов, TowerIQ)

«Попробуйте собрать какую-то схему или готовый набор вроде Arduino. Это поможет освоить базовые шины обмена данными и поработать с периферией. Придумайте себе задание — к примеру, подключить к схеме датчики и написать программу, которая будет обрабатывать их сигналы. В том же Arduino есть много библиотек для работы с шинами, датчиками, клавиатурой — сначала можно использовать их. А затем попробуйте написать все драйвера самостоятельно. Следующий шаг — работа с Raspberry Pi. После такой практики можно подавать резюме в компании». (Александр, Ubiquiti Labs Ukraine)

Платформа Raspberry Pi (image source)

Из личных качеств важны:

• целеустремленность;
• аналитический склад ума;
• тяга к неизведанному;
• внимание к деталям;
• ответственность;
• усидчивость.

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

«Вы не напишите программу для стирки кружевного белья в машинке без знаний о текстиле и швейном деле. Не напишите ПО для станции автоматического полива растений без знаний по биологии. А ведь кто-то пишет программы для аппаратов УЗИ, для исследований слуха, зрения. В этом случае разработчик должен руководствоваться той же клятвой Гиппократа, не так ли?» (Максим, Ubiquiti Labs Ukraine)

Возможные карьерные пути Embedded-разработчика:

• развиваться как Embedded-разработчик, изучая новые направления встраиваемых систем;
• стать архитектором Embedded-решений;
• перейти в менеджмент — стать тимлидом команды или СТО компании;
• попробовать себя в смежных отраслях — например, телекоме или инфраструктурной архитектуре.

«Куда дальше? Строить космические корабли, например. Вообще, прогресс постоянно держит в тонусе, спрос на Embedded-решения растет. Кстати, использовать свои знания можно и для личных целей. Мой знакомый построил себе автоматизированную теплицу. Система выполняет все необходимые действия сама, а он приезжает исключительно собрать урожай». (Денис Глусский, GlobalLogic)

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

Начало пути и DataStax

Моя дорога к работе мечты началась с обычного чтения ленты в Твиттере. Я увидел твит от Alex Petrov, в котором он искал инженеров для работы над Cassandra в DataStax.

Like distributed systems and would like to work on building a database? Our team at @DataStax is hiring! Ping me if you’re interested!August 23, 2017

В описании вакансии я увидел все, что подходило под описание идеальной работы для меня: отсутствие офиса, распределенная команда, highload база данных, которая используется во всем мире, и самые интересные технические вызовы в контексте распределенных систем. На тот момент я и мечтать не мог о том, что хотя бы попаду на собеседование. Я написал Алексу в личные сообщения и через пару дней получил письмо с приглашением начать общение и первым заданием. Ну что же, let the fun begins.

Собеседование в DataStax состоит из трех частей (спойлер: я зафейлился на второй): открытые теоретические вопросы, практическое задание и общение с командой. Получив теоретические вопросы, я был приятно удивлен тем, что они так или иначе связаны с реальными проблемами, которые решает Cassandra. Это не был очередной набор задач из Cracking the Coding Interview, взятых для галочки. В итоге, отправив решения, я на следующий день получил письмо с пропуском на второй этап.

На втором этапе вместо написания какого-то очередного бесполезного сервиса или имплементации алгоритма, мне прислали спеку для нового CQL оператора. За время, ограниченное здравым смыслом (дедлайн не указывали), мне нужно было разобраться с исходниками базы данных и имплементировать спеку. Ничего сложного, не правда ли? :)

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

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

Прорваться на собеседование в Elastic

Следующей компанией, которую я для себя выделил, была Elastic. На самом деле со стороны она очень похожа на DataStax в плане работы. Те же распределенные команды и highload база данных, но здесь занимаются полнотекстовым поиском.

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

Подождав пару недель и увидев шаблонное письмо с отказом, я начал искать сотрудников компании. Написал одному из разработчиков в Core team, пообщался с ним и получил реферал. Но так как я уже был отмечен в системе, то получил отказ без объяснения причины. В это время я узнал, что в Elastic разрабатывают не только базу данных, но и разный тулинг вокруг нее. Подав резюме в одну из таких команд, я попал на интервью. Я планировал пообщаться с рекрутерами и другими членами команды и узнать, можно ли потом перейти в Core team, которая была мне интересна.

Я прошел два этапа собеседований. Первый был с одним из разработчиков Elastic Cloud, на котором мы обсуждали мой предыдущий опыт и провели небольшое system design interview. О нем я расскажу больше в контексте собеседования в Facebook. Следующее собеседование было с тимлидом команды. Мы больше говорили о том, что мне интересно, а также я отвечал на базовые вопросы из курса Computer Science. Я был «слегка» удивлен, когда через час после собеседования получил отказ. До этого я не относился к мотивационным интервью серьезно, но, как оказалось, для продуктовых компаний это один из самых важных этапов. Интервьюер сказал, что мне вряд ли будет интересно работать у них в команде и лучше бы мне пойти на собеседование в Core team. Учитывая, что HR’ы из этой команды не хотели даже говорить со мной, я попал в ситуацию, когда все двери оказались закрыты.

Молчаливый рекрутинг Твиттера

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

Само собеседование было коротким — небольшой разговор с лидом команды, тестовое задание и... 4 недели тишины. Последние две недели я пытался разными способами узнать у HR, что происходит, и слышал лишь пустоту. Рекрутер не отвечал на мои письма, звонки и SMS. Мне повезло получить телефонный номер лида во время собеседования. Когда я позвонил ему и объяснил ситуацию, он пообещал помочь. Через два дня позвонил HR и объяснил, что позиция на которую меня собеседовали, была закрыта кем-то изнутри компании и мое решение задачи даже не смотрели. Взамен мне предложили другие вакансии, и мы остановились на infrastructure team, где инженеры строят базы данных специально для Твиттера. Этот вариант был даже лучше прошлого, и мы начали процесс заново.

В этот раз собеседование разительно отличалось от предыдущего. Один за другим пришли приглашения на мотивационное, кодинг и system design интервью. Особенность команды в том, что она распределена между разными офисами компании, поэтому можно было не лететь в Лондон ради интервью. Первое собеседование было с engineering manager’ом команды, на котором мы обсудили причины моего ухода из тех или иных компаний и мотивацию заниматься программированием вместо чего либо еще. Это было одно из самых лучших мотивационных интервью по моему опыту, так как оно проходило в абсолютно непринужденной обстановке и выглядело просто как общение двух знакомых. Остальные этапы интервью провела другая команда. Сейчас я понимаю, что не уделил достаточно внимания подготовке к system design интервью и не смог хорошо справиться с ним. Неожиданно, но нужно было спроектировать распределенную базу данных.

Через три дня после собеседования меня ждало шаблонное письмо с отказом на почтовом ящике. Я потратил так много усилий на весь процесс, поэтому хотел получить больше объяснений, но HR, как обычно, не отвечал. Я написал engineering manager’у напрямую и был приятно удивлен подробным фидбэком. Я получил пищу для размышлений и до сих пор благодарен интервьюеру за его открытость.

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

Окей, Google

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

Еще до разговора с Пашей, используя фидбэк после собеседования в Твиттер, я начал закрывать пробелы в своих знаниях. В ход шли whitepapers, которые присылал DataStax, курсы Седжвика на Coursera и разные статьи в интернете, которые объясняли непонятные мне термины и конструкции. Сам процесс разбора занял около месяца и закончился как раз к началу собеседований в обеих компаниях.

Собеседование в Google состоит из трех этапов: общения с рекрутером, онлайн- и оффлайн-этапов. Во время общения с рекрутером вы узнаете о процессе интервью и пройдете небольшой тест, по результатам которого вам могут порекомендовать почитать подготовительные материалы и взять паузу перед онлайн-этапом. Сам тест представляет собой около десяти вопросов на разные темы, начиная от базовых структур данных, заканчивая задачами, связанными с языками программирования и задачей на логику. Забавно, но это было первое собеседование за долгое время, на котором меня спросили про основные принципы ООП. В своем большинстве мой опыт был связан с функциональным программированием, поэтому пришлось быстро вспоминать заветные четыре слова :)

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

Сама задача совмещала в себе логическую часть и понимание алгоритмов поиска пути. Решение нужно было написать на «произвольном» языке. Вариант использовать JavaScript или Scala не сильно обрадовал моего интервьюера, поэтому пришлось писать на смеси Java и C++, что получалось у меня не так хорошо. После решения задачи я спросил собеседующего, стоит ли мне писать тесты и рефакторить код. Не получив утвердительного ответа, я сдал задание и ушел заниматься своими делами. Не удивительно, что меня ждал отказ.

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

Оффер от Facebook

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

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

Оффлайн-этап состоит из пяти собеседований подряд: трех coding challenge, благодаря чему комиссия может получить наиболее объективное мнение о соискателе, мотивационное и system design интервью. Как по мне, самое сложное из них — system design интервью. На нем необходимо спроектировать решение определенной открытой задачи. Сама задача состоит из одного предложения, описывающего общую идею. Все остальные детали вы должны узнать у интервьюера или спрогнозировать сами. Для меня это было очень похоже на начало разработки нового продукта, когда разработчикам нужно узнать все требования к проекту и на их основе составить высокоуровневую архитектуру приложения. Для подготовки к этому интервью я купил доступ к курсу Grokking the System Design Interview, что, безусловно, было лучшими вложением 79 долларов. Благодаря этому блогу я получил множество новых идей, как можно строить приложения, и научился задавать правильные вопросы самому себе во время проектирования.

Перед интервью я весь вечер повторял свои конспекты и разбирал задачи, которые другие соискатели публиковали на Glassdoor. Многие советуют прорешать «Cracking the coding interview», но, как по мне, это трата времени. Эта книга достаточно поверхностно описывает алгоритмы и структуры данных. Вместо того, чтобы учиться понимать идеи и принципы, заложенные изначально, с помощью книги вы просто научитесь решать конкретные задачи. В итоге собеседование превращается в бросание монетки: если вам повезет, то задача будет похожа на ту, которую вы прошли в этой книге. Мне куда больше пользы принесли курсы от Robert Sedgewickна Coursera (перваяи втораячасти). В них объясняются идеи, которые стояли за той или иной структурой данных и алгоритмом. Да и вряд ли кто-то может лучше объяснить красно-черные деревья, чем тот, кто их придумал :) И я бы не сказал, что на проработку задач из книги нужно меньше времени, чем на просмотр обоих курсов Седжвика.

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

Даже если бы я не получил оффер, это все равно был бы невероятно интересный опыт. Компания хотела не только проверить меня, но и показать себя с лучшей стороны. Как мне сказали во время обеда: «Till now you tried to sell yourself, now we will try to sell the company to you». Выходя из офиса, я чувствовал себя абсолютно опустошенным. Голос пропал, и следующие полчаса я перебирал мысли в голове. Несмотря на это, я был счастлив, так как чувствовал, что выложился на полную.

Выводы

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

Несколько советов:

• Лучший способ получить оффер — попасть на собеседование, а лучший способ попасть на собеседование — это найти человека внутри компании, который мог бы порекомендовать вас.
• Очень важно ознакомиться с core values компаний, чтобы понимать, подойдете ли вы друг другу. Но в то же время не нужно пытаться подобрать ответы под них. Вряд ли вам хочется сменить работу на ту, где вы не сможете быть собой.
• Если вы чувствуете, что ваши знания в computer science не так сильны, то уделите пару месяцев для подготовки и обучения. Я могу посоветовать вам этот курс (часть1, часть 2).
• Во время подготовки обращайте внимание на общие концепции и идеи вместо частных решений. Куда легче разобраться с парой десятков идеи, чем подготовиться к тысячам производных задач.
• Используйте все возможные ресурсы для подготовки, даже если вам придется заплатить за них. Скорее всего, цена на них вполне оправдана. Для меня очень важным шагом стала покупка этого курса.

Я желаю вам удачи в поисках, а сам собираю вещи на самолет «Мюнхен  —  Лондон» и улетаю в новое приключение. Буду рад ответить на ваши вопросы, а также подписывайтесь на мой Twitterи Instagram.

Сделать простое иногда во много раз сложнее, чем сложное
© Михаил Калашников

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

Действительно, зачем это нужен ещё один язык программирования? Понятно, он может быть нужен в каких-то НИИ при университетах, но обыкновенному бизнесу — какой толк от этой заумной мути? Вообще к чему столько разных языков, почему бы не использовать один единственный? Давайте разберёмся.

Почему бы не пользоваться одним языком

Жил да был в Великобритании выдающийся математик, логик, криптограф, и звали его Алан Тьюринг. В числе других открытий он придумал машину имени себя. Опуская подробности, скажем, что с помощью этой машины можно реализовать всё то же, что и с помощью любых средств программирования более высокого уровня. То есть любую программу на любом языке можно переписать с помощью этого достаточно простого средства. Тем более на любом языке типа Java или PHP можно реализовать эту самую машину.

Как следствие, существует критерий полноты по Тьюрингу-Чёрчу. Язык называется полным, если на нём можно реализовать машину Тьюринга. Все популярные языки программирования общего назначения (Java, C#, PHP, Python, Scala, JavaScript и так далее) являются полными. Что же это означает? Все популярные языки эквивалентны! Ну вот, смотрите: мы знаем, что все программы можно выполнить с помощью машины. Машину же, которая выполняет, можно написать что на PHP, что на C++. Получается, одну и ту же программу, записав её на языке машины Тьюринга, можно выполнить везде. А мы знаем, что так можно записать вообще любую программу.

На практике это означает, что программу на языке, скажем, JavaScript, поднатужившись, можно переписать на С++. Обратное тоже справедливо. Да, имеют значение библиотеки и фреймворки, но саму логику можно без проблем перенести с одного языка на другой.

Зачем тогда разные языки нужны, почему бы не пользоваться одним? В знаменитом романе Семюэля Дилэни «Вавилон 17» описан человек с выключенной частью мозга. Вместо этого он обучен искусственному языку, близкому по синтаксису к записям математических выражений. Он замечательно подходит для быстрого решения логических задач, компактен и удобен, но ограничен. Например, отсутствовали слова «я» и «ты». Поэтому парадоксы, такие как «Севильский цирюльник», мозг ограниченный «Вавилоном 17», сожжет или заставит обратиться к отключенной части. То есть языковые конструкции во многом определяют способ мышления.

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

Расшифровывается это так. Допустим, что:

1. Установлено, что P1 верно. (Это утверждение называется базой индукции)
2. Для любого n доказано, что если верно Pn, то верно Pn+1. (Это утверждение называется индукционным переходом)

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

Что же такое DSL

Domain Specific Language, или язык предметной области, — это язык, созданный для конкретной области применения. Построение его, или структуры данных, отражают специфику решаемых им задач © Википедия.

То есть, если человек знает свою работу, учить DSL не надо — достаточно взглянуть один раз, и всё понятно (см. пример с математикой). Также хороший DSL не требует больших знаний в теории и практике программирования. Во многих, например, нет циклов. В некоторых — условных операторов (типа «if»). Часто язык является не полным по Тьюрингу, то есть написать любую программу с его помощью нельзя. Опять же, вспомним язык математики или кванторов. Он используется лишь для описания теорем или для их автоматического доказательства. Писать web-сервисы с его помощью было бы затруднительно.

Примеры использования DSL

DSL используются очень по-разному. Рассмотрим несколько из них и постараемся понять, в каком же случае следует их использовать.

Резак лазера

Положим, вы — инженер кораблестроитель и хотите вырезать большущую деталь для корпуса судна. Раньше это делалось так: на плотном картоне или фанере вычерчивали детальки, вырезали, прикладывали к листу стали, и люди, которых называли кернильщиками, ползали по листу и набивали по контуру выкройки впадинки. Дальше газорезчик шёл по контуру и вырезал. Представляете, что будет, если резчик с утра перебрал? А можно сделать это автоматически, чтобы робот считывал чертёж и сам ехал по листу, вырезая нужную деталь? Да, можно! Однако проблема в том, что траекторию его передвижения нужно как-то задать. Мол, поедь туда, опусти резак и дальше двигайся эдаким манером. Для этого нам нужны следующие команды:

1. Двигаться из точки А в точку Б с выключенным резаком (помним, что прямая — кратчайшие расстояние между двумя точками).
2. Двигаться с включенным резаком уже по заданной кривой (частный случай кривой — прямая). Для простоты ограничимся, собственно, отрезком прямой линии и участком окружности с заданным радиусом и центром. Поскольку положение резака задано предыдущими движениями, указать нужно лишь точку остановки. Для отрезка прямой — это конец отрезка. Для участка окружности — угол поворота и центр окружности.

Таким образом, в наиболее простом случае нам нужны только три команды:

MoveTo(x, y)
LineTo(x,y)
AngleTo(centerX,centerY, angle) 

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

Алгоритмический трейдинг

Трейдер редко ошибается дважды — обычно раза три или больше
© Из грустного опыта продавшего квартиру

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

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

1. Понятно, что цена снега в Антарктиде и на экваторе, мягко говоря, отличается. То есть необходимо указать биржу, цены на которой мы исследуем.
2. Нужно указать стратегию, с помощью которой мы будем торговать (их есть много разных).
3. Для стратегии нужно указать параметры, специфические для каждой, и временной интервал, в течение которого происходит работа.
4. Стратегии запускаются на серверах, каждый из которых работает с заданной биржей. Нужно задать время, в течение которого они работают, поскольку доступ к бирже бывает и платным.

Давайте посмотрим, как будет выглядеть эта стратегия на языке Java. Допустим, мы хотим получить сигналы о покупке/продаже валют на серверах трех бирж с помощью стратегий: «фибоначчи», «скользящее среднее», «преобразование Гильберта». Для простоты будем считать, что время измеряется в тиках, название биржи, на которой работает сервер, задается просто строкой, и торгуем мы валютами — меняем доллары, евро или ещё что-нибудь на украинскую гривню и обратно.

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

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

С другой стороны, трейдинг — это постоянный стресс и гонка. Работать нужно действительно быстро, но без ошибок. Как же быть?

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

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

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

Разработка игровой логики

Ошибка: робот погибает при попадании в него гранаты (именно от попадания, а не от взрыва). Д — дизайнер, П — программист.
Д: программисты всё сломали! почему так получается?!
П: естественно, так получается! потому, что у гранаты масса 100 кг! зачем вы это сделали?
Д: да?! а чтобы граната в воде тонула!
П: а почему она с нормальной массой не тонет?
Д: а потому что у воды плотность большая! (прим.: больше, чем у ртути)
П: а почему плотность такая большая?!
Д: а чтобы ящики деревянные плавали!
П: а почему они иначе не плавают?!
Д: а потому что у них масса 50 кг!
П: а зачем такая масса?!
Д: а иначе они некрасиво разваливаются!

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

Более того, игры сейчас выходят на множестве разных платформ. Выпустили под Windows, и надо выходить на Vii, на планшетах, на smart TV и так далее. Каждый релиз приводит к переписыванию кода, который уже работает и оттестирован, хотя логика действий персонажей не меняется при переходе от устройству к устройству. Можно, конечно, использовать кроссплатформенные средства. Такие как Unity, или Haxe, но, как правило, проблема в том, что кроссплатформа работает одинаково плохо на всех устройствах. То есть хотелось бы сделать так, чтобы разрабатывать заново нужно было только специфические для конкретной платформы вещи, оставив логику без изменений.

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

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

Конечный автомат

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

<state name="run_to_enemy"><before methods="do_something_before"/><after methods="say_hi"/>	<in_process methods="say_hug"/><transitions><transition name="shoot" methods="run"><condition function="near_the_enemy && have_bullets"/></transition></transitions></state><state name="shoot"><before methods="do_something_before_shoot"/><after methods="say_hia"/>	<in_process methods="say_bum"/><transitions><transition name="run_to_bullets" methods="hi"><condition function="no_bullets"/></transition></transitions></state><state name="run_to_bullets"><before methods=""/><after methods=""/>	<in_process methods="run"/><transitions><transition name="run_to_enemy" methods="eat_bullets"><condition function="near_the_bullets"/></transition></transitions></state>

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

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

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

Выводы

Все рассмотренные DSL:

1. Небольшие и не требуют изучения. Это справедливо и в общем: язык предметной области с большим порогом входа — плохой.
2. Позволяют оперировать терминами предметной области, без деталей программной реализации. Говорят ЧТО делать, а не КАК.
3. Избавляют специалиста от необходимости получать высокую квалификацию в программировании.

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

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