Розбий моноліт! Kuberton — конференція для DevOps-ів & Python, Java, Ruby, GO розробників. 2-3 March, 2019
×Закрыть

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

Хело,

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

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

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

LinkedIn

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

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

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

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

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

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

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

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

кагбэ

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

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

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

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

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

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

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

или с бумажки не могут прочесть, слишком сложное)))

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

, естественно НЕ для собесов

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

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

— Закрой поддувало!

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

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

Это харасмент был бы.

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

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

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

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

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

У нас было 2 веревки различной длины, 75 слитков с неизвестным содержанием золота, 5 шаров которые весят одинаково и один чуть тяжелее остальных, полведра воды и целое множество крышек от люков всех сортов и расцветок, принципы ООП, а также абстракция, интерфейсы, абстрактные классы, SOLID и 2 дюжины кем вы видите себя через 5 лет. Не то чтобы это был необходимый запас для собеседования, но если начал собирать дурь, становится трудно остановиться. Единственное, что вызывало у меня опасение — это физбазз. Ничто в мире не бывает более беспомощным, безответственным и порочным, чем физбазные зомби. Я знал, что рано или поздно мы перейдем и на эту дрянь.

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

тогда уж лучше блендер заюзать

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

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

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

Делим его на 8 частей

теж ймовірно трошки

Бар рейзер

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

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

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

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

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

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

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

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

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

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

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

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

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

Я же уже писал, что пробовал эти ваши смузи — гадость. Пиво лучше. Так что 2 пива мне.

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

Пиво не смузи — из веревки не сделаешь.

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

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

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

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

Ну хоть не аксиома Эскобара
А вообще есть простое элегантное решение

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

Конечно влияет, складывать веревку не поможет
Но идея в общем правильная

Запалити з різних кінців, і коли догорить до половини, бухнути пивка, пів літра.

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

Тогда и только тогда когда прием пива занимает ровно 15 мин

—тут був хибний коментар—

Шото твоё объяснение путаное, вот как надо
Поджигаем одновременно конец одной веревки и два конца второй
Когда вторая веревкався сгорит через 30 мин — поджигаем второй конец первой веревки, она сгорит еще через 15 мин

Ой, все, піду спати. Я задачку прочитав вибірково г.

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

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

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

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

„Write a program that prints the numbers from 1 to 100. But for multiples of three print ‘Fizz’ instead of the number and for the multiples of five print ‘Buzz’. For numbers which are multiples of both three and five print ‘FizzBuzz’.”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У меня один раз спросили, читал ли я книгу Clean code. Говорю нет, ответ: ну тогда не о чем разговаривать :)))

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

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

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

за вечер?

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

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

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

Беркову знаю

А буква О — Ocean Aletta.

Єто точно уровень сеньора

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

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

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

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

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

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

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

Стесняюсь спросить, а из какой части постсовка он происходит?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я и вертел эти паттерны. Применимость в 1 из 100 случаев этих ваших паттернов. В реале же всё определяется тем, кто архитектуру конкретного софта наваял.
4 мужика нарисовали книжку, чтобы с лохов бабла поиметь. А то. что до них уже 30 лет все это применяли сказать забыли.

Можно высрать написать книжку с названием в стиле «Паттерны: как не обосраться на собеседовании».

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

Только юзалось всё это задолго то книжек недавних.

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

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

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

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

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

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

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

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

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

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

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

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

+100050000

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

Я помню и юзаю , когда нужно

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

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

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

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

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

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

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

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

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

а як ви з тим ДІ інстанси створюєте?

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

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

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

а референс на інстанс куди? в глобальну змінну?

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

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

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

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

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

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

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

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

звучить як сінглтон!

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

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

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

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

дізайн фор реплейсабіліті і не до такого доведе

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

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

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

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

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

приходить сінглтон скоуп в ді-контейнер, а ді-контейнер теж сінглтон :)

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

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

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

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

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

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

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

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

пліз дефайн «хороший дизайн». наприклад Теорія вирішення винахідницьких задач Альтшулєра в своєму ядрі суперечить information hiding Парнаса

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

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

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

так і про сінглтон поруч з Парнасом і Альтшуллєром не згадував :shrug:

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

В 2019 начитаются Скита и будут спрашивать, почему классическая реализация синглтона сосет.

Я в 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-х — опираемся на количество объектов, что человек может держать в кеше мозга.

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

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

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

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

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

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

Его аналог только без пейота.

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

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

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

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

Для одной и той же цели юзаются.

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

Проблема в том, что рядом с одним опытным 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, ответил что-то в духе «писать код хорошо» — ну ок, а что значит «писать код хорошо»?

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

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

мне действительно интересно, как тогда синьоров собеседовать.

По case study. Дано: некая проблема. Возможно даже такая, которая встречалась у вас на практике. Обязательно решенная. Вопрос: как бы ОН ее решил. И начинаем обсуждать подходы.

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

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

Совершенно верно. И знание (и опыт применения) таких практик как 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++? :)

JS конечно ))

Вопрос в контексте 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 якоїсь технології.

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

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

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

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

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

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

Об этом и речь. Ты просто ляг, поспи и полегчает.

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

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

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

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

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

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

Ну и что. Добавляешь, что за свою жизнь уже столько видел, что и названия их всех позабывал. И начинаешь рассказывать, начиная еще в 80-х. Тебя остановят и скажут, больше не надо, знаешь, знаешь, мы поняли.

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

Витя, ну это очень по- детски.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Розмова проходила з chief architect замовника.

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

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

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

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

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

А с чего ты его зафейлишь?

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

Всё знать не возможно.
С больными на голову работать себе дороже.
Так что что 60% на повезет, 40% на знания и умения твои. Всё однозначно и просто, если не заморачиваться лишнего.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

скажи, що не у любовніци, а у любовніка.

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

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

И не мечтай, не для тебя мама цветочек растила!!!

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

В начале пути

Я думаю у человека опыта не меньше 15 лет.

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

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

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

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

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

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

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

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

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

«армия» жеж

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

Да. Этого обычно достаточно.

«армия» жеж

Галера жеж. В армии копают.

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

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

протеже

vis-a-vis, kurwa matj!

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

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

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

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

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

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

В оригинале там только catch up был, не повторялся два раза. Это уже в переводе добавили «догоняй», чтобы русскоязычный зритель понял, в чем соль шутки.
www.youtube.com/watch?v=NrGeOHpEGk0

справедливості раді — вона повторює два рази :-)
на 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, о чем и говорю хедхантеру из агентства — не уверен, что в назначенный день смогу, она — может вы успеете за эти несколько дней поправиться? у них просто начальник из командировки возвращается, которого несколько недель ждали (в другой раз непонятно когда с ним пересечься получиться), давайте я вас запишу, а если не сможете — дайте знать нам как-можно заранее
за пару дней оклемался, выпил фармацитрона и поехал

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

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

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

Отыгрывать роль хорошего-плохого полицейского

Тоже было такое, видимо готовят специально для этого :)

Твои 2 поста говорят о том, что ты еще не сеньор. Сеньор обычно берет собеседование в свои руки и рассказывает собеседующим то, что хочет, а они слушают, открыв рты. Правда, если с рассказом переборщишь есть шансы получить отказ «overqualified».
Если они хотят собеседовать сеньора, как джуна и на другой вариант не соглашаются, то такие посылаются сразу лесом. Тебе охота работать у них джуном?

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

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

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

Не, это про физиков. А кванты — это финансы и математика. Ну вот так их теперь называют.

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

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

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

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

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

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

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

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

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

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

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

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

Это неприлично в культурном обществе.

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

Есть еще и более странные кейсы.. Тут чувак рассказывал про свою success story dou.ua/...​om-teacher-to-programmer но в Глобале есть чувак, например, который за 2,5 года выходил с python test trainee и вчерашнего выпускника GoIT курсов с дипломом медика и возрастом >30 на Senior/Architect по machine learning (на последнюю позицию он заходил после непродолжительной смены конторы). Везение? Постель? Знакомства? ХЗ. Казалось бы Киев, много выпускников крутых тех вузов, а на конференциях от Глобала выступают вчерашние трейни с дипломом медика но тайтлом Architect по machine learning, которые «как-то» успешно прошли собеседование..

Ничего себе новые вершины).

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

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

Некоторые еще в 2011 на западной Украине дропдаун называли «Випадайкою». А прогресс бар — «Рисочка»

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

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

Не сразу понял, блин круто! )))

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

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

титєчку нє дадііім гадавасу , он надудоооніт ! © мамкі_з_жж

А как надо? ))

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

«Сам выпадашка» — подумал любовник.

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

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

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

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

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

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

Не, вот с «у меня сапсан тут вылетел » бухгалтерским — ничего не сравнится.

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

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

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

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

А может ты просто не исполнил песенку Стоша Говнозад?

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

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

а менеджер их заслал, не выделив время, вероятно.
такое сплошь и рядом: «тыж сеньёр», у тебя 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дфутболити.

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

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

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

им не нужен специалист

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

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

пачіму?

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

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

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

З рекрутером взагалі окрема історія

Ну давай, трави, чего уж там.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если дело касается Lab1.cpp, то да. Если доходит до кровавого энтерпрайза, написанного индусом под марьиванной — то нет

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

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

Мой пойнт в том, что важно не столько знать, что делает этот код, сколько то, зачем он это делает.

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

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

Разумеется, поясняющие комментарии иногда нужны. Например для какой-нибудь длинной математической формулы или регекса или описания анимации.
Для прочих случаев, чаще всего достаточно сделать несколько 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». Вот тебе и вся документация, нужны детали — смотри публичный интерфейс. А если однострочником описать никак не получается, то есть вероятность, что имеються проблемы в дизайне.

// Get the final url
let finalUrl
// Create the request.
var request = URLRequest(url: finalUrl)

Чем не капитанство?))

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

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

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

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

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

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

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

Спасибі. Гарно написано.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это детский уровень зрелости, да и просто чушь.
1. Масштабы. Ты реально предлагаешь читать... Нет, не читать а еще и понять 100к-1м строчек кода разбитых на функциональные модули пакеты и тд что бы понять принцип работы системы?
2. Архитектура. Как понять в каком месте искать тот или иной код? Спросить у автора? С вашей текучкой? Ага, ну да, Это же более правильно чем открыть доку на 30стр и локализовать вопрос
3. Саппорт, тестирование, анализ, запросы бизнеса. Бггг это самое ржачное, вместо того что бы всем этим людям, не обязанным знать где в большой системе лежит модуль с функцией по расчету А, открыть доку и и получить ответ они что? Правильно, в день будут кидать девам по 20-50 запросов а где а что а как а почему. А дев и сам хор знает так как док нету, а весь код знать на таком большом проекте может только старожил коих смотри пункт о текучке

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

Джава або дотнет або пайтон або двх, або любой серьезный зрелый проект в энтерпрайзе
А сказать то что хотел?

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

Давайте прослідкуємо простий логічний ряд. З давніх часів був простий проект, ООП гарно лягло на нього, все було простим та логічним. Проект розвивався, ставав складнішим та перестав вміщатися в розум програмістів. Що винайшли програмісти? Правильно, 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 це досі неправильно. тіпає щоразу, як бачу таке

«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 летний сеньор? Ну-ну

Вот я недавно находился в поиске работы. Так что знаю не по наслышке как все происходит.
1. Большинство спрашивает одно и тоже. Причем я даже знаю статьи, где они это прочитали. Уверен, что они даже не запускали те примеры, по которым спрашивают.
2. Еще один тип, это спрашивают по тому, что у них уже реализовано в проекте. И как я понял, нужно сделать реализацию «как у них», чтобы не задеть чувства интервьюера.
3. Редкий. Дают идиотские задачки, анкеты, опросы. Первое чувство, RUN!
4. Самые адекватные: спрашивают как решал проблемы, какие проблемы решал, методы, ход мыслей, возможно дадут задание на интервью, на псевдокоде. С целью увидеть ход мыслей «мастера» в деле. Только не домой, иначе RUN!

4. Самые адекватные: спрашивают как решал проблемы, какие проблемы решал, методы, ход мыслей, возможно дадут задание на интервью, на псевдокоде. С целью увидеть ход мыслей «мастера» в деле. Только не домой, иначе RUN!

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

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

Это, ИМХО, самый лучший вариант — сделать в спокойной обстановке задание, на настроенной под себя машине.

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

Где там и про что ты я не знаю. Меня попросили написать класс аналогичные std::vector,
а до этого мы поговорили за математику, что в финансах, за буст.
И да к коду, с которым я позже работал приложил свои ручки Скотт Майерс.

Еще попадаются фанаты фреемверков и просто весь собес гоняют по доке фреемверков.

З реальної співбесіди

  • Ви знаєте фреймворк X?
  • Ні
  • А фреймворк Y?
  • Ні. Я можу написати сам обидва фреймворки, то мені розібратися в чужих не складає проблем.
  • Нам потрібна людина, яка може писати на фреймворках, а не фреймворки.
  • Ви мені не підходите

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

В приведенном диалоге не существует.

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

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

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

А что не так в том, что капиталисту нафиг не упало оплачивать Ваше переизобретение чужих фреймворков

Капіталісту пофігу на фреймворки. Йому потрібно швидко, дешево, ефективно вирішувати його задачі. З фреймворками це буде, чи без, чхати.

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

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

Так что то, что Вы можете переписать чужой фреймворк, практически ничего не значит.

Для вас — так.

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

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

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

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

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

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

Речь больше о «бесподобных» фреимворках. Например какуюнить акку, если вдруг не работал с очередями\сообщениями\акторами — таки потребуеться время чтобы «обернуть вокруг головы».

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

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

Це просто інший підхід до декомпозиції процесу.

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

не умеют девелоперы думать асинхронно. или разучились

Мав аналогічний досвід. Архітектор замовника, який раніше працював з php, на початках переписування системи на Scala + Spark робив спроби збільшити паралелізм за допомогою паралельних колекцій Scala всередині map. :-)

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

Ви, мабуть, погано прочитали діалог.

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

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

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

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

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

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

нарешті якісні поради

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

Ловко вы синьоров в петухи записали!

патчив 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)

Перестать самому открывать стандартные странички и оттуда же зачитывать те вопросы.

какие стандартные странички ?

google -> %technology_stack_name% interview questions -> first 5 URLs

А зачем ? Вы что сходу не придумаете 10 вопросов по важным базам вашего языка ?

Чем отличаеться абстрактный класс от интерфейса — гуглить както специально нужно ?

А зачем мне их придумывать? Я их уже наизусть знаю

надо выдать тестовое задание, двух джунов и ящик пива

если не справится во время или дилетант или перфекционист

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

Вы это про себя проговорить пробовали? Я минуты на две над этим словом подвис. Не граммарнаци, но написали бы уже «Як проводити співбесіду з сіньйором».

Да ты наверно просто не знаешь кто такой Чиполино.

У меня однокласницу так звали, мы её Павлина называли.

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

за яких умов ви згодні змінити роботу

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

Это вымещение боли по поводу того, что нанять кого надо не можете?

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

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

А синьор знает. А ты не синьор. В этом и весь «вопрос».

Только синьор может собеседовать синьора? )))

Співбесідувати — позадавати питання чи виявити рівень? ;-)

Если речь про нормальное собеседование, то да. Или кто-то выше уровнем.

Любая кухарка может собеседовать синьора!

Only a ginger can call another ginger ginger © Tim Minchin.
Но синьор, собеседующий синьора должен быть еще и более могущественным синьором.

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

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

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

P.S. Не гуглите что это такое

Не гуглите что это такое

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

Кто-то же собеседовал самого первого!

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

Синюшность синьора должна вызывать настороженность.

Синюшность — это всмысле он бухой на собес пришел. Да, я бы насторожился %)

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

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

Плох тот синиор, который не мечтает стать архитектором!

плох тот синьор который не мнит себя архитектом ))

Отличные вопросы, а можно пример ответа?)

Ой не, для меня слишком сложно

Эй помидоры, помогите таким неучам как я, дайте пример дизайна на эти вопросы, интересно!

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

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

ну ты ж понимаешь что это вопрос на час? открой дизайн интервью класс и ынджой

пусть пропитчат, кратко такое изложить — это и есть шик)

На 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.

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

Щось можна покращити у цьому підході? :-)

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