0: Привет, меня зовут Чурсов Геннадий. Я калит в компании тест тест тест софт. И сегодня я буду проводить техническое собеседование на позицию Синер автомейшн квалити шурс инженер, привет, меня зовут
1: Левадная Алина, я сдет инженер в стартапе и сегодня, соответственно, буду собеседоваться на позицию автомейшн кей на java перед тем, как начнём, мне просто интересно, из какого ты города я живу в московской области.
2: Работаю в Москве. И как у вас там погода? Сегодня ещё ничего. А вчера было не очень у вас, я слышал, у вас там снег уже было такое в Нижнем Новгороде, да, у нас пока только иней по утрам бывает. Вчера был.
3: 1 холодный день я сейчас в Белграде, в Сербии у нас отопление наконец то включили, но до снега нам ещё не скоро, у нас не будет никакого 2 там интервьювера и прочих людей, мы в принципе, можем начинать.
4: Давай тогда чуть чуть расскажу, как в принципе происходит собеседование. Оно у нас обычно делится на несколько частей. То есть 1 часть, где ты можешь рассказать про свой предыдущий опыт, про свои достижения, фартовые, там
5: Софт скиловые какие-то вещи, которыми ты гордишься, и, может быть какие-то твои карьерные ожидания. Чего ты хочешь от новой компании? В кого ты хочешь, например, дальше развиваться? Я, может быть, поспрашиваю что-то про твой опыт. Дальше будет.
6: Техническая часть, где мне хочется понять по тем техническим стекам, которые у нас есть на проектах, насколько ты подходишь, насколько тебе тоже будет интересно с этим работать. Возможно, будет какая-то практическая задачка. Ну и послед,
7: Часть у тебя будет возможность задать мне какие-то вопросы, но также стоит понимать, что у нас сейчас техническое собеседование в аутсорсинг компанию, где после технического такого общего собеседования возможно.
8: Будет собеседование на конкретный проект. Вот. И там, возможно, будет техническая часть, возможно будет какой-то калчер фит или ещё какие-то вещи. Я заранее не могу знать, на какие позиции ты потом будешь собеседоваться, поэтому это будет
9: Наверное, известно уже после технической части. Вот есть ли у тебя какие-то вопросы перед началом? Пока нет. Думаю, в процессе появится. Угу. Ну хорошо, давай тогда начнём с 1 части. Можешь рассказать о себе, да?
10: Спасибо, я работаю сейчас, как сдет инженер в стартапе, мы разрабатываем нечто вроде искусственного интеллекта для к. Инженера в рамках 1 большого предприятия, и наша задача построить, соответственно, такие
11: Модели искусственного интеллекта. Моя задача проверить их и провалидировать, что они работают корректно. Команда состоит из 6 человек, и это мой новый опыт. До этого был опыт интерпрайзный на разных позициях.
12: В разных ролях, соответственно, больше было менел кей, но последние годы было и автомейшн направление, и 1 из последних моих ролей и позиций это был фулстек инженер.
13: В компании тинькофф мы разрабатывали тесты в команде на java я была как ручным, так и автоматизированным тестировщиком в команде нас было 6 человек кией, и вся команда состояла из 30 человек.
14: Аналитики, дизайнеры, проджект менеджер и так далее. В мои задачи, соответственно, входило тестировать сервисы нашего продукта. Это был биллинг мобильного оператора. Мы
15: Сразу писали автотесты, как только получали фичу, сразу разрабатывали автотест, и у меня были частично задачи, как у сдета. Когда я приходила на проект, мне предложили решить такую задачку.
16: Было очень много падающих автотестов, но всего 6000 было на проекте, но с учётом параметризации было больше 10000, и нужно было что-то с этим сделать. Использовался на проекте 1 общий стенд кей.
17: Потому что развёртывалось очень много баз, и они ещё не перешли на docker, и я как раз разделяла тесты на по функциональности, делила их на разные ветки гитла.
18: И валюр где-то убирала параметризацию или там сокращала выборку параметризации и примерно за пару месяцев удалось разрешить проблему, если изначально падала.
19: Стандартно, после ночного прогона около 2000 Тестов, то через пару месяцев удалось прийти к средним 150 200 тестам, и это, как правило, уже были не падения, связанные с инфраструктурой, а падения, связанные
20: Больше с проблемами в тестах. Сейчас я бы все-таки рекомендовала идти в сторону докера, потому что, на мой взгляд, это было временное решение, но на тот момент задача была решена с точки зрения
21: Каких-то soft, скиловых и других задач, которые не связаны непосредственно с тестированием, мне приходилось вести релизы как раз на последнем месте, ну и до этого в разных компаниях иногда мне доводилось быть
22: Помощником леда, ну как бы замещать леда в момент его отпусков и больничных и собеседовать сотрудников, менели, инженеров и проводить анбординг обучения какие-то. И, соответственно, кажется, было ещё
23: Ещё 1 вопрос. Чем я горжусь? Да, я горжусь тем, что я не могу сказать, что на проде, по моей вине много багов, в какой в какой-либо компании произошло. Я считаю, какие.
24: Меры это, ну, хорошее достижение. И в целом хочется стремиться ещё лучше быть в этом отношении. Угу. Да, спасибо за историю. У меня будут ещё дополнительные
25: Вопросы. Вот, видя по твоему резюме, видно, что у тебя опыт он разносторонний, то есть ты аналитиком и ручным тестировщиком, автоматизатором стет, инженером. У тебя, ну, есть переход из как будто бы
26: Специализации в специализацию. Вот есть ли у тебя какой-то план на будущее там либо закрепиться в какой-то 1 специализации, либо может быть ты ещё что-то помимо сдетства какая-то может быть глобальная цель есть там
27: Да, в менеджера, в разработчика ещё кого. То. Есть ли у тебя сейчас какие-то такие планы, так как я уже многое попробовала, как ты заметила, я могу уже говорить обоснованно, что направление автоматизации, тестирования
28: Ну, сдт, автоматизация тестирования для меня приоритетные. Может быть, посмотреть в сторону кейли, да, а с точки зрения переходов ещё каких-то уже, наверное, нет. Пожалуй, это самое подходящее для меня направ.
29: Иногда на проектах требуется создавать фреймворки с нуля. То есть иногда ты приходишь уже готовый фреймворк, ничего не нужно делать, ты занимаешься только автоматизацией новых кейсов регрессий, но иногда нужно помогать именно с написанием или обновлением фрейм.
30: Вот есть ли у тебя какой-то опыт, именно в этом не относящийся к тому, что ты уже говорила. Мне не доводилось создавать фреймворк с нуля. Разве что на своих пет проектах, но был опыт доработки фреймворков. 1 из таких опытов это
31: Доработка, ну, перенос похожего фреймворка для нового микросервиса, это на предыдущем месте работы в тинькоффе доводилось писать различные обвязки для новых инструментов, для новых, с точки зрения к инженеров, обвязки ска,
32: Обвязки с новыми базами, с системой логгирования. Сейдж в тинькоффе используется вот такими вещами я занималась. Угу. А вот из технических задач, какая задача для тебя была самая сложная, можешь
33: Какой-то вот пример из опыта с точки зрения именно технических, да, подходов, задачи каких-то совершенно новых подходов, например, задачка
34: Связанное с фронтом. Но я в основном тестировала бэк и писала автотесты для бэка. Также у меня были энтен тесты, но в задачах, связанных с фронтом, я встречала для себя ошибки и моменты, которые
35: Не удавалось так просто разрешить например, у нас на прошлом месте работы фронт был написан на вью джиэс, и там встречались определённые формочки, которые выскакивали в какой-то момент.
36: Это асинхронное взаимодействие, и тестом очень сложно было отловить такую вещь даже с учётом построения каких-то ожиданий, условных, безусловных все равно либо проскакивали мы этот момент.
37: Либо не доходили до этой формочки, а проверять нужно было, потому что вот в этой формочке какой-то подсчёт происходил, какое-то значение выводилось, и это важно было с точки зрения бизнеса и, конечно же, переделывать продукт под нужды.
38: Тестирование никто не собирался полностью переделывать, но что то что-то надо было придумывать и с точки зрения автотестов, автоматизации, наверное так у меня не получилось ничего придумать, но в работе вместе с разработчиком получилось.
39: Эту проблему решить. Он настраивал именно асинхронность с точки зрения фронта, и тогда мне удалось попасть в эти штучки, но для меня это, говорю, была самая сложная проблема, потому что я не нашла.
40: Нигде в интернете, как с этим бороться не нашла, пообщалась, с коллегами походила. Никто тоже ничего не предложил. И поэтому вот для меня это была сложная задача, хотя звучит, наверное, как не что-то такое сверхсложное. Ладно?
41: Ну, у меня, наверное, по опыту сейчас все, если что, мы в технических вещах ещё будем, наверное, отсылаться на твой предыдущий опыт. Давай теперь ближе вот к каким-то техническим вещам, которыми ты занималась. Вот ты рассказывала про пкн, то что у вас
42: Сервисная архитектура была. Угу. Можешь вкратце рассказать, например, про микросервисный подход, и как его тестировать? Есть ли там какие-то отличия от, например, монолитной архитектуры именно в рамках тестирования. Угу.
43: Соответственно, последний проект как раз и развивался, как и большинство исторически развиваемых проектов изначально он был монолитом, а после этого его стали разделять на микросервисы микросервисы это определённые уча.
44: Блоки функционала, которые не связаны с основным, ну они используют какое-то взаимодействие между, допустим, микросервисами или между основным блоком функционала, но логически отвязаны.
45: Могут релизиться самостоятельно, могут тестироваться тоже самостоятельно. И в этом их отличие. И опять же, с точки зрения тестирования мы можем протестировать микросервис, не регрессить все.
46: Остальное и в общем то вывести микросервис в prod за рамками релизных циклов, допустим, основного продукта, и у этого подхода есть плюсы минусы, есть свои удобства, связанные с тем, что.
47: Для бизнеса мы можем более быстро доносить наши доработки, а с точки зрения инфраструктуры и тестирования. Ну, есть свои нюансы. Не всегда это действительно так замечательно. А можно пример, вот что именно у вас на проекте можно
48: Было, например, улучшить при микросервисном тестировании или чего вам не хватало, я сталкивалась с тем, что каждый микросервис имеет собственный пайплайн, собственный сиайсиди, и это усложнение инфраструктуры.
49: Каждая новая инфраструктура, она может вносить свои ошибки, какие-то замечания, их нужно устранять, нужно все равно релизить это отдельно, соответственно, кто-то этим должен заниматься и с точки зрения тестирования приходится
50: Тестировать очень много взаимодействий. Как правило, у микросервисов друг с другом, и это накладывает определённую сложность. И я ещё сталкивалась с такой проблемой, что в рамках микросервиса, к примеру, может поменяться. Ну, так, Зада,
51: Задача стоит, что приходится менять что-то в апиай взаимодействии. И тогда нужно во всех тех сервисах, которые используют схожие апиай, соответственно, тоже внести изменения или
52: Их все вместе. Это тоже должен кто-то отслеживать. Не всегда. Все на проекте тоже понимают, какие есть взаимосвязи. И с этим мы сталкивались и получали проблемы такие. Угу. А вот
53: Ты рассказываешь то, что, ну, получается взаимосвязь микросервисов друг с другом, как вы это тестировали? Это же больше похоже на интеграционное тестирование. Есть ли какие-то особенности у вас в тестировании вот этой взаимосвязи, да?
54: Это действительно классическое интеграционное тестирование. Соответственно, смотря как микросервисы общаются между собой по росту или как-то ещё, может быть, очереди какие-то используются, все это надо протестировать, тестировать вот это вот взаимодействие.
55: А использовали вы контрактное тестирование, вот для интеграционного тестирования проверка именно самого контракта, как апиай, да, то есть интерфейса, грубо говоря, да, взаимодействия у нас таких проверок на проекте не было чуть чуть.
56: Больше про асинхронное взаимодействие. Вот ты упоминала, что у вас синхронное, асинхронное было. Если асинхронное, то как вы это тестировали? Какие инструменты использовали? Мы использовали кафку для синхронного взаимодействия и кафка
57: Получает сообщения, ну это очередь, она получает сообщения, передаёт их от получате, от поставщика к получателю. Соответственно, в нашей системе логирования в je можно было прямо увидеть, как сообщение попало очередь.
58: Как оно ушло из очереди посмотреть статусы этого сообщения и были автотесты даже на это, на то, что сообщение попало в очередь на то, что сообщение валидно, и то, что оно
59: Полученном статусе ушло из очереди, к примеру. Соответственно, вручную это несколько сложнее отследить, потому что асинхронное взаимодействие все равно происходит очень быстро, но если есть какой-то ui, или именно к очереди, или хотя бы консолька, можно
60: Хотя бы посмотреть, что в очереди это сообщение действительно было. Ну, соответственно, тестируешь именно это взаимодействие, тестируешь формат сообщения, что он тот, который ожидается, иногда посылаешь какие-то кривые сообщения, чтобы посмотреть, что
61: Они не проходят, но в то же время система у нас полностью не ложится. Вот, собственно, чем мы занимались при тестировании очередей. Угу. А был ли у тебя опыт работы не только с кафкой на, например, там, с rabbitmq или ещё какими-то другими очередям?
62: Нет, с rabbitmq я не работала только с кафкой, а теоретические знания какие-то, например, тебя могут спросить заказчики на следующем собеседовании. Вот как бы ты отвечала на вопрос про бикью, я бы, наверное, все-таки ещё.
63: Немножко ознакомилась с этой темой поближе, но так как у меня практического опыта нет, я просто знаю, что есть разные подходы у rabbitmq и в кафке кафка сохраняет сообщения в очереди, rabbitmq их не сохраняет.
64: Есть различия на стороне консьюмера, получателя сообщений кто из них активный, кто пассивный, и на данный момент в моей голове это основные отличия, а детали я бы, наверное,
65: Почитала более подробно тут вопрос не был отвечен полностью, например, rabbit mq все-таки сохраняет сообщения, но удаляет их после отправки их потребителям, но так как это был стрессовый вопрос, чтобы в целом проверить.
66: Как кандидат будет вести себя здесь больше? Ожидается, что кандидат, во первых, не будет врать про свой практический опыт, во вторых, он все-таки постарается рассказать что-то из теории, ну и в конце будет готов изучить новое для того, чтобы выполнять.
67: Проектные задачи. Хорошо, давай тогда вернёмся тогда к синхронным взаимодействиям. То есть, получается, у вас, наверное, и рест апиай был, как тестировала ты, рест апиай, например, вот тебе верну.
68: Ответ от какого-то эндпоинта, например, мы тестируем какую-нибудь библиотеку, и нам возвращается список книг, и ты используешь гет метод, вот что из запроса ты тестировал.
69: Ну, то есть из ответа на запрос к этому. Итак, у нас есть список книг, сервис по возврату, список книг, у нас есть реализованный метод get, да, и этот список книг это, скорее всего,
70: Какая-то сложная структура тебе возвращается структурированный джейсон. Каждая книга это потенциально будущий объект с именем, названием, автором годом выпуска и другими вещами. Тебе надо протестировать.
71: Ну, допустим, смоук, смоук. Хорошо. Если мы говорим о смоуке, то я просто изначально посмотрела бы, дёрнула метод get, посмотрела, приходят ли те параметры, которые я ожидаю. Согла.
72: Спецификации и что они имеют нужный формат, что они ограничены значениями, которые опять же у нас указаны в спецификации, если говорить о каких-то негативных проверках использования.
73: Классов, эквивалентности граничных значений. Это, наверное, уже за рамками смоука, но, конечно, я бы ещё проверила статус. Код ответа для resta, хорошие статус коды это двухсотые и
74: Можно было бы попробовать получить какую-нибудь ошибку, 400 или 500, чтобы убедиться, что мы действительно получаем ту ошибку, которую мы ожидаем, а кроме двухсотых, четырехсотых и пятисотых есть ещё какие-то типы, статус кодов.
75: Нет, с единицы или стройки, если начинаются, да, y resta. Ну, во первых, много. Статус кодов есть, ещё, как ты сказал, который начинается на сотни и на 3 сотни сотки. Это информационный статус.
76: От а трехсотки это перенаправление. У меня такой ещё вопрос. В http есть, кроме гэта, ещё другие методы, например, есть post put и patch, и как будто бы их прям слишком
77: Много. Вот можешь мне объяснить, допустим, я не знаю, зачем нужно аж 3 метода, в чем между ними различия. Мы можем с помощью поста создать какой-то ресурс с помощью пута или патча обновить.
78: Ресурс это нам добавляет удобства пользования нашим сервисом, а отличия какие-то есть вот если, например, и путом, и патчем изменяем ресурс, то зачем нам надо 2 способа для изменения? Есть ли какие-то
79: Разницы в тестировании этих методов отличия есть put полностью перезатирает ресурс, перезаносит данные, а патч частично обновляет данные.
80: Поэтому, соответственно, если говорить об отличиях в тестировании, мы тоже должны проверять как раз, что при патче у нас проходит, происходит частичное обновление при put полностью перезатрется ресурс, а слышал ли ты ещё?
81: О таком свойстве. У http методов, как идемпотентность. И вот если слышала, то как это свойство как раз на перечисленные пост пути патчи применяется, да, идемпотентность у нас
82: Про то, что при повторном запросе к серверу, к ресурсу состояние ресурса не изменяется. И get у нас идемпотентный, потому что сколько бы мы не запрашивали данные, у нас состояние
83: Не изменяется пост и departed й. Раз мы вносим, ну, создаём новый объект или вносим изменения. Пост используется для создания нового ресурса, либо
84: Отправки данных на сервер для какой-то последующей обработки этот метод не идемпотентен, так как каждое выполнение пост запроса может привести к созданию либо нового ресурса, либо изменению состояния на сервере и если говорить
85: Put и patch to put идемпотентный, потому что он полностью перезатрет и соответственно ничего не изменится. А вот патч особенно смотря как его задавать мы же
86: Разные параметры можем пере перезатирать, обновлять. Соответственно, он не импотентный, так как у нас каждый раз будут разный результат. И вот как это свойство влияет на то, как ты будешь тестировать или влияет ли вообще, да.
87: Влияет. Соответственно, мы должны это учитывать. Опять же, при повторных запросах к этому ресурсу и при создании ресурса мы должны смотреть, что при get ничего не изменилось. При
88: Повторном запросе, а пост у нас либо ещё 1 ресурс создаёт, но это вряд ли, потому что айдишник уже новый. Скорее всего, должен создаться новый ресурс. У меня ещё вопрос такой небольшой.
89: Работал ли ты со, помимо немножко? Немножко работала, да? Угу. И можешь назвать какие-то отличия? Сопрас уреста в качестве бади может передаваться джио.
90: Xml xml даже у соупа только xml у соупа по сути есть 1 метод только это аналог пост в ристе и soap использует такой.
91: Специальный файлик это что-то вроде то, что в ресте используется сваггер. В соупе есть сделька, в которой как раз описано взаимодействие и соответственно, ты
92: Отправляешь запрос, он у тебя все время по сути пост и получаешь ответ в виде иксмл. Есть ещё какие-то отличия. Например рестфул имеет несколько свойств. Может быть в этом какие-то
93: Ты сейчас про принципы архитектуры рестфул, да? Или что-то другое? Ну, получается, если у нас есть какие-то принципы, возможно, как раз в этом и будет отличие. Угу. Рестфул архитектуры.
94: Полагает, ну это пожелание не настоятельное требование, что у нас сервер кэшируется, данные на сервере. Это удобно. Соответственно, следующее обращение будет быстрее.
95: Мы говорим, что у нас стейтлесс, то есть мы не храним состояние объектов и есть ещё много принципов у resta это расширяемость и по моему,
96: Всего 6. Я, наверное, сейчас все не перечислю, но основные, наверное, я назвала хорошо. Ну, представим себе, что мы закончили с автоматизацией пиай, и нам теперь разработчики дали за
97: Дачку на тестирование уже пользовательского интерфейса. Все те же самые список книг, которые мы можем добавить себе в корзину и потом перейти, например, на страницу оплаты. Но когда мы нажимаем на кнопку перейти на страницу оплаты, у нас появляется какой
98: Спиннер на какое-то количество секунд, допустим от 1 до 3 секунд у нас будет спиннер и потом отображается следующая страница. Вот как мы будем реализовывать наш тест, ожидать, что мы перешли на какую-то другую страницу.
99: Это возможно не мгновенно. Угу. Мы можем фреймворки разные использовать или не можем. Ну, расскажи мне, как ты бы решал эту задачу, может быть несколькими способами, в зависимости от каких-то условий. Я про
100: Фронт тестировать с помощью селениума. Есть такой инструмент. И, в общем то, в cypress джис есть схожие функции, они очень похожи, как они реализованы. Суть в том, что
101: Мы можем подождать какое-то время, к примеру. Ну мы можем подождать просто заданное количество минут, секунд или миллисекунд. Это у нас имплисит. Вейс есть также
102: Explicit, это условное ожидание, это про то, что мы можем дождаться какого-то события, появления кнопки доступности кнопки, открытие страницы, открытие вкладки это эксплисит.
103: И ещё селениум использует такое понятие, как флюент вейсс это подкласс, эксплисит, вейсс. Это когда мы можем каждое промежуток времени условно, каждые 3 или 5 секунд, как мы зададим проверять доступность.
104: Какого-то опять же объекта и на это завязываться. И если говорить про задачку со спиннером, наверное это был бы либо Флют или эксплисит такой явный, то есть какой-то вот из этих подходов.
105: Я бы использовала, а вот по поводу локаторов, да, то есть, если ты, например, хочешь ждать сколько-то секунд, пока отобразится какой-то элемент, соответственно, у тебя есть несколько способов, чтобы локатор этого элемента написать какими
106: Способами ты пользуешься. В каких случаях? Если у тебя, например, несколько вариантов есть самый идеальный случай? Это если разработчик нам на фронте прокинул какие-то айдишники к элементам. Для нас это самый простой
107: Вариант, но не всегда так бывает и не всегда позволяют фреймворки с точки зрения ui разработки чаще мы все-таки завязываемся на какие-то css, локаторы или экспа локаторы.
108: В каких случаях сиэсэс? В каких икспаф? Ну, например, у тебя же вряд ли будет такое, что во фреймворке у тебя сразу несколько способов, потому что, наверное, единообразия какого-то не будет. Или вы используете несколько способов?
109: 1 и того же фреймворка мы использовали несколько способов. Наверное, это не совсем корректно, но было такое, да? Угу. Ну и какой, в какой ситуации такой более хороший способ или
110: Ска удобна, когда у тебя к каждому элементу на странице есть чёткий какой-нибудь css класс, он не повторяется, и ты можешь на него завязаться спокойно и знать, что ты получишь.
111: Именно этот объект не всегда так бывает, у тебя могут быть на странице какие-нибудь перечисления, какие-нибудь списки, какие-нибудь таблицы, у тебя получается только 1 css класс, а элементов внутри.
112: Этой сущности много, и тогда, возможно, удобнее завязаться на экспа локаторы. У меня вот такая задачка. Представим себе, что нам нужно найти какой-то элемент, но у него нет никаких уникальных идентификаторов.
113: Внутри этого элемента, как его получается ребёнок лежит какой-то элемент, у которого есть уникальный идентификатор. Мы можем написать к нему локатор, как мы можем от ребёнка перейти?
114: На уровень вверх, к предку как написать этот локатор у экспасофт, обращаться к родительскому элементу и от него отсчитывать какие-то дочерние на количество элемент.
115: Грубо говоря. Угу. А у нас сейчас задачка наоборот, да, стоит от ребёнка обратиться к родителям, да, нам надо сначала найти ребёнка, потом, ага, шагнуть вверх на элемент, в котором он лежит. Наверное, я бы попробовала.
116: Сначала с помощью уникального идентификатора дойти до ребёнка и, возможно, потом с помощью экспасофт ться к родителю. Я сейчас не уверена, как именно синтаксически это нужно было бы.
117: Делать надо было бы поиграться, наверное, с этим. Угу. Ну, то есть ты не помнишь, как на уровень, вверх от элемента пройти на 1 уровень. У нас прям строго известно, что он сразу же в нём лежит. По моему, это
118: Что-то со слэшами надо посмотреть сколько слешей задать. Вот кажется это что-то об этом. Чтобы найти родительский элемент мы можем написать слэш, либо косая черта и 2 точки где-то в эту сторону, да.
119: Ладно, если ты не помнишь тогда. Угу. Ничего страшного. Давай тогда поговорим уже про ситуацию, когда мы все-таки написали все наши локаторы, и нам теперь надо их как-то, наверное, организовать в тестовом фреймворке, чтобы нам
120: Было удобно с ними работать, потому что разработчики нам добавляют, добавляют страницы. У нас появилась страница авторизации после того, как мы оплатили товар, у нас страница подтверждения заказа, и у нас теперь очень много локаторов, там сотни, там 1000 локаторов, нам сложно.
121: Теперь все это хранить. Вот как бы ты организовала всю эту систему работы. Для автоматизации используется основной паттерн, так называемый пейдж обжект. И он нам говорит о том, что хорошо бы все локаторы элементов хранить.
122: В 1 классе или в совокупности каких-то классов, но это какой-то отдельный слой. Далее идёт следующий слой. Это методы работы с локаторами, поиск, какие-то события.
123: Клик, что что-нибудь, что нам нужно. И следующий слой это непосредственно логика Тестов, но могут быть ещё какие-то промежуточные слои в зависимости от сложности нашего продукта. Хорошо. Ну вот представим себе, что у нас используется
124: Project, но у нас есть элементы, которые встречаются на каждой странице. Это может быть какие-то хедеры, футеры, ещё что-то, какие-то панельки, которые всплывают везде, вот как мы их будем описывать есть
125: Подкласс. У пейдж обжекта это page сабжект. Я ни разу не слышал термин пейдж сабджект только пейдж элемент, про который я, собственно, и хотел услышать. В данном случае я бы рекомендовал использовать либо самый популярный термин, либо
126: Просто перечислить все синонимы, как раз мы бы могли описать дополнительный слой, описать в нём повторяющиеся элементы, вот вроде хедеров и, соответственно, потом их использовать в наших тестах. Ну, допустим, мы все это
127: Писали, используем пейдж обжект. И тут у меня ещё такой вопрос. Можно ли все это теперь использовать с каким-нибудь бидди фреймворком? Если ты знаешь, что это такое и использовал, да, можно использовать на
128: В предыдущем проекте у нас был ddd фреймворк кукумбер, мы его использовали вместе с джавой, соответственно, в рамках фреймворка ты пишешь сценарии в парадигме гивен вен зен угу. У тебя дано.
129: Что-то. И если происходит какое-то событие тогда значит у нас мы ожидаем такой-то результат. И после этого сценарии в человекоподобном языке переносятся на код в языке разработки это
130: Можно использовать и вместе с селениумом, да? Угу. А есть ли какие-то минусы или условия, при которых бидди будет неэффективно и лучше его не использовать? Использование бидии довольно холиварная тема. Кто-то
131: Говорит, что здорово все можно сделать. Кто-то говорит, что не очень здорово считается, что когда у нас много условий и ветвистая вообще структура нашей логики, то бидии не очень
132: Очень гибок здесь и не очень удобен. Если у нас все чётко и мы можем выделить какие-то относительно небольшие сценарии без больших разветвлений, то бидии очень удобен. Ну и плюс он удобен.
133: Как, по сути, аналог документации на проекте, если мы её подробную не пишем, потому что сценарий бидии могут смотреть и аналитики, и, в общем, все люди на проекте.
134: Даже тех, кто не занят в разработке. Угу. А вот лично для тебя использование бидди на проекте это плюс или минус для меня, скорее, плюс, наверное, в части. Все. Теперь хотелось бы поговорить про
135: Твой опыт именно программирования, насколько я понимаю, у тебя основной язык это java?
136: Угу. Ну тогда у меня будут вопросы именно по джаве. Давай, наверное, начнём с таких, наверное, основных вещей. Это объектно ориентированное программирование в джаве. Можешь рассказать про парадигмы и про каждую можно там.
137: В 1 предложении как это можно использовать в тестировании java, объектно ориентированный язык, объектно ориентированное программирование или парадигма это концепция, которая подразумевает использование неск.
138: Основных постулатов, в частности, это наследование, это инкапсуляция, это полиморфизм. Ну, ещее абстракцию могут выделять. Угу. Как тоже отдельную такую концепцию с точки зрения тестирования.
139: Ну и с точки зрения разработки мы все эти парадигмы постоянно используем. Так или иначе, когда наследуемся, когда создаём дочерние классы, когда мы переопределяем какие-то методы активно используем во всех наших
140: Аспект. Ну вот, например, как тестировщик инкапсуляцию использует инкапсуляция. Это у нас сокрытие реализации. Соответственно, мы можем объекты использовать, которые
141: Реализации наших каких-то интерфейсов или мы можем использовать какие-то аннотации во фреймворках автоматизации много аннотаций используется вот как раз тоже использован подход инкапсуляции то есть
142: Мы не смотрим, как это реализовано. Просто используем аннотацию, когда ты упоминала интерфейс скрытия. Что ты под этим имела ввиду? Мы не, не думаем о том, как мы
143: Как у нас реализованы методы того или иного интерфейса, мы просто ego используем для каких-то реализаций, ну, например, у листа есть лист линк лист, и мы просто берём методы, которые есть у листа, и нам не нужно
144: Подробности есть того, как они устроены. Хорошо, давай тогда поговорим уже о таких, например, вещах, как ты упоминал, абстракцию. Вот, соответственно, можно считать проявле.
145: Абстракциями, когда ты абстрагируешься от каких-то вещей, объектов реального мира и концентрируешься только на тех вещах, которые важны именно тебе в программном коде. Ну например, у нас есть какая-то сущность и мы знаем, что нам
146: Важно только там имя, возраст, там ещё что-то и есть такое понятие, как абстрактный класс и интерфейс для того, чтобы описывать будущие наши объекты, как это использовать и в чем между ними различия абстрак.
147: Классы, интерфейсы, они во многом схожи между собой, и есть принципиальное отличие про интерфейсы мы говорим, когда мы хотим какое-то описать поведение нашей сущности или его
148: Какие-то действия абстрактные классы мы используем, когда нам нужно описать структуру нашего какого-то объекта в интерфейсах мы не описываем реализацию. Правда есть так как язык развивает
149: Java уже какая там версия на сегодняшний день? Вот по моему после 8 можно задавать дефолтные дефолтные методы, соответственно, описывать, реализовывать в интерфейсах, но в целом мы говорим о том, что в enter
150: Face мы ничего не реализуем, только описываем объекты и соответственно есть разница в том, как мы наследуемся от абстрактных классов и от интерфейсов, а можно поподробнее, в чем именно различие?
151: Когда мы наследуемся от абстрактных классов, мы наследуемся от 1 класса, ну, может быть, ещё от обжекта. А когда мы наследуемся от интерфейсов, мы
152: Реализуем интерфейс и их, может быть много ты упоминал, что мы наследуемся от обжекта можешь рассказать поподробнее, что это значит у джавы есть базовый класс object.
153: Насколько я знаю, у сишарпа тоже есть базовый класс, в этом они похожи. У джавы он называется object, у него есть базовые методы, соответственно, эти методы потом наследуются во все остальные классы. Эти методы, например, to string.
154: Это методы get класс, это методы хэшкод и кволс. И это методы, связанные с многопоточкой Вейт Атифа, Атифа ол и так далее. Ну и такой вопрос ещё про коллекции в джаве, как
155: Ты вообще представляешь себе иерархию коллекций, с какими коллекциями ты работала, все коллекции в джаве тоже составляют иерархию, соответственно, у есть коллекции, например сет. Есть коллекции list.
156: Которые мы сегодня упоминали. Есть коллекция map и есть ещее коллекшн, и каждый из этих интерфейсов тоже имеет ещё свои реализации. Более детальные у листа есть, например, link at least.
157: Released. У мапа тоже есть свои реализации, хэш мэп 3 мэпп и так далее. То есть каждая ещё коллекция интерфейс имеет свои далее реализации. А зачем все-таки так сделано, что
158: Мы не напрямую как будто бы используем реализации r, используем их со стороны интерфейса. Есть ли какое-то преимущество этого подхода, почему именно со стороны интерфейса? Да, мы, ну, здесь опять же, про
159: Полиморфизм и про то, что мы, используя какую-то реализацию конкретную, уже можем задействовать все методы базового интерфейса.
160: Можем ли мы создать свою реализацию на основе существующего интерфейса? Да, можем. Ну, и, получается, оно будет встроено, ну, работать по схожим принципам с уже существующими коллекциями. Угу. Хорошо.
161: Давай, наверное, тогда попробуем практическую задачку для практической задачки. Мне тебе понадобится идее расширить экран, подготовить базовый проект. Начнём с чистого листа и
162: И я тебе в зуме отправлю базовый код, который нужно будет вставить. Угу. Вот. Ситуация у нас такая. У нас есть сотрудник, которому доверили задачу написать реализацию фрак.
163: Класс для работы с дробными числами. Ну и, соответственно, дробное число. Числитель знаменатель представляется в виде нумератора и деноминатор. Ему также нужно было реализовать метод для сложения Дробных чисел и возвращения результата. Как
164: Дробное число. Ну и ему ещё сказали, что можно сильно не углубляться и реализовать поиск общего знаменателя самым простым способом просто перемножать знаменатель 1 и 2 числа.
165: Вот, ну и ещё на проекте стоит ограничение. Нужно писать юнит тесты, вкладывать их в pull request. И он написал юнит тест, и он считает, что все работает. Можно отправлять пулл реквест, но сам ушёл в отпуск и
166: Тебе переназначили эту задачу, тебе нужно провести ревью. Если все отлично, то на этом все и закончится. Если что-то нужно будет дописать, то тебе, получается, нужно будет доделать эту работу. Вот ты можешь сначала объяснить.
167: В чем проблема? А потом мы уже решим, нужно ли её сразу же исправлять. Ещё какие-то ограничения есть или вот все, что ты указал, больше никаких, ну, ограничений есть, что, в принципе, по проекту в основном мы покрываем и негативные
168: Ограниченные значения. Поэтому если здесь есть какие-то моменты, которые не покрыты, то ты можешь их тоже покрывать. Вот на этом пока, наверное, все. Если что, я тебе ещё буду подсказывать, тогда и по выбору именно
169: Вот ограничения, то есть интеджеры это все корректно или мы сейчас будем это обсуждать? У нас есть контракт, то есть под текущую реализацию будет какой-то другой клиент, который будет именно работать с этими данными.
170: Поэтому менять контракт мы не можем. То есть, если мы возвращаем фракшн как объект, дробное число иили используем интеджер, мы не можем это поменять, потому что у нас уже есть контракт здесь мы уже жёстко завязались. Хорошо, давай посмотрим, что нам
171: Далее. То есть у нас есть 2 интеджер, это, я так понимаю, числитель, знаменатель, судя по обозначению, у нас есть какой-то конструктор и у нас есть метод, это, это фракшн, это сложение, правильно? Угу. 2 дробей. И нам нужно
172: Соответственно, выводить результат тоже вот в виде объектов фрекшн. Здесь все чётко, ничего мы здесь не меняем с этой точки зрения. Ну, пока что выглядит, что не меняем пока что. Хорошо. Давай прове.
173: Как мы вычисляем наше сложение? Значит, ты сказал, что мы используем для общего знаменателя просто перемножение. И здесь похоже на правду. То есть мы 2 знаменателя.
174: 2 чисел перемножили и сложение. То есть мы числитель 1, домножаем на знаменатель 2, да, и, соответственно, числитель 2 на знаменатель 1. Здесь вроде все корректно. Ну,
175: Может быть что-то некорректно. Дальше посмотрим. Во первых, давай импорт нём так импортнули тест и импортном десерт икс.
176: Так импортнули, перестало быть красным. Попробую запустить, сразу посмотреть.
177: Как он работает у нас фракшн, да, не закрылся. Угу. Забыла скобочку добавить. Угу. Мы видим 2 объекта, судя по всему, разных. И при этом мы не видим.
178: Посчитал он что-то не посчитал, не очень понятно. Давай посмотрим. У нас есть здесь 1, 2 и 2/3, если их сложить, вроде похоже на правду. Да, 7/6 должно по идее.
179: Учиться. Корректный результат. Угу. Вот. Но у нас получилось 2 разных объекта. Ну, то, что мы здесь как бы каждый раз создаём нью фрекшн, соответственно.
180: Мы, мы сравниваем, ну, они у нас в соответствии с контрактом, как раз хэш код и equal. То есть у нас иквел, то может быть и равны, но хэш коды, судя по всему, не совпадают. Наверное, нам нужно
181: Переопределить контракт для этого. Ну, хэшкод иквел, чтобы, чтобы это у нас было корректно. Угу. Давай попробуем. Я буду делать тогда средствами ид.
182: Или можно средствами делать. Ну, делай, как тебе удобно.
183: Я не требую писать это все по памяти.
184: Угу, то есть нам нужен x и hash код?
185: Он нам переопределил. Попробуем запустить наш тест. Ну, выглядит, что теперь тест проходит, тест проходит, но есть проблемка. Да, мы не видим, что мы посчитали. Давай попробуем.
186: Ломать. Ну, тест упал, это хорошо. Угу. Но отладить мы его не можем. Сейчас нам нужно каким-то образом вывести на печать, соответственно, наши
187: Экшены, чтобы мы для отладки хотя бы увидели. Угу. Что они работают? Каким образом это сделать? Как ты думаешь, если я стрингу переведу, это будет нормальное решение? Ну, можно попробовать?
188: А какие ещё способы у тебя есть привести? А, ну ты сказал, нельзя. Да, мы только фрекшн должны выводить чётко. Ну, то есть я хотела привести, допустим, к интеджеру, пробовать. Есть ещё способы, не нарушая, кон.
189: Так-то. Но давай попробуем тот, который ты уже озвучивала.
190: Хорошо. Так, допустим, тест. Ну, мы сейчас и не увидим, если мы не сломаем тест. А, окей. А, ну вот мы сейчас видим хотя бы, что у нас, да, разные значения. Соответственно, тест упал.
191: Ну да, теперь более информативно. А в чем смысл вот того, что мы это исправили для автоматизации, это как-то используется. Поясни, пожалуйста, свою мысль. Смысл чего?
192: Ну вот мы сейчас переопределили ту стринг, но у нас до этого работало оно. Зачем мы все-таки это сделали, чтобы вывести именно для отладки вот эти значения, чтобы мы могли видеть хотя бы глазами, что мы могли бы подключить здесь отчётность какую-то, да, и
193: И у нас бы это тоже в allure какой-нибудь или ещё куда-нибудь передавалось бы, чтоб мы видели ну то есть когда ты потом открываешь у тебя 1000 Тестов и ты смотришь, тест упал, и ты не понимаешь, почему это больно, да?
194: Хорошо, давай тогда пойдём дальше. Ну, тут зависит от тебя. Нужно ли ещё что-то дорабатывать в этом конкретно в этом тесте? Или давай посмотрим в сторону.
195: Ну этот тест мы закончили. Нужно ли нам ещё тесты какие-то или в самом решении что-то ещё исправлять? Да, нам нужно ещё несколько Тестов. Соответственно мы проверили позитивную сейчас проверку, сделали функционально позитивную.
196: Ну, можем считать, что мы написали негативный тест, кейс, но негативный. Хорошо было, как поточнее написать там x, чтоб он как бы проходил, но говорил, что да, как бы это не
197: Соответственно, нужно ещё так как это у нас числитель и знаменатель, и знаменатель не может быть нулём. Соответственно, нам нужно проверить нули, чтобы в знаменателях не было и до
198: Либо сделать тест, либо, ну, можно прям в решении было бы уже отсечь это добавить какую-то проверку. И, соответственно, налы тоже хорошо было бы проверить, что если нал, то тоже, либо
199: Тестом, либо в самом решении уже тоже сказать, что если нал, то пожалуйста там введите что-нибудь не null. Ну давай попробуем либо нал, либо 0 keys. Сейчас прям написать. Давай тогда мы прямо здесь наверное в решении.
200: Отсечём этот вариант.
201: Окей, ну то есть я сейчас хочу выкинуть какую-то exception. Угу. На то, что мы ввели. 0.
202: Единственное, что
203: Я сейчас проверила 1. 1 знаменатель, ну вот какую-то такую проверку на 0 можно было бы попробовать реализовать. Посмотрим, как это отработает.
204: Исключение падает. У меня такой вопрос. В правильном ли месте добавили эту проверку? Я, получается, добавила в метод именно сложения. Ну, ну или, допустим, если это пра,
205: То обоснуй, почему именно сюда можно, можно здесь его сделать так как, ну, так как мы здесь производим действия с числителем и знаменателем здесь, ну, мы просто перезаписываем методы, наверное, не
206: Очень актуально сюда эти проверки вводить в конструктор. Тоже можно сделать просто отдельный метод какой-то, который бы там что-то проверял Водовский, допустим, ну мы его
207: Создадим, например, как приватный метод, но мы же его где-то будем вызывать, надо будет, да, везде, ну, как бы, вызвать его и чекать тогда тоже при вычислениях, либо в тесте, соответственно, вызвать, либо опять же, при любом вычис.
208: Вызвать этот метод. А представь себе ситуацию, что вот сегодня нам нужно только сумму делать, а потом тебе скажут, нам нужно разность, умножение, деление дробей, возведение дроби в степень и у тебя будет ещё там.
209: 4, 5 новых методов. Ты в каждый новый метод будешь добавлять этот код проверки на 0. Нет, тогда нет. Тогда я сделаю, как мы с тобой сказали. Просто метод войдовой приватный, который будет эти проверки проводить.
210: Допустим, в тестах я бы вызывала, наверное, уже эти методы. Угу. Хорошо, тогда у меня следующий вопрос. Если вернёшься сейчас к тесту,
211: Вот представим себе, что у нас нет сложения, а мы просто создаём дроби. То есть, получается, мы на 10 строке можем создать дробь с нулевым знаменателем, мы ничего с ней не делаем, ни
212: Складываем ни с каким другим числом, с другой дробью, но она существует в принципе. Может ли существовать дробь, если у него 0 знаменатель с математической точки зрения, наверное, нет. Ну как может быть какие-то теории?
213: Допускают такое, но, вообще говоря, нет. Угу. Ну и как бы ты это исправила? То есть, куда все-таки, может быть, перенести? Предлагаешь конструктор сделать эти проверки? Я ничего не предлагаю.
214: Я хочу услышать от тебя, как ты думаешь, как лучше это реализовать? Ну, то есть у каждого решения, скорее всего, есть плюсы, минусы, плюсы и минусы. Да, можно ещё что сделать вообще?
215: Говоря, можно и просто сделать какой-то 1 тест, который будет все это проверять, да, а потом мы это будем не дёргать каждый раз. Так тоже можно, кроме нула, нуля и сложения. Нужно ли нам ещё какими-то тестами покрывать, да?
216: Да, давай подумаем, наверное, ещё об этом. Соответственно, насчёт отрицательных чисел, по идее, должны работать нормально, потому что, ну, просто мы сложим с отрицательным числом, плюс на минус заменится будет все нормально по поводу каких-то
217: Строк, я имею ввиду типов данных. Вообще сильно не integer строки. Чары, наверное, тоже нужно было бы делать проверки, как вот мы 0 проверяли. Ну, вообще, на тип, либо
218: Делать какое-то приведение к интеджеру, если он у нас требуется и соответственно на опять же, если говорить там про какие-то ограниченные значения классы эквивалентности, то мы можем выйти
219: За рамки диапазона integer, к примеру, и тогда это тоже нужно учитывать и проверить а что ты подразумеваешь под выйти за диапазоны интеджер и какой тогда ожидаемый результат будет или как?
220: Как это обработать? Ну, каждый тип данных в джаве имеет свой какой-то диапазон, максимальный, который может быть использован у integer. Я не
221: Помню, там, по моему, то ли до 62 миллиардов ну, что-то, в общем, есть он 16 bit или 16, в общем, ограничения так или иначе есть, можно посмотреть, погуглить, сколько это именно и
222: Если мы берём число, выходящее за границы диапазона, мы можем не словить ошибку на этапе компиляции, но
223: Получить то число, которое мы явно не ожидаем увидеть. То есть у нас не будет там 62 миллиарда, что-то там, а будет минус - 60.
224: 2 миллиарда. Ну, как-то так. То есть мы уйдём за левую границу диапазона и начнём оттуда. Угу. И как тогда это исправить, если мы не можем исправлять контракт наших Тестов? Ну, опять же, мы можем либо
225: Пользователя напрямую попросить, если, ну, отсечь это значение, если сказать, что больше такого, то, то введи, пожалуйста, что-нибудь поменьше, либо, ну, а как ты это будешь проверять в коде, где
226: И каким способом? То есть у тебя есть сейчас там нумератор, деноминатор, да? Угу. Ну, вернись обратно к классу фракшн и просто покажи мне мышкой, куда, что ты будешь писать. Вот как сейчас мы реализовали проверку.
227: На 0. Также мы бы могли бы сравнить с каким-то вот числом, выходящим за границы диапазона. Ну вот, например, наш коман деноминатор при перемножении может выдать число, выходящее за интеджи больше, да, тоже может и как
228: Какую проверку мы бы здесь добавили вот мы посчитали, да, и мы могли бы сразу, допустим, в try catch это обернуть и отловить, то есть сделать try вот такое-то перемножение, и если
229: Вышли за границу, то catch тоже там exception описать этот эксепшн. В начале, при обсуждении переполнения интеджер Арина сказала, что мы просто получим отрицательное число. Теперь же она уже говорит о том, что
230: Будет выброшено исключение, а это неправильно. В данном случае исключение нужно выбрасывать самостоятельно, и трайкеч блоком его нельзя будет обработать. А какой exception бы у нас выловился, если бы мы
231: Перемножили 2 максимальных числа, я сейчас точно не вспомню какой-то exception, либо что-то с тайпам. А если мы
232: А если мы не знаем, какой конкретный тип, какой бы ты указывал какой-нибудь рантайм, тоже бы указала. Допустим, вообще мы можем и на проекте, и свои эксепшены тоже реализовать и описать много подвидов каких-то тоже частных.
233: Могли бы заморочиться в эту сторону или пробросить вот рантайм, остались ли у нас какие-то ещё тесты или ещё какие-то замечания к этому пулреквесту? Или после того, как мы допишем исключения на рантайм, эксепшн на этом будет все получать.
234: Можно бесконечно. Тестирование полное, тоже недостижимо. Угу. Соответственно. Ну, надо подумать, чтоб мы точно не забыли ничего важного, как ты уже тоже вот мне указал, что действительно у нас и результаты вычислений могут
235: Выходить тоже за какие-то ограничения, это хорошо бы все тоже отлавливать. Ну, нал, мы бы тоже бы обработали, к примеру, наверное, все, но возможно, что
236: Подумать ещё в сторону того, что можно ещё проверить. Ну, я тебя жду, когда ты закончишь тогда с этой задачей заключение, да, тестировщик можно выводить, да, вот как раз сейчас. Можно ли
237: Катывать в prod этот код есть ли отмашка от отдела тестирования всегда хочется, чтоб кто-нибудь другой да дал такое заключение всегда думаешь.
238: Что что-то недопроверена, наверняка что-то недопроверена даже сейчас. Ну с учётом всего, что мы с тобой указали, потому что, ну не знаю, могли бы мы тут передать где-то тоже битую ссылку, где-то
239: Ещё кроме того, что мы обозначили хорошо, у меня тогда такой вопрос представим себе, что мы это выложили в релиз в prod и действительно нашли какую-то ошибку, как тогда лучше всего действовать были?
240: У тебя такие, с какой точки моменты в карьере? Ну вот мы выложили новый релиз этого метода, к нему привязались и. Угу. Не работает. Там пишут отзывы в техподдержку звонят, говорят, мы не можем работать, потому
241: Потому что у нас дробные числа не считаются. А где уже в проде, получается наш, да, уже в проде, уже в проде, печально. Ну, хот фикс, наверное. Угу. А кроме хотфикса ещё какие есть варианты откатить релиз можно? Угу.
242: Больше, наверное, не будет вариантов. На самом деле есть ещё варианты, которые я хотел бы услышать. Например, можно было ещё выложить бы исправление в следующем релизе, в случае, если, например, текущая проблема, не блокирующая, также хотелось бы услышать
243: Как в целом можно снижать количество инцидентов после релиза, например, с помощью фича, флагов альфа и бета тестирования, да, наверное, тогда с практической частью все. Ну, я имею ввиду именно про кодинг часть можно
244: Вернуться просто к теоретической части. И вот ты упоминала, что можно было бы использовать аллюр, отчёты или что-то ещё, как бы ты это организовывала именно в процессе тестирования в целом. То есть как бы ты где
245: Ты это смотрел, то есть локально на ccd, как бы ты все это настраивал. Можешь про этот опыт рассказать. Угу. Можно, соответственно, и локально. Мы бы могли даже к нашему этому проекту подключить. Алер в зависимости и
246: Смотреть отчётик, но это не очень удобно. Если мы говорим о командной работе, соответственно, используется алюр, есть аллюр, те. Стопс и можно все
247: Иди подключить вывод результатов Тестов. Алерос их, соответственно, на какой-то ресурс в компании сервер какой-нибудь. И как только билд, допустим, с автотестами прошёл.
248: Сформировался аллюр отчёт и он выгружается прям в виде такой красивой диаграммы. Сколько упало, сколько прошло. А вот про твой опыт ты больше. Ну то есть имела ли опыт создания пайплайнов?
249: Job с нуля самостоятельно или это больше переиспользование каких-то существующих, или у вас была какая-то девопс команда, которая за вас это делала. В основном у меня складывалось так, что
250: Девопсы или saga, инженеры с нуля выстраивали этот процесс, но у меня были задачи, когда что-то нужно немножко для себя донастроить. И самое частое это, конечно, использование, это просто собрать билд.
251: С какой-то версией, вернее собрать жабу с какой-то новой версией билда. И ты в параметрах билда прописываешь соответственно номер может быть ещё какие-то настройки, компоненты, которые тебе нужно использовать, но это уже
252: Pipeline pipeline описывается в виде файлика если его открыть, то, в общем то можно прочитать, что делается в ходе этой джаббы и можно что-то поменять и такие задачки.
253: У меня были что то куда-то из другой ветки взять или что-то переложить. Но вот с нуля полностью, нет, не создавала. А с какими системами сиайсиди ты работала? Дженкинс и гитлаб сиай? Угу.
254: Ну вот, например, в дженкинсе ещё можно какие-то свои, паш скрипты использовать? Был ли у тебя опыт написания каких-то скриптов именно в дженкинсе? Нет, ну не нужно было делать это в рамках jenkins, но именно на
255: Стороне сервера. Иногда нужно написать какой-нибудь скриптик, чтобы, к примеру, файлик какой-нибудь класть куда-нибудь, подкладывать нужную папочку, чтоб каждый раз ручками это не делать. Такой опыт был, да? Угу. А можешь, например,
256: Вспомнить команду. Если у нас есть какой-то файл, мы хотим внести в него изменения, прочитать ещё что-то с ним сделать, но у нас нет к нему доступа. Как мы можем для этого файла открыть полные админские права?
257: У юникс систем unix подобных систем есть специальная команда для задания прав доступа к какому-нибудь файлу, к Папке. Называется команда цшот. Угу. И
258: Шмот вызываем или нужно с какими-то параметрами вызывать? Да, с параметрами есть группа параметров, которые относятся к доступам, к ресурсам. Сначала мы указываем к пользователю конкретно
259: Или группе это 1 параметр. Следующий параметр добавить или удалить права плюс или минус. И следующий параметр или группа параметров это какие именно операции разрешить или удалить.
260: Например, для чтения мы бы написали r для записи дабл ю. Ну, у меня по ccd, наверное, все, у меня ещё осталась последняя, наверное, такая техническая тема это твой опыт работы с базами данных и написания, например, запро.
261: Есть ли у тебя какой-то опыт? У меня опыт только с революционными базами, с нереволюционными. Опыта не было. Угу. Ну, нам иногда в тестировании приходится писать какие-то простые запросы. Я могу привести пример, ну, такой.
262: Образно. Допустим, у нас есть 2 таблицы таблица студентов, таблица оценок. И нам нужно написать запрос, который вернёт всех студентов, у которых средняя арифметическая по всем оценкам, по всем предметам.
263: Больше, например, 4. Я не прошу тебя писать этот запрос, просто рассказать, какие ключевые слова ты бы использовала селект. Угу. Чтобы вообще что-то получить далее.
264: С жонить, наверное, нужно было бы эти 2 таблички, если у нас студенты и оценки лежат в разных табличках. И далее нам нужно средние оценки и студенты, у которых оценка выше средней.
265: Соответственно, нам можно было бы сгруппировать этих студентов. И далее, когда мы группируем это групбай оператор и групбай не работает.
266: Допустим, с такими конструкциями, как ва, но у групбай есть своя подвыборка с помощью хэвинг, и вот хэвинг можно было бы посчитать среднее среднюю оценку.
267: Используя какие-то функции агрегации, ну, например, средние, это average авг. Угу. Вот такие бы команды у меня были бы в запросе. Ты упоминала джоины вот какой.
268: Именно там же их несколько есть, так как я сейчас не вижу структуру наших таблиц, я бы взяла просто join, который если мы пишем просто join это inner join, это пересечение.
269: Чёткая, как бы между 2 табличками хорошо абстрагируемся от наших текущих таблиц, просто в чем тогда разница между, например, left и иннерджоин?
270: Угу. Лефт джойн говорит нам о том, что мы берём все данные из 1 левой таблицы, потом берём те данные, которые у нас на пересечении со 2 таблицей, и все, что у нас не совпало, мы выводим как null и
271: Join. Соответственно, мы выведем только пересечение данных, которые и таблицах совпадают по ключам. Угу. Ну, соответственно, у нас, если есть лэф, то будет right. Join. Ещё какие-то джоины, кроме этого, существуют, да?
272: Их вообще много, потому что ещё используются всякие комбинации. Но Лев райт иннер, как мы уже назвали, есть ещё full join и cross join. Угу. Ну,
273: Вот full join кросс джоин это что за джоины такие кросс джоин это по сути, для каждого произведения мы выведем все сочетания строк 1 таблицы со всеми строками.
274: То есть, если у нас тут было 10 записей, тут 20 станет 200. Фул, джоин, мы просто выведем 2 таблицы и ещё пересечение данных, которые в этих 2 таблицах используются. Угу. А если
275: Нет соответствия, то какое значение тогда будет? Ну вот как ты говорила, нал, то есть соответствия то на full это как будто бы let i джин одновременно. Это как вместе, да. Угу. И по поводу
276: Агрегирующих функций ты использовала эвередж, а какие ееще агрегирующие функции ты знаешь?
277: Есть ещё мин Макс, для вычисления минимального максимального значения. Есть сам сумма и count, просто подсчёт количества. Угу. Ну, наверное, по эскелю достаточно. Вот.
278: В принципе, наверное, по техническим вопросам тоже. У тебя есть возможность задать мне какие-то вопросы. Перед этим я немножечко бы тебе ещё рассказал про возможности внутри компании. Возможно, это тебе поможет.
279: Какие-то вопросы тоже обновить. Может быть в целом в компании очень хорошо развита инженерная культура и инженеры, которые попадают в компанию, они являются инженерами внутри компании и у них есть какой-то проект.
280: На проекте может быть что-то своё, но оно в целом обычно сочетается с какими-то практиками, которые есть для всех инженеров. Кроме того, внутри компании у каждого сотрудника есть свой деливери, инженерный менее
281: Которые могут поставить себе цель на развитие, например, ты приходишь мидл кей инженером, и ты хочешь стать senior инженером, ты можешь получить план развития, согласовать его со своими менеджерами раз в полгода.
282: Встречаться на performance review раз в месяц встречаться на one тубане со своим менеджером и таким образом достичь своих целей кроме того, есть внутренние курсы, оплачиваются какие-то внешние курсы, которые сочетаются с тем планом развития.
283: Которые у тебя есть. Также у нас внутри компании проходят внутренние и внешние митапы. Можно участвовать в непроектных активностях, например, собеседовать, менторить, создавать какие-то новые внутренние курсы.
284: Быть куратором или ментором этого курса. То есть возможностей для развития на самом деле много. Кроме того, можно менять проекты, менять технологический стек и даже менять свою, наверное, специализацию. Например, ты пришла автоматизатором, ты
285: Может перейти в backend, ты можешь развиваться дальше, как калит или менеджер, или, может быть, стать, например, архитектором. Все зависит от тебя, от твоих возможностей, от твоих желаний. В целом это возможно внутри компании. Вот здорово.
286: Наверное, с моей, с моей стороны пока все. Вот можешь свои какие-то вопросы, если есть, да, самая интересная часть собеседования, у меня есть ряд вопросов. Ну, я поняла, что компания
287: Есть разные проекты, как в целом вы выстраиваете работу тестирования? Пишите ли вы тесты, сразу пишите. Я имею ввиду автотесты. Пишите, когда у вас уже есть вы.
288: Выделенный набор регресса или все привязано к проекту и зависит от его целей. Ну скорее всего все зависит от проекта в каких-то проектах у нас уже есть какая-то структура.
289: Настроенные процессы, мы приходим туда, там есть команда заказчика, у них есть какие-то ожидания от инженеров или, может быть случай, когда проект стартует с нуля и от компании как раз ждут, что придут опытные инженеры и настроят все эти
290: Процессы, то есть есть разные варианты. Есть вариант, где процессы уже настроены нашими инженерами и так далее. То есть есть все эти вариации и все зависит от того, на какой проект ты попадёшь. Либо тебе придётся что-то своё предлагать, либо
291: Тебе придётся использовать какие-то чужие процессы, либо что-то среднее, когда возможно чужие процессы, но ты можешь вносить в них изменения, либо обсуждать это, и там тебе будут идти навстречу. То есть возможны все вариации. Если мы говорим именно про тестирование, то там тож
292: Это все зависит. Я могу сказать про те проекты, на которых я работал. На тех проектах, на которых я работал. Там были ручные тестировщики, которые занимались ручным тестированием. Со стороны заказчика. Мы занимались именно автоматизацией, и там было дозволено, например, на 1 спринт от
293: От основного релизного цикла по каким-то некритичным тестовым набором. То есть мы должны смок вручную протестировать спринт, а потом дополнительный регрес можно будет закрыть в следующем, например, спринте. И это позволялось, но
294: Как это работает с какими-то другими командами, с другими заказчиками, это уже их какие-то внутренние решения. Я за все проекты не могу отвечать. Вот. Но в целом, наверное, все должно быть более менее адекватно и
295: Есть возможность в большинстве проектов что-то поменять под себя, допустим, если это приносит, например, какие-то улучшения процессам, бизнесу и так далее. Здорово. А вот такой вопрос по стекам технологии.
296: Вы на всех проектах пишите автотесты на java или есть разные варианты? Ну, я бы сказал, что у нас 3 основных стека, это java, python и javascript, тайпскрипт. Угу. Скорее всего, сейчас нет возможности, сишарп.
297: Котлин руби или какие-то там гои другие специфичные. Возможно кто-то у нас это использует на своём проекте какой-то модуль отдельный пишет, но это очень специфично и то есть это будет в плюс к предыдущим 3 стекам, то есть
298: У нас нет отдельных каких-то других стеков. В основном у нас тестирование это фуллстеки. То есть нужно уметь и бэкэнд юай для мобильного тестирования. Иногда это может быть отдельная команда. Перфоманс, тестировщик.
299: Это тоже, возможно, отдельные тестировщики. Сейчас открыта вакансия, именно фуллстека, которая включает в себя бэкент юай, но не включают мобилки, перфоманс. Но если, допустим, тебе эта история интересна, в этом можно будет развиваться и потом.
300: Найти применение либо на текущем проекте, на который тебя найдут, либо на каких-то других проектах. То есть именно вот эти направления, они у нас есть. Также можно будет развивать. Например, cloud технологии у нас на большинстве проектов хотя бы 1 какой-то
301: Используется в основном это настри, это эйжур, это aws или google cloud. То есть либо у тебя уже есть этот опыт, и ты можешь его применить, либо внутри компании есть сертификация, она оплачивается и можно
302: Будет изучить какой-то cloud и найти проект, например, где этот клауд тоже используется. Да, очень интересно. Следующий вопрос у меня на такую холиварную, наверное, тему, связанную с метриками. Они у вас
303: Писанные в вашей вакансии. И я часто встречала, приходя куда-нибудь на проект, что-либо метрики вообще не собираются, либо их собирается так много, что в общем то не очень понятно, что с ними делать.
304: И по результатам этих метрик устраиваются там какие-то дисциплинарные меры. Вот хотелось бы понять, какой у вас в целом по компании подход к метрикам, как вы собираете и как вы их используете? Ну, я бы не сказал.
305: Что у нас дисциплинарные меры какие-то в основном метрики используются для улучшения процесса, и они тоже как бы 2 подходов с 2 сторон. То есть могут быть какие-то метрики, которые нужны со стороны заказчика, то есть
306: Онсайт команда онсайт лит. Может прийти, мне нужны вот эти метрики и ты будешь их заполнять, потому что это запрос, либо есть другой способ. Это наши инженеры, они создают какие-то метрики для себя, чтобы лучше делать свою работу. И тут зависит от того. Это formal.
307: Метрики, которые кому-то нужны, или это метрики, которые нужны вам. И в этом случае, например, под этот проект. Скорее всего, это метрики, которые нужны и вам, и заказчику. У заказчика есть несколько метрик. Например, в основном его могут интересовать регресси.
308: Наборы, то есть процент прохождения, то есть в прошлый спринт было там 90% в этот спринт, там 92%, мы на 2% повысили регрессию, это уже будет, допустим, достижение какое-то или он будет смотреть на тренд мы уменьшаем или увеличиваем
309: И как это зависит от количества Тестов. Например, если количество Тестов увеличилось, но уменьшился процент, это ещё адекватно, потому что тесты увеличились. А если и тесты уменьшаются, и регресс уменьшается, здесь надо искать причину. И это вот как раз те метрики, которые тебе тоже могут, помоч.
310: То есть ты можешь по модулям смотреть, что происходит, в принципе, смотреть количество дефектов, количество про дефектов, обнаруженных там в каком модуле и так далее. Это тебе поможет как-то улучшать процессы. Поэтому здесь в целом
311: Нет, наверное, какого-то единого подхода. Это зависит от проекта к проекту, но есть какой-то такой общий гайдлайн. Если у вас нет требований на проекте, то можете использовать это, это то, что у нас есть внутри компании, то есть внутри компании есть гайдлайны по типовым
312: Шаблоном проектом есть типовые фреймворки, которые можно переиспользовать. То есть если ты придёшь на проект и у тебя вообще нет опыта, а тебе нужно создать тестовый фреймворк с нуля. Ну ты можешь сходить к коллегам, это можно будет сделать внутри компании. Тебе подскажут, выдадут ментора.
313: Если у тебя есть опыт, ты сама это можешь сделать, то есть в зависимости от нужды у нас есть различные возможности как это реализовать угу. Следующий вопрос по процессам с dlc с tlc насколько?
314: У вас бюрократизированы процессы, есть ли они или каждый проект процессы строит под себя, и как это вообще происходит в компании? Ну, со всеми проектами, на которых я работал, мы работали по аджайлу. Угу.
315: Соответственно, у нас есть релизный цикл, он может быть там неделя, 2, 3. Мы делаем какие-то фичи, как я уже говорил, вот у нас даже было послабление, что мы могли регрессию сделать в следующем, например, спринте именно какие-то неосновные кейсы и так далее, и
316: Здесь все, наверное, оно как-то стабилизируется, и в зависимости от того, как команда все-таки работает, есть какие-то модификации. То есть в 1 команде будет 1, в другой команде другое, где-то там agile больше там переходит.
317: Что-то ещё, но в целом, плюс минус, наверное, такой примерный подход, в основном у нас. И команда будет делиться, что у нас есть часть ансата, часть наших и типичное вот представление команды, это будет, наверное, какой-то про
318: Менеджер продукт, она будут аналитики, например, часть бэкенд юай разработки, может быть ручной тестировщик, может быть, нет и будут автоматизаторы. Иногда есть проекты, где таких команд много у 1.
319: Заказчика, и они между собой тоже коммуницируют. То есть будет возможность общаться не только внутри своего юнита, но и общаться с другими юнитами и также делиться знаниями. Работать возможно в общем фреймворке. То есть, например, может
320: Быть какая-то команда, которая отвечает за определённую страницу сайта, другая команда за другую страницу. И вы в целом как бы один и тот же сайт разрабатываете, но в разных таких юнитах и будете вот таким образом разрабатывать в целом. Угу.
321: А что касаемо шифт, лефт и shift right подходов используются, они по факту или не используются ну у меня на проекте использовался, там проект был перехода с монолитной архитектуры на микросервисную, и в этом есть плюсы.
322: Использование shift left подхода как раз с контрактным тестированием, который я упоминал, я как раз его реализовал, и это был вот такой процесс, что у заказчика не было контрактного тестирования, и это возможность в компании выделиться.
323: Разработать что-то новое, внедрить, доказать эффективность сначала на 1, ну в 1 команде, потом это расширить на другие команды, завоевать таким образом репутацию. И после этого можно поделиться теперь уже внутри всей ком.
324: Компании для всех заказчиков, приходить к ним и предлагать свои услуги. И это выгодно. На самом деле всем сторонам это выгодно и заказчикам, которым приходят и внедряют какие-то улучшения. Это выгодно и нашей компании, потому что мы теперь можем предлагать новые услуги.
325: И это выгодно и самому инженеру, потому что это возможность карьерного роста, если он делает какие-то достижения не только на уровне своей команды, но и потом на уровне всего аккаунта и на уровне всей компании. Здорово. Такой вопрос, ты мне
326: Не указал про перформанс ревью каждые, кажется, полгода. Выстроена ли у вас матрица компетенции, все ли там чётко прописано, понятно? И куда можно расти в целом в компании? Ну,
327: Матрица компетенций существует, соответственно, у нас есть система грейдов, она начинается с Интерна и для инженеров кьюэй она заканчивается distinguish, то есть junior middle senior staff, синьор стаф принц.
328: Инженер это именно инженерная ветка, но можно расти не только в инженерной ветке, можно расти, например, в менеджерскую ветку. То есть это будет деливери менеджер, можно, оставаясь в инженерной ветке, иметь роль. Это не отдельная игры, это
329: Тролль это, например, калит, можно также пойти по архитекторской ветке, то есть у тебя есть варианты именно как k инженеру, то есть, наверное, сеньора, у тебя уже будет развилка в delivery идти в менеджмент, оставаться инженером, либо
330: Приходить в архитектуру. Вот, то есть на самом деле у тебя такое будет и по матрице компетенции можно будет по каждому грейду посмотреть, какие есть требования. Ну вот, например, чтобы стать сеньором, нужно иметь, например, опыт либо создания тестовых фреймворков с нуля, либо, ну,
331: Существующим тестовом фреймворке, доработать его какие-то новые функциональности, добавить здорово. И последний, наверное, вопрос, поддерживает ли компания развитие личного бренда конференции участие
332: Написание блогов или речь об этом не идёт. Ну, в целом поддерживает, но здесь важно понимать, что у тебя тот проект, над которым ты работаешь, он у тебя должен всегда иметь 1 приоритет, то есть
333: Если ты справляешься со своими рабочими задачами и в дополнительное время или даже в рабочее время, но ты успеваешь этим заниматься без каких-то потерь, то ты можешь этим заниматься, и в компании есть возможность как раз применить свои какие-то активности.
334: То есть менторинг, выступление на конференциях, участие в собеседованиях, какие-то курсы и прочие вещи это все включено в корпоративную культуру, и этим можно заниматься. Плюс ты можешь этим и как-то, где-то
335: Стороне, например, заниматься. То есть, если у тебя, например, есть какой-то блог или YouTube канал, да, скорее всего, это будет как раз даже возможно поощряться, потому что ты развиваешься, если ты ещё и будешь этими знаниями делиться внутри своей команды, внутри компании,
336: Это, наверное, будет тоже очень положительно воспринято. Здорово. Спасибо большое. У меня больше нет вопросов. Угу. Тогда спасибо тебе за то, что пришла за собеседование. Было приятно с тобой познакомиться. Вот. И да.
337: Мы будем сегодня обратную связь или обратную связь, потом, позже будет по обратной связи. Смотри, как все происходит. Сейчас общее техническое собеседование. Я тебе дам сейчас обратную связь, кра.
338: Такое от себя плюс потом будет расширенная и дальше следующий этап либо это там over, либо это дополнительное собеседование к конкретному проекту ну и либо это расширенная связь почему?
339: Сейчас нет, и ты сможешь, например, если это нет, то всегда можно прийти ещё раз, например, через полгода или на какую-то другую открывшуюся вакансию. То есть варианты есть, мы. Угу. В любом случае не прощаемся. То есть в любом исходе. Вот.
340: Ещё что-то, какие-то вопросы по процессам все, больше нет. Угу. Тогда в целом по фидбеку давай, наверное тогда разделим это на части фидбэк по вступлению. Ну, во первых, видно, что у тебя есть подготовлен.
341: Речь. И в части моментов, оно звучало похоже, например, на старую методологию, где ты рассказывал, что вот у меня была такая-то ситуация, когда мне нужно было в регрессии исправить там с 2000 падений до 200, то есть ты
342: Показала ситуацию, какие твои были действия и в конечном итоге результат и здесь даже прослеживается, как это влияло на бизнес. Ну то есть в 10 раз уменьшить количество регрессов, значит вы меньше тратите время на анализ этих дефектов и можете чем-то дополнительным заниматься поэтом.
343: Это выглядит как достижение. И такие моменты хорошо включать в резюме. Оно таким, и историю о себе, оно таким образом продаётся. Я бы сказал, что это позитивное. Угу. Вот там были достижения, я услышал их хордовые
344: И soft скиловые достижения. Я слышал то, что был ментрида, это тоже позитивно. То есть, если в целом мы вот сейчас оцениваем, это не со стороны того, что я, например, тебя нанимаю, а со стороны понравится ли это потенциальному
345: То да, иногда собеседование, оно включает в себя, например, какого-то деливери менеджера или внимающего какого-то специалиста, которому интересно услышать вот про какие-то такие достижения, которые влияют на твою ценность.
346: Влияет на то, сколько бизнес денег сможет там заработать или где-то сэкономить благодаря твоим каким-то решениям. Вот в целом у тебя там было и саммари твоё, ты рассказал про свой текущий, про свой предыдущий проект, потому что текущий у тебя не сильно
347: На вакансию. А вот предыдущий там как раз опыт фулстек к инженера, он подходит под описание текущей вакансии, поэтому хорошо, что ты про него рассказала. И там довольно-таки подробно было. Единственное, что я спрашивал у тебя в вопросе какие у тебя
348: Дальше ожидание в твоей карьере, ты на это автоматически не ответила, и мне пришлось дополнительно с тебя спрашивать. Угу. То есть как будто бы вопрос потерялся, но здесь это, ну, выглядит довольно-таки адекватно, потому что было сразу же много вопросов. То есть ты можешь, не знаю, там заметки тогда себе
349: В будущее, что ты на какой-то вопрос просто не ответила. Угу. Потом, после этого мы перешли уже к технической части, мы начали с бэкенда, ну и, соответственно, про backend. Мне, в принципе понравилось как-то.
350: Отвечала на вопрос где ты чего-то не знаешь? Например, я спрашивал тебя про кафку и про rabbit, mq, ты честно призналась, что с rabbitmq у тебя практического опыта не было, то есть не надо врать на собеседовании, и это правильно, и в то же время ты сказала, что, если необходимо, я это.
351: Буду изучать. Просто у вас в вакансии сейчас этого нет, и адекватно, что ты этого не знаешь, если мы от этого, от тебя сейчас не требуем. Но конкретные заказчики могут все-таки от тебя что-то требовать, и им важно знать, что если у тебя этого опыта нет, то ты готова его получить. Поэтому это
352: Ну, достаточный, наверное, ответ на такие ситуации. Вот. Потом по ибен, по ui части у тебя были моменты, где ты что-то, допустим, немножечко неправильно отвечала, или
353: Были случаи, когда я тебя что-то хотел услышать, например, когда я у тебя спрашивал, какие варианты у нас тестирования бэкенда. Угу. То там можно было чуть чуть ещё доработать, например, про кэшируемо ть, рассказать или ещё про какие-то вещи. Ну, про это я.
354: Поподробнее про каждый вопрос. Ответ уже отдельно запишу тебя. Вот ещё могу сказать, что были моменты, когда чувствовалось, что ты не очень уверен. Если вот мы, например, перейдём к практической задачке, мне понравилось то, что ты озвучивала
355: Действия и в целом, что ты делаешь. И было понятно, почему ты это делаешь, хотя мне и приходилось иногда дополнительные вопросы задавать. Вот, наверное, минус такой был, что когда я тебя спросил, все, мы остановимся, когда ты скажешь, что ты закончил
356: Тестирование, и ты очень неуверенно закончила это тестирование. То есть здесь, наверное, все-таки, может быть, даже самоуверенности увеличить, чтобы чувствовалось, что твой опыт, который
357: У тебя есть, а у тебя так-то большой опыт, и в целом по вакансии ты подходишь, что ты ещё и сама в себя веришь, и это даёт дополнительные баллы. То что само собеседование, если оно проходит в целом, есть, наверное, несколько таких правил, как можно его улучшить.
358: То есть можно улыбаться, можно быть уверенным и настроиться каким-то образом, что это не экзамен, это, скорее всего, диалог с твоими будущими коллегами расслабиться, может быть там где то какую-то шуточку вставить.
359: То есть, разрядить атмосферу или так далее. То есть понимать, что, ну, в худшем случае тебе просто не дадут оффер, и ты получишь оффер где-то ещё, или придёшь ещё раз через полгода в эту же самую компанию, например, я сам же, у меня не раз были ситуации.
360: Когда я заваливал 1 собеседование, приходил потом и все, у меня отлично было. Меня брали на работу или, ну, не пришёл в 1 раз, попал в другую компанию и все отлично. Поэтому здесь вот немножечко не хватило, и на это тоже могут обращать внимание. То есть
361: В конечном итоге же нанимающий менеджер или технический специалист, он будет писать фидбэк, он, скорее всего, оценит в целом технический в целом софт, скиллы, и, возможно, он где-то там, в софтскилах напишет, что вот она менторил обучала, с ней было приятно.
362: Общаться, но она там не хватает ей уверенности. То есть, скорее всего, чисто сеньором на проект, где никого больше нет, могут побояться тебя взять. Угу. Скорее всего, скорее предложат проект, где может быть, на грейд ниже, там метла тебе предложат.
363: Или, может быть предложит проект, где есть какой-то старший коллега, который будет тебя курировать или так далее. То есть, ну, могут возникнуть какие-то сомнения из за этого. Ну, после того, как мы закончили с технической частью, у тебя был
364: Вариант задать свои вопросы, и это тоже оценивается, потому что я, например, разделяю вопросы нейтральные красные флаги и те, которые, наоборот, даже вопросом можно как-то выделиться среди других специалистов, ну, красных.
365: Флагов как таковых у тебя не было этого. Если бы ты про зарплату спрашивала или ты проигнорировала полностью то, что я говорил, что это собеседование на конкретный проект, но ты в вопросе ссылалась на то, что ты в курсе, что это общий
366: Собеседование. И так возможно, я знаю, что на других проектах, но это не было вот таким, что точно. Вот, то есть ты это запомнила. Нейтральные вопросы у тебя были, были и вопросы, которые мне понравились, например, про какие-то
367: Не проектной активности. Если в компании культура выстроена таким образом, что это поощряется, то, что ты про это упоминаешь, даёт небольшой такой намёк, что ты будешь, кроме работы, ещё каким-то образом другим влиять на проект. Возможно, у тебя есть цель.
368: Развитие, ты инициативный специалист, раз у тебя есть какие-то там ментинг, конференции и прочие вещи. То есть этим можно даже выделиться, что ты этот вопрос задала косвенно, он подтверждает, что у тебя есть интерес в саморазвитии, и я бы вот
369: Поставил бы галочку, да, и для какого-то нанимающего менеджера, и для технического специалиста это было бы в плюс, но одновременно это было бы и в минус, в компаниях, в которых нужно вот просто 8 часов работать. Ни никакой 2 работы, никакой 2 подработки. Вот.
370: Ты работаешь здесь и сейчас, никакой личной жизни там, конечно бы это сыграло бы в минус, но я не уверен, что в такие компании и надо идти вот это уже личный выбор каждого, то есть где-то если это minutes, то, возможно, и
371: И вам не надо туда. То есть тут уже от многого зависит. То есть, если для тебя это важно, то это нужно упоминать. Таким образом ты сможешь отсеять компании, с которыми у тебя калчер фита какого-то нет, с которыми вам не по пути, поэтому в моём
372: Мне лучше все-таки это упоминать, чем не упоминать. То есть в Нужных компаниях это сыграет в ненужных компаниях. Наоборот, тебе сэкономит время и тебе откажут.