Собеседование Java Middle Senior | Собеседование без конкретных требований от компании | Jetbulb
Vložit
- čas přidán 27. 06. 2024
- Техническое собеседование на позицию Middle/Senior Java Developer.
Иногда приходится проводить или проходить собеседование без каких-либо конкретных требований к кандидату. В таком случае выдвигается общий список требований, без учета специфики проекта или команды.
Такой подход вовсе не означает, что компания плохая или странная. Компания просто хочет найти потенциального сотрудника и усадить его за проект, что будет актуален в момент onboarding.
Вот и у нас точна такая ситуация. Компания ищет сотрудника уровнем от Middle до Senior. Нам предстоит задать вопросы, получить на них ответы и разобраться какой шеврон можно присудить кандидату.
Погнали!
Программа
00:00 Описание кандидата и требований
03:57 Про наш Тренинг-центр iPrody
07:52 Вопросы о базах данных
16:16 Вопросы о масштабировании
27:43 Вопросы о многопоточности
35:08 Вопросы о развертывании сервисов
40:05 Вопросы о микросервисах
46:50 Вопросы про архитектуру и дизайн
53:43 Выводы
Получи реальный опыт решения коммерческих задач в Agile команде
до 6 человек iprody.com/
Запись на обучение и собеседование:
iprody.com/interview
t.me/iPrody_Online
Мы в социальных сетях:
t.me/jetbulb
/ jetbulb
Супер! Побольше такого контента! ❤
Вопросы для Джуниор в 2023 году))
На стажера в 2024)
Что вы несёте
испугался?
@@user-nl2em4jm3e
Класс, спасибо!
Красавчик, на глазах скилл растет, как в съемке, так и в программировании, очень хорошее видео, много очень полезных нюансов, и в глубь не лез, и в то же время не по верхам👍
P.S. только стоит немножко разобраться с блокировками БД:
1) optiistic locks - это row versioning и последующая проверка версии при попытке коммита - она часто реализуется прямо на уровне приложения
2) pessimistic locks как раз те, о которых ты перед этим говорил, только их вообще больше:
- shared: S(for rows, pages and tables),
- exclusive: X(for rows, pages and tables),
- update: U(for rows and pages only) - она для предотвращения простых deadlocks
- и три intent locks: IS, IX, SIX(for tables only) - они блокируют нижестоящий в иерархии ресурс (это позволяет осуществить проверку такой блокировки перед осуществлением и предотвратить преждевременную блокировку более высокого уровня)
Они осуществляются на уровне БД, и DB Engine сам решает какую применить в той или иной транзакции, если явно не указано иное
1) версионирование не единственный механизм, самый базовый механизм, это когда фремворк содержит два экземпляра строки таблицы из БД, один для правки, второй неизменный, при сохранении выполняется блокировка, далее проверяется равенство всех полей неизменной строки и строки в БД, если значения в полях совпадают, то выполняется update, если не совпадают, то выбрасывается ошибка.
2) механизмы блокирования и оптимистическая/пессимистическая блокировка это совершенно разные вещи, пессимистическая блокировка - ресурс блокируется для изменений сразу, как только пользователь его запросил (предполагается, что пользователь будет его изменять), оптимистическая - пользователь запросил ресурс, что-то с ним поделал и только непосредственно в момент попытки сохранить сделанные изменения ресурс блокируется.
Что касается режимов и уровней блокировки, говорить о них в отрыве от конкретной РСУБД бессмысленно, глобально РСУБД подразделяются на два вида - блокировочники и версионники, в первом варианте читатели блокируют писателей, во втором нет, в версионниках эксклюзивная блокировка не означает, что данные нельзя читать и еще очень много нюансов))
Спасибо, за подробное объяснение. Я тоже заметил, что в видео все блокировки в кучу свалили, так же как и дополнительные аномалии транзакций.
@@user-pq1mq8gi4pух ты, неплохо) судя по комменту, его писал опытный программист, плотно работающий с компанией Oracle, но в целом дельные замечания кстати, спасибо. Нечасто люди такой квалификации встречаются на просторах CZcams, да и еще под таким видео) Мое почтение)
+ за вопросы и ++ за Lineage - эх времена были:)
Спасибо Макс!
Вот так я и попала на проект с AWS AppSync, блин 😂😂😂
А за видео как всегда лайк
Отлично затронули тему Docker'a и вопросов по нему. Было бы круто посветить отдельный видос с разобором вопросов и ответов👍
Docker*
Есть такой нюанс/проблема у разных интервьюеров: они сопоставляют определённые знания и уровень разработчика отталкиваясь не от бэкграунда и опыта человека, а от того, что по их мнению нужно знать. И в этом видео полно таких примеров.
Хотя в самом начале у нас есть оговорка, что конкретных требований нет, но нужно прощупать кандидата, тем не менее, начинается с исследования знаний о базах данных.
Приведу просто в пример себя: я довольно опытный разработчик в областях секьюрности и интеграции. У меня за мой опыт есть лишь какой-то минимальный контакт с персистентностью. Все мои знания в этом вопросе отсылают скорее к периоду учёбы в университете, который я закончил 10 лет назад.
Я бы с радостью поговорил бы про транзакциональность в процессах интеграции, если бы мы развили эту тему. Но, скорее всего вы сделаете свои выводы на основе вопросов по БД) Мой опыт собеседований, показывает, что именно так и бывает.
Таймзоны меняются на 15 минут? Очень интересно:)))
Было бы ещё хорошо услышать когда идёт речь о шаблонах не только про решение. Но и про проблему которую решает этот шаблон. Просто про ивент сорсинг я услышал только решение.
Стратегию можно мапой со спрингом удобно делать, в таком случае не нужно if else городить
Любой ассоциативный массив 🤷♂
Спасибо
Огнищеееее
Сливаемся и сливаемся)
thanks
Макс, можешь поподробнее о volatile? Встречал на одном курсе информацию, что не в кэше дело, т.к. процессор построен так, что кэш распространяется между потоками, и volatile это high-level абстракция, не имеющяя отношение к низкоуровневому управлению кэшем и процессором. А проблема в том, что компилятор не знает о том, что ресурс задействован в нескольких потоках, поэтому во время компиляции в байткод, происходит оптимизация кода, и volatile гарантирут ПОСЛЕДОВАТЕЛЬНОСТЬ выполнения кода, согласно тому, как этот код написан программистом, и не позваляет компилятору его оптимизировать так, что теряется каждоразовая проверка состояния ресурса (на пример while(sharedObject) {} оптимизируется компилятором так, чтобы проверка состояния sharedObject была только один раз, и не повторялась каждый раз во время петли). А везде только информация о кэше... Что думаешь на этот счёт?
вау, интересно
Оставил свой самый крутой комментарий)
Мой Like #1000
А что не так с escape analyse в первом вопросе?
Мне кажется нельзя запустить несколько имейджей в одном контейнере, скорее написать докер файл в котором будут и база данных и все сервисы
можно, но это бессмысленно, так как ты будешь видеть только pod1 и ничего не узнаешь о том, живы ли другие запущенные в данном контейнере сервисы
Вот бы ещё пояснение, как с query plan работать. Я один раз сказал, что для исследования неэффективного запроса надо смотреть план, а когда мне его тут же предоставили, я обосрался.
😆 Бывает)
Ну вот вопрос который задавал выше, что не так с запросом escape analyse и смотреть сколько шагов сделал каждый запрос?
@@TheDiablo461 Для начала нужно понимать, что все єто зависит от конкретной БД(Mysql, oracle.....). Минимально - у каждого єлемента плана есть свой вес, также в плане можно посмотреть какой вид(бьістрьій-медленньій) чтения/поиска таблицьі/индекса используется, каким образом связьіваютсяя єти данньіе, сортируются и т.д. и т.п. Ну и не стоит забьівать про такие вещи как Hints, про факт того, что после прослойки jdbc оптимизатором может сформироваться абсолютно другой запрос, про сбор статитстики в БД(когда и зачем) и возможно сбор єтой статистики значительно повлияет на скорость работьі базьі/запроса. Помимо єтого может стоит снять отчет о работе непосредственно с самой БД в которой указаньі кол-во чтений/записей на диск/память, в какой момент происходит проблема, насколько загружен процессор и чем.... В общем и целом єто работа DBA, но нужно знать, что такие ньюансьі существуют.
Важные аспекты Mono и Flux, которые ответят на вопрос работал ли человек с реактивщиной: какой тип publisher является Mono и Flux (hot or cold), сколько елементов оборачивается во Flux?
лайк за Spell SInger )
32:30 так какая коллекция в итоге подходящая когда много записей?
lost update это нестандартная?))
Смотря под каким углом смотреть 😏
Лично для меня базовая
Deisgn patterns best book for Java -> "Effective Java" by Addison Wesley
очень affordable
так надоела эта гнусная документация для хардкорщиков , посмотрюка зодорного Макса!
1.Если не прошел live coding єто отказ на продолжение?
2. Скільки не вчив і не переписував Патерни не можу запам'ятати
Патерни це про досвід, не про памʼять
А ось лайфкодінг це інше. Тут пройшов не пройшов залежить від компанії. Як на мене, то ЛайфКодінг потрібен лише для виявлення навичок з вирішення завдань. Але усе пізнається в поповненні
@@Jetbulb як прокачати навички з вирішення задач на проекті?
@@caffeinejavacode1475просити вирішувати проблеми у проекті 🙃.
Зазвичай це входить в твої обов'язки)) Тобто просто працювати і прокачувати
Тут важно отменить про джунов то, что лишь немногие могут чем-то похвастаться, (но они день-ночь развиваются и сильно потеют), что на счёт всех остальных - почти ничего не знают или вообще не знают.
Як вчасно, завтра співбесіда на мідл позицію, дякую за контент
Аналогичино, сейчас готовлюсь к собесам на мидла. Хорошее видео.
🇺🇦🇺🇦🇺🇦
Тільки вперед 🇺🇦
прошел?
@@u_n_d_e_r_s_c_o_r_e_d Та співбесіда відмінилась, але минулого тижня була інша і я отримав оффер)
Почти всё хорошо, но слишком много воды и абстрактых примеров/рассуждений, которое отводят внимание от вопроса
Русский военный корабль в левом верхнем углу. 🤣