Здравствуйте, so5team, Вы писали:

S>Бежать ли от компаний масштаба Яндекса, Касперского, Сбера, VK и пр. "гигантов" каждый решает для себя

Могу точно сказать, что чем больше компания, тем глубже болото.

Я работал на компанию(вернее, подкомпания) в примерно 200 чел — даже эта "средняя" контора — неплохая репетиция того ужаса, который происходит в крупняках.
1. У большой конторы очевидно есть "старейший продукт", приносящий ей деньги. Есессно, писаный сто лет назад на принципах "дедов" (это в идеале, на деле всё зависит от того умника, который всё это зачинал). И хоть ты бейся о гранит, НИЧЕГО в этом болоте ты не сдвинешь с места — любые инициативы улучшить технологии/форматы/принципы — сразу НЕТ. Потому что "это ж надо переписывать-тестировать", "у нас так сложилось", "есть дела поважнее", "мы поставили софт клиентам и не хотим обновлять"... вот это вот всё. А меня просто выворачивает жрать щи лаптем из корыта, когда есть ложки и тарелки.

Так-то в целом понятно, что "дойную корову" лучше лишний раз не теребить, но... сегодня ты доишь, а завтра жрёшь пыль, которую оставили конкуренты, обогнав тебя на этих самых "технологиях, которые нам неохота внедрять".
ИТ — тут всё происходит так быстро, что консерватизм — прямой путь в унитаз. Особенно для продуктов 20-30-летней давности (это прям вообще плесень).
2. Большая контора — больше волокиты. Тебе нужен моник? Можешь ждать его даже пол-года, потому что опять "есть дела поважнее", "мы ещё бухгалтерию не обновили" и т.д. То, что оборудование нужно как раз тем, на ком ваша "дойная корова" пишется — да пофиг! У тебя ж есть 14" CRT — чё те, мало что ли?

3. Меньше возможностей для ништяков. НЕ ДАЙ БОГ ты заикнёшься "поработать из дома" — всё, писец, большие глаза и страшный голос "Мы тут всей компанией жрём говно, а ты что — не хочешь?? А если все не захотят — это что, бунт? Коллапс?!". Хотя казалось бы, ВСЕ (наконец-то, бл____ть!) начали понимать, что программировать можно и нужно делать из дома — максимально комфортной среды. Нихрена тебе не светит, "потому что мы все так живём". Особенно начальство — ему чем ещё заниматься, кроме как дрючить вас?

Собственно, ты даже комнаты не выпросишь — вот посадили вас в "опенспэйс обезьянник" — сиди и нажимай кнопки! Один кондиционер на шестерых и вечная "борьба за климат" — как крысы в ведре грызёмся, а всё потому, что конторе впадлу сделать нормальные кабинеты.
В конторе с 10 челами всегда можно что-то порешать. Собственно, я так ещё до пандемии "выпросил" нормальный режим: работаю дома, раз в неделю-две обновляем результаты и радуемся (вернее, результаты доступны сразу, но надо обсудить планы, замечания и т.п.).

Короче, вот нахрен не нужон никакой ваш Фконтакт с Одноглазниками, никакие Мелкософты с Теслами... никто из них не заменит мои 16 часов вне сна, которые я трачу С УДОВОЛЬСТВИЕМ именно потому, что не работаю на вас.

Здравствуйте, Baiker, Вы писали:

B>Как программисту доказать, что он — профи высшего класса?

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

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

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

Здравствуйте, Baiker, Вы писали:

B>Мужики, вопрос такой необычный, но всё же ИТшный.

B>Как программисту доказать, что он — профи высшего класса?

Показать свои яхты и остров.

Здравствуйте, mike_rs, Вы писали:

_>зачем ты это делаешь?

А что, есть выбор? Во всех мало-мальски крупных компаниях это делается именно так, да и многие мелкие пытаются это копировать.

_>на каких предыдущих? у HR-а что ли? речь о техническом собеседовании в команду, если что

Речь о всех собеседованиях в предыдущие компании. Там что, не могли выяснить, насколько человек вообще адекватен в общении, и только тебе лично это под силу? А может, ЧСВ надо немного успокоить?

B>Как программисту доказать, что он — профи высшего класса?
Понятия не имею.
B>У п-стов нет медалей, "чёрных поясов", малиновых штанов и грамот "лучший погромизд года". Даже наколок нет!
B>И вот приходишь ты (лет в 40) в компанию, а тебя как студента-задрота начинают спрашивать, чем отличается делегат от события. Так-то ты внутри себя фэйспалмишь, но работодатель настолько туп, что считает свои "экзамены" важным звеном найма, напрочь игнорируя другие методы. А так ты ему показал "корочку" или медальон какой — и всё сразу понятно, это "старейшина" и он всё знает (это чисто как пример, где могут пригодиться твои регалии).
"Корочки" нифига ничего не показывают и не доказывают.
Как опытный препод говорю: у чела может быть ЕГЭ 100 баллов, а он простейших вещей не знает.

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

B>Как быть, кого бить, что делать?
Задавать вопросы на собесе собеседнику
Например: а как вы погружаете в проект?
Есть ли у вас документация внутренняя?
А куратор хотя бы на первое время будет?
А у вас есть какая-нить политика гитования ?

Если спрашивают по каким-то техническим вопросам, то самому спросить: а у вас в проекте это применяется?
Например, спрашивают про методы обработки ошибок в С++, а ты после краткого ответа встречный вопрос:
— а у вас какими способами ошибки обрабатываются?
А у вас в проекте проектировали обработку ошибок? Или просто по ходу вставляли try&catch ?
Ну, и т.д.

Здравствуйте, Baiker, Вы писали:

B>Как быть, кого бить, что делать?

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

Здравствуйте, Baiker, Вы писали:

B>Мужики, вопрос такой необычный, но всё же ИТшный.

B>Как программисту доказать, что он — профи высшего класса?

B>И вот приходишь ты (лет в 40) в компанию, а тебя как студента-задрота начинают спрашивать, чем отличается делегат от события. Так-то ты внутри себя фэйспалмишь, но работодатель настолько туп, что считает свои "экзамены" важным звеном найма, напрочь игнорируя другие методы.

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

Делегаты, события... Всё собеседование на любую роль можно построить на одном вопросе — "что такое ООП?".

Здравствуйте, Baiker, Вы писали:

B>И вот приходишь ты (лет в 40) в компанию, а тебя как студента-задрота начинают спрашивать, чем отличается делегат от события.

а как так получилось, что профи высшего класса вообще на такое собеседование попал?

Здравствуйте, Codealot, Вы писали:

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

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

B>А я не хочу!

Я вообще не хочу обсуждать то, что является моей РАБОЧЕЙ РУТИНОЙ.

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

Здравствуйте, Baiker, Вы писали:

B>Если HR не стоеросовый долбоклюй, вопрос должен быть конкретным: "Расскажите о своих прошлых проектах и их самых интересных/трудных местах", а не "расскажи о себе".

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

Здравствуйте, Baiker, Вы писали:

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

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

B>Это маловероятная вещь, как правило специалист с опытом 10+ лет УЖЕ считай "высший класс".

Только не в IT. Здесь нормально, что у двух таких 10-летних один за это время научился всему от запускать S/360 без диска и до веб-сайта на jQuery, а второй ничего кроме, например, Spring Boot не умеет.
Один мой коллега с 1999-го сидит на своей теме и никуда не дёргается — ему и так хорошо.

B>Но суть моего замечания не к тому, как докопаться к нанимаемому, а как ПРАВИЛЬНО, без пошлых игр в синтаксис и подкапотные тонкости, определить, стоит ли брать такого работника.

А для этого надо определить, что он в принципе умеет (а не что в резюмэээ написано).

B>Собственно, тем и отличается ИНЖЕНЕР от кодера — инженер смотрит на задачу глобально, большими блоками, с перспективой развития. Ну а кодер — тот да, будет долго прищуриваться, знаешь ли ты сколько микросекунд работает StringBuilder супротив "" + "".

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

Здравствуйте, Nuzhny, Вы писали:

N>Кажется, что лёгкого пути нет. Конференции, статьи, open source, известные проекты.

При наличии всего этого, если ты еще не (со)владелец бизнеса, то ты облажался.

Здравствуйте, so5team, Вы писали:

S>Здравствуйте, Sharov, Вы писали:

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

S>Нанятый после online-coding-а специалист у вас на работе будет:

S>a) решать алгоритмические задачи и
S>b) будет вслух рассуждать при их решении?

S>Если хотя бы по одному из этих пунктов получается "нет", то с высокой долей вероятности на собеседовании вы будете проверять не тот целевой признак.

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

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

Здравствуйте, gress, Вы писали:

G>Реальный промышленный не обязательно. Можно кафку себе локально поставить (это несложно) и попробовать какой-то пример поковырять самостоятельно. Понюхать, какие засады могут встречаться на пути. Решить какую-то несложную задачу обмена по кафке между 2 простенькими сервисами. Или попробовать реализовать пример, когда несколько подписчиков считывают из одного топика.
G>Это так, чисто пощупать. Почитать статьи, с какими проблемами сталкиваются при реализации взаимодействия на кафке. Прочитать, как архитектурно устроена Кафка внутри.

G>Представь себе, ты реализовал сервис, который слушает и отвечает по кафке. Сколько разных кафок он сможет слушать одновременно? Сколько топиков слушать и во сколько топиков отвечать? Можно ли слушать и отвечать в один и тот же топик? Как отправить сообщение в топик для тестирования сервиса? Как прочитать в топике сообщение? В твой топик внезапно отвечает кто-то, но твой сервис отключен. Как найти "виновника торжества"? Можно ли удалить сообщения или топик из Кафки? Из чего состоит сообщение в кафке? Как построить асинхронный обмен между 2 сервисами на кафке? Можно ли в одном сервисе реализовать REST API и взаимодействие по Кафке?

Скажите, а сколько времени нужно среднему разработчику, чтобы почитать про кафку и ответить на ваши вопросы? Неделя? Две недели?
Получается, что вы не готовы оплатить человеку 2 недели рабочего времени для изучения кафки, но готовы потерять месяц(или больше) на поиск кандидата со знанием кафки?
Или вы думаете, что не все способны осилить тайную магию асинхронного обмена?
Проясните свою позицию, пожалуйста.

Здравствуйте, Sharov, Вы писали:

S>К тому же это все-таки не олимпиадные задачи, а вполне обычные.

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

S>Речь идет о том, чтобы прорешать порядка 100 задач литкоде.

Допустим, по полчаса на задачу. Это уже 50 часов. Больше полной 40-часовой рабочей недели. Не лучше ли потратить их на что-то другое?

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

S>В чем проблема провести один день, вечер, пару часов, решая задачу для фирмы, куда очень хочешь попасть?

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

Еще вполне может оказаться, что тестовое не на один вечер.

S>Блин, неугодишь: алгоритмы -- плохо, тестовые -- плохо.

Да, жизнь, сука, суровая штука

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

Ну вот такие рассуждения вполне могут выдать и сферического теоретика. Ибо, условно, вставка в list -- это O(1), но если мы говорим о C++, то это O(1) может запросто умножиться на стоимость динамической аллокации и все, вставка в середину вектора (в котором capacity > size) запросто может оказаться дешевле.

S>Если много операций вставки, то сс лучше, если много поиска -- то массив.

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

1. Опыт работы в крутых компаниях типа яндекса.

2. Крутой гитхаб профиль.

Здравствуйте, Baiker, Вы писали:

B>Как программисту доказать, что он — профи высшего класса?

Для работодателя

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

Для себя

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

Про говнокод

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

Программист супер

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

Программист лошок

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

Синдром самозванца

Потому пошёл этот самоанализ в ...у. Мне интересно только какое слово люди подставляют вместо трёх точек.

Здравствуйте, LuciferSaratov, Вы писали:

LS>а как так получилось, что профи высшего класса вообще на такое собеседование попал?

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

Здравствуйте, Baiker, Вы писали:

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

B>Как быть, кого бить, что делать?

Попросить и сделать тестовое задание. Или online coding, где можно что-то обсудить.

Здравствуйте, ути-пути, Вы писали:

vsb>>1. Опыт работы в крутых компаниях типа яндекса.

УП>В смысле, умение гонять туда-сюда json?

Ну как минимум — туда ещё попасть надо. Я слыхал, что там адские собеседования, по несколько часов мучают людей. Это как в МГУ и подобными университетами. В целом там не учат ничему такому, чему не учат в других университетах. Но жесточайший фильтр на входе даёт высокое качество студентов, и даёт возможность отчислять тех, кто учится плохо. В итоге средний выпускник таких университетов гораздо лучше среднего выпускника обычных университетов. Так и с яндексом.

А json-ы везде гонять надо.

Да и кроме json-ов, очевидно, там хватает алгоритмо-ёмких приложений. У них же куда ни плюнь — везде хайлоад.

Здравствуйте, Sharov, Вы писали:

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

Нанятый после online-coding-а специалист у вас на работе будет:

a) решать алгоритмические задачи и
b) будет вслух рассуждать при их решении?

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

S>Но идеально это все же тестовое задание, приближенное к реальности, и его последующее
S>обсуждение.

Это очень и очень далеко от online-coding-а на собеседовании. И да, если это делается нормально со стороны работодателя, то это очень затратно для самого работодателя.

S>И то, и то -- сказать фи и исправить на "как надо". Объеменой писанины не требуется, т.е. даже не надо,
S>чтобы код компилировался.

Мне тут давеча интересная статья на глаза попалась: Захватывающая ловля багов, которые портили работу Unbound. И в контексте разговора про "исправить на "как надо"" хочется спросить: а что же там люди, имея исходники на руках, не посмотрели, не разобрались по коду, не сделали как надо? Вместо этого они долго ловили моменты возникновения проблем и использовали специализированные инструменты чтобы понять что и как происходит.

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

void f() {
  int * buf = new int[40960];
  ...
  delete buf;
}

то это опять-таки будет проверка не того целевого признака. Т.к. в реальности придется разбираться с проблемами как из упомянутой статьи. И умение быстро вылавливать "типовых блох" в тривиальном коде здесь не поможет.

Здравствуйте, alpha21264, Вы писали:

A>Обычно на собеседовании тебя просят рассказать о себе (в смысле про прошлую работу), и сразу становится всё ясно.

Да вот нихрена не ясно! "Рассказать о себе" — это настолько тупой вопрос, что если (к примеру) тебе его задала девушка, можешь сразу забирать шляпу и идти домой, ТЫ ПРОВАЛИЛСЯ.

Если HR не стоеросовый долбоклюй, вопрос должен быть конкретным: "Расскажите о своих прошлых проектах и их самых интересных/трудных местах", а не "расскажи о себе".

Опять же, вот я как более-менее опытный п-зд не считаю обмен данными по TCP каким-то охрененным скилом. А вот для будущего проекта это прям вот "фича №1"!

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

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

Здравствуйте, Baiker, Вы писали:

B>Согласен, будь сейчас 90-ые, так бы и сделал.

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

Кажется, что лёгкого пути нет. Конференции, статьи, open source, известные проекты. Мыщъх книгами добился. Если опыт на виду, то на собеседовании будут обсуждать не твои навыки, а твоё видение решения проблем, чем ты им сможешь помочь.

Здравствуйте, Baiker, Вы писали:

B>Абсолютно солидарен, это лучший вариант! Но он лучший среди всего худшего, что мы сейчас имеем. Да и HR'ам давно пора перенять эту практику. Но чтобы обеим сторонам сэкономить время, мне хотелось бы иметь некий "документ", который достаёшь из широких штанин и все сразу говорят ~~"уберите это обратно!"~~ "О, какой у вас большой опыт!".

Как раз HR'ы могли бы легче отсеивать людей, не задалбывая нанимателя "техническими интервью".

Это импосибле. Как только появится такой способ подтверждения профессионализма разработчиков, то у тебя сразу вообще исчезнут все шансы найти работу, т.к. пока ты будешь пытать получить такой "документ" честным путём, всевозможные условные "индусы" добудут эти бумаги другими путями и займут все твои потенциальные рабочие места. Такое уже было не раз. Например, в 2000-х индусы полностью дискредитировали MS сертификацию, испоганили title Architect.

B>Насколько я понимаю, кроме "дать профи крепкую задачку" пока единственный вариант показать, насколько ты силён. Ну, хотя бы так.

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

Здравствуйте, Baiker, Вы писали:

B>Я ж грю: ты много спрашиваешь сантехника про резьбу? Ты просто вызвал, показал проблему — он её решил. На крайняк обсудил цвет краников. А развлекать задротов викториной — извини, ищи клоунов в зеркале.

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

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

B> в нём нет места тупарям, которые "эй, гыгы, сделай мне вот так!". Только ТОЧНЫЕ формулировки дадут правильный результат. Если ты этого не понимаешь — вон из профессии.

Душнилы с ChatGPT вынесут тебя первее.

Здравствуйте, Baiker, Вы писали:

B>Как программисту доказать, что он — профи высшего класса?

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

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

Здравствуйте, Baiker, Вы писали:

IT>>Это всё очевидно. Спасибо, кэп. Ты после того как тебе всё это расскажут всё-таки дай человеку возможность покодить. Узнаешь о нём много нового.
B>А никто код-ревью не отменял! Но ПОСЛЕ того, как чел показал, что из себя представляет. Задачка на дом в виде какого-нть "мессенджера" вполне подойдёт.

Для этого ввели в крупных компаниях так называемое system design interview. Буквально люди делают
дизайн fb, твитерра, инстаграмма и проч. соц. сетей онлайн. Т.е. не одними алг. задачами.
Т.е. навыки кодописания проверяются алг. задачами, а на сколько человек ориентируется в технологиях,
имеет инженерный подход, т.е. выбор между этим и тем в условиях ограничений, вот это вот все
проверяет этап под названием system design. Т.е. в крупных компаниях теперь минимум 2-3
собеседования. Задачки на дом для них плохо масштабируются (выше обсудили).

Здравствуйте, Codealot, Вы писали:

C>Ты действительно пытаешься сказать, что компилятор требует меньшей культуры разработки, чем сраный фейсбук?
Представь себе да. Если не путать сложность и культуру разработки, то в этом утверждении ничего странного нет. Именно в продуктах с древней историей очень часто культура разработки никакая (я работал над компилятором, если что). Но главное не это, Интел продает чипы, а не софт. Если убрать интеловский компилятор, то не изменится практически ничего, чего нельзя сказать об их чипах. В компаниях типа Интела первый сорт это разработчики железа, а не программисты.

Здравствуйте, Codealot, Вы писали:

S>>Компилятор для вот этого языка.
C>Выглядит не очень серьезно.
Не важно как выглядит для человека со стороны, главное что всякие автодески и прочие боинги платили за этот компилятор очень приличные деньги.

S>>А совсем недавно пришлось работать с одинм не очень публичным интеловским API — далеко не фонтан.
C>Вебсайт у фейсбука — тоже далеко не фонтан.
Да, но он работает и им пользуются сотни миллионов и он приносит миллионы в день. Интеллу миллионы приносят чипы, а не компилятор.

Здравствуйте, alpha21264, Вы писали:

A>Обычно на собеседовании тебя просят рассказать о себе (в смысле про прошлую работу),
A>и сразу становится всё ясно.

Про скилл баснеплёта?

Здравствуйте, so5team, Вы писали:

S>А можно как-то не называя имен: большая ли компания, характер деятельности (аусорсер, интегратор, сервисная компания, собственные продукты, банк, ...)?
S>И очень интересно, а чем вызвана такая экономия времени? Большой поток соискателей?

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

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

Здравствуйте, Codealot, Вы писали:

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

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

Здравствуйте, Sharov, Вы писали:

S>Совершенно мимо, плохая аналогия.

Враньё.

S>Скорее спросить про устройство автомобиля, какие системы сущ. --
S>подвеска, двигатель (принцип работы), трансмиссия, электроника и т.п. Водителю такси эти
S>знания не помешают, равно как и программисту сис. дизайн.

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

Здравствуйте, Codealot, Вы писали:

S>>Но зачем?

C>Меньше расход памяти, и может быть быстрее.

На первый взгляд сомнительно. А есть какие-то примеры применения rope-структуры не для строк, а для чего-то другого?

S>>И непонятно в чем преимущество rope для T перед каким-нибудь условным списком чанков одинаковой емкости.

C>А это не частный случай веревки?

rope -- это дерево, причем желательно, чтобы оно было сбалансированным, т.е. при большом количестве кусочков оно должно быть "высоким". Тогда как список чанков -- это "плоская" структура.

Тут более актуален вопрос: а не является ли rope с листами фиксированной емкости (да еще и в которых есть пустоты) частным случаем какого-нибудь B-дерева?

S>>Как бы то ни было в контексте C++ rope вряд ли может дать те гарантии, какие дает список (они перечислялись выше).

C>Веревка позволяет реализовать даже доступ по индексу

Если нужен доступ по индексу, то список изначально мимо кассы.

C>и использовать пул заранее выделенных сегментов никто не запрещает.

Могу предположить, что геморра больше, т.к. rope гораздо более сложная структура, ее на коленке не сделаешь. В отличии от интрузивного списка.

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

Ну вот а мне бывает нужно именно это.

Здравствуйте, Baiker, Вы писали:

B>Как программисту доказать, что он — профи высшего класса?

Вот 1 раз в жизни проходил собеседование...
Я не профи.
Взял с собой 3 тестовые версии своих программ на дискетах (под вин3.1, с текстами). Показал. Сразу предложили временную работу — написать за 2 месяца программу... позже взяли в штат.

Здравствуйте, Sharov, Вы писали:

S>В какой из?

а вот в этой самой — мс. А что, это что-то меняет?

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

Нет, не только они. Там вопрос только о надувании пузыря акций, и ни о чем больше.
К тому же, как я уже сказал, конкретно FAANG уже устарел. Сейчас вместо него MAMAA.

Здравствуйте, Sharov, Вы писали:

S>Для этого ввели в крупных компаниях так называемое system design interview.

Дизайн интервью обычно дают архитекторам. А разработчикам уже обычно такое не дают, ибо не их это задача.

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

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

Здравствуйте, Sharov, Вы писали:

S>Не знаю, но насколько понял, в гуглах и фб дают вообще всем. Может кроме самых начинающих, а когда
S>уже какой-никакой есть опыт, то скорее всего спросят. А что в этом такого, кроме архитекторов никто
S>не должен разбираться, как устроены и работают масштабные сервисы? Хотя бы на понятийном
S>уровне понимать надо практически всем.

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

S>Ну все теперь, конченные люди, раз Кафку не видели. Вот это типичное отличие нашего подхода к западному --
S>там смотрят на более общие, абстрактные вещи, в том числе сис. дизайн, как человек думает, подход к решение.
S>А у нас дрючат конкретное api -- не знаешь, досвидание. Поэтому там -- ит инновационное, а здесь -- догоняющее.

Кафка — не единственный способ асинхронного обмена. Хоть с какой-нибудь шиной поработали бы или с RabbitMQ. Опять-таки, как ты себе представляешь человека, который может успешно пройти современное дизайн-интервью, не имея представления об асинхронном обмене? Что он может сказать о событийно-ориентированной архитектуре?

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

Мужики, вопрос такой необычный, но всё же ИТшный.

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

У п-стов нет медалей, "чёрных поясов", малиновых штанов и грамот "лучший погромизд года". Даже наколок нет!
И вот приходишь ты (лет в 40) в компанию, а тебя как студента-задрота начинают спрашивать, чем отличается делегат от события. Так-то ты внутри себя фэйспалмишь, но работодатель настолько туп, что считает свои "экзамены" важным звеном найма, напрочь игнорируя другие методы. А так ты ему показал "корочку" или медальон какой — и всё сразу понятно, это "старейшина" и он всё знает (это чисто как пример, где могут пригодиться твои регалии).

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

Можно указать (в CV) проекты, над которыми ты работал, но они слишком косвенный материал — мало ли, что ты там в проекте делал! Сам-то проект — какой-нть "банк", но ты там может так наговнокодил, что люди до сих пор разгребают, так что уровень пректа — не критерий. ОТСУТСТВИЕ таких проектов — критерий, но наличие проектов — необходимый, но не достаточный признак твоего уровня. Хуже того — практически ВСЕ коммерческие проекты идут под NDA, так что даже имея крутые сорсы, ты практически бессилен.

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

Есть ещё опенсорс, но там тоже то ещё болото: представьте говнопроект, где ты решил добавить функцию — сама-то функция написана нормально, но из-за интеграции с дерьмовой архитектурой, ты понаписал кучу клее-кода, без которого магия не работает. Со стороны это выглядит как говнокод, но это необходимое зло. Да и не докажешь каждому HRу, что ты молодец, что вообще смог туда впихнуть полезный функционал (попутно изучив весь код проекта).
Собственный проект? Опять же, сколько погромиздов, столько и мнений (в которых они не упустят шанс обосрать твой проект в собственном видении мира). Да и код — чтобы понять его качество, придётся разбираться со всем проектом — этот путь явно не для HR'ов (и даже не для других программистов — они с наскока просто ничего не поймут).

Есть ещё всякие онлайн экзамены, но это просто шелуха — знание мелких деталей языка или технологии, НИЧЕГО не говорящие о твоей способности писать хороший код.

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

Как быть, кого бить, что делать?

Если профи высшего класса — это тот, кто решает проблемы, которые не могут решить профи более низких классов, то:
1) он может сразу начать рассказ о себе с этих проблем, описания долгих неудачных попыток их решения другими профи и своего гениального их решения.
2) может предоставить контакты лиц, рекомендующих его именно как профи высшего класса (лиц, боле-менее близких к топ-менеджменту, а не просто коллег-программистов.)
3) если на рынке есть потребность в решении подобных проблем, то искать работу ему просто не придется (работодатели сами его найдут). но может случиться и так, что такой высокий класс профи просто не востребован. тогда по-любому придется понижать свои требования к работодателю.

Здравствуйте, Codealot, Вы писали:

C>Профессионализм в программировании, и профессионализм в пролезании в любую дырку без мыла — не одно и то же.

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

Здравствуйте, mike_rs, Вы писали:

_>если же где-то собеседующие вообще не относятся к команде, куда идет набор — то оттуда надо бежать сразу.

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

И ничего с этим поделать нельзя, процесс есть процесс.

Бежать ли от компаний масштаба Яндекса, Касперского, Сбера, VK и пр. "гигантов" каждый решает для себя. Но многие специально ищут работу только в крупных компаниях, т.к. там есть свои плюшки, которых нет у мелких работодателей.

Здравствуйте, Sharov, Вы писали:

S>>>Или online coding, где можно что-то обсудить.
S>>ИМХО, это одна из худших вещей, практикующихся на собеседованиях

S>1)Почему?

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

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

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

S>2)Чем те же code review на собесах плохи?

Тут нужно определиться: соискателю нужно на интервью код писать в online IDE или же посмотреть на уже написанный кем-то код и высказать свое "фи"?

Здравствуйте, mike_rs, Вы писали:

_>ты сколько собеседований провел?

Я думаю, побольше тебя.

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

Это в теории. А на практике, сначала кандидата долго выспрашивают про знание X, а потом внезапно оказывается, что на самом деле в основном нужно знание Y, которое к X вообще никак не относится. Примеров такого я видел немало.
А часто и вовсе спрашивают какой-нибудь Z, например алгоритмические задачи, которые ни к X ни к Y никакого отношения не имеют.

_>и насколько он вообще адекватен в общении.

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

_>если же где-то собеседующие вообще не относятся к команде, куда идет набор — то оттуда надо бежать сразу.

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

Здравствуйте, vsb, Вы писали:

vsb>Ну как минимум — туда ещё попасть надо. Я слыхал, что там адские собеседования, по несколько часов мучают людей.

Оптимист

Запросто может быть целый день.

vsb>Так и с яндексом.

На самом деле нет. Но многие в это верят.

Здравствуйте, Codealot, Вы писали:

C>Это в теории. А на практике, сначала кандидата долго выспрашивают про знание X, а потом внезапно оказывается, что на самом деле в основном нужно знание Y, которое к X вообще никак не относится. Примеров такого я видел немало.
C>А часто и вовсе спрашивают какой-нибудь Z, например алгоритмические задачи, которые ни к X ни к Y никакого отношения не имеют.

зачем ты это делаешь?

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

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

C>Вот ты и подтверждаешь ровно то, что я только что написал.

абсолютно нет

C>То есть, практически из любой компании крупнее чем "десяток студентов в подвале" придется бежать.

нет

Здравствуйте, so5team, Вы писали:

S>Здравствуйте, Sharov, Вы писали:

S>>>>Или online coding, где можно что-то обсудить.
S>>>ИМХО, это одна из худших вещей, практикующихся на собеседованиях

S>>1)Почему?
S>Некоторым людям (включая меня) нужно прежде подумать, возможно, разрисовав несколько листочков каракулями или сделав несколько черновых набросков, а лишь затем начать писать код. Когда интервью идет он-лайн да еще и время его ограничено, то как-то сидеть и молчать перед веб-камерой пока на тебя недоуменно смотрят с другой стороны... Ну такое себе.
S>Некоторые люди сильно стрессуют на интервью. Этот стресс сказывается на способности писать код (особенно если человек привык это делать в какой-то определенной IDE, а не в той он-лайн системе, которую используют на собеседовании). А осознание того, что ты не можешь хорошо себя показать именно в написании кода (т.е. в основной деятельности) стресс только усиливается и эта спираль давления еще больше раскручивается в худшую сторону.

Увы, это так. А что особого стресовать на алгоритмических задачах -- размышляй в слух, особого
знания языка они не требуют. Тут надо тупо практиковаться, т.е. набивать руку на самих задачах+
проходить mock-интервью. Сейчас полно таких услуг. Лично я считаю, что средней сложности алг.
задачки вполне посильно писать и онлайн, т.е. если человек неплохо подкован в алгоритмах, то
особых проблем не будет. Но идеально это все же тестовое задание, приближенное к реальности, и его последующее
обсуждение. Вероятно, это подход не очень масштабируется для FAANG конвейера. Все-таки надо вникать в решение
соискателя, что может потребовать сущ. больше времени.

S>Хотя, может для проверки джунов в написании сортировки пузырьком и нормально, не смотря на вышеперечисленные недостатки.
S>>2)Чем те же code review на собесах плохи?
S>Тут нужно определиться: соискателю нужно на интервью код писать в online IDE или же посмотреть на уже написанный кем-то код и высказать свое "фи"?

И то, и то -- сказать фи и исправить на "как надо". Объеменой писанины не требуется, т.е. даже не надо,
чтобы код компилировался.

Здравствуйте, so5team, Вы писали:

S>>Лично я считаю, что средней сложности алг.
S>>задачки вполне посильно писать и онлайн, т.е. если человек неплохо подкован в алгоритмах, то
S>>особых проблем не будет.
S>Нанятый после online-coding-а специалист у вас на работе будет:
S>a) решать алгоритмические задачи и
S>b) будет вслух рассуждать при их решении?

В Я. и FAANG реально надо уметь в алгоритмы и алг. сложность. Уж больно много
у них пользователей и плодить N^2 там, где можно NlogN крайне нежелательно.
Т.е. это обязательный навык. Как кроме кодинга онлайн его проверить? По скольку
это все же не показатель, добавили system design интервью. Проверка общего архитектурного
видения, каких-то других базовых знаний и пониманий, а не только алгоритмы.

S>Если хотя бы по одному из этих пунктов получается "нет", то с высокой долей вероятности на собеседовании вы будете проверять не тот целевой признак.

Вы так говорите, как будто это я решения принимаю. Это процесс устоявшийся и дающий результаты.
Кто хочет, тот будет готовиться и учиться проговаривать решение в слух. Тут только практика.
Да, для всех этих компаний важно не нанять плохо инженера в первую очередь, гораздо важнее,
чем упустить хорошего инженера. Поэтому такие фильтры и ставят. Дофигищи хороший инженеров,
кот. эти фильтры не проходят. Что поделать... Те, кто проходят, значит 1) что-то знают и
умеют 2) сильно надо\хотят. Значит можно довести до ума уже у себя внутри. Плохо, что упускают
таланты, но могут сами растить неплохих инженеров.

S>>Но идеально это все же тестовое задание, приближенное к реальности, и его последующее
S>>обсуждение.
S>Это очень и очень далеко от online-coding-а на собеседовании. И да, если это делается нормально со стороны работодателя,
то это очень затратно для самого работодателя.

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

S>>И то, и то -- сказать фи и исправить на "как надо". Объеменой писанины не требуется, т.е. даже не надо,
S>>чтобы код компилировался.

S>Мне тут давеча интересная статья на глаза попалась: Захватывающая ловля багов, которые портили работу Unbound. И в контексте разговора про "исправить на "как надо"" хочется спросить: а что же там люди, имея исходники на руках, не посмотрели, не разобрались по коду, не сделали как надо? Вместо этого они долго ловили моменты возникновения проблем и использовали специализированные инструменты чтобы понять что и как происходит.

SkyDance тут годами продвигает, что один из важнейших навыков это умение читать и понимать код.
А не писать. Как это делать на интервью -- хз. (Я не про простейшие code review задачи на собеседовании.)

S>В том-то и дело, что если соискателю предлагать простые задачки, которые можно проверить в условиях стресса и ограниченного времени, вроде вот такой:
S>

S>void f() {
S>  int * buf = new int[40960];
S>  ...
S>  delete buf;
S>}
S>

S>то это опять-таки будет проверка не того целевого признака. Т.к. в реальности придется разбираться с проблемами как из упомянутой статьи. И умение быстро вылавливать "типовых блох" в тривиальном коде здесь не поможет.

Не знаю, без понятия. Ну вот онлайн кодинг это лучше чем ничего. Хоть что-то.

Здравствуйте, Codealot, Вы писали:

C>... цель собеседования — подогреть ЧСВ тем кто его проводит, и попытаться убедить кандидата, что он недостаточно достоин хорошей зарплаты.

Про это и речь! Это как-то даже пóшло — имея за плечами годы разработки, обсуждать с усатыми 25-летними "сеньорами" как перегрузить метод. А сказать им "давайте сразу к делу" — могут вообще обделаться (т.к. 99% их "подготовленных каверзных вопросов" нахер не нужны) и закончить собес.

Здравствуйте, scf, Вы писали:

scf>А ты расскажи, чем отличается делегат от события

А я не хочу!

Я вообще не хочу обсуждать то, что является моей РАБОЧЕЙ РУТИНОЙ. Тем более, что ООП-теория широка, но практически применяются от силы 30%.
Вот ты приглашаешь сантехника, и тут ошарашиваешь его вопросом: "А чем резьба на 1/2 отличается от 3/4?". Он на тебя посмотрит как на придурка, плюнет и уйдёт.

И будет прав.

C>>... цель собеседования — подогреть ЧСВ тем кто его проводит, и попытаться убедить кандидата, что он недостаточно достоин хорошей зарплаты.
Это не везде так
Посмотри видос, который я запостил в Работе.
Там только один из 4 работодателей такой.
Остальные — вполне адекватные мужики в возрасте.
B>Про это и речь! Это как-то даже пóшло — имея за плечами годы разработки, обсуждать с усатыми 25-летними "сеньорами" как перегрузить метод. А сказать им "давайте сразу к делу" — могут вообще обделаться (т.к. 99% их "подготовленных каверзных вопросов" нахер не нужны) и закончить собес.
И слава Богу, что закончат.
Оно тебе надо с такими юнцами работать?

V>>Если ты можешь решить задачу работодателя за приемлемое время и на выходе будет хорошо работающая программа, то значит ты наёмный программист высшего класса для этого работодателя.
B>По идее — да. Но одно только обсуждение условий задачи может занять целый день! Хорошо, если другой тоже квалифицированный прогер тебя собеседует — тогда он по одним только вопросам поймёт, что ты секёшь фишку. А если нет? В том и есть проблема — ты-то сам можешь быть хорош, но хороши ли твои наниматели, чтобы оценить, насколько ты хорош??
А оно тебе надо с такими нанимателями работать?
B>Тут уместно будет вспомнить Влада и Немерлю: со стороны это выглядит как некий чувак пилит язык. Причём язык никому неизвестный, язык что-то там такое делает, но никто не оценит крутость языка, если в голове у него "бейсик". А на деле это титанический, глубокий труд, требующий тонну знаний, хаков, оптимизаций и прочего. "Создать свой язык" (хороший язык, а не пестоны всякие) — это охренеть какой труд!! Кто бы ещё это мог это оценить...
Профи — оценит. Но это хардскиллы.
Другое дело, что возникает вопрос по софтскиллам: а чего это перец пилит такой проект в одиночку и забесплатно?
И вопросы можно начать задавать совсем другого плана...

Здравствуйте, Sharov, Вы писали:

S>>Нанятый после online-coding-а специалист у вас на работе будет:
S>>a) решать алгоритмические задачи и
S>>b) будет вслух рассуждать при их решении?

S>В Я. и FAANG реально надо уметь в алгоритмы и алг. сложность. Уж больно много
S>у них пользователей и плодить N^2 там, где можно NlogN крайне нежелательно.
S>Т.е. это обязательный навык.

Ну т.е. всего одно "да" из двух

S>>Если хотя бы по одному из этих пунктов получается "нет", то с высокой долей вероятности на собеседовании вы будете проверять не тот целевой признак.

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

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

B> Я вообще не хочу обсуждать то, что является моей РАБОЧЕЙ РУТИНОЙ.

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

Здравствуйте, Baiker, Вы писали:

IT>>Тогда нужно давать определение "крепости"

B>Рассуждения над такими задачами и показывает, куда человек готов расти (или уже вырос). А умеет ли он "изменить один символ, чтобы программа заработала" — это вот туда, к джунам.

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

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

Здравствуйте, Baiker, Вы писали:

IT>>Да и нанимать "чела на синхронизацию" — это тоже не понятно о чём. У вас что, есть позиция, где нужно по 8 часов в день 5 дней в неделю не покладая рук всё подряд синхронизировать?

B>Это ты не уловил фишку. Человек должен выбираться как породистый щенок — "на перспективу". Если чел рассуждает как настоящий инженер, мне похрен, делал он обмен данными или нет — я знаю, что он РЕШИТ эту задачу.
B>Собственно, специалист до седых мудей ПОСТОЯННО сталкивается с новыми задачами — ничего страшного в этом нет, главное — чтобы он думал инженерно, думал о перспективе. Многие неизвестные мне задачи решались буквально одним часом гугло/чтения.

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

Здравствуйте, Baiker, Вы писали:

B>А никто код-ревью не отменял! Но ПОСЛЕ того, как чел показал, что из себя представляет. Задачка на дом в виде какого-нть "мессенджера" вполне подойдёт.

Сразу фсат. У тебя денег хватит оплатить моё время?

Здравствуйте, Baiker, Вы писали:

B>

Я понимаю, что ты имеешь ввиду, но ... ты как раз спускаешься к примитивам, которые осваиваются буквально за час ... Кратко, моя позиция проста: если 5-10 лет опыта есть — чела УЖЕ можно не доё___ывать своими языковыми/библиотечными шарадами. А вот порассуждать об инженерных решениях — надо непременно.

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

Здравствуйте, Baiker, Вы писали:
B>Будешь "отказывать", когда усы вырастут

]

мои усы давно седые

и с сединой пришло больше понимания "противоположной" стороны ( работодателей )
и что кандидаты часто с реальными закидонами ( а также то что я и сам был таким )
и что софт скилы/отсутствие токсичности не менее важно чем основные скилы

B>Я ж грю: ты много спрашиваешь сантехника про резьбу? Ты просто вызвал, показал проблему — он её решил.

Или не решил. И затопил весь дом говном.
Лучше заранее выяснить, что чел реально умеет.
Все конечно трудно узнать, но хоть что-то.
Если про резьбу не знает, ну его нафиг.

B>Облака. Облака мечтателей.

Про "рассказать о себе" уже написал.

Я о том, что стоит использовать первую же возможность рассказать о себе как о решателе проблем, с которыми не справляются другие. Если это так, конечно.
Если твой выбор в этой ситуации — "сразу забирать шляпу и идти домой" — ну ОК. Понимаешь, что даже девушку впечатлить своим рассказом не сможешь. (Хотя для большинства это гораздо легче, чем впечатлить профи.)

B>Контакты — ну такое себе... КТО и как может понять твой "гениальный код", если его даже в глаза не видел?? (это я про твоих "близких к топ-менеджменту") Как раз программист может оценить чужой код, насколько тот "хорош".

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

B>П.3 вообще какая-то идея из мира розовых пони. Вот когда программистов было 10 человек на всю планету, тогда да — их искали. Сейчас их МИЛЛИОНЫ, никто тебя при таком "предложении" искать не будет. Кроме мафии и налоговой.

Если мы всё ещё о профи высшего класса — их явно не миллионы. Если выделиться из этой миллионной массы — трудная задача для профи, то вряд ли можно говорить о его высшем классе. Можно быть лучше 80% или даже 90% программистов, но это еще не высший класс. Ну, может быть, первый. Успехов!

Здравствуйте, Baiker, Вы писали:

B>Я ж грю: ты много спрашиваешь сантехника про резьбу? Ты просто вызвал, показал проблему — он её решил.

А иногда и не решил.

Нормальных сантехников находят по сарафанному радио.

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

С программистами то же самое — на словах он охрененный спец, а на деле пилил одну фичу 20 лет в одном НИИ.

Здравствуйте, mogadanez, Вы писали:

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

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

Здравствуйте, Skorodum, Вы писали:

S>Компилятор для вот этого языка.

Выглядит не очень серьезно.

S>А совсем недавно пришлось работать с одинм не очень публичным интеловским API — далеко не фонтан.

Вебсайт у фейсбука — тоже далеко не фонтан.

Здравствуйте, Baiker, Вы писали:

B>Мужики, вопрос такой необычный, но всё же ИТшный.

B>Как программисту доказать, что он — профи высшего класса?

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

Здравствуйте, Vladsav, Вы писали:

V>Скажите, а сколько времени нужно среднему разработчику, чтобы почитать про кафку и ответить на ваши вопросы? Неделя? Две недели?
V>Получается, что вы не готовы оплатить человеку 2 недели рабочего времени для изучения кафки, но готовы потерять месяц(или больше) на поиск кандидата со знанием кафки?
V>Или вы думаете, что не все способны осилить тайную магию асинхронного обмена?
V>Проясните свою позицию, пожалуйста.

Не надо так расстраиваться из-за отсутствия компетенций в части асинхронного взаимодействия.

Новому разработчику еще много чего придется изучить помимо кафки.

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

Здравствуйте, Sharov, Вы писали:

S>Буквально люди делают
S>дизайн fb, твитерра, инстаграмма и проч. соц. сетей онлайн.

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

Здравствуйте, Codealot, Вы писали:

S>>Буквально люди делают
S>>дизайн fb, твитерра, инстаграмма и проч. соц. сетей онлайн.
C>Тоже абсурд, только другой. Еще можно давать кандидатам задание сделать филе миньон. Если старательный — то справится, и отношение к нормальной работе имеет примерно такое же.

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

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

Здравствуйте, Sharov, Вы писали:

S>Это в основном спрашивают в фаанге(или что там сейчас, маам?), и что в этом для
S>них плохого, понять понимает ли кандидат тонкие места и может ли он прикинуть
S>нагрузку на систему и какие в ней могут быть ключевые узлы?

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

Здравствуйте, Sharov, Вы писали:

S>Мы же выше это уже обсудили -- все это так, но крупные компании идут на это, т.к. для них лучше не нанять хорошего
S>программиста, чем нанять плохого.

Так ведь решение около-олипиадных задачек не показатель "хорошести" для программиста. Вот в чем дело.

S>Для менее крупных компаний -- тестовое на дом, с обсуждением,
S>кажется ок.

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

S>У такого способа есть проблема, что про структуры
S>данных и алгоритмы можно реально выучить, не скомпилировав при это ни одной программы.

Зазубрить можно описания структур данных и оценки сложности тех или иных операций. Но зазубрить цепочку рассуждений... Не верится. Вы вот сами попробуйте ответить на общие вопросы вроде "Сохраняет ли сейчас актуальность такая структура данных, как связанный список? Почему вы так думаете? Согласны ли с тем, что vector всегда предпочтительнее? Если да, то почему? Если нет, то можете привести пример, где список предпочтительнее?"

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

Здравствуйте, Stanislav V. Zudin, Вы писали:

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

SVZ>Ты так говоришь, будто впечатление создаётся одномоментно.

Говорю потому, что первое впечатление может (и бывает) обманчивым. И чем длиннее общение, тем меньшее влияние оказывает именно первое впечатление. Лучше потратить лишние 30 минут на собеседовании, чем узнать, что с человеком не сработаешься уже на испытательном сроке.

SVZ>Как раз часа — полтора достаточно, чтобы всё обсудить и сформировать впечатление.

Ну вот полтора часа общения -- это да, это оптимальный срок. Больше -- уже можно начать уставать (да и выкраивать это время сложнее).
Меньше как-то не то. Разве что собеседуется молодой программист, с небольшим опытом.

Опять же, собеседование же не только для тех, кто нанимает. Но и соискатель так же должен иметь возможность задать свои вопросы чтобы составить впечатление для себя. В полтора часа уложиться еще можно, в час -- сложнее. ИМХО.

Здравствуйте, Codealot, Вы писали:

S>>Может быть, если бы на собеседовании вместо просьбы написать разворот списка вы бы попросили соискателя рассказать о том, что он думает о применимости списков (отдельно двусвязных, отдельно односвязных) в современных условиях, то результат был бы точнее?

C>Правильный ответ — "связные списки не нужны практически никогда"?

В вопросах на "порассуждать" нет правильных ответов (с) Однако, как-то так, да

Правда, в случае C/C++/Rust для списков (особенно интрузивных) применимость может быть найдена, и как раз об этом было бы интересно побеседовать.

Здравствуйте, Codealot, Вы писали:

SVZ>>Ну давай возьмём пример попроще. Прочитать/записать какой-нибудь dxf, odb++, docx. Это по силам?
SVZ>>Документация на ODB++ всего 500 с копейками страниц. Написать парсер с преобразованием сырых данных в нечто высокоуровневое, пригодное для работы редактора, тянет на 10 чел/мес — работа на одного, максимум на троих.
SVZ>>Правда, если ты не знаком с проектированием и производством печатных плат, то даже не найдёшь ошибку — ни в коде, ни в данных.

C>Так прочитать/записать, или провалидировать? Это разные вещи.

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

Здравствуйте, Codealot, Вы писали:

SVZ>>На этот вопрос у меня есть заготовленный ответ

SVZ>>Там даже есть про богомерзкий разворот односвязного списка

C>А что мешает использовать в этой задаче веревку?

Чем она лучше односвязного списка в приведённом примере?
Даже не так, как rope вообще применима в приведённом примере?

Список использовался, потому что нужно хранить упорядоченный набор элементов (вершин). Над каждым элементом можно производить манипуляции (изменение координат, добавление, удаление), не затрагивая соседние. Каждый элемент должен быть идентифицируемым. Списки делятся, объединяются очень легко.
Наконец, все операции должны поддерживать Undo/Redo.

Ну и как тут поможет rope, у которой очень специфичная область применения?

Здравствуйте, Codealot, Вы писали:

S>>Про rope я наслышан только в контексте строк (т.е. последовательностей байт или символов).

C>Ничто не мешает использовать его с любым типом элементов.

Но зачем?

Фокус rope string в том, что это дерево, в листах которого расположены непрерывные блоки с CharT произвольного размера. И понятно откуда эти блоки берутся (как и понятно почему они могут быть сильно разными).

Тогда как в случае замены CharT на произвольный T смысл этой кухни теряется.

И непонятно в чем преимущество rope для T перед каким-нибудь условным списком чанков одинаковой емкости.

Как бы то ни было в контексте C++ rope вряд ли может дать те гарантии, какие дает список (они перечислялись выше).

Здравствуйте, Codealot, Вы писали:

S>>На первый взгляд сомнительно. А есть какие-то примеры применения rope-структуры не для строк, а для чего-то другого?

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

Интересны примеры использования rope для чего-то отличного от строк. Ибо если это не строки, то смысл rope от меня ускользает.
Так что если вам известны примеры, то поделитесь ссылками, плз. Реально любопытно.

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

S>>Тут более актуален вопрос: а не является ли rope с листами фиксированной емкости (да еще и в которых есть пустоты) частным случаем какого-нибудь B-дерева?

C>B-дерево отсортировано.

Дерево в rope (по сути) тоже отсортировано (по порядковым номерам фрагментов). Тут суть в структуре, когда есть дерево в котором промежуточные узлы просто ведут вниз, а данные находятся в листьях.

Здравствуйте, Baiker, Вы писали:

B>Мужики, вопрос такой необычный, но всё же ИТшный.

B>Как программисту доказать, что он — профи высшего класса? ...

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

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

Здравствуйте, IT, Вы писали:

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

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

Здравствуйте, vsb, Вы писали:

vsb>Да и кроме json-ов, очевидно, там хватает алгоритмо-ёмких приложений. У них же куда ни плюнь — везде хайлоад.

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

Здравствуйте, Sharov, Вы писали:

S>Или online coding, где можно что-то обсудить.

ИМХО, это одна из худших вещей, практикующихся на собеседованиях

Здравствуйте, so5team, Вы писали:

S>>Или online coding, где можно что-то обсудить.
S>ИМХО, это одна из худших вещей, практикующихся на собеседованиях

1)Почему? Яндекс же практикует, те же алгоритмы + system design. Да и вообще весь FAANG.
2)Чем те же code review на собесах плохи?

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Baiker, Вы писали:

B>>Как программисту доказать, что он — профи высшего класса?

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

IT>Если ты "профи высшего класса" и тебе задают только дебильные вопросы на интервью, то ты там не хочешь работать и доказывать никтому ничего не надо.

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

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

А теперь один из современных сценариев. Работодатель это подросший "профи" из нулевых. И тут перед ним
появляется некий "профи высшего класса"... дальше уже все понятно.

Здравствуйте, LuciferSaratov, Вы писали:

LS>я вот что имел ввиду: по-моему, если мы ведём речь о действительно высококлассном профессионале, то всё происходит наоборот.
LS>то есть не он ищет работу, а работа ищет его.

Если только ты достаточно крут, чтобы быть знаменитым. Но, опять же, пиар — это отдельный талант.

Здравствуйте, kov_serg, Вы писали:

_>Показать свои яхты и остров.

И средний палец тем, кто хочет его нанять.

Здравствуйте, m2user, Вы писали:

M>Рейтинг на RSDN

Распределение сообщений по разделам.

Здравствуйте, LaptevVV, Вы писали:

LVV>"Корочки" нифига ничего не показывают и не доказывают.
LVV>Как опытный препод говорю: у чела может быть ЕГЭ 100 баллов, а он простейших вещей не знает.

Вот в этом и соль вопроса! Что может показать программист ПОМИМО тупых корочек, что могло бы хоть как-то показать его уровень?

Здравствуйте, Нomunculus, Вы писали:

Н>Здравствуйте, Baiker, Вы писали:

B>>Как быть, кого бить, что делать?

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

Ну не, вообще мимо.

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

Это вообще секретная инфа — меж сотрудниками таким не делятся.

Здравствуйте, vsb, Вы писали:

vsb>1. Опыт работы в крутых компаниях типа яндекса.

vsb>2. Крутой гитхаб профиль.

Вообще мимо кассы. Яндекс не более "крутой", чем любая другая компания, мусолящаяся в СМИ. Пыль в воздухе. Это не говоря о том, что величина компании никак не говорит о твоём лично опыте.

Гитхаб — уже упомянут в начальном сообщении, перечитай.

Здравствуйте, SergeyIT, Вы писали:

SIT>Здравствуйте, Baiker, Вы писали:

B>>Как программисту доказать, что он — профи высшего класса?

SIT>Вот 1 раз в жизни проходил собеседование...
SIT>Я не профи.
SIT>Взял с собой 3 тестовые версии своих программ на дискетах (под вин3.1, с текстами). Показал. Сразу предложили временную работу — написать за 2 месяца программу... позже взяли в штат.

Согласен, будь сейчас 90-ые, так бы и сделал.

Здравствуйте, L_G, Вы писали:

L_G>Если профи высшего класса — это тот, кто решает проблемы, которые не могут решить профи более низких классов, то:
L_G>1) он может сразу начать рассказ о себе с этих проблем, описания долгих неудачных попыток их решения другими профи и своего гениального их решения.
L_G>2) может предоставить контакты лиц, рекомендующих его именно как профи высшего класса (лиц, боле-менее близких к топ-менеджменту, а не просто коллег-программистов.)
L_G>3) если на рынке есть потребность в решении подобных проблем, то искать работу ему просто не придется (работодатели сами его найдут). но может случиться и так, что такой высокий класс профи просто не востребован. тогда по-любому придется понижать свои требования к работодателю.

Облака. Облака мечтателей.

Про "рассказать о себе" уже написал.
Контакты — ну такое себе... КТО и как может понять твой "гениальный код", если его даже в глаза не видел?? (это я про твоих "близких к топ-менеджменту") Как раз программист может оценить чужой код, насколько тот "хорош".
П.3 вообще какая-то идея из мира розовых пони. Вот когда программистов было 10 человек на всю планету, тогда да — их искали. Сейчас их МИЛЛИОНЫ, никто тебя при таком "предложении" искать не будет. Кроме мафии и налоговой.

LVV>>"Корочки" нифига ничего не показывают и не доказывают.
LVV>>Как опытный препод говорю: у чела может быть ЕГЭ 100 баллов, а он простейших вещей не знает.
B>Вот в этом и соль вопроса! Что может показать программист ПОМИМО тупых корочек, что могло бы хоть как-то показать его уровень?
Реально — ничего.
Только свои мозги — а это надо проверять каждый раз конкретно.
Другое дело, то собеседник может иметь менее умные мозги.
Более умный программист должен это понять, и просто уйти с собеса...

Здравствуйте, velkin, Вы писали:

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

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

Тут уместно будет вспомнить Влада и Немерлю: со стороны это выглядит как некий чувак пилит язык. Причём язык никому неизвестный, язык что-то там такое делает, но никто не оценит крутость языка, если в голове у него "бейсик". А на деле это титанический, глубокий труд, требующий тонну знаний, хаков, оптимизаций и прочего. "Создать свой язык" (хороший язык, а не пестоны всякие) — это охренеть какой труд!! Кто бы ещё это мог это оценить...

Здравствуйте, Baiker, Вы писали:

B>"Создать свой язык" (хороший язык, а не пестоны всякие) — это охренеть какой труд!! Кто бы ещё это мог это оценить...

Overqualified! Если нет сильной потребности в таких специалистах, то лучше их и не нанимать, а то потом всей командой код поддерживать не получится.

Здравствуйте, no_ise, Вы писали:

B>>Как программисту доказать, что он — профи высшего класса? ...

_>Можно посмотреть в сторону выравнивания переговорной силы

Увы, в мире ИТ найма всё перекошено, будто они зятя собеседуют и он им заранее не нравится

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

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

Здравствуйте, LuciferSaratov, Вы писали:

LS>Здравствуйте, Baiker, Вы писали:

B>>И вот приходишь ты (лет в 40) в компанию, а тебя как студента-задрота начинают спрашивать, чем отличается делегат от события.

LS>а как так получилось, что профи высшего класса вообще на такое собеседование попал?

Не поверишь — ПРИГЛАСИЛИ!

Что тут необычного-то? Тебе нет 40 или ты никогда не был на собесе?

Всё совершенно одинаково — будь ты хоть сенсей с седой бородой до пят, для них ты — "ещё один олух господень", которого как-то надо собеседовать.
К слову, в ИТ идут люди даже под полтинник. Вот работал чел завскладом и вдруг понял — у него призвание — программист!

Ну, или "что-то связанное с компьютерами" (для них это одно и то же). ТАКИХ тоже надо собеседовать и как-то сразу отсеивать. Короче, тот ещё квест. И ты среди ВСЕГО ЭТОГО...

Здравствуйте, vaa, Вы писали:

vaa>экзамены же есть у MS, Oracle и т.д.
vaa>тоже самое что и везде. Сдаешь — получаешь серт.
vaa>Они вроде котируются.

Уже написал в первом же сообщении — не читал?

Здравствуйте, IT, Вы писали:

IT>Программист должен уметь программировать, а не доказывать уровень своей компетентности

Вот! Прям с порога и хочется этим обухом остудить собеседующих!

Жаль, нельзя вот так прямо по голове.
Для них-то ты просто "чувак, откликнувшийся на вакансию" — где твои регалии? (о которых я сейчас и спрашиваю)
Может, ты пылесосы продавал, а сейчас, на склоне лет, выучил похапэху и пришёл сипипискать.

IT>Если ты "профи высшего класса" и тебе задают только дебильные вопросы на интервью, то ты там не хочешь работать и доказывать никтому ничего не надо.

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

Но словесно не у всех есть способности ставить других на место или деликатно опускать глупые вопросы и выстраивать интервью под себя — тут целая психология трудится!

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

Абсолютно солидарен, это лучший вариант! Но он лучший среди всего худшего, что мы сейчас имеем. Да и HR'ам давно пора перенять эту практику. Но чтобы обеим сторонам сэкономить время, мне хотелось бы иметь некий "документ", который достаёшь из широких штанин и все сразу говорят ~~"уберите это обратно!"~~ "О, какой у вас большой опыт!".

Как раз HR'ы могли бы легче отсеивать людей, не задалбывая нанимателя "техническими интервью".

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

Здравствуйте, LuciferSaratov, Вы писали:

LS>то есть не он ищет работу, а работа ищет его.

Не огорчайся на минус, но вот вообще не то говоришь. "Высококлассный" — это не обязательно "написал фирмварю для марсохода" (таких вообще с десяток на весь мир наберётся).
Профи — это тот, кто делает программу по критериям задачи + немного опережает развитие программы, закладывая её апдейт хотя бы лет на 10-20. Гибкость, простота, сопровождаемость, вот это вот всё. Оно только звучит очевидно, да только реальные программы — без слёз не взглянешь.

И никто такого спеца искать не будет — время не то. Да и что ты скажешь миру, чтобы тебя искали? "Ребята, я написал Тетрис"?
Максимум, на что может рассчитывать прогер "чтобы его искали" — это вот если у него ну прям ОЧЕНЬ хорошие отношения с боссом, прогер уволился и тут у босса спрашивают: "Посоветуешь толкового погромиздика?" — вот тут ЕСЛИ БОССУ НЕ ЛЕНЬ, он подымет контакты и тебя найдут. Этакое "сарафанное радио" с единственным связующим звеном, которое подвержено человеческому фактору.

Вот вспомнил кстати... за всю жизнь я общался с не очень большим кол-вом прогеров (наверное чел 50+) и вот спроси меня прямо сейчас "Дай контакт!" — а я даже и не знаю кого

Все как-то были в жизни, но вот чтобы прямо лезть в чужой код и оценивать — никогда не было. Каждый что-то писал (очевидное разделение проекта на задачи/людей) и в целом мы не особо пересекались, чтобы знать — "вот этот чувак — голова, я его уважаю!". Были, конечно, "самые главные ойтишнеги" — они билд делали, знали все тонкости проекта, но это.... детали, пыль, это ничего не говорит, доверю ли я такому кодеру писать код для моего кардиостимулятора.

У всех так?

Здравствуйте, alpha21264, Вы писали:

A>Обычно на собеседовании тебя просят рассказать о себе (в смысле про прошлую работу),
A>и сразу становится всё ясно.

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

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

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

Здравствуйте, s_aa, Вы писали:

B>>А я не хочу!

Я вообще не хочу обсуждать то, что является моей РАБОЧЕЙ РУТИНОЙ.

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

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

Здравствуйте, IT, Вы писали:

B>>Насколько я понимаю, кроме "дать профи крепкую задачку" пока единственный вариант показать, насколько ты силён. Ну, хотя бы так.

IT>Тут тоже не всё просто, потому как понятие "крепкая" может быть сильно извращено. Задача должна быть одной из таких, которыми претендент будет заниматься на данном проекте. А сейчас стало модно нагружать народ на интервью алгоритмическими задачами, которые интервьюверы и сами не в состоянии решать.

Алгоритмы — согласен, с "крепкая" — настаиваю на крепости.

Здравствуйте, Baiker, Вы писали:

B>Здравствуйте, IT, Вы писали:

B>>>Насколько я понимаю, кроме "дать профи крепкую задачку" пока единственный вариант показать, насколько ты силён. Ну, хотя бы так.

IT>>Тут тоже не всё просто, потому как понятие "крепкая" может быть сильно извращено. Задача должна быть одной из таких, которыми претендент будет заниматься на данном проекте. А сейчас стало модно нагружать народ на интервью алгоритмическими задачами, которые интервьюверы и сами не в состоянии решать.

B>Алгоритмы — согласен, с "крепкая" — настаиваю на крепости.

Тут ведь ты нанимаешь чела не только на текущую задачу "генерить репорты" — а если завтра понадобится сервис синхронизации? Опять нанимать "чела на синхронизацию"? Пусть решает сложную задачу. Потому что здесь не важно её конкретное решение, важен сам подход и вопросы. Немногие люди писали "банк", но если поставить такую задачу и попросить нарисовать десяток квадратиков, будет видно, как глубоко плавает специалист.

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

Здравствуйте, Baiker, Вы писали:

B>Здравствуйте, LuciferSaratov, Вы писали:

LS>>то есть не он ищет работу, а работа ищет его.

B>Не огорчайся на минус, но вот вообще не то говоришь.

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

дискуссия, в которой все участники согласны друг с другом, это не дискуссия.

B>"Высококлассный" — это не обязательно "написал фирмварю для марсохода" (таких вообще с десяток на весь мир наберётся).

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

B>Вот вспомнил кстати... за всю жизнь я общался с не очень большим кол-вом прогеров (наверное чел 50+) и вот спроси меня прямо сейчас "Дай контакт!" — а я даже и не знаю кого

B>У всех так?

вот у меня не так.
я, впрочем, оцениваю не с точки зрения "лезть в код" — у меня критерий оценки заключается в том, насколько хорошо человек решает проблемы, а не создаёт их.
и за свою трудовую карьеру могу вспомнить таких человек 5-6, про которых я с уверенностью скажу что вот он — голова.

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

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

Здравствуйте, Baiker, Вы писали:

B>Здравствуйте, no_ise, Вы писали:

B>>>Как программисту доказать, что он — профи высшего класса? ...

_>>Можно посмотреть в сторону выравнивания переговорной силы

B>Увы, в мире ИТ найма всё перекошено, будто они зятя собеседуют и он им заранее не нравится

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

B>Компания — это объект с деньгами и люди, которые знают про деньги и что "вас таких за забором целая очередь". Т.е. отношение заранее унижающее. Тем более, что большинство соискателей действительно охреневшее стадо, которое требует з/п миддла, а сами едва два класса унаследуют. Но ты-то не такой!

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

B>Собственно, потому и вопрос — как "оптимизировать" ненужный трёп и сразу перейти к части, где два РАВНЫХ субъекта обсуждают, на каких условиях они будут сотрудничать.
B>Вообще, "Медалька Профессионала" нужна не только тут. Скажем, если ты презентуешь программу и говоришь, что "в моей команде три медалиста", это уже серьёзная заявка на качество — люди смелее будут доверять продукту, который писала не шобла индусских макак с купленными курсами "сипипи за 10 дней", а настоящие, думающие инженеры.

Хорошо, в такой метафоре, все еще интереснее. Невест <<50%, невесты с тещами обычно
выходят замуж за двоих сразу. Первый — например архитектор class A, второй — class B чтобы
первый не зазнался; ну и известно что в компаниях больше шанса закрепиться у class B,
т.к. class A это со временем угроза невесте и теще.

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

Общее решение задачи как "оптимизировать ненужный трёп и перейти к части, где два
РАВНЫХ субъекта" я не знаю, вроде оно вообще неизвестно. Но такая ситуация
разыгрывается в разных областях, не только в программировании, можно посмотреть по сторонам.

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

Здравствуйте, Baiker, Вы писали:

B>Короче, вот нахрен не нужон никакой ваш Фконтакт с Одноглазниками, никакие Мелкософты с Теслами... никто из них не заменит мои 16 часов вне сна, которые я трачу С УДОВОЛЬСТВИЕМ именно потому, что не работаю на вас.

В мелкомягких свои тараканы, не те, что ты описал.

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

Просто детально и развёрнуто ответь.

V> Потому пошёл этот самоанализ в ...у. Мне интересно только какое слово люди подставляют вместо трёх точек.

Если самоанализ был психоанализом, то в "дурку".

B> вопрос — как "оптимизировать" ненужный трёп и сразу перейти к части, где два РАВНЫХ субъекта обсуждают, на каких условиях они будут сотрудничать.

Просто создай юрлицо и договаривайся как директор с директором. Меряться будете уставным капиталом, прибылью (EBITDA) и всё такое.

Здравствуйте, Baiker, Вы писали:

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

Здравствуйте, Baiker, Вы писали:

B>Алгоритмы — согласен, с "крепкая" — настаиваю на крепости.

Тут ведь ты нанимаешь чела не только на текущую задачу "генерить репорты" — а если завтра понадобится сервис синхронизации? Опять нанимать "чела на синхронизацию"? Пусть решает сложную задачу. Потому что здесь не важно её конкретное решение, важен сам подход и вопросы. Немногие люди писали "банк", но если поставить такую задачу и попросить нарисовать десяток квадратиков, будет видно, как глубоко плавает специалист.

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

Да и нанимать "чела на синхронизацию" — это тоже не понятно о чём. У вас что, есть позиция, где нужно по 8 часов в день 5 дней в неделю не покладая рук всё подряд синхронизировать?

IT> нанимать "чела на синхронизацию" — это тоже не понятно о чём.

Человек или умеет в многопоточность или нет (ну, или, промежуточные состояния).
Почему бы не выяснить это на собеседовании?

B>> будет видно, как глубоко плавает

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

Здравствуйте, mogadanez, Вы писали:

M>Здравствуйте, Baiker, Вы писали:

B>>Если HR не стоеросовый долбоклюй, вопрос должен быть конкретным: "Расскажите о своих прошлых проектах и их самых интересных/трудных местах", а не "расскажи о себе".

M>если человек до таких формулировок будет докапываться на этапе собеседования — то и в работе он будет тот еще душнила — отказано

Будешь "отказывать", когда усы вырастут

А пока что первый признак тупого задрота — это вот как раз этот паршивый слэнг из "кринж", "душнила" и т.п.
Если угодно, то компьютер — это и есть самый точный инструмент, в нём нет места тупарям, которые "эй, гыгы, сделай мне вот так!". Только ТОЧНЫЕ формулировки дадут правильный результат. Если ты этого не понимаешь — вон из профессии.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, Baiker, Вы писали:

B>>Я ж грю: ты много спрашиваешь сантехника про резьбу? Ты просто вызвал, показал проблему — он её решил. На крайняк обсудил цвет краников. А развлекать задротов викториной — извини, ищи клоунов в зеркале.

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

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

Это маловероятная вещь, как правило специалист с опытом 10+ лет УЖЕ считай "высший класс".
Но суть моего замечания не к тому, как докопаться к нанимаемому, а как ПРАВИЛЬНО, без пошлых игр в синтаксис и подкапотные тонкости, определить, стоит ли брать такого работника.
Собственно, тем и отличается ИНЖЕНЕР от кодера — инженер смотрит на задачу глобально, большими блоками, с перспективой развития. Ну а кодер — тот да, будет долго прищуриваться, знаешь ли ты сколько микросекунд работает StringBuilder супротив "" + "".

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Baiker, Вы писали:
B>>Алгоритмы — согласен, с "крепкая" — настаиваю на крепости.

IT>Тогда нужно давать определение "крепости"

Легко. Сложная задача — это любая "глобальная" задача, бизнес-продукт, где вообще нет разницы, на чём ты её пишешь (Склад, Банк, бухгалтерия, автоматизация продажи билетов и т.п.). Если это позиция сеньора, он должен нарисовать, как он в целом видит решение, затем спуститься чуть ниже и позадавать (или послушать!) каверзные вопросы. А что если интернет отключен? А что если сервер упал? Как сделать ID независимым? Как управлять складом на другом континенте? Как и где нужно защитить данные?
Рассуждения над такими задачами и показывает, куда человек готов расти (или уже вырос). А умеет ли он "изменить один символ, чтобы программа заработала" — это вот туда, к джунам.

Здравствуйте, IT, Вы писали:

IT>Да и нанимать "чела на синхронизацию" — это тоже не понятно о чём. У вас что, есть позиция, где нужно по 8 часов в день 5 дней в неделю не покладая рук всё подряд синхронизировать?

Это ты не уловил фишку. Человек должен выбираться как породистый щенок — "на перспективу". Если чел рассуждает как настоящий инженер, мне похрен, делал он обмен данными или нет — я знаю, что он РЕШИТ эту задачу.
Собственно, специалист до седых мудей ПОСТОЯННО сталкивается с новыми задачами — ничего страшного в этом нет, главное — чтобы он думал инженерно, думал о перспективе. Многие неизвестные мне задачи решались буквально одним часом гугло/чтения.

Здравствуйте, IT, Вы писали:

IT>Я ещё раз настаиваю — программист должен уметь программировать, а не рассказывать о том как он умеет программировать.

Я понимаю, что ты имеешь ввиду, но ... ты как раз спускаешься к примитивам, которые осваиваются буквально за час. Ну неужели чел с 5 годами стажа не напишет тебе программу?! Тут важно совсем другое: умение смотреть НАД задачей! Этому (теоретически) и должны были учить нас в школе: не заучивать, а находить методы и решения, получать информацию. Ты СЕЙЧАС хочешь решить задачу — написать какой-нть сервер для отчётов. Ну он и напишет тебе! Однопоточный, с дедлоками, с распухшей базой и нелокализуемый кусок г-на. Он же так уже делал!

А если бы ты заранее спросил, как-чё он собирается делать, ты бы сразу увидел — чел плавает по деталям, не видя общего.
Ладно, это всё рассуждения в воздухе. Кратко, моя позиция проста: если 5-10 лет опыта есть — чела УЖЕ можно не доё___ывать своими языковыми/библиотечными шарадами. А вот порассуждать об инженерных решениях — надо непременно.

Здравствуйте, IT, Вы писали:

IT>Это всё очевидно. Спасибо, кэп. Ты после того как тебе всё это расскажут всё-таки дай человеку возможность покодить. Узнаешь о нём много нового.

А никто код-ревью не отменял! Но ПОСЛЕ того, как чел показал, что из себя представляет. Задачка на дом в виде какого-нть "мессенджера" вполне подойдёт.

B> "на перспективу"

На какую перспективу, если ему 40+ ?

Здравствуйте, Baiker, Вы писали:

B>А никто код-ревью не отменял! Но ПОСЛЕ того, как чел показал, что из себя представляет. Задачка на дом в виде какого-нть "мессенджера" вполне подойдёт.

Из моей практики, не стоит даже начинать делать задачку.
Пока ее делаешь, прилетают 2-3 более интересных оффера, потому лучши придти домой и отдохнуть.

Здравствуйте, Baiker, Вы писали:

B>Здравствуйте, vaa, Вы писали:

vaa>>экзамены же есть у MS, Oracle и т.д.
vaa>>тоже самое что и везде. Сдаешь — получаешь серт.
vaa>>Они вроде котируются.

B>Уже написал в первом же сообщении — не читал?
ну вот ты хороший? тогда сдай экзамен по шарпу базовый желательно без подготовки.
А вообше правильный это который не кодит. Пример — БГ.

Здравствуйте, Sharov, Вы писали:

S>В Я. и FAANG реально надо уметь в алгоритмы и алг. сложность. Уж больно много
S>у них пользователей и плодить N^2 там, где можно NlogN крайне нежелательно.

На собеседованиях они это умеют. В реальности — не очень.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>А иногда и не решил.

SVZ>Нормальных сантехников находят по сарафанному радио.

Это если стройка/ремонт.

SVZ>Либо стоит сперва выяснить, что умеет и делал ли раньше то, ради чего ты его вызвал.
SVZ>Я то я таких сантехников встречал...

А вызвать проще местного, из ЖЭКа. Базовые вещи, ради которых вызывают, он всяко умеет.

Здравствуйте, Codealot, Вы писали:

S>>В Я. и FAANG реально надо уметь в алгоритмы и алг. сложность. Уж больно много
S>>у них пользователей и плодить N^2 там, где можно NlogN крайне нежелательно.
C>На собеседованиях они это умеют. В реальности — не очень.

Работали в FAANG?

Здравствуйте, Baiker, Вы писали:

B>Мужики, вопрос такой необычный, но всё же ИТшный.

B>Как программисту доказать, что он — профи высшего класса?

Увеличить п-с? Деньги есть значит ПРО!

Здравствуйте, Baiker, Вы писали:

B>Как программисту доказать, что он — профи высшего класса?

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

Здравствуйте, Sharov, Вы писали:

S>Работали в FAANG?

Только в одной из этих 5 компаний, не включая никакие другие?
А ты в курсе, что этот термин означает и почему?

Здравствуйте, Codealot, Вы писали:

S>>Работали в FAANG?
C>Только в одной из этих 5 компаний, не включая никакие другие?

Можно ms добавить. Вы там работали или работаете?

C>А ты в курсе, что этот термин означает и почему?

Да, наиболее хайповые американские ит компании -- fb, amzn, apple, netflix, goog.
Можно и мс добавить. Но в этих компания дрючат гномиков и системный дизайн
на собеседования. Как в мс -- не знаю.

Здравствуйте, IT, Вы писали:

B>>А никто код-ревью не отменял! Но ПОСЛЕ того, как чел показал, что из себя представляет. Задачка на дом в виде какого-нть "мессенджера" вполне подойдёт.
IT>Сразу фсат. У тебя денег хватит оплатить моё время?

Здрасте, ну вот если будут давать 2ю5х от текущей зп, при условии, что решите домашнюю задачку без
оплаты, то пошлете их? Речь идет о задачах на один-два дня, от силы.
Может и вовсе пару часов.

Здравствуйте, Sharov, Вы писали:

S>Можно ms добавить. Вы там работали или работаете?

Таки да. И что теперь скажешь?
Отмечу на полях — а что, какой-нибудь там Интел — среди реальных пацанов не котируется как место работы?

S>Да, наиболее хайповые американские ит компании -- fb, amzn, apple, netflix, goog.

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

Здравствуйте, Codealot, Вы писали:

S>>Можно ms добавить. Вы там работали или работаете?
C>Таки да. И что теперь скажешь?

В какой из?

C>Отмечу на полях — а что, какой-нибудь там Интел — среди реальных пацанов не котируется как место работы?

Не я эту аббревиатуру выдумал.

S>>Да, наиболее хайповые американские ит компании -- fb, amzn, apple, netflix, goog.
C>Именно что хайповые, главным образом в плане роста акций. Причем данные уже устарели, и нетфликс из списка исключили. Но не слишком умные люди продолжают на него наяривать, даже не понимая, что в этом списке такого "крутого".

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

Здравствуйте, Worminator X, Вы писали:

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

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

B>Как программисту доказать, что он — профи высшего класса?

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

у самого такая же проблема
пока моё текущее понимание такое:
найм всегда был нездоровым процессом
всё в основном решает не скил или талант, а уровень конкуренции на рынке
свой проект коммерчески оправданный может удастся сделать — одна надежда окупить талант
ну а если возможности нет, то ~"потенциал без возможности его применить ничего не стоит" (с) (Наполеон)

Здравствуйте, Codealot, Вы писали:

C>Отмечу на полях — а что, какой-нибудь там Интел — среди реальных пацанов не котируется как место работы?
Интел продает кремний, а не софт и услуги. Для них софт это всегда второстепенно.
В среднем по больнице у производителей чипов культура разработки ниже.

Здравствуйте, Worminator X, Вы писали:

WX>это скорее электрик, чем ученый.
+1 только стандартные практики среди новых электриков еще не польностью устаканились. Для примера можно посмотреть на уровень владения гитом.

Здравствуйте, Skorodum, Вы писали:

S>Интел продает кремний, а не софт и услуги. Для них софт это всегда второстепенно.
S>В среднем по больнице у производителей чипов культура разработки ниже.

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

Здравствуйте, so5team, Вы писали:

S>b) будет вслух рассуждать при их решении?

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

Здравствуйте, Codealot, Вы писали:

S>>b) будет вслух рассуждать при их решении?

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

Я про другое. На собеседованиях просят порассуждать в слух типа для того, чтобы посмотреть, как человек думает, и ждут чего-то вроде "Так, значит нам нужно получить вот это... Можно попробовать вот так... А нет, здесь не получится потому-то и потому-то. Значит нужно получить вот это с учетом вот этого. Раз это не сработало, то можно попробовать вот так..." и т.д., и т.п. Даже если не затрагивать вопрос о том, насколько такие "рассуждения вслух" соотносятся с реальным процессом размышления. Просто можно представить себе что будет творится на рабочих местах, если программисты будут "думать вслух" в прямом смысле слова: один такой "здесь почему-то потребление CPU упирается в потолок, хотя быть такого не должно, значит ща запустим профайлер, посмотрим... Ага, вот здесь мы жрем слишком много, но почему?..." А за соседним столом другой: "этот запрос приходит на тред веб-сервера, а для его выполнения нужно обратиться к данным, которые обрабатываются на главном треде, значит нужно как-то синхронизироваться. Что, если вставить сюда mutex?..." И так все, не обращая внимания друг на друга. В опен спейсе, ага

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

Здравствуйте, so5team, Вы писали:

S>Просто можно представить себе что будет творится на рабочих местах, если программисты будут "думать вслух" в прямом смысле слова: один такой "здесь почему-то потребление CPU упирается в потолок, хотя быть такого не должно, значит ща запустим профайлер, посмотрим... Ага, вот здесь мы жрем слишком много, но почему?..." А за соседним столом другой: "этот запрос приходит на тред веб-сервера, а для его выполнения нужно обратиться к данным, которые обрабатываются на главном треде, значит нужно как-то синхронизироваться. Что, если вставить сюда mutex?..." И так все, не обращая внимания друг на друга.

Вот представь себе все это, только они при этом еще собираются кучками по 2-30 человек и делают это попеременно.

Здравствуйте, Skorodum, Вы писали:

S> (я работал над компилятором, если что).

Где?

Здравствуйте, Codealot, Вы писали:

C>Где?
Компилятор для вот этого языка.

А совсем недавно пришлось работать с одинм не очень публичным интеловским API — далеко не фонтан.

Здравствуйте, Skorodum, Вы писали:

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

За Therac-25 тоже заплатили очень приличные деньги. А уж сколько бабла было просрано на Rational Rose...

S>Да, но он работает и им пользуются сотни миллионов и он приносит миллионы в день. Интеллу миллионы приносят чипы, а не компилятор.

1. И какое это имеет отношение к "культуре разработки", о которой ты говорил?
2. Интелу чипы приносят многие десятки миллиардов. А компилятор — миллионы.

Здравствуйте, landerhigh, Вы писали:

L>Здравствуйте, mogadanez, Вы писали:

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

L>

L>Человек, который так будет проверять повара или столяра, сильно рискует нанять повара на стоярные работы.

Требуется пояснительная бригада.

Здравствуйте, Sharov, Вы писали:

S>Да, наиболее хайповые американские ит компании -- fb, amzn, apple, netflix, goog.
S>Можно и мс добавить. Но в этих компания дрючат гномиков и системный дизайн
S>на собеседования. Как в мс -- не знаю.

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

Здравствуйте, netch80, Вы писали:

S>>Да, наиболее хайповые американские ит компании -- fb, amzn, apple, netflix, goog.
S>>Можно и мс добавить. Но в этих компания дрючат гномиков и системный дизайн
S>>на собеседования. Как в мс -- не знаю.
N>В гугле точно уже не дрючат. В остальных — не знаю, по обстановке.

А как там сейчас, что спрашивают?

Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, Worminator X, Вы писали:

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

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

Глупости оба говорите. Во-первых, человек — это априори самый ненадёжный элемент бизнеса, а во-вторых, лучше в команде путь будет "лишний ум", чем "лишний тугодум". Да и "лишним" он не будет никогда — при обсуждении архитектуры и конкретных воплощений, как раз чем больше светлых голов, тем лучше. Для развития продукта — опять же нужны специалисты, а не "исполнительные кодеры" — они "нутром чуют", что и куда надо развивать.
Кроме того, не забываем простейший человеческий фактор: "главный сенсей" заболел/женился/помер/иммигрировал — кем заменять? Сворой джунов? Даже просто толковый спец есть в команде — уже хорошо.

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

— "А мы вообще никогда не прекращаем процесс найма! Специалисты нужны всегда". Вот так бесконечно водя неводом, они вылавливают жемчужины, которые на миг оказались на маркете. Профукаешь — будешь ещё год водить неводом впустую.

B>У п-стов нет медалей, "чёрных поясов", малиновых штанов и грамот "лучший погромизд года".
Нужно создать гильдию программистов, в которой заказчики будут выдавать программистам квесты, а за их выполнение — кроме денег, гильдия будет присуждать програмистам ранги от F(низший) до A(высший) или S(достижения мировых масштабов). У какой-нибудь игровой конторы уже и ПО готовое есть.

Здравствуйте, Baiker, Вы писали:

B>лучше в команде путь будет "лишний ум"

Ум стоит денег. У большинства компаний их на это недостаточно.

Здравствуйте, mogadanez, Вы писали:

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

Но если быстрый, как пчела, спотыкается о сложную задачу, когжа нужно именно посидеть- подумать. А "медленный" — посидел-подумал, и выдал результат? Как вместе с водой не выплеснуть и ребёнка?

Здравствуйте, gress, Вы писали:

S>>Для этого ввели в крупных компаниях так называемое system design interview.
G>Дизайн интервью обычно дают архитекторам. А разработчикам уже обычно такое не дают, ибо не их это задача.

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

G>Вот сейчас ищем разработчика-питониста. Опытные разрабы на простой вопрос — какие знаете способы интеграции между АС — начинают мычать что-то несуразное. Кафку многие в глаза не видели. Ну, ладно, Кафку — вообще асинхронного обмена не пробовали живьем. Ну, а смысл при каких угодно регалиях и прошлом опыте брать людей без опыта в конкретно нашей текущей технологии?

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

Здравствуйте, gress, Вы писали:

G>Здравствуйте, Sharov, Вы писали:

S>>Не знаю, но насколько понял, в гуглах и фб дают вообще всем. Может кроме самых начинающих, а когда
S>>уже какой-никакой есть опыт, то скорее всего спросят. А что в этом такого, кроме архитекторов никто
S>>не должен разбираться, как устроены и работают масштабные сервисы? Хотя бы на понятийном
S>>уровне понимать надо практически всем.
G>У нас сейчас на собес разработчика дается 1 час на все — общее интервью с вопросами об опыте, вопросами о проекте и компании, техническая часть. HR тоже свои вопросы задает.
G>На дизайн-интервью для собеседования разработчика обычно минут 10 есть, не больше. Полноценное дизайн-интервью — это час.

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

S>>Ну все теперь, конченные люди, раз Кафку не видели. Вот это типичное отличие нашего подхода к западному --
S>>там смотрят на более общие, абстрактные вещи, в том числе сис. дизайн, как человек думает, подход к решение.
S>>А у нас дрючат конкретное api -- не знаешь, досвидание. Поэтому там -- ит инновационное, а здесь -- догоняющее.
G>Кафка — не единственный способ асинхронного обмена. Хоть с какой-нибудь шиной поработали бы или с RabbitMQ. Опять-таки, как ты себе представляешь человека, который может успешно пройти современное дизайн-интервью, не имея представления об асинхронном обмене? Что он может сказать о событийно-ориентированной архитектуре?

Люди как-то проходят, имея исключительно теор. представление о том, как это все работает. Т.е. есть ментальная
модель. Все необходимые название (Kafka, rmq) скажут, но опыта не было. Практику получат уже решая непосредственно задачи.

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

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

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

Здравствуйте, Sharov, Вы писали:

S>Такое вопрос, а если у человека не было промышленного опыта с Кафкой, но он читал книжку с примерами
S>или взял соотв. курс, это зачтется? Или нужен реальный промышленный опыт?

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

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

Здравствуйте, gress, Вы писали:

G>У нас сейчас на собес разработчика дается 1 час на все — общее интервью с вопросами об опыте, вопросами о проекте и компании, техническая часть. HR тоже свои вопросы задает.

А если не секрет, "у нас" -- это где?

Один час на все про все выглядит как откровенно мало.

Здравствуйте, Osaka, Вы писали:

B>>У п-стов нет медалей, "чёрных поясов", малиновых штанов и грамот "лучший погромизд года".
O>Нужно создать гильдию программистов, в которой заказчики будут выдавать программистам квесты, а за их выполнение — кроме денег, гильдия будет присуждать програмистам ранги от F(низший) до A(высший) или S(достижения мировых масштабов). У какой-нибудь игровой конторы уже и ПО готовое есть.

Масса работы идет под NDA, особенно если дело связано с know-how, заказчики не будут
светить свои квесты. Все, что они могут светить, уже по-ходу есть на upwork, mechanical
turk и т.п.

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

Хотя, профсоюзы это вроде не модно. Тогда другая форма балансировки — саморегулируемая
организация (СРО). Это не относится к мелким компаниям, которые своим поведением на
рынке погоды не делают. Зато средние и весь крупняк обязаны быть в СРО, и подчиняться
более строгим этическим нормам, например, при том же хайринге.
Т.е. прежде чем наводнить рынок заскриптованными рекрутерами, любая известная компания
из 6-и букв будет обязана доказать что общение с ними не токсик. И не заставит большинство
народа забросить свое профессиональное развитие и переключиться на штудирование
литературы по сортировке гномиков, или что там еще придумают.

Владимир Сорокин.
Пьеса "Щи".
Сцена общения "по понятиям" двух криминальных авторитетов по кличке Уха и Борщ в постапокалиптическом мире, где победили "зелёные", животная пища запрещена, а "поваров в законе" сажают на пятнашечку:

	Много мата
	Уха (подходит вплотную к Борщу, затягивается и выпускает дым ему в лицо): Котлета по-киевски, блядь, с картофелем фри, блядь, и тарталетками, блядь, из гусиного паштета, блядь! Борщ (затягивается и выпускает дым в лицо Царской Ухе): Седло барашка, на хуй, с рисом, на хуй, с черносливом, на хуй, фаршированным, на хуй, жареным миндалем! Уха: Стерлядь паровая, блядь, под белым соусом, блядь, с каперсами, блядь, маслинами, блядь, креветками, блядь, раковыми шейками, блядь, и белыми грибами, блядь! Борщ: Молодая индейка, на хуй, вымоченная три часа в белом вине, на хуй, фаршированная телячьей печенью, на хуй, шампиньонами, на хуй, говяжьими мозгами, на хуй, рубленым яйцом, на хуй, обмазанная сливочным маслом, на хуй, посыпанная толчеными сухарями, на хуй, запеченная в духовке, на хуй, в течение двух часов, на хуй, разрубленная на шестнадцать кусков, на хуй, политая клюквенным соком, на хуй, поданная на серебряном блюде, на хуй, с тушеной айвой, на хуй, сладким картофелем, на хуй, маринованными черешнями, на хуй, свежими персиками и абрикосовым вареньем, на хуй!

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

Здравствуйте, so5team, Вы писали:

S>А если не секрет, "у нас" -- это где?

S>Один час на все про все выглядит как откровенно мало.

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

Здравствуйте, gress, Вы писали:

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

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

И очень интересно, а чем вызвана такая экономия времени? Большой поток соискателей?

Здравствуйте, mogadanez, Вы писали:

M>и что софт скилы/отсутствие токсичности не менее важно чем основные скилы

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

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Системные аналитики не в состоянии в разумные сроки расписать требования к задаче

По русски это называется некомпетентность.

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

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

Здравствуйте, netch80, Вы писали:

M>>>Тоже самое как повара могут проверить на умение шинковки например, или столяра как он гвоздь забъет и не будет ли вбивать шурупы.
L>>

L>>Человек, который так будет проверять повара или столяра, сильно рискует нанять повара на стоярные работы.
N>Требуется пояснительная бригада.

Ничего тут не требуется.
Человек вообще не представляет себе, в чем состоит работа повара или столяра.

Здравствуйте, Codealot, Вы писали:

SVZ>>Системные аналитики не в состоянии в разумные сроки расписать требования к задаче

C>По русски это называется некомпетентность.

Неа, не в этом дело. Вот получается на выходе талмуд в полторы тыщщи страниц. И как такой объём переваривать?

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

Если никогда не занимался подобными задачами осилишь?

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

C>Взаимоисключащие параграфы. Прочитать и запомнить где искать не могут, а просто так все помнить — могут.

Никакого противоречия. Есть память, а есть понимание. Понимаешь?

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Неа, не в этом дело. Вот получается на выходе талмуд в полторы тыщщи страниц. И как такой объём переваривать?

А как переваривать тот же объем информации, да еще и без доков? Бред какой-то.

SVZ>В качестве примера возьми последний стандарт с++ и напиши по нему с нуля оптимизирующий компилятор. Архитектуру процессора предлагается изучить дополнительно

SVZ>Если никогда не занимался подобными задачами осилишь?

Вообще никто в одиночку не осилит.

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

SVZ>Никакого противоречия. Есть память, а есть понимание. Понимаешь?

Ваши программисты не умеют понимать доки?

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Я несколько раз сталкивался с подобными требованиями. Связано было с заковыристой предметной областью.
SVZ>Системные аналитики не в состоянии в разумные сроки расписать требования к задаче (да и разработчик не в состоянии всё это потом прочесть и удержать в голове), поэтому часть требований остаётся недокументированными в расчете на то, что разработчик понимает, о чём идёт речь.

Э... А как это оправдывает то, что на собеседование тратиться всего час (включая и вопросы от HR)?

Здравствуйте, Sharov, Вы писали:

S>А то код, видите ли, просят написать

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

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

Условно: опытный программист наверняка развернет вам на собеседовании двусвязный список. Сложного в этом ничего нет. Но в условиях стресса самого собеседования и непривычных условий (то же online IDE далеко не для всех привычный инструмент) выглядеть это будет коряво. И тут возникает вопрос: а насколько произведенное впечатление будет соответствовать потенциальным возможностям соискателя?

Может быть, если бы на собеседовании вместо просьбы написать разворот списка вы бы попросили соискателя рассказать о том, что он думает о применимости списков (отдельно двусвязных, отдельно односвязных) в современных условиях, то результат был бы точнее? Например, поспрашивайте, видит ли соискатель место для таких структур данных? Не лучше ли использовать vector? Или deque? Если list таки лучше vector, то в каких условиях? Применял ли соискатель списки? Каким образом он принимал решения об их применении?

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

Здравствуйте, so5team, Вы писали:

S>Э... А как это оправдывает то, что на собеседование тратиться всего час (включая и вопросы от HR)?

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

Здравствуйте, Stanislav V. Zudin, Вы писали:

S>>Э... А как это оправдывает то, что на собеседование тратиться всего час (включая и вопросы от HR)?

SVZ>Когда я набирал, то часа было достаточно, чтобы оценить, что человек знает.

Знания-то ладно, особенно если область специфическая.
Но ведь есть и еще одна, не менее важная сторона: захочется ли с таким человеком работать.

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

SVZ>Ну и не исключено, что "час" это словесный оборот, на деле может оказаться и два-три часа

Ну пока что есть точная цитата: "У нас сейчас на собес разработчика дается 1 час на все — общее интервью с вопросами об опыте, вопросами о проекте и компании, техническая часть. HR тоже свои вопросы задает." Здесь неоткуда взяться двум-трем часам

Здравствуйте, so5team, Вы писали:

S>Знания-то ладно, особенно если область специфическая.

Это так.

S>Но ведь есть и еще одна, не менее важная сторона: захочется ли с таким человеком работать.

S>За час запросто можно понять, что с человеком работать не хочется. С этим соглашусь (хотя, опять же, а как защититься от того, что первое впечатление было неправильным?)

ИМХО первого впечатления вполне достаточно. Не зацепило и ладно, каждый найдёт себе работу/работника по вкусу.

SVZ>>Ну и не исключено, что "час" это словесный оборот, на деле может оказаться и два-три часа

S>Ну пока что есть точная цитата: "У нас сейчас на собес разработчика дается 1 час на все — общее интервью с вопросами об опыте, вопросами о проекте и компании, техническая часть. HR тоже свои вопросы задает." Здесь неоткуда взяться двум-трем часам

Видимо полагаются на чутье. Если результат их устраивает, значит всё правильно делают

Здравствуйте, Codealot, Вы писали:

SVZ>>Неа, не в этом дело. Вот получается на выходе талмуд в полторы тыщщи страниц. И как такой объём переваривать?

C>А как переваривать тот же объем информации, да еще и без доков? Бред какой-то.

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

SVZ>>В качестве примера возьми последний стандарт с++ и напиши по нему с нуля оптимизирующий компилятор. Архитектуру процессора предлагается изучить дополнительно

SVZ>>Если никогда не занимался подобными задачами осилишь?

C>Вообще никто в одиночку не осилит.

Нет таких людей на этой планете. Просто из-за объема задачи.
C>Да и не в одиночку тоже никто до сих пор не осилил. Все компиляторы поддерживают стандарт только частично и содержат обширный набор тараканов.
C>Так что либо ты не понимаешь эту задачу, либо намеренно решил заняться подтасовкой. Постарайся больше так не делать.

Ну давай возьмём пример попроще. Прочитать/записать какой-нибудь dxf, odb++, docx. Это по силам?
Документация на ODB++ всего 500 с копейками страниц. Написать парсер с преобразованием сырых данных в нечто высокоуровневое, пригодное для работы редактора, тянет на 10 чел/мес — работа на одного, максимум на троих.
Правда, если ты не знаком с проектированием и производством печатных плат, то даже не найдёшь ошибку — ни в коде, ни в данных.

Но это всё лирика.

Получается, есть два подхода:
1. Берём программиста, знакомого с предметной областью, и он всё делает. Возможно, не в одиночку.
2. Берём команду программистов общего назначения и в придачу к ним "няньку", которая будет писать ТЗ и разжевывать, что именно им надо делать.

Довелось поработать и по первому варианту, и по второму. Ты, насколько я понимаю, привык ко второму варианту.

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

Здравствуйте, so5team, Вы писали:

S>Некоторые видят проблему в том, что написание кода на интервью (а это наверняка какая-то несложная алгоритмическая задачка) сильно не похоже на написание кода в реальном проекте (даже если в реальном проекте нужно делать что-то алгоритмически сложное). Соответственно, проверяется не тот навык.
S>Да, корреляция, в принципе, будет сильная вот в каком плане: хороший программист и в условиях интервью сможет более-менее что-то нормальное выдать. Но этот процесс может выглядеть... непрезентабельно, скажем так. И выглядеть этот условный хороший программист на собеседовании будет хуже, чем тот, кто вымуштрован на решение подобных простеньких задачек.
S>Условно: опытный программист наверняка развернет вам на собеседовании двусвязный список. Сложного в этом ничего нет. Но в условиях стресса самого собеседования и непривычных условий (то же online IDE далеко не для всех привычный инструмент) выглядеть это будет коряво. И тут возникает вопрос: а насколько произведенное впечатление будет соответствовать потенциальным возможностям соискателя?

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

S>Может быть, если бы на собеседовании вместо просьбы написать разворот списка вы бы попросили соискателя рассказать о том, что он думает о применимости списков (отдельно двусвязных, отдельно односвязных) в современных условиях, то результат был бы точнее? Например, поспрашивайте, видит ли соискатель место для таких структур данных? Не лучше ли использовать vector? Или deque? Если list таки лучше vector, то в каких условиях? Применял ли соискатель списки? Каким образом он принимал решения об их применении?

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

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

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

Здравствуйте, Stanislav V. Zudin, Вы писали:

S>>За час запросто можно понять, что с человеком работать не хочется. С этим соглашусь (хотя, опять же, а как защититься от того, что первое впечатление было неправильным?)

SVZ>ИМХО первого впечатления вполне достаточно. Не зацепило и ладно, каждый найдёт себе работу/работника по вкусу.

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

SVZ>Видимо полагаются на чутье. Если результат их устраивает, значит всё правильно делают

Вот и интересно узнать в каких условиях это работает. И работает ли.

Здравствуйте, so5team, Вы писали:

S>>>За час запросто можно понять, что с человеком работать не хочется. С этим соглашусь (хотя, опять же, а как защититься от того, что первое впечатление было неправильным?)

SVZ>>ИМХО первого впечатления вполне достаточно. Не зацепило и ладно, каждый найдёт себе работу/работника по вкусу.

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

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

Когда-то давно, в другой компании, я проводил скрининговые собеседования. За это приплачивали

Потом отказался от этой затеи. Перешли к просто беседе за жизнь.

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

Это выясняется невзначай по ходу разговора.
Скажем так, ошибки из-за собственно с++ у нас возникали на порядки реже (за последние 10 лет раза три и то из-за невнимательности), чем проколы в алгоритмах.

SVZ>>Видимо полагаются на чутье. Если результат их устраивает, значит всё правильно делают

S>Вот и интересно узнать в каких условиях это работает. И работает ли.

+1.

Здравствуйте, so5team, Вы писали:

S>>Мы же выше это уже обсудили -- все это так, но крупные компании идут на это, т.к. для них лучше не нанять хорошего
S>>программиста, чем нанять плохого.
S>Так ведь решение около-олипиадных задачек не показатель "хорошести" для программиста. Вот в чем дело.

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

S>>Для менее крупных компаний -- тестовое на дом, с обсуждением,
S>>кажется ок.
S>Это сильно зависит от рынка, имхо. В крупном городе с большим количеством вакансий тестовое на дом -- это отпугивание большого количества соискателей. В небольшом городе, где всего 3-4 вменяемых работодателей, это может и сработать. Но опять таки, зависит от состояния рынка. Тем более, что он сейчас еще более глобальный, чем года три назад.

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

S>>У такого способа есть проблема, что про структуры
S>>данных и алгоритмы можно реально выучить, не скомпилировав при это ни одной программы.
S>Зазубрить можно описания структур данных и оценки сложности тех или иных операций. Но зазубрить цепочку рассуждений... Не верится. Вы вот сами попробуйте ответить на общие вопросы вроде "Сохраняет ли сейчас актуальность такая структура данных, как связанный список? Почему вы так думаете? Согласны ли с тем, что vector всегда предпочтительнее? Если да, то почему? Если нет, то можете привести пример, где список предпочтительнее?"

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

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

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

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

Здравствуйте, Sharov, Вы писали:

S>Мы же выше это уже обсудили -- все это так, но крупные компании идут на это, т.к. для них лучше не нанять хорошего
S>программиста, чем нанять плохого.

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

Здравствуйте, so5team, Вы писали:

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

Типичные задачи зубрят только в путь. Особо упертые — месяцами.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Если ты уже в предметной области, то половина информации, считай, уже в голове.

Так выглядит разумнее

А то формулировка была странная.

SVZ>Ну давай возьмём пример попроще. Прочитать/записать какой-нибудь dxf, odb++, docx. Это по силам?
SVZ>Документация на ODB++ всего 500 с копейками страниц. Написать парсер с преобразованием сырых данных в нечто высокоуровневое, пригодное для работы редактора, тянет на 10 чел/мес — работа на одного, максимум на троих.
SVZ>Правда, если ты не знаком с проектированием и производством печатных плат, то даже не найдёшь ошибку — ни в коде, ни в данных.

Так прочитать/записать, или провалидировать? Это разные вещи.

Здравствуйте, so5team, Вы писали:

S>Может быть, если бы на собеседовании вместо просьбы написать разворот списка вы бы попросили соискателя рассказать о том, что он думает о применимости списков (отдельно двусвязных, отдельно односвязных) в современных условиях, то результат был бы точнее?

Правильный ответ — "связные списки не нужны практически никогда"?

Здравствуйте, so5team, Вы писали:

S>Правда, в случае C/C++/Rust для списков (особенно интрузивных) применимость может быть найдена, и как раз об этом было бы интересно побеседовать.

Вместо rope? А зачем?

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

https://rsdn.org/forum/job/7846366.1
https://rsdn.org/forum/job/7846904.1

Здравствуйте, Codealot, Вы писали:

S>>Правда, в случае C/C++/Rust для списков (особенно интрузивных) применимость может быть найдена, и как раз об этом было бы интересно побеседовать.

C>Вместо rope? А зачем?

Про rope я наслышан только в контексте строк (т.е. последовательностей байт или символов). Тогда как связный список иногда может рассматриваться как замена контейнерам вроде vector или deque для любых T. Применительно к языкам вроде C++ у связных списков есть такие достоинства как:

— ссылки на содержимое не инвалидируются при модификации контейнера;
— в случае интрузивных списков и использования преаллоцированных элементов списка можно делать операции вставки в контейнер действительно noexcept.

Так же списки позволяют собирать в контейнер объекты, которые в принципе не Copyable и не Moveable. Тут, правда, все равно остается вопрос о том, на не будет ли vector<unique_ptr<T>> эффективнее, чем list<T>. Но это уже от условий зависит.

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

Здравствуйте, so5team, Вы писали:

S>Про rope я наслышан только в контексте строк (т.е. последовательностей байт или символов).

Ничто не мешает использовать его с любым типом элементов.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>На этот вопрос у меня есть заготовленный ответ

SVZ>Там даже есть про богомерзкий разворот односвязного списка

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

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>и восстановление недостающих/кривых данных.

Это точно обычно не входит в парсинг.

SVZ>А просто парсер накарябать — это задача уровня курсовика для студента.

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

Здравствуйте, Codealot, Вы писали:

SVZ>>и восстановление недостающих/кривых данных.

C>Это точно обычно не входит в парсинг.

У нас это называлось "Импорт данных".

SVZ>>А просто парсер накарябать — это задача уровня курсовика для студента.

C>Как показывает практика, современные эксперты по сортировке гномов не в состоянии сделать даже окно, не налажав при этом. Так что это, кхм-кхм, крайне оптимистично.

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

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

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Чем она лучше односвязного списка в приведённом примере?

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

SVZ>Даже не так, как rope вообще применима в приведённом примере?

Список с эффективной вставкой и/или удалением. В чем разница?

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

Упорядоченный в смысле отсортированный, или просто с известной позицией элементов?

Здравствуйте, Codealot, Вы писали:

SVZ>>Чем она лучше односвязного списка в приведённом примере?

C>Как минимум, расход памяти намного меньше. Возможно, также и быстрее.

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

SVZ>>Даже не так, как rope вообще применима в приведённом примере?
C>Список с эффективной вставкой и/или удалением. В чем разница?

Логарифм в верёвке против константы в списке? Я всё-таки за список

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

C>Упорядоченный в смысле отсортированный, или просто с известной позицией элементов?

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

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Касательно расхода памяти дерево не будет эффективнее списка.

Если у тебя несколько элементов в каждом сегменте и маленькая глубина в дереве (а здесь большая глубина не нужна), то будет.

SVZ>Для больших элементов, когда накладные расходы пренебрежимо малы, по-сравнению с полезными данными, это роли не играет.

Это может быть, если они очень большие.

SVZ>Логарифм в верёвке против константы в списке? Я всё-таки за список

В худшем случае O(C), где C длина сегмента

Здравствуйте, so5team, Вы писали:

S>Но зачем?

Меньше расход памяти, и может быть быстрее.

S>И непонятно в чем преимущество rope для T перед каким-нибудь условным списком чанков одинаковой емкости.

А это не частный случай веревки?

S>Как бы то ни было в контексте C++ rope вряд ли может дать те гарантии, какие дает список (они перечислялись выше).

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

Здравствуйте, so5team, Вы писали:

S>На первый взгляд сомнительно. А есть какие-то примеры применения rope-структуры не для строк, а для чего-то другого?

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

S>Тут более актуален вопрос: а не является ли rope с листами фиксированной емкости (да еще и в которых есть пустоты) частным случаем какого-нибудь B-дерева?

B-дерево отсортировано.

Здравствуйте, so5team, Вы писали:

S>Интересны примеры использования rope для чего-то отличного от строк. Ибо если это не строки, то смысл rope от меня ускользает.
S>Так что если вам известны примеры, то поделитесь ссылками, плз. Реально любопытно.

Ладно, видимо это все же не rope, а что-то похожее. Самое близкое, что я нашел, это https://en.wikipedia.org/wiki/Unrolled_linked_list
Можно сделать эффективнее, но как это называется я не знаю

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

Здравствуйте, Codealot, Вы писали:

S>>Интересны примеры использования rope для чего-то отличного от строк. Ибо если это не строки, то смысл rope от меня ускользает.
S>>Так что если вам известны примеры, то поделитесь ссылками, плз. Реально любопытно.

C>Ладно, видимо это все же не rope, а что-то похожее. Самое близкое, что я нашел, это https://en.wikipedia.org/wiki/Unrolled_linked_list

Я привык называть эту штуку chunked list.

C>Можно сделать эффективнее, но как это называется я не знаю

Возвращаясь к вопросу собеседований: имхо, вот такие вот разговоры (спором это сложно назвать) на собеседовании могут дать гораздо лучшее представление о возможностях программиста, чем online-кодинг около-олимпийских задач. Но именно разговоры в смысле рассуждений о применимости тех или иных структур данных (или алгоритмов) в разных условиях, с перечислением достоинств и недостатков, выяснением граничных случаев. Сильно сомневаюсь, что вероятность найти человека, который понимает, где лучше list, где лучше deque, где лучше vector, но при этом не умеет программировать, настолько велика, что с ней нужно считаться на собеседовании. Гораздо вероятнее встретить того, кто зазубрил решения для первых N задачек с leetcode или из какой-нибудь книги типа "Grokking the Coding Interview Patterns".

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

+100500

	От:	Codealot
	Дата:	22.05.23 17:02
	Оценка:	+1 -4

	От:	alpha21264
	Дата:	22.05.23 14:01
	Оценка:	+5 -2

	От:	ути-пути
	Дата:	22.05.23 16:49
	Оценка:	+8

	От:	ути-пути
	Дата:	22.05.23 16:49
	Оценка:	+2

	От:	m2user
	Дата:	22.05.23 19:20
	Оценка:

От:	IT	linq2db.com
Дата:	23.05.23 00:30
Оценка:	+5

	От:	Нomunculus
	Дата:	22.05.23 14:47
	Оценка:	+2 -1

	От:	LuciferSaratov
	Дата:	22.05.23 19:56
	Оценка:	+3

От:	netch80	http://netch80.dreamwidth.org/
Дата:	26.05.23 05:23
Оценка:	+3

	От:	mogadanez
	Дата:	24.05.23 10:32
	Оценка:	1 (1) -1

	От:	Vladsav
	Дата:	04.06.23 19:29
	Оценка:	1 (1) +1

От:	so5team	https://stiffstream.com
Дата:	06.06.23 15:58
Оценка:	1 (1) +1

От:	velkin	http://blogs.rsdn.org/effective/
Дата:	22.05.23 17:48
Оценка:	-2

От:	Nuzhny	https://github.com/Nuzhny007
Дата:	24.05.23 14:43
Оценка:	+2

От:	Эйнсток Файр	Странный реагент
Дата:	25.05.23 15:04
Оценка:	-1

От:	Worminator X	#StandWithPalestine 🖤🤍💚
Дата:	28.05.23 20:36
Оценка:	+1 -1

	От:	Sharov
	Дата:	29.05.23 18:15
	Оценка:	+1

	От:	Skorodum
	Дата:	31.05.23 08:53
	Оценка:	+1 -1

	От:	Skorodum
	Дата:	02.06.23 08:00
	Оценка:	+2

От:	Артём	жж
Дата:	03.06.23 23:27
Оценка:	+2

	От:	Stanislav V. Zudin
	Дата:	05.06.23 16:04
	Оценка:	-1

	От:	Явь-истъ
	Дата:	04.06.23 11:42
	Оценка:

От:	Pauel	http://blogs.rsdn.org/ikemefula
Дата:	23.05.23 07:14
Оценка:

От:	Kernan	https://rsdn.ru/forum/flame.politics/
Дата:	24.05.23 22:30
Оценка:

	От:	Министр Промышленности
	Дата:	30.05.23 11:46
	Оценка: