"Но при этом хочется сказать, что во всех компаниях есть испытательный срок, и обман достаточно легко вскрывается,"
Не надо надеяться на испытательный срок. Вы как нанимающий менеджер пропускаете время на адаптацию этого чела. положим это месяц. Дальше вам нужно тратить своё время, чтобы доказать что чел некомпетентен - если контора белая, а чел "опытный" - тот ещё гемор. Ну и потом вам надо начинать подбор заново - это время. В общем с квартальным планом завязаным на эту ставку пролетаем. оно надо? :)
В моем мировоззрении работодателю не нужен никакой высокопроизводительный качественный код от сеньора, а нужно стабильное решение бизнесовых проблем до финальной точки. А уж решается это через высокопроизводительный код или через подметание полов - это дело десятое.
Если мы говорим не полуподвальной конторе, где разработчик это автомотовелофототелерадиомонтёр, то между ним и бизнесом есть: продакт, аналитик, тимлид в конце концов. И они на вход выдают ему ТЗ на разработку. Если этого нет и разработчик получает на вход "нарисуй мне кунгуру" или "придумай чтобы на складе было чисто", это лишь говорит о качестве процессов разработки в конкретной организации. Конечно, он может съездить в поля, чтобы посмотреть что там вообще происходит или рассказать свой опыт на тему бизнеса, это только плюс для него. Но это прежде всего РАЗРАБОТЧИК. И он должен в первую очередь качественно выполнять свою основную функцию. Если он классно "трещит" с бизнесом, но для того чтобы закодить задачу ему надо изучать азы техстека компании, то он не на своём месте как разработчик.
"...Недавно я сходил на с десяток собеседований, и они меня очень сильно разочаровали...Максимум он специально для собеседования повторил..."
Очень странно, что человек проходил десяток собеседований и не обратил внимание, что требует текущий рынок труда. Тут сразу возникнут вопросы, а как он может "выяснить требования у бизнеса", если есть такие проблемы с коммуникацией? Уже если не после первого, так после второго собеса должен сформироваться список "что хочет рынок, что надо подтянуть".
"...И потом всё это реализовать на ЛЮБОМ языке программирования...Да, загуглит он, как создавать функции, классы и т.д. ..."
Штука в том, что "загуглит" - это как раз про джуна, тут работодатель не ожидает, что чел быстро войдёт в проект и обычно делает скидку на то что чел не сильно бьётся по техстеку. А вот сеньёр должен максимально быстро войти в проект и сразу писать высокопроизводительный качественный код на техстеке работодателя, а не гуглить "что такое бин в спринге". Исключение это обычно, когда работодатель понимает, что с рынка на свой экзотичный техстек никого не возьмёт.
"А ведь хорошая идея - попросить программиста написать бинарный поиск."
бинарный поиск это не КМП. А вот показать что ты не имея в памяти решения в общем то не самой сложной задачи можешь написать кодик - это большой плюс для соискателя.
"Но обычно бывает совершенно другая ситуация: приходишь на работу и слышишь: "Смотри, у нас тут есть табличка в БД, её надо вывести в CRM"."
А потом (реальный случай):
--У нас всё тормозит, нужен срочно ДБА. Х, сделай, чтонить, индекс там какой или типа того!
--Какой индекс, когда у вас тут все запросы вида "селект звёздочка фром табличка" и вся работа влючая фильтрацию на бэке?
"допиливать под довольно типовые задачи энтерпрайза" если у вас большая корпорация типа СберАвитоЗона, то все паттерны и типовые задачи с высокой степенью вероятностью за вас уже сделаны разработчиками "платформы". А вот избыточная вариативность скорее вредит: чем проще и "стандартнее" код, тем проще засунуть "на весло" новичка, чтобы он загребал жсоны в кафку.
PS есть опыт разгребания "разного" на c#, java, go - в общем гошный код читать легче, даже если он написан "наркоманами".
ИМХО, тут дело не только в классике "чем нам плох орм". В моей картине мира тимлид/сеньёр должен уметь "покрутить", поанализировать базейку запросами. Как свою, так и витринку в olap по своему домену. А они могут быть нетривиальными.
"...Вообще с чистым SQL в современном энтерпрайзе работают мало и редко... По моим ощущениям, им этот ответ не понравился, и в целом мне показалось, что оценили мои навыки в этой части низко..." Насколько я знаю, в озоне пользоваться ормами запрещено за исключением узкого круга ненагруженных админок. Так что "фи" на эту тему достаточно предсказуемо.
"Дистрибутив и библиотеки языка Hare полностью помещается на трёхдюймовой дискете" - Не уверен, что нонче большая часть разработчиков понимают, что такое "трехдюймовая дискета" и зачем она нужна. Так себе "киллерфича".
"... например, нужно сделать профиль риэлтора. Никаких больше вводных — и инженер уровня Е5 должен сам разобраться в ней, задать вопросы тимлиду и спрогнозировать сроки реализации...." Как по мне - это красный флаг для собеседуемого, что с процессами разработки в этой команде очень плохо. В команде аналитиков нет, продактов нет, задачи формулируются в виде "нарисуй мне кунгуру". Тимлид тупо пересылает на уровень ниже задачи валящиеся сверху на него: либо сам завален работой, либо занимается личными делами в рабочее время (такое тоже видел). Из своего опыта могу сказать, что на тестировании в этом случае тоже часто экономят. PS Я как разработчик сам в своё время на такое пару раз осознанно подписывался, но там на старте говорили "у нас ..опа, тебе надо придумать как вытащить из неё проект на котором ты будешь ведущий".
"Самое большое преимущество монолитов в простоте их развёртывания." удивительно как эта байка о простоте развёртывания монолита гуляет так долго. Наверное это для приложений: фронт->бэк->база без связей с другими системами. Если ваш монолит это база на несколько терабайт обвешанная сервисами разной степени мутности как новогодняя ёлка с кучей интеграций, то развёртывание этого монолита станёт весёлым и затейливым квестом.
Ваш рекурсивный запрос прямо говорит, что на универсальной базе в принципе хранение дерева реализуемо. Собственно, почему выбрано узкоспециализированное решение с его известными проблемами (ниже уже описали)? К примеру: "в ходе проектирования выявлено, что большинство запросов будет такого вида, мы провели бенчмарки и установили что arangodb выигрывает на такой нагрузке в N раз, а остальные запросы выполняются не хуже, поэтому...". PS Даже если в компании уже "пробовали", вы как минимум попадаете на повышение требований к конкретной команде, вам сложнее будет брать людей с рынка на редкое узкоспециализированное решение.
"Но при этом хочется сказать, что во всех компаниях есть испытательный срок, и обман достаточно легко вскрывается,"
Не надо надеяться на испытательный срок. Вы как нанимающий менеджер пропускаете время на адаптацию этого чела. положим это месяц. Дальше вам нужно тратить своё время, чтобы доказать что чел некомпетентен - если контора белая, а чел "опытный" - тот ещё гемор. Ну и потом вам надо начинать подбор заново - это время. В общем с квартальным планом завязаным на эту ставку пролетаем. оно надо? :)
Если мы говорим не полуподвальной конторе, где разработчик это автомотовелофототелерадиомонтёр, то между ним и бизнесом есть: продакт, аналитик, тимлид в конце концов. И они на вход выдают ему ТЗ на разработку. Если этого нет и разработчик получает на вход "нарисуй мне кунгуру" или "придумай чтобы на складе было чисто", это лишь говорит о качестве процессов разработки в конкретной организации. Конечно, он может съездить в поля, чтобы посмотреть что там вообще происходит или рассказать свой опыт на тему бизнеса, это только плюс для него. Но это прежде всего РАЗРАБОТЧИК. И он должен в первую очередь качественно выполнять свою основную функцию. Если он классно "трещит" с бизнесом, но для того чтобы закодить задачу ему надо изучать азы техстека компании, то он не на своём месте как разработчик.
Очень странно, что человек проходил десяток собеседований и не обратил внимание, что требует текущий рынок труда. Тут сразу возникнут вопросы, а как он может "выяснить требования у бизнеса", если есть такие проблемы с коммуникацией? Уже если не после первого, так после второго собеса должен сформироваться список "что хочет рынок, что надо подтянуть".
Штука в том, что "загуглит" - это как раз про джуна, тут работодатель не ожидает, что чел быстро войдёт в проект и обычно делает скидку на то что чел не сильно бьётся по техстеку. А вот сеньёр должен максимально быстро войти в проект и сразу писать высокопроизводительный качественный код на техстеке работодателя, а не гуглить "что такое бин в спринге". Исключение это обычно, когда работодатель понимает, что с рынка на свой экзотичный техстек никого не возьмёт.
бинарный поиск это не КМП. А вот показать что ты не имея в памяти решения в общем то не самой сложной задачи можешь написать кодик - это большой плюс для соискателя.
А потом (реальный случай):
--У нас всё тормозит, нужен срочно ДБА. Х, сделай, чтонить, индекс там какой или типа того!
--Какой индекс, когда у вас тут все запросы вида "селект звёздочка фром табличка" и вся работа влючая фильтрацию на бэке?
"допиливать под довольно типовые задачи энтерпрайза" если у вас большая корпорация типа СберАвитоЗона, то все паттерны и типовые задачи с высокой степенью вероятностью за вас уже сделаны разработчиками "платформы". А вот избыточная вариативность скорее вредит: чем проще и "стандартнее" код, тем проще засунуть "на весло" новичка, чтобы он загребал жсоны в кафку.
PS есть опыт разгребания "разного" на c#, java, go - в общем гошный код читать легче, даже если он написан "наркоманами".
ИМХО, тут дело не только в классике "чем нам плох орм". В моей картине мира тимлид/сеньёр должен уметь "покрутить", поанализировать базейку запросами. Как свою, так и витринку в olap по своему домену. А они могут быть нетривиальными.
"...Вообще с чистым SQL в современном энтерпрайзе работают мало и редко... По моим ощущениям, им этот ответ не понравился, и в целом мне показалось, что оценили мои навыки в этой части низко..."
Насколько я знаю, в озоне пользоваться ормами запрещено за исключением узкого круга ненагруженных админок. Так что "фи" на эту тему достаточно предсказуемо.
Хороший повод не давать жене карточку "на реснички". Давно ждали такой закон.
PS Интересно как будут обходить "опа, да я ж потерял карточку! спасибо что нашли! Люблю родную милицию!"
"Дистрибутив и библиотеки языка Hare полностью помещается на трёхдюймовой дискете" - Не уверен, что нонче большая часть разработчиков понимают, что такое "трехдюймовая дискета" и зачем она нужна. Так себе "киллерфича".
не задавался таким вопросом. вероятнее всего в следующей будет с маленькой буквы.
"... например, нужно сделать профиль риэлтора. Никаких больше вводных — и инженер уровня Е5 должен сам разобраться в ней, задать вопросы тимлиду и спрогнозировать сроки реализации...."
Как по мне - это красный флаг для собеседуемого, что с процессами разработки в этой команде очень плохо. В команде аналитиков нет, продактов нет, задачи формулируются в виде "нарисуй мне кунгуру". Тимлид тупо пересылает на уровень ниже задачи валящиеся сверху на него: либо сам завален работой, либо занимается личными делами в рабочее время (такое тоже видел). Из своего опыта могу сказать, что на тестировании в этом случае тоже часто экономят.
PS Я как разработчик сам в своё время на такое пару раз осознанно подписывался, но там на старте говорили "у нас ..опа, тебе надо придумать как вытащить из неё проект на котором ты будешь ведущий".
0) весёлые мультфильмы никогда не заменят хорошую документацию
1) ловите багу:
у вас "ус отклеился"
а где документация на эту штуку?
"Самое большое преимущество монолитов в простоте их развёртывания." удивительно как эта байка о простоте развёртывания монолита гуляет так долго. Наверное это для приложений: фронт->бэк->база без связей с другими системами. Если ваш монолит это база на несколько терабайт обвешанная сервисами разной степени мутности как новогодняя ёлка с кучей интеграций, то развёртывание этого монолита станёт весёлым и затейливым квестом.
Ваш рекурсивный запрос прямо говорит, что на универсальной базе в принципе хранение дерева реализуемо. Собственно, почему выбрано узкоспециализированное решение с его известными проблемами (ниже уже описали)? К примеру: "в ходе проектирования выявлено, что большинство запросов будет такого вида, мы провели бенчмарки и установили что arangodb выигрывает на такой нагрузке в N раз, а остальные запросы выполняются не хуже, поэтому...".
PS Даже если в компании уже "пробовали", вы как минимум попадаете на повышение требований к конкретной команде, вам сложнее будет брать людей с рынка на редкое узкоспециализированное решение.
А всё-таки, каковы основные причины что вы решили пойти в историю с ArangoDB кроме того, что рекурсивный запрос postgre выглядит не сильно красиво?
Это будет когда голова пешехода войдёт в KPI
"Архипелаг гулаг" вспомнился:
"... Мы покатываемся за своими столами и почти одновременно приходим к одному и тому же стишку:
Из этого РАЯ Не выйдет ни … !
"
" Блокировку Rutube в Турции заметил только сам Rutube" Вы уверены? Вангую, что в рутубе эта тема была в числе последних среди разговоров "на кухне".