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

Як співбесідувати сіньйорів-помідорів?

Хело,

Сьогодні п’ятниця, того можна вияснити це дуже важливе питання.

Дано:
— вакансія(ї) де треба бути сіньйором-помідором
— треба знати конкретний фреймворк на рівні сіньйора-помідора
— треба вміти працювати з БД на рівні сіньйора-помідора

Кароч, що питати потенційних 23-літніх архітекторів?

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

Найкращі коментарі пропустити

Ну, как правило, у сеньоров спрашивают нетривиальное, типа:

Если кинут баг под ноги, его фиксить или переступить?

Есть Ангуляр дроченый и Реакт точеный, на чем сам писать будешь, что другу посоветуешь?

Есть два воркспейса, на одном легаси проект развернут, на втором — багофикс унылый, за какой сам сядешь, куда мать посадишь?

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

Перше, що б я зробив, це поклав би перед ним тарілку з сирами по 500 та по 250. Якщо сіньйор поклює тільки сири по 500, та не доторкнеться до тих, що по 250, то це перша ознака, що перед вами саме сіньйор, а не його симулякр.

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

В якості третього завдання треба запрошувати до кабінету джунів та мідлів. Небагато, щоб не налякати. Справжній сіньйор швидко згуртує девелоперів навколо себе та почне, як квочка, розповідати цікаві історії про сучасні фреймворки, та як він в далеких N-х патчив KDE під FreeBSD.

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

Синьор сам всё спросит и вас прособедует)

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

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
— треба знати конкретний фреймворк на рівні сіньйора-помідора
— треба вміти працювати з БД на рівні сіньйора-помідора

Синьоры отличаются не знанием конкретного фреймворка или умением работать с конкретной БД. Они отличаются тем, что 1) тянут на себе проекты и ведут команды 2) решают проблемы.
А изучение очередного фреймворка, да базы данных из «зоопарков» — это для чела с опытом и мозгами, максимум неделя работы.

Соответственны и критерии для собеседования/выбора синьора:
— убедиться на собеседовании, что чел знает что такое проблемы на проекте и умеет их решать
— что чел способен много работать и нести ответственность за проект
— что у чела есть хорошие и отличные рекомендации от прошлых работодателей/клиентов, подтверждающие пункты выше (без таких рекомендаций, бывают не синьоры, а лишь «коты в мешке»)

Но платить такому синьору придётся не детсадовские 4-6к/мес, а совсем другие, «взрослые» деньги.

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

Действительно, что тот же спринг изучать, неделя работа )

>спринг изучать, неделя работа

в принципе, даже меньше...

На уровне хелловорлд — вполне. А галерам больше и не требуеться...

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

Глядя на рисунок, ответьте на следующие вопросы:

Давно ли ребята занимаются туризмом?
Хорошо ли они знакомы с домоводством?
Судоходна ли река?
В каком направлении она течёт?
Какова глубина и ширина реки на ближайшем перекате?
Долго ли будет сохнуть бельё?
Намного ли вырастет ещё подсолнух?
Далеко ли от города разбит лагерь туристов?
Каким транспортом добирались сюда ребята?
Любят ли в этих местах пельмени?
Свежая ли газета? (Газета датирована 22 августа)
В какой город летит самолёт?

это тетка с большими сиськами
это тетка с сиськами поменьше
а это совсем как вы, но с сиськами ©

Глядя на рисунок, ответьте на следующие вопросы:

Давно ли ребята занимаются туризмом?
Хорошо ли они знакомы с домоводством?
Судоходна ли река?
В каком направлении она течёт?
Какова глубина и ширина реки на ближайшем перекате?
Долго ли будет сохнуть бельё?
Намного ли вырастет ещё подсолнух?
Далеко ли от города разбит лагерь туристов?
Каким транспортом добирались сюда ребята?
Любят ли в этих местах пельмени?
Свежая ли газета? (Газета датирована 22 августа)
В какой город летит самолёт?

Показує квадрат Малевича

кагбэ

горит неравномерно

делает бессмысленным

Резать веревки

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

просто хотят порезать веревки и по нормальному время уже потом часами засекать

Это потому что стоп-слова не знают

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

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

Я не люблю хамить. 8-) А вообще
------------------------------------------------------------------------------------------------------------------------
Знак «Закрой поддувало» ставился перед пешеходными настилами и мостами, которые находятся под паровозом. В старину из-под паровоза прилично сорило из топки на путь горящими хлопьями шлака и кусками пылающего угля. Путь, по которому ходили паровозы на твердом топливе (уголь, дрова, сланец, торф), был всегда узнаваем. Были случаи, когда целые станции сгорали из-за поджога деревянных шпал и брусьев упавшим паровозным жаром. Знак «Закрой поддувало» заставлял паровозную бригаду закрывать в опасном месте зольник. На новых паровозах выпуска 1930-1950-х годов стояли большие бункерные зольники, сквозь которые шлак из топки просыпался гораздо меньше, однако знаки «Закрой поддувало» еще долго продолжали стоять, пока паровозы не ушли совсем.

---------------------------------------------------------------------------------------------------------------------

Не, харасмент был бы если «открой поддувало!»

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

Так вы оказывается можете быть интересным собеседником :)

Да, как раз незадолго до этого сдуру прочел один из томов Ракова 8-) как раз про переходной период 50-х годов.

начал девочке подробно рассказывать о правилах работы с паровозом на перегонах

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

поздняк, меня уже пару лет назад спрашивали -_-

На собесах вроде спрашивали попроще — полттора часа отмерять.

*надо переставать читать поперек. Не заметил, да, полтора часа* — это зачеркнуть

upd: стоп, какое полтора часа? 45 минут. Учитывая решение которое мне «впаривали» это не могло быть полтора часа. Надо не поперек читать, а в исправления вдумываться :D

в самых странных компаниях два часа просят отмерить двумя веревками, которые горят по часу :) все хотят резать все равно!

Проверка на то достаточно ли хорошо ты слушал условие задачи?

это было на границе иронии и сарказма :) все персонажи выдуманы, а совпадения случайны

ставить в ближайшей церкви свечку

но свечку поджигать с обоих концов

но свечку поджигать с обоих концов

Неравномерно

если нарезать веревки на отрезки сколь угодно малой длины epsilon (дальше я думаю сами знаете)

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

к стати не плохой вариант, сначала сделать хеш веревок, а потом их сравнивать.

не, серьезно. Хешируем 2 веревки до равномерной консистенции. Результирующий дайджест будет гореть 2 часа. Делим его на 8 частей, 3 поджигаем, вот тебе и 45 минут. Какую хеш функцию блендера использовать это уже другой вопрос. Бар рейзер так сказать.

умение делить порошок на равномерные дорожки это тоже скил.

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

во-первых, даже если оппонет считает, что время фундаментально дискретно — попросите его ОБОСНОВАТЬ свой бред (петлевую теорию квантмеха).

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

действуйте как Иисус, короче — вопросом на вопрос.

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

в смысле, под неравномерностью горения имеется в виду «тухнет»?

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

Со смузи понятнее?

не очень. какие ингредиенты помимо веревки?

два смузи из веревки этому господину

два пива из веревки этому господину

не очень. какие ингредиенты помимо веревки?

Никаких.
Но веревка должна быть конопляная, конечно.

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

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

то че больше сжечь тем лучше?

То через 45 минут вам с собеседующим будет уже абсолютно все равно, что там была за задача и интервью будет пройдено на ура.

Есть 2 веревки

достатньої довжини, щоб вистрелити собі в ногу

Есть 2 веревки разной длины. Про них известно, что каждая, будучи подожженной с одного конца, горит ровно час. Но горит неравномерно. Вопрос. Как с их помощью отмерить 45 мин

Принцип_неопределенности_Хайзенберга.txt

Ну как вариант сложить одну веревку пополам, а вторую не складывать, поджечь, когда сгорит первая (сложенная вдвое), теоретиЦки пройдет полчаса. После этого огрызок второй веревки тоже сложить пополам, ждать, пока догорит. Но это если «неравномерность» горения никак не влияет на горение в сложенном виде. Не гуглила, но ща пойду перепроверюсь, что ли)

мой малой притащил ее в распечатке «олимпиадных» задач в немношк другом антураже — про финал футбольного кубка (2 тайма по 45 + в случае ничьей 2 тайма по 15), сломаный (ну как всегда) секундомер и ШЕСТЬ веревок по одному часу
в этом варианте любителей резать можно дополнительно унижать вопросм «если уж допускается резать, то нафига веревок целых шесть?»

Идет урок. Учительница спрашивает детей:
— Маша, кем ты хочешь быть?
— Балериной!
— А ты кем хочешь быть, Витенька?
— Космонавтом!
показать полностью... Идет урок. Учительница спрашивает детей:
— Маша, кем ты хочешь быть?
— Балериной!
— А ты кем хочешь быть, Витенька?
— Космонавтом!
— Вовочка, а ты кем хочешь быть?
— Сексопатологом!
— ??? Объясни...
— Очень просто. Посмотрите в окно. Видите, там идут две девушки и едят мороженое. Причем первая лижет, а вторая сосет. Как вы думаете, кто из них замужем? Учительница (краснея):
— Hу, ... наверное, та которая сосет...
— Hет. Та у которой кольцо на руке. А вот таких, как Вы, я и буду лечить.
©

В задачі не вказано, що треба відміряти 45 хвилин часу. Значить будемо відміряти 45 хвилин кута! :D

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

Ти ще врахуй перехід на різні орбіти й яку вони при цьому виділять енергію

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

для число в 1...100 делаем {
начнем {
сервис.спросить(число)
}.затем { строка в
печатать_линию(строка)
}.а_вдруг_что { ошибка в
обработать(ошибка)
}
}

ще не забудем питання від HR
www.yaplakal.com/forum2/topic509653.html
найулюбленіше
«Считаете ли вы окружающих идиотами, и если нет то почему?»
s00.yaplakal.com/...​original/7/1/8/578817.jpg

Я оце вакансії дивився й надибав прекрасне на сєньорську посаду

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

Мдя. Краще ніж тисяча слів.

Можно сократить еще

Уміння доводити роботу до кінця

А юнит тесты — это уже конец, или только начало ?

До речі, цікаве зауваження! Патерни зараз ніхто не питає ващєєєєє, мене жодгого разу не запитали, ріальні!

Один хлопець запитав як би я реалізував кейс (ну і дав опис шо треба зробити), я зразу сказав що це називається патерн СТРАТЕГІЯ, а він і не знає шо воно таке ))) довелося на пальцях пояснити, звісно відповідь була коректною.

В порівнянні з 10-ми роками тупо на кожній співбесіді примушували згадувати максимум патернів а то ще й реалізацію пояснити.

Походу ми котимося в СОЛІДний адок, хлопці.

Просто те, кто их спрашивал укатили спрашивать алгоритмические задачки 🙂. На самом деле, есть много чего спросить поинтереснее паттернов.

на миддла на каждом втором собеседовании спрашивают

Паттерны и ООП уже не в моде.

Патерни зараз ніхто не питає ващєєєєє,
я зразу сказав що це називається патерн СТРАТЕГІЯ, а він і не знає шо воно таке ))) довелося на пальцях пояснити, звісно відповідь була коректною

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

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

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

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

Потому, что мне не важно, знает он пять паттернов, или нет. А то, как умеет думать. А человек, который вучил пять паттернов, далеко не факт, что умеет думать.

вопрос: чим помогає в сапорті кровавого легаці кода знання патерноу?

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

Потому что таки да в реальности там «приходят малогуру и суют свои паттерны во все дыры а оттуда течёт кровь и простите говно» (к)

Собственно по последнему сценарию и пишется всё то «кровавое легаси» ))

суют свои паттерны во все дыры а оттуда течёт кровь и простите говно" (к)

— Доктор, когда я вот так вот делаю у меня болит..

— А вы вот так вот не делайте

ну тут работает другое правило когда кто-то тупой то ему хорошо а больно всем вокруг ))

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

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

Єй вы тут полегче. Я мидлом не могу устрится на тех интервью синьерские вопросы задают(типа расшифровать Солид, что такое буква Л.Отвечаю, что это Лисков, кто такая Лисков не знаю. Беркову знаю, а Лисков нет

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

Ради интереса пришел домой/на работу, скачал, прочитал

за вечер?

Сміх сміхом, але, наприклад, мені після «Верёвки достаточной длины...» та ще кількох більш давніх книг, читати креавтив Мартіна, окрім як по діагоналі, дивлячись в одне око якийсь серіал — не хотілося; як зараз пам’ятаю, розтягнуте на чотири+ сотні сторінок капітанство, подекуди у вкрай максималістичній формі

читати креавтив Мартіна

Що даже Гру Престолів точніше Песнь криги то вогню не осилів?

Беркову знаю

А буква О — Ocean Aletta.

Слава безвизу. Можете называть порохоботом)
bookalettaocean.com/rates

Это теоретически или на практике?

Беркову знаю, а Лисков нет

Если рассказано было про личное знание (познание) оной девицы, то тогда не взяли из зависти. (На самом деле из опасения заразится)

(На самом деле из опасения заразится)

меня терзают смутные сомнения с учётом того как можно заразиться

ну не вопросы ж по патернам Берковой задавать

А чо, призвать Патриарха (Andrii Vereshchaka) шоб он растележил,как правильно поддувалом работать в паттерне паровозик.

оепт 8-)
а хто такая беркова ? єто хто-то из виагры ? лень в гугл лазить

говорят, беркова сама заменяет виагру. врут, поди..

ну и хрен с ней. мне это неинтересно

мне это

уже

неинтересно

?
:)

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

Ржал долго 8-)
Не, правда, мне пофиг на них. погуглил — это девушка, бывшая на одном из сезонов русского издания Дом. Ну и что ? Я эту фигню , кажется, Дом-1 пару раз посмотрел — чепуха полная..

Отож. И нема чого туди лазить, чого там не бачив. Дівка як дівка, тільки у хфільмах знімали про кохання.

Начал проходить собеседования в иностранные компании: земля и небо. Как здесь уже упоминали другие люди, спрашивают о реальных кейсах как в моих бывших проектах, так и как бы я решил ту или иную проблему, стоящую перед командой в которой собеседование. Аббревиатуры из теории когда упоминаются, то в качестве обоснования предлагаемого решения, никакого опроса как в школе у доски «что значит буква L в SOLID».
Собеседование в украинскую компанию и в немецкую — это как ездить на украинском автомобиле или на немецком. Уж простите, коллеги-собеседователи, но это так.
Земля и небо.

У меня, по моей специфике, и тут и там одинаково спрашивают.

Стоит наркоман, смотрит в небо.
Прохожие останавливаются, спрашивают;:
— Эй, что ты увидел?
Он:
— Там...
Смотрят, не видят. Толпа растет. Смотрят, не видят, спрашивают снова:
— Что там, что?!
— Там...
Уже заполонили улицу, движение остановилось, все смотрят в небо, мужчины, беременные женщины, дети, пенсионеры. Не видят! Орут:
— что там, чтооо? Что там?
Он:
— Тааам, парирурам...

Сидит обкуренная сова. Мимо пролетает воробей. Сова ему:
— Там!
Воробей летит дальше и думает: «Что „там“?» Возвращается к сове.
— А что «там»?
Сова, выпучившись:
— ГДЕ???

Один раз меня собеседовал выходец из постсовка и это было так же хорошо, как с гражданами ЕС. В Германии он прожил 4 года на момент собеседования.

Собеседование в украинскую компанию и в немецкую — это как ездить на украинском автомобиле или на немецком.

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

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

копроративных ценностей

Товарищ Фогол тонко подметил всю низменную суть капитализьмы !

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

И чем это отличается от галер.

приємно чути, що десь у світі є нормальні «техліди» :) Особливо порадувала буква Л. Я для себе вже вивів ознаку: якщо SOLID — привабливість вакансії зменшується вдвічі, якщо «буква С» — вдесятеро, «Л» — далі співбесіду можна переводити на тролінг.

стисняюсь спросить:
С — Скрам
Л — люксофт?

ID — замінник паспорта, ідентичний натуральному. Без ГМО.

Ок, а SOLID чем тут виноват?) И сразу сопутствующий вопрос: какой шанс, что человек, которого ты наймешь и который даже в теории с этим SOLID не знаком вдруг начнет его у тебя на проекте применять и вытаскивать его из говнокода? Получается давайте все скатимся в говно и им коллективно обмажемся потому что все равно нормально никак не получится?)

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

угу, называется common sense

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

Ну, может быть по совокупности всех признаков такая индикация и возникнет, но сам факт вопрошения о SOLID ни о чем таком сходу не скажет. До тех пор, пока ты сам не начнешь собеседовать собеседующего, это будут всего лишь домыслы. А узнать лютый ли у них говнокод в Авгиевых конюшнях, можно как раз таки вступив в обсуждение этого самого SOLID и подробно расспросив дядю о том, каким конкретно образом они эти принципы у себя применяют. Какие у них вообще стандарты качества установлены? Есть ли линтовщик? Какие требования к прохождению код ревью и слиянию в рабочую ветку? Обязательно ли покрытие всего нового кода тестами?
Я, по крайней мере, еще не встречал такого, чтобы откровенно врали в лицо. Обычно люди честно говорят, мол, да есть процентов 20 говнокода от индусов, но новое пишем уже год по SOLID и в TDD. И тогда логично, зачем они спрашивают про SOLID и TDD.
В целом, я понимаю откуда у местной публики такое отношение к баззвордам типа SOLID или Scrum — все говна наелись на украинских галерах и наслушались бреда на собеседованиях. Но убогость рынка говорит всего лишь об убогости рынка, а не о несостоятельности этих принципов и практик, которые, чтобы там ни говорили пропогандоны ебаного айти, все таки, с успехом применяются во многих командах разработчиков. Жаль, что в основном, не в наших широтах.

Согласен. Но я за то, чтобы уметь проводить разделительную черту между зашкваренными галерами и годными практиками, которые из-за этих галер страдают. А то народ начитается говна в интернете, а потом приходит на собеседования и рассказывает с гордостью, что они вертели на пне всякие солиды, паттерны и прочие архитектуры, потому что на DOU и e.it сказали, что это зашквар и что нормальный программист должен уметь кодить руководствуясь common sense (что в переводе означает «должен уметь на каждом проекте переизобрести велосипед»).
«Чтобы видеть дальше, нужно стоять на плечах гигантов» — это не про наших программистов.

Типа ты не знаешь что такое интерфейс, синглтон и фабрика.

А названия какие были?

Суть этих книжек в том чтобы обозвать одну и туже вещь одним и тем же именем чтобы облегчить коммуникацию между разных девелоперов.

это называется «справочник» или «словарь»

Так а чем книга банды 4-х не словарь ?

Букварь для варваров

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

Ага зато сейчас в моде говорить что ООП — фигня, и толпы хомячков говорят что ООП фигня.

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

Так ООП дійсно фігня. Для деяких типів задач. А для певних задач — шикардося.

они как хомячки тупо следуют моде и толпе.

Это человекам вообще свойственно.

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

+100050000

В 2008 на всех собеседованиях спрашивали как реализовать Singleton. В 2011 на всех собеседованиях спрашивали почему Singleton использовать нельзя. В 2018 о существовании Singleton никто не помнит.

Без него иногда не обойтись.

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

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

популярних бібліотек

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

Dependency Injection.
Можно достучаться из *любого окна* != доступно для чтения+изменения из *вообще любого места в проекте*.

И чем это будет лучше? По факту ж одно и тоже: один и тот же инстанс доступен во многих классах проекта (разные экраны и тп), только доступ к нему будет не синхронизирован (а это уже минус).

А при чём тут синхронизация?
Представь себе, что таких сессий у тебя может быть две (ну, бывают же парные игры).
Синглтон спокойно превратится в «мультитон», или просто в два объекта, а ссылка на него будет лежать в контексте, который будет проброшен в каждое окно (или окно может его спросить у своего владельца).
Синхронизация же — совершенно другой вопрос — она одинакова и для одного объекта на приложение, и если таких много.

Интсанс будет доступен только в тех местах, где нужен.
Классы не будут жестко связаны друг с другом, что позитивно скажется на поддерживаемости кода. Могу порекомендовать ознакомитться с DI, это намного лучше Singleton.

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

Ведь, создать этот инстанс и потом передавать его в параметры.

В Composition Root все конфигурится. Или как вы DI готовите?

а якщо композішн рутів більше одного?

Тогда что-то не то с пониманием что такое Composition Root.

треба попіклуватися трошки про те, щоб він був один на апплікуху

Это все решается в Composition Root.

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

Спринг головного мозга

Спринг головного мозга

Ты так говоришь, словно это чтото плохое.

Ну, вопрос широкий). Разные контейнеры могут давать разный инструментарий, но в основном достаточно тонко всё можно настроить.

Инстансы объекта с зависимостью, по-хорошему, создаются контейнером с помощью его API, а не через конструктор, чтобы подтягивались все зависимости... условно container.createInstanceOf(typeof(Type)) вместо new Type(). Создавать объект через new, а затем его зависмость через new с передачей параметра в конструктор — это «DI руками».

Если же это MVC контроллеры с зависимостями, то их и создавать не нужно, например — само всё подтянется контейнером...

В целом, если кто-то захочет создать зависимость в рандомном месте руками, а не через контейнер, то она создастся, конечно, и будет овер 1 инстанса без гарантий, да. Здесь универсального ответа нет, и DI — далеко не серебряная пуля, тем более, что замена синглтона далеко не является целью DI как такового.

DI контейнер менеджит это за нас. Например, если, как в кейсе из обсуждения, задать какой-то зависимости синглтон скоуп в конфигурации, то при создании первого объекта с синглтон-зависимостью, контейнером создаётся её инстанс, который будет висеть в памяти и инджектится во все новые объекты с этой зависимостью уже готовым.

Ну, справедливости ради, как минимум а некоторых контейнерах такой скоуп даже называется аналогично — синглтон). Хотя с формальными плюсами согласен, даст ли это что-то на практике реально в конкретном кейсе, даже не знаю... надо смотреть, не готов что-то утверждать.

Лал, теперь это скажи авторам SIP и др подобных библиотек, API аудиовывода и доступа к камере во многих ОС и тд.

Перечитай то что ты написал еще раз, принципиального профита это не даст.

Перечитай что ты написал еще раз

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

DI взагалі ні до чого до сінглтону. Якщо ви уважно подивитися на кишки спрінга то здивуєтеся скільки там всередині сінглтонів.

Тем хуже для Спринга. Джава-мир я вообще не назвал бы примером хорошем дизайна.

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

Для исчерпывающего определения хорошего дизайна здесь не время и не место.
В контексте обсуждения. Хороший дизайн ведет к поддерживаемому коду, плохой — к неподдерживаемому. Singleton означает сильное связывание классов. Сильное связывание ведет к плохо поддерживаемому коду.

В предыдущем сообщении я DI не упоминал.

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

Я в 2011 отвечал что делаю их так @Singleton

Только потом приходят такие «опытные» мидлы-синьоры, не знающие даже теории, и кому-то приходится разгребать еще более дикие Авгиевы конюшни после них самих...

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Краще генераліст )))

Смотря что за «опыт» у обоих. Может быть такое, что первый — опытный гений багфиксинга на легаси проекте и именно такой человек и нужен, тогда толку от знания теории вообще нет (как в общем-то и смысла ее спрашивать).
Если же проект/продукт новый и пишется с использованием best practices, то есть шанс, что второй кандидат поймет что от него хотят быстрее потому что хотя бы теоретически уже в курсе; и есть риск, что первый будет въезжать в разы дольше просто потому, что в силу своего опыта считает, что все надо делать не так, потому что привык что на предыдущих проектах все делалось по-другому и надо было на вчера.
Ну и тот случай, который вы скорее всего имели в виду — когда первый действительно опытный, а второй только вызубрил теорию и ничего не может на практике — тогда конечно первый лучше.
Вот только как это проверить на собеседовании? И сколько нужно лет работать (и на скольких проектах, разных по сложности), чтобы самому дойти до понимания всех тех особенностей разработки, которые десятки лет формировались у гораздо более опытных разрабочиков/архитекторов которые перенимали опыт друг друга?

теории чего? большого взрыва?
если человек может решить конкретный юзкейс, но не помнит/не знает как называется паттерн это проблема?

Если может — это не проблема. Но практика показывает что далеко не всегда может (качественно).
И я не про паттерны сейчас, а про SOLID. Зубрить значение каждой буквы нет смысла, но если человек хоть в общих чертах может рассказать что это/обяснить принцип стоящий за какой-то буквой (даже если не помнит название и ему посдказать) — это как минимум показывает что человек чем-то интересовался из мировых best practices, а не варился годами в однообразном легаси-болотце.

мировых best practices

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

есть отличная общемировая практика. назвается «здравый смысл». вот ее и надо применять

Призываю тебя дать определение «здравому смыслу» таким образом, чтобы я мог его сейчас показать джуниору и он все понял и начал его применять. Или чтобы я смог с минимумом лишних слов сказать коллеге «а давай-ка используем здесь здравый смысл — это поможет нам избежать массы проблем в будущем», и он мне в ответ: «верняк! сейчас рефакторну с применением здравого смысла и через час скину на ревью».

Призываю тебя

не надо меня призывать, я ж не демон

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

т.е. как только ты говоришь: «джуниор! SOLID!», джуниор делает стойку на задних лапках и бежит его применять?
бугагашеньки

«джуниор! SOLID!», джуниор делает стойку на задних лапках и бежит его применять?

Хоть ты и утрировал, но в целом — именно так. Потому что это систиматизированные знания, которые предельно легко доносить друг другу на код ревью, идентифицировать проблемы с помощью хорошо систематизированных code smells и исправлять отработанными поколениями разработчиков рефаторингами.
То есть будет примерно так: «джуниор, здесь нарушен SRP, выполни extract class и пару extract method». Nuff said.
Джуниор не знает, что такое SRP и extract class — кидаю ссылку или отправляю на курс доп. подготовки (хотя таких джунов на моей практике еще не было).
Давай теперь вернемся еще раз к «здравому смыслу», его определению и эффективному применению в коммандной разработке. Если не хочешь писать своими словами, дай ссылку на материал, где об этом будет хорошо написано (и чтоб там не было ни одного баззворда), так как будто я твой джуниор и не могу понять, что ты от меня хочешь.

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

«напиши как умеешь, а на кодревью узнаешь как надо»
аминь

«напиши как умеешь, а на кодревью узнаешь как надо»

Мощно

Интерфейс должен быть полон и непротиворечив. Причем сильно нежелательно в нем делать больше 7 функций (без учета служебных, типа set/get config). Лучше не больше 3-х

Отличный принцип. А какое ему обоснование с точки зрения ООП, кроме того, что человеку легко 3 метода в памяти держать?
Можно не отвечать — умные люди уже подумали, нашли ответ и оформили в виде богомерзского баззворда «Interface Segregation Principle».

следовать учению очередного гуру

карлос софтанеда

пимпл или фабрика

а что у них общего?

хм. и какая это цель?

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

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

Проблема в том, что рядом с одним опытным 10 неопытных. И даже если он это всё понимает интуитивно, то молодёжь — надо учить.

Я вот уже неделю ругаюсь страшными словами на «попэрэдныкив», которые заплели одну компоненту так, что невозможно разобрать. Там полный комплект перекликающихся друг с другом проблем:
1. Две параллельные иерархии классов, которые делают примерно одно и то же (и узлы в них одной и той же роли), но назначения распределены примерно поровну, и идут кросс-вызовы между ними.
2. При этом объекты классов второй иерархии временами создаются дважды (если там есть XBase, XA, XB, XC и параллельная ей YBase, YA, YB, YC, то в XA используется объект YA, а в XB, XC тоже есть YA, но есть одновременно YB и YC, в другом поле). Часть инициализаций вызывается и из YA, и из YB (YC), и они «прикольно» так интерферируют между собой.
3. В сценарных тестах даже самого нижнего уровня запускаются компоненты и моки, которые нужны верхним уровням, и в результате тесты рандомно вылетают, когда эта инициализация получает обгоны в использовании нижних компонент. Чуть другие внешние условия приводят к тому, что запросы к DB проваливаются непонятно куда без ответа, а когда рядом впараллель инициализируется тестовая DB, невозможно понять, какой запрос вызвал проблему.
4. При этом ко всему в дополнение, часть тестов по непонятным причинам не пишет лог (потому что сохраняющий логи xmlrunner использован в необычной манере). Поэтому часть проб распутать делалась вообще вслепую.

Зато всё это с использованием самых новомодных фишек языка, которые были на тот момент, и с нулём документации.

Наблюдая это всё, я готов перейти на позицию «пока человек не доказал, что он чего-то стоит, у него все эти SOLIDʼы должны от зубов отскакивать даже ночью посреди сна». И применять их к юниорам в принудительном порядке. И только начиная с синьора можно позволить отходить от них — потому что такой будет знать сам, когда их не надо нарушать.

ИМХО как раз у синьоров больше всего есть смысл спрашивать — с джунами и даже некоторыми мидлами может быть такое, что слова они вызубрили, но в реальности не понимают что они значат потому что им не попадались яркие примеры ситуаций где это применимо... Ну и синьоров с десятком лет «опыта», не знающих ни теории ни практики, я видела. К тому же, несколько странно если человек синьор, но никогда не интересовался best practices.

никогда не интересовался best practices

Так они постоянно меняются ) Может он уже устал учить одно и то же по кругу для «продвинутых» интервьюверов, а пишет так, как подходит к случаю. А вы ему — синглтон это хорошо или плохо?

Так «одно и то же», или «постоянно меняются»?
А если серьезно, мне действительно интересно, как тогда синьоров собеседовать. Если верить на слово резюме, то можно нарваться на человека получившего лычку за выслугу лет а не за опыт/вклад в проекты.Тут в треде где-то мелькало сообщение, что человек на вопрос о том, что такое SOLID, ответил что-то в духе «писать код хорошо» — ну ок, а что значит «писать код хорошо»?

а что значит «писать код хорошо»?

а что мировые бест практицес на это говорят?

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

Совершенно верно. И знание (и опыт применения) таких практик как SOLID, CQSP, паттернов, архитектур и прочих «баззвордов» — это возможность для этих двух умных людей вести так называемый high-bandwidth conversation. Потому что там, где нормальный синьор скажет «мы передавали зависимости через Dependency Injection, что позволило нам легко использовать test doubles в юнит тестах» и позволит интервьюверу безошибочно понять его с первого раза, там сторонник «здравого смысла» и противник «баззвордов» будет полчаса невнятно блеять и жестикулировать, рисуя в воздухе какие-то абстрактные интерфейсы, конструкторы и прочий language specific bullshit. И будет это похоже на разговор двух умных людей — только одного на английском, а другого на французском языке. С некоторым шансом проскакивания знакомых слов с каждой стороны.

вести так называемый high-bandwidth conversation.

— SOLID?
— SOLID
— поэл (ик)

А можна я розшифрую, що таке «писати код добре».

  • Твій код мусить бути таким, щоб через пів року ти сам зміг його прочитати. Це значить, що треба давати коректні назви змінним, методам, функціям, тощо. Менше коментарів — краще код.
  • Він мусить вирішувати не тільки задачу «на зараз» або «в лоб», а ще й трохи розрахований на майбутні задачі. А це трохи краща архітектура коду в цілому.
  • Код мусить бути fail-safe та fault-tolerant. Його крихкість мусить бути зведена до мінімуму.
  • Код мусить вирішувати певну задачу, а не підлаштовуватися під інструменти, утиліти, патерни, БД, тощо.

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

Гарна архітектура — це архітектура, яка задовольняє всім вимогам проекту. Для кожного конкретного випадку гарною буде своя власна архітектура, розрахована на даний випадок. Але, при всьому цьому є ряд особливих рис, які мусять бути в будь-якій архітектурі.

  • KISS (Keep It Simple, Stupid) Не треба переускладнювати те, що не вимагає складнощів. Це не значить, що треба писати код «в лоб», це значить, що код мусить залишатися простим в підтримці та змінах
  • Архітектура мусить бути модульною. Викинути одну систему/інструмент/технологію/мову програмування та прикрутити нову мусить бути не складно
  • Вартість підтримки мусить наближатися до нуля. Якщо архітектура вимагає з кожною новою ітерацією все більше ресурсів, то це погана архітектура

ОК, я признаю что это хороший ответ на мой вопрос в том виде в каком я его задала...
Но в целом это чересчур общие слова. Что такое хороший код и архитектура должен знать даже джун, отличие синьора в том, что синьор должен понимать, как этого достичь. При том, что у каждого проекта своя ахитектура и one size fits all решения не существует, есть набор более конкретных техник и принципов, следование которым обычно приводит к построению хорошей архитектуры, и часть из них были для удобства собраны в SOLID.
Это круто, если вы за свою карьеру дошли до тех же самых принципов самостоятельно, но все же это крайне маловероятно так как SOLID — это собрание многолетнего опыта множества людей. И читая коментарии в этой ветке у меня складывается впечатление, что половина присутствующих пытаются на ходу собрать теоретический велосипед и при этом изо всех сил защищать идею о том, что их велосипед лучше/не уступает уже готовому решению выложенному другими (скорее всего гораздо более опытными) людьми.

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

нельзя слепо следовать чужим велосипедам

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

хороший сеньор всегда найдет хорошую причину

Но в целом это чересчур общие слова.

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

что синьор должен понимать, как этого достичь.

Сіньор мусить досягати цього, а не тільки розуміти. Розуміння + досвід + реалізація = успіх.

и часть из них были для удобства собраны в SOLID

СОЛІД не про архітектуру. Взагалі. Це принципи. Я можу побудувати архітектуру на антипатернах, та вона буде кращою за ту, яка побудована по «солідних» принципах. Наприклад, реактивний підхід + подійне програмування може працювати краще для певних задач, але бути побудованим антагоністично до SOLID принципів.

но все же это крайне маловероятно так как SOLID — это собрание многолетнего опыта множества людей.

Ну, по собі не треба все міряти. Я останні 13 років розвиваю патерн під назвою СПП (структурно-подійне програмування). Більше для себе, а не для загалу.

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

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

для любых задач

Не згодний. Класичний приклад — DOM. Це верхівка вдалого використання ООП в задачі опису структури. Так, потім вже можна згори прикрутити події, але не замість.

но событийное программирование — слишком сложно для современных т.н. девелоперов

Тому що в подійному програмуванні тобі не допоможуть ані IDE, ані тести, ані SOLID. Але саме цей тип програмування є найбільш наближеним до реального світу та може описувати процеси, які в ньому протікають. Класичне ООП принципово не може вирішити цю задачу.

для любых задач
Не згодний.
Але саме цей тип програмування є найбільш наближеним до реального світу

никакого противоречия не чувствуете?
таки да — событийное программирование это реальный мир
и еще:

Класичний приклад — DOM. Це верхівка вдалого використання ООП в задачі опису структури

описание структуры — еще не программирование

никакого противоречия не чувствуете?

Ні, тому що я казав про опис подій, а не об’єктів.

описание структуры — еще не программирование

Тоді ОО в слові ООП не про програмування теж. ;)

ООП

объектно
ориентированное
проектирование
угу?

и тебе привет

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

Знать — легко, инфы на уровне определения приведенного выше полно в интеренете, и гораздо более детальной.

Вот только чтобы «инфа» стала «знанием» нужна сущая мелочь — практика.

Заучить формальное определение каждой буквы вовсе не значит «знать».

ЗЫ: если уже на то пошло то если и спрашивать за L т.е. полагать что человек уже уровня готового за это отвечать то спрашивать в ключе «а вот L значит то-то и то-то было ли у вас такое? как решали? как может лучше было бы б порешать? как порешали бы б сейчас? как лучше не решать?» и т.д. и т.п.

Потому что само «знание абревиатуры» совершенно бессмысленно имеет смысл только непосредственное понимание каждой буквы достигнутое личным опытом либо хотя бы б личными рассуждениями «а я вот сам догадался а оказывается такое уже есть придумали до меня» а ну ок значит правильно догадался значит есть серьёзный реальный шанс что и далее человек продолжит «догадываться правильно» либо сам либо не сам читая и обмозговывая и применяя на практике в т.ч. и чужие «принципы и догадки».

Если человек до этих принципов сам не способен догадаться то и знание их ему не помогут я проверял.

Поле чудес: угадал все буквы, но смог прочесть слово.

что значит буква L в SOLID

Братан не повіриш, буквально вчора мене тіп питає «шо таке SOLID». Ну я такий «базворд для виразу „пишіть хороший код“». а він такий нє, нє, ну це ж принципи їх корисно знати. я йому розказав що харе базаріть базвордами краще налашутвати на проекті статичний аналізатор і затягнути всі гайки які тіки можна, у вас код автоматично стане СОЛІДним. зі мною не дуже погодилися. ну і ок.

короче перший раз така фігня.

Забув додати, кажу ж я тому хлопцю шо я більше вірю в rubocop ніж в соліди-драї, а він мені такий «ну...в нас теж є рубокоп але білд він не фейлить». «Все з вашим солідом зрозуміло», подумав я, але виду не подав. Зате мені поставили відмітку «не знає бази» про що не переминув згадати менеджер на наступному інтерв’ю.

Братан не повіриш, буквально вчора мене тіп питає «шо таке SOLID». Ну я такий «базворд для виразу „пишіть хороший код“». а він такий нє, нє, ну це ж принципи їх корисно знати. я йому розказав що харе базаріть базвордами краще налашутвати на проекті статичний аналізатор і затягнути всі гайки які тіки можна, у вас код автоматично стане СОЛІДним. зі мною не дуже погодилися. ну і ок.

А как можно согласиться, если это разные вещи абсолютно?) Солид — про абстракции, линтер — про мелочь «вот в этой строке у тебя какая-то фигня подозрительная, обрати внимание, ну и на форматирование своё страшное». Анализатор не скажет «вот так вот классы сделай, а этот разбей на два, а здесь можно абстрактный выделить на толпу, да и вообще здесь должно быть два модуля по-хорошему, а не один». Или одну функцию скажет разбить на 3 по-человечески именно вот так вот, ага).

линтер — про мелочь

комплітлі дізагрі
по перше не тільки лінтер, а статичний аналізатор коду. це тобі не eslint в джаваскріпті. рубокоп вміє багато всяких метрик, ну а під комбінацію checkstyle+findbugs+pmd можна такий рулсет зробити шо девелопер буде замість години тиждень готувати свій коміт щоб він пройшов усі перевірки.

аналізатор тобі скаже шо в тебе цикломатік комплексіті овер 9000, аналізатор тобі скаже шо в тебе в класі методів більше ніж треба, аналізатор тобі скаже що в тебе клас залежить від 10 інших тому давай розбивай, аналізатор скаже шо в тебе методи великі і тд

коротше кажучи ви просто не вмієте їх готувати, або ніколи реально не використовували на проектах жорсткі налаштування

звісно один аналізатор не гарантує відсутність гавна, але аналізатор дозволяє мені не думати про соліди і драї, бо курва мать, я і так не можу написати сильно зв’язані два класи, або великі методи, білд впаде все зломається нафіг.

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

читайте Єгора256 www.yegor256.com/tag/quality.html в нього все чьотко розписано.

але аналізатор дозволяє мені не думати про соліди і драї, бо курва мать, я і так не можу написати сильно зв’язані два класи, або великі методи, білд впаде все зломається нафіг.

По такому описанию — анализатор именно что заставляет о них думать). Просто по непонятным причинам это многими воспринимается как «раз сказали солид, значит я пишу и мысленно перебираю в голове паттерны, чтобы ничего не пропустить», хотя все и так понимают, что солид — это банальный здравый смысл, и никто паттерны не перебирает специально. Т.е., в таком случае, чем объясняется подбор метрик для правил? Почему именно Х строк методы — норм, а Х+1 — нет? Почему Y зависимостей — норм, а Y+1 — нет? В итоге, почему так бомбит выражать ответы на эти вопросы терминологией солид (шмолид, любой другой общепринятой) на собесе?) Вот это «бунтарство» реально непонятно.

все и так понимают, что солид — это банальный здравый смысл

від мене вимагали по буквам назвати

Вот это «бунтарство» реально непонятно.

Я без руля, для мене базворд без метрик це фігня. Запам’ятовувати абревіатуру я вважаю дебілізмом. В мене регістр 4 розряди тільки на signed DRY та максимум GTFO вистачає, SOLID вже «базворд максимум розрядність оверфлоу» викликає.

Почему именно Х строк методы — норм, а Х+1 — нет? Почему Y зависимостей — норм, а Y+1 — нет?

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

від мене вимагали по буквам назвати

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

Тому шо ми с пацанами вирішили що в нас макс левел гавна отакий. в когось може бути інакшим.

Человек на собесе хочет узнать, как соискатель работает с абстракциями. То, что накрутили в анализаторе, не дает ответа, что будет дальше. «Мы накрутили, и теперь не сможем писать плохо, потому что правила повалят билд» — такой себе ответ, если вопрос состоит в том, откуда взялись эти правила, и почему. А то хрен его знает, может и билд не соберётся никогда теперь)).

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

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

И третья — когда метрики безосновательны. Тогда это будет подобие карго-культа.
— Почему в методе 21 строка кода?
— StyleCop так сказал.

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

Вопрос не в том, как это будет имплементиравано (с помощью гаек), а что будет имплементировано (какие принципы) и почему. Судя по постам, откуда взялись метрики и почему именно такие (тот самый солид своими словами), объяснений на собесе не было. Логично, что такой ответ собеседующий не воспринял. Потому что сначала солид/whatever, а потом разговор про метрики, а не наоборот, т.к. именно второе зависит от первого. Точно так же если я на вопрос о ПДД предложу «нормально ездить, нормально будет», в машины забивать автоограничение скорости в зависимости от условий, зафигачить все разделители металлическими столбиками вдоль, и перед каждым светофором поставить шлагбаум... мне ж не дадут за это права, правда?)

Это не говоря уже о том, что ездить/кодить в таких условиях мало фана.

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

Можно просто закрыть репозиторий на запись.

поки базворд не виражається в конкретній метриці.

А якщо метрики нема — будеш говнокодити? Oook...

читайте Єгора256

Читали. Але чайко-девелоперів і чайко-блогерів не цінуємо.

А якщо метрики нема — будеш говнокодити?

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

краще налашутвати на проекті статичний аналізатор і затягнути всі гайки які тіки можна, у вас код автоматично стане СОЛІДним. зі мною не дуже погодилися.

І вірно зробили, що не погодилися: статичний аналізатор шукає зовсім інші проблеми.

Ну у вас він шукає де там є унюзбл варіабл, а в мене — де в класі забагато методів, де в класі забагато залежностей і де цикломатік комплексіті овер 9000.
Я взагалі вважаю що одними цими трьома метриками можна закрити 80% проблем з дизайном. Бо коли в тебе є такі жорсткі обмеження то починаєш думати, якби його так краще зробити.

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

Какие синиоры суровые пошли, уже и про

SOLID

нельзя спросить... Скоро уже будет табу и классический вопрос про отличие интерфейса от абстрактного класса?

про отличие интерфейса от абстрактного класса?

java or c++? :)

Вопрос в контексте C# 8 похоже чуток вымрет.

Добре, які запитання хотіли б почути ви?

Конечно же — «что общего у интерфейса и абстрактного класса?» )

і ще до кучі з підковиркою питання про віртуальний конструктор/деструктор

СОЛИД относится к фундаментальным принципам ооп. Причем здесь статический анализатор?

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

СОЛИД относится к фундаментальным принципам ооп.

Что-то во времена разработки Simula и Smalltalk слова SOLID не знали...

Тому що бракороби. Знали б, мови не повмирали б...

А они и не повмыралы тот же ж smalltalk идейно чуть ли не 1 в 1 реализован в objective-c да и другие ооп языки «типа современные» наполовину оттуда.

Кстати сам smalltalk всё ещё доступен для запуска не только на mainframe 30-х годов и даже относительно свеж (2015-го):

smalltalk.gnu.org

Боб Мартін в своїй книжці по архітектурі пише, що основи SOLID та інших принципів закладалися ще з часів Алана Тюрінга, тому знали.
Ну і якщо бути геть задротом, то можна сказати, що Барбара Лісков представила свою роботу, здається в 2004 році, а лише трішки згодом це все скомпілилось в одне слово.

Ну і якщо бути геть задротом, то можна сказати, що Барбара Лісков представила свою роботу, здається в 2004 році,

Га? В цій книзі (переклад) воно вже було — може, ще не названо як слід, але сформульовано.
Тобто 1986.

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

Барбара Лісков

назвали б хоть Liskoff. Тогда хоть водку под это дело забодяжить можно былобы

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

ага, то ли дело когда от сердца прямо код идет: тут так, тут так, тут статика, тут лапша, тут «не трогать работает» и прочая красота, творчество одним словом!

Да блин это смешно городить архитектуру на таких хлипких высосаных из пальца идеях. Обьект это всего лишь контейнер для группы процедур, которые называются методами. Ничего больше. Уже где-то спорил, что никто во всем мире не знает что есть single responsibility principle даже. 10 разных человек ограничат ответственность обьккта по разному.

городить архитектуру на таких хлипких высосаных из пальца идеях

Чтобы не путать понятия: каким боком к en.wikipedia.org/...​iki/Software_architecture SOLID? Они всего лишь о том, как правильно писать ООП код, чтобы его было не больно поддерживать, и всё.

10 разных человек ограничат ответственность обьккта по разному.

Если это будет нормально поддерживаться и соответствовать тому же солиду, то ради Бога — почему нет.

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

Солид это лол. Он существует только в туду листах в книгах по паттернам. И самое веселое, что под конец книги автор уже сам начинает костылить, чтобы хоть как-то его проект интернет-магазина хотя бы что-то делал чуть в сторону. Я никогда в жизни за уже 11 лет не видел реальных проектов написанных по солид. Это как карточный домик, который порождает кучу мусорного инфраструктурного кода и по истечению уже 3-го месяца рушится и все приходится переписывать.

то как карточный домик, который порождает кучу мусорного инфраструктурного кода и по истечению уже 3-го месяца рушится и все приходится переписывать.

Умудриться обвинить SOLID в чьём-то говнокодерстве (wat???), всего лишь за 3 месяца запоров всё до необходимости тотального рефакторинга — такого я ещё не видел). Ушёл за попкорном.

Я никогда в жизни за уже 11 лет не видел реальных проектов написанных по солид.

Судя по цитате выше, вряд ли увидите.
В отрыве от неё это аналогично «я не видел ещё реальных людей, 100% живущих по ЗОЖ всю сознательную жизнь, поэтому питаюсь только чипсами и колой».

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

?

Я никогда в жизни за уже 11 лет не видел реальных проектов написанных по солид

ну не повезло тебе, бывает

А можно конкретный пример проекта без нарушений SOLID? Только не какие-то поделки или «внутренний мега-секретный проект под NDA», а что-то из мира open source, чтобы все дружно могли оценить и поучиться.

Ну поищи, я от опенсорса далеко

Всё понятно. Теоретики...

Теоретики это не те, кто в опенсорс не контрибьютит

Дело не в том, кто и куда контрибьютит. А в подтверждениях книжных теорий реальными проектами, проживших хотя бы пяток лет.
Лучшая архитектура — та, которая приносит максимум денег. Всё остальное — вечное бла-бла-бла об идеальном коде.

я только недавно написал что солид не про архитектуру. а еще она денег не приносит вообще

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

Начали с Open Source, закончили баблом как метрикой качества кода :)

Любая написанная строчка кода, любое принимаемое на рабочем месте решение в той или иной степени ведёт либо к прибыли, либо к убыткам.

примерно так же как выпитая или нет чашка кофе

Но программисты почему-то считают своей целью написание кода.

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

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

Работать в вашей компании большая честь? )

Работать в вашей компании большая честь? )

Я не по этой части. Я больше по теме поколбасить код. Посто не приемлю работу с людьми, у которых mindset «что сказали — то и буду делать».

Посто не приемлю работу с людьми, у которых mindset «что сказали — то и буду делать».

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

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

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

Якась галерна профдеформація...

разве? попробуй поперек стратегического плана руководства по развитию продукта попереть, слоя через 3-4 менеджеров аргументировать уже перестают, просто говорят что будет так и не обсуждается

Я ж кажу, якась галєрна профдеформація. Я спілкуюся напряму із CEO або кураторами, які стоять над CEO. Можу повністю впливати на розвиток проектів.

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

І це правильно. Програмерів не наймають щоб вони стратегічні рішення приймали (що б вони там собі не уявляли). :)

Любая написанная строчка кода,

Много проектов пишутся «в ящик» или через некоторое время закрываются. Поэтому обобщение 80го левела.

любое принимаемое на рабочем месте решение в той или иной степени ведёт либо к прибыли, либо к убыткам.

Если принимаемое решение ведёт к прибыли или убыткам, оно относится не к кодингу как таковому, а к выбору идеи/инструментов/приоретизации/архитектуре etc.

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

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

Много проектов пишутся «в ящик» или через некоторое время закрываются. Поэтому обобщение 80го левела.

Значит хреново работали, если проект закрылся. Причём, на всех уровнях. Так бывает.
Если проект изначально «в ящик», то на кой в него вообще идти работать? В чём смысл? ЗП получать?

Если принимаемое решение ведёт к прибыли или убыткам, оно относится не к кодингу как таковому, а к выбору идеи/инструментов/приоретизации/архитектуре etc.

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

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

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

Я не отрицаю необходимость знать базовую теорию. Не отрицаю необходимость писать maintainable/supportable код. Не отрицаю, что изначально «правильная архитектура», вдумчиво реализованная бородатыми синьорами, будет легче в дальнейшем саппорте и всех прочих акспектах. Но во-первых, не все готовы писать такой код. Во-вторых, сколько это будет стоить? В-третьих, когда будет релиз? Поэтому когда в команде появляется персонаж, который ничего не видит дальше своей IDE, то это скорее не преимущество, а сигнал приглядывать за ним повнимательнее чтобы после череды заваленых пулриквестов «патамуша не по солид» не стал для проекта проблемой.

Если проект изначально «в ящик», то на кой в него вообще идти работать?

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

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

Если проект изначально «в ящик», то на кой в него вообще идти работать? В чём смысл? ЗП получать?

Изначально «в ящик» проектов не бывает.

ПО — это код. Не больше и не меньше. Всегда должен быть компромисс между между желанием создать шедевр после прочтения очередной главы Макконелла и реальной жизнью, где кастомерам насрать на всё кроме финальной цены при приемлемом качестве.

В реальной жизни «компромиссного варианта» не существует, потому что человек пишет +/- на одном уровне и от него особо не отступает. Если постоянно задачи «на вчера» или нужно быстро догонять, то будет говнокод без вариантов. Поэтому или быстро говнокодим в меру своей испорченности, или пишем нормально в меру своей подкованности. Это джуниор будет сидеть с мыслями о недавней книжке и думать, как же так красивенно написать, а сеньор будет писать так каждый день как обычно, поэтому этапом обдумывания можно пренебречь — говнокод тоже ведь обдумывается.

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

Опять же, к SOLID это не имеет отношения, ну).

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

Если код был написан по SOLID, его и рефакторить легче/быстрее при смене бизнес-требований.

Но во-первых, не все готовы писать такой код.

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

Во-вторых, сколько это будет стоить?

Снова см. название темы. Зачем тогда там сеньоры? Дискуссия начинает заходить в сторону «понанимали сеньоров на миддловские задачи» или «а какой там реально левел на самом деле».

В-третьих, когда будет релиз?

Если бизнес-контекст заставляет говнокодить, можно это просто признать). Да, мы не живём в идеальном мире, но это точно не то, к чему нужно стремиться, и уж точно не делать из этого правило.

Значит хреново работали, если проект закрылся. Причём, на всех уровнях. Так бывает.

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

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

«Так бывает», «цена каждой строчки кода»... 90% стартапов не взлетают, камон, какая цена, какое «бывает», если упасть — это правило для стартапа, а не исключение. Должен ещё будешь за чужие бизнес-идеи). Я уже молчу о том, что большая часть стартапов сидит на ограниченном потоке денег и нанимает максимально дешевле с соответствующим уровнем команды и практиками.

Изначально «в ящик» проектов не бывает.

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

У меня есть шикарный кейс, когда мне в наследство достался проект, написанный по всем канонам командой жавистов. Продирась сквозь десятки интерфейсов я потратил некоторое время на восхищение архитектурными решениями. Я всё же гик и умею видеть красоту в коде. Но я всё никак не мог найти собственно базовый алгоритм, решающий основную бизнес-задачу, ради которого всё это создавалось. Когда же я его обнаружил, был немало удивлён. Потому что по-сути задача не была решена. :) Не то чтобы тупо заглушка вместо имплементации, но очень близко к этому. Зато был потрачен год на создание реально красивого, но абсолютно бесполезного кода.

В реальной жизни «компромиссного варианта» не существует, потому что человек пишет +/- на одном уровне и от него особо не отступает.

WTF?! Люди развиваются, читают книжки, строят архитектуры, контрибьютят оупенсорс, вырастают из зелёных джунов в бородатых синьоров, пересматривая свои взгляды на разработку ПО в целом. Взрослеют в конце концов. Это нормальный процесс становления разраба, суть которого не в очередной лычке, а в ежедневном развитии. Какой ещё ± один уровень?

Опять же, к SOLID это не имеет отношения, ну).

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

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

Мы уже давно отошли от темы топика.
Помимо бородатых синьоров, которых ещё нужно захантить и удержать, на проектах есть 2/3 джунов-мидлов, которые далеко не всегда могут отличить хороший код от плохого. И с ними нужно как-то взаимодействовать, чтобы получить результат в виде продукта.
Честно говоря, я даже не уверен что для проекта хуже: очевидно для всех и прогнозируемо говняющий джун, или синьор с серьёзным лицом неочевидно для всех два года педалящий за зарплату очередной идеальный фреймворк, которые решит все мировые проблемы и ответит на главный вопрос Вселенной, вместо того чтобы решить какую-то одну проблему конкретного юзера.

Если бизнес-контекст заставляет говнокодить, можно это просто признать). Да, мы не живём в идеальном мире, но это точно не то, к чему нужно стремиться, и уж точно не делать из этого правило.

Идеализм, не? Стремления — это прекрасно. Но есть бабло, которое платят кастомеры за продукт, которое перенаправляется бизнесом в зарплаты разрабов, создающих продукт. Нет продукта — нет бабла. Всё просто. Да, это бизнес-контекст. Но он есть в любом продукте. И, очевидно, в гораздо меньшей степени в «сервисных компаниях». Отсюда и основная разница во взглядах на разработку в целом. Помимо персонализированного «человеческого фактора».

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

90% стартапов не взлетают, камон, какая цена, какое «бывает», если упасть — это правило для стартапа, а не исключение.

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

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

В случае, когда люди целый год делали вроде как непонятно что — проблема очевидна. Спойлер: она не в линейных девелоперах, а в менеджменте, который не умеет/не знает, как готовить IT решения.

Люди развиваются, читают книжки, строят архитектуры, контрибьютят оупенсорс, вырастают из зелёных джунов в бородатых синьоров, пересматривая свои взгляды на разработку ПО в целом. Взрослеют в конце концов. Это нормальный процесс становления разраба, суть которого не в очередной лычке, а в ежедневном развитии. Какой ещё ± один уровень?

Мы говорим о банальном написании кода (SOLID), и тема о сеньорах — самый настоящий +/- один уровень в этом плане.

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

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

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

Если 90% падает, это — всё-таки правило, сорри. Поэтому в разрезе того, что код — это убытки или прибыль, в итоге почти гарантированно работа девелоперов (и всех остальных) превратится в убыток. Верить — это дело каждого, но се ля ви.

Если 90% падает, это — всё-таки правило, сорри.

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

Поэтому в разрезе того, что код — это убытки или прибыль, в итоге почти гарантированно работа девелоперов (и всех остальных) превратится в убыток

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

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

т.е. практически все

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

И при этом критично важно, чтобы человек, возглавляющий этот процесс, умел правильно приоритизировать задачи с точки зрения ценности для продукта и был способен надавать по рукам девелоперам, заигравшимся в код.
Понимание, что идеального кода не бывает, а есть код с уровнем качества, достаточным на данном этапе развития продукта и который нужно поддерживать,- залог здоровья проекта.
Но, боюсь, истории синьоров с саблями наголо «тут_место_для_баззворда — это круто и поэтому давайте всё тут нахрен перепишем», будут вечными...

Изначально «в ящик» проектов не бывает.

Бувають. PoC якоїсь технології.

Согласен, но это другое и крайне редкий зверь — там цель достигнута.

))))))
Принимается!
Теперь каждый собес буду начинать с опроса на знание SOLID.

что значит буква L в SOLID

Лол, мне чехи такой вопрос задавали.

Очередное интервью
Тут все нормально, очень вменяемый техлид,хороший разговор.
Но я...блин, посреди беседы с ужасом понимаю, что забыл как называется модель загрузки с GIUD партишнами 8-)))) GPT бл.ь !!!!! Мда 8-) вот такие фокусы память выделывает.

ты сегодня будешь к каждой моей фразе на форуме цепляться?
может тебе отдохнуть и расслабиться надо?

Так бомбит же тебя. Я же просто развлекаюсь. Ну нравиться мне xxx-ботов доставать.

ровно тоже самою хочу сказать тебе

Та просто сказать, что вылетело из головы. Я тоже не мог утром вспомнить как называется pesto.

Та так и сказал 8-) Посмотрим в общем, вроде пока ничего плохого нет 8-)

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

И твой вариант,и Андрея Л.-оба норм

Хм, а давайте начинать с 80. Как вы в ве48 решали проблемы с стеком?

А кого имели в 80 х имеется в виду интеллектуально?

А Искра жеж? Мазовии уже были в конце 80-х, снова-таки.

Вот у искры телевизор был матёрый. Зелёный такой. Даа. И трава зеленее... Даа... И девчули даааа...

А девчули таки да. Как посмотрел, во что они превратились нынче — жуть.

точно. Дааа ....

Вот у искры телевизор был матёрый.

Самой матерой у Искры была мышь типа «колобок». С проводом в руку толщиной и цельностальным шариком для укатывания потенциального противника.

Мне те мыши без надобности тогда были.
а потенциальный супостат тогда тож не отставал
upload.wikimedia.org/...​_Rollkugel_RKS_100-86.jpg
противу таких жеж разрабатывалось

Мне те мыши без надобности тогда были.

Это да. Мы ее использовали в основном для диггера и иногда мой шеф на ней чего-то фокспрочил. Пока не захватил себе 386sx

нет стека — нет проблемы
все преаллоцировано

там стек є, але глибина дуже мілка

можна швидко вийти за його межі

для 1К пам"яті ОЗУ можна було ваяти і на стеку в 16 байт
life-prog.ru/...​-mikroevm-k—ve—ve-.html
а перехід із i48 на i51 був як квантовий стрибок, як DOS3.11 на WindowsNT

для себе особливої проблеми не бачу, так як колись розробляв пристрої на основі і48\і51

П.С.
Вітя, розслабся. Ти занадто напружений. Мабуть це С++ на тебе так діє.

абуть це С++ на тебе так

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

В очередную задачку лбом врезался

порахувати кількість круглих каналізаційних люків у Мінську?

быстрое и до жути неверное

методом індукції: пройтися по одній вулиці, порахувати і натягнути на весь Мінськ

второе ну очень медленное, но очень корректное.

дедукції: обійти пішком всі вулиці Міньска і таки порахувати

ну да, запустити дрона із вебкою, щоб він облетів, розпізнав і порахував :)

у айробота спросить

моя колишня іпостась як електронщика підказує, що можна використати один із алгоритмів розводки PCB, напр., daisy chain

а можна алєксу на кольосики поставить хай їзде і щитає.

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

гдето по колено :)

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

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

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

Може простіше буде не ходити на конференції по біофізиці? :)

Спасибі за підтримку, воно таке й є. 8-)

Я так було забув як правильно дати дефінішн subnet mask і почав тупити )))

Тю, то таке ! Володя, ти втору частину давай, класно пишеш !

Мда 8-) вот такие фокусы память выделывает.

я це називаю «тупічє нападає»
так і живем

Черговий день, чергове інтерв’ю.

Цього разу на жаба техліда (з рубі пора зав’язувати, бо там якийсь фейл на фейлі ))))

Розмова проходила з chief architect замовника. Зв’язалися, мені видали завдання на кодінг та сказали що є 2 години, можна відключатися від камери і його робити, через 2 години чекпоїнт.

Саме завдання було типу зробити «хайлоад» запис даних кудись (без дурних алгоритмів та сортувань)—в принципі, задача, наближена до боєвої. Треба було зробити робочий софт, та тести+конкаренсі тести.

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

Рівно через 2 години після старту ми розм’ючуємося, я шарю екран і він робить рев’ю мого рішення. По ходу рев’ю я відразу ж озвучую які недоліки є в рішення, та як би я робив, якби в мене було більше часу. Також в нього були підготовані питання по едж кейсам та з розширеними умовами «а що, коли у вас навантаження зростає в 10х...», «а як сюди додати моніторинг» і так далі. Питання були спрямовані на загальне розуміння роботи JVM, хайлоаду, розподілених систем і тд.
Потім запитав які рішення я робив на попередніх проектах, чому обирав ті чи інші технології, як деплоїли, чомусь особливо приділили увагу тому, як вирішувати проблему синхронізації клієнтів та серверів при роботі з RPC (SOAP форева ))), поговорили про ті чи інші фреймворки, їх плюси та мінуси.

10/10 best interview ever, would do it again.

По результатам мене взяли на наступний етап.

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

Если собеседует человек на проект, которым рулит и ищет себе подчиненного, то будет большей частью всё нормально.

Абсолютно погоджусь, все так. Найгірші інтерв’ю в мене були з рандомними тіпами.

Молодець ! Поздоровлюю. В мене теж сьогодні інтерв’ю буде, подивлюся. Зафейлити не хочу, а там як Бог дасть.

А хз. Всяко может быть.
Посмотрим.

А вот за это спасибо, кстати.

Когда люди ищут человека работу делать, то прикидывают насколько быстро ты сможешь начать ее делать.

Вот да, кстати.

Зафейлил . Но как !!!!
Позиция системного инженера
Собеседовать пришел коммерческий директор (!!!!!!!)

Вопросы -
-а чо нет у тебя сиртификатов ? Чо, не учился чоли ? А чо так долго в банке сидел ? Учиться не любишь,да ?
-а ну шоб я в линкедин твой не смотрел, скажи какие курсы проходил ?
-а чо ты в Киев собрался ? А ты шо, там будешь квартиру снимать ?
-ага, так ты не только к нам подаешься, так еще и в Польшу...а где работать хочешь — в Польше наверное (с подколочкой эдак) ?
ЗЫ — вспомнил

— А ТЫ ХТО БОЛЬШЕ — ИНЖЕНЕР ИЛИ ПРОГРАМИСТ, А ?

Прям на йо..е айти попал.

— А ТЫ ХТО БОЛЬШЕ — ИНЖЕНЕР ИЛИ ПРОГРАМИСТ, А ?

Наверное, правильный ответ: Я больше ... не заинтересован в этой вакансии 🙂

И это был правильный ответ 8-) Мой ответ.

— А ТЫ ХТО БОЛЬШЕ — ИНЖЕНЕР ИЛИ ПРОГРАМИСТ, А ?

А Вам как больше нравится)?
ЗЫ: бегите оттуда

бляха, прочитав — як в 90-ті вернувся... Де Ви лише цю древність відкопали?

Для розробників того вже нема, а от для нас ще трапляється.

А чо так долго в банке сидел ?

Качественный ADSL, бесплатные обеды и униформа.
Прямая маршрутка сразу под офис.

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

Первая Оргструктура Пивоварова Андрея.

а чо ты в Киев собрался ?
А ты шо, там будешь квартиру снимать ?

У любовницы своя квартира в центре Крещатика.

— А ТЫ ХТО БОЛЬШЕ — ИНЖЕНЕР ИЛИ ПРОГРАМИСТ, А ?

Инженер по демонтажу дверей. В маски-шоу работал.

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

У любовницы своя квартира в центре Крещатика.

Лайфхак: добий співбесідника тестом на толерантність, скажи, що не у любовніци, а у любовніка.

Директор: А ты шо, там будешь квартиру снимать?
Кандидат: У любовника своя квартира в центре Крещатика.
Д: А ты шо, этот что ли?
К: Да;-) И не смотрите на меня так, будто бы у вас мыло упало и стесняетесь его поднять.

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

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

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

Кхм... Раз она так исправилась, у меня для тебя плохие новости.... Или нет...

Есть, да, но вот новый опыт на собесах получаю...прикольный. 8-)

— А ТЫ ХТО БОЛЬШЕ — ИНЖЕНЕР ИЛИ ПРОГРАМИСТ, А ?

Толя. Папа, а шо лучче — пулімьот чи танк?
Миша. Танк лучче, по пулімьоту pаз пиз*ане і пиз*арики. (З цими словами Миша наливає вино Опанасу, Гpиші, Толі і собі).
Толя. Папа, я, як виpосту, виучуся на ахвіцеpа чи на камандіpа. А шо лучче — ахвіцеp чи камандіp?
Гриша. Та адін х*й!
Опанас. Вафльониш ти іще на ахвіцеpа вчиться.
Миша. Скажи, Толя, "за*бал ти меня, папа, сваімі ахвіцеpами, я на моpе їду купаться. Хочеш купаться?
Толя. Я стpілять хочу!
doslidy.org.ua/?page_id=59

А ТЫ ХТО БОЛЬШЕ — ИНЖЕНЕР ИЛИ ПРОГРАМИСТ,

а у вас должність кого?
інженера-прогрмізда, да?
от, іженер по перєду, значить інженер більше.

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

Когда люди ищут человека работу делать, то прикидывают насколько быстро ты сможешь начать ее делать.

и через 15+ минут уже готовы на оффер

Когда же грести отсюда и до обеда

«армия» жеж

С больными на голову работать себе дороже.

Вот вспомнил.

протеже

vis-a-vis, kurwa matj!

все в истории хорошо. но тут 78% тех кто скажет «я мана лкодинг интервью11».

Чувак ти так і роботу найдеш шо потом будеш дєлать!? ((

Як співбесідувати сіньйорів-помідорів?

(хлоп) — догоняй, кетчуп ©

(хлоп) — догоняй, кетчуп

переклад — овно
гра слів — наше все
catch up, ketchup
(кеч ап, кечап)

справедливості раді — вона повторює два рази :-)
на 11 і 17 секунді

Ну шо хлопці, чергове інтер’ю на рубі девелопера, чергове приниження.

Спочатку запитали шопачьом в класах, модулях, блоках і ше чомусь я відповів 50/50 чого судячи з всього не вистачило. Далі було «назвіть всі види асоціацій в рейлс моделях», ну я по пам’яті трійко назвав, за іншими сказав шо ходжу в доку, що теж судячи з всього було не ок.

А ше я не знав шо таке yield (в методі а не те що у view), лол. Ну тут погоджусь, просто соромно )))

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

Щойно ми попрощались, я спокійно сів і за 5 хв написав коректне рішення.

Знову підгоріло.

Схоже що треба-таки сидіти перед співбесідами і задрочувати «< put your languate name here > interview questions» та їбучі типові алгоритмічні задачі щоб не виглядати повним бовдуром.

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

Щойно ми попрощались, я спокійно сів і за 5 хв написав коректне рішення.

+

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

Нет уж! Если человек растерялся — нужно додавить и унизить.
Раскрывать его сильные стороны? За этим к здоровым людям. У нас же в айти в большинстве работают душевнобольные: сами покоя не имеют и другим иметь не дадут.

Я просто себе вважаю досить стресотривким, припустимо минулого тижня в мене теж було тех інтерв’ю де давали задачу «знайти максимально довгий підрядок що містить унікальні символи», так от я її асіліл, а тут задача була значно простіша і я ніасіліл. Ну і раніше такі задачі досить просто розв’язував а тут щось пішло не так, не знаю що, але блін соромно kurwa matj!

Заспокойся, в мене позавчора подібне було. Тільки попер з температурою під 39, думав, що витягну. З дівчиною-HR навіть нормально більш-менш побалакали англійською (на неї зібрав всі сили, бо голова розвалювалася), а коли діло дійшло до техзавдання, я зрозумів, що просто тупо втрачу свідомість, хоча там все було відносно просто (робота з whois та dig + міграція сайта), в мене все пливло перед очима. Карочє..бувають сумні дні в житті, да. Нічого, прорвемося, бува всяке.
Да, і ніяке це не приниження. Тебе може, як кажуть «одвело».

а вот это с вашей стороны не правильно — болеете, сидите дома, и не заражайте работников фирмы в которую хотите пойти

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

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

омг. «обожаю эту срану» ©

Не зрозумів, ти ж так любиш «здобутки», а що не так ? Помирай — але повзи, хулє.

Не зрозумів, ти ж так любиш «здобутки»,

що? які здобутки?

Помирай — але повзи

це, вибачайте, совок.

Ні, це не совок. Це саме те, що побудували в Україні реформатори. Це те, що ви захищаєте.

Це саме те, що побудували в Україні реформатори. Це те, що ви захищаєте

це ваша хвора уява. це було задовго до 91-го року: всрамся, но не здамся
ну то ваш вибір — зкопититись прямо на співбесіді або перенести її

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

Вообще нормальные конторы на то нормально реагируют, если нет, то вы уверены что хотите работать с мудаками?

ёмаё взрослый же чоловек (ладно, спишем на температуру)
в подобных ситуациях нужно вести диалог с противоположной стороной (объяснить, что таки 39), коммуницировать, а не надумывать себе что-то
может для них не проблема — перенести на другой день, тем более это и в их интересах
причем, если противоположная сторона не готова к диалогу — это таки индикатор...
P.S. сам когда-то был в подобной ситуации, тоже температура 39, о чем и говорю хедхантеру из агентства — не уверен, что в назначенный день смогу, она — может вы успеете за эти несколько дней поправиться? у них просто начальник из командировки возвращается, которого несколько недель ждали (в другой раз непонятно когда с ним пересечься получиться), давайте я вас запишу, а если не сможете — дайте знать нам как-можно заранее
за пару дней оклемался, выпил фармацитрона и поехал

сказали ты квант

то підручник «квантова фізика» був про Вас?

Вже досить давно, між іншим, Нассім Талеб от каже що він працював квант-трейдером.

квант-трейдером

Ну тут моя уява вперто малює такого біржового «білого комірця», що намагається перепродати кілька ящиків фотонів :)

Кілька ящиків з котами Шрьодінгера...

Щойно зрозумів, як прикольно мій останній комент виглядає в профілі
picua.org/...​957b293a93d067aa94932.png

не откроешь — не узнаешь

Віктор, як завжди, не в бровь а в глаз!

Твои 2 поста говорят о том, что ты еще не сеньор.

я сеньор, просто 22-х річний

Сеньор обычно берет собеседование в свои руки

А ше двері ногою відкриває )))

я сеньор, просто 22-х річний

чтото староват для сеньора
в 22 уже архитект не меньше

Знакомая тема! Мне как-то начальница трейдинга в одной конторе — косплейша на Трисс Меригольд (ну реально рыжая баба так выглядит) задвинула, что мол, надо построить модель предсказания цены электричества и учесть все-все факторы.
Я ей — про overfitting не слышала? Ну на этом и закончилось

надо построить модель предсказания цены электричества и учесть все-все факторы

Тут є дві відповіді

  1. Треба, будуйте. Дозволяю
  2. Давайте розробимо кошторис проекту, контракт підпишемо й будемо вам будувати вашу систему.

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

А так би була можливість піти не на нову галєру, а одразу у власну компанію... ;)

Кажется я был в этой же компании на собеседовании. Реализацию each_slice написал успешно, но затем не рассказал CAP-теорему, не расшифровал SOLID и т. п. Компания в одной из двух башен находится? :)

но затем не рассказал CAP-теорему, не расшифровал SOLID и т. п.

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

Так шо, вам офер не дали в результаті?

Компания в одной из двух башен находится? :)

чесно кажучи не знаю, теревенили по хенгаутс.

В результате сказали что я могу претендовать на роль мидла, и если мне это подходит, устроят интервью с американской стороной. Я не стал продолжать процесс. Вообще, компания мне понравилась, классная HR, классный CTO, уютный офис.
А, то что я не ответил по каким-то причинам на воросы, — ну, это мои проблемы. Они мне делать оффер не обязаны, выбирать людей по критериям, которые важны для них, — их полное право.
А самые лучшие вопросы мне задавали на собеседовании в компании RailsReactor. Очень хорошее техническое собеседование.

А самые лучшие вопросы мне задавали на собеседовании в компании RailsReactor.

Ха, а ці пацани мене просто прокинули з фідбеком. Поговорив з їх РМом, с тімлідом якимось а далі вони просто зникли :)) Хоча в мене там коріш працював (а може й досі працює) і він пінгував того РМа, але безрезультатно. Було це 2015го чи 2014 року правда.

Я там был кажется в 2015. Ну, шит хэпенс. Никто не идеален.

А он нужен, этот фидбэк? Ты же сам помнишь на что знал ответ, а на что не знал ответ, вот тебе и весь фидбэк. Пришел домой и почитал теорию (очень полезно), написал каконить POC или подебажил\поковырял бибилотеку.

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

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

А то что пара чудиков раскажет мне как я плох в java script потому что не смог сказать результат выполнения монстроуозной функции от индуса под LSD то мне такое и нах не надо, я уже все увидел, что мне нужно был, это в добавок тому что всегда говрю в начале собесов что я больше бэк-эндщик и с джава скриптом уже не имею дело, но если сильно нужно то могу попедалить.

А он нужен, этот фидбэк?

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

Не ну это уже другое конечно. Вообще на мороз это свинство, хотя не редкость.

each_slice написал успешно, но затем не рассказал CAP-теорему, не расшифровал SOLID

Ну, кстати, звучит как вполне адекватный для украинской галеры набор вопросов для синьора. Не берусь судить о прочих вопросах по Ruby, о которых написал Włodzimierz Rożkow, но вот эти прям вполне ок. Дать написать простенькую функцию на 20 строк кода и обсудить CAP-теорему и SOLID. Еще б добавить CQSP. Эти темы открывают очень широкое поле для обсуждения и дают возможность синьору от души выговориться и направить разговор в сторону своей основной компетенции. Может он расскажет про то, как работал над публичным API для SDK, которую поставлял его клиент и какие принципы помогли ему избежать типичных ошибок. Или о том, как он наворачивал DI, чтоб отделить бизнес логику от базы данных и покрыть ее тестами.
Но это, конечно, при условии, что цель собеседующего была именно в том, чтобы дать возможность синьору показать свои сильные стороны, а не в том, чтобы просто получить расшифровку SOLID как на экзамене и перейти к следующей аббревиатуре пока не найдется такая, про которую собеседуемый не слышал.

Не берусь судить о прочих вопросах по Ruby, о которых написал Włodzimierz Rożkow

То були питання рівня «чим відрізняється абстрактний клас від інтерфейсу», я їх зафейлив )))

Був сьодні на співбесіді на сеньора, запитали як називається метод в арраю що фільтрує ніли, я його не знав напам’ять. Далі запитали шось типу «де використовується Enumerable» я підозрював що це щось типу Collection в Java, так і сказав, біс його знає, я щоденно юзаю map/reduce/select і не парюсь звідки воно приходить, кажу, дядя, я кодю на джаві, на пітоні, на жаваскріпті та рубі, в мене пам’яті не вистачить на всі сдк знати, воно гуглиться за дві секунди. Ну і ще пару таких питань на які я вже ок відповів типу «чим відрізняється where від having» і ще яксь маячня.

Перед тим було тестове завадання на написання дерев, регекспів, рефакторингу та іншої фігні, я його зробив на 9 з 10 балів.

CV моє теж ніхто не читав, походу тіпам взагалі я був нецікавий.

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

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

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

Досі підгорає.

Это норма, у меня обычно каждая 3 или 4 галера это клоунада. Порой так смотришь на таких чудиков и думаешь — а ваш менеджер вообще смотрит кому он поручил отбирать кандидатов и как вы их отбираете? Потом понимаешь что менеджер скорее тоже из той оперы, быренько сводишь собес ответами «не знаю/не помню» на ноль и идешь за вкусняшкой попутно матерясь зачем тратил время и нервы на этот цирк :-)

выпадашка

лол. в мемориз!

«Я трогала выпадашку и пропала крутилка! Погромизды памагите!»

«Засереная кнопка»

Это как то связанно с засерями?

«у нас большие засери!»

«Неклікабельна клікуша»

Открыл муж шкаф, а оттуда выпал любовник.
«Выпадашка» — подумал муж

Стисняюсь спросить шкаф засереный был или нет?

крутилочка — подумал любовник.

«выпадашка» вместо дропдаун

Нє, ну ніби то щось погане )

От тільки не «крутилочка», а «крутьолка», треба було виправити кандидата.

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

вчерашние трейни с дипломом медика но тайтлом Architect по machine learning

 Я так понял судный день и скайнет начнется в недрах Глоабала.

так то думаю он уже там во всю идет)

У меня так двери епама закрылись на долгие годы :)

это было настолько давно, что у них еще не пели

Доречі в Епам танцюють ніби краще ніж співають
youtu.be/t4kXixZVJxU

а ваш менеджер вообще смотрит кому он поручил отбирать кандидатов и как вы их отбираете?

а менеджер их заслал, не выделив время, вероятно.
такое сплошь и рядом: «тыж сеньёр», у тебя 25 часов в сутках.

dou.ua/...​rums/topic/24952/#1411997

А ще думка, походу може вони просто подумали що я мудак та дали формальну відмову. Бо я сказав що стендап мітінги це комплітлі вейст оф тайм (www.yegor256.com/...​ing-standup-meetings.html) ну і може це було стоп-словом лол.

Радійте, що серед них не було скрам-майстра, а то й живим би не випустили ))

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

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

надо говорить таким прямо:
ваши отфонарные эстимейты методом срам-покера, я трубу шатал.

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

на святое покусился!

Бо я сказав що стендап мітінги це комплітлі вейст оф тайм

пфф..

Прямой вопрос—прямой ответ.

На вашу думку ваша прямота у співбесідах вам допомогла знайти очікувану Вами позицію і людей з однаковими поглядами чи радше помішала? Це дещо схоже навіть на прояви раніше згадуванної тут «токсичності». З Датаарт в подальшому може не скластися :)

З Датаарт в подальшому може не скластися :)

це попередження чи що?

На вашу думку ваша прямота у співбесідах

більше мене про аджайл ніхто не питав а я сам не наривався.

Ніяких попереджень :) Всі ж тепер знають, що Датаарт не любить токсичних сіньйорів :)

Всі ж тепер знають, що Датаарт не любить токсичних сіньйорів

Я не в курсі, що за історія?

На вашу думку ваша прямота у співбесідах вам допомогла знайти очікувану Вами позицію і людей з однаковими поглядами чи радше помішала?

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

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

Був сьодні на співбесіді на сеньора, запитали як називається метод в арраю що фільтрує ніли, я його не знав напам’ять. Далі запитали шось типу «де використовується Enumerable» я підозрював що це щось типу Collection в Java, так і сказав, біс його знає, я щоденно юзаю map/reduce/select і не парюсь звідки воно приходить, кажу, дядя, я кодю на джаві, на пітоні, на жаваскріпті та рубі, в мене пам’яті не вистачить на всі сдк знати, воно гуглиться за дві секунди. Ну і ще пару таких питань на які я вже ок відповів типу «чим відрізняється where від having» і ще яксь маячня.

от души.
классика сеньёрского собеседования, когда собеседователь хочет отфутболить.

***
а це ввечерi було? бува таке прийшли два зайобанi задроти.
один: «ти резюме роздрукував?»
другий: «оп, нi, зараз»
перший: «нiколи» вiдкрив на смартфонi, читають резюме.

ну й починають чуму водити, щоб вiдфутболити.

Досі підгорає.

пачіму?

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

ты написал свой фидбек рекрутеру?
потому, что те двое на тебя написали

А то, в першу ж чергу написав. З рекрутером взагалі окрема історія :)))

Тю та то же ж єрунда саме інтєрєсне починається кода ти всьо от єто прошьол а тобі такіє «міл чєловєк а почіму ві такі хатіті у нас работать?» і «а што ві іщіті?»

Такшо можна смєло забівать ящєтаю. Я провіряв. ))

Такі да! Причому чомусь нікого не влаштовує «я працюю за бабло» :(

Був сьодні на співбесіді на сеньора
..
Зареджектили, сказали що основ рубі не знаю

звучит как «я объяснил этим щеглам что по чем, но они меня не взяли, потому что лохи не доросли еще»

Ні, я був супер коректним і понти не кидав а ретельно намагався пояснити чому я не пам’ятаю як називається Array#compact але чому це ок у мому випадку. Мого протеже це не задовільнило і не зацікавило, далі він обмежився іншими питаннями на джуна і ми швиденько закінчили справу тому що йому треба було на наступний мітинг йти.

Думаю с таким отношением мало где взяли бы.

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

Синьор ты либо везде, либо нигде

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

Порой там нужно чутье детектива, чтобы найти причину бага, комит с фиксом на этот баг, требования или человека который может тебе хоть как-то дать требования к сторе :-)

нужно чутье детектива

археолога по говнокоду там нужно ))

И не телько по говнокоду, ибо зачем оно именно так было зделлано — тоже загадка.

ибо зачем оно именно так было зделлано — тоже загадка.

дык это же не «загадка» а сама глубинная суть говнокода.

зачем оно именно так было зделлано — тоже загадка.

покрой это тестами.
чо так долго?
сколько процентов?
чо так мало?

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

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

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

один такой «ключевой человек» когда-то
с важным видом подняв глаза в потолок изрёк мне в ответ:
«код — лучшая документация».

В таком проекте документация не поможет.

Документація, яка була написана індусом, гірша за код, який був написаний тим самим індусом.

Олександр Шпак прав: документация на подобном проекте, как правило, не только безполезна, но еще и крайне зловредна. Потому что документация и код имеют свойство крайне быстро расходится между собой, тем самым превращая документацию в банальную ложь. Какова вероятность, что на проекте со сваленным в кучу говнокодом будет аккуратная и актуальная документация?
Поэтому прав был «ключевой человек»: код — это лучшая документация. А лучшие примеры использования этого кода — это юнит тесты.

Разумеется, поясняющие комментарии иногда нужны. Например для какой-нибудь длинной математической формулы или регекса или описания анимации.
Для прочих случаев, чаще всего достаточно сделать несколько extract method/class рефакторингов, переименований и тд. И код станет самодокументированным. Приведу пример на свифте. Я выдрать отсюда этот говнокод, который по мнению авторов «нуждался» в комментариях:

public func asURLRequest(_ apiKey: String) -> URLRequest

        var queryItems = query
        queryItems.append(URLQueryItem(name: "api_key", value: apiKey))
        // Get the final url
        let finalUrl: URL = {
            switch method {
            case .get:
                var urlComponents = URLComponents(string: url.absoluteString)
                urlComponents?.queryItems = queryItems
                guard let fullUrl = urlComponents?.url else { return url }
                return fullUrl
            default:
                return url
            }
        }()
        // Create the request.
        var request = URLRequest(url: finalUrl)
        request.httpMethod = (method == .upload ? "POST" : method.rawValue)
        // Add the custom headers.
        for (header, value) in headers {
            request.addValue(value, forHTTPHeaderField: header)
        }
        switch method {
        case .post, .delete, .put:
            // Set up request parameters.
            request.addValue("application/x-www-form-urlencoded", forHTTPHeaderField: "content-type")
            
            var urlComponents = URLComponents(string: url.absoluteString)
            let encodedQueryItems: [URLQueryItem] = queryItems.map { queryItem in
                return encodedURLQueryItem(queryItem)
            }
            urlComponents?.queryItems = encodedQueryItems
            request.httpBody = (urlComponents?.query ?? "").data(using: String.Encoding.utf8)
        case .get:
            request.addValue("application/json", forHTTPHeaderField: "content-type")
        default:
            break
        }
        
        return request

Дальше я сделал пару extract method с нормальными названиями и необходимость в комментариях полностью отпала, потому что код стал самодокументированным. Это заняло у меня минут 5.
public func asURLRequest(_ apiKey: String) -> URLRequest

let queryItems = createQueryItems(byAddingAPIKey: apiKey,
                                  toQueryItems: self.query)

let finalUrl = createUrl(byAddingQueryItems: queryItems,
                                    toURL: self.url,
                                    withMethod: self.method)

let request = createRequest(withUrl: finalUrl,
                                             method: self.method,
                                             customHeaders: self.headers,
                                             queryItems: queryItems)
return request
func createQueryItems(byAddingAPIKey apiKey: String, toQueryItems items: [URLQueryItem]) -> [URLQueryItem]
var queryItems = items
queryItems.append(URLQueryItem(name: "api_key", value: apiKey))
return queryItems
func createUrl(byAddingQueryItems queryItems: [URLQueryItem], toURL url: URL, withMethod method: GPHRequestType) -> URL
 switch method {
case .get:
    var urlComponents = URLComponents(string: url.absoluteString)
    urlComponents?.queryItems = queryItems
    guard let fullUrl = urlComponents?.url else {
        return url
    }
    return fullUrl
default:
    return url
}
func createRequest(withUrl url: URL, method: GPHRequestType, customHeaders: [String: String], queryItems: [URLQueryItem]) -> URLRequest
var request = URLRequest(url: url)
request.httpMethod = (method == .upload ? "POST" : method.rawValue)
self.addCustomHeaders(customHeaders, toRequest: &request)
self.addSystemHeaders(toRequest: &request)
self.encodeQueryItems(queryItems, intoBodyOfRequest: &request)
return request
func addCustomHeaders(_ headers: [String: String], toRequest request: inout URLRequest)
for (header, value) in headers {
      request.addValue(value, forHTTPHeaderField: header)
}
func addSystemHeaders(toRequest request: inout URLRequest)
switch request.httpMethod {
case "POST", "DELETE", "PUT":
    request.addValue("application/x-www-form-urlencoded", forHTTPHeaderField: "content-type")
case "GET":
    request.addValue("application/json", forHTTPHeaderField: "content-type")
default:
    break
}
func encodeQueryItems(_ queryItems: [URLQueryItem], intoBodyOfRequest request: inout URLRequest)
switch request.httpMethod {
case "POST", "DELETE", "PUT":
    var urlComponents = URLComponents(string: self.url.absoluteString)
    let encodedQueryItems: [URLQueryItem] = queryItems.map { queryItem in
        return encodedURLQueryItem(queryItem)
    }
    urlComponents?.queryItems = encodedQueryItems
    request.httpBody = (urlComponents?.query ?? "").data(using: String.Encoding.utf8)
default:
    break
}

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

Ну я бы не сказал, что о капитанских. Вот разве комменты в том примере, что я выше скидывал капитанские? Они довольно полезные и описывают неочевидный код. Но как только этот неочевидный код подвергается рефакторингу и становится очевидным, то необходимость в этих комментах пропадает. То же самое происходит с комментами, описывающими работу god-класса, в котором намешано кучу ответственностей, как только этот класс рефакторится. То же самое происходит с комментами, описывающими модуль, который и дрова рубит и воду выносит. Комменты либо полностью выпиливаются, либо заменяются на однострочники типа «This class provides conversions between different Unicode encodings». Вот тебе и вся документация, нужны детали — смотри публичный интерфейс. А если однострочником описать никак не получается, то есть вероятность, что имеються проблемы в дизайне.

Ну ок, я более упоротого примера по-быстрому найти на гитхабе не смог — не свой же код скидывать)

В чем упоротость этого примера?

В чем упоротость этого примера?

Ну там чистый Ad Hoc везде, типа константного количества елементов в коллекции. Но так и задумывалось, ибо это демка на один раз запустить и поклацать — это было актуально, когда Apple TV только вышел и не было никаких других примеров в сети, а людям было интересно как оно выглядит на телевизоре и управляется этим сенсорным пультом. Щас уже можно грохнуть репо спустя 3 года. Да и платформа apple tv нахрен никому не нужна, как показала практика.

Есть такое) Но это, кстати, делалось не для демонстрации кода, а для демонстрация самой платформы AppleTV когда она только вышла — чтобы запустить и поклацать с коллегами. По свободе грохну.

Во красота.
Даже дедушка, которій щас питон изучает
но раньше вышивал на дельфи огого
видит што это красивый и очень структурированный код
и даже понимает што это парсинг урла всяческий.
а што это за язык ?

Спасибо)
Язык Swift. Но в примере рефакторинга я специально не стал использовать никаких особенностей языка, которых бы не было в любом другом C-подобном ООП языке. То есть его можно читать как псевдокод для какой-нибудь джавы или C#.

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

Жесть конечно. Мои тиммейты говорят сфигали ты выпилил мой коммент — мне без него непонятно 🤦. Хорошо, хоть, чаще всего, они оказываются, на удивление, актуальны. Тоже, по опыту предыдущих проектов, комменты просто сразу идут в игнор/утиль.

«погибают» любители художественного форматирования кода и прочие вредители, которые навязывают постоянную поддержку своего кода другим

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

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

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

А в общем случае каждый лепит как хочет и всем противен код всех

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

Т.е., им при ревью линк на полиси бросали, а они отказывались ему следовать? Тогда П — Профессионализм, конечно...

Ну а гнуть линию..

Я в том плане, что без полиси это можно подать как «он придирается», а с полиси — совсем другое дело.

Т.е., им при ревью линк на полиси бросали, а они отказывались ему следовать? Тогда П — Профессионализм, конечно...

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

Я в том плане, что без полиси это можно подать как «он придирается», а с полиси — совсем другое дело.

в моем случае оказалось что разницы нет

Жесть, ещё и время своё тратить на такую дичь... надеюсь, не придётся работать с такими людьми).

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

Дай вгадаю, джава або дотнет?

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

Давайте прослідкуємо простий логічний ряд. З давніх часів був простий проект, ООП гарно лягло на нього, все було простим та логічним. Проект розвивався, ставав складнішим та перестав вміщатися в розум програмістів. Що винайшли програмісти? Правильно, IDE. Стало краще. Ненадовго. Все одне були баги та якась фігня постійно траплялася. Що зробили програмісти? Тестування. Стало краще. Знову ненадовго, бо тести вимагають час та не гарантують нічогісінько. Проект росте, розуміння його деградує з кожною ітерацією.

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

Що робити? Еволюціонувати нарешті. Якщо задачу неможливо принципово описати за допомогою ООП таким чином, щоб код був лаконічним, простим та ефективним, значить до біса те ООП. Зазвичай навіть самий простий DSL (domain specific language), який працює виключно в рантаймі та не компілюється, вирішить задачу краще, буде простіше в підтримці та дешевше в виробництві, ніж канонічний інтерфейс абстрактного класу. Так, IDE буде безглуздим та не буде підказувати, що в тебе помилка в ДНК, але профіт від використання DSL повністю перекриє всі мінуси.

Это детский уровень зрелости, да и просто чушь.

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

1. Масштабы.
понять принцип работы системы?
2. Архитектура.
3. Саппорт, тестирование, анализ, запросы бизнеса

Какое отношение все это имеет к комментариям в коде? Мы не говорим о высокоуровневом описании системы, написанном техническими писателями и не о UML диаграммах, составленных архитекторами. Мы говорим о комментариях в мать его коде. Это когда индус-говнокодер пишет //Adding the custom headers перед куском нечитабельного кода, типа поясняя, что он хотел тут сделать. Когда говорят «код — лучшая документация», речь идет не о 30 страничных документах для бизнес аналитиков, а про комментариях в функциях на 200 строк. Смотри пример рефакторинга, который я выше опубликовал.
Касательно тех вещей, которые ты описал в пунктах 1, 2, 3 я с тобой полностью согласен.

нужны и комменты и доки

отсутствие документации — это технический долг.

может это ты про комменту уже начал писать но вся ветка — про документирование системы

Ок, возможно я сам внес путаницу в терминологию, извиняюсь: «код — лучшая документация» — это я про практику написания чистого самодокументированного кода, который не нуждается в пояснениях на ломанном английском через каждые 10 строчек. Тоже самое касается публичных интерфейсов и собственно классов. Что делает класс должно быть понятно из его названия и публичного интерфейса. Что делает метод — из сигнатуры. К модулю и классу можно написать пару-тройку абстрактных предложений касательно его назначения, но без конкретики, потому что конкретика очень быстро устареет по мере добавления новых методов, которые самодокументированы.

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

На счет системной документации согласен с тобой. Но я бы не сказал, что писать и поддерживать ее — работа программистов. Кто занимается интеграцией и сборкой модулей, тот пусть и пишет документ к системе: архитекторы, BA и прочие 23-летние таланты.

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

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

Тесты показывают что ожидать от вызова целевого метода, а не как вызывать 🙂. А еще лучше: почему.

ГетЮзерс юзеров вернёт, а РемувАккаунт аккаунт удалит, а все что не ясно с названия является проблемным и наличие тестов не гарантирует правильность, много видимо тестов, которые писались ради покрытия, никто не парился что в методе был баг и этот баг «задокументировали» тестом, это очень сильно подрывает репутацию тестам и начанаются рассказы, что юнит тесты такие изолированные, что толку с них нет, все вместе не работает, а они зеленые

РемувАккаунт аккаунт удалит

А каким образом он удалит аккаунт?

Ну всегда два варианта прямо таки удаляет или делегирует, в целом очевидно из контекста что контроллер делегировать будет, а репозиторий удалять лично. И какой бы ни был тест, если контроллер удаляет сам это какое-то фуфло

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

А удалит полностью или пометит удаленным? А если эта операция должна сгенерить событие, что еще должно быть в этом событии?

У пометить удаленным есть общеизвестное название софтделит, единственная ответственность не предполагает других операций, соответственно не должно быть события там где выполняется эта операция

Хмм. Бывает и так. В event-driven системах целый процесс может начаться на событие удаления сущности. Например, пользователь удалил свою платежную карту из системы. Но, я вижу, что у вас на любой кейс есть ответ, это хорошо.

Хмм. Бывает и так. В event-driven системах целый процесс может начаться на событие удаления сущности. Например, пользователь удалил свою платежную карту из системы

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

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

но пускать событие все равно не будет тот, кто выполняет целевую работу, пускать его будет тот метод у которого целевая работа пустить это событие

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

Та яка різниця? Навіщо вам знання про особливості реалізації?

На реализацию накласть. Мне интересно поведение системы.

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

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

Мы обсуждаем конкретный пример и конкретный тест модуля. Я хочу знать как именно удалятся сущность и какой именно ивент создается. Как и кем он обрабатывается выходит за пределы модуля.

Тому що програміст так захотів, тому він так й робить. З реальністю це може не бути пов’язаним

«код — лучшая документация».

Два чая этому джентльмену!

Список вопросов синьору:

— вакансія(ї) де треба бути сіньйором-помідором

Do you feel yourself as a senior something developer? ^_^

— треба знати конкретний фреймворк на рівні сіньйора-помідора

I: Are you familiar with ExtJS?
S: ^$%#^%$#^% , $#^%$#^%$ , $#$#%^ !!!!111
I: Such much?

— треба вміти працювати з БД на рівні сіньйора-помідора

Are you resilient, result-oriented person, able to work under strict deadlines in fast-paced dynamic static environment?

Do you feel yourself

оце треба казати так
да йю филль юрсельфь азі сиинииор самсн девелопєє ?

www.youtube.com/watch?v=vAF5Pj02dPc
Нє, отаке шото, но впрочєм два чєловєка на відєо тожі доставляють 8-)

Do you feel yourself

Тест на знання англійської мови: якщо кандидат не зможе стримати посмішку, значить, рівень англійської вище середнього. :-D

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

Так, важко переналаштувати паттерни мови, якщо використовувати у ролі основної мову з іншими паттернами, напр., українську чи російську. У мене це колись проявлялося, наприклад, у тому, що довго перекладав речення з фразами «feel confused / embarassed»: мозок зі всіх сил довго пробував знайти для кожного слова відповідник замість того, щоб здатися і перекласти ціле речення не дослівно.

Через емігрантів (і не тільки) англійська змінюється, і те, що колись вважалося неправильним, стає нормальним і використовується навіть носіями. :-) Наприклад, з того, з чим я стикався, double negatives і «You» / «Your» замість «you» / «your» (підозрюю, що через слов’ян), чи «I could care less» і «could of» / «should of» / «would of» (підозрюю, що через чиюсь лінь), «Me» замість «I», ...

Double negatives есть исконно во многих английских диалектах.
Me вместо I — тоже.

еее, не треба тут, could of/should of це досі неправильно. тіпає щоразу, як бачу таке

You/Your скорее из за немцев.

«Me» замість «I», ...

учи матчасть , там четко прописано когда можно так а когда этак

Не ну может он feel myself прямо на собеседовании))

Точно блін 8-) забув значення 8-) це ж про онанізм 8-)
До речі якась хрінь стається. Дуже часто зараз легше щось пояснити англійською ніж українською й швидше забуваються англійські ідіоми яких не використовуєш. От і тут не втулив одразу 8-) а знав же 8-)

Ну а якщо в кімнаті тільки кандидат і симпатична рекрутер, яка прямим текстом питає і хоче вияснити, чи він feel himself так, як справжні сеньйори?))

А если не улыбается, то уровень английского C1, не меньше.

Классика, плохо подрочил, потому sick leave

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

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

Это вы на секс по телефону намекаете?

айяйяй. у меня все ходы записаны

нотаріально завєрєнний скріншот жарту про сігму й сфінкткер ? 8-) ну буває. не сподобалося , витер.

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

Блін, самураї то представники японського феодального класу.. Ніде вони не мандрували, окрім як на війну разом зі своїм кланом, бо були намертво закріпленні в феодальній системі.

Вот кстати не совсем. Шляхта то шляхта, но в том же Великом Княжестве Литовском и позже Речи Посполитой шляхта имела такие свободы, которые и не снились практически ни в одном другом феодальном госсударстве, и особенно японцам.

но вобщем да, все правлиьно. Шляхта самый лучший аналог.

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

Мали, але різне в різні часи. Аналогія з РП, до речі — дуже гарна.

Уважно гуглимо 浪人,

During the Edo period, with the shogunate’s rigid class system and laws, the number of rōnin greatly increased. Confiscation of fiefs during the rule of the third Tokugawa shōgun Iemitsu resulted in an especially large increase of rōnin. During previous ages, samurai were able to move between masters and even between occupations. They could also marry between classes. However, during the Edo period, samurai were restricted, and were—above all—forbidden to become employed by another master without their previous master’s permission.

Because the former samurai could not legally take up a new trade, or because of pride were loath to do so, many rōnin looked for other ways to make a living with their swords. Those rōnin who desired steady, legal employment became mercenaries that guarded trade caravans, or bodyguards for wealthy merchants. Many other rōnin became criminals, operating as bandits and highwaymen, or joining organized crime in towns and cities. Rōnin were known to operate or serve as hired muscle for gangs that ran gambling rings, brothels, protection rackets, and similar activities. Many were petty thieves and muggers. The criminal segment gave the rōnin of the Edo period a persistent reputation of disgrace, with an image of being thugs, bullies, cutthroats, and wandering vagrants.

Сеньёр без меча подобен самураю с мечом, но только без меча.

Сеньёр без меча подобен самураю с мечом, но только без меча.

І не самурай. А так все те саме.

вместо меча 13 дюймовый гейбук.

клали руку на меч

а куда друг другу руки класть синьйорам?

23 летний сеньор? Ну-ну

Там часто подход «давай накидаем на бумаге даиграмки для архитектуры» или простенький код сошибками синтаксическими но срешением и его, лично мне, порой даже легче написать чем обьснять на пальцах как и что делать\делал при решение каких-то проблем.

Еще попадаются фанаты фреемверков и просто весь собес гоняют по доке фреемверков.

З реальної співбесіди

  • Ви знаєте фреймворк X?
  • Ні
  • А фреймворк Y?
  • Ні. Я можу написати сам обидва фреймворки, то мені розібратися в чужих не складає проблем.
  • Нам потрібна людина, яка може писати на фреймворках, а не фреймворки.
  • Ви мені не підходите

Вариант когда человек просто разбирается в фреемверке которого не знает и пишет на нем, а не создает новые не существует? :-)

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

Хорошее собеседование. Как минимум, обе стороны были друг перед другом честны.

людино часи затрачені на співбесіди видно безплатні, а втрачені можливості бізнесом не значні... тоді шукаєм далі сенйора-фреймвокера

А что не так в том, что капиталисту нафиг не упало оплачивать Ваше переизобретение чужих фреймворков

Капіталісту пофігу на фреймворки. Йому потрібно швидко, дешево, ефективно вирішувати його задачі. З фреймворками це буде, чи без, чхати.

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

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

Так что то, что Вы можете переписать чужой фреймворк, практически ничего не значит.

Для вас — так.

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

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

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

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

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

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

Речь больше о «бесподобных» фреимворках. Например какуюнить акку, если вдруг не работал с очередями\сообщениями\акторами — таки потребуеться время чтобы «обернуть вокруг головы».

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

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

Це просто інший підхід до декомпозиції процесу.

Ну этото процесс именно что понимать надо. У меня был опыт, когда на самописной месенджевой системе, достаточно синьйорнутый народ не понимал что происходит, и делал всякую ахинею вроде блокировки треда чтобы дождаться ответа (но это было давно когда акка не существовало и на акторы не было столько хипа).

не умеют девелоперы думать асинхронно. или разучились

Мав аналогічний досвід. Архітектор замовника, який раніше працював з php, на початках переписування системи на Scala + Spark робив спроби збільшити паралелізм за допомогою паралельних колекцій Scala всередині map. :-)

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

Ви, мабуть, погано прочитали діалог.

треба знати конкретний фреймворк на рівні сіньйора-помідора
— треба вміти працювати з БД на рівні сіньйора-помідора

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

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

Перше, що б я зробив, це поклав би перед ним тарілку з сирами по 500 та по 250. Якщо сіньйор поклює тільки сири по 500, та не доторкнеться до тих, що по 250, то це перша ознака, що перед вами саме сіньйор, а не його симулякр.

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

В якості третього завдання треба запрошувати до кабінету джунів та мідлів. Небагато, щоб не налякати. Справжній сіньйор швидко згуртує девелоперів навколо себе та почне, як квочка, розповідати цікаві історії про сучасні фреймворки, та як він в далеких N-х патчив KDE під FreeBSD.

Це ваші асоціації, не мої ;)

патчив KDE під FreeBSD

это уже синьор-архитект как минимум.

патчить кеды не надо после 6й версии фряхи (или 5й — не помню уже), а это было давно.

Там соль была в версии кедов а не фряхи, если я правильно помню.

Кста вопрос по делу:

Как собеседовать синьйоров-помидоров по скайпу ?

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

Кодинг задачу на разбалансировку нестандартного дерева ? Но если ищуться именно мидлы-помидоры ?

«Що робить такий код». Код демонструвати у screen share. Код тупий, але щоб не гуглився, або гуглився, але не той. Подробно поговорити що де в коді відбувається. Питання на розуміння базових визначень.

Додам ще:

  1. формулювати частину питань так, щоб відповідь на них могла бути короткою і час на те, щоб придумати пошуковий запит, знайти у результатах пошуку потрібний результат і в ньому знайти відповідь був більше декількох секунд;
  2. якщо для значної частини розгорнутих питань кандидат робить довгий нерелевантний до питання вступ, брати це до уваги при написанні фідбеку.
пошуку потрібний результат і в ньому знайти відповідь був більше декількох секунд;

несколько секунд — мало, «на подумать» время то тоже должно быть...

Так, є питання, де треба подумати чи згадати.

Добре, наведу приклад. Через те, що Ви пишете на Scala, він буде на знання Scala.
Питання для співбесіди:

Чи є якийсь недолік у такій реалізації:

{
  case x: List[Int] => x.exists(_ > 0)
  case _ => false
}

Для такого питання недостатньо декількох секунд, щоб зрозуміти, що відповідати? :-)

Распарсить и скомпилировать в голове что происходит займет секунд 5-10 при условии что чел таки активно програмирует на скале а не видел по учебнику. Впринципе если делать скриньшер, чтобы чел видел код, но не мог его тупо скопировать в гугл\иде, и чтобы хотябы объяснил что происходит и почему — уже неплохо.

З.Ы. данный конкретный пример трохи сбивает с толку :-)

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

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

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

Сар ! Айем сітінг інфронт ов ов ю ен чатін віз ГАРЛЗ у фізбуук. 8)

какие стандартные странички ?

А зачем ? Вы что сходу не придумаете 10 вопросов по важным базам вашего языка ?

Чем отличаеться абстрактный класс от интерфейса — гуглить както специально нужно ?

надо выдать тестовое задание, двух джунов и ящик пива

если не справится во время или дилетант или перфекционист

Як співбесідувати сіньйорів-помідорів?

Вы это про себя проговорить пробовали? Я минуты на две над этим словом подвис. Не граммарнаци, но написали бы уже «Як проводити співбесіду з сіньйором».

Да ты наверно просто не знаешь кто такой Чиполино.

У меня однокласницу так звали, мы её Павлина называли.

Кароч, що питати потенційних 23-літніх архітекторів?

за яких умов ви згодні змінити роботу

по итогам получилась отличная простынь на тему «почему для продуктового проекта лучше всего нанять команду с апворка»)
всем каментаторам по два чаю

Это вымещение боли по поводу того, что нанять кого надо не можете?

— треба знати конкретний фреймворк на рівні сіньйора-помідора
— треба вміти працювати з БД на рівні сіньйора-помідора

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

А синьор знает. А ты не синьор. В этом и весь «вопрос».

Только синьор может собеседовать синьора? )))

Співбесідувати — позадавати питання чи виявити рівень? ;-)

Если речь про нормальное собеседование, то да. Или кто-то выше уровнем.

Любая кухарка может собеседовать синьора!

Only a ginger can call another ginger ginger © Tim Minchin.
Но синьор, собеседующий синьора должен быть еще и более могущественным синьором.

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

сырной палочкой
могущественные сеньёрши владеют сырной дырочкой

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

P.S. Не гуглите что это такое

Не гуглите что это такое

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

Кто-то же собеседовал самого первого!

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

Синюшность синьора должна вызывать настороженность.

Синюшность — это всмысле он бухой на собес пришел. Да, я бы насторожился %)

попросить спроектировать ленту инстаграма или твиттера вот в таком общем виде. Таким образом можно пробежаться по всему стеку и понять видит ли человек общую картину. Спросить как бы он дизайнил на 1 юзера, а как масштабировал бы на 1к в секунду. Как шардил бы данные, по какому принципу выбрал бы бд. Софтскиллы проверяются тут же — уточняет ли, задает ли вопросы, или понял как понял и давай решать.

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

Плох тот синиор, который не мечтает стать архитектором!

плох тот синьор который не мнит себя архитектом ))

Ой не, для меня слишком сложно

ну ты ж понимаешь что это вопрос на час? открой дизайн интервью класс и ынджой

На 1 пользователя то просто скл выберать посты

На 1к в секунды — денормализация + кеширование — должно хватить с головой для такой нагрузки

Ну так микросервисы в моде, берешь в облаке каком нибудь(AWS, DO) делаешь автоскалинг в зависимости от нагрузки и при одном юзере будут минимальные затраты, а при потоке на автомате расшириться. Также и базу слейвами сделать. Если в своем датацентре, то можно точно так-же все настроить через лоадбалансинги.

Всё правильно и в практике нужно с этого начинать.
Но вопрос то теоритический, который явно выводит условия хранения/доступа к данным на новый уровень. Очевидно что предпологаются миллиарды постов, которые в одной табличке хранить то можно, если к ним не часто обращаться.
Но есть 1k запросов на постройку ленты, пусть в среднем фоловят 200 других людей. При решении в лоб это уже превращается в 200k sql запросов / sec (по каждому на кого я подписан должен выбрать последних N записей, которые не старше моего последнего просмотра). И всё в рамках одной гигантской таблицы. Понятно что убираем сетевой оверхед, получая всю инфу за один вызов склейкой запросов через union all, стоят правильные индексы и даже на сервере сейчас не проблема 500GB+ памяти и ssd raid подсистему.

Но с точки зрения системного дизайна не это хотят услышать.
Скажут жеж: «если строительство не на**ётся в этом квартале, оно обязательно на**ётся в следующем» © Лесь

А хотят про шардинг данных, про денормализацию, memory-кеши, redis sorted sets по пользователям или какие-то другие реалистичные примеры как можно было бы сделать.

превращается в 200k sql запросов / sec

тут я погарячился, запросы вида user_id IN (user1,user2,..) AND time_add < N база сама внутри развернёт в (user_id=user1 AND time_add < N) OR (user_id=user2 AND time_add < N) и можно не городить отдельные запросы для лучшего использования составного индекса (user_id, time_add).

Ну, это элементарно.

спроектировать ленту инстаграма или твиттера вот в таком общем виде.

Ну — как то так, например!

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

На одного — запустить на своей локальной тачке, на 1000 — засунуть в контейнер и позвать девопса. Делов то!

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

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

А это вообще к ПМу, чтобы клиента на новый инстанс-железо раскручивал.

Ну это уже проблемы девопса, сделать так, чтобы все помещалось.

пример ответа?)

ответа нет но можно точный вариант вопроса на ответ ))

«как нах.!?» (к) (тм)

Особенно если он Kernel developer, финтеховец или специалист по распознаванию образов.

Ага, а после такого собеса поотм вешать баги «эта красная кнопка недостаточно красная».

Я плохо понимаю зачем собеседовать вопросом на проектировку твитора, если синьйор по итогам собеседования не будет работать ни над тивтером, ни над его убийцей, ни над 1\10 его функциональности, а будет какойто фигней заниматься, вроде кнопки на вебе менять.

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

А, ну для галер наверное не надо

Типа в гугл на позицию меняющего цвет кнопки — сильно надо ?

Как мне объяснили про Гугл, они берут в компанию, а не на позицию/проект, даже если ты следующие 100500 лет будешь там менять цвет кнопок, но ты должен рассказать им как на право и на лево сортировать красно-чёрные деревья и рассказать как будешь побеждать последствия вируса который некоторые файлы дублировал, некоторые перекодировал , а некоторые просто съел :)

Ага а еще про круглые люки, и количество мячиков в автобусе :-)

Вот кто бы мне объяснил как после этого кнопки править!!

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

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

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

А галеры типа сами для себя кодят ага ))

Ну похоже на то, раз синьоры им для кнопочек онли нужны

Можно зайти по классике: «Кем вы видите себя через 128 лет?»
Или из новых философских трендов: «Читали ли вы о новейшем фреймворке блокчейн на jquery»

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

  1. перетин областей, для яких виконуються всі 3 умови:
    • деякий досвід у яких вимагається у вакансії,
    • які згадуються в резюме,
    • з чим я сам працював;
  2. перетин областей, для яких виконуються всі 3 умови:
    • глибокий досвід чи знання яких вимагається у вакансії,
    • з якими кандидат працював як Senior (деколи це з резюме неочевидно, тоді треба бути готовим уточняти під час співбесіди і зразу на співбесіді підкоректувати список питань)
    • у чому сам впевнено себе почуваю.
Області можуть бути загальними (Python, Scala, Java, Data Science / Machine Learning, Big Data, бази даних / SQL, NoSQL, Cloud, Linux, ...) або вужчими (NLP, Spark Dataframes, якісь конкретні БД чи NoSQL-сховище, якісь конкретні сервіси від AWS / GCP / Azure, ...).

На основі перетину 1 ставлю питання, які допомагають виявити, чи людина з цим дійсно працювала на практиці (а не просто прочитала у wikipedia / Quickstart / ...). На основі перетину 2 згадую, які речі відкрив для себе у кожній області, коли «глибоко» працював з нею; їх і питаю. Senior кандидат не повинен знати відповіді на всі чи майже всі питання, сформовані на основі перетину 2, бо, можливо, він стикався з іншими нетривіальними проблемами, але очікую, що на значну частину буде знати відповіді. Як і те, що буде знати відповіді на майже всі питання з перетину 1.

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

Щось можна покращити у цьому підході? :-)

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

Хороше питання. :-) Треба буде почитати і подумати, що і якими методами можливо за годину співбесіди перевірити. Зараз тільки деколи роблю ремарку, якщо деякі моменти в комунікації насторожують.

Behavioral questions. Как поступишь в той или иной ситуации.

Ну, как правило, у сеньоров спрашивают нетривиальное, типа:

Если кинут баг под ноги, его фиксить или переступить?

Есть Ангуляр дроченый и Реакт точеный, на чем сам писать будешь, что другу посоветуешь?

Есть два воркспейса, на одном легаси проект развернут, на втором — багофикс унылый, за какой сам сядешь, куда мать посадишь?

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

Переступить

Мидл переступит, синьор ноги вытрет.

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

Ну вы, блин, даёте )) В департаменте исполнения наказаний появился IT отдел?

вот так должно выглядеть собеседование
www.youtube.com/watch?v=GccSt8LuyO4

Можно по наталу, или нумерологически.

Отличный план, надёжный. Как швейцарские часы.

Як співбесідувати сіньйорів-помідорів?

на коленях

:)

а если он тяжелый?

Тогда наоборот.

под коленями?

Пів години довго. Маю 15 хв, щоб зробити висновок

По фотографии ещё можно

Проще монетку подбросить. А вообще нужно тоньше, тренируйся.

Серьезно? Зачем тогда вообще собеседование проводить. Случайным образом вытянуть резюме из пачки и сделать оффер будет эффективнее.

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

Некст лвл чсв сеньйор

Синьор сам всё спросит и вас прособедует)

Берёшь синьора-помидора и синьоришь-помидоришь его по полной программе, какие проблемы?

Кароч, що питати потенційних 23-літніх архітекторів?

почему люки не квадратные — уже предлагали?

питав про люки і про два стільці навіть питав

Пора объединять.

Сколько шариков для пинго-понга поместятся в открытый круглый люк, который прорезан в полу автобуса в Сан-Франциско?

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

ПринятЪ!

Сколько шариков для пинго-понга поместятся в открытый круглый люк, который прорезан в полу автобуса

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

почему люки не квадратные

Есть и квадратные, и даже треугольные.

Препод: -Какой предмет сдаем? -Какого цвета учебник? Студенты: во валит, сволочь!

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

впринципі, застосовував такий підхід. що робити, якщо кандидат каже — всьо під НДА, нічого конкретно казати не можу

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

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

як тоді реагувати на відповідь — я б загуглив

Спасибо, мы вам перезвоним.

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

як тоді реагувати на відповідь — я б загуглив

хмм, что не так с ответом?
вполне логичный как по мне.

тем более:

ри цьому часові рамки правильні

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

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

— вы ж со Spring знакомы?
— NDA!
— но хоть Java?
— NDA!!
— вы ж разработчик?
— NDA!!!!
— а еще какие-то слова знаете?
— NDA ;(

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

Это все субъективно, вам с ним работать — вам и решать.

проект написаний на певному фреймворку, людина взагалі не використовувала апі фреймворка.

сенйор фрейморка

нє, ну умови завалити людину з першого питання я не ставлю

Если скажет «Не знаю», берите.)

Попробуйте на мові жестів зобразити слово «Поліморфізм» ? Як в грі ?

Опишите полиморфизм при помощи танца

у индусов это первый вопрос на собеседовании

ти що, сам з собою балакаєш?

це як, праве полушаріє сообщає месидж лівому?

То которое наливает наливает тому, которое пьет :-)

И за анаморфизм, катаморфизм, иломорфизм, параморфизм, наконец.

Помидоро-рфизм, на синьор-помидора же идет!

причем правильный ответ будет — «какой из n видов?» ))

Я так сегодня сделал, в ответ интервьюеры сделали квадртные глаза.

Ну как-то раз после похожих действий нанимающий менеджер разозлился.

Хороший фильтр на самом деле

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

Такое на миддл куа спрашивают, для синьора-помидора надо что-то круче.

Лучше — объясните что такое полиморфизм бабушке

І токо так
-Дєточка, ми цей стандарт розробляли 8-)

Я за 9 лет так и не запомнил.
Просто херачишь в коде this.super() и работает :)

А потом, вдруг откуда ни возьмись, появился... следующий вопрос: что такое статический полиморфизм? )

— треба знати конкретний фреймворк на рівні сіньйора-помідора

васкансия > /dev/null

о.. і таке я зробив буквально на цьому тижні...

Меня тут один дядя американец давече решил прособеседовать.
При этом вакансия была нуу Full Stack — требовались знания Delphi, C++ .NET, Knockout.JS, Assembler для каких-то Embedded процессоров. И он мне такой — «ты компилятор писал?».
Потом докапывался минут 15 почему у меня в резюме, которое я впервые сделал лет 13 лет назад, я назвал факультет на котором учился — Computer Engineering, а не Computer Science — я хз, я то думал что я инженер и отбалды перевёл. Потом он начал показывать фотки моего ВУЗа, типа «узнаешь здание?». «Назови лабы и предметы?»
А в конце сказал, что я его «не впечатлил».

Я это к чему, после такого собеса, мне показалось спрашивание конкретного фреймворка на собесах в наших милых конторах — это еще верх прагматизма и логичности.

Жесть, конечно, но, может, его товарищи из солнечной Индии вкрай утомили.

Было ощущение, что чувак крепко чешет ЧСВ, местной братьи надо брать у него уроки. Он так гордился, что учился 20 лет назад в каком-то левом ВУЗе, я уж думал он начнёт рассказывать в каком Омега братстве он состоял.

я уж думал он начнёт рассказывать в каком Омега братстве он состоял.

это бывает это вообще похоже часть классического «introduce yourself».

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

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

Эта традиция весьма забавна в америках. Когда на проэкт понабирали инжусов и прочих Украинцев. Можно трололо устраивать :-)

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

За каждый пропущенный знак ему приходит один DotCoin).

Может тот амер один из твоих преподов был, просто шифровался...

Хотя, как это по-ангельски правильно сказать — не знаю.

«оу зэт воз икзактли зи плэйс вере ай нью йо литтл мамми бро!» (к) (тм)

Не. Я чотко знаю. Тхере вас зе свииит бушыс эраунд зе кампус вере ви юсте гетбомбид 8-)

ой я кажиццо дажи кантору знаю... ))

Потом докапывался минут 15 почему у меня в резюме, которое я впервые сделал лет 13 лет назад, я назвал факультет на котором учился — Computer Engineering, а не Computer Science — я хз, я то думал что я инженер и отбалды перевёл. Потом он начал показывать фотки моего ВУЗа, типа «узнаешь здание?». «Назови лабы и предметы?»

ЗЫ: но вообще узнаю брата колю (к) (тм) похоже у них там такая вава головного мозга и процессов кстати уже замеченная и описанная как «машина для отсева самозванцев» якобы у них там стоит толпа людей на входе непременно пытающихся выдать себя за других для этого же ж и «собеседование под видеокамеру» и «психологический практики с применением практикующего психо эйчара» и стрёмные вопросы «что вы делали 22 мая хх года когда у вас написано что вы были пьяные после защиты диплома» и вот ещё свежее «звонок другу для этого назови 100500 друзей».

Причём там практически 146% корреляция с тем самым «нууу full stack» как только видишь странный смесь технологий можно 146% утверждать это они со своими «комплексами самозванцев».

ну дык открываешь любую вакансию в которой:

нуу Full Stack — требовались знания Delphi, C++ .NET, Knockout.JS, Assembler для каких-то Embedded процессоров.

— и это сразу ОН! (к) (тм) ))

ЗЫ: я вот название снова забыл и снова нашёл тем же ж путём ))

Не, это была продуктовая компания (а что? мечта многих :), но так экзотикой не впечатлили, обычный гавнокод 25 летней давности.

сколько у него подписчиков на SO

А разве там подписчики есть?

Разве что Impact 0-o
content.screencast.com/...​cb607/2018-10-19_1323.png

чувак ты путаешь помидор с огурцом а это вообще даже не овощи ))

-как организовать автоподчистку базы данных чтоб она не разрасталась до бесконечного размера?

Не согласен, как можно проектировать хранилище не понимая что дальше с ним делать.

Та легко, full stack backend на все руки мастер )
Но а вообще не всегда dba таки бывают в команде.

Это вопрос с подвохом? Как можно без контекста задавать такие вопросы?

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

Ох жесть %)

Я бы на такие вопросы переспросил бы о какой бд идет речь ?

майсиквел? оракл? мссиквел? кассандра? монга? каучбейз ? мемсиквел ? редшифт ?

А потом бы послал задающего эти вопросы наюх %)

нет никакой разницы мускл или оракл для концептуального ответа

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

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

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

Теперь по поводу нагуглить — 50%требований озвученных тс — дб.

Мой посыл, что если 50% требований по ДБ, и таки нужен хороший опыт в ДБ, то нужно конкретную ДБ в вакансии озвучивать и описывать.

Например, тебя волнуют

концептуальные принципы и типы индексов?

или, то что можно выжать максимум на практике из майсиквела ?

Принцип удаление дубликатов дб независим, один и тот же принцип даже в монго сработает

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

вот только документы все равно могут быть одинаковые и пофиг на ключ

на ключь не пофиг, ибо если они дублированые, то удаление нужно к чемуто привязывать, чтобы не удалить все. Вот тебе быстро гуглеж по ораклу: https://blogs.oracle.com/sql/how-to-find-and-delete-duplicate-rows-with-sql который для решаемой проблемы использует оракловские штуки. Аналог для майсиквела народ делает через ж**у копирование таблицы https://stackoverflow.com/questions/2728413/equivalent-of-oracle-s-rowid-in-mysql А вот например еще более цпоротое решение, которое тоже подойдет с использованием INSERT IGNORE thelazylog.com/...​rom-large-table-in-mysql

ведь это можно сделать на чистом сиквеле

уф, тяжкий ты начальника :-)

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

Уровень дискуссии доставляет.

Подход один и тот же во всех базах?

Нет. Но для этого нужно базы таки знать.

1. Есть ключ — юзай его

Тогда это не дупликаты.

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

Которые или уникальные для каждой СУБД, либо их может и не быть.

3. Архитектор был настолько туп что вообще ничего не продумал из этого? Самое время продумать, уникальный ключ+ сиквенс добавить в таблицу — 2 минуты дела, если в субд нет служебных rowid, как в оракле

И немедленно сломать нахер всю бизнес-логику, использующую select * или insert без указания полей. Отличное решение!

Но подход один и тот же

Единственный возможный универсальный подход в этом случае — выбрать все дупликаты во временную таблицу, стереть из изначальной и вернуть назад.
Индексам при этом будет больно.
На табличках в 10+ миллионов записей придется заказать даунтайм часиков на 8-12.

алгоритм подхода един

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

А синтаксис каждой из баз это уже мелочи

Это не синтаксис.

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

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

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

Детали всех фреимворков он таки знать вообще не обязан.

Level 2 з тої таблиці тобі дасть ± картину, що треба питати: sijinjoseph.com/...​rammer-competency-matrix
Ідеальне знання ферймворка — то трохи дивна вимога на сіньйора. Стандартні вимоги: Сіньйор має мати системне, аналітичне і критичне мислення. Має вміти задизайнити систему або її частину, має вміти найти і пофіксати ботлнеки і баги не зважаючи на якому вона буде рівні(код, бд, інфраструктура). Має вміти потестити то, шо написав. Сіньор переважно бачить повну картину і відповідно відповідає. Джун — мідл розкаже один кейс, не повну картину.

це складно, вакансія не в амазон і не в гугл

А шо буде, якщо прод ляже, а чувак навіть не буде знати що робити? :)

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

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

Табличка лиш почаже наскільки він відповідає субєктивним уявленням автора таблички, нажаль. А роль проста — писати код.

ну это, дайте тогда на интервью кодинг таск, можно пару.

Вообще-то я всегда считал, что синьор-помидор — это несколько (на много) больше, чем просто «писать код».

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

Так вам нужен кодер, называйте кодеров своими именами.

мені не потрбіен ніхто) я всього навсього асасін маю провести інтерв’ю. а по-друге як багато ви бачили вакансій де пишуть потрібен кодер? пишуть сініор, бо такий запит.

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

Блин, слушай, ну они то сами наверно знают кого они ищут и что им от него надо, как бы они его не называли.

ЗЫ; это еще что, синьёр который хорошо пишет код это нормально. А как тебе тимлид, который... ну да, код лучьше всех пишет?

они то сами наверно знают кого они ищут и что им от него надо

Чем точнее назовут тем больше вероятность найти кого хотят, ящетаю 🙃.

twitter.com/...​tatus/1052958907063263232

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

По зарплатной вилке отличать 😂

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

нафіг мені сініор який не вирішує задачі краще ніж джун

Поит в том, что синьер решает другой класс задач, чем джун, а не те же задачи, но лучше.

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

Вы считаете себя синьером? Какие задачи решаете?

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

Чтоб поднять прод, надо совсем не теоретические знания, часто детективные, кстати хороший вопрос для собеса — «ты хоть раз в жизни прод то поднял?»

И дополнительно «а ложил ли прод?». Тоже экспириенс, добавляет +3 к крепости яиц.

Когда с продом такое случается, глаголов и эпитетов целое море возникает. Даже клал на то что ложил.

Клал.

В данном случае именно — ложил. )
Причем обязательно уточнить — а сколько раз?
И — «как уйти огородами от девопса»?

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

ну если он идёт на синьора по поднятию продов то логично но если таки нет то уместным будет ответ вопрос «а что у вас синьоры прод поднимают?» и «вы знаете я как раз сейчас занятой я обязательно позвоню вам в понедельник!» (к) (тм)

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

це напевно ідеальний варіант, якщо ще б можна було ці 2-3 місяці не платити... але, є пару раундів співбесід і я мушу відсіяти тих хто старше 23 років не сініор, тобто я на першому раунді. тіпа першого боса

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

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

Как же они запарили этим!
9 кругов собеса выглядят так — в компанию тех собес, на проект тех собесс, с менджером в компанию, потом с кастомером тех собес, потом с кастомером манагер собес...Результат -извините но ванасия на он холд.
Четрыждблядская ярость, мне вего-то контр оффер нужен был!!! :-)

ну это кстати тоже неплохой индикатор рынка и твоих на нем позиций...

По-моему это банальный индикатор пробивки рынка и того, что дефицита ИТ-специалистов не существует

И я о том же.

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

Впрочем, я не скажу что таких позиций нет, просто они заметно реже чем галерный синьор на 3-3.2К.(Таких можно за день получить с десяток предложений на джинни)

Я про Харьков.

В Харькове есть Zone3000, там вполне предлагают 5.5

Я туда собеседовалась мильон лет назад. Мне они показались супер-стремной конторой. Как раз для прекрасного.айти вариант. Они что, реально хорошей компанией стали?

У них просто можно получить высокую зп, к «хорошести» это отношения не имеет

что дефицита ИТ-специалистов не существует.

не существует дефицита желающих и претендующих а это уже совсем другая история ))

но их хрюши, по идее, должны еще на этапе просмотра резюме/скрининга отсеять. Писечка начинается, когда доходит

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

А потом начинается параша с отсутствием фидбека

я тебя полюбил я тебя научу (к) (тм) как трушный синьор «из бывших» открою сикрет забиваешь и стаёт тибе щасти ))

не пытаясь продавить тебя по ЗП.

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

Это скорее показатель общего кризиса галерного способа хозяйствования. Все эти zero-bureaucracy дружные молодые коллективы все больше тонут в бюрократии.

Да что там галеры, даже Гугл начал ориентироваться на середняков

за гугл я бы б не брал в качестве примера просто у гугла закончились неиспользованные синьоры которых полагалось непременно «с горящими глазами» а уж потом (может быть) «синьоры» и соотв. вполне логично переключиться чутка пониже где «зажечь в глаза» всё ещё можно плюс тут чисто технические вопросы роста компании как чисто бизнеса и «горящих синьоров вместе с гуру» гораздо проще скупать на рынке ipo сразу готовыми пачками вместе с командой и технологиями и тут же ж подсаживать к ним +100500 джунов набирая их целыми галерами во всё той же ж далёкой снежной Украйине а «трушного синьора» возиться со всеми этими странными белокожими варварами не особо прельщает так что сегодняшнего синьора в сегодняшний гугл ещё попробуй замани.

Там исчо проще если до вас приходит синьор а у вас 100500 раундов интервью а вы не гугл не амазон и даже прости господи не мелкософт то и он не синьор. ))

А зачем его брать?

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

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

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

БД — это «абстрактная» DBMS или какая-то конкретная?

ну классика же:
interface vs abstract class
error handling in framework XYZ (обычно никто о нем не читает, и он есть везде)
HAVING vs WHERE;
how to optimize slow query
и прочая ерунда в том же духе

interface vs abstract class

це вже всі знають

error handling in framework XYZ (обычно никто о нем не читает, и он есть везде)

а от це чотко, дякую

HAVING vs WHERE;
how to optimize slow query

теж не нове

ну спроси как выбирать random users set из БД и чтобы быстро работало

Кстати насчёт оптимизации запроса, дай какой-то запрос который у вас оптимизировали + схема + експдайн(если попросит) + для чего запрос нужен

Классические вопросы для собеседования джуна.

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

у джуна — how to optimize slow query??? хочу посмотреть на такого джуна, а если справится с этим то фреймворк синьор не нужен

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

Как-то я учил в ШАГе ребят, была группа разных от 14 до 45. Так вот лучше всех шарил тот, который 14, я даже думал брать его на проект, но эти все контрольные и мамки забивают мозги.

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