Speaker A
Да, естественно, к собеседованию тебе нужно подготовиться к первому же скиннингу, чтобы таких технических проблем не было. Ну, ты сам понимаешь, да, и свино. Это первый раз такое вообще произошло.
Собеседование на позицию тестировщика в Сбере: обсуждение опыта, инструментов и советов по презентации себя.
Ask about this video. Answers come from its transcript only — with the timestamp, so you can check them.
Generated from the transcript and can be wrong — check the timestamp.
Key Takeaways
- Подготовка к собеседованию должна включать отработку рассказа о себе своими словами и взглядом в камеру.
- Лид тестирования не входит в функциональную команду, а является выделенной ролью.
- Важно чётко и просто объяснять причины поиска новой работы, избегая излишних деталей.
- Знание инструментов и процессов тестирования, а также архитектуры проекта — ключ к успешному собеседованию.
- Практика и тайминг рассказа о себе (около 3 минут) значительно повышают шансы на успех.
What the video covers
- Обсуждение подготовки к собеседованию и важности презентации себя живо и уверенно.
- Описание проекта личного кабинета в Сбере с микросервисной архитектурой и высоконагруженной системой.
- Подробный рассказ кандидата о предыдущем опыте в Альфабанке, используемых инструментах и процессах.
- Советы по улучшению подачи информации на собеседовании, включая рекомендации по взгляду в камеру и свободному изложению.
- Обсуждение причин поиска новой работы и правильного позиционирования себя на интервью.
- Разбор технических аспектов тестирования, таких как инструменты, процессы и архитектура.
- Акцент на важности понимания разницы между тестированием веб и мобильных приложений.
- Рассказ о командах, процессах Scrum и взаимодействии с другими ролями в проекте.
- Обсуждение систем логирования, CI/CD и работы с микросервисами.
- Рекомендации по подготовке к разным этапам собеседования и важности практики рассказа о себе.
Chapters
- 00:00Введение и подготовка к собеседованию
- 03:17Описание стека и инструментов проекта
- 06:35Советы по презентации и подаче информации
- 09:15Обсуждение причин поиска новой работы
- 11:42Вопросы о платформах и релизах
- 14:52Техники тест-дизайна и виды тестирования
- 24:26Работа с микросервисами и архитектура
- 33:30Логирование, CI/CD и отличия тестирования веб и мобильных
- 48:30Обсуждение количества собеседований и технические проблемы
Full Transcript — Download SRT & Markdown
Speaker A
Бывает. Главное, что обнаружили. Так, давай. А, значит, да, значит, я собеседую у тебя в Сбер. Давай, я буду лидом тестирования. Я тестирование. А мы теперь собеседуем на проект вот, знаешь, личного кабинета в Сбере, да, вот этот личный кабинет, там где деньги лежат и в
Speaker A
мобилке, и в веб-версии, да? То есть у нас есть Webmobile, а просто Mobil iOS Android. Э, значит, в команде уже есть два тестировщика. Мы ищем третьего для усиления команды. А значит, тут есть огромное количество микросервисов, очень высоконагруженная
Speaker A
система. А много интеграций. А, э, я, получается, лид тестирования. Я твой линейный руководитель, но не функциональный. Твой функциональный руководитель будет команды, в которую ты отправишься. Э, в это, ну, обычная кроссфункциональная продуктовая команда.
Speaker A
Там вот сейчас два тестировщика, потом ещё там разработчики, аналитики, а получается лид команды, он разработчик, вот он является мобильным разработчиком, он же является лидом команды. Вот. А я не вхожу в команду, да, я как бы являюсь руководителем всех тестировщиков в
Speaker A
разных командах во всём нашем домене. Да. Вот. Э, про проект я тебе так поверхностно рассказал. Мм. Мм, вот теперь расскажи про себя, пожалуйста.
Speaker A
А в конце после всего собеса оставим момент для твоих вопросов ко мне. А пока сейчас вот расскажи, пожалуйста, о себе коротко. Я посмотрел твоё резюме. Вот. Ну, сделай акцент, конечно, больше на последнем месте работы, да, ну, так плюс-минус там
Speaker A
последние два-три. Вот расскажи, пожалуйста, да, чем занимался. Ну там особенно интересует стек, да, подходы, процессы в меньшей степени, продукт, да, но, ну, короче, да, расскажи про себя, пожалуйста, угу. Да, ещё раз здравствуйте. Зовут меня Евгений. В тестировании я уже около
Speaker A
4 лет. Начинал я свою работу в Сибуре цифровом. Вот. Потом я работал в ВК. А последнее моё место работы — это Альфабанк. А вот проект Альфабанка, сервис альфа-командировки.
Speaker A
Ну, вкратце расскажу, что это вообще за проект. Это такая B2B платформа для организации деловых поездок сотрудников.
Speaker A
Вот где можно добавлять сотрудников, управлять и их правами, доступами, травел политиками, а также лимитами на расходы. С помощью этого сервиса можно бронировать авиабилеты, а также отели.
Speaker A
Вот на проекте было порядка 20 микросервисов. Наша команда отвечала за три из них. Это сервис сотрудников, сервис командировок и сервис travel политики.
Speaker A
Так вот, по стеку: Джира, а мы использовали для отслеживания задач и заведения багов. А Confluence у нас в ней хранилась документация по проекту. Аа Postman использовали мы для работы с API. Swagger для документации API. Аа, мм, получается, что ещё, а, мы
Speaker A
писали тесткейсы и чек-листы. А GitHub использовали в качестве Git-репозитория, Jenkins как CI/CD. OpenShift в качестве оркестратора.
Speaker A
Вот так. Кафка у нас был как брокер сообщений. Для просмотра топиков и сообщений у нас было в set Explorer, Kibana. А, получается, мы анализировали, смотрели логи, данные хранились в Elastic Search.
Speaker A
А, и для работы с макетами использовали мы Figma. В качестве базы данных у нас была PostgreSQL, а работали через DBeaver. Так что по команде, наверное, по команде, по процессам расскажу. У нас было в команде два мануальных тестировщика, один
Speaker A
автоматизатор, четыре разработчика, два фронтенд-разработчика, системные бизнес-аналитики, а проект-менеджер, DevOps и UX/UI дизайнер. А работали по скрам двухнедельными спринтами, но тут всё по стандарту. А груминг, планирование, дейлики, ретроспективы.
Speaker A
А вот раз в месяц проводили приёмосдаточные испытания, так как это банковский продукт. Вот для стейкхолдеров. А релизились мы обычно по четвергам.
Speaker A
Вот работал я примерно в соотношении, ну, фронтбек в соотношении примерно 60 на 40 в пользу БЭКа. Ну вот, занимался ручным функциональным тестированием. Вот, пожалуйста, ваши вопросы.
Speaker A
Ага. Так, красава. В целом для первого раза хорошо. В 3 минуты уложился. 2 минуты 55 секунд. Вот. Да, в предел 3-х минут уложился. Есть пару моментов, которые я услышал. Ты сказал, что лид тестирования входит в команду. Лид тестирования никогда в функциональную
Speaker A
команду не входит. Он всегда будет всё-таки выделенной ролью. Вот напиши себе это. Внутри команды обычные тестировщики. Вот. Угу.
Speaker A
Потом что ещё? Звучало так, что когда будто читаешь, это не очень хорошо. Надо смотреть. Вот вот это же к тому, что я сказал. Если бы ты смотрел в вебку и прям прямо в камеру и говорил бы своими словами, это было бы,
Speaker A
ну, всё то же самое. Это было бы в 100 раз живее и лучше. Тебе нужно это выучить как некий шаблон, но рассказывать своими словами. А сейчас ты как будто прямо по бумажке читал. И это был ещё глазами
Speaker A
смотрел не вебку, а на монитор. То есть это выглядит чисто, как будто ты читаешь, даже если ты не читал. Вот поэтому вот на этом сделай акцент. Это прямо я бы даже это раньше это не выделял так важно. Сейчас я это выделяю
Speaker A
как прямо отдельный отдельный блок собеседования, ну отдельный блок, из которого состоит собеседование, потому что это важно и для скрининга, и для собесов технических, для третьего этапа.
Speaker A
Короче, для всех созвонов сама презентация нужна, поэтому она должна быть идеальная. Сам с собой посиди.
Speaker A
Я бы тебе даже дал задание прямо записать. Можно без видео, просто записать. Мне вот я моему ментору по проекту, с которым я сейчас занимался, он меня прямо заставлял, говорит: "Таймер ставишь 3 минуты, шаблон у тебя есть, своими словами рассказываешь, вот
Speaker A
без запинок, убедительно. Ты не запинаешься, когда рассказываешь реальную историю, понимаешь? Тебе не нужно что-то вспоминать, это у тебя прямо отлетает от языка должно. Поэтому вот над этим нужно ещё поработать. Но по фактуре, по всё остальное, то, что ты
Speaker A
перечислил, все блоки, да, процесс затронул, скрам, да, состав команды, инструменты, микросервис, то, что там много микросервисов, это ты сказал. По сути всё правильно, да? Только вот нужно над изложением поработать. Вот. Всё, всё окей. Давай дальше. Так, отлично, хорошо. А
Speaker A
давай тогда перейдём к моим вопросам. А расскажи, пожалуйста, вот а почему ты сейчас уже уволился или ты всё ещё в компании и почему находишься в поиске? Вот.
Speaker A
Угу. Нет, сейчас я ещё до сих пор работаю. А у нас в компании пошёл слух о реструктуризации. Угу.
Speaker A
Вот хотят нашу вообще команду всю реструктуризовать, а вот и, соответственно, сервис передать вообще, чтобы он был под эгидой другого, ну, скажем так, корсервиса Alpha Travel.
Speaker A
Угу. Вот. И остальной функционал отдать технической поддержке. Поэтому я решил не ждать, уморе погоды искать уже новое место.
Speaker A
М. А почему ты уверен, что тебе обязательно сократят? Может быть, тебя вот реструктуризируют и как-то, ну, будешь в новой, будешь в новом юридическом лице или в новом департаменте. Какая разница?
Speaker A
Ну, ээ, мне кажется, что я уже поработал достаточно в этой структуре, изучил её изнутри, поэтому мне хотелось бы для себя увидеть что-то новое. То есть появилась некая точка роста, и поэтому я и следую.
Speaker A
Ну вот тут, смотри, ты правильно начал. Только единственное, ну, всё проще можно сказать. Да, у нас просто сейчас идут сокращения, и моих коллег многих уже сократили, и есть риск, что я пойду под сокращение, поэтому я... Но это всё
Speaker A
равно не самая выгодная позиция. Самое выгодная — это я тебе сейчас, ну, говорю, я всё ещё работаю. Это правильно, да, ты всё ещё работаешь, потому что, да, чтобы не казаться в положении просящего. Я всегда хожу пассивно на собеседование и рассматриваю
Speaker A
интересные мне предложения. И я хожу только на те собеседования, которые мне интересны. Не на все, которые меня зовут, а только те, которые мне интересны. И если мне интересен новый проект, там меня привлекают финансовые условия и всё остальное, я, в
Speaker A
принципе, готов туда перейти. Вот так. Это вот меня опять же моё самое такое актуальное, мой самый новый ответ по этой истории. Раньше я тоже говорил там про риски сокращ...
Speaker A
знаешь, поскорее ищешь работу. Ну, ну я согласен фраза. Это не фраза про то, что ты сказал ещё ещё что-то сказать. Давно работаю и ещё что более интересное. Это плохая вообще. Это означает, что ты не готов долго работать в одной компании. А они ищут всегда раба
Speaker A
надолго себя, понимаешь? Поэтому тут нельзя говорить, что тебе надоело, стало скучно. Это плохой ответ. Вот.
Speaker A
Угу. Ну, о'кей. А если такой ответ, что, ну, проект передали, ну, и передают в скором времени поддержки.
Speaker A
Угу. Вот. И, соответственно, то есть он заканчивается, ты это имеешь в виду? Да. Да. Нет, нет, не то, что он заканчивается, разработка закончилась, но новые новые фичить не будут. Вот останется только вот поддержка, ну, на которой присутствуют специалисты первой,
Speaker A
второй, третьей линии. Я так говорил, да. Угу. О'кей. Вот смотри, по поводу твоего. Я всегда хожу пассивно на собеседование.
Speaker A
Мне кажется, это тоже не совсем корректный ответ. Почему? Потому что они могут подумать: "Ну, если ты каждый раз ищешь, куда тебе выгоднее съебаться, то, возможно, ты съебёшься и от них тоже.
Speaker A
Ну, как только у тебя появится возможность". Поэтому, блин, мне кажется, тут стоит придерживаться какой-то нейтральной позиции. Вот, может быть, действительно стоит говорить о том, что, а, проект передаёт поддержки.
Speaker A
Вот он заканчивается, да? То есть основ, давай так, активная фаза разработки заканчивается, да? Он переходит на этап поддержки, и поэтому я так Да, да, да, да. И для меня тут типа работы уже больше скоро не будет, поэтому я вот,
Speaker A
да, вот так можно сказать, да, я я так сам тоже говорил, да. Угу. Это норм. О'кей.
Speaker A
О'кей. Аа так. А как часто у вас были это? Какие какие платформы у вас были, да? То есть мобильные или веб? А и как часто у вас были релизы вот тех платформ, которые ты тестировал?
Speaker A
Угу. Ну, вообще у нас было две платформы: Webmobile, но вот мы отвечали именно за веб-версию. Угу.
Speaker A
А получается, мобилки это было, ну, функциональностью другой команды. Угу. Вот поэтому, да, отвечали мы преимущественно за веб, иногда помогали мобильщикам, но вот именно с веб-версией, например, мобильного приложения.
Speaker A
Ага. Ага. А, а вот как часто у нас релизы? Но релиз у нас обычно проходил в четверг, то есть, чтобы зарелизиться как раз неделю получается.
Speaker A
Ну, вообще, да, ну, на самом деле у нас релиз не был привязан к спринту, то есть мы могли зарелизиться раньше, если раньше допилим фичу, могли зарелизиться позже. То есть, ну, просто это, скажем так, такая путеводная звезда была, да,
Speaker A
на то, чтобы, а-э, вот в скраме а работали по двухнедельным спринтам, чтобы за 2 недели запилить какую-то фичу.
Speaker A
Как-то так. О'кей. Ладно. А-а, как часто был регресс? Ну, регресс у нас был на обычно на второй неделе спринта. выделялось на него 2 дня. Ну, это обычно со вторника по четверг, то есть в четверг, ну, точнее вторник и среда. В
Speaker A
четверг у нас уже обычно проходил релиз. Угу. То есть, а, в понедельник вечером уже был код приз, то есть разработчики за заканчивали а пилить какие-то фичи, останавливали разработку. Вот. Угу.
Speaker A
И далее вот вторник и среда выделялся он как раз-таки на регресс. О'кей. А давай так. Вот такой вопрос тебе задам.
Speaker A
Вот вот у те у тебя происходили, да, получается, регулярные регрессы перед, а, расскам релизом. А были ли ситуации, когда, э, вы не успевали провести полный регресс? И что тогда вы делали в такой ситуации?
Speaker A
Ну, такие ситуации, на самом деле, очень часто происходят. А вот, ну, как обычно делаем, а, то есть, я созваниваюсь с разработчиком, с аналитиком, вот, и выясняю, на что новая фича может заэффектить конкретно.
Speaker A
Вот на на основании этого создаём такой некий импанализ. Вот. Угу. И проверяем смежные блоки, вот, на которые может заэффектить новая фича.
Speaker A
Если времени совсем не остаётся, то прогоняем смоукте. Вот. И, соответственно, такое вот у нас покрытие. А если регресс происходит у нас, ну, всё нормально, как бы по времени мы не ограничены, то также мы созваниваемся, прежде всего проводим небольшой импанализ.
Speaker A
Вот. И есть у нас такое новое новое введение. Мы используем матрицу трассировки. То есть это соотношение требований и покрытие. Ой, и получается тесткейсы. И, грубо говоря, на перепуте мы ставим галочки. И так мы проверяем покрытие требований тесткейси.
Speaker A
Хорошо. Да, ну тут самое главное ты сказал про, соответственно, господи, забыл, смок, да, тут хотят услышать про смок обычно в этом вопросе, да, то, что мы делаем смок, если мы полную регрес успеваем.
Speaker A
О'кей, давай дальше. О'кей, давай перейдём к таким техническим вопросам, быстренько по ним пробежимся. Вот расскажи мне вообще, что такое тестирование в твоём понимании?
Speaker A
Ну, тестирование - это проверка между ожидаемым и фактическим результатом поведения программы вот на специальном наборе тестов, выбранных определённым образом.
Speaker A
Отлично. Хорошо. А какие виды тестирования ты чаще всего используешь и какие вообще есть? Ну, если говорить о видах тестирования, их всего два. То есть функциональные и нефункциональны. У, а вот, а если мы говорим про типы тестирования, то это уже немножко
Speaker A
другое. Ну, расскажи, да, про типы, да, про типы, да, расскажи. Ну, о'кей. Про типы тестирования. Ну, о'кей. Бывает по запуску кода на исполнение статическое, динамическое, по функциональности тестирования, функциональное нефункциональное тестирование по установке, инсталляционно ну инсталляционное тестирование, где проверяется установка,
Speaker A
обновления удаления. Вот. А что ещё? Кроссбраузерное тестирование, кроссплатформенное тестирование. Ну, на самом деле, типов тестирования достаточно много. Сложно всего помнить.
Speaker A
Вот. Ну, самое основное, конечно же, это функциональное тестирование, то есть функциональные виды тестирования по уровню функциональности тестирования.
Speaker A
Вообще как бы, что, ну, от малого до большого у нас может быть. Это получается мы начинаем всегда со смоков, то есть просто проверяем, работает ли сборка вообще. Если не работает, то, в принципе, дальше тестирование бессмысленно. Вот потом дальше мы можем пойти по тестированию
Speaker A
критического пути. Это вот именно по функциональности тестирования, по уровню его. А вот то есть основные пользовательские сценарии, в общем, зачем нужен вообще продукт. Ну и также расширенное тестирование, где уже проверяются какие-то нефункциональные аспекты, то есть как работает наша
Speaker A
система, как надёжно, как безопасно, как стрессоустойчиво. Угу. Вот. Ну как-то так. Я ответил на твой вопрос.
Speaker A
Да. Хорошо, спасибо. Э, о'кей, давай дальше пойдём. Расскажи мне про техники тест-дизайна, вот которые больше всего используешь в тестировании, при создании тестой документации.
Speaker A
Да. Ну, чаще всего я использую эквивалентное разделение, анализ граничных значений, диаграмма состояния переходов очень хорошо подходит, а, для моего продукта, для нашего, потому что у нас есть разные роли. И в соответствии с тем, какая у тебя роль, ээ, ну,
Speaker A
пользователю доступен разный функционал. Угу. Вот. Либо либо недоступен. Угу. Модель. Угу. Да. Также есть техника попарного тестирования.
Speaker A
Угу. Вот. Ну, мы, на самом деле, используемся пользуемся редко. Также, э, техника тестдизайна можно выделить как избыточное тестирование, но оно не применимо практически. Ну, просто я знаю, что вот оно есть, потому что один из принципов тестирования гласит, что избыточное тестирование не
Speaker A
выполнило. А вот расскажи как раз про принципы, раз ты затронул, да, какие есть принципы тестирования?
Speaker A
Ну, вообще этих принципов, по-моему, шесть или семь. Ну, первый принцип, наверное, тестирование зависит от контекста. Пояснять нужно или нет? Просто поми просто перечислить.
Speaker A
Вот. То есть первое - это тестирование зависит от контекста. Второе - это избыточное тестирование невозможно.
Speaker A
А тре третье - это парадокс пестицида. Четвёртое - это раннее тестирование. А пятае, пятое, пятое. Что-то, блин, сумбурно в голове сейчас не приходит. Ну я, в принципе, все их знаю.
Speaker A
А вот раскрой парадокс пестицида. Что это такое? Ну, парадокс пестицида, если мы будем каждый раз использовать одни и те же тестовые данные, то рано или поздно они, ну, перестанут выявлять новые баги.
Speaker A
Угу. У. То есть это означает то, что тестовые данные нужно периодически обновлять. Угу. О'кей. Хорошо. Расскажи про пирамиду тестирования. Сколько там уровней и почему она в виде пирамиды?
Speaker A
Ну, пирамида тестирования - это классическое представление по тому, сколько, в принципе, каких и сколько тестов у нас должно быть. Если мы берём классическую пирамиду тестирования, где четыре уровня, а на первом у нас уровне идёт это модульное тестирование, то есть
Speaker A
где разработчик обычно пишет модульные тесты. Это самое такое основание, самое большое больше всего там тестов, потому что а они дешевле всего, потому что их проводит сам разработчик, и они довольно-таки быстрые. Дальше у нас идёт интеграционное тестирование, то есть мы проверяем взаимодействие между
Speaker A
этими модулями, юнитами. А дальше у нас идёт системное тестирование, где мы проверяем, в принципе, работу системы в целом. И также вот есть у нас приёмочное тестирование. А вот, соответственно, чем мы движемся по конусу вверх, а, к верху пирамиду, тем тестирование становится
Speaker A
дороже. Поэтому необходимо распределять, ну, скажем так, ресурсы пропорционально, чтобы всё было нормально. Угу. Да, правильно. Хорошо. Так, отлично.
Speaker A
О'кей. А давай тогда задам тебе вопросы по пишке. Вот расскажи, какие есть, что такое рест, чем отличается от сап. Вот давай с этого начнём.
Speaker A
Ну первое что хочу сказать, что такое, это representation, ладно, точно не помню. А вот это архитектурный стиль. А вот, то есть это набор, скажем так, методов и ограничений, а, которые используются в клиентсерверной архитектуре. То есть они, э, если мы
Speaker A
используем, то мы работаем по протоколу HTTP, используем методы HTTP. Угу. Вот SOAP - это уже протокол, то есть он строго типизированный, очень похож он, ну, он из он работает только с форматом XML, а вот это такой формат, состоящий из ээ из открывающих,
Speaker A
закрывающих вот этих вот а тегов. Используется тандом система. Очень похож на разметку страницы HTML. Вот он более такой строго строго типизированный. То есть он такой больше, ну, гибкий по сравнению с эапом.
Speaker A
О'кей. А-а, какие есть методы HTP запроса? Ну, обычно, ну, какие мы, а, вообще методы HTTP запросов, их существует огромное количество, но в основном этот операции, то есть create, read update delete.
Speaker A
Вот мы используем эти методы. То есть для того, чтобы получить ресурс, пост для того, чтобы, ну, скажем так, отправить, создать сущность, вот update.
Speaker A
Естественно, это это либо пут, либо патч. А это два метода очень похожие. Вот один, получается, меняет данные полностью, это, а пач меняет данные частично. Ну и метод delete для удаления ресурсов. А вот методы пост и патч, а они являются нендепотентными, то
Speaker A
есть при повторной передаче запроса они могут поменять состояние сервера. или меняют его. То есть импотентные методы - это всё-таки get, а вот именно, а, put и delete.
Speaker A
Хорошо, отлично. А вот ты сказал, что ещё есть какое-то множество методов. Какие ещё-то есть, например, хотя бы?
Speaker A
Ну, вот кроме этих основных, которые крут. А есть на самом деле ещё другие, там я слышал head options, но вот я о них только слышал и увидел недавно новыю, что появился новый метод, который называется query. То есть он что-то
Speaker A
между гетом и постом. То есть он получает, а он позволяет получить именно те данные, которые э нам нужны. То есть если мы отправляем get, он нам вернётся сразу. Это такая некое подобие э граф Qэ. Ну вот что-то в этом роде, мне
Speaker A
кажется. Ну, ну да, квеy запрос, да. Это раньше был просто криза запрос, собственно говоря, обычно. Ну как бы они он всегда был, да, просто сейчас это выделили как отдельный метод, да, это очень круто и правильно, что ты это помнишь. Это нужно
Speaker A
обязательно на собеседовании сказать, пофлексить этими знаниями новыми, потому что многие, я думаю, большинство даже не знают этого ещё.
Speaker A
Вот. Хорошо. Отлично. Так, хорошо. Давай дальше. А из чего состоит HTP запрос? Но HTTP запрос состоит. Ну, первое - это стартовая строка, то есть, а вот потом он далее идёт у нас хедеры, то есть заголовки, ну, и тело
Speaker A
запросов, возможно, если мы, например, какой-то ещё между телом, между телом запросом и headдер ещё пропуск строки blлай. Тоже это запомню. Это важно.
Speaker A
Ладно, хорошо. Это не везде пишут, но это важно. Да, когда к автом готовился, ну, пробойки BLй, да, там это как бы такой момент, вот я когда, ну, короче, готовился по автотестам, мне мой ментор все мозги этим выил. Ну, на собеседованиях это
Speaker A
более правильно так говорить. Ну, если ты откроешь, собственно говоря, статью, то там это будет написано. Вот.
Speaker A
Хорошо, давай дальше. Мм, отлично. Так, о'кей, о'кей, о'кей, о'кей. Какие бывают вообще вот виды м виды, так сказать, э виды виды сервисов, да? То есть ты работал с микросервисами, да? Вот есть ещё монолиты. Вот в чём они отличаются? Какие плюсы и минусы,
Speaker A
преимущества? В чём отличие? Ну о'кей. А-а, в принципе, есть два вида архитектуры. Мо, монолитная. Но есть, конечно, ещё бессерверная архитектура, но мы к ней, э, не будем, потому что она настолько редко используется, поэтому мы не будем о ней говорить. А,
Speaker A
а то есть два основных вида архитектуры, это монолитная и микросервисная архитектура. Маленько расскажу. Монолитная архитектура - это та, где весь проект, весь код, он находится, ну, на одном сервере. И, соответственно, этот код очень тесно связан между собой.
Speaker A
Вот его плюсы, то что, ну, в нём проще разобраться, проще, ну, кот, кто его делает, конечно, ему проще разобраться, локализовать ошибки. А минусы, условно говоря, если какая-то часть, а, например, у нас всё, то есть и сервис авторизации, и сервис грубо говоря,
Speaker A
какой-нибудь там сообщений, там бронирований, а вот всё находится в одном месте. Предположим, что, а, на каком-нибудь сервисе сильно вырастет нагрузка. И самый главный его, наверное, такой минус вот один из главных, он плохо масштабируем, точнее, ну, масштаб возможен только, а, то есть запустить
Speaker A
ещё второй сервис и, соответственно, и перекатить часть ну, скажем так, клиентского трафика туда. То есть, а, в отличие от микросервисной архитектуры.
Speaker A
где каждый сервис отвечает за какую-то определённую функциональность. Эти сервисы они скажем так, ээ, они масштабируемы, а в том плане, что если какому-то сервису не хватает ресурсов, то мы спокойно можем э докупить, э, трафик, ну, скажем так, либо купить ээ ресурсы нового сервера и пере,
Speaker A
э, скажем так, перевести весь поток туда. То есть главный плюс его - это, конечно же, масштабируемость, независимость. То есть если у нас один сервис отлетит, а то, в принципе, вся система продолжит работу. А если, не дай бог, в монолите у нас отлетит вся
Speaker A
система и нам нужно будет откатиться, то нам придётся откатывать абсолютно всё. То есть не только аа то, что не работает, но и то, что работает. Поэтому вот, да, такой вот минус. И вот, а, минус микросервисной архитектуры, наверное, в том, что, аа, наверное,
Speaker A
сложнее маленько разобраться, может быть, а, и сложнее локализовать. Вот где именно, например, была ошибка.
Speaker A
О'кей. Смотри, там ты можешь, в принципе, да, вот отвечать большими такими ответами, если тебя они будут прерывать, это наоборот хорошо. То есть, чем больше ты потратишь время с объеса на хороший ответ по тому вопросу, на который ты знаешь этот хороший ответ,
Speaker A
это как бы хорошо, да? То есть некоторые собеседователи могут тебя прямо стопать душно и говорить: "Так, всё понятно, идём дальше", чтобы уложиться в свою анкету. Вот. Ну, если даёт, говорить, рассуждать.
Speaker A
Ещё лучше тактика - это спрашивать. Вот если человек что-то рассказывает про себя, про свою команду, компани, ну, смотря кто он там есть, он может про себя начать рассказывать. свои дела, и тогда ты можешь его расспрашивать об этом, и это будет вообще зашибись,
Speaker A
потому что многие любят про себя рассказывать, и собеседование может вообще состоять полностью из твоих вопросов ему и всё. Ну вот это такой момент, да, пере перехватить инициативу, так называемую.
Speaker A
Ну да, то есть чтобы это не было только навязчиво, как бы так органически. Вот искренний такой интерес у тебя появился.
Speaker A
Вот. А, да. На самом деле, ну так ладно, быстро ремарку ставлю. Вот я хочу весь оттуда хлам убрать. Ну и гитару поставит на самое видное место, потому что некоторые тоже: "О, играешь на гитаре".
Speaker A
Вот у моего знакомого так было. И вот они там какое-то количество времени чисто про гитару говорили, про музыку, про то, про всё. А, ну такое может быть.
Speaker A
Но это как бы когда вот мэтч в принципе по характеру, по личности это, да, действительно может сложиться такое приятное общение. И это, конечно, выгодно. Вот. Ладно. Так, дальше. О'кей.
Speaker A
Так, о'кей. А расскажи, пожалуйста, вот микросервисы, когда взаимодействуют между собой, да, ээ они же используют брокера очередей, да? Вот ты работал с брокерами очередей, ты говорил вроде, да, что ты с кавкой работал. Вот скажи, зачем нужна кавка, в чём её вообще
Speaker A
преимущество, зачем её используют? Ну, скажем так, у нас есть вообще два вида взаимодействия. Это синхронное и асинхронное. А, то есть он работает по синхронному взаимодействию, то есть и он statless, то есть не хранит состояние.
Speaker A
Ага. Клиент отправляет запрос, получает ответ, соединение, как бы всё разрывается. И бывают такие моменты, когда, ну, условно говоря, нужно сообщить о каком-то событии, а, другому микросервису. Вот что это событие, например, произошло, чтобы у получается может какие-то скрипты сработали, да,
Speaker A
чтобы запустился какой-то другой функционал. Вот. То есть если мы используем ст, то есть клиент всё время будет что-то есть для меня, что-то есть для меня, ну, получается, ничего нет. То есть это будет тратиться ресурс. А брокер сообщений - это асинхронное
Speaker A
взаимодействие. То есть есть вообще два вида, то есть продюсер и консюмер. То есть продюсер - это тот, кто пишет сообщение, вот публикует его в брокер в определённый топик. Конюмер - это тот, кто подписан на этот топик, возможно, на определённую
Speaker A
партицы, вычитывает это сообщение и дальше данные, ну, как задумана бизнес-логикой, туда они идут. Вот.
Speaker A
Угу. Собственно говоря, вот, да. То есть это нужно для асинхронного взаимодействия. Угу. Аа о'кей.
Speaker A
А расскажи, пожалуйста, если если вдруг аа ну произойдёт сбой системы, да, те сообщения, которые были в очереди, они не сохранятся или не сохранятся в Кавке?
Speaker A
А, да. То есть в Кавке есть такая система, то есть вообще оно называется офсетом. То есть это такая некая очередь вот, которая сохраняет последнее прочитанное сообщение вот из партиции. То есть, если, условно говоря, сервис, который консюмер вычитывает сообщение, там он с
Speaker A
нуля дошёл до пдесяти, вот не успел прочитать сервис сообщение и сервис обвалился, как у меня ноутбукси экран.
Speaker A
Вот после того, как он остановится, Кавка хранит эти данные вот о том, на каком именно офсете он сохранился, и дальше начнёт а просчитывать сообщение он, ну, с последующего, грубо говоря, с пятьдесят первого.
Speaker A
Угу. О'кей, о'кей о'кей о'кей. Давай про логирование. Вот расскажи, какие системы логирования вы использовали, использовали ли Кибану, как именно?
Speaker A
Да, Киба мы использовали, данные хранились в Elastic Search, то есть как вообще это было? А если, условно говоря, мне нужно было проследить какой-то запрос, а чаще всего мы использовали Trace ID, то есть как это было, я заходил, а, в Chrome def
Speaker A
Tools, во вкладку Network, выбирал, а, запрос, который меня интересует в хедерах искал Trid, вот именно этот айдишник, который позволяет отследить весь путь этого запроса, ну, через все сервисы.
Speaker A
А, соответственно, после того, как я находил этот Race ID, я заходил в Кибану. У нас была такая Uная часть, вот переходил в Discoverover, выбирал поиск по ID, вводил свой айдишник и, ну, вводил этот айдишник этого запроса. И далее я видел, э, ну, всю информацию по
Speaker A
этому айдишнику, то есть через какие системы он проходил, а что прошло, а что не прошло. Вот.
Speaker A
Отлично, зашибись. Так, давай SQL. По SQL вот какие есть, собственно говоря, агрегирующие функции, расскажи, которые чаще всего использовал. Там виды джоинов вообще, чем отличаются редационные от нереационные базы? В общем, всё, что знаешь про SQL, прямо расскажи.
Speaker A
Насколько глубоко ты с ним работал? Да. Да, ну работал мы с Постгре SQL в качестве СУBD через Deber. Повторюсь ещё раз. А вот SQL я знаю примерно на уровне джоинов. Ну, про агрегирующие функции какие у нас есть? Это, ну, естественно,
Speaker A
минимум, максимум сумм, ну, и каунт для подсчёта строк. Вот. А потом что ещё? Джоийны, какие они бывают? А, есть просто join либо inner join, то есть это одно и то же. А нужно пояснить, типа, чем они между собой отличаются и как.
Speaker A
Ну да. Чем называется? Left join, right join, outer join. Да. А, о'кей. Как я, как я это понимаю? А, то есть, а inner join, он берёт, а, скажем так, блин, сложно объяснить.
Speaker A
Нет, ладно, это полная. А, в общем, он берёт только те данные, которые находятся между двумя, скажем так, таблицами. Ну, скажем так. на их перепуте. А вот если мы говорим про left, он берёт данные из левой страницы и совпадающий,
Speaker A
э, получается этот, он берёт с правой стороны совпадающие строки. А вот, ну, right joy, соответственно, с правой таблицы, часть с левой. Вот. И остальное есть ещё join, кажется. Ну вот с ним я не работал. Вот. Да, знаю я такую тему,
Speaker A
что вот есть у меня такой бросак, нужно его повторить. Вот. Угу. А что такое инъекции в сквеле?
Speaker A
Бляха-муха. Вот знал. Вот. Ну не могу ответить. Ну вот запиши. Да. Это всегда спрашивают.
Speaker A
Хорошо. инъекции и по джойнам. Хорошо. По агрегирующим функциям я ответил. Ну да, да. Ну тему SQL в целом повтори.
Speaker A
Её могут, особенно если в вакансии написано про SQL, её могут глу глубже гораздо копать. Задачи могут давать. Я тебе говорил же, да, про задачи.
Speaker A
Ну да, я знаю. То есть, блин, ты просто, ну, ты представляешь, да, то, что вот решаешь задачи, вот изQL Academy я решал, у меня есть аккаунт, вот у меня у жены, вот мы решали там задачки даже какие-то аа более сложные, ну, выше, скажем так,
Speaker A
среднего задач я решал. У меня есть товарищ разработчик, мы в дискорде подключались, вот, и вдво и и он мне прямо, ну, подсказывал, где вот алия ставить, например. Вот. Всё. То есть я это знаю, бляха-муха, надо повторить.
Speaker A
Ну, считай этот сколько, ну, может, месяца полтора назад или сколько я проходил этот SQL. Естественно, когда ты с этим не работаешь, оно очень быстро забывается.
Speaker A
Ну, это одна из самых таких вот сложных вещей, поэтому, да, это лучше повторить, особенно если в вакансии про это написано. Где-то могут скорее вообще не спрашивать, а где-то могут очень глубоко спрашивать.
Speaker A
Да, о'кей, я понимаю это и, естественно, я повторю, ну, перед реальным собесом, потому что я знаю, сколько я сабесов не видел, ну, от реальных своих знакомых каких-то вот всегда про SQL спрашивают.
Speaker A
Ну, очень часто, практически всегда. О'кей. Давай дальше. Смотри, вот CCD зачем нужно расскажи пожалуйста.
Speaker A
Но CCD - это процесс непрерывной интеграции и непрерывно либо доставки, либо развёртывание. Сейчас объясню. То есть непрерывная интеграция - это что такое? А это этап, когда, ну, условно говоря, разработчик что-то поменял в гите в репозитории, и запустился процесс
Speaker A
непрерывной интеграции. То есть, что получается? А проверяется код, ну, автоматически проверяется код на его работоспособность, то есть линтеры, то есть, а это на наличие синтактических ошибок вообще, что код рабочий. А далее у CI, ну, может быть несколько стейджей,
Speaker A
то есть этапов. В каждом этапе есть определённые джобы, то есть это то, что выполняется на определённом стейдже, то есть этапе. Вот. То есть, соответственно, код собирается, прогоняются какие-то тесты. Вот когда этот процесс закончен, есть у нас два других процесса. Это либо непрерывная
Speaker A
доставка, либо непрерывный деплоймент. А вот чем они друг от друга отличаются. Если у нас настроен процесс CCD в качестве C и потом CD, то есть deployment, то есть это получается так.
Speaker A
Разработчик закончил код, а, нажал там merch request, его одобрили, и этот код изменённый, он полетел сразу на прот.
Speaker A
Вот. Ну, обычно мы так не делаем и всегда, поэтому у нас CD - это м continuous delivery, то есть непрерывная доставка. После того, как прошёл процесс C, э, и остановился на процессе CD. И дальше мы уже ручками запускаем.
Speaker A
То есть, если мы запускаем ручками, то дальше этот пайплайн CD, он переходит уже в другой инструмент, который называется Open Shift. То есть это, скажем так, Kubernetis, только такая коммерческая версия.
Speaker A
Вот. Не из коробки, так скажем. Вот. И дальше это приложение разворачивается вот именно уже через Бернетис.
Speaker A
Отлично. Так. О'кей. О'кей, о'кей. Так, по по мобилкам ты готовился? Ой, как сказать. О, блин, я вот что-то помню. Ну, типа так.
Speaker A
Ну, вот это важно, естественно, если мобильная позиция, то это просто, ну, нереально важно. Это самое важное. Очень важно повторить модули с мобилками.
Speaker A
Вот тут, видишь, в легге в нашем Моке получилось так, что я сезону на мобильную позицию, поэтому тебя по-любому ещё буду спрашивать. Короче, давай расскажи мне вообще, какие есть виды мобильных приложений.
Speaker A
Ну, в виде мобильных приложений есть их, э, несколько видов. Ну, вообще их три. То есть это, а-а, нативные, то есть это для того устройства под операционную систему, на которой он сделан. То есть это либо Android, либо iOS. А вот есть веб-приложение, то есть
Speaker A
это, грубо говоря, браузер просто в телефоне. Вот, то есть рендерит страницу, отображает вот для, ну, для мобильных устройств. Вот есть также кроссплатформенные приложения. В кроссплатформенные приложения у нас входят гибридные приложения, ээ есть и другие кроссплатформенные приложения.
Speaker A
Это они написаны либо на Флаттере, либо на React Nativeве. Ну, они отличают два фреймворка, которые отличаются между собой. Одни используют ресурсы операционной системы. Вот именно я имею в виду, что Android либо iOS - это, по-моему м вот именно, что он Native. Вот. А
Speaker A
Platter он использует вроде как свои какие-то ресурсы. Вот это вот момент я очень хорошо знал. Надо его повторить.
Speaker A
Вот. Ага. О'кей. Расскажи, вот самый важный вопрос. Отличие тестирования веб и мобильных приложений. Там прямо их много. И вот этот вопрос очень важно выучить. Прямо там, ну, как-то можно рассказывать и рассказывать.
Speaker A
Ну, особенности тестирования мобильных приложений, они включают в себе, ну, всевозможные проверки, которые, ну, скажем так, ээ отличны от веба. такие, например, как м как устройство, ну, я имею в виду, насколько, то есть это сети, насколько оно держит заряд, а может у неё там 1
Speaker A
процент она жёстко будет тупить. Вот самое главное отличие - это в пермишенах. То есть пермишены - это разрешение, то есть это доступ к камере, доступ к микрофону, доступ к геопозиции.
Speaker A
Вот это, наверное, основная особенность отличия от тестирования мобильных приложений. что нужно проверить, что при а-а во-первых, может быть, что ээ при первом запуске это был онбординг. Вот, а что, например, всё рассказано, если оно, например, есть, э опять же особенности
Speaker A
инсталляционного тестирования, то есть веб-приложение мы его не обновляем, оно обновляется в браузере автоматически, то есть пользователь даже об этом не знает.
Speaker A
Вот соответственно мобильное приложение оно обновляется вручную, ну, либо по авто, как мы вот мы поставим либо на Андроиде, либо на Айосе. Вот, соответственно, удаляется, ну вот, и устанавливается через магазины приложений. Вот если мы про нативное именно говорим.
Speaker A
Угу. Ну, о'кей, да. Инсталляция, деинсталляция, разное состояние приложений, там свёрднутое, задийбленное включенное звонки кнопки аналоговые прерывание тротлинг плохой интернет. Вот, вот всё это нужно выучить на иззусть. Это очень важно для мобильного средства слабона.
Speaker A
Да не, я понял. Ну опять же, я просто выбрал для себя такую стратегию, что у меня же написано, что я работал с мобилками, я реально с ними работал только, ну, не настолько, скажем так, красочно, как я описал в резюме.
Speaker A
Ну, я могу сказать, что в действительности у меня есть опыт мобильного приложения, но на предыдущем проекте. Вот что хотите, вот что вспомню расскажу пожалуйста.
Speaker A
Угу, угу, угу. Опыт есть, типа, вспомнить не проблема. О'кей. Так, ладно. Смотри, в целом, по всему прошлись. Я не прямо всевсе вопросы задавал, но у тебя вот технически вроде всё зашибись по техническим, по большинству технических тем. Единственный вот есть момент,
Speaker A
смотри, во-первых, у тебя вот в комнате потемнело и тебя вообще не видно стало. На собеседовании такого не допускай. Ты вот поработай над картинкой, то есть заранее подумай о свете, о фоне. Ну, мы это уже обсуждали, да? Ну, короче, ты
Speaker A
вот вот вот сейчас зашибись стало, да. Всё-таки я бы ещё выше сделал, чтобы ты был всё-таки ровно по центру. Окена созвонов, потому что сейчас ты выглядишь, ну вот сверху вниз. Я не знаю, как это объяснить. Сверху вниз.
Speaker A
Вот. Ну блин, я не знаю. Я могу там как-нибудь сидушку при, ты как бы когда начинаешь рассуждать, ты уезжаешь ещё ниже, и получается, что ты вообще не по центру. Это как бы момент.
Speaker A
И ещё ты почти не смотришь в камеру. И это прямо особенно на моментах, короче, иногда кажется, что ты смотришь там в монитор, вот вот вот то, о чём я и говорил. Я раньше на это внимание не обращал, но это пипец как прям влияет.
Speaker A
Угу. Чем больше ты будешь смотреть в прямо вот в точечку вебки при любом своём ответе, рассуждении, тем это будет вот лучше. Это прямо вот реально на восприятие влияет. Потому что когда у тебя бегают глаза, ты смотришь там какой-то по сторонам на монитор, ну вот
Speaker A
чисто вот то ли он шпаргалки смотрит, то ли просто ему как-то неинтересно, то ли ещё что-то, да, то ли какой-то он интроверт, что-то ещё. А вот когда смотришь камеру, да, ну, ты в принципе нормально рассказываешь, то есть ты там
Speaker A
улыбаешься и шутишь. То есть в целом всё нормально, но вот чаще смотреть в камеру надо, это реально работает. Вот.
Speaker A
А так по всем параметрам, по остальным. Ну, молодец, нормально. Единственное, да, попрошу вот самопрезентацию ещё отрепетировать прямо вот, ну, прямо вот отрепетировать, чтобы она была идеально. И запиши мне вот ГС на 3 минуты, когда точно её подготовишь. Вот, вот это вот сделай, а
Speaker A
так всё остальное норм. Так что я думаю ты можешь этим, это меха уже начинает отвлекаться.
Speaker A
Ну вот если ты видел у нас сейчас ТГК, там же есть у меня запись ээ тред по ку выкладывают созвоны, да? Угу. Александр Фирсов ходит, и на него свалилась какая-то мана небесная. У него, не знаю, каждый день собеседование, и он все
Speaker A
проваливает. То есть вот как как на зло. Поэтому то ли сейчас хорошо, то ли звать, то ли что, но ты должен сходить на собеседование и устроиться. Я в тебя верю. У тебя вот уровень прямо хороший.
Speaker A
Ты убедительно звучишь. Вот он как-то нервничает, что ли, не знаю. Вот сейчас буду как раз смотреть его сабеса, анализировать, в чём у него там проблема. Ну вот я я слушаю его Собеса, но вот последний, вот честно, очень такой душный был. А ну
Speaker A
у него тип говорит: "Ты будешь единственным тестировщиком. Там всего тек собезлится на 20 минут". Я заметил, очень часто спрашивают про токены. Вот прям токены - это прямо масх. Вот я сегодня тоже думал, может ты мне задашь этот вопрос, поэтому я чуть-чуть вот
Speaker A
подготовился. Вот именно они любят про джо токен. GVT токены, GVT токены, аукены, метод авторизации. Да, это хорошие вопросы. Да, да, да, да, да. То есть они вот любят про это очень спрашивают. Он у него спросил, из чего он состоит, как, ну,
Speaker A
типа вообще происходят все вот эти вот операции. Вот. Ну, кстати, он, мне кажется, нормально, он довольно-таки уверенно рассказывает. Ну вот есть, да, какие-то пробелы. Ну и опять же от интервьера зависит, что может быть душнит. А по поводу того, что
Speaker A
я не нервничаю, это я с тобой, наверное, не нервничаю. Мне кажется, на реальном собесе я буду нервничать сильно. Ну мне как бы, знаешь, мне нужно понять, если меня слушают, если я вижу там заинтересованные, довольные лица, ну, то есть дружелюбны,
Speaker A
то, в принципе, я легко вступаю в контакт. Вот. Ну и очень часто я заметил, что любят задавать какие-то абстрактные вопросы. А представь, что если бы там, вам бы осталось жить 2 дня, ну только чем ты мог бы заниматься, так это
Speaker A
работать. Вот, чем бы ты занялся конкретно? Выбери приоритет, расставь его там и так далее.
Speaker A
Ну вот да, ну ты не нервнича Нет, ты как бы понимаешь, если ты сейчас уверенность, короче, есть вот разные люди, да, есть, которые нервничают даже на мок собесие.
Speaker A
Это плохо. Вот это вытровить человека сложно. Ты в целом уверенно как бы ну как бы уверенно держишься. На собеседовании надо ещё более уверенно даже, чем сейчас. И как бы, как сказать, просто не будь в образе, я всегда всегда
Speaker A
всем говорю, в образе какого-то студента на допросе, на экзамене, да, а вот как бы на равных с каким-то контрагентом, да, у которого есть какие-то бизнес-цели, и ему нужен функциональный специалист, а ты вот специалист, который, э, собственно говоря, выполняет, может выполнить определённую
Speaker A
работу, и вы с ним как бы договариваетесь об условиях, да, то есть это не как экзамен, как вот, не знаю, к сантехнику, когда вот обращаешься, да, там звонишь там, а он тебе говорит, там 100.000 тысяч трубы переложить. Ты
Speaker A
говориш: "Ты что, совсем охерел, что ли?" А звонишь другому, там, типа, он тебе говорит: "50.000. И вот этот вот разговор на равных. И даже более мне ещё кто-то сказал в рандом кофе мне это сказали, даже даже не на равных. Даже
Speaker A
тот, кто делает услугу, он выше, потому что тому человеку, которому нужна услуга-то, она ему нужна, собственно говоря. Ну вот. А ты, собственно говоря, воен тебе как бы, ну, как бы похер, ты в другое место можешь пойти, а он
Speaker A
нуждается в тебе. Вот, вот такой момент. Поэтому спокойно, уверенно, да, смотря в вебку, ну, то есть в глаза, то есть ты, когда смотришь в вебку, ты смотришь как бы в глаза.
Speaker A
Вот. Проходи, да? И и обязательно поставь OBS, реши технические проблемы, чтобы с ноутом всё было зашибись, с компом. А, всё записывай и скрининги, и сабьесы, и выкладывай в ТГК, чтобы я мог проверить, потому что Арсений, тьфу, Арсений вот этот Александр, он проебал
Speaker A
собеседований пять. Я просто, я в шоке. Я ему говорю: "Ну ты что, совсем, что ли?" то у меня, то у меня что-то похерилось, то не записалось, то я звук не включил, то мне с мобильного телефона звонили. Я говорю: "Ну, ты понимаешь, что все эти
Speaker A
собеседование, они как бы в молоко. Мы их не проанализировали, ты по ним не улучшился, ты их не записал, ты их сам не переслушал, ты не выписал свои проблемные ответы, ты те же самые ответы будешь давать на следующем собеседовании, хуёвое, да, по каким-то
Speaker A
вопросам. Нужно всё записывать, пересматривать, выписывать и улучшаться. Вот это такая главная стратегия. Ну вот для самого тебя даже это важно пересмотреть своё собственное собеседование. Хотя бывает кринжово как-то всё это стыдно, но вот через силу надо своё собеседование смотреть. Это
Speaker A
очень важно. Вот. Да. На самом деле наоборот мне кажется, что это хорошая работа над ошибками. Я вот у тебя поинтересоваться хотел, как ты в принципе, ну, ты сказал то, что, ну, указал, да, вот мне на мои, э, скажем
Speaker A
так, ошибки. Вот по поводу самопрезентации, да, есть такой некий у меня кзик. то, что вот, ну, вот это вот всё перечисление, оно, блин, и будет всё выглядеть как заученный текст. А вот, а по поводу остального, о'кей, я понял,
Speaker A
что мне нужно подтянуть мобилки SQL, а в целом так по остальной, я имею в виду, по технически всё нормально, да?
Speaker A
Ну да, да, даже, ну да, весьма даже хорошо, я бы сказал. Вот. Хорошо, спасибо.
Speaker A
Вот. Ну о'кей. О'кей. Слушай, Кирилл, я думаю, что, наверное, нужно провести ещё один мокбис. Ну такой, может быть, финальный. Вот я как раз-таки заполню свои пробелы в плане СQэля. Может будут какие-то, например, ещё у тебя блок вопросов. Может быть, мы ещё какие-то
Speaker A
пробелы мы выясним. И, собственно говоря, дальше только выход на рынок. Ну и смотрим резюме, конверсию. Я могу с тобой провести предметно по тем темам, по которым ты уже, по которым у тебя были трудности. Самопрезентацию можем погонять, можем по СQлю что-то
Speaker A
поспрашивать. Новые вопросы по теории тестирования я особо не придумаю. Не придумаю. Ты это знаешь. Ну как бы я считаю, что тут уже апруф, так сказать.
Speaker A
Можешь уже по этой теме не париться, но не забудь главное то, что ты уже знаешь. Вот.
Speaker A
Угу. Я предлагаю, да, самопрезентации поработать, записать её и скинуть. Мне этого будет достаточно, на самом деле.
Speaker A
Ну, хочешь выйти на чем больше ты начнёшь отвлекаться, на самом деле, тем лучше, потому что уже пойдёт процессинг, да, и можем, например, начать отвлекаться, параллельно ещё раз провести, если хочешь. Ну, как бы не полностью будет тоже те же самые вопросы
Speaker A
какие-то там, не знаю, по тем проблемным темам, которые у тебя были там, может, ещё вопросы погуглю. Короче, я хочу, чтобы ты уже начинал отвлекаться резюме.
Speaker A
Вот моё такое мнение. Угу. Угу. Ну, о'кей. О'кей, ладно. Ну вот просто давай как-то там, я не знаю, во вторник, может мы с тобой ещё А во вторник у нас общий созвон. Контрольно бы нам созвониться ещё вот по
Speaker A
самопрезентации. Ну можешь я тебе голосовуху запишу там. Или ещё ещё ещё знаешь что, когда тебя позовут на собеседование, да? Например, вот ну конкретная компания с конкретной вакансией.
Speaker A
Я так вот со мной так ментор по прожекту делал, это помогло очень сильно. Можем провести вот тот самый контрольный зазвон.
Speaker A
предметная подготовка к конкретной вакансии, да? То есть вакансии же описаны требования и вот прямо по ним пройтись по всем вместе. Вот это полезно, да? Особенно если хорошая, если какая-то хорошая компания зовёт, не какая-то ноунейм то вот к ней
Speaker A
можно прямо предметно подготовиться. Вот. Ой, на самом деле я бы, блин, ходил бы по всем, потому что один из советов моего товарища, который, ну, тут также волчком залетел, он сказал о том, что надо идти абсолютно на все собесы, куда
Speaker A
тебя приглашают. Хоть там, за булку хлеба, чтобы ещё как-то вот именно для этого вот опыта.
Speaker A
Да. Да. Нет, само собой, ходим-то мы на все, да, это понятное дело. Да, да. Вот такие вот.
Topics:собеседованиетестированиеСбермикросервисыScrumтест-дизайнCI/CDлогированиетестировщикпрезентация
