Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Технічна співбесіда на Java-розробника: питання і поради щодо підготовки

[Про автора: Зеновій Верес — керівник освітнього напрямку Lviv IT Cluster, Solution Architect в компанії SoftServe, асистент кафедри комп’ютеризованих систем автоматики у Львівській політехніці]

За останні 10 років я провів понад 300 технічних інтерв’ю Java-фахівців — як Intermid, Senior рівнів, так і TechLead/Architect. Існує багато коментарів як кандидатів, які пишуть про неадекватні запитання, так і інтерв’юерів, які нарікають на недостатній рівень кваліфікації спеціалістів.

Хочу поділитися своїм підходом до проведення технічних співбесід, спостереженнями та загальними рекомендаціями, які, на мою думку, можуть допомогти кандидатам справлятися із завданнями успішніше. Звісно, існує багато різних методик та варіантів організації процесу, тому одразу наголошу — все, викладене нижче, є моїм особистим досвідом.

Цілі інтерв’ю та підхід

Перш за все, хочу почати з цілі технічного інтерв’ю. Я завжди ставлю собі завдання виявити сильні сторони фахівця. Згодом на основі цієї інформації рекрутер може пропонувати кандидата на конкретні проекти, які будуть цікаві йому, і де він зможе принести максимальну користь команді та компанії. Я не маю завдання завалити фахівця чи показати, що він чогось не знає. Для мене найважливіше — з’ясувати, що він знає.

Очевидно, що зробити об’єктивну оцінку рівня знань надзвичайно складно за короткий проміжок часу — як правило, технічне інтерв’ю триває близько години, іноді — півтори. Саме тому я готуюсь до інтерв’ю заздалегідь, спершу перечитую резюме та профіль кандидата (Candidate Profile), який він сам заповнює, оцінюючи свій рівень знань (knowledge area) та володіння технологіями. Перший блок співбесіди традиційно ознайомчий — я зазвичай задаю декілька вступних запитань, щоб познайомитися та розрядити атмосферу.

Досвід роботи

На цьому етапі я отримую розуміння про роботу кандидата в команді: як він оцінює свою роль на проекті, як була розподілена команда, яка була взаємодія між учасниками, як відбувалось узгодження вимог до проекту, яким чином команда оцінювала тривалість задач та наскільки мала можливість впливу на процес розробки. Якщо кандидат претендує на лідерську позицію, важливо з’ясувати, як він організовував процес командної роботи над кодом, хто здійснював перегляд коду, оцінював тривалість задач, як проект поділявся на спринти та релізи, як приймалися архітектурні або технічні рішення, які недоліки прийнятих рішень та на основі чого обиралися фреймворки. Також слід очікувати на запитання — що, на вашу думку, варто змінити в проекті, які з прийнятих вами рішень виявились помилковими та чому?

Запитання

Після цієї секції починається власне технічна частина. Я не використовую заготовлених тестових завдань чи запитань — підбираю їх ситуативно, виходячи з результатів першої частини інтерв’ю. Траплялися різні випадки — наприклад, іноді кандидат не вказував у резюме весь свій досвід або оцінював рівень володіння технологіями нижче, ніж є насправді. Бували також випадки, коли людина копіює інформацію з інших резюме, навіть не перевіряючи, чи відповідає це його досвіду, головне, щоб було ближче до вимог вакансії. Саме на цьому етапі я отримую первинне розуміння рівня кандидата, від цього і залежить складність наступних задач.

Зважаючи на те, що я прихильник практичних завдань, то дуже часто описую певну задачу і прошу кандидата розказати, як би він її вирішив. Приклад такої задачі для архітектора/технічного лідера: для описаного вами проекту, яким чином ви б забезпечили підтримку додаткових 5000 користувачів одночасно; яким чином ви б організували заливання 1000 записів у базу даних з використанням Spring/JPA і т. п.

Відштовхуючись від отриманої інформації, я переходжу до запитань по об’єктно-орієнтованому дизайну. Я очікую, що людина із рівнем Intermid і вище знає, для чого слід використовувати шаблони проектування (GoF/GRASP/SOLID/Layered Arcitecture). Від кандидатів Senior-рівня я очікую розуміння, коли і котрий з шаблонів слід застосовувати, а також як виконувати рефакторинг коду із використанням шаблонів (рекомендую книгу Д. Кірієвскі «Рефакторинг з використанням шаблонів»). А також ситуації, коли використання шаблону може мати негативний вплив або бути невиправданим. Також до базового набору я відношу запитання по SQL/DB Design, програмного доступу до бази даних (DB Access), що включає в себе знання JPA/Hibernate. Звісно, від кандидата також очікується і знання мови програмування Java та змін, які були внесені у Java SE 8/9 s Java EE 8 (Jakarta EE). Зауважу, що на даний момент менше уваги приділяється багатопоточності, адже наявність багатьох фреймворків ізолює розробника від потреби створювати та керувати новими потоками.

У випадку наявності досвіду по Spring обов’язково задаю низку питань — перш за все, з якими компонентами цього фреймворка працював кандидат. А також запитання по REST/SOAP сервісах.

А тепер найцікавіше — які саме запитання слід очікувати на інтерв’ю? Я зазвичай починаю зі складніших запитань, але якщо кандидату вони виявляються заскладні, то поступово переходжу до простіших. Для економії часу читачів не буду наводити список стандартних запитань (чому слід перевизначати equals та hashCode, яким чином інтерфейси дозволяють реалізовувати інкапсуляцію та ін.) — по кожній із зазначених вище сфер є достатньо запитань в інтернеті. Зупинюся більше на запитаннях, пов’язаних з архітектурою, та запитаннях «з родзинкою».

Про архітектуру:

  1. Опишіть архітектуру проекту — яким чином ви її документували, як вносили зміни, що було причиною внесення змін? Назвіть основні якісні характеристики (quality attributes) системи — яким чином ви їх досягли, чому для системи важливі саме ці атрибути, які у вас є обмеження, які припущення ви зробили при проектуванні системи? Рекомендую почитати книгу Len Bass «Software Architecture in Practice», 3rd Edition.
  2. Які фактори вплинули на вибір фреймворків для проекту, які були альтернативи, що було основним фактором відхилити альтернативи? Яким проблеми виникали при виконанні запитів до бази даних, як ви їх вирішували? Як реалізовували REST-сервіси, яку бібліотеку обрали, як реалізовували HATEOAS-принцип?
  3. Яку версію Java використовували на проекті? Що для вас є найважливішим у версії Java SE 8/9? Що входить в Java EE, яким чином відбувається реліз Java EE (Jakarta EE)? Що саме з Java EE ви використовували? Чи стикалися ви з out of memory error? Якщо так, то як саме вирішували та відслідковували використання ресурсів? Чи стикалися з memory leak? Якщо так — як шукали причину, як організовували роботу з пам’яттю?

Звісно, це лише декілька запитань з великої кількості можливих, але зазвичай саме вони допомагають зрозуміти рівень знань та досвіду роботи кандидата на проекті. Інколи буває, що людина губиться у відповідях, що, не виключено, є результатом стресу, тому я переключаюся на теоретичні запитання, щоб кандидату було комфортніше і він заспокоївся. А також я не задаю всі ці запитання одночасно :)

Каверзні запитання

Іноді я відходжу від стандартної канви і ставлю запитання зовсім іншого характеру. Роблю це не для того, щоб підловити, а щоб зрозуміти хід думок кандидата. Трапляються випадки, коли людина завчила запитання суто по Java і навіть не хоче подумати, хоча відповідь може бути дуже простенькою. Наприклад, запитання по типах колекцій є достатньо стандартними. А ось запитання на кшталт «при яких операціях відбувається економія часу, коли ми працюємо з HashMap та за рахунок чого відбувається така економія; які операції при цьому відбуваються повільніше, у порівнянні з ArrayList» показує, наскільки кандидат розуміє принципи роботи даної колекції. Крім того, така методика зазвичай використовується саме для того, щоб подивитися, як людина відреагує на такі запитання. Інколи «правильна відповідь» не найважливіше, що ми хочемо почути. Такі завдання дозволяють нам побачити ваші soft skills, глибину мислення та підхід до вирішення непростих завдань.

Поради

  • Найголовніша порада — будьте чесними, починаючи з резюме. В ньому варто чесно відобразити технології та фреймворки, з якими працювали саме ви, а не які в цілому використовувалися на проекті. Пам’ятайте, що на початку інтерв’ю кожен кандидат має 100% довіри — з кожною невідповідністю цей кредит падає і з кожним разом все швидше.
  • Відображайте в резюме всі проекти, над якими працювали, навіть якщо їх багато. Це дозволить побачити всю картинку розвитку вас як фахівця. Також це дає уявлення, чи неперервний досвід ви мали, чи були перерви, з якими технологіями стикалася.
  • Чесно розкажіть про ваше особисте ставлення до проекту — подобався\не подобався, чому зупинилися саме на таких технологіях, чи були виклики і як з ними справлялися, яка була взаємодія команди в таких випадках, як приймали рішення. Це дозволить зрозуміти, наскільки ви були залучені до проекту та жили ним, а також який ви командний гравець.
  • Ставте запитання. Переконайтеся, що перед тим, як почнете відповідати чи розв’язувати задачу, ви правильно її розумієте. Не варто часто просити повторити запитання. Якщо хочете дізнатися більше про проект, команду чи компанію — запитуйте. Відсутність запитань може означати, що ви не зацікавлені в компанії чи позиції, на яку проходите співбесіду.
  • Зробіть домашнє завдання. Під час інтерв’ю з рекрутером вам надають первинну інформацію про проект — не соромтеся розпитувати та просити трохи більше деталей. Це дозволить вам зрозуміти специфіку проекту та краще підготуватися до технічної співбесіди — освіжити теоретичні знання, заглянути в код, зрозуміти, яка інформація з вашого резюме може бути найактуальнішою.
  • Заспокойтеся та не нервуйте. Співбесіди — це стресова ситуація для будь-кого. Можливо, ви подалися на позицію, на яку дещо не вистачає кваліфікації, чи навпаки — здається, що в описі вакансії йдеться саме про вас. В будь-якому випадку ви хвилюєтесь. Важко розкрити всі свої переваги, коли нервуєшся. Тому заспокойтеся, підготуйтеся та розкрийте свої сильні сторони.
  • Погугліть перед інтерв’ю. На інтерв’ю задають достатньо стандартні запитання, до яких можна і потрібно підготуватися.
  • Запишіть запитання, на які ви не знали відповіді під час співбесіди або незадоволені своєю відповіддю. Потім пошукайте відповіді для себе — це дозволить вам розвиватися.
  • Завжди просіть надати інтерв’юера відгук про інтерв’ю — які у вас виявлені сильні сторони, а над чим слід попрацювати.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному2
LinkedIn

Схожі статті




75 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

TL; TR Я прочитал много умных книг, записал на бумажке десяток акронимов и знаю самый-самый верный способ прособеседовать чуваков.

та змін, які були внесені у Java SE 8/9 s Java EE 8 (Jakarta EE).

— lol, зачем? Абсолютно бессмысленное занятие.

У випадку наявності досвіду по Spring обов’язково задаю низку питань

- «Я спрашиваю про Java 10 и Java 20», но не слышал о Guice, Dagger, etc. Кстати, про билд системы забыли — ant, maven, gradle, blaze, buck, etc.

Також до базового набору я відношу запитання по SQL/DB Design

 — NoSQL и их облачных друзей не?

Від кандидатів Senior-рівня я очікую розуміння, коли і котрий з шаблонів слід застосовувати, а також як виконувати рефакторинг коду

- Дизайн, у помидоров надо спрашивать дизайн, и про то, как разруливать проблемы.

Опишіть архітектуру проекту — яким чином ви її документували, як вносили зміни, що було причиною внесення змін?

- Как заплатили, так и задокументировал, можно и не спрашивать. Типичный ответ на галере.

TechLead/Architect

 — Stuff и principal уже или ещё не называют?

і прошу кандидата розказати, як би він її вирішив.

- Че, серьёзно не просите программиста покодить хоть полчасика? Даже малюююсенькой задачки на динамическое программирование не задаёте?

технічне інтерв’ю триває близько години, іноді — півтори.

- Серьёзно? Только один человек в лупе?

Класс! ...так як маю багатий досвід з обох сторін — дуже гарно описано! ..всі б такі були!
...гарні книжки рекомендуєте — я б сюди добавив Martin Flower ...в нього є гарна книжка по патернам рефакторінгу та по ентерпрайз патернам...

Відображайте в резюме всі проекти, над якими працювали, навіть якщо їх багато.

...оце трохи не зрозуміло... власне є варіанти — як в мене — де досвід 30 років... а що актуально? ...останні 12-15... Якщо в резюме давати всі... Були варіанти коли менеджери пропонували скоротити до шести...
І як бути з опен-соурс проектами та «власними локальними» проектами.
Тут же як.. .часто-густо треба щоб розіратися з новими технологіями їх реально «пощупати». Тому паралельно підіймаєш дещевий лкальний проект під свою фінансову відповідальність на нових і складних (не адекватно потребі) технологіях... І приходиться довго і нудно пояснювати «то ти ще робиш на тім проекті?» — «Ні, то мій власний проект. Там мої хлопці лишилися на підтримці, але я там ...менторо-лідер... але я там не працюю...» — вбільшості випадків виходить на те, що краще про то не розповідати...
По опен-соурс зворотня ситуація. Нормальні проекти мають обмежену кількість контрибюторів — які весь час можуть присвятити проекту — а ти, за звичай, робиш з одним з контрибюторів — береш на себе певний ковалок імплементації чогось там. ...і тут виникає питання — з одного боку написати про свою участь в опен-соурс — ніби і добре, маєш додаткову нагоду щось спробувати, пощупати. Але два дізадвантажес зразу — тебе немає в списках контрибюторів і ти там працюєш паралельно основному проекту (ну важко пояснити — особливо каліфорнійцям — що твій оптимальний робочий графік — більше ніж вісім годин... і Що три години ти цілком можеш ще використати на щось ще... І, цілком можливо, з користю для основного проекту...
Тож, як тут бути?

Я не використовую заготовлених тестових завдань

Тут теж не зрозумів... Загалом — на мою думку — зроблеен тестове завдання може скоротити час під час інтерв’ю.
І тут буваюь варіанти цікаві.
Була в мене ситуація. Вирішили з однією фірмою робити класні курси повищення кваліфікації.
Прийшло 300 заявок, але ... ну не в стані були стільки переворити...
Розраховували на дужів плюс == мідлов мінус...
Я зробив тестові завдання на рівні сеніорів і, що цікаво, 30 чоловік їх вирішили на ура. При чому кожен міг пояснити чому саме такий алгоритм використовував, чому такий патерн, тощо...
і що цікаво — після піврічни курсів та роботі в команді по пять-шість чоловік, всі вони досить успішно пійшли далі. Наприклад, 12 з них вже працюють по інших фірмах сеніорами...
То може є сенс в тестових завданнях?

...просто в мене на одному проекті був тім-лідом принципал з Санта-Клари, який для цієї корпорації де ми працювали робив «скрінінг кандидатів» і він, люблячи поговорити на загальні теми під час щоденного мітінгу, багато розповідав про їхні підходи. Так от його «бест практіциз...»:
—якщо людина в тестовому завданні не відпрацьовує усього ланцюгу тестів... Не вартує потім говорити з людиною про ТДД та подібне — щоб людина теоретично не говорила.
—якщо людина в тестовому завданні не описує «що робила та чому», не оформлює джавадоків, тудушек та т.п. — можемо не слухати розповідь людини про «великий досвід командної роботи».
Теж саме з використанням певних коллекцій та варіантів конкюренсі...

Тож, може, в тестовому завданні таки є сенс?

Хоча — ще раз — дякую за багато нових ідей! Гарно! Є над чим ще раз подумати!

Я не маю завдання завалити фахівця чи показати, що він чогось не знає

Так, ми знаємо, що зазвичай інтерв’ювери ставлять мету затвердитися в очах власної компанії, що вони не зря їдять свій хліб. Якщо приходять спеціалісти, які вищі вас на голову, то ви не завжди зможете це зрозуміти навіть. ;)

"Пам’ятайте, що на початку інтерв’ю кожен кандидат має 100% довіри"©
Совсем не факт..
Беседовал с одной HR и она говорила, что поскольку встречаются кандидаты, что вписывают вообще все, какие только названия слышали (я лично таких случаев не встречал, но она видимо или встречала или верит в такой достаточно распостраненный миф), то изначально к кандидату настороженность, что половина в его резюме — неправда.

А я встречал. Однажды попался кандидат, который не смог ответить вообще ни на один вопрос, даже по азам, но у него было в резюме перечислена половина екосистемы.

Сомнительно как то.. Обычно в резюме пишут только то, что на 100% знает и в чем уверен. А то, с чем хоть и работал, но знаешь недостаточно хорошо — в резюме вообще можно не вписывать.
Насторожила фраза — «даже по азам, » ©
То вполне возможно была несколько другая ситуация — может быть беседовали с человеком с опытом в 10-15 лет вот и надо было беседовать не об «азах», а на более глубокие вопросы (насколько позволяет самому собеседующему его уровень). Надо было говорить о практических вопросах и их решениях, а не спрашивать «азы», написанные на первых трех страничках Getting Started with... (то есть то, что реально считается «азами», «основами», но во всей последующей практике практического применения не имеет — так и остается чисто академическими знаниями, которые кандидат не факт что и помнить будет через 10 лет). Надо было поговорить по практическим вопросам, по реальным задачам, а не по каким-то академическим азам.

может быть беседовали с человеком с опытом в 10-15

Ну вот может не надо выдумывать ответы собеседникак за него? Это был около-джуниор с зарплатными ожиданиями около 800 баксов.

Бывает. ...но, особенно около-джуниорами, бывает встречная ситуация, когда человек психологически не готов к собеседованию...

Пример ситуации (из личного опыта).
Чел неплохо проше профильное образование. Участвовал во время учебы в нескольких локальных комерческих проэктах за 20-ть баксов, голова соображает.
И вот он попадает к вам на собеседование с работой «на запад» и с возможной зарплатой 500-800 баксов и ...реално у него отнимается «возможность говорить»... он все забывает, потому что это собеседование для него очень важно.... Это как первый раз выйти на сцену...

И тут важно иметь загатовку как человека вывести из этого состояния. Ничего не мешает рассказать анекдот. Смешной. Про програмистов... Работает. :)
Чем «дружнее» обстановка на собеседовании — тем лучше...

Всегда прекрасно видно, человек забыл изза волнения, что не страшно и не грешно, или человек изначально «не знал и забыл».

Обычно в резюме пишут только то, что на 100% знает и в чем уверен. А то, с чем хоть и работал, но знаешь недостаточно хорошо — в резюме вообще можно не вписывать.

Не факт. Первое дело в резюме пишется опыт работы. Далее — очень чесно — роль в команде, специализация...
Если человек начнет утверждать что он все знает на 100% — я ему просто не поверю...
Даже принципалы не могут утверждать что они что-то знают на 100%...
Всегда есть специализация на чем-то и достоточное для работы знание другого...

То вполне возможно была несколько другая ситуация — может быть беседовали с человеком с опытом в 10-15 лет вот и надо было беседовать не об «азах»,

Вот вот. Такое бывает очень часто, что заставляет для себя фирму ставить в «черный список».
Ну давайте от бухгалтеров требовать «написания диктанта»...

Просто если кандидат имел какой-то опыт (пусть даже три месяца или полгода) — он в принципе не может вообще ничего не знать.. Если даже он просто числился на стуле без компа в кабинете и смотрел в окно — коллеги между собой общались — он косвенно, подсознательно все равно хоть что-то но знал бы..
Поэтому «не ответил ни на один вопрос» весьма сомнительно..(Если, разумеется, сами вопросы были по существу )

Просто если кандидат имел какой-то опыт (пусть даже три месяца или полгода) — он в принципе не может вообще ничего не знать

экий вы, батенька, пессимист :)

А да, еще был забавный кадр.
Приходит такой парниша. Взгляд плавающий, как будто парень дунул в подворотне перед собесом, как будто не в себе. Начинаю спрашивать по технологиям, написанным в резюме. После каждого вопроса — молчание 10-20 секунд и ответы — «нет», «не знаю». Вот у вас написано JAX-RS, расскажите что делали. Молчание. А что это вообще? -фреймворк. А что он делает? взгляд в пустоту, молчание 20 секунд -Не знаю.
Приошлось попрощаться через несколько минут.

Взгляд плавающий, как будто парень дунул в подворотне перед собесом, как будто не в себе.

Вот вот — это именно оно. Человек психологически был не готов к собеседованию.
Варианта два: ...попробовать вывести из этого состояния. ...перевести собеседование на друге время... Это ж джуны. Посылать их — не лучший вариант... :)

Ну нет, это совсем не оно. Когда человек волнуется, и когда человек наврал в резюме, а вы это обнаруживаете на каждой аббревиатуре — это таки разные вещи и разница видна.

Технічна співбесіда на Java-розробника

Переименуйте статью в «Технічна співбесіда у Зеновій Верес». Статья — откровенная вкусовщина и имеет очень мало с реальностью.

А теперь мы будем докапываться до текста статьи :)

Звісно, від кандидата також очікується і знання мови програмування Java та змін, які були внесені у Java SE 8/9 s Java EE 8 (Jakarta EE).

1) 9-ку мало кто использует, особенно из тех кто следит за джавой, потому что 9-ка не лонг терм саппорт, ее публичная поддержка заканчивается в марте 2018
2) Jakarta EE — это не Java EE 8, а следующая за ней версия.

Зауважу, що на даний момент менше уваги приділяється багатопоточності, адже наявність багатьох фреймворків ізолює розробника від потреби створювати та керувати новими потоками.

Ага, от только дедлоки на сра... ХешМапе кто будет разруливать? А гонку на тредлокалах? А что делать когда добавили магическую аннотацию фреймворка Async и все затормозило?

А також запитання по REST/SOAP сервісах.

Вот всегда поражали люди которые пишут REST/SOAP. Это 2 принципиально разных подхода.

А ось запитання на кшталт «при яких операціях відбувається економія часу, коли ми працюємо з HashMap та за рахунок чого відбувається така економія; які операції при цьому відбуваються повільніше, у порівнянні з ArrayList» показує, наскільки кандидат розуміє принципи роботи даної колекції.

Угу, очень каверзный вопрос, проверяет прочитал ли кандидат ответ на вопрос «Как работает ХешМапа», который очень-очень редко задают на собеседованиях :)

Ага, от только дедлоки на сра... ХешМапе кто будет разруливать? А гонку на тредлокалах? А что делать когда добавили магическую аннотацию фреймворка Async и все затормозило?

Завжди дивують люди, які додумують своє в текст.

Угу, очень каверзный вопрос, проверяет прочитал ли кандидат ответ на вопрос «Как работает ХешМапа», который очень-очень редко задают на собеседованиях :)

тим не менше, таке запитання ставить в ступор багатьох

1) 9-ку мало кто использует, особенно из тех кто следит за джавой, потому что 9-ка не лонг терм саппорт, ее публичная поддержка заканчивается в марте 2018

Якщо я працюю з котроюсь мовою програмування, то маю знати що є в нових версіях, чи ні?

«яку б ви версію Java брали для проекту? — саму останню, 8-му.
окей, чи слідкуєте за оновленнями? — Так звісно, наступного року має бути 9-та»
«що з 9-ї Java вам б стало у нагоді на проекті?» — «не знаю, я не читав про 9-ту версію»

«не знаю, я не читав про 9-ту версію»

Вот тут пожалуй соглашусь, что человек, позиционирующий себя как джавист (любого уровня) как минимум должен ознакомиться, что оно вообще.

Завжди дивують люди, які додумують своє в текст.

А вы пишите тексты так чтобы не приходилось додумывать.
Та и проблема в том что вы (по моей догадке) взяли конкретный пример и подменили его общим утверждением, которое ложно (я привел контрпримеры).

тим не менше, таке запитання ставить в ступор багатьох

После первого прочтения, этот вопрос ввел меня в ступор тоже, мысль была «че я прочитал? зачем сравнивать время работы 2 структур которые имеют разное назначение?»
Проблема вашего примера в том что он не «каверзный», это просто вопрос из серии «угадай мысли собеседующего» (надо объястнять почему это плохо?)

Якщо я працюю з котроюсь мовою програмування, то маю знати що є в нових версіях, чи ні?

И снова подмена конкретного примера, на общность. Ответ на этот вопрос: вы __НЕ__ обязаны знать что будет в новых версиях.
При том __в большинстве__ случаев, __хороший__ специалист будет __интересоваться__ тем что будет в новых версиях.
Простой пример — это вы. Вы спутали ДжЕЕ8 и ДжакартаЕЕ. Это потому что вы плохой специалист? Или потому что умеете приоритизоровать входящую информацию?

«яку б ви версію Java брали для проекту? — саму останню, 8-му.
окей, чи слідкуєте за оновленнями? — Так звісно, наступного року має бути 9-та»
«що з 9-ї Java вам б стало у нагоді на проекті?» — «не знаю, я не читав про 9-ту версію»

Хороший пример 2+ годичной давности, который сейчас выглядит как глупость

Хороший пример 2+ годичной давности, который сейчас выглядит как глупость

я очікував що ви напишете про 2+ роки — на жаль ні, це свіжий приклад (3-римісячної давності)

Простой пример — это вы. Вы спутали ДжЕЕ8 и ДжакартаЕЕ

ні, несплутав, це ще одне з питань з підвохом :)

я очікував що ви напишете про 2+ роки — на жаль ні, це свіжий приклад (3-римісячної давності)

Так вы би и писали, что 3 месяца назад пришел человек который считает что «наступного року має бути 9-та». Это уже совсем другая проблема, и она довольно опосредовано относится к знанию того что именно поменялось в определенной версии.

ні, несплутав, це ще одне з питань з підвохом :)

Ну да, конечно :)

1) 9-ку мало кто использует, особенно из тех кто следит за джавой, потому что 9-ка не лонг терм саппорт, ее публичная поддержка заканчивается в марте 2018

Якщо я працюю з котроюсь мовою програмування, то маю знати що є в нових версіях, чи ні?

А може компроміс? (якщо це співбесіда сеніор +)
Запитати про роботу гарбаж колектора, альтернативні JVM... а потім запитати про «інтерфейс гарбаж колектора» --- «А що це?», — «Ти не дивився Java9»?... ...якось так.

Для рівня мідл і нижче звісно це не актуально....

Zenoviy, расскажите историю этой статьи. Врядли вас переполняло желание поделиться столь очевидными вещами с общественностью, что вы по своей инициативе запостили статью. Это SoftServe в «добровольно-принудительном» порядке заставляет писать подобные статьи или DOU напрямую обратился к вам с такой просьбой?

а ще мене заставили запиляти 9 програм у львівських ВНЗ, написати цю статтю dou.ua/...​olumns/lviv-it-education і пообіцяли відвязати від батареї, коли на цій сторінці fb.com/iotlvivua буде 2000 лайків — поможіть лайком, а?

Как по мне спрашивать про 9 версию и Jakarta EE ещё слишком рано. Куча проетов ещё — на 7 и EE6 пишется.

Интересно, а что мешает перейти на JDK8 ?

Деньги. Установка и конфигурирование новый версий application servers, пересборка всего софта что на них крутился, потом полный цикл тестирования включая интеграционное — это много времени работы девопсов, программистов и тестировщиков. А если это огромные энтерпрайзные проекты которые пишутся по 5-10 лет?

Да забудь ты уже про Java EE, кроме JPA и JAXRS оно мертво, а особенно CDI, EJB, JNDI, JTA, JMS это бесполезное дерьмо мамонта.

Да забудь ты уже про Java EE, кроме JPA и JAXRS оно мертво, а особенно CDI, EJB, JNDI, JTA, JMS это бесполезное дерьмо мамонта.

JMS вполне живой, используется так же как и JPA. Вопрос в другом: КРУД с релиационной БД нужно чуть ли не в каждом приложении, а вот очереди сообщений далеко не в каждом.
CDI используют процентов на 10% (по факту как Guice), в основном те кто __не хотят__ завязываться на спринг

а в львівській політехніці першокурсників навчають якраз JPA и JAX-RS і CDI

а в львівській політехніці першокурсників навчають якраз JPA и JAX-RS і CDI

Это сейчас шутка была? Или Во Львове решили занятся производством инвалидов?

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

JAX-RS. Вы уверены что первокуры, которые вообще программ не писали поймут как и зачем нужен REST (это которые про архитектуру сетевых приложений)?

JPA. Это без знания СКЛ и реляционных БД?

UPD. Это был не стеб. Я правда считаю что изучение подобных технологий на первом курсе — это дебилизм.

iot.lviv.ua/projects_1st_year — список студенських проектів.

UPD. Это был не стеб. Я правда считаю что изучение подобных технологий на первом курсе — это дебилизм.

перефразую: я вважаю що неможна вчитись їздити на авто, поки не вивчив будови коробки/двигуна/трансмісії і далі по списку

iot.lviv.ua/projects_1st_year — список студенських проектів.

А какой из них имеет сервер-сайд джава?
Я пооткрывал ГитХабы, там в основном ЮИ приложение + что-то непонятное с тудушками в место кода на питончеге.
github.com/...​lbrusProject/branches/all — Навешайте звиздюлей «Mentor: Anton Minashkin.» А комманде обястните зачем нужны бранчи.

перефразую: я вважаю що неможна вчитись їздити на авто, поки не вивчив будови коробки/двигуна/трансмісії і далі по списку
Завжди дивують люди, які додумують своє в текст.

Переведу на ваш язык: я считаю что чтобы ездить на авто, не надо учится в универе.

жоден немає — оскільки це проекти студентів, що провчились 1 семестр поки. А пітони/мобайл/веб вони вчили самостійно де-факто, оскільки в першому семестрі в них все стартує з с/с++
а тепер вони вчать джаву і як зробити бек на джаві щоб через рест віддати дані

жоден немає

Тогда на...зачем вы бросили эту ссылку в контексте разговора про серверные джава технологии?

а тепер вони вчать джаву і як зробити бек на джаві щоб через рест віддати дані

Какой нах РЕСТ?
Объясните им зачем надо ветки для начала. И научите не коммитить код экзамплов от 3-тесторонней библиотеки в свои репозитории. Это вполне можно было сделать в курсе «Вступ до спеціальності»

научите не коммитить код экзамплов от 3-тесторонней библиотеки в свои репозитории

А вот этому, как раз — как и другим вещам из серии «инженерная культура», в ВУЗе, к сожалению, не учат :(

И, скажу вам, вы большой оптимист, если думаете, что так делают только студенты :)

учать, чого ж не учать — є вимоги що має бути в репо. Вимоги порушені — балів нема. Всім все було розказано і показано. А тепер просто: вимоги невиконано — значить задача не зроблена

А тепер просто: вимоги невиконано — значить задача не зроблена

Тогда на...зачем вы бросили эту ссылку?

«зачем бросіл». Мені неважко, можу повторити і ще раз: тому що зараз студентів навчають як побудувати бек на джаві. І внєзапно більшість вже відчула потребу в тому, щоб їм пояснили як то все працює, що вони використовували при написанні проекту (рести, база і далі по списку)

І внєзапно більшість вже відчула потребу в тому, щоб їм пояснили як то все працює, що вони використовували при написанні проекту (рести, база і далі по списку)

Вопрос в том смогут ли они понять?
Смогут ли люди, которые БД уровень оставляют в виде тудушки, понять какие проблемы решает ДжПА? Смогут понять какие проблемы он привнесет?
Смогут ли люди, которые как-то присобачили 1 веб-вызов, понять какие проблемы решает РЕСТ?

а для того щоб змогли — по лабі на душу населення. І пояснення де працює, а де непрацює. Це як посів зерна — не все з сказаного проросте в головах, але де шукати і куди дивитись в них завжди буде під рукою. А далі — це вже досвід і підгон навиків під потреби проектів

а для того щоб змогли — по лабі на душу населення. І пояснення де працює, а де непрацює.

Супер. У меня есть идея лучше: надо просто взять и научить.

Це як посів зерна — не все з сказаного проросте в головах, але де шукати і куди дивитись в них завжди буде під рукою. А далі — це вже досвід і підгон навиків під потреби проектів

Тадам! Университет учит учится ©

По факту вы за 1 семестр уже посеяли очень неслабые зерна профессиональной неполноценности в своих студентов (см гитхабы по вашей ссылке): ребята просто прикручивают разные хрени без особого понимания.
Вы забейте на тот стек что перечислен в начале ветки. Давайте сразу спрингбут со спринг-датой.

то може долучитесь і врятуєте професійну повноцінність? команда з 4-х другокурсників, ідея проекту — генеруєте спільно, дедлайн — початок червня? (я серйозно)

то може долучитесь і врятуєте професійну повноцінність?

В теории да, на практике ни вы, ни админ апарат универа не будут впрягаться в бюрократию с переделкой учебных планов :)

команда з 4-х другокурсників, ідея проекту — генеруєте спільно, дедлайн — початок червня? (я серйозно)

Мы явно не слышим друг друга. Я вам тут пытаюсь намекнуть что у вас проблема в построении процесса по которому вы преподаете теорию. В ответ на это вы мне предлагаете курировать практические занятия.

В теории да, на практике ни вы, ни админ апарат универа не будут впрягаться в бюрократию с переделкой учебных планов :)

перелопачуєм щороку — процес відкатаний, було б бажання

теорія іде в звязці з практикою, додайте мене у ФБ і я по джмилу дам доступ до презентацій і списку лаб

Приклад такої задачі для архітектора/технічного лідера: для описаного вами проекту, яким чином ви б забезпечили підтримку додаткових 5000 користувачів одночасно; яким чином ви б організували заливання 1000 записів у базу даних з використанням Spring/JPA і т. п.

В такой формулировке это не пример задачи. Какая изначально архитектура, какие технологии. Сколько было пользователей? Что тормозило/не работало когда добавили ещё 5000 пользователей? Они имели жирную сессию на сервере? Про 1000 записей. 1000 записей в сек? Работает медленно/ не работает совсем? У вас всего в базе было меньше 1000 записей)? От того как поставлен вопрос, можно сделать вывод о компетенции собеседователя))

А от якщо співбесідуваний задасть такі уточнюючі питання у відповідь, можна буде зробити висновки про його компетенцію :)

спершу на інтервю я прошу кандидата розказати про проект, в тому числі яка архітектура, які технології . І ці питання стосуються того, як змінити його проект, щоб забезпечити підтримку додаткових 5000 користувачів одночасно (якщо це питання буде релевантне).

Якщо хочете дізнатися більше про проект, команду чи компанію — запитуйте.
...не соромтеся розпитувати та просити трохи більше деталей.

90% таких питань зустрічають відповіть у стилі:
— ми ще не знаємо;
— в нас немає детальних даних по проекту/вакансії;
— ми ще не знаємо, на який проект ти потрапиш;
— поки що замовник не надав більш детальної інформації;
— більше інфи вже буде, коли почнеться робота безпосередньо з замовником;
— Найкраща з відповідей: «Ми розробляємо софт для „проблеми Х“ в „галузі У“».

Питання, які зустрічають подібні відповіді:
— Це буде новий проект?
— Я буду писати бекенд/фронт енд?
— Проект вже розпочато?
— Терміни проекту?
— Скоуп відповідальності?
— Чи потрібно буде лідити команду?
— Тайм-слот?
— Скільки народу буде в команді?
— Ціна питання?

Це якщо співбесідують не на конкретну позицію/проект, а «в пул». Мені то трохи дивним видається, бо у 90% випадків людину на проект потрібно «на вчора» — тобто з замовником вже домовлено, скільки людей якого профілю він готовий оплачувати на проекті, і вже під структуру команди йде пошук.
Хоча є варіант, коли є кілька різних відкритих вакансій. Тоді, як правило, перша співбесіда загальна — з цими «ми ще не знаємо», а друга вже на конкретний проект.

яким чином відбувається реліз Java EE (Jakarta EE)?

Возможно, многие со мной не согласятся, но я считаю это не совсем адекватным вопросом, который показывает, что интервьюеру либо нечего спросить, либо.

Я спрашиваю только то, что кандидат должен знать для успешной работы на проекте. И начинаю вопросы «за философию» только если кандидат успешно ответил на 80-90% вопросов технических.

А спрашивать про правовые тонкости релизов версий, проблемы Оракла или на каком боку спал Гослинг, когда ему приснилась джава — это не совсем правильные вопросы.

Зауважу, що на даний момент менше уваги приділяється багатопоточності, адже наявність багатьох фреймворків ізолює розробника від потреби створювати та керувати новими потоками.

Серьезно?
Т.е. существование спринга освобождает джависта от понимания многопоточности? Или то, что мы больше не делаем new Thread() освобождает от необходимости знаний о многопоточности? Breaking news.

при яких операціях відбувається економія часу, коли ми працюємо з HashMap та за рахунок чого відбувається така економія

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

Если я вас спрошу, быстрее ли выполняется добавление в ArrayList, закономерным вашим вопросом будет «быстрее чего?». А я вам в ответ, «а просто быстрее».

Кстати быстрее )). Вопросы по быстродействию коллекций без привязки либо к O(*) либо к каким-то совршенно конкретным деталям не имеют смысла, да.

Я спрашиваю только то, что кандидат должен знать для успешной работы на проекте
Т.е. существование спринга освобождает джависта от понимания многопоточности? Или то, что мы больше не делаем new Thread() освобождает от необходимости знаний о многопоточности? Breaking news.

так питаєте ви про багатопоточність чи не питаєте? і чи часто вам доводилось застосовувати Fork/join framework?

так питаєте ви про багатопоточність чи не питаєте?

Конечно спрашиваю! Это одна из обязательных тем в интервью. Форк-джойн нет, но вообще многопоточность у нас в проекте есть сплошь и рядом, и огромное количество вопросов нужно решать с учетом многопоточности. Если человек не понимает многопоточности ему у нас просто нечего делать.

И да, я не спрашиваю про форк-джойн, так же как не спрашиваю про CompletableFuture и/или перечислить классы из java.util.concurrent. Я спрашиваю понимание базовых вещей и основ. А с классами человек разберется.

не спрашиваю про CompletableFuture

А я спрашиваю, но не конкретно про него, а даю задачку — нужно конкурентно вычитать из 3 ендпоинтов данные, смерджить их и отдать обратно.
И не важно что использовать, но сделать их на completable future или реактивных стримах или rxjava гораздо легче чем на fork/join или просто фьючурах.

Это так. Но если человек сделает их на фьючурах, это не беда. Если он понимает основы, он легко и быстро разберется и с более сложным API.

Я не даю таких задач по достаточно простой причине — на ее выполнение человеку нужно дать время. Зачастую у меня этого времени просто нет. Поэтому я все выясняю устно. Имхо, если человек сам скажет, что такую задачу он решил бы передав коллекцию колаблов в екзекьютор, я не вижу смысл в написании кода.

для мене це і є "

менше уваги приділяється багатопоточності

". Фюче, Коллабл, Локи, Екзекютор Сервіси, Циклічний бар’єр, дедлоки/лайвлоки — і їдем далі :)

Эээ... а что, понятие многопоточность остановилось на мониторах, wait/notify и synchronized?

Иностранный (интернациональный) миддл

Перш за все, хочу почати з цілі технічного інтерв’ю. Я завжди ставлю собі завдання виявити сильні сторони фахівця. Згодом на основі цієї інформації рекрутер може пропонувати кандидата на конкретні проекти, які будуть цікаві йому, і де він зможе принести максимальну користь команді та компанії. Я не маю завдання завалити фахівця чи показати, що він чогось не знає. Для мене найважливіше — з’ясувати, що він знає.

слова не мальчика, но мужа. Это разительно отличается от подхода прыщавого 19 летнего сеньора, который вчера вычитал про корнер кейс какой-то либы и теперь всех умножает на 0 на собесе.

Ну блін, а як збивати зарплатні очікування кандидата? :)

Пустые слова.
Ты хоть раз реальные случаи «сбивания» видел ?
На позицию сразу выделяется определенная вилка. Если сумма, озвученная кандидатом попадает в эту вилку — все норм, берут. Если заявленная ниже нижней — - дают свою выделенную верхнюю. Если заявленная выше верхней — не берут.
Это и называется — «торг». Никто никогда не сбивает (прежде всего потому что деньги эти не свои, а компании, поэтому никакой ни выгоды сбивать нет, ни интереса). Я не думал, что и сейчас кто-то еще живет с мифами, достаточно распостраненными лет 15 назад (когда компании были маленькие и на работу принимал сам владелец, который был реально заинтересован в экономии).

поправка:
«Если заявленная ниже нижней — - дают свою выделенную нижнюю»

Це не міфи, це реальність при проходженні інтервюшки мною кілька років тому. При чому це не була якась шарашкіна кантора. Суму здається відразу сказали. І переважно людину беруть на компанію, а не проект. Тому потім платити людині на іншому проекті чи бенчі неадекватну знанням суму ніхто не захоче.

А як тоді пояснити ситуацію, коли рекрутери переважно пишуть «у нас дійсно нема як такої вилки по ЗП»?

Очевидно же — такой вилки нет (то есть и торга нет).
Либо попадаешь в нашу вилку, либо не берем (я же именно это постом выше сказал)

вилки нет... попадаешь в нашу вилку

Так і не зрозумів, є вилка чи нема)

Якщо є і рекрутеру нема вигоди збивати зп, який зміст не називати вилку?
Які можуть бути мотиви у людини, що не знаходиться у пошуку роботи, витрачати свій час на підготовку до співбесіди на позицію, верхня межа вилки якої, можливо, до того ж менша за поточну зарплату?

1) Есть вилка, есть. И эта вилка и есть основой того, что торга нет. (либо попадаешь в вилку, либо нет)
2) Рекрутер и не сбивает зп никогда. Ей в этом интереса никакого нет — она делает техническую работу — спросить «пожелания» кандидата и сравнить с записанными у нее от компании. (вот это — «який зміст не називати вилку?» — тоже загадка, почему такая мода у нас так принялась)
3) Согласен. Нет смысла. Мотивы тоже загадочны :)).

Ты хоть раз реальные случаи «сбивания» видел ?

Не знаю как Виталий, но я видел (сам и слышал от других) и не раз. О последнем таком случае мне расказали где-то неделю назад, так что проблема еще актуальна.

Никто никогда не сбивает (прежде всего потому что деньги эти не свои, а компании, поэтому никакой ни выгоды сбивать нет, ни интереса).

Есть случаи, в основном в небольших компаниях: собеседует ТимЛит/ПМ, то он приблизительно понимает бюджет и брать очень дорогого не хочется.
Есть люди которых жаба давит, когда начинает соотносить со своей ЗП и при этом противопоставляя свой «гигантский» опыт с вашим.

"собеседует ТимЛит/ПМ, то он приблизительно понимает бюджет и брать очень дорогого не хочется.«©
Какие то у Вас ТимЛит/ПМ сплошь альтруистами нарисованы.. Как они за бюджет владельца своей компании искренне переживают («Лучше пусть у меня в чем-то недостаток будет — лишь бы моему хозяину было хорошо...»).. ))
Это из жизни или просто в книжках прочитали, что «так должно быть» ?

Как они за бюджет владельца своей компании искренне переживают

Они переживают за количество людей в комманде, за количество бонусов которые они могут выдать людям (для улучшения мотивации), за то сколько дорогих игрушек ... то есть тулов можно будет использовать.
К слову, иногда собеседующий может и не знать конкретных сум, может просто быть просьба от ХРа или ПМа/ВПофИнжениринг «нам бы как-то подешевле нанять».

Это из жизни или просто в книжках прочитали, что «так должно быть» ?
я видел (сам и слышал от других) и не раз.

а потом смещал его с должности? :)

Підписатись на коментарі