Для кого это статья

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

Для QA Engineer без опыта, лишь бы не пугаться страшных технических слов, которые будут в статье. Первый раз устраиваться на работу сложнее, потому что меньше отвечают на резюме, но цитирую: Не бьешься не добьешься (к/ф Ловец Снов).
Если не лениться, опираться на советы в интернете, то работу найти можно в течение месяца спама резюме и сверканием своей физиономией на собесах.

Для QA Engineer с опытом работы в полгода, когда ты уже знаком HR-ам, у тебя на руках отзыв от первого работодателя и толковая причина смены компании.

Остальные, кто уже несколько раз менял работу, могут просто услышать историю о том, как QA Engineer искал работу.

Про себя

Парень, 30 лет, родился в СНГ, закончил офлайн курсы QA Engineer от EPAM, хорошо владею английским (B2).

Опыт в ИТ

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

Образование

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

Жизненный опыт

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

Пока путешествовал удаленно приходилось зарабатывать разными способами:

• делал сайты на WordPress, никакого кода, база HTML + CSS, работа с хостингом
• занимался графическим дизайнер: лого, брошюры, иллюстрации и digital портреты
• фотографировал и ретушировал изображения

Почему решил сменить предыдущее и одновременно первое место работы

• Не было английского языка на проекте
• Хотел в автоматизацию
• Нужны менторы, которые бы научили best practices, так как со мной в команде QA была только девочка-учитель английского
• Постоянные овертаймы: периодами три раза в неделю до девяти-одиннадцати, вечера на работе и никакой ясности о будущем
• Больше ЗП, там был потолок в 300 долларов для меня на ближайшие полтора года, но я не плакал первый опыт

Как только получил более или менее несколько месяцев опыта сразу же убежал искать новое место.

Несмотря на маленький опыт (совсем маленький как я понимаю) я хотел найти удаленную работу. Да, мне десяток сеньористых разрабов и тестировщиков покрутили у виска, ни один не верил в успех. Но я верил.

Что я сделал для больших перемен

Доработал резюме

Заполнил LinkedIn по-правильному (тысячи статей в гугле):

• нормальная фотография
• в хэдэре чётко прописал свою позицию QA Automation Engineer
• заполнил самари и прикрепил CV
• добавил курсы пройденные
• Обновил резюме в соответствии с тем, что требовалось в вакансиях и сохранил его в PDF

Написал красиво Cover Letter

• 4-5 предложений, которые человек может просканировать глазами за 5 секунд (разбить на абзацы), и если он схватит нужную ему инфу смог прочитать за 15-20 секунд
• в нём нужно указать опыт или то, почему вы можете быть рассмотрены на желаемую позицию
• написать, что именно вы хотите: I would like to express my interest in applying for a full-time QA manual/automation position
• текст должен начинаться и заканчиваться банальными фразами Здравствуйте представители компании .., I am eager to discuss the contribution I can make to your company, Name Surname
• в cover letter прикрепите в конец линкедин ссылку, HR если заинтересуется, то он может сэкономить время и глянуть профиль, а не скачивать и читать ваше CV.

Ещё учил Java вечерами/утрами еще до увольнения с предыдущей работы, гуглил топ-скилы, которые могут пригодиться новому работодателю, и прокачивал их, потому что всё новое всё нравилось.

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

• топ вопросов по SQL на собеседовании,
• топ вопросов по Selenium на собеседовании,
• Linux на собеседовании,
• теория тестирования на собеседовании

Готовился, как готовились к экзаменам в ВУЗе, если пропустили весь семестр

Отправлял резюме потенциальному работодателю

• Спамил всех, кто набирает на удаленную работу разрабов. За 5 часов поиска нашел 30 сайтов с разными вакансиями.
• Спамил в LinkedIn рекрутеров с вопросом: а есть ли удаленные вакансии? (5% были успешными и меня перенаправляли на нужного мне HR.)
• Спамил компании своего города с пометкой ищу удалённую работу. Я со столицы поэтому много фирм, можно найти, если усерднее искать. Но интереснее было именно в 100% зарубежную компанию.

В итоге прошел пять собеседований

1. Онсайт в моем городе, был оффер., Работа предполагалась в офисе, без удалёнки. Согласился, потому что нравилась тематика и кайфовал бы от работы над проектом.

2. Европейская компания с релойкетом на Кипр. После собеседования предложили офер с релокейтом к ним на Кипр в офис.

3 и 4. Собеседования в британскую и немецкую компании, которые не понравились из-за разговора и перспектив в фирме: либо исключительно ручное тестирование, либо part-time и без ментора, что равнозначно потерянному времени.

5. Самое первое интервью на удалёнку в европейскую компанию на американский проект. Прошёл, работаю там по сей день.

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

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

Что было на интервью (самое интересное из статьи)

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

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

Вкратце, что было из вопросов

1. Европейская компания

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

Еще через неделю было второе техническое.Два интервьюера, без видео. 110 минут выноса мозга. 110. Минут. Без перерыва. Без остановок. Это было мое первое настоящие айтишное интервью, так как на первую работу попал по блату: знакомый оказался тим лидом и в компанию требовался любой тестер, а я вроде как не глупый и с сертификатом EPAM QA Engineer.

Вопросы:

• Прошлый проект, какие технологии, за что отвечал на проекте
• В теории разница между severity / priority
• Типы тестирования (Функциональное? а что это значит такое вообще функциональное? Ты уверен? Exploratory testing? а что это и как делается и какие деливереблз по итогу? (на 10 минут дискуссий)

• Вот ты тестишь web app, у тебя ошибка. Где смотреть ошибку? А какая вкладка в дэв тулз? А как ещё можно посмотреть эти ошибки?
• Какие ошибки бывают? А что делать если прилетела 400 ошибка? А вот у тебя 500 error и Кибаны нет, твои действия? А ещё? а ещё?

• Тест план из чего состоит, что туда не входит? Копали минут 15 на эту тему.
• Дано одностраничное веб-приложение, (банальный вопрос, к которому я не подготовился). Слева три энтри-филда для ввода сторон треугольника и батон submit. Справа результат построения фигуры. У вас два дня на релиз.

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

• В винде: разница между processes и application, где они? И ещё парочка вопросов, чтобы понять, на каком уровне человек владеет компьютерной грамотностью.
• В принципе, что происходит когда ты нажимаешь кнопочку сабмит? А каким именно запросом? А почему не GET? а дальше что приходит? а где куки и где кэш?

• Что такое DNS? ну хорошо, это ясно, но а как оно работает?
• Linux у тебя в резюме написано? Команды: вывести список файлов в папке, чтобы список был со всей инфой о пермитах, как их менять их и пользователя; где смотреть из-за чего идёт краш системы; какие процессы запущены и нагрузка; смотреть свой айпи. А кстати скажи-ка нам свой айпи сейчас? Это внешний? А внутренний какой? Какие команды в линукс используешь?; посмотреть последние записи документа (tail), вим? баш команды? На всё что я говорил ЗНАЮ, копали глубже. Например, где глянуть сетевые настройки? nslookup а что там отображается, кроме айпишки и мака? ОК, давай весь вывод команды рассказывай по памяти

***Спрашивали не просто так, линукс действительно очень нужен в работе.

• Java? Ну, поехали по джаве по-спрашиваем: Что значит слово статик, Tell me about constructor in Java, what is 'an instance', how to create?, сколько может быть мэйн методов, наследование, рекурсия и все в этом духе.

• SQL с какими работал, какие знаешь, посчитать максимальное значение, джойн. Причём на ровном месте: Так, слушай внимательно. Даны две таблицы. В одной юзеры, в другой страны, и скажи мне запрос, который выводит INNER JOIN. Тут мне пришлось переспросить и внятно сказать (не получилось внятно) запрос. Потому что ты ведь не пишешь, ты говоришь, тебя слушают. Если не услышал или не запомнил названия столбцов задача не решена. The best challenge ever!

• Если конфликт, как решается?
• Почему ты в тестировании?
• Почему ты нам подходишь?

По итогу, на 105 минуте разговора, длящегося без перерыва, мне задали вопрос: Ну что, а какие у тебя вопросы к нам?

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

Ещё момент: сразу предупредили: Мы будем копать, всё норм. Можно отвечать НЕ ЗНАЮ. Сэкономит время и будет честно. В итоге без зазрения совести, часто с улыбкой я: Неа, не знаю что это, даже не слышал.

2. Европейская компания с перспективой релокейта на Кипр

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

Интервью 60 минут. Первые 45 мин:

• типы тестирования
• севирити-приор
• с чем работал
• какие тулы применяются и какие применял для разных типов тестирования
• что тестировал и как расскажи сам

По технической части все. Затем лайтовые 25 мин:

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

Через неделю попросили референс на LinkedIn от моего предыдущего руководителя.

3. Продуктовая немецкая компания

Третье интервью с продуктовой немецкой компанией. Штат 5 основных членов команды, и около десяти студентов, приходящих и уходящих практикантов. Требовался основной QA Engineer, но на полставки, причем ищем ручника, но если тебе будет удобнее и необходимо писать автотесты на здоровье.

Интервьюеры CEO и HR, задавали вопросы по очереди по видеосвязи:

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

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

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

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

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

Результат: не отчитывался, но мои таски были видны. Писали на email, чтобы продолжить общение, но я сказал: Sorry, but no.

4. Британская компания

В Британскую компанию предлагали удаленно, или релокейт, потом посмотрим...

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

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

5. Онсайт в моем городе

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

Этапы общения:

Предварительно пятнадцатиминутный разговор по телефону с HR через дней пять после моего спама. Еще через дней пять назначили встречу в офисе.

Меня опрашивали три QA менеджера и лида. Продолжительность собеседования 50 минут, но в быстром темпе. Только важное и без заминок.

Что было:

• один из экзаменаторов, тимлид, зашёл с ноутом, позвал меня и спросил: Вот real-life задание: что-то не так. Твои предположения? Я сам ещё не разбирался, только что прилетело Там был какой-то лог с кибаны и серверной ошибкой с докером.
• Рассказать про себя, почему в тестировании, а не скучно ли и бла-бла как везде и всегда, уже стало скучно отвечать на этот вопрос в пятый раз.
• Аутентификация vs авторизация.
• Кто виноват, если баг на проде.
• У нас есть дэв и прод энвайронменты. Всё. Нет стэйджинга. Что нужно сделать, чтобы всё было удачно? Ок, а что сделать, чтобы было максимально безопасно?
• Что такое дженкинс? За что отвечает? А какая разница между CI и CD?
• Java and the whiteboard: Сможешь написать на доске простенькую задачку типа вывод чётного или нечётного? Давай попробуем и всё это в формате диалога, а не спросил-ответил. Если туплю, то подсказывают и рассуждаем вместе. Шикарно.

Чего не было, удивило:

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

Результаты поиска работы и мои офферы с зарплатами

Всё. Больше собесов не было.

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

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

1. Кипр. Кипру я понравился. Разработчик сказал, что ему понравился мой background сомелье, и он хочет разбираться в вине, поэтому и выбрал меня. Без понятия, насколько это правда.

Через неделю после собеседования на email выслали оффер, огласив цифру salary (я не подписывал NDA, могу смело говорить вслух 2600 евро чистыми, 3200 грязными)
Это случилось в день собеседования в моем городе. На радостях пишу HRу и говорю: Сорри, тут мне предложение сделали, от которого нельзя отказаться.

2. Удаленка в европейской компании. За неделю до этого мне удалённая работа от европейской компании сказала: Ты нам понравился, жди оффера, ты наш. И я жду, но ищу синицу в руках.

3. Онсайт в моем городе. Компания в моём городе тоже готова сделать оффер. Изначально просил 800, сами подняли и предложили 1000 долларов, что выше всяких статистик с моим опытом. Причём компания моей мечты, но я со слезинкой говорю им: Сорри. Я в Кипр, наверное.

Дальше лирика, можно закрывать статью

Но те, кто дочитал до этой строчки, узнают еще об одном важном факторе принятия на работу. Он называется Soft Skills.

Я самоуверенный парень, думал, что всё в кармане. Еду на Кипр с шикарной ЗП и теплой жизнью. Честно говоря, не очень хотелось: непонятная работа и далеко от дома, плюс я уже устал жить далеко от Родины, требовался отдых. Но зарплата привлекала

Спустя месяц молчания от Кипра, когда я уже даже анализы ВИЧ и другие штуки для релокейта отправил вместе с пакетом документов, я перегорел.

Решил остаться дома и написал кампании в моём городе (которых я кинул из-за Кипра), и там меня ждали.

Пришёл, оговорили ЗП, сказали: Завтра будет оффер. На завтра его не было.

Вот они, soft skills: Дмитрий, извините, мы взвесили все за и против и не готовы взять на себя ответственность, вдруг вы всё-таки передумаете и уедете на Кипр. Так что желаем вам удачи.
Ах, если б они знали, насколько я хотел быть с ними Жаль.

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

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

Но я рад: команда шикарная, цели приземленные, документация божественная. То, что задумывал осуществил.

P.S. Мне Кипр ещё писал, но я отказался. И это того стоило!

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

Если вам необходимо спроектировать взаимодействие двух систем, в каких случаях вы выберете RPC, в каких REST, а в каких MQ?

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

---

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

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

Во-вторых, модель взаимодействий может быть однонаправленная (one-way) и вызовы вида запрос-ответ. Если вы исповедуете CQS, соблюдаете требование идемпотентности, то скорее всего вызовы будут однонаправленными.

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

Выбор

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

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

Сценарий транзакции

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

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

Исходя из определения, данного Мартином Фаулером, вызывать необходимо определённый сценарий и в определённой последовательности. RPC подход появился именно отсюда. Т.е. подойдут такие протоколы как: Sockets, WebSockets, gRPC, SOAP и другие.

Обработчик таблицы

Одна сущность обрабатывает всю бизнес-логику для всех строк таблицы БД или представления.

Для данной формы организации доменной логики характерна работа над отдельными таблицами, с помощью репозиториев, реализующих CRUD-операции. Сервис строится с использованием API-Controller адаптера к репозиторию реализующий удалённый вызов CRUD-процедур с использование протокола HTTP. Таким образом, если ваше приложение базируется на БД с отдельными репозиториями, вам наиболее подходит REST протокол. В ряде случаев, особенно полезным становится использование протокола OData, расширяющего REST.

Модель предметной области

Объектная модель домена, объединяющая данные и поведение.

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

Шаблон доменная модели, как можно видеть, очень похож на сценарий транзакции, но (1) имеет очерченные границы (Bounded Context), и (2) связан с доменной сущностью (агрегатом). Структура данных при этом сокрыта за абстракцией и может быть реляционном виде, а ещё проще когда в нереляционном.

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

Совершенно по-новому в этом отношении смотрится gRPC замена Windows Comunication Foundation. С последним очень часто бывают существенные проблемы соразвития, особенно если интеграция происходит с командой, интеграция с которой оставляет желать лучшего (т.е. худшие варианты карты контекстов тут не подходят). В рамках же смыслового ядра считаю технологию оправданной. А сам RPC подход был бы наиболее верным.

Отдельные возможности открываются для брокеров сообщений как средство получения ответа от сервиса, ведь доменная модель идеально подходит для получения очень чистых событий предметной области, потребителями которых могут быть любые другие сервисы, а сама ШИНА ДОМЕННХ СОБТИЙ может стать превосходным средством масштабирования. Организуя архитектуру определяемую событиями, важно не забывать про возможность циклического вызова, про маркеры корреляции.

---

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

---

Что почитать

• Мартин Фаулер | Шаблоны корпоративных приложений | ISBN 978-5-8459-1611-2 | Глава 9. Представление бизнес-логики
• Хоп Грегор, Вульф Бобби | Шаблоны интеграции корпоративных приложений | ISBN 978-5-8459-1946-5
• Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем | Эрик Эванс | ISBN 978-5-6040724-9-3
• Крис Ричардсон | Микросервисы. Паттерны разработки и рефакторинга | ISBN 978-5-4461-0996-8 | Глава 5. Проектирование бизнес-логики в микросервисной архитектуре.