0:00 Вступление. План собеседования 0:55 Информация о компании 2:25 Расскажите о себе, о своем опыте как разработчике 3:45 Почему решили уйти с предыдущего места работы? 4:45 Как вы подняли revenue на 50%? 7:02 Какие кастомные плагины в юнити вы использовали? 9:06 Есть ли опыт работы с Zenject? 11:07 Есть ли опыт использования Firebase? 11:55 Что такое архитектура MVP? 12:40 В чем разница между MVP и MVC 12:52 Есть ли опыт в использовании CI/CD окружения? 13:35 Назовите принципы ООП 13:57 Как вы понимаете принцип инкапсуляции? 14:27 Что такое полиморфизм? 14:57 Является ли использование интерфейсов примером инкапсуляции? 15:20 Что такое интерфейс? 17:11 Назовите 5 принципов SOLID 17:42 Какой принцип SOLID вы чаще всего нарушаете? 18:23 Назовите методы базового класса Object 18:50 Чем List отличается от массива? 20:20 Как называются запросы, фишка языка С# для обращения к листу? 21:53 Какие простые типы данных вы знаете? 23:15 Какие типы коллекций вы знаете? 24:00 Когда нужно использовать словарь, а когда лист? 24:30 Какое ключевое отличие листа от словаря? 25:03 Какие существуют шаблоны проектирования? 26:33 В чем разница между классом и структурой? 27:32 Задача с подвохом на Value type 28:42 Что такое корутина в Unity? 29:20 В чем разница между Async и Корутиной 30:57 Жизненный цикл Monobehaviour 31:54 Зачем используют 2 системы Canvas на 1 сцене? 33:45 Что такое drawcalls и как уменьшить их количество вызовов? 35:33 Какие плохие практики кода вы видели? 36:45 Какой 3D объект Unity съедает меньше всего GPU 37:45 Поделитесь опытом рекламной интеграции 39:32 Расскажите про ваш самый большой провал 41:23 Как вы определяете время на задачу? 41:50 Что вы будете делать если дадут 2 задачи с высоким приоритетом? 42:29 Как вы получали фидбек о своей работе? 43:13 Ваши ожидания по зарплате? 43:34 Вопросы собеседника к интервьюеру 47:08 Итоги
20:01. Лист создаётся изначально на 0 элементов, если создавать просто через new List(); При первом добавлении произойдет расширение до 4 элементов, потом будет происходить увеличение в два раза. private void EnsureCapacity(int min) { ... int num = this._items.Length == 0 ? 4 : this._items.Length * 2; ... }
Около года разрабатываю в юнити, и практически на все вопросы смог ответить, даже иногда информативнее, чем надо) Хотя по коммерческому опыту на джуна то не факт, что возьмут)
Есть слабые места у собеседующего: 1. Некорректно противопоставлять DI-фреймворк внедрению зависимостей через конструктор. DI и DI-фреймворк/контейнер это разные вещи. 2. LINQ работает не с List, а с IEnumerable.
Видно, что собес mock. Заметны принятия совсем простых ответов по типу: 11:40 12:45 На реальном собесе попросили бы раскрыть мысль глубже. Но всё равно полезно. Спасибо за видео!
ООП впросы на мидл собеседовании))) ПРИНЦИПЫ СОЛИД Еще больше выдуманных принципов, которые не понятно к чему применить и кучей трактовок. Когда такое спрашивают, можно смело клеймить студию, джунами инди итд. далее, использование Zenject в мобильных играх, но скорее всего легаси. Вопросы по синтаксису C#?? Какой мидл помнит трактовки и определения и всякий синтаксический сахар, который никто не использует? Что что такое инкапусляция??? Инкапсуляция сокрытие?))))))))))))) что такое сокрытие в C# гугл плиз. собеседуемый джун+, есть много существенных проблем. Опыт про то что слегка ковырял зенжект, после сравнения с автоматом газировкой, я бы заворачивал. ни на одном собесе на мидл - сеньер, такое не спрашивали, вопросы джуновские. В комментариях джуны это подтверждают. Без обид, но кому нибудь будет полезно.
Симметрично. Слушал и офигевал. Парень идет на мидла, а меня с вопросами посложней даже на стажировку гоняли в свое время. Единственное в чем у меня оказался серьезный пробел это DI, но сейчас с высоты опыта ваш комментарий про zenject вызывает у меня 100% одобрение. Такое можно и нужно заворачивать.
Евгений правильно сказал по вопросу о съедании ресурсов графического процессора 3D объектами. Куб меньше памяти съедает, чем сфера, т.к. у него полигонов намного меньше.
Крис Диккинсон. Книга Оптимизация игр в юнити. Автор указывал про сферу. Пруфнуть не могу, книга за 2000км от меня. Буду рад если ошибаюсь и Евгений действительно был прав
@@sulimannxx Действительно. Был неправ. Книга у меня перед глазами) Для истинного понимания, почему так, стоит сделать уточнение. Отрисовка куба занимает меньше ресурсов графического процессора, чем отрисовка сферы из-за числа полигонов. Это что касается мешей. Но графический процессор также обрабатывает физику. И расчет столкновений для сферического коллайдера намного проще, чем кубического. Т.е. вообще идеальные объекты для игры - это куб со сферическим коллайдером.
@@user-ji4iy8db5k К сожалению не прошел Основные вопросы были про серверную часть, клиент-серверная архитектура, как правильнее это все обрабатывать, а я с подобными вещами практически не работал)
Полезный видос. Как минимум для того, чтобы понять, что ты не "лох" и знаешь примерное как этот "Мидл"... При этом считая себя джуном :D Ну и всякие полезные мелочи, которые помогают глубже понять тему есть. Как минимум взгляд на предмет со стороны другого человека, уже полезен. Есть только пару вопросов: Первый - Зачем отказываться от Зенжекта, когда он: а) Экономит время в итоге и упрощает работу с зависимостями на глобальном уровне (даже при самом примитивном его использовании). б) На то, чтобы его внедрить и изучить уже было потрачено куча человекочасов и подобный отказ наоборот скажется отрицательно на времени, вложении сил и, соответственно, денег, чтобы выпилить то, что уже было сделано и переставить проект на старые рельсы. Второй - почему, когда инкапсуляцию объясняют сокрытием, таких разрабов не ставят на место? Ибо сокрытие и инкапсуляция, это не одно и тоже. Сокрытие, это, как максимум, треть от всего понятия инкапсуляции.
Посмотрел интервью 12:00 минут. Странные ощущения сложились об интервьюировании. - Вы знаете Zenject - Да, знаю - Отлично, движемся дальше Погодите, погодите... А где вопросы про что такое Context'ы, про разные способы способы внедрения зависимостей, про уход от монобехов, что такое MоnoKernel и так далее... Аналогичное увидел и с MVP паттерном... В общем слишком лайтово как-то...
Недавно собес проходил, готовился в основном по коду, а в итоге спрашивали по юнити. По ощущениями ответил слабо, но сказали что человек не тот попался, у них был тот, кто мог и по коду в основном спросить =( Пока хз что решили, но я буквально за день освежил память по юнити инструментам и понял что ответил еще хуже чем думал
Я может чего-то не понимаю, но в заголовке написано "собеседование на мидл разработчика", а где, собственно, вопросы непосредственно по C#? то, что было в интервью - это прям поверхность, 0 углубления. Это точно на мидла?
Ты когда был последний раз на собеседовании на мидла? Никого не интересуют знания по C# или юнити углубленно. Все спрашивают про предыдущий опыт и по конкретным технологиям, которые используются на проекте компании. Советую сходить на собес на сеньора. Там вообще не услышишь вопросов по C#
@@sulimannxx Я могу понять почему на позициях сеньора/тимлида не спрашивают про знание языка. На этих позициях решаются бизнес-задачи. Позиция мидла же наоборот предполагает 100% участие в разработке и именно на этой позиции надо знать и понимать функционал язык. Иначе я просто не понимаю, как люди пишут код. Стек используемых технологий это, конечно, хорошо, но это же скорее дополнение. Хотя ладно, возможно, я действительно слишком давно не был на собесах.
@@nyarlukhotep На собесе на джуна, у собеседующего действительно не так много вариантов что бы проверить знания, кроме как штормить по C# и Unity. На мидла открывается пространство для маневра. На сеньора собес скорее напоминает пиздеж по душам + обсуждать инкапсуляцию пол часа. Откуда я это знаю? Сам часто собешусь на сеньора что бы держать руку на пульсе рынка + ученики скидывают записи живых собесов где они подавались на мидла.
@@sulimannxxЕсли уж есть вопросы по C#, то зачем на мидла спрашивать так поверхностно? Или бы вообще уже не спрашивать, или не принимать такие ответы, с которыми и джуна бы не взяли. Или предполагается, что в процессе становления мидлом джун должен резко забыть все что знал до этого?)
Не заменяют, свойство это синтаксический сахар из одного или двух методов: T get_Property() и set_Property(T value). Язык, прямо и косвенно, крайне не рекомендует использовать публичные поля, так как поле - это внутреннее состояние объекта, а выставление поля наружу приводит либо к непредсказуемому поведению внутри методов класса, либо к избыточным проверкам в них. Свойства, в противовес полям, можно валидировать - изначально этот вопрос на собесах был про это, сейчас это формальность, спрашивают не пойми зачем
22:00 сурово про байт)) По этому у нынешних разрабов даже самое простенькая индюшатина, жрет ресурсов как ААА проект :D А потом они говорят, что использовали обычные геймОбджекты, чтобы "добавить производительности", но при этом не замачиваются с типами))) Плюют на байт, создают листы для одного элемента, которые передают в методы "как есть"... и пр.
Чем отличается List от массива? Помимо всего прочего массив может иметь мерность, а лист, увы, нет. И не совсем верно насчет того, что менять размер массива нельзя -- Array.Resize в помощь.
Чушь, прежде чем отсылать кого-то, удосужитесь проверить свои заявления, открываем Array.resize: This method allocates a new array with the specified size, copies elements from the old array to the new one
@@DarkIllusoire Вам не нравится, что Resize создает новый массив? Ну так и методы List создают новые массивы и копируют. Или Вас беспокоит то, что Resize подменяет указатель и при неосторожном использовании Вы можете работать с двумя (или более) массивами одновременно? )) Ну так я и написал, что "не совсем верно, что менять размер нельзя". Функция есть, но то, что она не вполне соответствует Вашим желаниям, не отменяет факта ее существования. ))
Учитывая специфику юнити то MVC в нем не применим. MVP самое то, по сути это идет из трактовок и оба этих паттерна одинаковы по своем природе. Основная суть в том что сущность разделяется на 3 составляющие (Модель данных, Визуал и То что отвечает за логику работы между первым и вторым) а если любишь события тогда юзай MVVM
0:00 Вступление. План собеседования
0:55 Информация о компании
2:25 Расскажите о себе, о своем опыте как разработчике
3:45 Почему решили уйти с предыдущего места работы?
4:45 Как вы подняли revenue на 50%?
7:02 Какие кастомные плагины в юнити вы использовали?
9:06 Есть ли опыт работы с Zenject?
11:07 Есть ли опыт использования Firebase?
11:55 Что такое архитектура MVP?
12:40 В чем разница между MVP и MVC
12:52 Есть ли опыт в использовании CI/CD окружения?
13:35 Назовите принципы ООП
13:57 Как вы понимаете принцип инкапсуляции?
14:27 Что такое полиморфизм?
14:57 Является ли использование интерфейсов примером инкапсуляции?
15:20 Что такое интерфейс?
17:11 Назовите 5 принципов SOLID
17:42 Какой принцип SOLID вы чаще всего нарушаете?
18:23 Назовите методы базового класса Object
18:50 Чем List отличается от массива?
20:20 Как называются запросы, фишка языка С# для обращения к листу?
21:53 Какие простые типы данных вы знаете?
23:15 Какие типы коллекций вы знаете?
24:00 Когда нужно использовать словарь, а когда лист?
24:30 Какое ключевое отличие листа от словаря?
25:03 Какие существуют шаблоны проектирования?
26:33 В чем разница между классом и структурой?
27:32 Задача с подвохом на Value type
28:42 Что такое корутина в Unity?
29:20 В чем разница между Async и Корутиной
30:57 Жизненный цикл Monobehaviour
31:54 Зачем используют 2 системы Canvas на 1 сцене?
33:45 Что такое drawcalls и как уменьшить их количество вызовов?
35:33 Какие плохие практики кода вы видели?
36:45 Какой 3D объект Unity съедает меньше всего GPU
37:45 Поделитесь опытом рекламной интеграции
39:32 Расскажите про ваш самый большой провал
41:23 Как вы определяете время на задачу?
41:50 Что вы будете делать если дадут 2 задачи с высоким приоритетом?
42:29 Как вы получали фидбек о своей работе?
43:13 Ваши ожидания по зарплате?
43:34 Вопросы собеседника к интервьюеру
47:08 Итоги
20:01. Лист создаётся изначально на 0 элементов, если создавать просто через new List();
При первом добавлении произойдет расширение до 4 элементов, потом будет происходить увеличение в два раза.
private void EnsureCapacity(int min)
{
...
int num = this._items.Length == 0 ? 4 : this._items.Length * 2;
...
}
Около года разрабатываю в юнити, и практически на все вопросы смог ответить, даже иногда информативнее, чем надо)
Хотя по коммерческому опыту на джуна то не факт, что возьмут)
Есть слабые места у собеседующего:
1. Некорректно противопоставлять DI-фреймворк внедрению зависимостей через конструктор. DI и DI-фреймворк/контейнер это разные вещи.
2. LINQ работает не с List, а с IEnumerable.
душнила, есть еще более серьезнее слабые места у разработчика, я бы даже сказал у интервьющего тоже есть проблемы.
Видно, что собес mock. Заметны принятия совсем простых ответов по типу:
11:40
12:45
На реальном собесе попросили бы раскрыть мысль глубже.
Но всё равно полезно. Спасибо за видео!
От места к месту. Меня "мидлом" взяли без собеса вообще
@@serser3946 даже без скрининга? Тупо за качество кода на гитхабе?
Интересное получилось интервью и очень полезное, теперь стало немного яснее к чему готовиться на собесе :) спасибо вам
Ничиго себе, так я уже мидл++ всмысле не c++, а типо умный капец
Очень во время)
Попробую сам ответить на вопросы из видоса + ещё пересмотрю твой видос с неуверенным чувачком. Да и вообще все видосы посмотрю у тебя)
ООП впросы на мидл собеседовании)))
ПРИНЦИПЫ СОЛИД
Еще больше выдуманных принципов, которые не понятно к чему применить и кучей трактовок.
Когда такое спрашивают, можно смело клеймить студию, джунами инди итд.
далее, использование Zenject в мобильных играх, но скорее всего легаси.
Вопросы по синтаксису C#?? Какой мидл помнит трактовки и определения и всякий синтаксический сахар, который никто не использует?
Что что такое инкапусляция???
Инкапсуляция сокрытие?)))))))))))))
что такое сокрытие в C# гугл плиз.
собеседуемый джун+, есть много существенных проблем.
Опыт про то что слегка ковырял зенжект, после сравнения с автоматом газировкой, я бы заворачивал.
ни на одном собесе на мидл - сеньер, такое не спрашивали, вопросы джуновские.
В комментариях джуны это подтверждают.
Без обид, но кому нибудь будет полезно.
Согласен с тобой
Когда он сказал 2500 долларов в а*уе сидел
Симметрично. Слушал и офигевал. Парень идет на мидла, а меня с вопросами посложней даже на стажировку гоняли в свое время. Единственное в чем у меня оказался серьезный пробел это DI, но сейчас с высоты опыта ваш комментарий про zenject вызывает у меня 100% одобрение. Такое можно и нужно заворачивать.
Евгений правильно сказал по вопросу о съедании ресурсов графического процессора 3D объектами. Куб меньше памяти съедает, чем сфера, т.к. у него полигонов намного меньше.
Крис Диккинсон. Книга Оптимизация игр в юнити. Автор указывал про сферу. Пруфнуть не могу, книга за 2000км от меня. Буду рад если ошибаюсь и Евгений действительно был прав
@@sulimannxx Действительно. Был неправ. Книга у меня перед глазами)
Для истинного понимания, почему так, стоит сделать уточнение. Отрисовка куба занимает меньше ресурсов графического процессора, чем отрисовка сферы из-за числа полигонов. Это что касается мешей.
Но графический процессор также обрабатывает физику. И расчет столкновений для сферического коллайдера намного проще, чем кубического. Т.е. вообще идеальные объекты для игры - это куб со сферическим коллайдером.
Больше похоже на strong junior.
@@KopylovRoman🔥
@@user-xz5ce7jp8fstrong?
Прям в тему!
Завтра собес на позицию middle!
Спасибо за видео))
Отпишитесь по результатам?
@@user-ji4iy8db5k К сожалению не прошел Основные вопросы были про серверную часть, клиент-серверная архитектура, как правильнее это все обрабатывать, а я с подобными вещами практически не работал)
@@user-ed8lq7vh6c Спасибо за ответ и удачи на следующем собесе)
Полезный видос. Как минимум для того, чтобы понять, что ты не "лох" и знаешь примерное как этот "Мидл"... При этом считая себя джуном :D
Ну и всякие полезные мелочи, которые помогают глубже понять тему есть. Как минимум взгляд на предмет со стороны другого человека, уже полезен.
Есть только пару вопросов:
Первый - Зачем отказываться от Зенжекта, когда он:
а) Экономит время в итоге и упрощает работу с зависимостями на глобальном уровне (даже при самом примитивном его использовании).
б) На то, чтобы его внедрить и изучить уже было потрачено куча человекочасов и подобный отказ наоборот скажется отрицательно на времени, вложении сил и, соответственно, денег, чтобы выпилить то, что уже было сделано и переставить проект на старые рельсы.
Второй - почему, когда инкапсуляцию объясняют сокрытием, таких разрабов не ставят на место? Ибо сокрытие и инкапсуляция, это не одно и тоже. Сокрытие, это, как максимум, треть от всего понятия инкапсуляции.
сокрытие, вообще не про инкапсуляцию, ни в каком виде
2 вопроса:
1) Взяли ли его на работу?
2) Ищите ли вы джунов? Я бы с радостью поработал над таким проектом
Посмотрел интервью 12:00 минут. Странные ощущения сложились об интервьюировании.
- Вы знаете Zenject
- Да, знаю
- Отлично, движемся дальше
Погодите, погодите... А где вопросы про что такое Context'ы, про разные способы способы внедрения зависимостей, про уход от монобехов, что такое MоnoKernel и так далее...
Аналогичное увидел и с MVP паттерном... В общем слишком лайтово как-то...
Недавно собес проходил, готовился в основном по коду, а в итоге спрашивали по юнити. По ощущениями ответил слабо, но сказали что человек не тот попался, у них был тот, кто мог и по коду в основном спросить =(
Пока хз что решили, но я буквально за день освежил память по юнити инструментам и понял что ответил еще хуже чем думал
Запиши вопросы с собеса, выучи на них ответы, на втором собесе ты уже знаешь больше и сильнее. И так по кругу
Я может чего-то не понимаю, но в заголовке написано "собеседование на мидл разработчика", а где, собственно, вопросы непосредственно по C#? то, что было в интервью - это прям поверхность, 0 углубления. Это точно на мидла?
Ты когда был последний раз на собеседовании на мидла? Никого не интересуют знания по C# или юнити углубленно. Все спрашивают про предыдущий опыт и по конкретным технологиям, которые используются на проекте компании. Советую сходить на собес на сеньора. Там вообще не услышишь вопросов по C#
@@sulimannxx Я могу понять почему на позициях сеньора/тимлида не спрашивают про знание языка. На этих позициях решаются бизнес-задачи. Позиция мидла же наоборот предполагает 100% участие в разработке и именно на этой позиции надо знать и понимать функционал язык. Иначе я просто не понимаю, как люди пишут код. Стек используемых технологий это, конечно, хорошо, но это же скорее дополнение. Хотя ладно, возможно, я действительно слишком давно не был на собесах.
@@nyarlukhotep На собесе на джуна, у собеседующего действительно не так много вариантов что бы проверить знания, кроме как штормить по C# и Unity. На мидла открывается пространство для маневра. На сеньора собес скорее напоминает пиздеж по душам + обсуждать инкапсуляцию пол часа. Откуда я это знаю? Сам часто собешусь на сеньора что бы держать руку на пульсе рынка + ученики скидывают записи живых собесов где они подавались на мидла.
@@nyarlukhotep Вот собес на Lead (JS), и там значительная часть - вопросы о языке. "РЕАЛЬНОЕ JS собеседование Frontend TeamLead" с канала "IT Отец"
@@sulimannxxЕсли уж есть вопросы по C#, то зачем на мидла спрашивать так поверхностно? Или бы вообще уже не спрашивать, или не принимать такие ответы, с которыми и джуна бы не взяли. Или предполагается, что в процессе становления мидлом джун должен резко забыть все что знал до этого?)
17:00 зато в интерфейсе можно указывать свойства, которые, вполне себе, заменяют поля...))
Не заменяют, свойство это синтаксический сахар из одного или двух методов: T get_Property() и set_Property(T value). Язык, прямо и косвенно, крайне не рекомендует использовать публичные поля, так как поле - это внутреннее состояние объекта, а выставление поля наружу приводит либо к непредсказуемому поведению внутри методов класса, либо к избыточным проверкам в них. Свойства, в противовес полям, можно валидировать - изначально этот вопрос на собесах был про это, сейчас это формальность, спрашивают не пойми зачем
22:00 сурово про байт))
По этому у нынешних разрабов даже самое простенькая индюшатина, жрет ресурсов как ААА проект :D
А потом они говорят, что использовали обычные геймОбджекты, чтобы "добавить производительности", но при этом не замачиваются с типами))) Плюют на байт, создают листы для одного элемента, которые передают в методы "как есть"... и пр.
На джуна не тянет
Тю та я уже сеньор
Чем отличается List от массива? Помимо всего прочего массив может иметь мерность, а лист, увы, нет.
И не совсем верно насчет того, что менять размер массива нельзя -- Array.Resize в помощь.
Ты прав, спасибо
Чушь, прежде чем отсылать кого-то, удосужитесь проверить свои заявления, открываем Array.resize: This method allocates a new array with the specified size, copies elements from the old array to the new one
@@DarkIllusoire Вы это к чему?
@@alexgetmansky751 к тому, что можно менять размер массива
@@DarkIllusoire Вам не нравится, что Resize создает новый массив? Ну так и методы List создают новые массивы и копируют. Или Вас беспокоит то, что Resize подменяет указатель и при неосторожном использовании Вы можете работать с двумя (или более) массивами одновременно? )) Ну так я и написал, что "не совсем верно, что менять размер нельзя". Функция есть, но то, что она не вполне соответствует Вашим желаниям, не отменяет факта ее существования. ))
и все таки, чем же mvp отличается от mvc?
Контроллер не подразумевает обработку пользовательского ввода(Например, через Input Field)
Учитывая специфику юнити то MVC в нем не применим.
MVP самое то, по сути это идет из трактовок и оба этих паттерна одинаковы по своем природе.
Основная суть в том что сущность разделяется на 3 составляющие (Модель данных, Визуал и То что отвечает за логику работы между первым и вторым)
а если любишь события тогда юзай MVVM
После объяснения инкапсуляции и похвалы наставника выключил и отписался 😂
Люди, кто вводят лутбоксы в игру, должны гореть в аду)