Вопросы с собеседований
Неделю назад проходил первый этап собеседования на проект крупного банка. Держите новую пачку вопросов.
— Collection – основные интерфейсы
— Зачем нужно красно-черное дерево в Джаве
— Есть одна таблица в БД и три сущности. Как осуществить маппинг с помощью JPA/Hibernate
— Уровни кэширования в Hibernate. Чем они отличаются
— Какие есть сторонние решения для кэширования
— Рассказать про Inversion of Control Containers и Dependency Injection
— Spring – какие есть скоупы и для чего используются
— TDD и BDD
— Для чего нужен Mockito
— Отличие Mock от Spy
— Этапы сборки проекта
Присылайте задачи и вопросы с собеседований в личку, буду публиковать @zybkin
Неделю назад проходил первый этап собеседования на проект крупного банка. Держите новую пачку вопросов.
— Collection – основные интерфейсы
— Зачем нужно красно-черное дерево в Джаве
— Есть одна таблица в БД и три сущности. Как осуществить маппинг с помощью JPA/Hibernate
— Уровни кэширования в Hibernate. Чем они отличаются
— Какие есть сторонние решения для кэширования
— Рассказать про Inversion of Control Containers и Dependency Injection
— Spring – какие есть скоупы и для чего используются
— TDD и BDD
— Для чего нужен Mockito
— Отличие Mock от Spy
— Этапы сборки проекта
Присылайте задачи и вопросы с собеседований в личку, буду публиковать @zybkin
Дикие имена
Джава разрешает разработчикам давать нечитаемые имена переменным. По соглашениям такие имена нельзя давать методам, переменным или классам, но код будет компилироваться.
Примеры компилирующихся имен:
normname
НормИмя
$NORM2Name
_tozheNorm3Name
__EtoTozheNormName$
А эти имена не скомпилируются:
3DCircleClass
takSebe@Name
*$coffee
public
Три правила нейминга переменных, которые нужно знать:
— имена должны начинаться с буквы, знака нижнего подчеркивания «_» или знака доллара «$»;
— в имени могут присутствовать цифры;
— нельзя использовать в качестве имени зарезервированные слова. Например: abstract, private, static.
Джава разрешает разработчикам давать нечитаемые имена переменным. По соглашениям такие имена нельзя давать методам, переменным или классам, но код будет компилироваться.
Примеры компилирующихся имен:
normname
НормИмя
$NORM2Name
_tozheNorm3Name
__EtoTozheNormName$
А эти имена не скомпилируются:
3DCircleClass
takSebe@Name
*$coffee
public
Три правила нейминга переменных, которые нужно знать:
— имена должны начинаться с буквы, знака нижнего подчеркивания «_» или знака доллара «$»;
— в имени могут присутствовать цифры;
— нельзя использовать в качестве имени зарезервированные слова. Например: abstract, private, static.
Ситуация. Вы руководитель проекта
Ваша команда работала над большой функциональностью в течение трех месяцев. Релиз через 2 недели, но вы не готовы к нему из-за ряда ошибок. Сейчас нет времени проводить анализ ошибок, нужно принимать решение. Возможные варианты:
1. Попытаться договориться с заказчиком и сдвинуть сроки на 2 месяца. По расчетам их достаточно для полной доработки.
2. Добавить ресурсов – взять разработчиков и тестировщиков из другой команды. И большей командой попробовать добить проект в срок.
3. Уменьшить функциональность. Убрать часть, которая еще не реализована, и выкатить только ту, которая готова и точно работает.
Ваша команда работала над большой функциональностью в течение трех месяцев. Релиз через 2 недели, но вы не готовы к нему из-за ряда ошибок. Сейчас нет времени проводить анализ ошибок, нужно принимать решение. Возможные варианты:
1. Попытаться договориться с заказчиком и сдвинуть сроки на 2 месяца. По расчетам их достаточно для полной доработки.
2. Добавить ресурсов – взять разработчиков и тестировщиков из другой команды. И большей командой попробовать добить проект в срок.
3. Уменьшить функциональность. Убрать часть, которая еще не реализована, и выкатить только ту, которая готова и точно работает.
Java Developer via @vote
Как вы поступите?
anonymous poll
Уменьшу функционал – 354
👍👍👍👍👍👍👍 68%
Сдвину сроки – 82
👍👍 16%
Добавлю ресурсов – 82
👍👍 16%
👥 518 people voted so far.
anonymous poll
Уменьшу функционал – 354
👍👍👍👍👍👍👍 68%
Сдвину сроки – 82
👍👍 16%
Добавлю ресурсов – 82
👍👍 16%
👥 518 people voted so far.
Продукт vs. Проект
Есть продуктовая разработка, и есть проектная разработка. В одной важно уметь смотреть в будущее и брать ответственность за конечный продукт. В другой – быстро работать и переключаться между задачами. В обеих разработках ценится работа в команде и профессионализм в целом.
Есть продуктовая разработка, и есть проектная разработка. В одной важно уметь смотреть в будущее и брать ответственность за конечный продукт. В другой – быстро работать и переключаться между задачами. В обеих разработках ценится работа в команде и профессионализм в целом.
Agile
11 февраля 2001 года в США на горнолыжном курорте собрались 17 человек. Это были известные приверженцы разных методологий разработки: инженеры, разработчики и менеджеры. Некоторые из них были конкурентами. На встрече собравшиеся поняли, что у них много общего и выделили общие ценности, которым должны следовать успешные команды. Уже после встречи в течение двух месяцев шла бурная переписка между участниками. В её результате появилась страничка вики с 12 принципами айти команды. Так зародился Agile.
Agile – ценности и принципы, которыми руководствуются успешные команды. Их определяет Agile Manifesto. Манифест содержит 4 основные идеи и 12 принципов. Причем в нем нет практических советов.
Принципы Agile:
— Люди и взаимодействие важнее процессов и инструментов
— Работающий продукт важнее исчерпывающей документации
— Сотрудничество с заказчиком важнее согласования условий контракта
— Готовность к изменениям важнее следования первоначальному плану
И не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
http://agilemanifesto.org
11 февраля 2001 года в США на горнолыжном курорте собрались 17 человек. Это были известные приверженцы разных методологий разработки: инженеры, разработчики и менеджеры. Некоторые из них были конкурентами. На встрече собравшиеся поняли, что у них много общего и выделили общие ценности, которым должны следовать успешные команды. Уже после встречи в течение двух месяцев шла бурная переписка между участниками. В её результате появилась страничка вики с 12 принципами айти команды. Так зародился Agile.
Agile – ценности и принципы, которыми руководствуются успешные команды. Их определяет Agile Manifesto. Манифест содержит 4 основные идеи и 12 принципов. Причем в нем нет практических советов.
Принципы Agile:
— Люди и взаимодействие важнее процессов и инструментов
— Работающий продукт важнее исчерпывающей документации
— Сотрудничество с заказчиком важнее согласования условий контракта
— Готовность к изменениям важнее следования первоначальному плану
И не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
http://agilemanifesto.org
Модификаторы доступа
private – доступ открыт только внутри класса
default или package-private – класс, методы или переменные будут видны только внутри пакета
protected – члены класса доступны внутри пакета и в наследниках
public – доступны всем
В наследниках можно менять модификаторы доступа в сторону большей видимости. Например, метод
private – доступ открыт только внутри класса
default или package-private – класс, методы или переменные будут видны только внутри пакета
protected – члены класса доступны внутри пакета и в наследниках
public – доступны всем
В наследниках можно менять модификаторы доступа в сторону большей видимости. Например, метод
protected Object clone() можно сделать public, но нельзя сделать default.
Где взять примеры резюме
Регистрируемся на HeadHunter как работодатель, вводим нужный город, должность и просматриваем реальные резюме. Контактные данные в резюме скрыты, но зато можно подглядеть опыт и навыки.
Регистрируемся на HeadHunter как работодатель, вводим нужный город, должность и просматриваем реальные резюме. Контактные данные в резюме скрыты, но зато можно подглядеть опыт и навыки.
Зарплаты джавистов в 2018 году
Если на сайте «Мой круг» зарегестрироваться и указать свою зарплату, то можно посмотреть зп других айтишников: разработчиков, тестировщиков, аналитиков. Выбираешь город, навык, должность и получаешь выборку.
Вот средние зарплаты джава-разработчиков в Москве за первое полугодие
#компании #зп
Если на сайте «Мой круг» зарегестрироваться и указать свою зарплату, то можно посмотреть зп других айтишников: разработчиков, тестировщиков, аналитиков. Выбираешь город, навык, должность и получаешь выборку.
Вот средние зарплаты джава-разработчиков в Москве за первое полугодие
#компании #зп
Вопрос про ссылочные переменные. Какие из этих фраз верны?
A. Объекты имеют доступ только по ссылке
B. Если закастить объект к его суперклассу, то вы навсегда потеряете доступ к методам, которые описаны в подклассе
C. Тип объекта определяет, какие свойства объекта хранятся в памяти
D. Тип переменной определяет, какие методы и поля доступны в программе
E. С помощью кастинга к подклассу можно добавить атрибуты объекту в памяти
A. Объекты имеют доступ только по ссылке
B. Если закастить объект к его суперклассу, то вы навсегда потеряете доступ к методам, которые описаны в подклассе
C. Тип объекта определяет, какие свойства объекта хранятся в памяти
D. Тип переменной определяет, какие методы и поля доступны в программе
E. С помощью кастинга к подклассу можно добавить атрибуты объекту в памяти
Правильные ответы: A, C, D. Хоть объекты хранятся в памяти, но получить доступ к ним можно только по ссылке - вариант A верный. B не подходит, потому что если закастить объект обратно к своему типу, то у нас будет доступ ко всем методам. C, D верны и описывают различия между объектом и переменной. Вариант E неверный, потому что кастинг объекта не изменяет его в памяти.
Когда горит проект
Недавно проводил опрос "Как бы вы поступили на месте руководителя проекта, когда поняли, что проект горит" и решил задать этот же вопрос профессионалу. Олег Мохов руководитель службы разработки интерфейсов в Екатеринбургском Яндексе. Ещё он ведёт канал "Про руководство разработчиками" @teamleading. Передаю микрофон Олегу.
Спасибо, Дима. Отличный вопрос. Совсем недавно я общался с несколькими своими сотрудниками как раз на эту тему.
Нулевое правило. Руководитель в любом случае виноват и вся ответственность на нём. Даже если самодур разработчик ушёл в пьяный загул и увёл всю команду. Даже если косячили внешние подрядчики. Даже если дизайн выдали на 5 месяцев позже. Даже если случилось землятресение, ураган и нашествие инопланетян. Ответственность всегда на руководителе. Я считаю важным про это регулярно говорить с разработчиками, даже в тех проектах где нависают сроки, что вы отвечаете за сроки, а разработчики отвечают за написание кода.
Итак, сроки профакаплены. Что делать? Сначала нужно довести задачу до конца, а дальше выяснять почему возникли проблемы и делать выводы. Т.е сначала приложить все усилия чтобы устранить проблему. Если нужно остаться ночью, то я буду первым кто останется ночью. Если нужно поковыряться в базе, то я сяду рядом с разработчиком и буду смотреть, даже если я сам нифига не понимаю. Если разработчик сидит удалённо, то я всё равно буду онлайн. Т.е нужно сделать всё, чтобы решить задачу
Когда проблема решена, нужно понять почему она возникла, и что мы можем сделать в следующий раз, чтобы её не было. Я, обычно, провожу ретроспективы, где в командном формате мы решаем дальше, что можно поменять в процессе.
Надо сказать, что сроки в том или ином виде продалбываются регулярно. 6 лет назад я участвовал в одном спецпроекте Яндекса, запустить который нужно было точно в указанное время. Мы допустили кучу разных ошибок на всех этапах, но не могли не запуститься. За два часа до связанного события мы выкатили первую версию, на которую пошел трафик, облегченно вздохнули, и даже смогли немного поспать. Через четыре часа нам позвонили админы и сказали что сервис 500-тит. Наше достижение здесь в том, что никто массово этого не заметил, а для этого мы приложили максимум усилий.
В фильме «Москва слезам не верит» главная героиня Катя, будучи директором, говорит замечательную фразу: «Меня не интересует почему нет, меня интересует что вы сделали чтобы было да». Я очень часто говорю эту фразу, например, когда кто-то говорит мне о внешних проблемах, то я всегда по максимуму узнаю что именно он ещё сделал, чтобы решить проблему. «Там уже в тикете не отвечают два дня!». «А ты звонил им?». «Может отправить им кого-то из менеджеров в Москве?», «Может командировку оформить, лично приедешь?» – это пример проблемы, и примеры вопросов, которые я задаю. Если проблема ограничилась «проблема не на моей стороне» – мы идём и разговариваем с разработчиком про это. И я рассказываю ему в который раз, что решить задачу не означает сделать только свою работу. И если задача не решена, то не бывает «я всё сделал, а они нет», т.к важно только что задача не решена.
Недавно проводил опрос "Как бы вы поступили на месте руководителя проекта, когда поняли, что проект горит" и решил задать этот же вопрос профессионалу. Олег Мохов руководитель службы разработки интерфейсов в Екатеринбургском Яндексе. Ещё он ведёт канал "Про руководство разработчиками" @teamleading. Передаю микрофон Олегу.
Спасибо, Дима. Отличный вопрос. Совсем недавно я общался с несколькими своими сотрудниками как раз на эту тему.
Нулевое правило. Руководитель в любом случае виноват и вся ответственность на нём. Даже если самодур разработчик ушёл в пьяный загул и увёл всю команду. Даже если косячили внешние подрядчики. Даже если дизайн выдали на 5 месяцев позже. Даже если случилось землятресение, ураган и нашествие инопланетян. Ответственность всегда на руководителе. Я считаю важным про это регулярно говорить с разработчиками, даже в тех проектах где нависают сроки, что вы отвечаете за сроки, а разработчики отвечают за написание кода.
Итак, сроки профакаплены. Что делать? Сначала нужно довести задачу до конца, а дальше выяснять почему возникли проблемы и делать выводы. Т.е сначала приложить все усилия чтобы устранить проблему. Если нужно остаться ночью, то я буду первым кто останется ночью. Если нужно поковыряться в базе, то я сяду рядом с разработчиком и буду смотреть, даже если я сам нифига не понимаю. Если разработчик сидит удалённо, то я всё равно буду онлайн. Т.е нужно сделать всё, чтобы решить задачу
Когда проблема решена, нужно понять почему она возникла, и что мы можем сделать в следующий раз, чтобы её не было. Я, обычно, провожу ретроспективы, где в командном формате мы решаем дальше, что можно поменять в процессе.
Надо сказать, что сроки в том или ином виде продалбываются регулярно. 6 лет назад я участвовал в одном спецпроекте Яндекса, запустить который нужно было точно в указанное время. Мы допустили кучу разных ошибок на всех этапах, но не могли не запуститься. За два часа до связанного события мы выкатили первую версию, на которую пошел трафик, облегченно вздохнули, и даже смогли немного поспать. Через четыре часа нам позвонили админы и сказали что сервис 500-тит. Наше достижение здесь в том, что никто массово этого не заметил, а для этого мы приложили максимум усилий.
В фильме «Москва слезам не верит» главная героиня Катя, будучи директором, говорит замечательную фразу: «Меня не интересует почему нет, меня интересует что вы сделали чтобы было да». Я очень часто говорю эту фразу, например, когда кто-то говорит мне о внешних проблемах, то я всегда по максимуму узнаю что именно он ещё сделал, чтобы решить проблему. «Там уже в тикете не отвечают два дня!». «А ты звонил им?». «Может отправить им кого-то из менеджеров в Москве?», «Может командировку оформить, лично приедешь?» – это пример проблемы, и примеры вопросов, которые я задаю. Если проблема ограничилась «проблема не на моей стороне» – мы идём и разговариваем с разработчиком про это. И я рассказываю ему в который раз, что решить задачу не означает сделать только свою работу. И если задача не решена, то не бывает «я всё сделал, а они нет», т.к важно только что задача не решена.
Что посмотреть на выходных
Доклад о Spring Boot’е ч. 1
https://youtu.be/yy43NOreJG4
Доклад о Spring Boot’е ч. 2
https://youtu.be/7Cq5zEm2wq0
Интервью основателя Revolut
https://youtu.be/srX8NrtZg7k
#чтопосмотреть
Доклад о Spring Boot’е ч. 1
https://youtu.be/yy43NOreJG4
Доклад о Spring Boot’е ч. 2
https://youtu.be/7Cq5zEm2wq0
Интервью основателя Revolut
https://youtu.be/srX8NrtZg7k
#чтопосмотреть
Принципы ООП
Абстракция – выделение функциональности, которая нужна для решения задачи, и отсечение всего лишнего. Например, интерфейс и его реализации.
Инкапсуляция – сокрытие реализации. Объект имеет внутреннее состояние, которое нельзя менять извне, и поля, с которыми могут взаимодействовать другие объекты. В Джаве инкапсуляция реализована с помощью модификаторов доступа.
Наследование – передача свойств и поведения родительского класса дочернему. В Джаве наследование реализовано с помощью ключевого слова extends.
Полиморфизм – один интерфейс, множество реализаций. Пример – с помощью переменной родительского типа можно оперировать объектами дочернего типа.
Вопросы на закрепление:
- особенности наследования в Джаве
- примеры нарушения инкапсуляции
- примеры абстракции
- примеры полиморфизма
Абстракция – выделение функциональности, которая нужна для решения задачи, и отсечение всего лишнего. Например, интерфейс и его реализации.
Инкапсуляция – сокрытие реализации. Объект имеет внутреннее состояние, которое нельзя менять извне, и поля, с которыми могут взаимодействовать другие объекты. В Джаве инкапсуляция реализована с помощью модификаторов доступа.
Наследование – передача свойств и поведения родительского класса дочернему. В Джаве наследование реализовано с помощью ключевого слова extends.
Полиморфизм – один интерфейс, множество реализаций. Пример – с помощью переменной родительского типа можно оперировать объектами дочернего типа.
Вопросы на закрепление:
- особенности наследования в Джаве
- примеры нарушения инкапсуляции
- примеры абстракции
- примеры полиморфизма
Интерфейс
Минимум, который нужно знать об интерфейсе:
• Интерфейс - ссылочный тип
• Может наследоваться от нескольких интерфейсов
• Переменные по умолчанию public static final
• Методы по умолчанию public abstract
• С восьмой Джавы есть default методы, которые имеют реализацию
• Может хранить вложенные интерфейсы
• Нельзя создать экземпляр интерфейса
• Класс может реализовывать несколько интерфейсов
Вопросы на закрепление:
- Перечислить отличия абстрактного класса от интерфейса
- Что произойдет, если класс реализует два интерфейса с методами, у которых одинаковая сигнатура
Минимум, который нужно знать об интерфейсе:
• Интерфейс - ссылочный тип
• Может наследоваться от нескольких интерфейсов
• Переменные по умолчанию public static final
• Методы по умолчанию public abstract
• С восьмой Джавы есть default методы, которые имеют реализацию
• Может хранить вложенные интерфейсы
• Нельзя создать экземпляр интерфейса
• Класс может реализовывать несколько интерфейсов
Вопросы на закрепление:
- Перечислить отличия абстрактного класса от интерфейса
- Что произойдет, если класс реализует два интерфейса с методами, у которых одинаковая сигнатура
Дизайн-принципы Intercom
Сегодня посетил митап Кости Горского. Костя – дизайн-менеджер в Intercom, в прошлом дизайн-директор Яндекса.
Мне запомнились дизайн-принципы, которым в какой-то степени могут следовать и разработчики:
1. Правильно поставить задачу важнее, чем правильно её решить
2. Переиспользование вместо изобретения
3. Простота важнее функциональности
4. Человечность важнее технологичности
5. Неважно, что ты нарисовал. Важно, что мы запустили
Сегодня посетил митап Кости Горского. Костя – дизайн-менеджер в Intercom, в прошлом дизайн-директор Яндекса.
Мне запомнились дизайн-принципы, которым в какой-то степени могут следовать и разработчики:
1. Правильно поставить задачу важнее, чем правильно её решить
2. Переиспользование вместо изобретения
3. Простота важнее функциональности
4. Человечность важнее технологичности
5. Неважно, что ты нарисовал. Важно, что мы запустили
