Комментарии 417
Это вы еще на собеседовании в Одноклассники(!) не были…
В Яндексе задачки обычно проще.
Написать калькулятор достаточно типовая задачка для собеседований.
Там делов то. Вспомнить про стек и вперед. () — рекурсией тоже просто.

И все ()*/+- покрываются на раз. Строк 30 кода, если не особо над переполнениями заморачиваться. За типовой час пишется на доске и разбирается с запасом.
() — рекурсией тоже просто.

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

Зачем вы искали рекурсию в алгоритме сортировочной станции, если алгоритм рекурсивного спуска — это совсем другой алгоритм, который алгоритмом сортировочной станции не является?

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

У меня вариант попроще описан.
Который проще придумать, проще написать и он не сильно хуже. Собеседование же, все на лету.


Уложу в 30. Простейший вариант естесвенно. Целые цисла, целочисленная математика, числа по одной цифре. Чтобы не писать не показательные вещи вроде парсинга чисел из строки.

По моему, для этого нужна обратная польская запись. И там вроде бы стэк и все несложно.
Алгоритм
Пока есть ещё символы для чтения:
Читаем очередной символ.
Если символ является числом или постфиксной функцией (например, ! — факториал), добавляем его к выходной строке.
Если символ является префиксной функцией (например, sin — синус), помещаем его в стек.
Если символ является открывающей скобкой, помещаем его в стек.
Если символ является закрывающей скобкой:
До тех пор, пока верхним элементом стека не станет открывающая скобка, выталкиваем элементы из стека в выходную строку. При этом открывающая скобка удаляется из стека, но в выходную строку не добавляется. Если стек закончился раньше, чем мы встретили открывающую скобку, это означает, что в выражении либо неверно поставлен разделитель, либо не согласованы скобки.
Если существуют разные виды скобок, появление непарной скобки также свидетельствует об ошибке. Если какие-то скобки одновременно являются функциями (например, [x] — целая часть), добавляем к выходной строке символ этой функции.
Если символ является бинарной операцией о1, тогда:
1) пока на вершине стека префиксная функция…
… ИЛИ операция на вершине стека приоритетнее o1
… ИЛИ операция на вершине стека левоассоциативная с приоритетом как у o1
… выталкиваем верхний элемент стека в выходную строку;
2) помещаем операцию o1 в стек.
Когда входная строка закончилась, выталкиваем все символы из стека в выходную строку. В стеке должны были остаться только символы операций; если это не так, значит в выражении не согласованы скобки.


ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%80%D0%B0%D1%82%D0%BD%D0%B0%D1%8F_%D0%BF%D0%BE%D0%BB%D1%8C%D1%81%D0%BA%D0%B0%D1%8F_%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D1%8C

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

Не нужна тут ОПЗ. Вместо формирования выходной строки можно или сразу вычислять выражение, или же строить AST.


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

Вы скопировали решение другой задачи. Да еще и на русском языке, вместо любого языка програмирования. Вместо того чтобы придумать решение для обычного калькулятора.
Что же в этом хорошего?
На олимпиаде по Ораклу вроде писал парсер на SQL.
Вот тут было весело.
В Одноклассниках калькулятор мне не задавали.
Задачки были несколько посложнее. Ну и вторая из них выглядит как выносящая мозг любому Java-разработчику в силу своей специфики.
Одна из причин почему не вылазим с фриланса. Внезапные приступы тормозной тупости с реактивной гениальностью. Работает по принципу как в том мультике "Лучше день потерять потом за пять минут долететь"
Один раз, в глубокой молодости, интервью случилось аккурат в приступе «реактивной гениальности» и к несчастью прошло успешно. Первая неделя была крайне интересной — каждый день 8 часов тупого пяления в монитор и 3 строчками кода, потом приступ кодинга вечером в домашнее время и притащенное утром решение задачи над которым контора уже 3 дня билась. Через неделю увольнение, после беседы с директором, который это объяснение выслушал с недоверчивым прищуром и явным подозрением, что у нас дома спрятана какая-то команда индусов, а собес был просто куплен по знакомству.
Теперь принцип простой. Только проектный фриланс. К любой задаче даже 1 день сроком прибавляется неделя на выполнение. Никакие задачи не показываются в состоянии "тут будет дом, а то что сейчас забор после 50% срока, это норм" Со студиями спускающими нам проекты как «неграм» очень даже работает (правда портфолио не пополняет), с конечными клиентами это уже сложнее (обычно хотят видеть плавный постоянный прогресс, а не авралы с простоями), а вот в команду с таким подходом без шансов — незакоммитил пару килобайт за сутки — весь следующий день будешь оправдываться перед тимлидом вместо работы — это сильно расстраивает на самом деле.
Где такие заказы:
К любой задаче даже 1 день сроком прибавляется неделя на выполнение.
?=) Никогда толком фрилансом не занимался, но как не попадется какая-нибудь «подработка», то вечно с какими-то горящими-сумасшедшими сроками. Не люблю торопиться, поэтому никогда не беру, поэтому нет дополнительных денег (а хотелось бы=) ).
незакоммитил пару килобайт за сутки — весь следующий день будешь оправдываться перед тимлидом вместо работы — это сильно расстраивает на самом деле.
— очень не очень, согласен!
?=) Никогда толком фрилансом не занимался, но как не попадется какая-нибудь «подработка», то вечно с какими-то горящими-сумасшедшими сроками. Не люблю торопиться, поэтому никогда не беру, поэтому нет дополнительных денег (а хотелось бы=) ).
Зачастую сводится к цене.
Высокий ценник — будут лишь авральные заказы по типу «надо было вчера», т.к. иначе за что платить при прочих равных? Будет низкий ценник — будет из чего выбирать, в т.ч. и заказы вида «мне не горит, главное что бы цена приятная» будут.
Тут просто вопрос насколько Вы готовы снижать цену ради приятности заказа. Допустим приходит к Вам заказчик и кидает на стол штукарь баксов «что бы завтра все было готово», а Вы так задумчиво три сотни оттуда тянете, остальное ему обратно двигаете и говорите «а что насчет следующей недели»? И зачастую спешка внезапно куда-то пропадает.
.
Вторая частая ситуация — многим нужна не столько срочность, сколько гарантированность сроков. А срочность они просят просто потому, что хотят иметь время найти кого-то еще, если тут продинамят. В таких случаях можно обсудить увеличение сроков в обмен на повышенные финансовые гарантии со своей стороны. Типа — а давайте я сделаю это за неделю, а не за день, но если пропущу сроки, то не Вы мне косарь отвалите, а я Вам в качестве неустойки. Достаточно типичный вариант со студиями, кстати, которые сами перед заказчиком отвечают.

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


Напоминает анекдот про давно прошедшие времена в судах России:


К судье приходит секретарь и говорит: «Ваша честь, у нас проблема. Ответчик дает 130 тыс., а истец дает 100 тыс. Что будем делать?» Судья говорит: «Верните 30 тыс. ответчику, и будем решать дело по закону».

И второе предложение хорошо смотрится. Блин. Почему такая практика нигде не прижилась?? Что для этого нужно?

Почему такая практика нигде не прижилась?? Что для этого нужно?
Не так много людей кому это подходит.

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

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

Странный директор — если проблемы решаются, какая разница каким образом это делается?
Paskin «самураю не важна цель, ему важен путь» как-то так. В крупных фирмах предсказуемость и планируемость на первом месте, т.к. иначе невозможно управлять большими процессами. Представьте себе что у Вас колесо авто то 1 оборот в секунду делает, то 10, но в среднем выдает те самые нужные 5 — надо оно Вам в автомобиле?:)
Странный директор — если проблемы решаются, какая разница каким образом это делается?
К нам как-то пришла на интервью девушка, прямо сказавшая что руками она тестировать умеет, а автоматические тесты только начала изучать — но у нее муж крутой спец в этом деле и будет ей советовать если мы ее возьмем.
То ли девушка поскромничала, то ли муж действительно оказался крутым спецом — но тестов она написала целую кучу и вполне по делу.

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


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


Владение лайвкодингом это признак готовности или неготовности. Всё тренируется. И да не спешите. Тяните время. Но это интересно на самом деле проверять самого себя.

Некоторые действительно не могут эффективно писать по TDD. Особенно если вообще тесты никогда не писали.

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

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

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

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


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

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

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

Какой-то у вас неправильный нормальный программист :) для задач уровня парсера выражений TDD очень даже удобен, там тесты нужны уровня expect(calculate("2+2*2"), equals(6));
Ну, это такое. Лично я считаю, что TDD — это overhyped фигня, которая не везде подходит, а часто написание тестов «после» намного удобнее и дает большее покрытие.
А тестирование некоторых вещей — долго и дорого, по сравнению со стоимостью/сроками решаемой бизнес задачи.
а есть ещё совсем свежее поколение разработчиков которое считает что логирование не нужно. про сложность алгоритмов уже ни один андроид-разраб ответит не способен. что же будет дальше.
это реальность. но я как специалист на фоне такого буду больше зарабатывать. так что можете не тестировать, забыть про логирование, наплевать на сложность алгоритмов, не интересоваться структурами данных.
Ну, я не говорил, что автоматизированные тесты не нужны. Я сказал, что я считаю, что TDD не нужно.

И, да, не беспокойтесь, безработица мне не грозит.

Парсер выражений должен выдать на выходе не 6, а AST: Add(Const(2), Mul(Const(2), Const(2))).


Два таких дерева сравнить — уже нетривиальная задача (придётся добавлять во все классы метод Equals исключительно для нужд тестирования). А как начинать писать код с тестов, а не с классов для представления AST — для меня и вовсе загадка...

Можно написать некомпилирующийся тест

…без подсказок IDE. А современные IDE ещё и будут активно мешать.

С подсказками.


Это слишком большой тест для TDD. Сначала, придется написать Const(2), для этого надо будет написать Const — для текущего кусочка подсказок не будет, но будет кодогенерация

Ну, если надо именно аст красивый выдавать, то никто не мешает начать тест с более простого, типа Const(2), потом Add(Const(2),Const(2)). Не знаю, как там в строгом понимании TDD, но я бы делал так. Как минимум, api класса должно какое-то быть для теста. Скажем, та же функция createAst(String input) => throw Error();. Потом тест на неё, сначала expect(createAst("2"), equals(Const(2));, упадёт по-любому, потом можно к минимальной реализации приступать.

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

В нормальных языках уже завезли data-классы.

В каноническом TDD вы API создаёте пытаясь заставить тест скомпилироваться или что там у вас. То есть используете в тесте какой-то не существующий AstNode интерфейс с методом, например, children, получаете ошибку компиляции и только потом создаёте этот интерфейс с этим методом.

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

И если не секрет, то в чем здесь проблема? В .net я обычно пишу либо интерфейс без реализации, на него тест, и далее реализация. Либо метод с NotImplementedException, на него тест, далее реализация.

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

Чушь и не правомерное обобщение=)
TDD удобно если умеешь, если есть на него время, если проект в долгую и если не заставляют. Да «если» тут много.
И если не секрет, то в чем здесь проблема?

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

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

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

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

Для этого достаточно интерфейса.


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

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

И если не секрет, то в чем здесь проблема? В .net я обычно пишу либо интерфейс без реализации, на него тест, и далее реализация. Либо метод с NotImplementedException, на него тест, далее реализация.

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

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

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

Не согласен. Допустим, вы транслируете выражение в LLVM байткод, а LLVM генератор выдает Вам машинный код. И вот оно уже работает быстро.

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

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

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

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

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

Я ведь уточнил, что "обычно" :) И да, часто для дискуссии нужно чуть больше, чем одно слово и минус.

Я ведь уточнил, что "обычно" :)

Без "обычно". Тут я вижу есть определенное непонимание — некоторые под ТДД подразумевают просто "пишу код и тесты параллельно, как мне будет удобно". Но нет, это не тдд, это просто человек как-то пишет тесты. ТДД же строго регламентирует как и когда пишутся тесты/продакшн код, из этого регламента тдд и состоит. И если вы базовые принципы тдд нарушаете, то это уже не тдд.
Ну в самом деле, если вы, когда это удобно и разумно, пишете сперва код, а потом тесты, то в каком месте это будет test driven development?

И если вы базовые принципы тдд нарушаете, то это уже не тдд.

Когда человек начинает использовать TDD, ему ведь не дают подписать контракт, запрещающий любые другие подходы? Можно вполне быть разумным человеком и применять то, что удобнее в конкретной ситуации. Также как если человек придерживается в основном ООП, а потом где-то тулит Util- класс или передаёт лямбду в качестве аргумента, (обычно) к нему не прибегают ООП-апологеты с палками.

TDD это про проектирование и валидацию системы при эксплуатации. А также про эксплорацию кода на каждом из этапов.
Тесты взаимодействуя с интерфейсами имитируют работу системы, поставляя ей набор данных от других интерфейсов. Реальной системы может ещё и не быть, а всё состоять из рендеров или заглушек. Задача разработчика заменить рендеры и заглушки на реальный код, сохраняя ее работоспособность. Которая и проверяется тестами. Насколько хорошо? Это зависит от граничных данных которые мы хотим или не хотим получать или передавать. Иногда ты физически можешь работать только со статическим рендером, но остальные части твоей системы об этом ничего не знают, так как общаются через интерфейс, который скрывает реализацию и если надо имитирует готовность и валидность.
Поэтому разумно начинать проектирование именно с описания интерфейсов. Которые обычно задаются схемами с последующей кодогенерацией.

И если не секрет, то в чем здесь проблема?

Проблема в том, что вам надо написать код, который вы совершенно точно целиком выкинете через 5 минут. И так несколько раз.


Еще проблема ТДД — программист не имеет права сразу в коде обрабатывать краевые случаи. Сперва вы должны написать алгоритм без обработки каких-либо краевых случаев, а потом добавлять краевые случаи по одному с соответствующими тестами. Засада тут в том, что в случае сложного алгоритма можно про эти краевые случаи просто забыть — они пока алгоритм пишешь очевидны, а потом уже нет. В итоге возникает парадоксальная ситуация, когда код написанный в лоб в один присест без всяких тестов оказывается более надежен, чем написанный по ТДД со 100% покрытием.

Проблема в том, что вам надо написать код, который вы совершенно точно целиком выкинете через 5 минут. И так несколько раз.

Эм, с чего бы? Вероятно я вас не понимаю, вы не могли бы привести пример, какие «недоалгоритмы» понадобятся, чтобы написать тесты на калькулятор?
Еще проблема ТДД — программист не имеет права сразу в коде обрабатывать краевые случаи. Сперва вы должны написать алгоритм без обработки каких-либо краевых случаев, а потом добавлять краевые случаи по одному с соответствующими тестами.

Эм? А эту догму вы откуда достали?
В итоге возникает парадоксальная ситуация, когда код написанный в лоб в один присест без всяких тестов оказывается более надежен, чем написанный по ТДД со 100% покрытием.

Довольно бездоказательное утверждение. К слову 100% покрытие — это такой же не здоровый фанатизм, как и полное отсутствие тестов.
Эм, с чего бы? Вероятно я вас не понимаю, вы не могли бы привести пример, какие «недоалгоритмы» понадобятся, чтобы написать тесты на калькулятор?

Ну, хотя бы, что на первый тест assertEqual(3, eval(«1+2»)); по TDD надо написать минимальный код, который починит тест, которым является return 3; Чтобы прийти к return a+b; надо написать минимум два теста. Соответственно, «return 3» тот самый выброшенный код.
Этот пример, конечно, упрощение, и в реальном мире все сразу напишут return a+b; что будет отступлением от канонов TDD. А если мы разрешаем пропускать шаги и писать больше кода, чем это требуют тесты, то легко пропустить юзкейсы, которые надо было бы зафиксировать в тестах (чтобы убедиться, что они все еще будут работать при последующих рефакторингах), потому что юзкейсы-то уже покрыты и тесты не сломаны.

Эм? А эту догму вы откуда достали?

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

К слову 100% покрытие — это такой же не здоровый фанатизм, как и полное отсутствие тестов.

Ну, по TDD у Вас оно всегда должно быть 100%. Вывод: TDD — нездоровый фанатизм.
1) надо писать тест вперед, 2) тест изначально должен быть сломан, 3) надо писать минимальный код, чтобы сделать тест работающим.

Там выше цитату приводили, что надо писать мало того, что минимальный, но еще и production(не знаю, как на русский перевести), коим return 3 врядли является. Вот если бы return 42, но он тест не пройдет.

Ну, по TDD у Вас оно всегда должно быть 100%. Вывод: TDD — нездоровый фанатизм.

Любую идею или подход можно довести до абсурда, мне кажется, что если я сначала напишу набор тестов на граничные случаи, которые взбредут в голову, потом код, который их последовательно закрывает, то это все равно можно назвать TDD.
Там выше цитату приводили, что надо писать мало того, что минимальный, но еще и production(не знаю, как на русский перевести), коим return 3 врядли является. Вот если бы return 42, но он тест не пройдет.


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

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

Лично я делаю так: пишем некий код. Потом задаемся вопросом: «делает ли этот код то, что я хочу?». Пишем тест. Проверяем. Поправляем, если не делает. А если я вот так позову, должно вот такое возвращать. Если вот так — вот такое. Нет этих глупых ограничений, что тест должен быть изначально сломан. Есть нюансы в том, чтобы убедиться, что Вы пишете правильные тесты, которые тестируют именно то, что Вы думаете оно тестирует. Обычно я просто изменяю тот кусок, который я думаю оно должно тестировать на заведомо неправильный и убеждаюсь, что тест сломался.
production он в том плане, что это не код тестов, а код, собственно, продукта. И это вполне валидный продакшен код, соответствующий спецификации (которая требует, чтобы в итоге результат был «3»).

Не могу согласиться, спецификация все же требует, чтобы была обработана строка «1+2» и на выходе был правильный результат, который равняется «3». Можно конечно возразить, что есть вариант захордкодить все возможные входящие строки, но это абсурд и ИМХО никак не является требованием TDD, смысл 3го шага, который refactor там в том, чтобы сделать изначально работающий корректно код более сопровождаемым и/или читабельным.

P.S. Сейчас открыл книжку Бека, как одного из основателей подхода, там действительно предлагается на первом шаге предлагается хардкодить вычисленный в голове результат, но, опять же ИМХО, это намеренное утрирование, чтобы было понятно, что тесты должны запускаться почти на каждую компиляцию, а компилировать стоит почти на каждую новую строку (люди пишушие на C++ вздрогнули).

Хотелось бы всё-таки точную цитату а не имхо. Вообще тесты сейчас просто фоном в процессе набора гоняются NCrunch и live unit testing.


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


https://medium.com/@kentbeck_7670/test-commit-revert-870bbd756864

и в реальном мире все сразу напишут return a+b;

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

Эм, с чего бы? Вероятно я вас не понимаю, вы не могли бы привести пример, какие «недоалгоритмы» понадобятся, чтобы написать тесты на калькулятор?

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


Эм? А эту догму вы откуда достали?

Ну, это и есть определение ТДД — не писать код до теста, который покроет этот код. Если вы сперва пишите код, а потом тесты на него (в данном случае — сперва пишите код для обработки краевого случая, а потом тест для этого случая) — это прямой tdd violation.


Довольно бездоказательное утверждение.

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


К слову 100% покрытие — это такой же не здоровый фанатизм, как и полное отсутствие тестов.

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

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

А можно пример рефакторинга в результате которого возникает непокрытый код из покрытого?

Есть ТЗ на работу с каким-то списком из 10 элементов. На задачу хорошо ложится единоразовое выделение памяти. Пишем тесты для 10 элементов, пишем единоразовое выделение памяти изначально, захардкодив 10. Но мы же думаем о будущем и понимаем, что скоро может прилеть задача на расширение списка до 11+ элементов. И делаем ветку, в которой при обращении к элементу с индексом большей длины происходит выделение памяти в достаточном для этого индекса размере. Наши тесты этого не покрывают, но остаются зелёными. Рефакторинг проведён, наблюдаемое поведение кода осталось неизменным.

Это не рефакторинг, это создание мертвого кода на вырост либо увеличение функциональности.


Википедия:


Рефа́кторинг (англ. refactoring), или перепроектирование кода, переработка кода, равносильное преобразование алгоритмов — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы[1][2].


У вас цель не совпадает с целью из определения

Английской вики я доверяю больше:


code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the software (its non-functional attributes), while preserving its functionality. Potential advantages of refactoring may include improved code readability and reduced complexity; these can improve the source code's maintainability and create a simpler, cleaner, or more expressive internal architecture or object model to improve extensibility. Another potential goal for refactoring is improved performance; software engineers face an ongoing challenge to write programs that perform faster or use less memory.
Refactoring is intended to improve the design, structure, and/or implementation of the software (its non-functional attributes), while preserving its functionality.

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

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

Это уже не рефакторинг. Меняется не только факторинг но и функциональность.


Там уточнено.


(its non-functional attributes)

Никто эти изменения функциональности не видит, ни одним существующим способом их выявить нельзя. Разве это можно назвать изменением функциональности?

То есть это мертвый код?


In computer programming and software design, code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior.

Статья factoring ведет на decomposition.


Decomposition in computer science, also known as factoring, is breaking a complex problem or system into parts that are easier to conceive, understand, program, and maintain.

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


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

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

Как же это нельзя? Можно. До этого у вас был один результат вызова ф-и, а теперь — другой.


Разве это можно назвать изменением функциональности?

Ну функциональность меняется же. Значит — можно. Семантика изменилась.
Рефакторинг не должен менять семантики — т.е. не должно существовать терма, который до рефакторинга и после рефакторинга дает разные результаты.


До рефакторинга никто не мог видеть поведения для 11.

Как это не мог? Мог. Вызываю вашу ф-ю на списке размером >10, и вижу это поведение.

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

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

Изменение семантики — это не рефакторинг.

without changing its external behavior.

То, что вы описываете, поведение, очевидно, меняет.


Если в команде программист обязан работать по TDD, то не писать их он права не имеет.

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

Внешнее поведение не изменяется, поскольку оно определено только для 10 элементов. Для 11 оно неопределённое.

Разве изменение не было для того, чтобы доопределить его для 11?

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

Внешнее поведение не изменяется, поскольку оно определено только для 10 элементов. Для 11 оно неопределённое.

Ну т.е. меняется внешнее поведение для 11. До рефакторинга f(x) (где х — список длины >10) давало один результат, после — другой.


С-но, по ТДД вы сперва напишите тест для >10 элементов, а потом проведете соответствующее изменение кода.

До рефакторинга никто не мог видеть поведения для 11. после рефакторинга его также никто не может видеть. Следовательно внешнее поведение не изменилось. )

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

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

Программист имеет право вообще не писать тесты, например. Только это будет уже не ТДД :)

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

Чем-то похоже на блиц-шахматы. Это надо иметь навык и/или талант. Алёхину, понятно, это не помеха, но обычные люди, хорошие шахматисты, очень часто теряются.

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

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

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

Чем писание кода на доске не лайвкодинг?! В период пандемии теперь все интервью — лайв кодинг: пишете в каком-нибудь coderpad, там же и запускаете. Решение задачек на доске/блокноте — это повсеместные практики интервью для программистов. И да, к этому надо готовиться, тренироваться. Есть задачи на знание алгоритмов и структур данных, есть — на реализацию (как у автора).

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

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

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

Лайвкодинг — он разновидность кодинга. Так что он похож на то что делается на работе.

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

Там другая атмосфера, нет ощущения экзамена, а это ощущение как раз ответственно за 80% провалов.

Так это ощущение, надо от него избавляться. Собственно когда избавился, крайне редко испытываю сожаление, что не прошёл. В 80% случаев облегчение что пронесло )

А может даже и вреден, ведь в том же Яндексе нет своих уникальных продуктов, всё откуда-то спёртое. Ну и особо про качество тоже не сказать, тот же Яндекс.Диск как то системы пользователям поудалял.
А можете привести пример «уникального» продукта? Интересно, что вы вкладываете в это слово.
Объясню. В моём представлении об устройстве мира все продукты уникальны. Вы не найдёте два идентичных продукта. Да, даже в Яндекс.Браузере, на мой вкус, есть неплохие технологические фишки, которых нет больше нигде, хотя база же на Хромиуме. Идеи, на которых строятся продукты, могут быть не уникальны, да. Новые идеи вообще редко когда возникают сейчас. Вот только люди пользуются не идеями, а конечными продуктами. И их удовлетворённость зависит от того, как продукт реализован, а не как идея сформулирована. Поэтому мне и стало интересно, что же такое «уникальный продукт» в вашем представлении. Хочется посмотреть на него.
Уникальный продукт это который вы придумали и выпустили в мир первые, например? Это всё тонкие материи, насколько копия отличается от оригинала и мало интересно. Есть же специалисты по копированию, тот же Naspers. Мало кто знает, что они делают, но многие пользуются. Нет в этом ничего плохого. Ну просто им придумывать ничего не надо, надо просто хорошо повторить.

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

Веб-поиск, например? Если, конечно, не считать Yahoo! Directory — поисковой системой, или Lycos — хоть сколько-нибудь конкурентноспособным. Или это недостаточно революционно для вас? Или вы думаете, что Гугл старше? Или что?

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

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

Но вы не привели пример :)


В вашей терминологии есть предвзятость: подразумевается, что «копия» это что-то заведомое более плохое, чем «оригинал». Понятно, что наверно есть мелкие ребята, которые просто копированием занимаются, но в реальности и у крупных ребят обычно похожие продукты возникают вокруг похожих идей, и заменить один на другой не всегда просто. Например, Netflix и Amazon Prime. На одном есть сериалы «Загадочные события», на другом «Пацаны». Но я не хочу смотреть «Пацанов». Имеет ли в этом случае значение, кто из них появился раньше? А если нет, то в чем физический смысл довода про «неуникальность»? Вы думаете, у ребят из Амазона техническая сложность задач ниже? Конечно же, нет. Или вот Альтависта и Гугл. Правда ли тут важно кто «копия»? Повлияло ли это на качество продукта, успех в будущем или сложность задач?


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


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

Ну нет, я к тому, что придумывать что-то уникальное не надо и всё. не надо глубокого смысла искать. Есть готовый продукт и надо сделать не хуже. К тому же в Яндексе полно уважаемых специалистов, типа Полухина, например, которые плохо сделать не дадут ну или исправят.

Ох, если бы всё было так просто :)


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

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

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


Кстати ещё раньше мода была на тесты на знание языка — вот это вообще жесть.

Ерунда.

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

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

Объективно они не настолько выше вас профессиональным классом, насколько они вам это показали.

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

Тем не менее примите как данность — оно встречается.

Но при этом ничего не говорит ни о фирме.
Ни о потенциальных коллегах.

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

Причины этого явления хорошо были показаны, например, в тюремном эксперименте в Стенфорде:

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

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

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

… про проблемы которого в той же википедии есть ссылки, в англицкой подробней чем русской.
Участники эксперимента играли в тюрьму. Некоторые прямо намеренно отыгрывали роль как они её видели: "Critics also noted that some of the participants behaved in a way that would help the study, so that, as one "guard" later put it, "the researchers would have something to work with," which is known as demand characteristics."
Причём было указание прессовать "заключённых": "Although Zimbardo interpreted the experiment as having shown that the "prison guards" instinctively embraced sadistic and authoritarian behaviors, Zimbardo actually instructed the "guards" to exert psychological control over the "prisoners"."
То есть, они попросту делали что а) входило в роль; б) было прямо запрошено заказчиком.

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

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

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

А в чем конкретно проблемы дизайна? Т.е., да, люди делали то, что:
а) входило в роль; б) было прямо запрошено заказчиком.


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


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


evadesad


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

Все верно. Ровно это (в том числе) в эксперименте и исследовалось.


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

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


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


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

Ноуп, им никто не приказывал, только предлагал.

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

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

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

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

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


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

Нет, этого не было.


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

Нет, этого не было.


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


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

А дальше — уже полная самодеятельность. Ни к каким конкретным действиям "вертухаев" никто не принуждал.


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


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

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


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


С чем тут можно спорить — непонятно.

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

А Вы перечитайте кто конкретно не выпускал. Сам же руководитель лично и.


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

С чем тут можно спорить — непонятно.

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

А Вы перечитайте кто конкретно не выпускал. Сам же руководитель лично и.

При поддержке остальных "работников тюрьмы", ага.


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

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


Вы немного переворачиваете ситуация — это не стэнфордский эксперимент является частным случаев эксперимента Милгрэма, а наоборот — эксперимент Милгрэма является частным случаем стэнфордского.

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

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

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


А не "они сами стали такими в ходе эксперимента"

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


Не "сами в ходе", а "как задали заранее — так и вели"

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

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

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

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

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


Эксперимент Милгрэма, кстати, поляки воспроизвели. https://journals.sagepub.com/doi/10.1177/1948550617693060

Милгрэма с влиянием авторитета и тут считают затесавшимся, то есть знатно влиявшим эффектом.

Ерунда.

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

А.С. Макаренко и Э.В. Ильенков давно научно опровергли туфту, что люди говно по своей природе.
А.С. Макаренко и Э.В. Ильенков давно научно опровергли туфту, что люди говно по своей природе.

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

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

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

Эхм… точно? Или они и тут найдут варианты "реализоваться"?

Я 5 недель уже сижу без работы. Опыт разработки лет 8-9. Каждое техническое собеседование как колоноскопия. С лайвкодингом никогда не сталкивался и, надеюсь, не столкнусь. Это же вообще ад.


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

Как и автору поста, вам помогла бы работа над ошибками. Да, работа над ошибками, все очень просто.
Приходим домой после собеседования и сразу выписываем какие были вопросы, как мы на них отвечали и какая была реакция интервьюеров. Бывает, что на некоторые вопросы удалось хорошо ответить, такое сохраняем отдельно и стараемся запомнить к следующему интервью. Те вопросы, где есть какие-то сомнения в ответе или реакция интервьюера нам не понравилась, прорабатываем и находим ответы дома в спокойной обстановке. Так к вашему -дцатому собеседованию у вас будет покрыто 90% наиболее частых вопросов.

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


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

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

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

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

Теперь я понимаю, откуда на хабре берутся статьи про ООП, SOLID и прочие баззворды — люди просто к собеседованиям готовятся :-).

У нас в семье этот ад регулярно на добровольной основе :)

да, знакомо) Я вот 13 лет с JS суммарно, но на собесах просто большая половина мозга отваливается или занята не тем, чем надо, но все ровно половины мозга обычно достаточно для прохождения тех интервью.
Но вот лайвкоддинг в маленькой формочке на каком то сайте вообще застал врасплох, я там даже не мог нормально воспринять шрифт, цветовую схему и банально скобки расставить, буквально ослеп ибо не было еще и подсветки блоков/сигнатур.
Начал писать код, просто чтобы начать что то писать, до конца не поняв ТЗ по реализации API, ибо я ожидал от них спецификацию по интерфейсам, а они примеры вызовов налепили.
Короче, я как в универе- лучше начать что то делать, чтобы не совсем зафейлить). Очень долго рожал, как потом уже понял, посредственную фигню. Тупка жесткая, сам себе удивился… Просто дно, еще и при этом, в качестве хобби, коллаборатор/около ментейнер пакетов, один с которых с 17лямами загрузок в месяц и 1,5к зависимых модулей :)
Хоть и не одобряю лайвкодинг, должен признать что через какой-то время привыкаешь и волнение отходит, черствеешь как-то. Начинал всегда с чего-то тривиального, вся оптимизация, красота и пр. — потом, если есть время, в основном устно.
Если кому не нравится и хочет чтобы я на лайвкодинге фигачил продакшн код нон-стоп — пусть идет лесом.
У самого было похожее интервью. Очень странные ощущения. Причем в какую-то задрипанную конторку из региона по профильному языку. Прошло ужасно и, естественно, не написали даже потом. А вот в одну крупную компанию пробовал собеседоваться (причем, только лайвкодинг и был) ради «а почему бы и нет» по совершенно непрофильному языку и на удивление прошло гладко, хотя тоже волновался, но впечатления остались приятнее.
Причем в какую-то задрипанную конторку из региона по профильному языку.
Не надо так делать. В нормальные конторы на нормальную зарплату устроиться, как показывает мой пятнадцатилетний опыт, зачастую проще, приятнее и профита куда больше. У меня есть знакомые в малом бизнесе и не понаслышке знаю, если пойдёшь устраиваться продавцом в задрипаный бутик 2х2 метра — зачастую тебя будут на собесе (и на работе потом) драть и в хвост и в гриву, при зарплате в реальные копейки. С другой стороны, если не совсем олень, можно устроиться в место покрупнее, и получать без нервов зарплату получше, попивая кофеёк в кресле. Это какая-то профдеформация владельцев и мелких руководителей нижних сегментов рынка в постсоветских странах.

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

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

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

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

А что, знакомство со своим полом в этом смысле как-то кардинально отличается?

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

Имелось в виду для романтических отношений.

Мне кажется, это стоило бы сразу уточнить.

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

Есть конторы особо упоротые на TDD, ничего плохого в этом нет, просто заранее кандидату надо сказать. Т.к. навык скоростного TDD прекрасно тренируется, погонял coding kata немного, и будете говорить на одном языке на собеседовании. Хуже когда по факту никакое TDD и не используется в конторе, и на собеседование протащили 'потому что модно', как с теми олимпиадными задачками в Гугле.

Кажется, моду на олимпиадные задачки придумал Гугл, потому что у них реально очередь из кандидатов, и надо отсеивать.
Еще хуже, когда у интервьюеров вертится в голове «ни проектов ни денег больше не стало, а начальство ищет человека — видимо на замену кому-то из нас». Тогда TDD может показаться детскими игрушками…
Это называется конфликт интересов, можно задать об этом вопрос на начальных этапах. Ситуации, в которых появляются эти конфликты — угроза существующим процессам.
Вопрос-то можно задать — но кто же вам ответит, тем более когда интервьюеров несколько. Именно поэтому, если поведение интервьюеров вам показалось странным — лучше возблагодарить судьбу и поискать более нормальную компанию. А если странным образом ведет себя HR — вдвойне.
Смотря кому задавать вопрос. Есть не заинтересованные источники, нельзя вот так вот просто взять и пойти и устроиться в произвольную компанию, не понимая, какие у неё текущие финансовые показатели, вероятные интересные проекты и обстановка внутри.
При одном из предыдущих трудоустройств я не знал об этих показателях, и в итоге за это поплатился. Хотя там был опыт, и я особо сильно не жалею.
Любая новая ситуация для человека — стрес. Это нормально. Пройдете десяток и все наладится.

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

Да я сейчас даже уравнение получения C2H5OH из сахара не вспомню.
В самом лайвкодинге ничего плохого нет. Он ставит целью проверить соображалку разработчика и умение родить какой-то алгоритм.
Когда я проводил собеседования, то просил разработчка изобразить какой-нибудь простой алгоритм на целевом языке на доске. Сразу с оговорками, что всякие синтаксические ошибки если и будут — то не страшно. Из задач предлагалось обычно перевернуть строчку задом наперёд или поменять порядок бит в числе на обратный. Требовать парсер выражений писать бессмысленно. Так вот, далеко не все Senior'ы даже с такими задачами справлялись (что, в первую очередь, говорит о качестве рынка разработчиков в целом).

Но если к вам приходят чуваки и говорят работать строго в одной парадигме (TDD), то от них надо бежать сломя голову. И есть серьёзные сомнения, что с архитектурой их проекта тоже не всё в порядке, и там костыль на костыле, но зато тесты работают.
Ну да, я на своём первом интервью 10+ лет назад не смог написать Фибоначи. Передо мной положили листок — и внутри головы все сразу опустело, и я уже даже не особо понял задание, что они спрашивали. Потому что лайв-кодинг — это 80% стресс-тест и в лучшем случае около 20% — проверка навыков. И если бы у меня, даже на привычной мне работе, постоянно стояли бы сзади и смотрели бы, как я пишу код, я бы тоже долго не задержался. Слава-богу, такого нигде нет.
Если человек не имеет привычку часто менять работу, или просто часто ходит на собеседования, шансы на успешное прохождение лайф-кодинга и алгоротмичных задач весьма низки. Говорит ли это как-либо о ровне навыков человека? Я не уверен в этом.
И если бы у меня, даже на привычной мне работе, постоянно стояли бы сзади и смотрели бы, как я пишу код, я бы тоже долго не задержался. Слава-богу, такого нигде нет.


Ойли! А вы не слышали про парное программирование? Очень модная фигня, кстати. Не все это делают, но те, кто делают, очень этим гордятся.

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

Еще раз: к собеседованиям надо готовиться. Это не так, что сегодня вместо работы пошел на собеседование, а завтра — опять на работу. В хорошие компании люди по полгода готовятся к собеседованиям, по вечерам решая задачи на LeetCode, прорабатывая дизайны разных систем для дизайн интервью, делая mock-интервью.

Говорит ли это как-либо о ровне навыков человека? Я не уверен в этом.

Может, говорит, может — не говорит. Можно долго рассуждать на эту тему, но те, кто готовятся, попадают в хорошие компании на хорошие зарплаты, а те, кто не готовится, продолжают рассуждать, что это не показатель.
Ойли! А вы не слышали про парное программирование? Очень модная фигня, кстати. Не все это делают, но те, кто делают, очень этим гордятся.
Ну тут совершенно разные ситуации, на самом деле.
При парном программировании вы сидите вместе не с каким-то абсолютно незнакомым мутным типом который смотрит на вас с подозрением «а не самозванец ли ты», а с коллегой по проекту с которым знакомы уже какое-то время и который знает что вы нормальный разработчик. И точно так же различаются цели: при парном программировании вы команда, ваша общая цель — написать рабочий код, а если один будет тупить/тормозить, то другой его поддержит и поможет, и это абсолютно естественно. На собеседовании же цель «написать рабочий код» только у вас, а цель интервьюера — оценить как вы умеете это делать, и каждый ваш затуп работает против вас, отнимая ценные очки (общее число которых вы знать не можете, и каждый затуп может оказаться последним), отсюда и стресс.
У меня раньше тоже было такое отношение к собеседующему, типа, «меня оценивают», «ему нельзя доверять», «все советы интервьюера будут засчитаны не в мою пользу, если я ими воспользуюсь, ибо будет выглядеть как подсказка». И все поменялось, когда я перестал бояться интервьюеров и относиться к ним как к своим коллегам, где вы вместе на собеседовании пытаетесь решить общую задачу. Также, есть возможность показать свои софт скилы, как вы умеете слушать и общаться с другими, воспринимать критику.
Бывает, конечно, когда интервьюер &удак и нормальный диалог с ним трудно построить. Но тогда и Вам стоит задуматься: а хотите ли вы работать с такими &удаками в одной компании. Интервью — это обоюдный процесс: они оценивают Вас, Вы — их. Им тоже важно заинтересовать придти работать к ним в компанию (и сэкономить немного на Вашей зарплате, потому что работать с &удаками люди идут только если там платят больше других).
Да, интервьюверов тоже оценивают, но это сводится к вежливому поведению и рассказе о проекте/компании. Им не приходится активно защищать свои профессиональные навыки. Для них это не стресс, а рутина, или даже навязанная обязанность, как это бывало со мной.
Раньше, если хорошо подобрал компанию и она тебе подходила по профилю, можно было с очень высокой вероятностью устроиться туда, сейчас же люди зачастую собеседуются десятки раз, ибо это превратилось в лотерею, ну или в длительное задротсво.

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

Ойли! А вы не слышали про парное программирование?

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

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

Это приходит с практикой, а не «потому что так подумал». Покуда не пойдешь их какое-то количество, спокойствие не придет.

Еще раз: к собеседованиям надо готовиться

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

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

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

И да, вы совершенно правы про FAAGN и пр… Они, впрочем, сами заявляют, что им норм большой процент false-negatives, т.е. то что они отвергают много хороших специалистов, которые им на самом деле подошли бы. Но у них огромная очередь, всех не принять, вот и придумали, как отсеивать дополнительно.
Проблема только в том что не все компании — это FAANG, но они этого не понимают. А потому продолжают в лайв-кодинг просит делать неприличные вещи с деревьями, и потом жаловаться на то что не могут полгода закрыть одну вакансию, когда у них в продакшене унылый REST API с каким-нибудь legacy/говнокодом.

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

Еще раз: к собеседованиям надо готовиться. Это не так, что сегодня вместо работы пошел на собеседование, а завтра — опять на работу. В хорошие компании люди по полгода готовятся к собеседованиям, по вечерам решая задачи на LeetCode, прорабатывая дизайны разных систем для дизайн интервью, делая mock-интервью.

К собеседованиям в нормальные компании готовится не надо.
Потому что в нормальных компаниях оценивают навык работы а не навык прохождения собеседований.
И нет, Гугл и прочие подобные нормальными не являются.
Да, там есть пончики, настольный теннис, огромная зарплата и интересные задачи на острие технологий (но попасть на них очень и очень сложно, в большинстве случаев ты будешь писать нечто супер скучное для чего не требуется не один из навыков которые у тебя спрашивали на собеседовании) и строчка в резюме «я работал в Гугле».
Собственно за зарплатой и строчкой в резюме туда и идут.
Но это не делает Гугл нормальной компанией.
А как оценить навык работы?
Я просто вижу несколько способов —
1. устроить на испытательный срок, причем, в зависимости от бизнес-логики, в которую понадобится вникать, срок может варьироваться от месяца до года. — не подходит по очевидным причинам.
2. рекомендации с прошлой работы от начальства — не видел ни одной норррмальной конторы, где такое просили бы (в России)
3. поверить кандидату на слово, что он хорошо работает. Автор статьи, под которой мы комментим, как раз про такое писал не раз — что он знает, что мало чего умеет, а собесы прошёл исключительно на софт-скиллах, нагрузив интервьюверов — читай обманув. В норррмальных конторах работают лохи, которых можно легко обмануть?

Ничего не упустил?
А как оценить навык работы?

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


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

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

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

Что делать людям, которые не пушат в опенсорсы и не делают коммиты в чужие проекты?

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


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

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


либо недостаточно времени уделяют основной работе

Да-да. И те, кто на Stack Overflow отвечают — делают это в ущерб работе. И в блоги тоже пишут лентяи. Слыхали, знаем. Я лично не скрываю ни активность на SO, ни PR в чужие проекты, ни почти десяток активно поддерживаемых и развиваемых мною лично библиотек, — от руководства. И ему, руководству, почему-то не приходит в голову сделать из этого вывод, что я — тунеядец.


Про тестовое задание вам тоже выскажут своё «фи» секта свидетелей ненужного тестового задания [...]

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

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

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


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


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

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

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

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


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

Да ну? Прямо-таки нет смысла? Так-то я от неинтересных задач на работе просто отказываюсь, их как раз отлично сделают те, кто не пилит пет-проекты на хаскеле.


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

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


P. S. С Шипилёвым, процитированным sergey-gornostaev чуть выше, я при всем этом не согласен. Мне просто нравится делать мир чуть-чуть лучше, дальновидность тут ни при чем.

Делать мир чуть лучше, чтоб пересылать чужие деньги для разрушения матушки Земли чуть быстрее — каков цимус ситуации…

Может все таки лучше апельсины собирать напрямую?
Да ну? Работодателю это даст гораздо больше, чем можно было бы подумать: человек умнеет, набирается опыта, расширяет кругозор, точит профессионализм. Если мы не про галеры, конечно, где слишком умные никому не вперлись..

Ну, это просто не так.


Да ну? Прямо-таки нет смысла?

Прям-таки нет. Зачем писать код в опенсорс бесплатно, если можно писать этот же код на работе за деньги?


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

А следить за апдейтами форка кто потом будет?


sergey-gornostaev
А зачем кому-то может понадобиться что-то с собой "утаскивать" после увольнения?

Ну, это просто не так.

Непробиваемый аргумент. Был бы, если бы для опровержения не требовал одного контрпримера. Так вот, в моем мире это так. На моей работе это так.


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

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


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


А следить за апдейтами форка кто потом будет?

Один из квадриллиона гитхабовских ботов, предназначенных специально для этого.


А зачем кому-то может понадобиться что-то с собой «утаскивать» после увольнения?

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

Был бы, если бы для опровержения не требовал одного контрпримера.

Один контрпример это утверждение никак абсолютно не опровергает.


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

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


Бывают люди, выбравшиеся из нижнего слоя пирамиды Маслоу

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


Один из квадриллиона гитхабовских ботов, предназначенных специально для этого.

Уже придумали ботов, которые конфликты слияния сами разруливают?


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

А зачем для этого что-то "утаскивать" после увольнения?

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

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

Опять деньги.

Не понял, где вы в процитированной фразе увидели деньги.

А зачем кому-то может понадобиться что-то с собой «утаскивать» после увольнения?

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

Приглашения разыскавших тебя людей в погонах?
(сейчас уже давно не 90-е, и то что на работе по контракту находится под NDA)
то что на работе по контракту находится под NDA

Во-первых, это зависит от того, что написано в NDA. Во-вторых, мы тут про коммиты в OSS, алё.

Как уже сказали, что под NDA — зависит от условий контракта. У меня самого был такой случай: писали мы продукт на работе и в веб части пользовались известной библиотекой для валидации данных от пользователя. В какой-то момент нашли в продукте баг, оттрейсили его до этой библиотеки. Я сделал патч для нее и отослал PR в ее репозиторий. Мэйнтейнер согласился, что это была плохо продуманная функциональность, которая в определенных случаях ломает все остальное, но, поскольку эта фича была уже публчная, надо ждать мажорного релиза, чтобы убрать ее. В итоге мы на работе форкнули проект и поддерживали свой внутренний форк с нужным нам фиксом. Далее, после нескольких дополнительных проблем с этой библиотекой, я сел и за выходные написал свою библиотеку валидации, выложил на Github (под MIT лицензией), а потом на работе предложил перейти на нее. И последующие доработки моей библиотеки я уже делал на работе, потому что нужно было для нужд компании. У компании был код без багов, возможность чинить баги быстро (ибо мэинтейнер библиотеки работает в компании), у меня — еще один опенсорс проект в мое Github портфолио.

Зачем им что-то показывать? Разве недостаточно просто рассказать про свой опыт?

Многим нанимателям недостаточно. Представьте на секунду, что у того же Шипилёва нет никого вклада в опенсорс и вся его работа обложена NDA, как это часто бывает, а ему надо сменить работу. И вот на рынке труда оказывается один из самых крутых программистов современности, за спиной которого больше десятка лет работы с виртуальными машинами и сборщиками мусора, но об этом никто не знает и нет тому никаких доказательств. Что делать в таком случае?
Что делать в таком случае?

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

И работодатель должен поверить на слово? Мне, например, даже в менее невероятных утверждениях не верит.
И работодатель должен поверить на слово?

Почему нет? В других отраслях же верят.

Например в каких? Повторюсь, я очень часто сталкиваюсь с необходимостью доказывать свой профессионализм, несмотря на то, что у меня область деятельности намного проще, чем у Шипилёва. Да и по другую сторону баррикад бывать приходилось. Любая более-менее серьёзная экспертиза просто не укладывается в формат тестового задания, а беседа с соискателем может демонстрировать только то, что он начитался Клепмана, например, а по факту не писал ничего, что обрабатывало больше одного запроса в секунду.
Например в каких?

Да во всех :dunno:
Это только программистов почему-то считают патологическими лжцецами.


chapuza


Работодатель-то, работодатель как его найдет? Или вы предлагаете специалисту такого уровня рассылать резюме?!

Эм, ну есть специально обученные люди — эйчары, которые видят, что Вася уволился из Х и теперь свободен. Даже у меня такие предложения сразу после увольнения бывали, хотя я нифига не специалист "такого уровня".
Каким боком тут всякий опенсорс — непонятно.
Опять же — в других индустриях никакого аналога опенсорсу нету, но как-то работодатели квалифицированных кадров находят.

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

Чем они увидят, третьим глазом? Как? Или мне теперь пойти обратно открыть профиль на линкедине, и разгребать спам? Зарегистрироваться на фейсбуке и там ныть про потерю работы?


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


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

Чем они увидят, третьим глазом? Как?

Я не эйчар, так что не знаю. Я только знаю, что видят — это наблюдаемый факт.


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

Какие еще разговоры с эйчарами?


Профиль на линкедине

Какой еще профиль на линкедине?


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


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

Это только программистов почему-то считают патологическими лжцецами.

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

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


А программитами устраиваться — идут. Толпами. FizzBuzz же не спроста появился. А чего такого? Там же просто кнопки надо нажимать, это просто.

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

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

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

Дело как раз в мошенниках. Вернее в тех, кто вводит работодателя в заблуждение, может сам находясь в добросовестном заблуждении, что знает технологию X v.15 и может на ней решать реальные задачи.


То, что водитель не умеет водить машину типа X будет заметно моментально. А вот программист может долго вводить в заблуждение, если хоть что-то умеет.

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

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

PS а насчёт доказательств, то:
habr.com/ru/company/headzio/blog/519590
Однажды мне довелось проводить собеседование кандидата, который просто скопировал кусок моего резюме. Вскоре после моего увольнения он пришёл на проект, в котором я работал. Как потом выяснилось, долго не мог придумать как красиво описать полученный на новом месте опыт и просто нагуглил резюме человека, уже работавшего в этой команде.

Работодатель-то, работодатель как его найдет? Или вы предлагаете специалисту такого уровня рассылать резюме?!

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

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

В испуганные глаза, которого, я посмотрел когда просто поднялся в ваш офис. Вы то думали я далеко…

А вон оно как вышло…
Я вообще считаю, что люди, которые делают коммиты в чужие проекты либо сверхлюди, либо недостаточно времени уделяют основной работе

Что ж… Осталось понять, кто я такой…
Что ж… Осталось понять, кто я такой…

Сверхчеловек, который недостаточно времени уделяет основной работе)
Я вообще считаю, что люди, которые делают коммиты в чужие проекты либо сверхлюди, либо недостаточно времени уделяют основной работе

Ну вот часть моих коммитов в чужой код родилась так:


  • приходит задача от бизнеса или техруководителя
  • понимаю, что можно решить с помощью какого-то опенсорс ПО (в случае с задачи от техруководителя оно может быть указано явно)
  • решаю, всё хорошо, проверил на основных кейсах на дев-окружении.
  • на тестировании QA проверяет глубже и находит баг. А то и пользователь конечный в продакшене находит.
  • локализация бага показывает на это ПО
  • нахожу способ решения путём изменения этого ПО, делаю публичный форк и PR в апстрим
  • в зависимости от разных условий или переключаю нашу систему на свой форк, или жду очередного релиза в апстрим с фиксом, или делаю обход проблемы, аналогичный по сути PR, но в обёртке типа декоратора для этого ПО.

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

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

За 10 лет работы программиста был на 15 в сумме собеседований наверно. При смене работы больше 3 собеседований не нужно обычно.

Если Вы готовы принимать первый же офер не торгуясь, то, да, из трех интервью Вы, скорее всего, одно да пройдете. А если хотите поторговаться, то нужно иметь хотя бы офера три. Чтобы их получить надо будет сходить на 5-10 интервью.

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

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

Зачем? Какая разница три или один? Вы же не аукцион устраиваете с одновременным присутствием всех возможных работодателей.

Затем, что можно поторговаться. Берете офер у компании А, говорите, что подумаете и подождете оферы от компании Б и В. Потом, когда рекрутер компании А Вам снова позвонит, скажите, что Вы еще не собрали все оферы, но есть уже офер от компании Б, который немного выше (есть какие-то более приятные бенефиты и т.п.). Спросите, может ли компания А заматчить офер компании Б/предложить какие-то дополнительные бенефиты?" И вот это все. И там можно по кругу поднимать ставки, если у Вас есть соответствующие скилы. Если Вы действительно ценный специалист, компании будут готовы поторговаться, потому что искать кадры — долго и дорого.
Если Вы действительно ценный специалист, компании будут готовы поторговаться, потому что искать кадры — долго и дорого.

Нет, потому что в набор умений «ценный специалист» в первую очередь входит отсутствие стремления нагреть работодателя по мелочи. Хочешь не N, а N+M денег? — Озвучь, и если ты ценный специалист, мы что-нибудь, да придумаем.


А вот «у меня тут предложение от конкурентов» — это сразу безвозвратное «до свидания». В хороших местах крайне редко бывают востребованы люди с таким менталитетом.

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

Остальные за ними. Так что предупрежден, значит вооружен…

Про апельсины я выше вам написал — для вас это будет выход…
Что будет 21 декабря ?) Гугл пишет только «Землю ждет мощная энергетика перемен – очередной большой цикл гигантов станет ...»
А вот «у меня тут предложение от конкурентов» — это сразу безвозвратное «до свидания». В хороших местах крайне редко бывают востребованы люди с таким менталитетом.

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

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

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


тебя за холопа считают без права договариваться

И чего, часто отказывались? Можете не отвечать, вопрос риторический.


Я же по-русски, вроде, окрытым текстом написал:


Хочешь не N, а N+M денег? — Озвучь, и если ты ценный специалист, мы что-нибудь, да придумаем.

Где тут холоп, кроме вашего подсознания?

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

Да не важно. Просто скажите имя компании. Прорекламируйте, где самые лучше люди, проекты, технологии и вот это все.
kantox — такой небольшой стартап :-) оборот около 12 000 000 000 евро (да да 9 нулей а не 6 !). А все потому, что ваш коллега с которым вы выше общались лично, написал работающий код и построил работающую систему с другими своими коллегами.
А не многовато ли?

На их LinkedIn странице написано
Over 5,100 clients in 72 countries have already exchanged more than USD $12.5 billion with Kantox.

Они «помогли клиентам перевести 12 ярдов денег». Это, как бы, не их собственные деньги. Более того, это, похоже, сумма за 9 лет существования компании, а не за год.
www.kantox.com/es На сайт зайдите там внизу точный счетчик

$12 675 912 143
Volumen cambiado

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

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

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

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

Охрана пропустит при должном навыке и приглашения не спросит… А если не можете, то тогда и воздух не сотрясайте.
Зря вы спорите, если вы да же тот самый Максим, который проживает в Болгарии, все равно ваш визави на дух не переносит хакеров… потому что сам такой же…
И чего, часто отказывались? Можете не отвечать, вопрос риторический.

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

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

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

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

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

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


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

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

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


Milein


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

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

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

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

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

В смысле «не договорились»?! Я так понял, до обсуждений дело не доходит. Вы имели в виду «что если не взял что дают»? Это такое. Всех благ таким работодателям и успехов с поиском работников. Если, конечно, у Вас из достижимых мест работы только одна контора, то, да, ничего не сделаешь, надо переезжать.
У Вас, наверно, рынок перегрет: вакансий мало, а желающих много

Не понял связи.


В смысле «не договорились»?!

Ну что-то вроде: "плати Х" — "не буду" — "до свидания".


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

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


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


По-этому наличие/отсутствие оффера никак и ни на что не влияет кроме вашего блефа. Или — вообще ни на что не влияет, если работодатель и так знает, что блефа нет.


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

Так зачем эти варианты заранее искать? Как понадобятся — так и найдутся.


Milein


Но если я продаю арбуз, и мне предлагают купить его за 20 рублей, а я отвечаю «мне уже за 30 предложили, но за 35 отдам» это сильнее позиция чем, «нет, 20 мало, давай 30».

Да нет, это заблуждение. Совершенно неважно в данном случае готов ли кто-то другой у вас купить арбуз за 35, 100, 135. Важно лишь желание вот этого конкретного человека и его финансовые возможности. До желаний и финансовых возможностей других людей ему дела нет. Тот факт, что Вася заплатил за арбуз стотыщрублей, никак не влияет на вашу готовность самому платить за этот арбуз больше. Понимаете? Если он вам за 35 рублей не нужен, то вы его за 35 покупать не станете. И не важно кто и сколько за него готов заплатить среди других вероятных покупателей.

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

Напрямую не влияет, но если вы приносите.экономите работодателю Х денег, платит он вам Х/3, но вдруг узнаёт, что вам кто-то готов платить Х/2, то он может и начать платить вам больше, если будет знать, что за Х/3 он друго сотрудника не найдёт.

но вдруг узнаёт, что вам кто-то готов платить Х/2, то он может и начать платить вам больше

Это если он сам узнает. Мы же говорим про ситуацию когда вы пришли к нему и говорите: "давай денег". И тут не важно узнает он или нет. Он либо готов вам платить столько, сколько просите — либо нет. Сумма, которую предлагают другие покупатели, вообще никак не может повлиять на его решение.


Milein


Простите, но у вас какая-то альтернативная экономика, совершенно оторванная от реальности.

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


Как вы здесь умудряетесь видить заблуждение? Когда тут нужно посчитать всего лишь 2 варианта «переговоры удались» и «переговоры провалились» перемножить на 2 ситуации — есть вариант Б или нет.

Ок, разжую полностью вам. Вот у вас есть продавец он готов продавать арбуз не менее чем за Xр. Вот есть покупатель — он готов покупать арбуз не более чем за Yр. Они начинают торговаться, и если Y > X то когда цена попадет в диапазон [X, Y] сделка совершена.


Обратили внимание, что третьих лиц тут нет? Если мы введем некоторого покупателя, который готов купить арбуз за Z > X, то это никак не повлияет на то, что максимальная цена первого покупателя — это Y.


Просто не существует причины, по которой первый покупатель ВНЕЗАПНО захочет отдать арбуз дороже из-за существования второго.


MaximKulkin


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

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


Давайте начнем с предыстории.

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


Хотя бы потому, что 1) как отмечалось ранее, к собеседованиям надо готовиться;

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


Хотя бы потому, что

Дык а контроффер то с вашими пунктами как связан?


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


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

Не понял, какое это отношение имеет к процитированному куску про арбузы. Еще раз — если человек не готов покупать арбуз за 35, то он не будет. Можете хоть там толпой бегать и покупать по 100 или по 1000, не важно это ему. Он не хочет арбуз за 35, ему не нужен такой арбуз. Зачем покупать то, что не нужно?

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

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

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

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

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


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


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


Работодатель всегда знает про хорошего сотрудника, что у него есть стопиццот офферов, и никакими деньгами удержать его нельзя (если мы не про сумасшедшие стартапы с миллиардными инвестициями). Также и с вновь приходящими: завлекать их +20% к текущей зарплате недальновидно (да просто глупо), потому что вечно быть на 20% впереди рынка нерентабельно (если ты не торгуешь приватными данными, конечно, тут у FAAGN карт-бланш, но туда приличные люди и не ходят уже давно), а как такой сотрудник к тебе пришел за 20%, так он от тебя завтра и уйдет. Я никогда не слышал, чтобы адекватные работодатели платили заметно больше рынка — эта тактика на длинном отрезке времени просто не работает.

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

Нет, не бедствуют, но время от времени однотипность проектов/выполняемой работы надоедает и хочется смены обстановки. Ну а кто-то недоволен отсутствием возможности роста и повышений (как должности, так и зарплаты). Как правило, люди сидят на одном месте от 1.5 до 5 лет, потом настает время что-нибудь поменять. И часто переходу сопутствует повышение статсов разработчика (больше лет опыта, больше проектов в резюме и т.п.), поэтому каждый переход часто сопровождается и обновлением ЗП. Конечно, бывают ситуации, когда разработчик уперся в потолок, сидит лидом, и зарплата у него такая, что в новом месте с порога не найти. Такой разработчик продолжает сидеть дальше, все просто.
[…] как должности, так и зарплаты […]
[…] переходу сопутствует повышение статсов […]
[…] обновлением ЗП […]
[…] зарплата у него такая, что в новом месте с порога не найти […]

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


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

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

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


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

Как бы Вы нам не хотели продать, что надо за гроши работать в «крутых командах».

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


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


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

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


«Вы бы видели, какую я в Сплите вырастил капусту», — как в схожей ситуации говаривал Диоклетиан.

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

Это все читалось между строк.

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

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

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

Вообще, достаточная зарплата — это движущаяся цель. Когда Вам 25-30, нет жены и детей, $150к в год (в Долине*) — отличная зарплата. Но как только появляется жена и ребенок, сразу надо содержать и их, переехать из комнаты в квартиру/дом, купить машину (а то и две). Потом захотите завести еще ребенка и уже надо дом побольше, сменить SUV на минивэн. И вот уже надо искать работу с зарплатой побольше (точнее, искать заранее). А потом Вы решите заняться каким-нибудь хобби, которое тоже требует денег.

Только, если человеку интересно материальное благополучие как самоцель. Вы удивитесь, но довольно многим — нет.

Вы опять лукавите. О каком «материальном благополучии» мы сейчас говорим? Иметь гараж с Феррари и Бентли? Да, многим это не нужно. А содержать семью с двумя детьми и иметь возможность хотя бы раз в год съездить куда-нибудь в отпуск — это базовая потребность, которая тоже немало стОит.
Это все читалось между строк.

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


Вы опять лукавите.

Ditto.


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

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

Слушайте, ну почитайте хоть в википедии, что такое вообще пирамида Маслоу, не позорьтесь.

Я и не позорюсь. Я говорю простым понятным языком, а не пытаюсь казаться умным, аппелируя к «тонким материям».

Например, я систематически отказываюсь от работы в США, потому что мне просто неприятна страна. Хотя увеличесние зарплаты в пять раз могло бы случиться завтра.

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

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


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

Я что-то пропустил, и вышел закон, запрещающий упоминать умозрительные гипотезы?


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


Даже хуже, разделение разных подходов в CS на ООП, ФП и прочее ПП — тоже не более, чем умозрительная гипотеза. Даже ньютоновская механика — внезапно — умозрительная гипотеза.


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

Любовь — это тоже умозрительная гипотеза

Любовь — это не гипотеза, это чувство.


Даже хуже, разделение разных подходов в CS на ООП, ФП и прочее ПП — тоже не более, чем умозрительная гипотеза.

И это тоже не гипотезы.


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


Я что-то пропустил, и вышел закон, запрещающий упоминать умозрительные гипотезы?

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


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

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

Любовь — это не гипотеза, это чувство.

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

Внезапно — нет. Под этим термином понимают широчайший спектр комбинаций эмоций и ощущений

Это и называется "чувство".

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

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


саму эту гипотезу, из который делаете выводы — не понимаете

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

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

А не важно, как именно — главное, что некорректно.


Я не делал вообще никаких выводов.

Делали.

Для меня повышение зарплаты напрямую относится к 3-4 уровню.

Чтобы выстраивалась толпа, надо везде и сильно пиарится. Не все это делают, совсем не все.

Например я крутой web-разработчик со знанием интернет-маркетинга, делал 10 лет очень крутые уникальные e-commerce штуки в одном и том же месте, которые были в top-5 отрасли, стал практически партнёром компании. Но нигде не пиарился, кроме выступления на одной конференции на it-retail, и ежегодных попоек конференций там же, конференций Oborot и Ciso Forum. Но сейчас, когда повсюду кризис, не вижу за собой очереди хедхантеров.
Я думаю, хедхантеры работают немного иначе. Вряд ли какой-нибудь хантер просматоривает списки докладчиков конференций, чтобы намайнить себе потенциальных кандидатов. Обычно всякие такие активности идут Вам плюсом уже после того, как Вашу карточку найдут на каком-нибудь ЛинкедИне. Ну и в кризис найм во многих компаний уменьшается, а не увеличивается.

Лично я считаю, что выступления на конференциях — это достаточно небольшой бонус с точки зрения нанимателя. Часто туда ездят люди, которым нравится выступать на конференциях, и рассказывают про то, что они делают на работе. Не все доклады — это какой-то хайтех, часто просто структурированный сборник накопленных практик. Для DevRel специалистов такие скилы важны, для разработчиков — не особо.
Насчет больших StackOverflow профилей — этого я вообще не понимаю. Т.е. человек в рабочее время сидит и занимается ответами на SO вместо работы?!
Также, надо разбираться и с Гитхаб активностью. Я понимаю, когда человек горит программированием, выкладывает свои проекты (потенциально полезные другим, а не непонятные домашние поделки), контрибьютит в чужие. Если куча выложенных проектов с работы — мне это особо ни о чем не говорит.

Так что, не парьтесь сильно. Занимайтесь тем, чем нравится, для души, а не для статсов.
Обычно всякие такие активности идут Вам плюсом уже после того, как Вашу карточку найдут на каком-нибудь ЛинкедИне.

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


Интересные предложения в 99% случаев исходят от CTO напрямую и начинаются с фразы «наткнулся на ваш профиль на gh / so».


Такие дела.

Интересные предложения в 99% случаев исходят от CTO напрямую и начинаются с фразы «наткнулся на ваш профиль на gh / so».

Только на самом деле, как вы понимаете, натыкается не СТО.

Конечно. Но прямое указание искать на GH/SO отдает CTO, а тот, кто натыкается — умеет там искать. Другой уровень совсем, судя по результату.

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

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

Или на уровне рынка, если есть, чем завлечь помимо зарплаты.


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


Но никогда не заметно ниже рынка, даже если это rocket science.

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

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

Простите, но у вас какая-то альтернативная экономика, совершенно оторванная от реальности.

И нет, другой человек может иметь бюджет в 100, но он не дурак и хочет заплатить минимум за этот арбуз.

Как вы здесь умудряетесь видить заблуждение? Когда тут нужно посчитать всего лишь 2 варианта «переговоры удались» и «переговоры провалились» перемножить на 2 ситуации — есть вариант Б или нет.

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

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

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

Не понял связи.

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

Ну что-то вроде: «плати Х» — «не буду» — «до свидания».

Если в Вашем окружении вот буквально так общаются, то это жесть.
Давайте начнем с предыстории. Когда Вы задаетесь какой-то суммой X, она не берется с потолка. Сначала Вы делаете исследование, сколько на рынке стоят программисты со схожими Вашим навыками, опытом и т.п. Получаете вилку. Потом Вы ищете компании, которым нужны специалисты Вашего уровня, делаете исследования, какие зарплатные вилки в каждой конкретной компании для специлистов Вашего уровня. Отсеиваете те, которые столько заплатить не могут. Может получиться так, что не найдете и надо будет пересмотреть X. Честное слово, почему это вообще надо проговаривать. Это не так, что пришел в любую рандомную компанию, открыл дверь с ноги и сразу просить заоблачную зарплату. Если Вы дошли до этой компании и прособеседовались, надо уже иметь понимание, смогут они Вам столько платить или Вы просто тратите и свое, и их время.

Так зачем эти варианты заранее искать? Как понадобятся — так и найдутся.

Хотя бы потому, что 1) как отмечалось ранее, к собеседованиям надо готовиться; 2) мы рассматриваем ситуацию, что Вы находитесь в активном поиске и надо найти новую работу за конечное, обозримое время; если Вы сидите на свое текущем месте и Вас все устраивает, можно вялотекуще собеседоваться… или вообще не собеседоваться; 3) у Вас в городе более двух-трех мест работы и город не достаточно маленький, чтобы все друг друга знали; 4) есть больше одной потенциальной конторы, где хотелось бы работать (с интересными проектами/технологиями и т.п.). Так вот, при всем при этом, делать одно интервью за раз, потом ждать ответа, потом при отказе делать следующее интервью и т.д. очень долго. и противоречит второму предположению (что надо быстро). Далее, на протяжении всего этого долгого процесса надо поддерживать свои знания алгоритмов, структур и вот этого всего свежими… Если процесс растянется на месяца 4, то к концу можно уже все позабыть. Поддержания себя в тонусе — занятие утомительное (да и в целом интервьюирование — это стрессовое занятие, поэтому хочется сделать его побыстрее). Поэтому люди освежают свои знания и начинают ходить на интервью, не дожидаясь результатов. Также, не все офферы и компании одинаковые: в каких-то более интересные технологии, где-то платят чуть больше, где-то работать престижнее. Поэтому сравнивать офферы не просто сравнить TC (total compensation). И также, если Вы ищите новую работу, чтобы получить прибавку к ЗП (например, потому что на старой работе Вам уже лет 5 не индексировали ЗП и получить прибавку очень сложно) хочется максимизировать прибавку, а не просто найти первое же место, где платят на 5-10% больше (к вопросу про «просто скажи сумму»).

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

Я же говорил, надо выбирать компании, которым нужен сильный специалист, такой как Вы. Если Вы, например, разрабатываете высоконагруженные сайты, Вы же не пойдете в CMS странички верстать, а в такой конторе не будут готовы платить много, потому что для их нужд Вы — переквалифицированы (overqualified). А если компания полгода не может закрыть вакансию, потому что все кандидаты отказываются работать за такие деньги, хочешь-не хочешь, а задумаешься, не поднять ли ЗП.
Вы же не пойдете в CMS странички верстать, а в такой конторе не будут готовы платить много, потому что для их нужд Вы — переквалифицированы (overqualified).

Чуть ли не самые частые предложения ко мне: "у нас несколько лет работает сайт на коробочной CMS, но с ней мы в тупик зашли — надо как-то допилить"

можно прийти логически к тому, что для этого нужен контроффер.

Нужен? Нет.
Влияет? Да.

Но если я продаю арбуз, и мне предлагают купить его за 20 рублей, а я отвечаю «мне уже за 30 предложили, но за 35 отдам» это сильнее позиция чем, «нет, 20 мало, давай 30».

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

Я не знаю, мне нужно ещё больше упростить ситуацию или вам азы обсуждения сделок стали понятнее?

Аддед: а ещё знаете какой есть вид «контроффера» при обсуждении оффера? Называется «да я сейчас больше получаю».
Это ничем не отличается «от у меня оффер от другой компании на суммы выше предложенной вами».
И если вы думаете что человек с ЗП в 300 и человек с ЗП в 200 имеют одинаковую силу в обсуждениях (при отсутствии других офферов) при получении оффера на 300 и попытке попросить 350-400, то вы более чем заблуждаетесь.
Ну, как бы, там тоже не дураки сидят. Когда Вы говорите какие-то цифры, которые, якобы предлагают в других конторах, все рекрутеры/нанимающие менеджеры оценивают правдивость, исходя из понимания, могут там столько платить или нет. Если Вы действительно сидите в конторе, про которую извне известно, что могут платить много, и на собеседовании Вы себя показываете как хороший специалист, то Вам могут и поверить. А если Вы пришли из какой-то непонятной конторы в 5 человек и/или себя плохо на собеседовании показали, Вам не поверят и отпустят обратно получать баснословные деньжищи.
Почему якобы? Я же не стану врать, и в принципе в такой ситуации могу показать пруф. Конечно можно сказать что письмо с оффером и все переписки до этого я подделал, но не будем совсем уж ударяться в паранойю.

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

Это всё самой собой с учётом того что я веду себя вежливо.
Кстати, по поводу из широких штанин офферы доставать: многие конторы (по крайней мере в США) сразу спрашивают, собеседуетесь ли Вы с другими конторами и на какой стадии переговоры. Делается это для того, чтобы понять, надо ли ускорять процесс интервью (который может и до нескольких месяцев растянуться), чтобы не получилось так, что в других конторах Вам уже дадут офферы и надо будет срочно выбирать. Потому что ответ на оффер часто ожидают фиксированное время, а принять оффер, а потом отказаться, считается дурным тоном. А так для Вас это хороший способ менеджить ожидания («у меня, возможно, будут офферы вот от таких компаний»), в плане «с какими компаниями придется конкурировать за Вас».
Я-то как раз в курсе о таком. И о том что рекрутеры там тебя по два раза спрашивают «Есть ли офферы? Нужно ли нам поторопиться? Нет? Если появятся обязательно пишите».
И на блайнде и на других ресурсах, где можно FAANG и другие крупные компании обсудить, что же там является главным советом в обсуждении компенсации?
«Get competing offers».
А если у тебя их нету, то процесс обсуждения становится тяжелее.

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

Да рассматривать-то каждый может что угодно. Зачем сообщать детали каждому встречному, если они не просят?

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

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

Своего рода доказательства того, что «вооон я скока стою»? А кому это доказательство нужно и зачем? Ну и с-но сам факт необходимости такого «доказательства» как раз и есть холопство какое-то.

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

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

Причём почему-то когда «барин» не предлагает сразу максимум что они могут позволить себе заплатить, инфантилизмом вы видимо это не считаете. Одни значит вправе тянуть цифру вниз, а другие вверх нет.

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

Торговаться нормально, но вот бряцать другими офферами непонятно зачем. Этот оффер сделан неадекватным работодателем, не знающим сколько мне заплатит рынок? Так с ним проблемы постоянно будут — для повышения зарплаты надо будет опять искать другие офферы. А вот если в ответ на "мы можем предложить вам Х", говоришь "я соглашусь на X+10%" и тебе говорят "ок", то вероятность что через годик в ответ на "я теперь хочу X+10%+12,1%" услышишь "ок" выше.

Что такое «неадекватный работодатель»? Ну кроме тех в которых вот тот товарищ со сдвигом работает?

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

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

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

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

Но если вы имеете ввиду что это типа будет политикой в хорошем смысле — «приноси оффер, и мы его замэтчим», то есть компании действующие в открытую именно так. Netflix например. Если тебя хотят сохранить, то ты приносишь оффер — не средний не по рынку, не +10%, а то что лично ты можешь на рынке ухватить. И в этом нет ничего плохого.
И с такой схемой обычно будет не +10%, а гораздо больше, потому что люди редко уходят на офферы ниже +20%, а рынок широкий и найти хоть кого-то кто платит много можно.

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

А кто вам мешает торговаться не имея оффера? оО


Спросите, может ли компания А заматчить офер компании Б/предложить какие-то дополнительные бенефиты?"

Ну просто говорите в А: "я хочу Х денег". Никакого оффера в Б для этого не требуется. И либо А соглашается, либо тогда уже ищите другую компанию.

Без оффера Вы можете просто уйти. Обычно компании не поднимают офферы на пустом месте. Скажете «хочу больше», чаще всего получите ответ «мы считаем, это адекватное и конкурентное предложение». Конечно, вы можете с порога заявить свой ценник и или с Вами даже разговаривать дальше не будут, или дадут ровно столько, сколько Вы попросили, и Вы, возможно, проиграете, если компания могла предложить Вам больше. Поэтому, фиксированную сумму считается невыгодно говорить. Говорят, обычно, диапазон. Далее, если Ваш диапазон пересекается с вилкой вакансии компании, они начнут процесс собеседования, а имея другие офферы можно подобраться к верхнему пределу вилки компании.

А вот «у меня тут предложение от конкурентов» — это сразу безвозвратное «до свидания». В хороших местах крайне редко бывают востребованы люди с таким менталитетом.

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

Я в курсе, как компании ищут хороших кандидатов. Мы собрали лучшую команду в нашем стеке в двухмиллионнике.


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


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

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

Поэтому, как я говорил ранее, надо иметь несколько офферов.

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


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

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

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

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

Несомненно. У нас и не отказывают, более того, ежегодно индексируют з/п на 10%, и это прописано в договоре. Но уж подавно никто не увольняет сотрудников за мыслепреступления и любые речи. А при чем тут это?


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

У вас увольняют за мыслепреступление, просто вам не докладывают.

Чемодан — Андалусия — Апельсины.