Собеседование на тестировщика ПО (Junior QA)

Подготовка к собеседованию на QA Engineer

Транскрипция видео:

  • [музыка] ну тогда стартуем расскажи немножко о себе о своем предыдущем опыте почему в тестировании пошел и чего ты хочешь сегодня [музыка] [музыка] [музыка] видео [музыка] [музыка] ты уже устроился ты уже работаешь но еще хочешь как-то свой уровень и дополнительно ладно хорошо ну давай тогда начнем с основ с того как ты понимаешь в принципе профессию и чаще всего мы можем в принципе начать с самых базовых вещей даже не про профессию а в принципе про ай ти до часто задают вопросы например и ты можешь рассказать как работает

    00:00:00 - 00:01:55

  • интернет интернет работает не на философии так что может нас технической стороны описать ну хотя бы в общем какой принцип используется какой протокол [музыка] [музыка] [музыка] [музыка] технически [музыка] а вот если мы говорим запрос ответ есть состоит запрос так в зависимости от того что он над общей что еще представлял состоит из какого-то состоит из какого-то и уже по-моему называется [музыка] это не важно хорошо а в ответ от сервера что приходит наклеен мой запрос то что пользователь не видит

    00:02:12 - 00:04:32

  • непосредственно мой запрос прошлые диска страницу мы ссылаемся хорошо а если не найдено страницы которые ты запрашивает информацию что приходит и найдено страница ну вот информация не найден это запроса правил а что-то пошло не так что может пойти не так и как это мы обычно можем отличить а [музыка] если что то не так с сервером топ какая ошибка приходит 500 хорошо хорошо в принципе да так оно и есть ладно замечательно тогда давай поговорим уже про тестирование ты самый тестируешь сейчас какого рода

    00:04:22 - 00:06:04

  • приложения мобильные гибридные нативные это больше [музыка] то есть ты как тестирование бэг-энда выполняешь сейчас понятно хорошо нокий давай тогда абстрагируемся от бренда и посмотрим на все сверху что в твоем понимании тестирования знаешь что это какой-либо определение [музыка] известно [музыка] сейчас [музыка] давай формулируй тестирование является фактически результаты сопоставляется с ожидаемым для выявления каких-то дефектов тестирование это улучшение продукта [музыка] даты низко рассказал про выявление

    00:05:42 - 00:07:40

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

    00:07:16 - 00:08:44

  • она не только прямо влиять наш продукт виде всяких отчетов багрепорт of и так далее но и в целом помогает менеджменту допустим понять на каком уровне качества наше приложение например классический вопрос менеджмент я не знаю задавал тебе его кто-то на данный момент или еще нет но звучит так можем ли мы релизиться прямо сейчас и если ты менеджеру ответишь у нас 4 дефекта это не будет вопрос на скажи да хорошо но можем ли мы релизиться прямо сейчас или как тестировщик как правило можешь предоставить ему информацию в

    00:07:59 - 00:09:20

  • общем целом окажется продукта о рисках которые возникла сейчас или если релиз будь там через неделю через месяц или через три часа вот то есть цели тестирования и еще есть там некоторые цели то есть все таки здесь рекомендуется чуть чуть пошире смотреть на этот вопрос помимо поиска баков есть еще хорошо какие-то знаешь типы тестирования может быть классификации в тестирования [музыка] тестирования хорош что когда-нибудь и про тестирование локализации слышал вот например например доп локализация в

    00:08:40 - 00:10:04

  • рамках локализации что мы тестируем допустим продуктов на какой-то определенный регион и для этого региона соответственно лежи какая-то своя культура или что то еще но известен в первую очередь там корректно символов если не какой-то специфический вид корректность перевода [музыка] как-то сказать вашим адаптировать но как мы можем адаптировать кроме текста да то есть что у нас часто бывает когда мы переключаемся с одного региона на другой помимо того что язык разных до [музыка] просто реальную жизнь вполне отвлечемся

    00:09:56 - 00:11:28

  • отойти вообще вот бывает покупаешь что-то и смотришь на ярлычок а там не только есть русский формат или европейский но еще какой-то это что такое например ну да локализация ну вот примеры жизни эти могу сказать что если ты будешь тестировать магазин одежды или обуви то есть вероятность что при переключении локализации будет размерность меняться потому что в америке принято один формат размеров японии другой в европе 3 а еще кроме размеров допустим вот есть имперская система да у нас измерение метрическая надо вот если ты допустим

    00:10:58 - 00:12:44

  • захочешь какие-то стройматериалы продавать в америке европейские очень часто кажется что требуется перевод в их единицы измерения а еще такая же ситуация с температурой цельсия фаренгейт си и еще самое часто распространяемая ситуации это дата формат даты я не знаю встречался и или нет но на западе принято сначала писать месяца потом день она сначала день а потом месяц а потом год вот и соответственно при переключении локали формат отображения даты и времени допьем и то есть у нас 24 часа использоваться у них 12

    00:11:54 - 00:13:21

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

    00:12:37 - 00:14:26

  • не знает как должно работать приложение [музыка] хорошо а вот допустим когда тестируешь какими тестируешь [музыка] здесь у нас сказать что [музыка] но на самом деле вопрос тестеры серым ящиком это довольно такой потный спорный вопрос этого серого ящик изначально не было большом количестве литературы он позже появился у некоторых авторов и можно долго философствовать что такое серый ящик на сколько надо знать строение системы не знать но как правило грань проходит по тому что покрывается тестами да то есть когда мы тестируем

    00:14:40 - 00:16:21

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

    00:15:53 - 00:17:14

  • про-уровня тестирования знает что-нибудь это вот модульный [музыка] [музыка] интеграцию нет с тинга модульной это стерн и от одно и то же на самом деле их обычно выделяют 3 или 4 в зависимости от источников то есть модульная или unit тестирование одно и то же интеграционная системная это как говорят в интернете это база еще иногда добавляет приемочной тестирование иногда нет потому что очень сложно объяснить почему приемочная тестирование это отдельный уровень хотя на самом деле это тоже системное просто

    00:16:35 - 00:18:04

  • в определенных обстоятельствах которые включается а разницу может назвать между допустим модульным интеграционным приемочным [музыка] в принципе да хорошо про техники дизайна используем [музыка] [музыка] ну давай попробуем представить ситуацию как бы ты бы смог применить например представим что ты и тестируешь не backend а у тебя есть веб-сайт и там есть регистрация в ней есть поле логина более пароль 1 вот у тебя допустим есть поле логина как ты к более логина можешь применить технику эквивалентного разбиения и

    00:17:44 - 00:19:34

  • граничное значение разбиение сначала [музыка] есть [музыка] так есть они ничего [музыка] логин ну значит этого users еще нету мышь про регистрацию говорим да вот у нас есть правило определенное с вот так как в этом случае работает техника эквивалентного разбиение что чему эквивалентно ты говоришь есть разные подходы да есть нормальный юзер с нормальными каретами есть users каретами которые не должны подойти есть еще какие то каким образом применяется класс эквивалентности тот повторил то же сам это сказал 1 раз

    00:19:47 - 00:21:29

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

    00:21:56 - 00:23:21

  • валентности выражаются и какой-то чем [музыка] я тут конечное значение ниже может быть может быть про граничное значение можно отдельным тазик валентность это обычно мы сокращаем количество тестов для проверки в данном случае как я сказал поле ввода при регистрации и что мы можем здесь делать у нас например есть поле воды там установлены правила что имя юзер может состоять только из букв например соответственно соответствии с подходом эквивалентного разделения мы при тестировании можем использовать

    00:22:51 - 00:24:25

  • минимальный набор букв который у нас установлен и при этом мы допускаем что все буквы фаль это будут эквивалентны друг другу и у нас нет необходимости все тестировать понимаешь то есть мы устанавливаем правила что должны быть буквенные символы но это не значит что мы должны протестировать все буквы какие существуют в данном увозите да пусть нам достаточно проверить только несколько мы вернулись до дыр нет отвалился все хорошо так по поводу close от насти вот когда мы используем какой-то тип символов мы можем считать

    00:23:42 - 00:25:09

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

    00:24:35 - 00:25:52

  • анализ граничных значений давай поговорим до в разрезе того же поле ввода вот у нас есть поле ввода и например у нас есть к нему требования по длине какие то минимально значит максимально вот здесь можно анализа граничных значений какой то придумать ну например минимальную логин максимально 51 51 [музыка] сколько это все проверки шла [музыка] это 607 получилось 52 брать зачем-то а зачем так много вот допустим давай верхняя граница у нас есть интервал положительных значений от 5 до 50 вот у нас есть верхняя граница 50 ты говоришь

    00:25:14 - 00:27:05

  • нужно 4950 51 и даже можно 52 зачем так много уже может быть логическая ошибка не по-любому выйдет также логично ширина 52 она тоже выйдет и смысла get но если есть время много на тестирования если есть если из много на тестирование времени то действительно можно на всякий случай проверить много чего но если мы все-таки говорим в рамках подхода до определенного то мы все таки стараемся минимизировать количество этих сценариев поэтому нам на самом деле достаточно как правило либо 4 либо 5 сценарий в

    00:26:38 - 00:27:51

  • зависимости от того кто какие книжки читают то есть 5 сценарий это любое произвольное значение изнутри интервала а остальные четыре это ближайшее внутри границ например если мы говорим 5-50 5 это уже минимальное значение внутри границ 4 это ближайшее значение смени к минимальной границы а с другой стороны будет 5 51 5 это внутри 50 это внутри границ 51 снаружи все то есть если мы проверяем что самое крайнее значение внутри интервала правильно работает и самое близкое снаружи тоже правильно отрабатывает то мы уверены что границы

    00:27:30 - 00:29:01

  • работать так то конечно мы можем там новый кейс мы хотим их сократить [музыка] времени кто-то тут надо конечно захотеть все главное что вообще откинуть и вот тех тестов целом достаточно будет да да да вот просто мужик сокращаем уже середина и значение тоже используется пусть 45 25 4950 ну вот как я уже заметил в зависимости от того какие то книжки читаешь где-то написано четко что границы достаточно протестировать но из своего опыта тестирования и из некоторых других источников выходит что желательно взять

    00:28:15 - 00:29:38

  • любое произвольное значение из интервала внутри потому что иногда такое бывает что сами границы работает интервал нет ну так это как-то программируется не очень хорошо если бы 4 либо взять это обычно правильно свет вот а так то да хорошо о техники в принципе нормально поговорили может рассказать что-нибудь про смог цените и регрессом тестирование что это за понятие о чем они [музыка] не смог testing это такое поверхностные воды цените [музыка] [музыка] но если прям совсем сверху стрелять туда что то похоже вот но допустим про смолк

    00:28:56 - 00:30:50

  • в каком случае мы его проводим вот у тебя из спринт у тебя есть релиз когда-то будет там в конце спринта есть ежедневные какие-то может быть релиза может быть утихнет не знаю вот так как у тебя будет в этом случае выглядит смог можно [музыка] [музыка] [музыка] проводить этот смог правильно да цените ты говоришь тоже в твоем понимании как часто будешь проводить и что-то больше следует ценить их более [музыка] [музыка] я считаю что нам нужно время занимает интерес ну цените это в принципе есть несколько подходов носом

    00:30:17 - 00:32:10

  • распространенное это когда мы относимся к цените как тестирование в глубь то есть у нас есть какой-то определенный функционал который мы пилим вот конкретно спринте допустим что-то свежее и мы когда пройдет станете тестирование мы углубляемся вот истерия конкретной фичей конкретные новой функциональности вот соответственно мы может сказать что тестируемые регулярно нельзя раз два в три дня может быть каждый день просто мы тестируем конкретно этом задачу которая ставит но в отличие от смолко мы не тестируем все

    00:32:03 - 00:33:13

  • остальное приложение а концентрируемся на конкретном кусочке и капаем углу вот а regression ты как часто будешь проводить и в каком моменте в твоем спринте может быть [музыка] [музыка] вот ты говоришь мы проходимся по всей системе а чем тогда этот смог отличается [музыка] [музыка] хорошо вот представьте т1 тестировщик на проекте у тебя 1000 тест кейсов в регрессии у тебя будет возможность физическая проходить все что у тебя есть что будешь делать [музыка] максим [музыка] хорошо хорошо это очень здравая мысль

    00:32:38 - 00:34:26

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

    00:34:51 - 00:36:46

  • тестирования [музыка] в четверть у нас здесь там дискрипшн задачи у нас есть какой-то ожидаемый результат и статус этого достаточно на эту моих разница но 400 мужчин допустим я потрясти сам провел керамика резины мне надо на следующий день 3 с луком и лучшие христом почему лучше нам нет [музыка] ну а представь себе ты попал в проект в новой для тебя он огромный а там сиона и чек-листа и там такой чеклисте по проверить что корзине в корзину добавляются товары а это какое-то инопланетное вообще интернет-магазин для

    00:36:20 - 00:37:59

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

    00:37:45 - 00:38:57

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

    00:38:19 - 00:39:41

  • [музыка] он не будет [музыка] [музыка] ну да да правильно то есть размер проект еще важно его текущее состояние временное то есть принципе как обе системы сложно не было если она на ранних этапах и если допустим запланированная mvp и который будет через 2 месяца то тоже не смысла расписывать много тайцев потому что она может просто не взлететь и вся хитрая задумка никому не понадобится твоей чем точнее тайские циником и не нужны будут или если так получается что ты знаешь что будешь единством тестировщиком и

    00:39:02 - 00:40:16

  • несмотря на сложность такая систему понял ты можешь пользоваться одними чек-листами а если ты знаешь что команда скажите будет расширяться то это можно будет всё равно потом переделывать и переписка хорошо багрепорт из чего обычно состоит и давай про это и про жизни цикл [музыка] description то есть когда мы ожидаем результат его глобальность причине и какие-то комментарии к нему это более знаете такой не стали зеленой метрика я бы сказал для отслеживания принципе достаточно верно говоришь есть есть поля который

    00:40:23 - 00:41:54

  • можно назвать обязательными есть поля которые могут прям сильно отличаться от проекта проект от настройки вот допустим про глобальность я в жизни никогда не слышала что такое глобальность это очень интересно надо будет почитать и такой системы пользоваться здесь глобальность [музыка] вот там есть там есть что у нас обычно если верить и есть priority либо бывает просто прием да вот вот такие слова уже лучше использовать на глобальную цифрами я напугался [музыка] сне 2 коршун колоссальные а какой при

    00:42:06 - 00:43:13

  • этом параметр возрастает а вот параметр да по которым вы оцениваете у вас один в бак треккинговой системе или их несколько вот допустим приоритет и все или там есть приоритеты есть серьезность вот ты можешь назвать разницу между приоритетом и серьезности и [музыка] а [музыка] то может привести пример когда высокий приоритет они скасси верить или наоборот [музыка] [музыка] хорошо нормально ты старался [музыка] нет я не спорю до вернулся хорошо и про жизни цикла багрепорт поговорим вот ты создал багрепорт допустим представим

    00:42:54 - 00:44:48

  • идеальную ситуацию до когда ничего странного не начало происходить вот сама обычно workflow можешь описать что происходит пустой кпсс был хорошо разработки на исправление хорошо вот по поводу реворка вот ты завел бак его вроде как починили отправить н revoke ты проверяешь а он не по чину что сделаешь в общем повесить [музыка] по годится что вот представь себе что вы ты убедился все верно ты проверил что у вас и окружение совпадают 0 это максимальный совпадает и код свежий завидной лет который ты тестируешь и все

    00:45:19 - 00:46:52

  • правильно вот а он тебе говорит но вешу меня не воспроизводится время воспроизводится анри там не нет и вот вы друг другу его пинаете этот бак до какого-то момента производится у него по хедж-на в какой момент [музыка] . у [музыка] него очень много задач таких программистских и он такой да я уже дали новую фичу мы пили уж а ты ко мне с этим старым непонятно чем подходишь опять ты мне вот это вот я месяц назад запилил я уже забыл как я писал у меня все работает мне просто не хочется и не отойду от

    00:47:11 - 00:48:51

  • [музыка] темы же спросит говорит о насколько этот баг вообще опасен с представим себе что ты сказал допустим типа но это типа это минор да там где по не важно ну там что-то не очень важно как тебе кажется ты же информацию представляешь а он тебе говорит ну еще давайте его закроем да и все что бы ждет ну смотреть ты не сдашься да если вдруг тебя скажут закрою для тебя это важно но бренд и category но в принципе такой подход конечно может существовать но обычно все-таки до какого-то момента тестировщик можно педалировать ситуация

    00:48:32 - 00:50:03

  • потом все таки как бы ты доносишь информацию о качестве ты как бы не можешь со всеми и ругаться вот и если уж менеджер который отвечает в конце перед заказчиком или перед другим менеджером более 1 к поставили зависит от того компания на себя программа пишет или на заказ да за ним последнее слово просто твоя задача будет оставить как можно больше доказательств того что ты пытался объяснить доказать и в комментариях к тому же ticket а ты можешь спокойно дописать типа вот менеджер такой-то решил так

    00:50:13 - 00:51:21

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

    00:50:46 - 00:52:03

  • говорил про скрам про комбан а что такое в принципе отжарил более гибко более этим чувакам изменением гибкая манифест церемонии церемонии не помочь там смотри там есть 12 принципов которые и есть четыре мудрости так как назовем 4 вывода на которые 12 принципы поэтому и ты можешь ознакомиться потом позже вот я сейчас не помню что да ладно я могу это понять потому что отжала это не методология отжал это набор принципов а вот как раз таки скрам комбан вот это вот методологии вот хорошо бостром и можешь основные

    00:51:55 - 00:53:38

  • какие-то назвать артефакты то есть что такое планирование допустим не снять что в начале спринта вы делаете у нас идет начала спринта у нас начинается планирование ладно это другие процессы это все-таки более низкого уровня высокого уровня скрам если назначали планирование правильно сказал потом идет спринт в течение спринта выполняется задачи в конце спринта что делается в конце и выясняются какие-то слабые и сильные стороны [музыка] смогли то с какими сложностями вы сколько [музыка] [музыка] там и баги бывает задачу на разработку

    00:53:18 - 00:54:54

  • какие-то не успели сделать их назад закидывают а кроме ретроспектива одежды [музыка] хорошо хорошо а про оценку в чем мы можем оценивать задачи смотри вот я и спрашиваю в чем можно оценивать что у нас измерения мы можем его днях в час ardo a можем в этих стори поинтов вот я потом спрашиваю я обычно в чем-то одном измеряют изредка когда говорят в два очка это два дня ну иногда в них проектах так делают конечно ну это как бы нарушение все эти философии но неважно ну вот вот это и был вопрос как рассказал одну 2 дня 2 ч там два

    00:55:00 - 00:56:24

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

    00:56:31 - 00:57:53

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

    00:57:11 - 00:58:15

  • клиент сервер http протокол или просите во взаимодействии пакеты данных передадут как ты говорил там провода по ним переходит это все то есть на уровне железу вот и чаще всего конечно хотят услышать правые взаимодействия потому что но если тебя не на сисадмина берут то важно вот что бы ты умел с сервером общаться и понимал что такое 44 502 или 200 вот и [музыка] в принципе по детству документации на так как прежде есть опыт и хорошо ответил по методологии ну нормально тоже то есть в принципе на там стройка

    00:57:45 - 00:59:04

  • джуниора вполне себе но я думаю если ты поработаешь еще там месяц [музыка] вот если ты хочешь узнать путь ближайшие два метла допустим его таять и рекомендую ну ты можешь еще пару месяцев поработать с текущими технологиями если тебе нравится big bag and earn a тестируешь это в принципе востребованная вещь ну конечно было бы круто если ты следующие полгода смог бы допустим протестировать веб-приложения и код который полностью до собираются и мобилки нативные приложения или гибрид какой-то из этих

    00:58:25 - 00:59:37

  • двух частей и вот после этого тебе прям будет намного проще двигаться и так далее - конечно ситуация такая на рынке своеобразная но тем не менее сейчас [музыка] секундочку тогда запись надо остановлю потому что на обсудить общие вещи и править и подробнее поговорим [музыка]

    00:59:07 - 01:00:05

Менторы

Специалисты своей области, которые смогут помочь вам

  • Нигма Нурия
    Нигма Нурия

    Middle .Net Developer

  • Сущенко Татьяна
    Сущенко Татьяна

    Senior Product Manager

  • Гудков Денис
    Гудков Денис

    Middle Python Developer

  • Курочкин Константин
    Курочкин Константин

    Ведущий программист

  • Гудман Макс
    Гудман Макс

    Backend Software Engineer (PHP)

  • Гребенкин Антон
    Гребенкин Антон

    Senior .NET/C# developer

  • Ахназаров Фёдор
    Ахназаров Фёдор

    Middle DevOps Engineer | Tbilisi, Georgia

  • Шорохов Дмитрий
    Шорохов Дмитрий

    Middle C# .NET

  • Жуков Александр
    Жуков Александр

    Senior PHP-разработчик

  • Мазикин Павел
    Мазикин Павел

    Middle python developer

© 2024 HireGuru. Сделано в Санкт-Петербурге с hireguru.ru