Про фейкових інженерів, або Чому я недолюблюю Stack Overflow Driven Development

Розкажу вам одну історію, яка трапилась не так давно та змусила мене шукати відповіді на питання «Що не так зі Stack Overflow?» та «WTF?»

Все почалося з того, що на одному з проектів компанії Erbis, над яким я працюю вже понад три роки, почали розширювати команду інженерів Java. Мене, як тім ліда, запросили проводити інтерв’ю з кандидатами. Знаю, що зараз ситуація на ринку IT неординарна і у більшості випадків останнє слово саме за розробниками. Але коли Java-інженер з досвідом 5+ років претендує мінімум на 5 штук баксів і не може вирішити на співбесіді просту задачку (і мова тут не про тестове завдання), яка передбачає нескладну логіку і знання базових алгоритмів... варіант з закиданням оферами відпадає.
Сорян, та далі буде швидше про закидання віртуальними помідорами.

Обережно, сеньори, полетять помідори

Було б не так сумно, якби не ситуація, що сталася декілька днів потому, коли зелений «джун» вирішив ту ж саму задачку, не зіпрівши, за 10 хвилин. Може, ще свіжими лишилися принципи й методології з універа чи з курсів, та було дивно, як Junior Java Developer зміг переплюнути Senior Java Engineer?

Відповідь можна вмістити у два слова: Stack Overflow.

Річ у тому, що наш «Mature Senior» настільки звик гуглити й копіпастити, що підзабув основи мови, на якій кодить і самостійно будувати рішення. Але в такому разі постає питання чи доречно називати такого спеціаліста інженером?

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

Працюєш з JakartaEE? З мене пиво!

Аналізуючи ситуацію далі, я дійшов висновку, що більшість «інженерів» працюють з технологією Spring/Spring Boot. Одразу скажу: так, мій проект на JakartaEE, але я не маю на меті докинути на вентилятор субстанції кольору #964B00, підігріваючи холіварну тему, що краще Jakarta EE чи Spring.

Насправді, написати REST сервіс, що отримує дані з бази даних, можна однаково добре, як на Spring, так і на Jakarta EE. З першим, звісно, буде швидше, бо на те, щоб знайти до компонента А компонент B на Stack Overflow і змусити їх працювати разом, піде небагато часу. Але фішка у тому, що коли потрібна кастомізація, заготовки для Spring часто не спрацьовують.

У випадку з Jakarta EE ви, зазвичай, теж підете спочатку пошукаєте чи не виклав хто готове рішення? Але вже за півтори години зрозумієте, що вихід один: закотити рукава і кодити.

Jakarta EE — це як вивчити польську

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

Не дивлячиь на те, що проект з Кремнієвої долини, над яким я працюю, побудований за допомогою Jakarta EE, ми розглядали у тому числі і Java-інженерів з досвідом Spring. Бо, за великим рахунком, перейти (особливо сеньйору) зі Spring на Jakarta EE — це як перейти з української школи до польської. Тобто розуміти мову ти будеш від самого початку, з арифметикою також все буде ок, читання і письмо треба буде підучити, ну ще танці будуть без бубна.

На жаль, у багатьох досі жива асоціація Java з EJB і іншими страшними речами 10-річної давнини. Цікаво, що за звітом Eclipse Foundation’s 2020 Jakarta EE Developer Survey, Spring/SpringBoot користуються 44% розробників як найбільш поширеним фреймворком для Java. Втім, JakartaEE не надто відстає, — серед її поціновувачів більш як третина (35%) Java-розробників. При цьому, у 2019 відсоток юзерів Spring/SpringBoot сягав 57%.

З мого досвіду, наразі реально крутих проєктів, побудованих на Jakarta EE, у Штатах та Європі вистачає. Тож списувати цю технологію з рахунків зарано. Більш того, на відміну від Spring, вона стимулює рости і розвиватися.

Якщо ви вирішите спробувати сучасну Jakarta EE і впевнитися у її потенціалі, запрошую до співпраці.

👍НравитсяПонравилось5
В избранноеВ избранном0
LinkedIn

Лучшие комментарии пропустить

Ну если джуны решают алгоритмические задачи лучше сеньоров — так и нанимайте джунов, они ж стоят в 5-10 раз дешевле. С какой стороны ни глянь — везде профит.

А если еще и клиенту этих джунов по рейтам сеньоров продавать — так вообще сказка, а не жизнь, получается)

...или всё же ценность сеньора не только в умении решать алгоритмические задачи?
Да не, бред какой-то, в чем же еще))

Если «простая задачка на логику» написана, как и эта статья, то не странно что у многих возникают проблемы с ее решением.

Начинается с «Що не так зі Stack Overflow?», дальше идут сеньоры в пересмешку с джунами, а заканчивается все пиаром «JakartaEE». Также автор добавил, что проект именно с Кремневой долины и разбавил все аналитикой с Eclipse Foundation’s.

Ну и напоследок, в одном из комментариев автор меняет изначальное условие и уже говорит, что: «Недолюблюю саме Stack Overflow Driven Development, а не Stack Overflow (до нього ставлюсь нейтрально)»

Проблема в том что современный жаба синьйор кроме собственно языка, должен знать еще фреймворки и бд, докер, кубернетис, клауда, писать конфиги в helm и terraform, настраивать CI/CD и еще кучу вещей по мелочи. И когда на собесе тебя начинают задрачивать какими-то задачками которые ты решал 5+ лет назад — это, конечно, вызывает затруднения.

Статья крайне интересная.

Если автор хотел захантить новых людей на собеседование — то ему стоило написать какие интересные технические задачи они решают.

Если цель статьи была пиар Jakarta EE — то тема не раскрыта, кроме как «это как Spring, но без кучи готовых вещей».

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

По теме.
Да, на рынке есть проблема, что кандидаты могут не знать (не уметь, не помнить) базы. И не только в разработке. В тестировании и автоматизации такое тоже повсеместно. И тоже интервьюеры «сокрушаются...».

Но откуда кандидатам помнить и знать базу, если
— они ее почти не применяют в повседневных задачах;
— большинство задач сводится к дописыванию бизнес логики в заготовку Spring Boot микросервиса;
— на большинстве собеседований в аутсорсинг компании тебя будут 2 часа задалбывать вопросами по API Спринга и базовых библиотек джавы, а не задачки на алгоритмы. И таких собеседований у нас 90%;

Кандидат, знающий и имеющий БАЗУ, спринг, джакарту, системный дизайн и задачки с leetcode — скорее всего пойдет или в местный интересный продукт на много денег или поедет собеседоваться в FAANG и компании рангом поменьше. Потому что, какой смысл это все готовить, учить и тратить время, чтобы потом работать в небольшой совсем компании и делать вообще неизвестный продукт. Если можно поехать пилить даже тот же Booking.

Deal with it or build technical brand.

Не верю в существование «Stack Overflow-driven development». В реальности крайне редко встречаются задачи, решение которых от начала до конца будет присутствовать на stackoverflow. Разве что если компания постоянно занимается рутинным "формошлёпством"/"крудошлёпством"/etc.

В остальных случаях программист так или иначе должен думать сам. Даже если какие-то небольшие куски он может подсмотреть на стековерфлоу (и то, не слепо копипастя, а адаптируя их под свою задачу в её конкретном контексте) — отлично, он молодец, воспользовался одним из доступных ему инструментов, сэкономил время. Ничего плохого в этом нет.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Нові рішення. А не відстежує відповіді на вищезгаданому ресурсі.

Hiт. иначе это будет изобретения велосипеда для уже давно решенных проблем.
А вот предложить решение не решенной проблемы может только инженер-исследователь, и никак не copy-paste SO developer

Думаю стоит порадоваться за тех ребят, кто не прошел собеседование к вам в компанию.

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

Проблема не в Stack Overflow, а в тому що програмісти не думають: а чи можна зробити краще? Після того як знайшли першу відповідь на сайті.

І Stack Overflow не має відношення до розв’язання задач.

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

І в тому, що програмісти не думають, чи перша знайдена відповідь правильна та вирішує їх задачу

То тому джуніору дали ЗП в 5000 $? Програмісти не інженери.

Якщо його взяли як Junior CTO, то цілком могли дати

Але ж senior хотів 5000 і не впорався а junior впорався. Значить це його треба взяти на посаду програміста з ЗП в 5000.

Не дивлячиь на те, що проект з Кремнієвої долини, над яким я працюю, побудований за допомогою Jakarta EE, ми розглядали у тому числі і Java-інженерів з досвідом Spring. Бо, за великим рахунком, перейти (особливо сеньйору) зі Spring на Jakarta EE — це як перейти з української школи до польської. Тобто розуміти мову ти будеш від самого початку, з арифметикою також все буде ок, читання і письмо треба буде підучити, ну ще танці будуть без бубна.

А ви впевнені, що у Jakarta EE таке безхмарне майбутнє? Чому люди, які все життя писали на Spring, раптом повинні переучуватися і переходити на Jakarta?
Я для порівняння зробив пошук Java вакансій на ДОУ:
--- Spring 457
--- Java/Jakarta EE 62

Я думаю, що Jakarta EE нікуди не подінеться. Моя думка полягає в тому, що для досвідченого розробника перехід зі Spring’а на Jakarta EE і назад не має бути проблемою. В моєму досвіді так і було: починав з Java EE, потім купу років використовував Spring / Spring Boot і зараз знову Java EE / Jakarta EE. А крім цього ще встиг порозроблювати ПО, не використовуючи жоден з цих важковаговиків.

Тут я з вами не згоден абсолютно. Java EE/Jakarta EE — це тільки специфікація, до якої йдуть купа реалізацій.
І ось уявіть собі. Девелопер використовував Spring Boot + Spring MVC + Spring Data + Spring Cloud, а повинен вивчити Payara + Jersey + чистий JPA + Microprofile. Одне повноцінне вивчення цих технологій — кілька місяців мінімум.

Цікаво, що за звітом Eclipse Foundation’s 2020 Jakarta EE Developer Survey, ... Втім, JakartaEE не надто відстає

По результатам Интернет-опроса, 100% пользуюся интернетом (см. выделенное в цитате)

Я бы сказал, что гораздо более реальный порядок цифр, как приведено выше — 457/62 или 85% vs 15% (ну пусть даже сделаем реверанс в сторону Jakarta и умножим на 2 — 70% vs 30%, может в Украине просто не понимают)

Моя думка полягає в тому, що для досвідченого розробника перехід зі Spring’а на Jakarta EE і назад не має бути проблемою

Да, в целом не должно. Только ЗАЧЕМ ? Переходить с мэйнстрима на достаточно нишевую технологию, с потенциальной сложностью поиска новой работы через X лет

У випадку з Jakarta EE ви, зазвичай, теж підете спочатку пошукаєте чи не виклав хто готове рішення? Але вже за півтори години зрозумієте, що вихід один: закотити рукава і кодити.

Тут у Stackoverflow є один плюс. Неважливо, що ви використовуєте, але коли ми самі написали рішення, ви можете потім порівняти його з тим, що пропонують на Stackoverflow і можливо знайдете якісь способи його поліпшити (або знайдете у себе помилку).

Опишу свою точку зору по Stackoverflow.
Цей сайт (а він частина Stack Exchange), як мені здається, корисний, коли ви зіткнулися з помилкою/виключенням або необхідно налаштувати якусь складну систему.
Якщо ви спробуєте самостійно це зробити (без Інтернету), то на це можуть піти дні та години. Який у цьому сенс? Це просто одноразова проблема, яка може більше ніколи не повториться.
А ось йти на StackoverFlow для того, щоб знайти алгоритм вирішення — це більш спірний момент. Швидше за все, це говорить про те, що у вас слабка база в тій технології, з якої у вас затик. І головна проблема не в тому, що ви скопіювали рішення і заощадите час, а можете скопіювати невірне/застаріле рішення. Або навіть правильне, в якому нічого не будете розуміти. Використовуючи Stackoverflow подібним чином, ви ніяк не будете рости як фахівець.

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

Именно! Это тот самый «индуский» стиль программирования, который сейчас так популярен в аутсорсе. Это, можно сказать, философия галер «мы можем все за ваши деньги».
Если спросить любого сейлза может ли галера сделать проект — он всегда ответит что КОНЕЧНО: у нас есть экспертиза, мы уже такое много раз делали, у нас целая команда специалистов под рукой. И абсолюно не важно что за проект и какие технологии!
Главное ввязаться в бой (получить проект) — а там видно будет. В результате ситуация, когда девелоперу приходится решать задачу на технологиях, которые он плохо знает встречается повсеместно. И времени разбираться девелоперу никто не даст — ведь клиенту сказали что у нас уже команда профи, которые все знают и умеют! Вот и рабоаем как индусы: нашли кусок непонятного кода, вставили — как-то работает — тасочку закрыли.

Главное ввязаться в бой (получить проект) — а там видно будет.

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

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

Річ у тому, що наш «Mature Senior» настільки звик гуглити й копіпастити, що підзабув основи мови, на якій кодить і самостійно будувати рішення. Але в такому разі постає питання чи доречно називати такого спеціаліста інженером?

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

Але фішка у тому, що коли потрібна кастомізація, заготовки для Spring часто не спрацьовують.

Цiкаво, можете надати приклади?

Неудачно написанные SDK или библиотеки, c @Autowired бинами общего назначения (типа object mapper-ов) глубоко внутри. Но это в целом более характерно для достаточно старых версий

Мені здається, що автор мав на увазі щось інше ....

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

Однако проблема того, что есть куча «синьоров», которые не помнят / не знают / не интересуются совершенно базовыми вещами, существует.

Из личного опыта, встречал заслуженных синьоров с лычками и годами опыта которые:
— не знали что есть List.retainAll(), List.removeAll(), т.е. человеку даже не приходила в голову мысль посмотреть в документацию или тыцнуть в иде точку и пробежать глазами по списку автокомплита
— не знали что такое тред пул.
— не знали что такое модификатор final
— не понимали смысл терминов stateless / statefull
— не знали разницы между объектом и примитивом и их передачей

На интервью, или в реальной жизне?
Бо я сразу рекрутерам пишу, например, что если будут спрашивать, как расшифровывается SOLID, то давайте уже сразу не надо

Якщо раптом так трапиться, що на одну вакансію буде 50 кандидатів, то ви будете готові набити тату SOLID, аби вас взяли на роботу

Вибачте, але в ситуації, коли рекрутери/сорсери наполегливо долдонять людині, яка вже має роботу, бо їм дуже потрібний саме спец, скажемо, в event driven highload project, і ти вже такий «Ну ок, послухаю, мож чим зможу допомогти», та готуєшься обсудити саме робочі питання — тобто, де затик, що треба вирішити, які переспективи на майбутнє у сенсі навантажень, костів інфраструктури, тощо... і тут тебе питають щось типу «що таке sealed класи». Я у студентів таке не питаю.

Ну він же спочатку запитає про sealed classes, а потім про highload.
Насправді такі питання цілком доречні, щоб з самого початку відсікти junior/middle, які раптом вирішили, що вони senior.

В реальной жизни.
Я видел как синьор писал код типа
int a = 5;
changeValue(a);
assertThat(a).notEqual(5)
и не понимал в чем проблема

Ось такі «синьйори» і непокоять

Якось вирвано з контексту. Задача яка була?

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

Если это «плюсы» и сигнатура метода типа «void changeValue(int& a);» — почему бы и нет?

Если это "плюсы"

Сорян, профдеформация, речь за джаву.

если будут спрашивать, как расшифровывается SOLID, то давайте уже сразу не надо

не я один такой )))

Ну тут тоже есть место для маневра. Я сегодня на интервью спросил от обратного — придумай пример где нарушается буква L, кандидат начал напрягаться.

Не верю в существование «Stack Overflow-driven development». В реальности крайне редко встречаются задачи, решение которых от начала до конца будет присутствовать на stackoverflow. Разве что если компания постоянно занимается рутинным "формошлёпством"/"крудошлёпством"/etc.

В остальных случаях программист так или иначе должен думать сам. Даже если какие-то небольшие куски он может подсмотреть на стековерфлоу (и то, не слепо копипастя, а адаптируя их под свою задачу в её конкретном контексте) — отлично, он молодец, воспользовался одним из доступных ему инструментов, сэкономил время. Ничего плохого в этом нет.

Может решения задач над которыми работает конкретный ТС и встречается, каждый смотрит со своей колокольни

должен думать сам
не слепо копипастя
Не верю

Ахахаха
i.imgur.com/K8hhaI2.jpeg

really are

У каждого своё «really».

Мені здається, що основна мета StackOverFlow — не вирішення типових задач (це не letitcode), а рішення проблем (чому помилка/виключення, чому не працює і т.д.).

Не знаю каких джунов нанимает тс, но давеча в LI в одном из тредов джуны жаловались что в требованиях на java dev требуют (о мой бог) знания SQL.

По их мнению это требование на фулстека.

джуны жаловались что в требованиях на java dev требуют (о мой бог) знания SQL.

І для чого __зараз__ джава джуніору знати СКЛ?

Ну, хочаб для того щоб розуміти що саме робить хіб, звідки беруться дані та як їх отримати поза апкою.

що саме робить хіб

Є леєром під спрінг-дата :)

та банальный силект в базу сделать, шоб посотреть шо там за данные лежат и откуда оно береться. И шоб от минимальных джоинов и групбай глаза из орбит не вылазили.

Ну якщо ви не знаєте SQL, це не означає, що ніхто не повинен його знати.

Ну якщо ви не знаєте SQL

Ліл, гадатель по аватрці? Звідки інфа? Чи це помста за те що я спалив ваше незнання того що таке ДТО? :)

це не означає, що ніхто не повинен його знати.

То скажіть для чого це __зараз__ потрібно саме джуніору.

Задачі типу:

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

Вирішуються автогенерацією в УІ клієнта до БД.
Проекти де було потрібне вміння писати складні запити (усілякі репортінги, наприклад) зараз переростають в БігДату або віддаються усіляким дата сайнтистам. Програмісту знання СКЛ треба все менше з кожним роком.

А який в нього потім буде стимул його вчити? ІМХО СКЛ треба знати, ну хоча б на рівні джойнів для джуна. Бо хіб іноді таку діч робить, що краще СКЛ

А який в нього потім буде стимул його вчити?
І для чого __зараз__ джава джуніору знати СКЛ?

Типу знати щоб знати?
Якось співбесідував чувака з десь 5 років досвіду в 3 конторах, так у нього не було РСКБД, була монга, наче ще ріак і кауч.

что в требованиях на java dev требуют (о мой бог) знания SQL

Тут нужно уточнить, что понимается под «знанием SQL». Обычно глубоких знаний не требуется, но основы знать обязательно, на мой взгляд. Конечно, если джун будет хоть как-то взаимодействовать с реляционной БД.

Или они надеются, что для джава джуна необязательно знать Hibernate? (для понимания которого знание SQL идет «в нагрузку»)? Тогда у меня для таких джунов плохие новости: с ними будут конкурировать люди, которые знают и SQL, и Hibernate (естественно, на базовом уровне)...

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

11 років SQL навіть не дотикався. Хоча до того було багато.

Чи на програміста БД питають, що таке диференційна пара, манчестерське кодуваня, і гальванічна розв’язка?

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

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

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

Кто решил задачку тот и сеньор :-)

Если синьйору надо нянчить джуна 8*5 времени, то дешевле такого джуна уволить и взять нового. (За редким исключением).

11 років SQL навіть не дотикався.

Мої співчуття

Не все подметают свое рабочее место в конце дня.😁

Чи на програміста БД питають

Нет, но программист БД должен хотя бы в общих чертах понимать то окружение, в котором будет осуществляться доступ к БД, так как есть скоуп задач, где нужно разбираться и разработчику приложений, и разработчику БД: конфигурация пула соединений, обработка и реагирование на ошибки БД, управление транзакциями и т.д. Хоть эти вопросы и не возникают каждый день, но когда они возникнут — лично мне хотелось бы получить от своего коллеги минимально необходимое понимание предметной области. И я более чем уверен, что моему коллеге того же хотелось бы получить и от меня.

решил задачку (что тс писал в комментах ниже) за 5 мин. я теперь помидор? в некоторых кампаниях, считают, что нет. в некоторых — что да.

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

Не знаю как там в современной джаве, но на котлине такая задача, мягко говоря, не на 5 минут

str
.split(" ")
.sortedWith(comparedBy({it.length},{it.first()}))
.toSet()

ещё смешат рекрутеры что спрашивают зп на предыдущем месте работы, говоря что из интереса. а потом говорят что забыли сказать что у них зп привязана к предыдущему месту работы и больше чем +500 они не дают.

А кто запрещает врать рекрутеру про свою текущую зп? Всегда говорил немного ниже желаемой, ну чтобы добавили +500 к моей «текущей» и спали спокойно мамкены переговорщики :-)

у меня памяти мало что бы врать :)

Это не обман, а переговоры, что бы не запоминать кому и как сказал, говори всем по схеме, типа минус 10 15 процентов от желаемой зп

Это сбоку так кажется, ты не знаешь как конкретная компания поступит, часто такую информацию сложновато нарыть

Да мне все равно что там кажется или нет, я хочу «столько-то» и точка. Не дают — досвидос. Сейчас работы море просто.

А потом стонут про «перегретый рынок»)))
С такой позиции рынок штатов вообще уже в состоянии высокотемпературной плазмы.

Скільки я був на HR інтерв’ю, мене ніколи не питали про попередню зарплату. Можливо, для сеньйорів вона і так +/- відома.

В описанной картине о слабых синьорах не хватает деталей, их могут добавить те кто был на этом собеседовании.
Приходишь, сначала заходит девочка хр и рассказывает в общих чертах о проекте, потом немного общения с CTO, заходит «тимлид» проекта и с ехидной ухмылкой начинает читать твоё резюме, потом с такой же ухмылкой говорит ну давай посмотрим как ты решишь наши задания. Дают список задач. Ты начинаешь решать на бумаге, в это время в комнате стоит балаган, все весело общаются, на бумаге не идёт (не помнишь все API в деталях), просишь ноут. Тебе дают какой-то старый ноут и садятся у тебя за спиной, весело обсуждая что-то своё и периодически задавая тебе отвлекающие вопросы (типа о ты работал там-то, а знаешь того-то?). Ты нажимаешь на клавиши, ноут дико тупит, IDE не настроена совсем, java доков нет. Спрашиваешь как так? На что тебе с ухмылкой отвечают «он поломался, чинили, мы его не успели настроить, пиши так!». Ты понимаешь что попал в какой-то цирк (похоже что намеренно устроенный цирк), решение задачи не идёт, за спиной болтовня и периодические комментарии относительно твоих действий, типа «ну да, давай так». Говоришь не могу решить, балаган успокаивается, все переходят и садятся за стол напротив тебя, просят решить следующие задачи уже устно. Решаешь следующую, говорят да ок, следующую, крутят головой говорят «аяяй как же это можно не знать?», начинают задавать вопросы касательно разных тем. Общаетесь, в ходе общения оказывается что «супер спецы» собеседующие тебя сами не знают важных вещей о технологиях с которыми работают, тут уже ты говоришь «аяяй как же это можно не знать?». Время уходит за отведенные рамки, разогретый «тимлид» не хочет останавливаться и изъявляет желание поговорить о каждой технологии из твоего резюме, но его успокаивают, он уходит. Тебе на выходе предлагают дать алгоритмическую задачку для решения дома, на что после пройденного циркового представления соглашаться у тебя нет никакого желания. Говоришь спасибо не хочу, прощаешься.
Выходишь на улицу, выдыхаешь, пытаешься понять где ты только что был и что это было. Интервью с элементами проверки на стрессоустойчивость? Или может они в такой обстановке балагана любят работать и проверяют смогут ли потенциальные кандидаты? В общем уже не важно. Приходишь домой, садишься за комп, решаешь за 5 минут задачу которая не пошла на собесе (без stack overflow), понимаешь что с тобой все в порядке. В качестве вывода из полученного опыта даёшь себе установку — в будущем сразу разворачиваться и уходить с подобных цирковых собеседований.

Используйте слово Я, вместо ты — очень поможет!

Выход — ходить на собесы с своим ноутом :)

Так в смысле, а что нужно было сделать? Закодить в жабе решение задачки, не польуясь интернетами?

Такие предложения — свидетельствуют лишь о явном идиотизме запрашивающего.

Можна діяти краще. Попросити не закодувати завдання, а придумати і пояснити рішення (алгоритм). Для цього Інтернет не потрібен.

знаем мы таких «интервьюверов», разворачивай деревья туда сюда, свапай через xor и прочий бред, а потом приходишь на проЭкт и хопа, вот тебе 1000 и 1 баг разгребай, куда только рокет сайнс подевался!

А що вони роблять не так? Їх завдання знайти кращого кандидата за пропоновану зарплату, нехай і на їх гавно-проект.

да все так, но пусть упоминают этот моментик до собеса, зачем время тратить :)

Kurwa, co jest takiego trudnego w nauce polskiego? Co za pieprzone stereotypy?

Ну если джуны решают алгоритмические задачи лучше сеньоров — так и нанимайте джунов, они ж стоят в 5-10 раз дешевле. С какой стороны ни глянь — везде профит.

А если еще и клиенту этих джунов по рейтам сеньоров продавать — так вообще сказка, а не жизнь, получается)

...или всё же ценность сеньора не только в умении решать алгоритмические задачи?
Да не, бред какой-то, в чем же еще))

Цінність сеньйора не тільки в цьому. Але якщо він не може продемонструвати вміння думати, комунікувати, використовувати інструменти розробки, то чи так вже важливо, що він з SO і такою-то матір’ю запустить свій мікросервіс у кубері.

Важливо щоби Сіньор вмів продемонструвати вміння думати, комунікувати, використовувати інструменти розробки, а не саме вміння думати, комунікувати, використовувати інструменти розробки.
Ясно. Так і запишемо.

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

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

Але якщо він не може продемонструвати вміння думати, комунікувати, використовувати інструменти розробки

Увы, это нельзя проверить, давая алгоритмические задачки.
Алгоритмические задачки позволяют проверить умение решать алгоритмические задачки — и больше ничего. Если кандидат натренировался решать задачку того типа, которая ему выпала на интервью — он её решит оптимальным образом.
Если он таких задач не решил — вряд ли вообще даст рабочее решение. И скорее всего, напишет нерабочий бред.
Программирование — это решение технических задачек, а не алгоритмических. То есть, задачек из реального мира. Адаптировать сервис А в связке с сервисом B на платформе C.
Человек либо умеет это делать, либо нет. Если он никогда об этом не слышал, ему не поможет даже опыт решения всего литкода. Если он это делал — это не вызовет затруднений. Если делал похожее и знает не всё — стэковерфлоу отлично помогает разобраться с неожиданными проблемами в тех частях, с которыми он незнаком.

Программирование — это решение технических задачек, а не алгоритмических. То есть, задачек из реального мира. Адаптировать сервис А в связке с сервисом B на платформе C.

Алгоритмические задачки — это модель реальных технических задач, которые можно решить за 40 мин. Если тебе нужно:

Адаптировать сервис А в связке с сервисом B на платформе C.

, а ты заимствуешь условные поиски по графам из собеседования в Google Maps команду.

это модель реальных технических задач

Ноль общего.
Какие алгоритмические задачки помогут адаптировать JetPack LiveData для постинга событий навигации по приложению?
Это чисто технические знания, там нет никакой науки.

ты заимствуешь условные поиски по графам из собеседования в Google Maps команду.

Я никогда не буду работать в Google Maps команде. Максимум — использовать Google Maps API в приложении, что абсолютно не потребует знания математического и научного аппарата их работы. Только знания API.

Алгоритмические задачки — это модель реальных технических задач, которые можно решить за 40 мин. Если тебе нужно:

Когда алгоретмические задачи встречаються реально в практике:
-Если есть готовая либа, то за велосипед скорей всего не похвалят.
-Если нашел книгу, или статью (в том числе стек оверфлоу), то это не минус а плюс, так как решение скорей всего проверялось кучей «умного» народу.
-Никто из за спины не стои, в монитор не втычит, на ухо нервно не дышит. Можно спокойно все обдумать.
-Если решил не за 40 минут, а за 3 дня — то не страшно, не уволят (ок, геймдев наверное исключение).

Ні-ні. Тільки алгоритмічні задачки на рівні 2-го курсу університету.

правда в том что в среднестатистической «галере» не нужно решать (только) алгоритмические задачи. а нужно решать проблемы широкого профиля. как мистер Вульф в Криминальном чтиве «я Вульф решаю проблемы. какие проблемы? -любые проблемы» . Там деплоймент сломался, там на проде что-то упало, тут надо какой-то костыль по быстрому креативно прилепить , потом откатить и смерджить. в учебниках всего этого не пишут и в университетах не преподают, так что джуны для такой работы как-бы не очень

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

Проблема в том что современный жаба синьйор кроме собственно языка, должен знать еще фреймворки и бд, докер, кубернетис, клауда, писать конфиги в helm и terraform, настраивать CI/CD и еще кучу вещей по мелочи. И когда на собесе тебя начинают задрачивать какими-то задачками которые ты решал 5+ лет назад — это, конечно, вызывает затруднения.

Не називайтесь тоді жаба синьйором і питання відпадуть

Ну это уже не вам решать кому кого как называть, у вас свое лекало, у других компаний свое.

Согласен. При желании можно на собеседовании любого синьйора завалить.
— «Не знаешь докера или терраформа? фуу не синьйор.
— «Не решаешь задачки уровня medium — hard? Не синьйор.»
— «Английский ниже advanced? Не синьйор.»
— «Работал всего с тремя базами данных? Не знаешь нашу БД, которую использует полторы компании в мире? Не синьйор»
— «Пишешь мало тестов? Не синьйор».
— «Не знаешь все изменения в каждой версии джавы? Не синьйор»
— «Не можешь написать баш скрипт для деплоя втутренних штук? Не синьйор»
— «Пишешь с багами? Не синьйор!!!».

Самое интересное, что таких людей нанимают!
Есть куча манипуляций которые позволяют не отвечать на такие вопросы.
Если кандидат при мне такое применяет, =*0.
Но есть люди с софтскилами вместо тех стека. Там так и получается, что *отбрехаться* — больше ок, чем зазубривание JavaDoc.

кєк коли влаштовуєшся в серйозну контору, а там все це очікують від señоr-a.

twitter.com/...​/1427926455976091653?s=19

Коллега придумал стартап, с помощью которого к собесу будет привлекаться консультант, который будет доказывать, что собеседуемый недостаточно квалифицирован и сбивать размер зп. Называться сервис будет «Он вам не сеньор»

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

Дивно, в цьому році сам був у ролі кандидата не один раз і якось не питали :) Тобто я розумію, що є те, що ви описуєте. Але є життя й поза докер, кубернетис, helm і terraform

Проблема автора рішається загоном усіх в офіс erbis і блокуванням в офісі stackoverflow)

Прекрасна думка. Якби автор заблочив Stack overflow, то всяких таких senior стало б набагато менше.

І зп можна меншу платити))

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

Я бы назвал это «google-driven development» / «junk information consumption». Проблема в том, что альтернативы — нормальных книг и мануалов — нет особо.

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

Як можна інакше робити,коли від програміста вже вимагають море технологій використовувати?

Проблема в том, что большинство технологии — г-но у которого нет нормальной документации. Нормальной документации нет потому что
1. забили
2. нет плана и вижина проекта

Таких полным-полно в любой сфере — программирование, языки, юриспруденция, медицина, строительство и т.д. Увы, высокий ценник результата не гарантирует.

Ни из текста, ни из комментариев ТС решительно не понятно при чем тут вообще Stack Overflow. Интервью не проходят люди, декларирующие наличие некоторого опыта? Ну так для этого и нужен процесс — чтобы отстрелить на подлете всяких самозванцев. Это не баг, это фича.

Осадок остаётся от осознания того, что так бывает. Я с такими людьми общался — человек не знает вообще ничего, но при этом умудряется устраиваться в какой-нибудь банк сеньором, наверно со stackoverflow как раз. Просто немного страшно становится за эти компании.

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

Вообще я и на доу видел фразы типа — если человек «токсичный» то каким бы он ни был отличным специалистом, то его нельзя нанимать, он типа не изменится, а вот хорошего человека якобы всегда можно научить. В результате сейчас везде очень добрые и общительные люди, которые вчетвером с трудом могут лампочку в крутить. Зато не «токсичные»

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

Колись Черчіль казав: «Якщо країна між війною і ганьбою вибирає ганьбу, вона отримає і війну, і ганьбу». Так от, якщо замість спроби найму інженера (з алгоритмікою, сис.дизайном, літкодом і так далі по списку вимог фаангів) компанія обирає найм «Програміста на мові Х під фреймворк Y версії Z», то вона отримуєте програміста, який може не знати ні мови Х, ні фреймворка Y, та й інженером не бути. І мати в резюме досвід от якраз виключно завдяки Stack Overflow Driven Development. Ну, бо знайти рішення якоїсь задачі в контексті трійки {X, Y, Z} дійсно швидше за все на Stackoverflow.

Господебожемой, да найдите для начала человека с продуктовым виденьем и стратегическим мышлением.
Какой там литкод и алгоритмы если разработчики не умеют ставить курсор в таблице модулем на секунды системного времени и хотят делать отдельно таблицу для анонимных сессий.

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

А Ильич вроде говорил, что нельзя верить цитатам из интернета.

Всі програмісти не інженери.

Вибачте, але у вас якась каша в голові

Если «простая задачка на логику» написана, как и эта статья, то не странно что у многих возникают проблемы с ее решением.

Начинается с «Що не так зі Stack Overflow?», дальше идут сеньоры в пересмешку с джунами, а заканчивается все пиаром «JakartaEE». Также автор добавил, что проект именно с Кремневой долины и разбавил все аналитикой с Eclipse Foundation’s.

Ну и напоследок, в одном из комментариев автор меняет изначальное условие и уже говорит, что: «Недолюблюю саме Stack Overflow Driven Development, а не Stack Overflow (до нього ставлюсь нейтрально)»

А де підміна? В заголовку явно значиться «Чому я недолюблюю Stack Overflow Driven Development»

тому що на проекті епічна технологія, як івно мамонта і SO не дає відповіді щодо неї

Приклад задачі подібної до тої, що даємо на співбесіді, є в коментарях. Так що можна оцінити

В том примере что вы указали — все понятно и должно быть относительно просто для любого дева без привязки к языку программирования. Если кандидат пришедший на сеньорную должность не смог ее решить — он или не был особо заинтересован в работе, или были проблемы в постановке самой задачи. Лично мне кажется, что было именно второе. Также, есть люди, которые просто нервничают на собеседованиях и не могут выразить свои мысли, при этом являются хорошими специалистами.
Ну и как-то вообще не понятно, к чему тут в итоге «Stack Overflow Driven Development». Данной практикой может пользоваться абсолютно любой человек не зависимо от должности или ранга. В ней есть как свои плюсы, так и минусы. Я не думаю, что все сеньоры сильно злоупотребляют данным подходом.

Проблем з постановкою немає. Окрім самого формулювання дається приклад інпуту і очікуваного аутпуту. Кандидатів явно заохочуємо уточнити якщо щось незрозуміло. Але зазвичай реакція: «Все зрозуміло. Дайте вже закодити» і потім страждання хвилин на 40, а то й більше.

Статья крайне интересная.

Если автор хотел захантить новых людей на собеседование — то ему стоило написать какие интересные технические задачи они решают.

Если цель статьи была пиар Jakarta EE — то тема не раскрыта, кроме как «это как Spring, но без кучи готовых вещей».

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

По теме.
Да, на рынке есть проблема, что кандидаты могут не знать (не уметь, не помнить) базы. И не только в разработке. В тестировании и автоматизации такое тоже повсеместно. И тоже интервьюеры «сокрушаются...».

Но откуда кандидатам помнить и знать базу, если
— они ее почти не применяют в повседневных задачах;
— большинство задач сводится к дописыванию бизнес логики в заготовку Spring Boot микросервиса;
— на большинстве собеседований в аутсорсинг компании тебя будут 2 часа задалбывать вопросами по API Спринга и базовых библиотек джавы, а не задачки на алгоритмы. И таких собеседований у нас 90%;

Кандидат, знающий и имеющий БАЗУ, спринг, джакарту, системный дизайн и задачки с leetcode — скорее всего пойдет или в местный интересный продукт на много денег или поедет собеседоваться в FAANG и компании рангом поменьше. Потому что, какой смысл это все готовить, учить и тратить время, чтобы потом работать в небольшой совсем компании и делать вообще неизвестный продукт. Если можно поехать пилить даже тот же Booking.

Deal with it or build technical brand.

Дякую за коментар.

большинство задач сводится к дописыванию бизнес логики в заготовку Spring Boot микросервиса

Щоб дописати бізнес логіку треба володіти мовою. На співбесіді це й перевіряється.

Кандидат, знающий и имеющий БАЗУ, спринг, джакарту, системный дизайн и задачки с leetcode — скорее всего пойдет или в местный интересный продукт на много денег или поедет собеседоваться в FAANG и компании рангом поменьше.

Так в нас запити скромніші: знайте базу і не крутіть носом при згадуванні джакарти.

Deal with it or build technical brand.

Задача не одного місяця.

Так в нас запити скромніші: знайте базу

То есть достаточно знание java core и алгоритмов? Это достаточное условие?

забыли самое важное —

і не крутіть носом при згадуванні джакарти.

Та просто щас окажется что надо еще знать кучу всего кроме этих двух требований

упомянутый в статье джун знал базу и решил задачки, но 5К ему так и не дали ;)

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

Навык умения искать и адаптировать решения, архитектурные например(а не тупо копипастить), важнее просто по тому, что в гугл влазит больше, чем в графу *достижения* в вашем CV.
А лицом по коду(в случае админов, по стойке😜) возить много ума не нужно.

Так не вміють :( Ми і таке пробували. От є задача відсортувати мапу, врахувавши і ключ і значення. Відповідь гуглиться елементарно. Але «синьйорний» кандидат проходить повз, бо в нього не спрацьовує трігер, що ось же воно.

В том же шарпе я раза 2 за жизнь эти компараторы встречал, зачем держать это в голове если оно гуглится и вспоминается за 1.5 минуты.
P.S. В java до сих пор нельзя просто передать лямбду в sort вместо создания компаратора?

Можна передати лямбду. І мій коментар якраз про те, що кандидат і нагуглити не може.

Из статьи выходит что кандидату дают жава док, гугл тут причем?

Як на мене то автору завидно що крабам платять по 5к, а в нього, крутого ліда, 4к:)
А піти на 7к не виходить бо англійської не знає або якісь таракани в голові

Увидел такие потоки сознания:
— Я тимлид ... проект с Кремниевой долины ... Как мощны мои лапищи! ( с ) , кстати мы нанимаем.
— Jakarta живее всех живых, стимулирует расти и развиваться, Spring — то такое, и вообще без StackOverflow не кастомизируется (<%Dunning-Kruger reference%>)
— StackOverflow для лузеров, настоящий инженер должен тратить в 5 раз больше времени для решения уже давно известных проблем cамостоятельно, иначе нещитово

Что из этого основное ?

Автор бросил курсы *Java за 3 мес по JavaDoc* почти под конец, а не в начале. 😁
И сам автор основной, тимлид целый.😇
И 5к дают.(но это не точно.)
(Просто троллинг, ничего личного или в серьез.)😝

Нічого з переліченого :) Основне написане, наприклад, в коментарі Тараса Чорноморця

Молодь вже не та пішла, а от раньше ми в vim самі алгоритми сортування писали, а зараз що? прийшлов сопляк, відкрив ide з автокомплітом, визвав метод sort() і воно все саме зробило. А як оце воно під капотом робить, нікому не цікаво. І тетріс на асемблері ніхто не напише. ох уж це покоління смузі пропаще...

Настолько тоненько, что можно порезаться...😃

До речі молодь є ще ого-го, а от ті, хто писав колись сортування самостійно, скисли

Молодь вже не та пішла ще із часів Платона. Як мінімум.
І кожне наступне покоління все більше і більше «не те», що раніше.

Ще раніше. Сократ всіх розбещив, за що його і стратили.

Ну в ті часи греки були дуже розбещені.
І кожне наступне покоління все більше «не те».

а покоління пепсі вже б давно мало сплавитися Дніпром

На жаль, у багатьох досі жива асоціація Java з EJB і іншими страшними речами 10-річної давнини.

На сколько я помню, в JEE уже давно (как минимум 5+ лет) не используется EJB (технология 2000-ых). Как так разработчики с опытом 5+ помнят эту «замечательную» технологию?

Згідно Вікіпедії, «інженер — це особа, яка на основі поєднання прикладних наукових знань, математики та винахідництва знаходить нові рішення технічних проблем». Нові рішення. А не відстежує відповіді на вищезгаданому ресурсі.
ми розглядали у тому числі і Java-інженерів з досвідом Spring.

Вам нужны инженеры или разработчики на Spring и/или JakartaEE? Если вы ищите узкоспециализированных разработчиков, то не удивительно, что у вас возникают вопросы к экспертизе кандидатов.

З.Ы. Картинка с фильма «300 спартанцев» и надписью что это джакарта как бы намек на то, что у джакарты нет будущего? В итоге греки проиграли войну персам :)

Нам потрібні інженери, які вміють самостійно думати і не цураються JakartaEE

Если вам нужны инженеры, то зачем же вы много пишете о JakartaEE? Не знаю, в каком оно сейчас состоянии — может быть «конфетка», а может быть «так себе». Пишите лучше о том, что разрабатываете, опишите чем интересны ваши задачи — наберете инженеров, а не программистов на спринге/джакарте и, возможно, неоправданный выбор JakartaEE (не знаю, судить не буду) прикажет долго жить :)

Не знаю, в каком оно сейчас состоянии — может быть «конфетка», а может быть «так себе».

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

Є ManagedExecutorService Можна самостійно використовувати Можна поєднувати з CompletableFuture Можна зробити як описано в arjan-tijms.omnifaces.org/...​chronous-alternative.html
І @Asynchronous з EJB теж працює

Якщо треба щось реактивне, то www.eclipse.org/...​september/reactive_mp.php

Т.е. частичная поддержка неблокирующего IO на уровне сервлетов. Если сравнивать со spring/vert.x/akka, то похуже будет, но жить можно. Это в плане оптимизаций/цены. Хотя, возможно, вам это и не надо, из статьи то не понятно, какие у вас задачи. Ну а если сравнивать спринг (сейчас на нем работаю, но это далеко не мой фаворит) и джакарту, то спринг получше будет, не говоря уже с какой скоростью он развивается. Так что ищите инженеров, а не программистов на спринге/джакарте и будет у вас все хорошо.

Как там с асинхроностью?
спрінгбут на мінімалках

Просто інші анотації. Спрінг пушить ВебФлакс, чуваки з ДжЕЕ просто не пушать (не розповідають по конференціях), але підтримка там точно є, як на рівні асинхронних сервлетів, так наче воно «реактивні оператори» називається, колись лайтбенд багато на цю тему розповідали.

Стопе, это когда это греки проиграли войну персам ? Я наверное в школе не ту историю учил. ru.wikipedia.org/...​ki/Греко-персидские_войны

я сравнительно недавно писал на EJB3 -это более новая технология но и то она устарела, бо в спринге все это есть давно. по сути тот же Спринг с аннотациями — transactions, security. на собеседовании про знание EJB3 никто не спрашивал (мало кто знает), типа если знаешь Спринг то и с этим разберешься

Ejb не про это, это про удаленный вызов процедур. Он умер из-за реста и соап по дороге прихватил. Транзакции отдельного были.

к статі, нє, там довго і нудно воювали....
на сьогодні Греція є, Персії нема
хто переміг?

Иран, это Персия. И в отличие от Греции он никуда не исчезал.

Kaк не исчезал? 560-летний промежуток эллинистического Ирана с 334 года до н.э. до 226 года н.э. (империя Александра Македонского — государство Селевкидов — парфянское царство), когда Иран исчез, превышает по времени 368-летний промежуток между падением Византии в 1453 году и образованием независимой Греции в 1821 году, когда Греция исчезла. И это если не считать 300-летнее пребывание территории Ирана в составе арабского халифата, когда также Иран исчезал. Так что и современный Иран, и современная Греция имеют весьма опосредованное отношение к тем государствам, которые вели греко-персидские войны...

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

Вот можно посмотреть на «индуский код» в «индуском стартапе» с капитализацией в 1 лярд. В Украине есть что-то подобное? Разве что playtika/wix, но они не украинские.

бачу потенційну суперечність, можливо терміни сплутані.
cosmopolitan — containing or having experience of people and things from many different parts of the world
тобто не може виключати Індію та Україну.
спробуйте перефразувати без слова космополіт, ширшою смисловою фразою.

і не розумію чому нас в Україні має пошта Індії відлякувати порівняно з Америки чи Чехії,
якщо наприклад наші колеги з Індії пишуть для перевезень по Україні в тому числі:
щойно закривав древні рев’юшки — наткнувся на квиток про українські індекси.

завжди радій дізнатися щось нове, правда «90% всього — ...».
мені дійсно важко зрозуміти як можна було протрактувати

...
Rating/booking/tracking API integrations with Czech Post and Blue Dart (Indian national post service).
...

як

как писать что то для облгаза

до речі, за фасадом DHL в Індії працює Blue Dart.

Stack Overflow Driven Development
не може вирішити на співбесіді просту задачку
JakartaEE

«мёд, говно и гвозди» ©

Кожен бачить щось своє :) Стаття не про це

Стільки тексту і скільки пихатості :)

Ключові слова ... erbis ... 21-80 людей...дніпро...проект три роки без розширення...я тім лід (певно все в uppercase)...приходьте до нас в компанію — запрошуємо до співпраці.

Та тут не пихатості, а скоріше суму :( Якраз розширюємося. І не 3 роки, а більше. І Jakarta EE ще треба додати до ключових слів :)

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

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

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

Jakarta EE — це як вивчити польську

Яке відношення Jakarta EE має до теми СтекОферфлоу девелоперів не зрозуміло.

Якщо ви вирішите спробувати сучасну Jakarta EE і впевнитися у її потенціалі, запрошую до співпраці.

Стопе. Ця стаття — це рекламка «ми наймаємо»? Якщо так, то вийшло так собі.

Я навіть сказав що вийшла анти-реклама, а не реклама. Але хайп зайшов.

Саму задачу не дам.
Але наведу приклад подібної до неї задачі. З тою ж ідеєю розв’язання і того ж рівня складності.
З введеного користувачем рядка треба вивести унікальні слова, відсортувавши за довжиною слова — від найдовшого до найкоротшого. При однаковій довжині сортувати в алфавітному порядку.
Що тут складного?

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

Це не задача на знання алгоритмів :)
Взагалі досить проста і дивно, що «сеньор» таке не розв’язав.

З мого досвіду бувають варіанти:
1) Найбільш розповсюджений. Чувак справді слабий. Так у нас на ринку є люди з 5+ років, які не можуть таке розв’язати.
2) Є люди які просто впадають в ступор при будь-якому кодінгу. Іноді бояться запитати про АПІ яке не пам’ятають. Зазвичай просто попросити проговорити перші кроки допомагає вивести кандидата зі ступору.
3) Кандидит вже на цьому етапі вирішив, що не зацікавлений у продовженні співбесіди.

От і мені дивно :( Якби це були поодинокі випадки, то не було б і статті
1) З таким і зтикаємося
2) Кандидати вирішують задачу в IDE і можуть вільно користуватися Javadoc. Це проговорюється ще на початку.
3) Не схоже. Бо кандидати витрачають по 40+ хв, намагаючись все ж таки подолати задачу

У меня прям болит, сколько было послано очкастых сетевиков в засаленных футболках, при попытке предложить мне посчитать 10-20 сеток на листике. По тому, что так не делается! У меня небыло и нет этого навыка. И в вакансии его нет, потому что вакансию в коллайдер, где нельзя телефон с калькулятором я еще не видел. Даже на северном полюсе уже есть инет. Хотя, там наверное и время покурить маны тоже есть.
Мой вывод, либо кто-то не тянет на свою лычку, причем по своей же метрике. Либо програмист нужен на Марс. Только там нужно именно знать, а не уметь находить решения.
Если бы вы, небыли тимлидом который 8/5 задает вопросы *где таски?* И тех вопросы оставили тому, кто каждый день гребет и может спросить поглубже но абстрактно. А сами оценивали как быстро выгорит если будет овертаймить нашару, или согласится ли еще фотошопить и девопсить.
Для всех, кто работает не с людьми а с предметной областью, чётко отделяйте вопросы не по теме. И помните, отвечать на то, что гуглится меньше чем за минуту, выдает в вас ждуна, который это пилит каждый день.
Админам 5к не предлагают😞 я бы наверное с гуглом минут за 10 решил бы, видя первый раз, и иде, и фреймворк.

Це не задача на знання алгоритмів :)
Взагалі досить проста і дивно, що «сеньор» таке не розв’язав.

Ніколи не розумів для чого ці задачі і що вони показують. За всю мою практику я такі задачі вирішував нечасто, а коли вирішував — завжди можна було мати досить часу, щоб продумати рішення, і не було вимоги вкластись в півгодини.
Людина може бути класним програмістом і завалити всі задачі, а може вирішити всі за хвилину, і бути ніяким програмістом.
Мені здається що це як міряти здатність воювати розборкою калаша на швидкість :)
Робота програміста має зовсім іншу природу, яка такими задачами ніяк не перевіряється.

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

Кандидати вирішують задачу в IDE і можуть вільно користуватися Javadoc.

И все? Токенайзер, сортированный сет, саму сортировку — это все надо самому писать в процессе решения?

Все. Токенайзер і алгоритм сортування писати не треба.

А если я не помню наизусть, как токенайзером разбить строку — можно погуглить? Или это как раз вкладывается в понятие SODD?

То есть, сам алгоритм мне понятен — токенайзером разбиваем строку на слова, пихаем в sorted-set, с сортировщиком «сортируем сначала по словам, потом по алфавиту», выводим содержимое на экран.

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

Требуется именно знание таких низкоуровневых АПИ, а не создание общей логики — я правильно понимаю?

погуглить можна)) на стековерфлов не можна)))

Не знаю, як автору вдається так писати, або вам так читати ) Але наче ж зрозуміло, що на їх співбесіді МОЖНА гуглити, навіть на stackoverflow заходити :-) Але помідори, що приходять до них часто навіть з інетом, IDE і доками не здатні вирішити такі задачки.

Наверное, проблема в том, что человек, которого это спросили, не знает про токенайзеры, трисет и компаратор. Я б такого тоже б не взял.

Так у нас на ринку є люди з 5+ років, які не можуть таке розв’язати.

Є люди, які як деведопери вже завели трактор, авс, клауд-хуяуд, 6-7 років досвіду і не знають що таке тред пул. Серьозно. Я бачив.

Є люди, які як деведопери вже завели трактор, авс, клауд-хуяуд, 6-7 років досвіду і не знають що таке тред пул.

Так і це демонстрація того, що треба відходити від мандсету «екзамен» і переходити на «чим ця людина буде корисна».

О! То, о чем я говорил уже лет пять назад, наконец-то приходит в массы

Саму задачу не дам.

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

О! Клёвая задачка на automation QA собеседовать :)

О! Клёвая задачка на automation QA собеседовать :)

Що ви хочете перевірити цією задачею?
ІМХО, задача не дуже для співбесіди, бо фактично перевіряє знання про ТріСет, що не найбільш затребувана структура.

Нормальна задача для джуніора чи мідла. От те вона і показує, чи може людина реально написати хоч пару рядків. Не раз бачив, як у людей елементраний for викликає нереальні складності.

От те вона і показує, чи може людина реально написати хоч пару рядків.

1) Якщо людина не вирішила цю задачу, то чи означає це, що людина не зможе писати код (особливо АКуА)?
2) Якщо вирішила, що це дає? Чи дає це гарантію, що людина зможе писати нормальний код на роботі? Як вам допомагають знання того, що людина вирішила таку задачу прийняти рішення що цього кандидата треба наймати?

На співбесіді час обмежений, і тому кожне питання має принести те чи інше розуміння куди і як кандидат може бути корисним. Але це якщо задача найняти працівника, а не впевнитись, що на ринку купа людей у яких «елементраний for викликає нереальні складності» (при тому, що з появою стрімів, все менше задач, які потребують роботу саме з циклами)

1) Якщо людина не вирішила цю задачу, то чи означає це, що людина не зможе писати код (особливо АКуА)?

Звісно.

2) Якщо вирішила, що це дає? Чи дає це гарантію, що людина зможе писати нормальний код на роботі?

Автор правильно написав: це необхідна умова, але недостатня. Саме тому співбесіда і складається із серії різнопланових питань.

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

Якщо вона нормально вирішила цей синтетичний приклад то і вирішить і реальну задачу схожої складності. По тому як вирішується задача складності Х можна спрогнозувати чи вирішить вона задачу складності Х+1. Звісно, все це припущення, непрямі докази проф. пригодності і т. п. Але іншого варіанту не дано. За таким принципом працює все: екзамени у ВУЗах, автошколі, армії, авіації, і т. д.

Цікаво, що ти пропонуєш взамін?

Але це якщо задача найняти працівника, а не впевнитись, що на ринку купа людей у яких «елементраний for викликає нереальні складності» (при тому, що з появою стрімів, все менше задач, які потребують роботу саме з циклами)

Ну так це і є дуже важливе питання, що дозволяє не " впевнитись, що на ринку купа людей у яких «елементраний for викликає нереальні складності»" а дозволяє таких відсіяти.

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

Як показує практика, потоки викликають ще більше складності ніж цикли. Інакше люди би не писали єресь у дусі
List<Foo> list = new ArrayList<>();
randomFoos.stream().filter(allow).forEach(f -> list.add(f));

По тому як вирішується задача складності Х можна спрогнозувати чи вирішить вона задачу складності Х+1.

Ось це ключова помилка:
Зі здатності вирішити просту задачу не слідує здатність вирішувати складніші, а тим паче інші (умовні КРУДи або проклікування автотестами).

За таким принципом працює все: екзамени у ВУЗах, автошколі, армії, авіації, і т. д.

1) Співбесіда — не екзамент. Проблема багатьої співбесід в майндсеті екзаменатор-студент.
2) В вишах, особливо зараз, все не так. Треба працювати семестр. Фактично екзамен дає можливість студенту довести наявність у нього хоч якихось знань, якщо він забивав весь семестр.
Про армію не зрозуміло. Там є спеціалізації і система рутинних задач. Умовний снайпер не стає автоматично кулеметником, зазвичай це окремі кваліфікації.
З авто та ж історія. Водійські права на легкову, наче не дають автоматом права на мотоцикл.

Цікаво, що ти пропонуєш взамін?

Кращу кодінг задачу :) Знову ж для КуА не знаю, бо я їх не наймаю. Для девелоперів це ті що включають роботу з ХешМапою/Сетом, роботу з заданим не завжди логічним АПІ, можливо рекурсію.
Приклад я вже писав тут багато разів, якщо коротко, то роздрукувати каталог по аналогу en.wikipedia.org/wiki/Tree_(command

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

Ось це ключова помилка:
Зі здатності вирішити просту задачу не слідує здатність вирішувати складніші, а тим паче інші (умовні КРУДи або проклікування автотестами).

Не думаю.

1) Співбесіда — не екзамент.

Часто чую це твердження на ДОУ. Якщо екзамен це «итоговая форма оценки знаний.», то на співбесіді і перевіряють знання. У тому числі і знання.

Про армію не зрозуміло. Там є спеціалізації і система рутинних задач. Умовний снайпер не стає автоматично кулеметником, зазвичай це окремі кваліфікації.
З авто та ж історія. Водійські права на легкову, наче не дають автоматом права на мотоцикл.

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

Кращу кодінг задачу :) Знову ж для КуА не знаю, бо я їх не наймаю. Для девелоперів це ті що включають роботу з ХешМапою/Сетом, роботу з заданим не завжди логічним АПІ, можливо рекурсію.
Приклад я вже писав тут багато разів, якщо коротко, то роздрукувати каталог по аналогу en.wikipedia.org/wiki/Tree_(command

Якщо чесно, tree та задача автора теми мені дуже схожі по смислу. Єдине, що, що твоя сильно більша по об’єму та часу. Також потребує знання FS API, що величезний мінус, як на мене. Як задача додому — мені подобається. А як на пару десятків хвилин (чи скільки там) для кодування на ходу... не думаю. Без документації її нереально написати.

кзамен по фіз. підготовці нічого не каже про бійця — на полі бою він же не буде по турнікам скакати

Крутий приклад, погугліть ACFT.

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

Не за моєю, а за вашою, бо я такого не казав, а воно прийшло вам (не мені) в голову.
Фізпідготовка та стрільба — це історія про комітмент, а не про саму підготовку. Ще різнийя армії і співбесіди в тому, що в армії ти живеш, і тебе армія натренує виконувати ті (рутинні) дії, що їй потрібно. Це я про нормальну армію.
Щодо гаража. Так ви загубили суть: я не казав, що не треба симуляції. Я сказав, що та конкретна є поганою. Бутафорскість не змінює реалістичності. Знову ж купа водіїв у нас не вміють паралельне паркування, але права їм якось видали.

Якщо чесно, tree та задача автора теми мені дуже схожі по смислу.

Скільки патернів можна застосувати до моєї задачі і до задачі ТСа? Які крайові умови кандидат може помітити в задачі ТСа і в моїй? Як вийти з задачі ТСа на багтопоточність та розподілені обчислення?

Єдине, що, що твоя сильно більша по об’єму та часу. Також потребує знання FS API, що величезний мінус,

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

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

Так само як і працевлаштовані програмісти, які не вміють програмувати.

Скільки патернів можна застосувати до моєї задачі і до задачі ТСа? Які крайові умови кандидат може помітити в задачі ТСа і в моїй? Як вийти з задачі ТСа на багтопоточність та розподілені обчислення?

Згоден. Я не кажу, що ваша задача гірше. Я лише стверджував, що ваша набагато об’ємніша.

Чомусь для мене було очевидно дати АПІ кандидату (там 3 метода), а ви чомусь вирішили, що інтерв’юер буде вимагати знання реального АПІ.

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

«Проста алгоритмічна задача» на співбесіді може просто вибити людину, яка їх постійно не вирішує.

А вам не здається дивним, що джуніор, який 100% буде хвилюватися на інтерв’ю, спокійно вирішить «найпростіше алгоритмічне завдання», а сеньйор з досвідом 10+ буде хвилюватися як першокурсник?

Может чувак просто пришел по приколу на собес, или захочел набить руку на собесах

було б можливо, якби не те що таких практично всі за останні три роки.

Ну в одном месте гайки крутить после универа со свежими мозгами — если это надо, то да, с другой стороны сеньор, скорей, всего в общих чертах и докер с кубером знает, основы секьюрити, что-то из паттернов по микросервисам, базы данных, настраивал какой никакой ci/cd и т.д. и это независимо от конкретной специализации. Но да, гайки крутить может лучше и джун, у него то только база в мозгах.

Бо, за великим рахунком, перейти (особливо сеньйору) зі Spring на Jakarta EE — це як перейти з української школи до польсько

Скорей как перейти с центрально украинского на западно украинский диалекты.
При подобном переходе отличия настолько поверхностные, что действительно читать книги, статьи. туториалы — оч влом, и солюшен хочеться тупо скопи-пейстить со стек оверфлова.

Річ у тому, що наш «Mature Senior» настільки звик гуглити й копіпастити, що підзабув основи мови, на якій кодить і самостійно будувати рішення.

Скорей задачи вы (аутсорс) дает ему такие что только копипейстом и решаеться. Давайте «интересные» задачи и синьйоры будут помнить как это решать.

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

якраз інденер поєднує і застосовує блоки та рішення придумані науковцями

Смешались в кучу кони, люди и залпы тысячи орудий
1. Инженеры часто действительно не помнят базовых вещей. В институте их делали и забыли
2. Вот я базовые вещи помню, что толку? Платить то больше по сравнению со стандартным спринг/хибернейт не хотят. А-то и норовят меньше, интересная работа мол.

Проблема не в тому, щоб все пам’ятати, а в тому. щоб не втратити навички думати самостійно. У нас на співбесіді дозволяється використовувати IDE та Javadoc у повну силу, але кандидатам це чомусь не допомагає :(

Большинство задач в АйТи отнюдь не на умение перевернуть строку. Поэтому знание алгоритмов превращается в шагистику в современной армии: когда-то это был вполне боевой навык, для боя в строю. Но с появлением пулемётов, оно конечно воспитывает умение подчиняться и вообще «шоб парядочек був», но практического толку мало

Но с появлением пулемётов, оно конечно воспитывает умение подчиняться и вообще «шоб парядочек був», но практического толку мало

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

Ровно как в реалиях армии презрительное отношение к шагистике является красным флагом того, что у человека проблемы с подчинением и выполнением приказов. Однако сам по себе навык практического применения в бою не имеет

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

Головний інженер ! = Senior developer
Головний інженер == CTO або архітектор

Архітектора на співбесіді точно не будуть навантажувати на співбесіді алгоритмічними завданнями.

Если по теме топика, то учитывая ваши замечания, получается так: Фрезеровщика или токаря 6 разряда просят заварить трубу. Причем *сварка* не их специальность, но стать сеньером не получится без базового понимания в ней. Про арматурщика с перегаром и дилемму связанную со скоростью/качеством раскрытом в моем превидущем сообщении нужно обьяснять?

Специально беру примеры из другой области, *жидко-скиловые* манипуляции уже откровенно надоели.😔

Я б перефразував. Не заварити трубу, а розповісти як заварити трубу.
Навіщо ваш слюсар-сантехнік повинен це знати? По-перше, щоб пояснити менш досвідченому колезі або наприклад проконтролювати результат.

Опять манипуляции, не слесарь а токарь. У слесаря *сварка* часть фулстека.
И не рассказать а сделать. Автор топика просил именно реализовать а не рассказать как.

Если вас, не устраивает, это не значит что неверно. (на всякий случай)
Аргументы, пожалуйста.

ні, без задачки стаття не стаття

не можна — задача занадто проста, а використовується як типова.
на чому сеньйори валяться, а юніори ні — Comparator на два поля.

не можна — задача занадто проста, а використовується як типова.

І чому ж не можна? Люди будуть гуглити ваші питання на співбесіди і точно знайдуть цю тему та зламають систему відсіювання? :)
Гарна новина в тому, що ви «Невловимий Джо». Знаєте чому він невловимий?

на чому сеньйори валяться, а юніори ні — Comparator на два поля.

Ніт
dou.ua/...​rums/topic/34464/#2206671

Це все тому шо зараз сініорське звання знецінилася, зараз будь-який вайтішник за рік в сініори промовтається ))

Omg EJB динозавр воскрес (навіть коли вони там 3.0) у вигляді зомбі. І всім почав казати що вони блін гірше за джунів тому що використовують платформу обміну знаннями, як то StackOverflow. На арені є Whyldfly і платний JBoss, а комусь ще треба конфігурити датасурси через UI control server-а WebLogic. Э ще везунчики у котрих IBM WebSphere із IBM jdk т.д. Як зараз пам’ятаю, редагуєшь такий собі JSP, локально JBoss — на сервері WebSphere (бо локально треба заплатити силлену грошей за ліцензії щоб поставити той апплікейшн сервер). Локально працює, — на сервері ні. Стандарти ! А от Spring Boot якась дурня, і на сервері паше і в будь якому клауді через кубернетес, і настройки із профайлами під будь який енв і смак. І зараз навіть без костилів інтегрується із SPA UI на Angular/React/Vue. І навіть тримає нагрузку і не вилітає з аут оф меморі при 2х гігабайтах пам’яті. Так не цікаво працювати! Іньша справа JEE/Jakarta EE написав собі Hello world,щоб піднялось запустив усього лише кластер із 4-х апплікейшн серверів які встановлював і налаштовував два тижні. Дав їм 12 гігабайтів пам’яті, отримав OutOfMemory налаштував колектор під профайлингом, відтюнив запрацювало — цікаво ж як! Правда закривають твій аккаунт, бо сусідні хлопці на Spring/Docker-Kubernetes/Postgress клепають проекти в тричі швидше і беруть собі всі закази.

Проблема в тому, що зтикнувшись колись з описаними проблемами, зробити висновок один раз і назавжди — це не зовсім інженерний підхід.
Щодо StackOverflow. Якби синьйори його використовували хоча б на 1% таким же чином як, наприклад, Vlad Mihalcea чи Jon Skeet, то можна було б говорити про обмін знаннями. Але ж ні. Розбиратися ніколи — дайте готову відповідь.

Ну буває і не раз, а навідь три п’ять (кожен день з 2010 по 2019) такий собі гуманітарний підхід. 2. Я щось чув що крім копі-пастити зі StackOverflow можна підти і відповісти на пару питань, бо комюніті така річь — цікава.

Та можна й відповісти, але роблять це одиниці, а копіпастять масово

ну, у меня рейт на SO около 2.5k — мне можно им пользоваться в работе? :-)

:) Я десь тут в коментах писав, що таких як ви — меншість

прям мою боль на прошлой работе описал

мне 300 лет я вышел из тьмы

Ігор, розкажіть в чому була суть задачі.

судя по всему что-то из разряда:
«вы работали со спрингом, и не работали с джакартой? Окей, как в джакарте сделать Х? Не знаете? Ну что же Вы, голубчик»

Таким не займаємося. Для розуміння. Приходить людина з купою років досвіду і не може написати нескладний компаратор або застосувати стріми.

а можна конкретніше що таке «нескладний компаратор»?

По суті комбінація 2 компараторів, які вже є в Map.Entry

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

Саму задачу не дам.

©

Все равно не очень понятно это задача была на логику и алгоритмы, или на память как выглядит Comparator -> thenComparing и т.п.?

Дозволялось на повну користуватися IDE та Javadoc :)

— Вам нужен был дизайн или подбор цветовой палитры?
— Можно пользоваться кисточками!

maybe maybe maybe

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

Ніякої асинхронщини. Можна писати й без стрімів, але обходити їх тільки тому, що ніяк не розберешся з ними, якось не синьйорно.

В общем, статья не всем зашла
задачу и вопросы в студию, мы здесь как бы инженеры и делать свои вывод хочется самостоятельно, а не читать и принимать как совет из stackoverflow (pun intended)

перейти (особливо сеньйору) зі Spring на Jakarta EE — це як перейти з української школи до польської

Хорошую аналогию привел — ее стоит рассмотреть шире. Что будет если человек, который в повседневной жизни использует преимущественно русский, сразу переключится общаться на украинском? Вот например я — мову я со школы знаю на отлично, проблем читать или воспринимать на слух — минимум (разве что если западенский говор и очень быстрый). Но если мне нужно писать или общаться на мове — то я очень сильно торможу. Потому что пере-проверяю мысленно каждое слово что бы не получилась «йолка» или «кровосиси» (позорный суржик).
Абсолютно то же получится, если программист, который долгое время работал на одной технологии или языке, выучит другой и начнет писать. Будет или намного медленнее — или масса глупых ошибок.
Что делает обычный человек, которому, например, нужно перевести на близкий язык? Например с украинского на белорусский? Он скорее всего воспользуется гугл-переводчиком. При этом результат будет заведомо лучше, чем если он попытается сам переводить со словарем.
Аналогично, когда у девелопера мало опыта в какой-то технологии или он просто не знает теории (например как транспонировать матрицу) — то найдя на Stack Overflow подходящий ответ он скорее всего получит результат лучше, чем пытаясь разобраться в формулах и сочинить алгоритм «на коленке».
В конце-концов: что делает программист, когда у него течет кран в ванной и нужно поменять прокладку? Умный, конечно, вызовет специалиста и получит качественный результат с гарантией. Но в современном ИТ ценятся «фулстеки», а не специалисты — поэтому правильный ответ: полезу гуглить видосик как разобрать кран, вырезать прокладку из старой камеры и потом все это собрать. С вероятностью больше 50% дело закончится потопом — но зато «настоящий мужик» (как и ты-ж программист) должен уметь делать все!
P.S. Нужны специалисты, которые знают как сделать без Stack Overflow? Тогда не ищите специалистов на Spring что бы потом посадить на Jakarta EE !

Тут дещо інша ситуація. Ближче буде така аналогія: людина заявляє, що знає англійську на рівні Upper Intermediate, але на практиці без словника нічого не розуміє.

Я пишу на джаве уже 20 лет. Но совершенно не помню, как прочитать текстовый файл или открыть коннект к БД.

Мне хотя бы позиция джуна светит? Или только трейни за 100$?

до 7-й джавы был совершенно дебильный интерфейс для работы с файлами. немудрено его не помнить наизусть

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

В конце-концов

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

Увы, но вы также скопипастили методику проведения интервью(как и «сеньоры» со стэк оверфлоу), без пониманя зачем это.
При том что вам нужен фреемверк девелопер, вы решили проверять скилы человека алгоритмической задачкой...
То что джун прошел интервью, а сеньор нет, говорит что методика тестирования работает через одго место.
Что показывает тот факт что задачку решил джун? Он будет перформить как вы ожидаете от синьора?

Сорня конечно но, АМ/КГ. Не умеешь собесить — не лезь.

Нам якраз не потрібен сферичний «фреемверк девелопер». Нам потрібні люди, які вміють думати самостійно. А коли «синьйор» намагається вирішити задачу навмання, а буває, не розуміючи підказок IDE, — це сумне видовище.

цікавий висновок, поясните на основі яких вхідних?

скопипастили
без пониманя зачем это

радий що ми узгодили погляд, що

«сеньоры» со стэк оверфлоу

я зацікавлена людина та помітив дві зноски що потрібен не формошльопер та не

фреемверк девелопер

задачка не алгоритмічна, принаймні у моєму розумінні -
алгоритмічні я, серед інших задач та питань, здавав у 2003
коли переходив зі стажера на юніора за 100$ (хто такі з/п згадає),
— генерація усіх щасливих білетиків,
— оптимальне узваження набору ваг (на жадібний пошук),
— пошук циклу у однозв’язнову списку.
решту не пам’ятаю.
а це задача на основу базового (тавтологія задумана) мислення.

алгоритмической задачкой

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

Что показывает тот факт что задачку решил джун? Он будет перформить как вы ожидаете от синьора?

це мабуть показує, що ми не можемо знаходити та запрошувати щирих сеньйорів.
проте це вже no true scotsman, бо ці що приходять (теж) є висооплачуваними.

конструктивні поради — ще кращий відгук.

Не умеешь собесить — не лезь.

Вы бы не лезли со своим мышлением к другим в голову. Дело в том что лиду и ключевому разраьотчику нужно понимать что не важно как думает программист, важно то как он выполняет поставленную вами задачу, сроки и качество. Нет, блт все лезут со своим «правильным мышлением и логикой».
Не нужен никакой мейджик, все что тебе надо на собесе просить что человек делал, какие задачи решал, почему решал так, а не иначе, если ты сам понимаешь как эти задачи решать то леко видишь что чловек делал правильно или нет. Спрашиваешь что за архитектура у приложухи была, что было в ней хорошо что плохо...Общее понимание важных вещей типа депенденси инжекшен и зачем он, какую проблему решает, или как писать тесты (если вы их пишете), что делать если запрос в базу тормозит(для бэкэндера) Что вам эти всратые алго задачки дают? Память на студенческие поделки? Ну студенты их щелкают ра ура...но сделать годное не могут от слова совсем. Заколупали уже.

Лучших сеньоров нанимаете? Щито? У вас там хоть 7К дают?
Ну и смаое главное — что сеньор делать будет? Месть легаси которое на западе уже никто и смотреть не хочет?

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

«Рынок перегретый до предела!!!»

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

просить что человек делал

до

если запрос в базу тормозит(для бэкэндера)

колись так і робили, і сподіваємося колись знову спитати, коли час лишить, який зазвичай типовий сеньйор витрачає весь через неспроможність кодити на своїй машині, на своїй IDE, зі своїми javadoc чи devdocs.io чи що завгодно.

колись давно було тет-а-тет з листочком,
а замість javadoc та code completion — питати всіх присутніх,
тоді все рухалося найкраще, правда і вакансій мало було.
до речі, купу людей що відсіяли тоді, зараз би взяли.
та люди що не могли писати код казали що винен листочок,
тож потім пробували давати вільну машину і звісно це був той ще треш -
схоже на відгук можливо несправедливо скривдженого про ті жахливі часи:
dou.ua/...​rums/topic/34464/#2207168
(до речі автора тоді не було серед тих зі злісною ухмилкою.
я був — треба буде якось вчитися з живими людьми спілкуватися -
хочеш як краще, думаєш що створюєш невимушену атмосферу,
а в результаті, кажуть HR, один бугай навіть у сльозах пішов)

ні я ні автор за кращих наче нічого не писали.
роблю висновок що це твердження еквівалентне
«non-SODD — (най?)кращі з розробів, й заслуговують мінімум 7к ойро»
і долучаю свої до Ваших променів любові усім non-SODD.
і на жаль так, такі бюджети у нас мабуть не доступні.

Лучших сеньоров нанимаете? Щито? У вас там хоть 7К дают?

так, звісно. таку тему гайпову лишили поза статтею (сіквел?!).
додам, все що ми всі без винятку робимо — це лишаємо legacy.
і ми всі від хтось хоче залишити краще і згадує правило бойскаута за дядьком Бобом,
до хтось жаліється що тут було насрано до нього і лишає неозвученим що він насрав ще більше.

Месть легаси

чому, найняти сенйора за копійки... вповні адеквати
було б дивно, якби навпаки джуна за рублі

Дивно то ви якось вмістили джунів, сеньйорів та Jakarta в один пост

Недолюблювати Stack Overflow лише за те, що ним зловживають, це те саме що недолюблювати ніж за те, що ним можна когось зарізати.

Постійно збільшувати дозу.

Недолюблюю саме Stack Overflow Driven Development, а не Stack Overflow (до нього ставлюсь нейтрально)

Звісно джуну не дали 5к :) А от сеньору таки дали копняка. Бо задача хоч і проста та наближена до повсякденних задач проекту. Тобто ніяких інвертувань бінарного дерева чи чогось подібного.

Якраз ні. Просто цінуємо базові знання більше за тимчасові та поверхневі

Ні, ми до недавнього часу джунів взагалі не набирали. Стали поглядати в їх сторону, коли не один раз наткнулися на Senior Java розробників, які не знають Java (і річ не про якісь рідко вживані можливості)

І знову ні. Орієнтуюсь на статистику ДОУ і вакансії, які мені пропонували цього року

Достатньо, щоб пройти ораклову сертифікацію :) Не все знаю, але чимало. Конкретні цифри назвати не можу. Вище медіани того, що отримують Java синьйори з 10+ років досвіду

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

через === чи як зараз модно?
з.і.
просто сінойр, не жава

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