Comments 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м году как-то странно, а чтобы преобразовать инфиксную форму в постфиксную — вам придётся алгоритм сортировочной станции использовать. Ну и зачем в таком случае ОПЗ?
Что же в этом хорошего?
Вот тут было весело.
Задачки были несколько посложнее. Ну и вторая из них выглядит как выносящая мозг любому Java-разработчику в силу своей специфики.
Один раз, в глубокой молодости, интервью случилось аккурат в приступе «реактивной гениальности» и к несчастью прошло успешно. Первая неделя была крайне интересной — каждый день 8 часов тупого пяления в монитор и 3 строчками кода, потом приступ кодинга вечером в домашнее время и притащенное утром решение задачи над которым контора уже 3 дня билась. Через неделю увольнение, после беседы с директором, который это объяснение выслушал с недоверчивым прищуром и явным подозрением, что у нас дома спрятана какая-то команда индусов, а собес был просто куплен по знакомству.
Теперь принцип простой. Только проектный фриланс. К любой задаче даже 1 день сроком прибавляется неделя на выполнение. Никакие задачи не показываются в состоянии "тут будет дом, а то что сейчас забор после 50% срока, это норм" Со студиями спускающими нам проекты как «неграм» очень даже работает (правда портфолио не пополняет), с конечными клиентами это уже сложнее (обычно хотят видеть плавный постоянный прогресс, а не авралы с простоями), а вот в команду с таким подходом без шансов — незакоммитил пару килобайт за сутки — весь следующий день будешь оправдываться перед тимлидом вместо работы — это сильно расстраивает на самом деле.
К любой задаче даже 1 день сроком прибавляется неделя на выполнение.?=) Никогда толком фрилансом не занимался, но как не попадется какая-нибудь «подработка», то вечно с какими-то горящими-сумасшедшими сроками. Не люблю торопиться, поэтому никогда не беру, поэтому нет дополнительных денег (а хотелось бы=) ).
незакоммитил пару килобайт за сутки — весь следующий день будешь оправдываться перед тимлидом вместо работы — это сильно расстраивает на самом деле.— очень не очень, согласен!
?=) Никогда толком фрилансом не занимался, но как не попадется какая-нибудь «подработка», то вечно с какими-то горящими-сумасшедшими сроками. Не люблю торопиться, поэтому никогда не беру, поэтому нет дополнительных денег (а хотелось бы=) ).Зачастую сводится к цене.
Высокий ценник — будут лишь авральные заказы по типу «надо было вчера», т.к. иначе за что платить при прочих равных? Будет низкий ценник — будет из чего выбирать, в т.ч. и заказы вида «мне не горит, главное что бы цена приятная» будут.
Тут просто вопрос насколько Вы готовы снижать цену ради приятности заказа. Допустим приходит к Вам заказчик и кидает на стол штукарь баксов «что бы завтра все было готово», а Вы так задумчиво три сотни оттуда тянете, остальное ему обратно двигаете и говорите «а что насчет следующей недели»? И зачастую спешка внезапно куда-то пропадает.
.
Вторая частая ситуация — многим нужна не столько срочность, сколько гарантированность сроков. А срочность они просят просто потому, что хотят иметь время найти кого-то еще, если тут продинамят. В таких случаях можно обсудить увеличение сроков в обмен на повышенные финансовые гарантии со своей стороны. Типа — а давайте я сделаю это за неделю, а не за день, но если пропущу сроки, то не Вы мне косарь отвалите, а я Вам в качестве неустойки. Достаточно типичный вариант со студиями, кстати, которые сами перед заказчиком отвечают.
Очень кстати прикольное предложение про "за три сотни и никуда не торопимся", чем-то оно мне нравится.
Напоминает анекдот про давно прошедшие времена в судах России:
К судье приходит секретарь и говорит: «Ваша честь, у нас проблема. Ответчик дает 130 тыс., а истец дает 100 тыс. Что будем делать?» Судья говорит: «Верните 30 тыс. ответчику, и будем решать дело по закону».
И второе предложение хорошо смотрится. Блин. Почему такая практика нигде не прижилась?? Что для этого нужно?
Почему такая практика нигде не прижилась?? Что для этого нужно?Не так много людей кому это подходит.
Посмотрите с другой стороны, в первом случае исполнитель получает меньшую оплату за то же самое рабочее время (отработает-то столько же), во втором случае берет на себя риск попасть на штраф (например заболев). Выгода же сводится к получению бОльшего времени на выполнение заказа.
Из тех кому это подходит — часть предпочитает делать свои пет-проекты, которые являются логичным продолжением идеи «делаю в свободные сроки», при этом риски и давление сводятся к нулю, но какая-то денюжка все же может капать.
Странный директор — если проблемы решаются, какая разница каким образом это делается?Paskin «самураю не важна цель, ему важен путь» как-то так. В крупных фирмах предсказуемость и планируемость на первом месте, т.к. иначе невозможно управлять большими процессами. Представьте себе что у Вас колесо авто то 1 оборот в секунду делает, то 10, но в среднем выдает те самые нужные 5 — надо оно Вам в автомобиле?:)
К нам как-то пришла на интервью девушка, прямо сказавшая что руками она тестировать умеет, а автоматические тесты только начала изучать — но у нее муж крутой спец в этом деле и будет ей советовать если мы ее возьмем.
То ли девушка поскромничала, то ли муж действительно оказался крутым спецом — но тестов она написала целую кучу и вполне по делу.
Некоторые действительно не могут эффективно писать по TDD. Особенно если вообще тесты никогда не писали.
Достаточно одного! но крутого действующего проекта, которым можно хлестать по фейсу любого интервьюера.
Одного — но действительно крутого — проекта — вполне достаточно для того, чтобы вообще не связываться с интервьюерами, а разговаривать сразу с CTO за ланчем.
Тесты не имеют отношения к алгоритмам. Рассказ про то как тесты мешали написать интепретатор смахивает на сказочку.
Ну в случае ТДД это действительно так — в рамках ТДД вы не можете сразу начать писать итоговый алгоритм, даже если его знаете. Вам надо для каждого теста писать недоалгоритм, а потом с нуля его переписывать под новый тест.
Это не то чтобы сложно, но нормального программиста просто от такого будет воротить и придется преодолевать себя.
Причём, емнип, по канону сперва код должен сперва быть такой, чтоб тест падал.
нормального программиста просто от такого будет воротить и придется преодолевать себя
Какой-то у вас неправильный нормальный программист :) для задач уровня парсера выражений TDD очень даже удобен, там тесты нужны уровня
expect(calculate("2+2*2"), equals(6));
А тестирование некоторых вещей — долго и дорого, по сравнению со стоимостью/сроками решаемой бизнес задачи.
Парсер выражений должен выдать на выходе не 6, а AST: Add(Const(2), Mul(Const(2), Const(2))).
Два таких дерева сравнить — уже нетривиальная задача (придётся добавлять во все классы метод Equals исключительно для нужд тестирования). А как начинать писать код с тестов, а не с классов для представления AST — для меня и вовсе загадка...
придётся добавлять
Или не придется
А как начинать писать код с тестов
Можно написать некомпилирующийся тест
Const(2), потом Add(Const(2),Const(2)). Не знаю, как там в строгом понимании TDD, но я бы делал так. Как минимум, api класса должно какое-то быть для теста. Скажем, та же функция createAst(String input) => throw Error();. Потом тест на неё, сначала expect(createAst("2"), equals(Const(2));, упадёт по-любому, потом можно к минимальной реализации приступать. придётся добавлять во все классы метод Equals исключительно для нужд тестирования
В нормальных языках уже завезли data-классы.
Ну в случае ТДД это действительно так — в рамках ТДД вы не можете сразу начать писать итоговый алгоритм, даже если его знаете. Вам надо для каждого теста писать недоалгоритм, а потом с нуля его переписывать под новый тест.
И если не секрет, то в чем здесь проблема? В .net я обычно пишу либо интерфейс без реализации, на него тест, и далее реализация. Либо метод с NotImplementedException, на него тест, далее реализация.
Это не то чтобы сложно, но нормального программиста просто от такого будет воротить и придется преодолевать себя.
Чушь и не правомерное обобщение=)
TDD удобно если умеешь, если есть на него время, если проект в долгую и если не заставляют. Да «если» тут много.
И если не секрет, то в чем здесь проблема?
Требуется больше итераций и кода на выброс, чем если сначала написать все тесты потом весь код или наоборот.
Требуется больше итераций и кода на выброс, чем если сначала написать все тесты потом весь код или наоборот.
По моему опыту это не так.
Все тесты сразу написать просто невозможно, ибо нет интерфейса\класса который тестируется, а в его отсутствие код тупо не скомпилится.
Написать весь код, а потом написать все тесты, так себе затея.
Во-первых, тоже не всегда можно без рефакторинга, так как программист в порыве страсти может написать что-то что в принципе не тестируется, либо тестируется сложно, например статический коннекшин к бд.
Во вторых, натягивание тестов на код, внезапно может потребовать рефакторинга, так как программист не учел что-то с точки зрения использования кода, и написал код, неудобный для использования, а рефакторить
TDD же в первую очередь удобно тем, что тест — это потребитель кода, а когда сперва пишется потребитель, хочешь не хочешь, а думаешь над удобным использованием, и только после над удобной реализацией. Поэтому рефакторинга меньше, так как он происходит на ранней стадии.
Все тесты сразу написать просто невозможно, ибо нет интерфейса\класса который тестируется, а в его отсутствие код тупо не скомпилится.
Для этого достаточно интерфейса.
Во-первых, тоже не всегда можно без рефакторинга, так как программист в порыве страсти может написать что-то что в принципе не тестируется, либо тестируется сложно, например статический коннекшин к бд.
Мы рассматриваем ситуацию когда алгоритм известен. Например вычисление выражений с приоритетами.
И если не секрет, то в чем здесь проблема? В .net я обычно пишу либо интерфейс без реализации, на него тест, и далее реализация. Либо метод с NotImplementedException, на него тест, далее реализация.
Здесь скорее отсылка к тому, что на первый простейший тест у Вас реализация будет простая — вернуть константу. Потом Вы реализуете какой-нибудь наколеночный парсинг выражений, потом будете добавлять-добавлять и в конечном итоге упретесь в то, что, чтобы это работало быстро, надо все выкинуть и переписать на каком-нибудь парсер-генераторе/модной парсинг либе. И получится, что в один шаг надо большую часть реализации переделать/выбросить все ранее написанное. Или, например, реализация более-менее понятна, известный алгоритм с небольшими модификациями. И тут TDD, и нельзя просто взять и написать алгоритм. Надо ментально нарезать его на какие-то мелкие шаги, которые бы работали инкрементально, но чтобы не писать лишнего для отдельного шага. Потому что по TDD нельзя писать лишний код и нельзя писать тесты, которые уже работают (не сломаны).
Как раз таки наоборот, чтобы быстро работало скорее всего нужно свое наколеночное решение. На парсер-генератора/модной парсинг либе это чтобы быстро написать, а не чтобы быстро работало.
На парсер-генератора/модной парсинг либе это чтобы быстро написать, а не чтобы быстро работало.
Не согласен. Допустим, вы транслируете выражение в LLVM байткод, а LLVM генератор выдает Вам машинный код. И вот оно уже работает быстро.
генерация llvm байткода как минимум накладывает ограничения на среду исполнения программы, он там должен быть в этой среде, llvm генератор. Так можно и просто программу на С сгенерить и скормить её компилятору, и вообще не париться с парсерами и стэковыми машинами. Это как раз скорее всего не то чего хотели от автора интервьюеры.
получится, что в один шаг надо большую часть реализации переделать/выбросить все ранее написанное.
Программирование, и даже TDD — это ведь не культ (обычно), необязательно неуклонно следовать непонятно кем описанным условностям. Можно, если в голове уже есть представление, что делать, тесты писать более крупными мазками, не начиная с банальщины.
TDD — это ведь не культ (обычно)
Разве?
Я ведь уточнил, что "обычно" :) И да, часто для дискуссии нужно чуть больше, чем одно слово и минус.
Я ведь уточнил, что "обычно" :)
Без "обычно". Тут я вижу есть определенное непонимание — некоторые под ТДД подразумевают просто "пишу код и тесты параллельно, как мне будет удобно". Но нет, это не тдд, это просто человек как-то пишет тесты. ТДД же строго регламентирует как и когда пишутся тесты/продакшн код, из этого регламента тдд и состоит. И если вы базовые принципы тдд нарушаете, то это уже не тдд.
Ну в самом деле, если вы, когда это удобно и разумно, пишете сперва код, а потом тесты, то в каком месте это будет test driven development?
И если вы базовые принципы тдд нарушаете, то это уже не тдд.
Когда человек начинает использовать TDD, ему ведь не дают подписать контракт, запрещающий любые другие подходы? Можно вполне быть разумным человеком и применять то, что удобнее в конкретной ситуации. Также как если человек придерживается в основном ООП, а потом где-то тулит Util- класс или передаёт лямбду в качестве аргумента, (обычно) к нему не прибегают ООП-апологеты с палками.
Мелкость шагов по TDD определяется разработчиком.
И если не секрет, то в чем здесь проблема?
Проблема в том, что вам надо написать код, который вы совершенно точно целиком выкинете через 5 минут. И так несколько раз.
Еще проблема ТДД — программист не имеет права сразу в коде обрабатывать краевые случаи. Сперва вы должны написать алгоритм без обработки каких-либо краевых случаев, а потом добавлять краевые случаи по одному с соответствующими тестами. Засада тут в том, что в случае сложного алгоритма можно про эти краевые случаи просто забыть — они пока алгоритм пишешь очевидны, а потом уже нет. В итоге возникает парадоксальная ситуация, когда код написанный в лоб в один присест без всяких тестов оказывается более надежен, чем написанный по ТДД со 100% покрытием.
Проблема в том, что вам надо написать код, который вы совершенно точно целиком выкинете через 5 минут. И так несколько раз.
Эм, с чего бы? Вероятно я вас не понимаю, вы не могли бы привести пример, какие «недоалгоритмы» понадобятся, чтобы написать тесты на калькулятор?
Еще проблема ТДД — программист не имеет права сразу в коде обрабатывать краевые случаи. Сперва вы должны написать алгоритм без обработки каких-либо краевых случаев, а потом добавлять краевые случаи по одному с соответствующими тестами.
Эм? А эту догму вы откуда достали?
В итоге возникает парадоксальная ситуация, когда код написанный в лоб в один присест без всяких тестов оказывается более надежен, чем написанный по ТДД со 100% покрытием.
Довольно бездоказательное утверждение. К слову 100% покрытие — это такой же не здоровый фанатизм, как и полное отсутствие тестов.
Эм? А эту догму вы откуда достали?
https://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html
- You must write a failing test before you write any production code.
- You must not write more of a test than is sufficient to fail, or fail to compile.
- You must not write more production code than is sufficient to make the currently failing test pass.
Эм, с чего бы? Вероятно я вас не понимаю, вы не могли бы привести пример, какие «недоалгоритмы» понадобятся, чтобы написать тесты на калькулятор?
Ну, хотя бы, что на первый тест 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 элементов, а потом проведете соответствующее изменение кода.
Программист имеет право сразу написать тесты на краевые случаи, если они ему очевидны с самого начала, типа факториал нуля равен единице
Программист имеет право сразу написать тесты на краевые случаи
Программист имеет право вообще не писать тесты, например. Только это будет уже не ТДД :)
Если в команде программист обязан работать по TDD, то не писать их он права не имеет. TDD реглментирует, что тесты должны быть написаны и должны быть написаны до кода. Но на какой кусок задачи, в частности на единичные краевые случаи или на самую большую область эквивалентности, писать первый тест программист обычно имеет право выбирать сам. Подход "сначала тесты на краевые случаи" вполне имеет право на жизнь. Мало того, пожалуй, он в среднем увеличивает качество решения задачи.
Несколько месяцев назад устраивался на работу и на паре собеседований просили лайвкодинг. Блин, вроде тоже задачи не особо сложные, но какой же это был стресс. Я хоть и прошел, но покрылся семью потами в процессе.
Чем писание кода на доске не лайвкодинг?! В период пандемии теперь все интервью — лайв кодинг: пишете в каком-нибудь coderpad, там же и запускаете. Решение задачек на доске/блокноте — это повсеместные практики интервью для программистов. И да, к этому надо готовиться, тренироваться. Есть задачи на знание алгоритмов и структур данных, есть — на реализацию (как у автора).
Да и про то, что это весьма распростанено, тоже понятно.
Я говорил только, что реально стрессирует. Конечно если много раз выступить таким образом, стресс должен уйти.
И да, к этому надо готовиться, тренироваться.
Единственно непонятно, каким боком этот скилл связан с реальной работой.
Вот вот, это просто отдельная спортивная дисциплина, хуже того, навыки лайфкодинга наиболее свежи сразу после универ, а чём больше работаешь, тем они хуже, потому что не используются.
Лайвкодинг — он разновидность кодинга. Так что он похож на то что делается на работе.
А если бы фишки яндекс.браузера были заметны, его бы не пришлось ставить из каждого утюга с оплатой за инсталл. Так-то и в браузере который я делаю «фишки» есть.
Уникальный продукт это который вы придумали и выпустили в мир первые, например?
Веб-поиск, например? Если, конечно, не считать Yahoo! Directory — поисковой системой, или Lycos — хоть сколько-нибудь конкурентноспособным. Или это недостаточно революционно для вас? Или вы думаете, что Гугл старше? Или что?
Но вы не привели пример :)
В вашей терминологии есть предвзятость: подразумевается, что «копия» это что-то заведомое более плохое, чем «оригинал». Понятно, что наверно есть мелкие ребята, которые просто копированием занимаются, но в реальности и у крупных ребят обычно похожие продукты возникают вокруг похожих идей, и заменить один на другой не всегда просто. Например, Netflix и Amazon Prime. На одном есть сериалы «Загадочные события», на другом «Пацаны». Но я не хочу смотреть «Пацанов». Имеет ли в этом случае значение, кто из них появился раньше? А если нет, то в чем физический смысл довода про «неуникальность»? Вы думаете, у ребят из Амазона техническая сложность задач ниже? Конечно же, нет. Или вот Альтависта и Гугл. Правда ли тут важно кто «копия»? Повлияло ли это на качество продукта, успех в будущем или сложность задач?
Про браузер — это же классическое «если продукт хороший, то ему не нужна реклама». На самом деле даже хорошему хлебушку просто так на витрину супермаркета не попасть. Можете попробовать найти хоть один популярный браузер без дистрибуции и рекламы в свои лучшие годы. Не получится. В конце концов, установить ведь мало — имеет значение только реальное использование. В общем, для успеха надо уметь делать и то, и другое.
Что касается технологических фишек, то можете посмотреть в истории моих публикаций некоторые из них. Готов взглянуть и на ваши. Профессиональный интерес: раньше и достаточное долгое время был сфокусирован на браузерных технологиях.
Да, ты такой не один.
Но это все решается "натаскиванием", как и алгоритмические вопросы, как и литкод задачи. Тоже люблю когда дают тестовое на дом, и ты спокойно делаешь, не думая что ты выглядишь тупым.
Кстати ещё раньше мода была на тесты на знание языка — вот это вообще жесть.
Это человеческая психология.
Мы существа социальные, живущие в ранговой системе, и желание самоутвердиться в доминировании в нас неисправимо.
И зачастую это желание выпирает настолько явно, как в вашей ситуации у вас тестирующих людей.
Объективно они не настолько выше вас профессиональным классом, насколько они вам это показали.
Понятно, что это не приятно.
Понятно, что следует проявлять уважение к коллегам и так не делать.
Понятно, что эта ситуация не связана никак с конечной целью собеседования.
Тем не менее примите как данность — оно встречается.
Но при этом ничего не говорит ни о фирме.
Ни о потенциальных коллегах.
Будучи принятыми в коллектив и уже будучи с ними в равном положении вы могли узнать насколько они приятные люди.
Причины этого явления хорошо были показаны, например, в тюремном эксперименте в Стенфорде:
Если людям предоставить ненаказуемую возможность поиздеваться, то окажется, что большая часть из нас — сущее говно.
И только в ситуациях, когда можно, хотя бы теоретически, получить ответную защитную реакцию угнетаемых — тогда нападок на вас не будет.
В обычных ситуациях — мы примерно равны по возможности дать отпор, поэтому в обычной жизни такой неприятной ситуации вам не встречалось.
habr.com/ru/post/414973
Причины этого явления хорошо были показаны, например, в тюремном эксперименте в Стенфорде:
… про проблемы которого в той же википедии есть ссылки, в англицкой подробней чем русской.
Участники эксперимента играли в тюрьму. Некоторые прямо намеренно отыгрывали роль как они её видели: "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"."
То есть, они попросту делали что а) входило в роль; б) было прямо запрошено заказчиком.
Так сделанные из результата вывод эксперимента: "Если людям предоставить ненаказуемую возможность поиздеваться, то окажется, что большая часть из нас — сущее говно" это же не отменяет ровно никак.
Странная логика. Вам показывают проблемы дизайна исследования, а вы говорите, что это не отменяет его выводов.
Странная логика. Вам показывают проблемы дизайна исследования, а вы говорите, что это не отменяет его выводов.
А в чем конкретно проблемы дизайна? Т.е., да, люди делали то, что:
а) входило в роль; б) было прямо запрошено заказчиком.
Это входит в изначальную постановку эксперимента в явном виде, и, конечно, эти факторы всегда учитывались в выводах.
Непонятно, почему вы решили, что кто-то говорил будто "они сами" — эксперимент как раз и должен был в том числе продемонстрировать влияние ролевой модели и авторитета. Людям сказали сыграть отбитых ублюдков — и они с радостью начали играть отбитых ублюдков, искренне получая от этого удовольствия и не обращая никакого внимания на то, что, вообще-то, приносят другим людям вполне себе реальные страдания.
Разве охранники сказали "с нас хватит, мы не будем заниматься этим дерьмом"? Нет. Не смотря на то, что это были вроде бы обычные нормальные люди, не склонные к садизму.
Это меняет вывод эксперимента на «люди склонны следовать за авторитетом, даже когда их действия выходят далеко за пределы здравого смысла и собственной или чужой безопасности».
Все верно. Ровно это (в том числе) в эксперименте и исследовалось.
То есть они творили ужасное не потому, что едва ли не каждый из нас — сущее говно, а потому что авторитет приказал вести себя как говно.
Ноуп, им никто не приказывал, только предлагал. В стенфордском эксперименте еще исследовалось влияние ролевой модели.
Т.е. в эксперименте Милгрэма подопытный знает, что поступает неправильно, но делает это. В стенфордском эксперименте подопытные поступали так как поступали легко и без каких-либо проблем — т.к. это соответствовало принятой ими ролевой модели.
"авторитет" в данном случае не вынуждал их на конкретные действия — он вынуждал их принять определенную ролевую модель. А дальше уже все сами, сами — с улыбкой на лице и получая удовольствие от процесса.
Ноуп, им никто не приказывал, только предлагал.
Извините, но нет.
Участники эксперимента пытались покинуть эксперимент, но им в этом было отказано (для того, чтобы они более натурально чувствовали себя в тюрьме). Один из участников симулировал сперва физическое, а потом психическое недомогание, чтобы выйти из эксперимента. Такие условия ну совсем никак нельзя назвать «им просто предлагали».
«авторитет» в данном случае не вынуждал их на конкретные действия — он вынуждал их принять определенную ролевую модель.
Авторитет их инструктировал на конкретные действия по достижению конкретной цели. Нам нужно сделать то и это, говорил авторитет, и для этого у нас есть такие и такие методы. И все методы и действия не были придуманы заключёнными, они были придуманы организаторами эксперимента.
В итоге, одних не выпускали, а других подробно инструктировали, что им следует делать. Это всё крайне отличается от концепции «им просто разрешили, а они радостно сами-сами».
Стэнфордский эксперимент пытались реплицировать, но без того, чтобы одних удерживать, а других инструктировать он не воспроизводится.
Участники эксперимента пытались покинуть эксперимент, но им в этом было отказано (для того, чтобы они более натурально чувствовали себя в тюрьме).
Так это "заключенных" не выпускали, т.е. вы сейчас на мою мельницу воду льете — у людей настолько сдвинулось восприятие реальности, что они действительно начали считать, что это нормально кого-то не выпускать!
Мы же обсуждаем конкретно поведение "вертухаев" — их никто ни к чему не принуждал. Им просто предложили "поиграть в ублюдков" — и они с радостью начали играть в эту игру, забив полностью на тот факт, что, вообще-то, "заключенным" они доставляют вполне реальные страдания. Они могли этого ничего не делать, их никто не заставлял.
Авторитет их инструктировал на конкретные действия по достижению конкретной цели. Нам нужно сделать то и это, говорил авторитет, и для этого у нас есть такие и такие методы. И все методы и действия не были придуманы заключёнными, они были придуманы организаторами эксперимента.
Нет, этого не было.
В итоге, одних не выпускали, а других подробно инструктировали, что им следует делать. Это всё крайне отличается от концепции «им просто разрешили, а они радостно сами-сами».
Нет, этого не было.
Была сформулирована определенная роль: сыграть злобных вертухаев-ублюдков, собственно:
Создайте у заключенных чувство тоски, чувство страха, ощущение произвола и того, что их жизнь полностью контролируется нами, системой, вами, мной, и у них нет никакого личного пространства… Мы будем различными способами лишать их индивидуальности. Все это в совокупности создаст у них чувство бессилия. Значит, в этой ситуации у нас будет вся власть, а у них — никакой.
А дальше — уже полная самодеятельность. Ни к каким конкретным действиям "вертухаев" никто не принуждал.
Самое забавное тут вообще то, что эксперимент-то изначально состоял в изучении поведения заключенных. Никто не ожидал, что "вертухаи" начнут превращаться в реальных садистов уже буквально через несколько дней.
Стэнфордский эксперимент пытались реплицировать, но без того, чтобы одних удерживать, а других инструктировать он не воспроизводится.
Эм, так стенфордский эксперимент в явном виде включает две ролевые модели — "заключенных" и "вертухаев" и изучает влияние этих моделей на самоопределение и личность. Естественно, что эксперимент без ключевых условий повторить нельзя — если вы исключаете ролевые модели, то вам нечего и изучать.
По факту, вывод из эксперимента весьма очевиден: принимая определенную ролевую модель, человек со временем перестает играть и начинает быть. В данном случае — люди буквально через несколько дней перестали считать себя играющими в "заключенных" и "вертухаев" — они начали считать себя этими заключенными и вертухаями.
С чем тут можно спорить — непонятно.
Так это "заключенных" не выпускали, т.е. вы сейчас на мою мельницу воду льете — у людей настолько сдвинулось восприятие реальности, что они действительно начали считать, что это нормально кого-то не выпускать!
А Вы перечитайте кто конкретно не выпускал. Сам же руководитель лично и.
Никто не ожидал, что "вертухаи" начнут превращаться в реальных садистов уже буквально через несколько дней.
…
С чем тут можно спорить — непонятно.
С тем, что этот результат был запрошен заранее и желаемое поведение было озвучено перед экспериментом.
А Вы перечитайте кто конкретно не выпускал. Сам же руководитель лично и.
При поддержке остальных "работников тюрьмы", ага.
С тем, что этот результат был запрошен заранее и желаемое поведение было озвучено перед экспериментом.
Эм, так не был. Людям предложили поиграть в ублюдков — а они стали ублюдками.
Понимаете разницу? Я могу делать вид, что бью вас дубинкой, делая это "по-нарошку", а могу просто бить дубинкой. Если не вы, то ваши почки разницу ощутят, поверьте. При этом никаких угрызений совести я испытывать не станут — ведь это всего лишь игра, без обид. Это не я жестокий человек, это у меня просто роль такая была — от*издить вас дубинкой.
Вы немного переворачиваете ситуация — это не стэнфордский эксперимент является частным случаев эксперимента Милгрэма, а наоборот — эксперимент Милгрэма является частным случаем стэнфордского.
Ещё раз, по буквам: ожидаемый результат эксперимента и ожидаемое поведение было донесено до "охранников" заранее, до начала эксперимента. А не "они сами стали такими в ходе эксперимента", как про него любят рассказывать. Не "сами в ходе", а "как задали заранее — так и вели"
Ещё раз, по буквам: ожидаемый результат эксперимента и ожидаемое поведение было донесено до "охранников" заранее, до начала эксперимента.
Ну да все верно. Установление ролевой модели — это часть эксперимента.
А не "они сами стали такими в ходе эксперимента"
А вот это неверно. Ожидалось что они будут играть роль а не "сами такими станут". Поведение охранников вообще не было темой эксперимента, напоминаю. Эксперимент был направлен на изучение узников.
Не "сами в ходе", а "как задали заранее — так и вели"
Ну так в том и результат. Никто не ожидал, что люди могут себя так вести, если им предложат.
Не будут заставлять, давить автоиртетом и т.п. — просто предложат поиграть в злых охранников — даже без уточнений того, что конкретно делать. Конкретные действия охранники уже сами придумали, выводя из своей роли. Сравните с экспериментом Милгрэма, где подопытному прямо указывают на конкретные действия и буквально убеждают их выполнять, выдавая вполне четкие оправдания ("все будет в порядке", "я беру на себя ответственность, не волнуйтесь" и т.п.) — в стэнфордском эксперименте ничего такого не было и близко.
Это меняет вывод эксперимента на «люди склонны следовать за авторитетом, даже когда их действия выходят далеко за пределы здравого смысла и собственной или чужой безопасности».
А на эту тему уже есть эксперимент Милгрэма и другие именно о следовании за авторитетом, и как раз таки это свойственно людям в полной мере, причём следование как авторитету личности, так и авторитету группы, уж такие мы социальные существа, «все побежали и я побежал» и прочие «мне сказали, я сделал».
То есть они творили ужасное не потому, что едва ли не каждый из нас — сущее говно, а потому что авторитет приказал вести себя как говно.
А удовольствие или неудовольствие при этом то такое, адаптивные механизмы психики, ну как драйв солдата в первой шеренге, который бежит на верную смерть, просто хорошо играя свою роль, а не потому, что он в душе самоубийца и всегда мечтал.
С собеседованием тоже самое может быть: сказали программисту провести его в первый раз в жизни и он вспоминает такие посты на Хабре и начинает отыгрывать роль крутого собеседующего.
Повторить эксперимент всё-равно никто не решился, кроме BBC, но это был журналистский эксперимент с участием учёных и другими условиями.
Эксперимент Милгрэма, кстати, поляки воспроизвели. https://journals.sagepub.com/doi/10.1177/1948550617693060
Нет в человеческой психике какого-то биологически обусловленного стремления доминировать за счёт унижения других. А вот потребность в уважении коллективом вполне присутствует.
А.С. Макаренко и Э.В. Ильенков давно научно опровергли туфту, что люди говно по своей природе.
А.С. Макаренко и Э.В. Ильенков давно научно опровергли туфту, что люди говно по своей природе.
А можно ссылку? А то по этим фамилиям гуглится только всякие методики воспитания. А раз надо воспитывать, значат биологические обусловленое стремление доминировать всё-таки существует. Правда унижать других — это лишь один из способов(ИМХО самый непродуктивный). Но это я больше на интуиции и логике на малом количестве субъективных наблюдениях.
Макаренко брал с улицы полных отморозков, помещал в человеческие условия, и они внезапно становились нормальными людьми, причём по моральным качествам они становились даже лучше нас с вами, ибо живём мы в скотских условиях, если принимать во внимание взаимодействие с обществом, а не ограничиваться уютной коробочкой, в которой мы отдыхаем от трудовой деятельности.
А Ильенков доказал, что человек является продуктом общественной практики, а не чем-то отдельным. Это подтверждается Загорским экспериментом, где сделали людьми слепоглухонемых детей, которые в обычных условиях стали бы почти «овощами». Ну и не забываем про реальных маугли, которые во всём вели себя, как животные, с которыми выросли.
Будучи принятыми в коллектив и уже будучи с ними в равном положении вы могли узнать насколько они приятные люди.
Эхм… точно? Или они и тут найдут варианты "реализоваться"?
Я 5 недель уже сижу без работы. Опыт разработки лет 8-9. Каждое техническое собеседование как колоноскопия. С лайвкодингом никогда не сталкивался и, надеюсь, не столкнусь. Это же вообще ад.
В итоге, после примерно десятка собеседований, решил пока забить на трудоустройство. К тому же меня нашли пара проектов, один из которых от иностранной компании с соответствующей оплатой. Занятость есть, можно пока забить о собеседованиях.
Приходим домой после собеседования и сразу выписываем какие были вопросы, как мы на них отвечали и какая была реакция интервьюеров. Бывает, что на некоторые вопросы удалось хорошо ответить, такое сохраняем отдельно и стараемся запомнить к следующему интервью. Те вопросы, где есть какие-то сомнения в ответе или реакция интервьюера нам не понравилась, прорабатываем и находим ответы дома в спокойной обстановке. Так к вашему -дцатому собеседованию у вас будет покрыто 90% наиболее частых вопросов.
Все собеседования были в Скайпе, причем большинство интервьюеров были без видео. У меня и так не очень навык считывания реакции, а в таких условиях так и подавно.
Есть ещё мой косяк — я периодически читаю информацию, связанную с популярными вопросами, но я ее не запоминаю, поэтому на некоторые вопросы не могу ответить вообще. Не откладывается у меня это в голове. И непосредственно в разработке пользы от этого нет.
Есть ещё мой косяк — я периодически читаю информацию, связанную с популярными вопросами, но я ее не запоминаю, поэтому на некоторые вопросы не могу ответить вообще. Не откладывается у меня это в голове. И непосредственно в разработке пользы от этого нет.
Я еще в университете пришел к написанию шпор по памяти, а уже потом(к сожалению) вычитал, что запоминать лучше именно через воспроизведение информации, желательно в письменной форме.
Вот с тем, кроме собесодований, пользы нет — беда, трудно найти мотивацию это изучать такие вопросы. С другой стороны, почти любые знания рано или поздно пригождаются. Ну да — можно нагуглить за 5 минут, а можно просто помнить или хотя бы помнить что гуглить). Кстати, не вспомните пример такого вопроса(ов)?
У нас в семье этот ад регулярно на добровольной основе :)
Но вот лайвкоддинг в маленькой формочке на каком то сайте вообще застал врасплох, я там даже не мог нормально воспринять шрифт, цветовую схему и банально скобки расставить, буквально ослеп ибо не было еще и подсветки блоков/сигнатур.
Начал писать код, просто чтобы начать что то писать, до конца не поняв ТЗ по реализации API, ибо я ожидал от них спецификацию по интерфейсам, а они примеры вызовов налепили.
Короче, я как в универе- лучше начать что то делать, чтобы не совсем зафейлить). Очень долго рожал, как потом уже понял, посредственную фигню. Тупка жесткая, сам себе удивился… Просто дно, еще и при этом, в качестве хобби, коллаборатор/около ментейнер пакетов, один с которых с 17лямами загрузок в месяц и 1,5к зависимых модулей :)
Причем в какую-то задрипанную конторку из региона по профильному языку.Не надо так делать. В нормальные конторы на нормальную зарплату устроиться, как показывает мой пятнадцатилетний опыт, зачастую проще, приятнее и профита куда больше. У меня есть знакомые в малом бизнесе и не понаслышке знаю, если пойдёшь устраиваться продавцом в задрипаный бутик 2х2 метра — зачастую тебя будут на собесе (и на работе потом) драть и в хвост и в гриву, при зарплате в реальные копейки. С другой стороны, если не совсем олень, можно устроиться в место покрупнее, и получать без нервов зарплату получше, попивая кофеёк в кресле. Это какая-то профдеформация владельцев и мелких руководителей нижних сегментов рынка в постсоветских странах.
А мне норм. Главное, не воспринимать его, как и остальные собесы, как экзамен. Это как с противоположным полом знакомство. Когда вопросы задают, то смотрят подходите друг другу или нет, а не баллы считают (хотя, не исключаю...)
Так что такое восприятие адекватно.
Я рассматриваю собесы, тестовые, включая лайвкодинг как презентацию своих знаний и навыков с полным пониманием, что на 100% вряд ли попаду в потребности с одной стороны, ведь какие-то пробелы могут быть выявлены всегда. А, с другой, нужно показать, что при достаточной мотивации за короткий срок могу закрыть конкретные пробелы, знаю куда рыть. Ещё нужно показать свой предпочитаемый подход к разработке и что есть границы, по его изменению, которые я перейти не готов. Понравилось — жду ваших предложений и ответов на мои вопросы. Нет — мне повезло, что потратил на выяснение того, что мы не сработаемся, всего несколько часов, а не год.
Это как с противоположным полом знакомство. Когда вопросы задают, то смотрят подходите друг другу или нет, а не баллы считают
А что, знакомство со своим полом в этом смысле как-то кардинально отличается?
Есть конторы особо упоротые на TDD, ничего плохого в этом нет, просто заранее кандидату надо сказать. Т.к. навык скоростного TDD прекрасно тренируется, погонял coding kata немного, и будете говорить на одном языке на собеседовании. Хуже когда по факту никакое TDD и не используется в конторе, и на собеседование протащили 'потому что модно', как с теми олимпиадными задачками в Гугле.
«Простейшая университетская задачка». Именно что университетская. Я в университете был последний раз десять лет назад. А на работе таких задач не было. Мозг забывает то, что не вспоминает регулярно. Кто-то здесь помнит уравнение фотосинтеза? А ведь это простая школьная задачка.
Когда я проводил собеседования, то просил разработчка изобразить какой-нибудь простой алгоритм на целевом языке на доске. Сразу с оговорками, что всякие синтаксические ошибки если и будут — то не страшно. Из задач предлагалось обычно перевернуть строчку задом наперёд или поменять порядок бит в числе на обратный. Требовать парсер выражений писать бессмысленно. Так вот, далеко не все Senior'ы даже с такими задачами справлялись (что, в первую очередь, говорит о качестве рынка разработчиков в целом).
Но если к вам приходят чуваки и говорят работать строго в одной парадигме (TDD), то от них надо бежать сломя голову. И есть серьёзные сомнения, что с архитектурой их проекта тоже не всё в порядке, и там костыль на костыле, но зато тесты работают.
Если человек не имеет привычку часто менять работу, или просто часто ходит на собеседования, шансы на успешное прохождение лайф-кодинга и алгоротмичных задач весьма низки. Говорит ли это как-либо о ровне навыков человека? Я не уверен в этом.
И если бы у меня, даже на привычной мне работе, постоянно стояли бы сзади и смотрели бы, как я пишу код, я бы тоже долго не задержался. Слава-богу, такого нигде нет.
Ойли! А вы не слышали про парное программирование? Очень модная фигня, кстати. Не все это делают, но те, кто делают, очень этим гордятся.
Если человек не имеет привычку часто менять работу, или просто часто ходит на собеседования, шансы на успешное прохождение лайф-кодинга и алгоротмичных задач весьма низки.
Еще раз: к собеседованиям надо готовиться. Это не так, что сегодня вместо работы пошел на собеседование, а завтра — опять на работу. В хорошие компании люди по полгода готовятся к собеседованиям, по вечерам решая задачи на LeetCode, прорабатывая дизайны разных систем для дизайн интервью, делая mock-интервью.
Говорит ли это как-либо о ровне навыков человека? Я не уверен в этом.
Может, говорит, может — не говорит. Можно долго рассуждать на эту тему, но те, кто готовятся, попадают в хорошие компании на хорошие зарплаты, а те, кто не готовится, продолжают рассуждать, что это не показатель.
Бывает, конечно, когда интервьюер &удак и нормальный диалог с ним трудно построить. Но тогда и Вам стоит задуматься: а хотите ли вы работать с такими &удаками в одной компании. Интервью — это обоюдный процесс: они оценивают Вас, Вы — их. Им тоже важно заинтересовать придти работать к ним в компанию (и сэкономить немного на Вашей зарплате, потому что работать с &удаками люди идут только если там платят больше других).
Раньше, если хорошо подобрал компанию и она тебе подходила по профилю, можно было с очень высокой вероятностью устроиться туда, сейчас же люди зачастую собеседуются десятки раз, ибо это превратилось в лотерею, ну или в длительное задротсво.
Ойли! А вы не слышали про парное программирование?
Я не только не не слышал про парное программирование, но и был к нему причастен. Оно никак не сопоставимо с ситуацией во время интервью, об этом неплохо уже написал falseortrue ниже.
Это, в целом, имеющая место быть практика, и, если она поставлена нормально, приносит неплохие результаты и наоборот понижает уровень стресса.
И все поменялось, когда я перестал бояться интервьюеров
Это приходит с практикой, а не «потому что так подумал». Покуда не пойдешь их какое-то количество, спокойствие не придет.
Еще раз: к собеседованиям надо готовиться
Хах, в этом-то и проблема. Почему это вдруг, надо (кроме того, конечно, что печальные современные реалии так диктуют)?
Какая вообще цель технического интервью?
Проверить, кто как/сколько подготовился быстро и правильно решать олимпиадные задачи под давлением? Оценить, насколько человек задротил litcode и насколько способен в стрессе это воспроизвести?
Или, все же, быть может, подобрать своей компании/команде подходящего по опыту и навыкам сотрудника?
Конечно, если человек — джун, то там должен быть достаточно энтузиазма/памяти с универа/отчаяния, что бы это канало.
Но после 10+ лет в продакшене, думаете, мне интересно готовить этот непотреб, который даже не служит задаче, которую, якобы, должен решать? Нет. Это последнее, что я хочу делать, возвращаясь поздно вечером домой, потому что это уже не так задорно и весело, как было когда-то, но в основном, потому что это переливание из пустого в порожнее.
Но после 10+ лет в продакшене, думаете, мне интересно готовить этот непотреб, который даже не служит задаче, которую, якобы, должен решать? Нет.
Так никто не заставляет. Можете сидеть на попе ровно на своем текущем месте, «крутить свою гайку» и по вечерам отдыхать на диване, потягивая пивко.
Вы даже, скорее всего, без труда сможете найти подобную Вашей работу в небольших конторах. Но большие конторы выберут кандидатов пободрее. Потому что могут.
Но не подумаете, я по прежнему интересуюсь новыми технологиями в моей (и не только) области. Просто задачки со списками и графами остались в далеком прошлом в универе.
И да, вы совершенно правы про FAAGN и пр… Они, впрочем, сами заявляют, что им норм большой процент false-negatives, т.е. то что они отвергают много хороших специалистов, которые им на самом деле подошли бы. Но у них огромная очередь, всех не принять, вот и придумали, как отсеивать дополнительно.
Проблема только в том что не все компании — это FAANG, но они этого не понимают. А потому продолжают в лайв-кодинг просит делать неприличные вещи с деревьями, и потом жаловаться на то что не могут полгода закрыть одну вакансию, когда у них в продакшене унылый REST API с каким-нибудь legacy/говнокодом.
К собеседованиям не нужно готовиться, если хотите попасть в комфортную среду с нормальными взаимными ожиданиями. Например, если вы ожидаете от работы, что на новую для вас задачу будет дано время и средства на изучение темы, то не дача таковых на собеседовании покажет, что или вы в личное время будете этим заниматься по рабочим задачам, проще говоря овкптаймить бесплатно,. Или в компании процессы фиговые и нужно им одно, а проверяют другое. Или настолько круты (или дурны), что ждут 100% попадания в требования
Еще раз: к собеседованиям надо готовиться. Это не так, что сегодня вместо работы пошел на собеседование, а завтра — опять на работу. В хорошие компании люди по полгода готовятся к собеседованиям, по вечерам решая задачи на LeetCode, прорабатывая дизайны разных систем для дизайн интервью, делая mock-интервью.
К собеседованиям в нормальные компании готовится не надо.
Потому что в нормальных компаниях оценивают навык работы а не навык прохождения собеседований.
И нет, Гугл и прочие подобные нормальными не являются.
Да, там есть пончики, настольный теннис, огромная зарплата и интересные задачи на острие технологий (но попасть на них очень и очень сложно, в большинстве случаев ты будешь писать нечто супер скучное для чего не требуется не один из навыков которые у тебя спрашивали на собеседовании) и строчка в резюме «я работал в Гугле».
Собственно за зарплатой и строчкой в резюме туда и идут.
Но это не делает Гугл нормальной компанией.
А как оценить навык работы?
Заглянуть в код, написанный соискателем? Подойдет OSS проект, коммиты в чужие проекты, тестовое задание на крайняк.
Прикиньте, при приеме человека на работу, которая заключается в том, чтобы писать код — простейший случай проверить компетенции — взглянуть на уже написанный код.
Что делать людям, которые не пушат в опенсорсы и не делают коммиты в чужие проекты?
Начать пушить в опенсорсы и делать коммиты в чужие проекты? Еще можно ничего не делать, и ныть на форумах про сложность прохождения собеседований. Которых, кстати, можно избежать вовсе, если см. пункт 1.
люди, которые делают коммиты в чужие проекты либо сверхлюди
Возможно, вы никогда не сталкивались с тем, что в используемой библиотеке / фреймворке / языке недостает чего-то такого, что лично вам необходимо — могу только позавидовать. Я с таковым сталкиваюсь с завидной регулярностью и между двумя вариантами — подкостылить и навелосипедить в проекте, или заслать PR — проще, быстрее и разумнее заслать PR. Я и в компилятор языка, и фактически в каждую вторую из используемых библиотек патчи слал.
либо недостаточно времени уделяют основной работе
Да-да. И те, кто на Stack Overflow отвечают — делают это в ущерб работе. И в блоги тоже пишут лентяи. Слыхали, знаем. Я лично не скрываю ни активность на SO, ни PR в чужие проекты, ни почти десяток активно поддерживаемых и развиваемых мною лично библиотек, — от руководства. И ему, руководству, почему-то не приходит в голову сделать из этого вывод, что я — тунеядец.
Про тестовое задание вам тоже выскажут своё «фи» секта свидетелей ненужного тестового задания [...]
Так это же прекрасно: мы расстанемся с такими кандидатами на берегу, даже не встретившись. И я лично уж точно сожалеть не стану.
Начать пушить в опенсорсы и делать коммиты в чужие проекты?
Количество людей, пушащих в опенсорсы и чужие проекты, прямо пропорционально количеству работодателей, которые позволяют делать это в рабочее время и платят за это деньги.
Ну и да — значительная часть тех, кто пушит в опенсорс, занимается какими-то интересными для себя вещами, не имеющими ничего общего с работой. Например, пилит человек какие-то там пет-проекты на хаскеле — что это даст возможному работодателю? Да ничего.
Тут и другой момент — если на работе есть достаточное количество интересных задач, то опенсорсом заниматься смысла нет.
Я с таковым сталкиваюсь с завидной регулярностью и между двумя вариантами — подкостылить и навелосипедить в проекте, или заслать PR — проще, быстрее и разумнее заслать PR.
О, далеко не всегда, т.к. могут часто возникать проблемы с приемом этого пр.
Например, пилит человек какие-то там пет-проекты на хаскеле — что это даст возможному работодателю? Да ничего.
Да ну? Работодателю это даст гораздо больше, чем можно было бы подумать: человек умнеет, набирается опыта, расширяет кругозор, точит профессионализм. Если мы не про галеры, конечно, где слишком умные никому не вперлись..
Тут и другой момент — если на работе есть достаточное количество интересных задач, то опенсорсом заниматься смысла нет.
Да ну? Прямо-таки нет смысла? Так-то я от неинтересных задач на работе просто отказываюсь, их как раз отлично сделают те, кто не пилит пет-проекты на хаскеле.
могут часто возникать проблемы с приемом этого пр
Да ну? Иногда (пренебрежимо редко, но все же) возникают, но из форка библиотека собирается ничуть не хуже, чем из транка.
P. S. С Шипилёвым, процитированным sergey-gornostaev чуть выше, я при всем этом не согласен. Мне просто нравится делать мир чуть-чуть лучше, дальновидность тут ни при чем.
Да ну? Работодателю это даст гораздо больше, чем можно было бы подумать: человек умнеет, набирается опыта, расширяет кругозор, точит профессионализм. Если мы не про галеры, конечно, где слишком умные никому не вперлись..
Ну, это просто не так.
Да ну? Прямо-таки нет смысла?
Прям-таки нет. Зачем писать код в опенсорс бесплатно, если можно писать этот же код на работе за деньги?
Да ну? Иногда (пренебрежимо редко, но все же) возникают, но из форка библиотека собирается ничуть не хуже, чем из транка.
А следить за апдейтами форка кто потом будет?
sergey-gornostaev
А зачем кому-то может понадобиться что-то с собой "утаскивать" после увольнения?
Ну, это просто не так.
Непробиваемый аргумент. Был бы, если бы для опровержения не требовал одного контрпримера. Так вот, в моем мире это так. На моей работе это так.
Зачем писать код в опенсорс бесплатно, если можно писать этот же код на работе за деньги?
Бывают люди, выбравшиеся из нижнего слоя пирамиды Маслоу, для них «бесплатно» или «за деньги» не является ни определяющим, ни значимым фактором.
Ну и мне лично платят зарплату за развлечения в OSS, все зависит от того, как договоришься с работодателем.
А следить за апдейтами форка кто потом будет?
Один из квадриллиона гитхабовских ботов, предназначенных специально для этого.
А зачем кому-то может понадобиться что-то с собой «утаскивать» после увольнения?
Чтобы потом не рассылать резюме, а откликаться на приглашения людей, которые разыскали тебя сами, например.
Был бы, если бы для опровержения не требовал одного контрпримера.
Один контрпример это утверждение никак абсолютно не опровергает.
Ну и мне лично платят зарплату за развлечения в OSS, все зависит от того, как договоришься с работодателем.
Ну так я ж сразу и сказал, что: "количество людей, пушащих в опенсорсы и чужие проекты, прямо пропорционально количеству работодателей, которые позволяют делать это в рабочее время и платят за это деньги"
Бывают люди, выбравшиеся из нижнего слоя пирамиды Маслоу
И у этих людей обычно есть немало других способов потратить свое время, кроме как на бесплатную работу.
Один из квадриллиона гитхабовских ботов, предназначенных специально для этого.
Уже придумали ботов, которые конфликты слияния сами разруливают?
Чтобы потом не рассылать резюме, а откликаться на приглашения людей, которые разыскали тебя сами, например.
А зачем для этого что-то "утаскивать" после увольнения?
у этих людей обычно есть немало других способов потратить свое время, кроме как на бесплатную работу
Опять деньги. Вы о чем-нибудь, кроме денег, умеете думать? И да, это ни разу не взаимоисключающие вещи. Аргумент про «у меня лапки хобби» я слышал тысячу раз; как правило от людей, у которых основное хобби — прокрастинация.
А зачем кому-то может понадобиться что-то с собой «утаскивать» после увольнения?
Чтобы потом не рассылать резюме, а откликаться на приглашения людей, которые разыскали тебя сами, например.
Приглашения разыскавших тебя людей в погонах?
(сейчас уже давно не 90-е, и то что на работе по контракту находится под NDA)
то что на работе по контракту находится под NDA
Во-первых, это зависит от того, что написано в NDA. Во-вторых, мы тут про коммиты в OSS, алё.
Зачем им что-то показывать? Разве недостаточно просто рассказать про свой опыт?
Что делать в таком случае?
Ну он говорит работодателю: "за моей спиной больше десятка лет работы с виртуальными машинами и сборщиками мусора" — и все.
И работодатель должен поверить на слово?
Почему нет? В других отраслях же верят.
Например в каких?
Да во всех :dunno:
Это только программистов почему-то считают патологическими лжцецами.
Работодатель-то, работодатель как его найдет? Или вы предлагаете специалисту такого уровня рассылать резюме?!
Эм, ну есть специально обученные люди — эйчары, которые видят, что Вася уволился из Х и теперь свободен. Даже у меня такие предложения сразу после увольнения бывали, хотя я нифига не специалист "такого уровня".
Каким боком тут всякий опенсорс — непонятно.
Опять же — в других индустриях никакого аналога опенсорсу нету, но как-то работодатели квалифицированных кадров находят.
эйчары, которые видят, что Вася уволился из Х и теперь свободен
Чем они увидят, третьим глазом? Как? Или мне теперь пойти обратно открыть профиль на линкедине, и разгребать спам? Зарегистрироваться на фейсбуке и там ныть про потерю работы?
Кроме того, эйчары — это совсем не те люди, с которыми хочется вообще разговаривать. Возможно, это работает до какого-то уровня, дальше — предложения этих эйчаров в лучшем случае вызывают нервный смех.
Профиль на линкедине даст много спама от непоймикого, профили на SO и GH — дадут предметные предложения от CTO/техлидов, которые тебя лично/заочно уже годами знают по этим профилям.
Чем они увидят, третьим глазом? Как?
Я не эйчар, так что не знаю. Я только знаю, что видят — это наблюдаемый факт.
Кроме того, эйчары — это совсем не те люди, с которыми хочется вообще разговаривать.
Какие еще разговоры с эйчарами?
Профиль на линкедине
Какой еще профиль на линкедине?
Вы выдумываете какие-то непонятные вещи, которые вообще не относятся к разговору.
И я еще раз вам напоминаю — процесс трудоустройства в другим отраслях прекрасно работает без гитхабов со стековерфлоу.
Т.е. все то, о чем вы говорите, опровергается обыкновенными практическими наблюдениями — достаточно из окна выглянуть.
Это только программистов почему-то считают патологическими лжцецами.
Вероятно потому, что наш брат часто лжёт, иногда из-за неспособности трезво оценить свои знания и умения, а иногда и специально.
В других областях нет такого количества войти-в-айти-шников и мошенников. Никому не придет в голову идти устраиваться водителем бульдозера, не умея им управлять. Никто не пойдет устраиваться хирургом, не имея медицинского образования. Ну, исключая отдельных особо редких психов.
А программитами устраиваться — идут. Толпами. FizzBuzz же не спроста появился. А чего такого? Там же просто кнопки надо нажимать, это просто.
В других областях нет такого количества войти-в-айти-шников и мошенников. Никому не придет в голову идти устраиваться водителем бульдозера, не умея им управлять
Дело не в мошенниках, а в том, что водителю не нужно постоянно сложно переучиваться на актуальную модель автомобиля.
По сложности смахивает на пилота самолёта, но пилоту достаточно показать сертификат о прохождении обучения требуемой модели самолёта.
Программисту (хорошему) тоже нет необходимости как-то особенно переучиваться. Проблема именно в тех странных личностях, которые программировать не умеют, а зарплату хотят.
Дело как раз в мошенниках. Вернее в тех, кто вводит работодателя в заблуждение, может сам находясь в добросовестном заблуждении, что знает технологию X v.15 и может на ней решать реальные задачи.
То, что водитель не умеет водить машину типа X будет заметно моментально. А вот программист может долго вводить в заблуждение, если хоть что-то умеет.
И работодатель должен поверить на слово?
Рыбак рыбака видит издалека.
Если у работодателя, есть специалист, который в теме, то он это легко определит из разговора.
PS а насчёт доказательств, то:
habr.com/ru/company/headzio/blog/519590
Однажды мне довелось проводить собеседование кандидата, который просто скопировал кусок моего резюме. Вскоре после моего увольнения он пришёл на проект, в котором я работал. Как потом выяснилось, долго не мог придумать как красиво описать полученный на новом месте опыт и просто нагуглил резюме человека, уже работавшего в этой команде.
Работодатель-то, работодатель как его найдет? Или вы предлагаете специалисту такого уровня рассылать резюме?!
Я вообще считаю, что люди, которые делают коммиты в чужие проекты либо сверхлюди, либо недостаточно времени уделяют основной работе
Что ж… Осталось понять, кто я такой…
Я вообще считаю, что люди, которые делают коммиты в чужие проекты либо сверхлюди, либо недостаточно времени уделяют основной работе
Ну вот часть моих коммитов в чужой код родилась так:
- приходит задача от бизнеса или техруководителя
- понимаю, что можно решить с помощью какого-то опенсорс ПО (в случае с задачи от техруководителя оно может быть указано явно)
- решаю, всё хорошо, проверил на основных кейсах на дев-окружении.
- на тестировании QA проверяет глубже и находит баг. А то и пользователь конечный в продакшене находит.
- локализация бага показывает на это ПО
- нахожу способ решения путём изменения этого ПО, делаю публичный форк и PR в апстрим
- в зависимости от разных условий или переключаю нашу систему на свой форк, или жду очередного релиза в апстрим с фиксом, или делаю обход проблемы, аналогичный по сути PR, но в обёртке типа декоратора для этого ПО.
Дополнительных затрат времени минимум: проблему так или иначе пришлось бы решать. Но сделанный (и принятый) PR улучшает качество нашей кодовой базы, в частности уменьшает количество временных костылей в ней.
За 10 лет работы программиста был на 15 в сумме собеседований наверно. При смене работы больше 3 собеседований не нужно обычно.
Если Вы готовы принимать первый же офер не торгуясь, то, да, из трех интервью Вы, скорее всего, одно да пройдете. А если хотите поторговаться, то нужно иметь хотя бы офера три. Чтобы их получить надо будет сходить на 5-10 интервью.
Можно просто владеть удачей и/или навыком распознавания и собеседоваться только в места, где 100% оффер будет.
А если хотите поторговаться, то нужно иметь хотя бы офера три.
Зачем? Какая разница три или один? Вы же не аукцион устраиваете с одновременным присутствием всех возможных работодателей.
Если Вы действительно ценный специалист, компании будут готовы поторговаться, потому что искать кадры — долго и дорого.
Нет, потому что в набор умений «ценный специалист» в первую очередь входит отсутствие стремления нагреть работодателя по мелочи. Хочешь не N, а N+M денег? — Озвучь, и если ты ценный специалист, мы что-нибудь, да придумаем.
А вот «у меня тут предложение от конкурентов» — это сразу безвозвратное «до свидания». В хороших местах крайне редко бывают востребованы люди с таким менталитетом.
Адекватные люди (в том числе в хороших компаниях, в том числе за рубежом) воспринимают такие заявления как ещё один сигнал что работник вероятно толковый, раз другие компании тоже его оценили настолько чтобы дать оффер.
Адекватные люди оценивают кандидатов по качеству произведенного кандидатом кода, а не по мифическим оценкам других компаний.
тебя за холопа считают без права договариваться
И чего, часто отказывались? Можете не отвечать, вопрос риторический.
Я же по-русски, вроде, окрытым текстом написал:
Хочешь неN, аN+Mденег? — Озвучь, и если ты ценный специалист, мы что-нибудь, да придумаем.
Где тут холоп, кроме вашего подсознания?
Ну, мы уже про Вас все поняли. Осталось только озвучить название компании и можно расходиться.
«Мы» — это кто? Лемминги с хабра?
На их LinkedIn странице написано
Over 5,100 clients in 72 countries have already exchanged more than USD $12.5 billion with Kantox.
Они «помогли клиентам перевести 12 ярдов денег». Это, как бы, не их собственные деньги. Более того, это, похоже, сумма за 9 лет существования компании, а не за год.
Адекватные люди (в том числе в хороших компаниях, в том числе за рубежом) воспринимают такие заявления как ещё один сигнал что работник вероятно толковый, раз другие компании тоже его оценили настолько чтобы дать оффер.
Адекватные люди воспринимают это как признак инфантилизма и неуверенности, хз.
Я не представляю себе, как нормальный здоровый человек будет искать контроффер прежде чем просто сказать начальству, что хочет большую зп.
Какое вообще у него говно должно быть в голове, чтобы вообще хотя бы такая идея появилась? Как он к ней пришел? Какой логикой? Это же, как минимум, просто непрофессионально.
Вот смотрите, Вы сами что-нибудь когда-нибудь продавали? Например, машину? Если нет, я Вам доложу: большинство людей первоначальный ценник ставят выше цены, которая бы их устроила, закладывая запас на торг. Приедет покупатель, начнет придираться: «тут скол, там затерто...» А Вы ему скидку. ВСЕ довольны: Вы получили свои деньги, покупатель заплатил меньше. Намного хуже, когда Вы упретесь рогом и ни сколько уступать не станете. Многих покупателей просто подход такой заставит уйти и поискать другого продавца. Торговаться — это нормально.
И с компаниями так же: когда дают оффер, обычно закладывают процент от него на торги: работнику намного приятнее будет работать, думая, что он «выбил» большие деньги, нежели когда ему в грубой форме отказали, «показав его место».
Я не знаю где Вам доводилось работать, но процесс переговоров насчет условий контракта во всем цивилизованном мире считается нормальным. В некоторых компаниях даже никаких контрофферов не надо, достаточно просто попросить немного прибавить (но надо таки уметь делать это вежливо, это тоже показывает уровень вашей адекватности). Но если есть контора, где Вы бы действительно хотели работать, но она Вам дала, по Вашему мнению, слабый оффер и есть другая, готовая дать больше, почему бы не попросить первую хотя бы заматчить оффер второй?! Все равно идти куда хотел работать за сколько дали не всегда возможно: во-первых, это демотивирует, во-вторых, есть внешние факторы (например, жена), которые могут давить на Вас взять самый денежный оффер не смотря ни на какие нематериальные бенефиты.
Вот смотрите, Вы сами что-нибудь когда-нибудь продавали? Например, машину? Если нет, я Вам доложу: большинство людей первоначальный ценник ставят выше цены, которая бы их устроила, закладывая запас на торг.
Все что вы пишите работает только при одном условии — если ваш работодатель думает, что без оффера вы блефуете и после его отказа не уйдете.
Это все зависит от того, конечно, как вы ставите себя — все мои работодатели всегда твердо знают, что если по вопросу условий работы мы не договорились, то можно сразу не терять время и переходить к обсуждению условий прекращения сотрудничества.
И из этого мышления и выходит что «ой, неудобно просить больше, ой, непрофессионально, ой, что обо мне барин подумает»
Просить больше — вполне удобно, мне просто искренне непонятно, как можно прийти логически к тому, что для этого нужен контроффер.
Своего рода доказательства того, что "вооон я скока стою"? А кому это доказательство нужно и зачем? Ну и с-но сам факт необходимости такого "доказательства" как раз и есть холопство какое-то.
Все что вы пишите работает только при одном условии — если ваш работодатель думает, что без оффера вы блефуете и после его отказа не уйдете.
У Вас, наверно, рынок перегрет: вакансий мало, а желающих много, раз работодателям проще потерять кандидата и искать нового, чем немного поторговаться. Мой совет — если не хотите с этим мириться, переезжайте.
все мои работодатели всегда твердо знают, что если по вопросу условий работы мы не договорились, то можно сразу не терять время и переходить к обсуждению условий прекращения сотрудничества.
В смысле «не договорились»?! Я так понял, до обсуждений дело не доходит. Вы имели в виду «что если не взял что дают»? Это такое. Всех благ таким работодателям и успехов с поиском работников. Если, конечно, у Вас из достижимых мест работы только одна контора, то, да, ничего не сделаешь, надо переезжать.
У Вас, наверно, рынок перегрет: вакансий мало, а желающих много
Не понял связи.
В смысле «не договорились»?!
Ну что-то вроде: "плати Х" — "не буду" — "до свидания".
Если, конечно, у Вас из достижимых мест работы только одна контора, то, да, ничего не сделаешь, надо переезжать.
Опять же, непонятно как вы такой вывод сделали. Все строго наоборот — когда контора одна, то события будут развиваться по схеме: "плати Х" — "не буду (зная, что человек все равно не уйдет" — "ок, потерплю с нынешней зп". А то, что я описал происходит тогда, когда контор много — в текущей платить больше не могут, ну ок, смогут в другой.
Вы поймите, готовность работодателя платить вам Х вообще никак не зависит от готовности других работодателей платить вам Х. Она зависит исключительно от того, сколько вы денег этому работодателю приносите/экономите/етц.
По-этому наличие/отсутствие оффера никак и ни на что не влияет кроме вашего блефа. Или — вообще ни на что не влияет, если работодатель и так знает, что блефа нет.
Вы все неправильно понимаете. Другие офферы — это не только возможность показать, что «а вот там меня больше ценят», но и запасные (или основные) варианты, на случай, если другие офферы отвалятся.
Так зачем эти варианты заранее искать? Как понадобятся — так и найдутся.
Но если я продаю арбуз, и мне предлагают купить его за 20 рублей, а я отвечаю «мне уже за 30 предложили, но за 35 отдам» это сильнее позиция чем, «нет, 20 мало, давай 30».
Да нет, это заблуждение. Совершенно неважно в данном случае готов ли кто-то другой у вас купить арбуз за 35, 100, 135. Важно лишь желание вот этого конкретного человека и его финансовые возможности. До желаний и финансовых возможностей других людей ему дела нет. Тот факт, что Вася заплатил за арбуз стотыщрублей, никак не влияет на вашу готовность самому платить за этот арбуз больше. Понимаете? Если он вам за 35 рублей не нужен, то вы его за 35 покупать не станете. И не важно кто и сколько за него готов заплатить среди других вероятных покупателей.
Вы поймите, готовность работодателя платить вам Х вообще никак не зависит от готовности других работодателей платить вам Х. Она зависит исключительно от того, сколько вы денег этому работодателю приносите/экономите/етц.
Напрямую не влияет, но если вы приносите.экономите работодателю Х денег, платит он вам Х/3, но вдруг узнаёт, что вам кто-то готов платить Х/2, то он может и начать платить вам больше, если будет знать, что за Х/3 он друго сотрудника не найдёт.
но вдруг узнаёт, что вам кто-то готов платить Х/2, то он может и начать платить вам больше
Это если он сам узнает. Мы же говорим про ситуацию когда вы пришли к нему и говорите: "давай денег". И тут не важно узнает он или нет. Он либо готов вам платить столько, сколько просите — либо нет. Сумма, которую предлагают другие покупатели, вообще никак не может повлиять на его решение.
Простите, но у вас какая-то альтернативная экономика, совершенно оторванная от реальности.
Да нет, обычная наблюдаемая экономика, которую вы можете пронаблюдать везде — от деревенского рынка, то сделок между крупными корпорациями.
Нигде не наблюдается зависимость готовности заключить сделку на условиях Х от готовности третьих лиц на эти условия.
Исключение одно — если вам нужно не самому заключить сделку, а именно не дать заключить другому.
Как вы здесь умудряетесь видить заблуждение? Когда тут нужно посчитать всего лишь 2 варианта «переговоры удались» и «переговоры провалились» перемножить на 2 ситуации — есть вариант Б или нет.
Ок, разжую полностью вам. Вот у вас есть продавец он готов продавать арбуз не менее чем за Xр. Вот есть покупатель — он готов покупать арбуз не более чем за Yр. Они начинают торговаться, и если Y > X то когда цена попадет в диапазон [X, Y] сделка совершена.
Обратили внимание, что третьих лиц тут нет? Если мы введем некоторого покупателя, который готов купить арбуз за Z > X, то это никак не повлияет на то, что максимальная цена первого покупателя — это Y.
Просто не существует причины, по которой первый покупатель ВНЕЗАПНО захочет отдать арбуз дороже из-за существования второго.
Связь самая простая: если работников много, а мест — мало, значит работодателю можно не торговаться насчет условий, если работник не согласен, можно быстро и дешево найти другого.
Так я вам описывал строго обратную ситуацию — когда работодателей много, а работников мало, то работнику торговаться не надо, ведь если работодатель не согласен, то можно быстро и дешево найти другого.
Давайте начнем с предыстории.
Ну окей, пусть будет "изучил рынок" — «плати Х» — «не буду» — «до свидания». Просто этот пункт самоочевиден, а на обсуждаемый вопрос не влияет никак. Потому я его просто опустил.
Хотя бы потому, что 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, и ежегодных
Лично я считаю, что выступления на конференциях — это достаточно небольшой бонус с точки зрения нанимателя. Часто туда ездят люди, которым нравится выступать на конференциях, и рассказывают про то, что они делают на работе. Не все доклады — это какой-то хайтех, часто просто структурированный сборник накопленных практик. Для DevRel специалистов такие скилы важны, для разработчиков — не особо.
Насчет больших StackOverflow профилей — этого я вообще не понимаю. Т.е. человек в рабочее время сидит и занимается ответами на SO вместо работы?!
Также, надо разбираться и с Гитхаб активностью. Я понимаю, когда человек горит программированием, выкладывает свои проекты (потенциально полезные другим, а не непонятные домашние поделки), контрибьютит в чужие. Если куча выложенных проектов с работы — мне это особо ни о чем не говорит.
Так что, не парьтесь сильно. Занимайтесь тем, чем нравится, для души, а не для статсов.
Обычно всякие такие активности идут Вам плюсом уже после того, как Вашу карточку найдут на каком-нибудь ЛинкедИне.
Рабов на галеры эйчары ищут именно так, да. Поэтому, кстати, я несколько лет назад закрыл свой линкедин от незнакомцев: слишком много спама.
Интересные предложения в 99% случаев исходят от CTO напрямую и начинаются с фразы «наткнулся на ваш профиль на gh / so».
Такие дела.
В любом случае сотрудник может уйти вообще без разговора об изменении условий труда. Просто прийти и, как говорится, положить заявление. Поэтому хороший работодатель отслеживает рынок и держит условия превентивно выше рынка
Также, никто адекватный не ходит просить повышение в стиле «накиньте денег или уйду». Или ходят «пора бы прибавить, вон у меня какие заслуги» (ну и тут или могут накинуть, или сказать, что пока заслуг недостаточно), или «я Вас уведомляю, что я ухожу» (и тогда возможен или вариант «хорошо, передай свои дела и уходи», или «в чем причина? что мы можем сделать, чтобы ты остался?» и негошиирование)
Важно лишь желание вот этого конкретного человека и его финансовые возможности.
Ну, естественно, если у человека нет денег, то и соваться на рынок нечего. Если человек арбуз покупает себе домой на десерт и не хочет столько платить, он не заплатит. А если от покупки арбуза зависит его собственный бизнес, и если не купить ни сегодня и ни завтра, то бизнес встанет, а потом и денежки закончатся, вот тогда и разговор будет.
Да, есть такие, кому не к спеху, и можно повыбирать и подождать подешевле. Но в современных реалиях скорость часто решает.
Не понял связи.
Связь самая простая: если работников много, а мест — мало, значит работодателю можно не торговаться насчет условий, если работник не согласен, можно быстро и дешево найти другого.
Ну что-то вроде: «плати Х» — «не буду» — «до свидания».
Если в Вашем окружении вот буквально так общаются, то это жесть.
Давайте начнем с предыстории. Когда Вы задаетесь какой-то суммой X, она не берется с потолка. Сначала Вы делаете исследование, сколько на рынке стоят программисты со схожими Вашим навыками, опытом и т.п. Получаете вилку. Потом Вы ищете компании, которым нужны специалисты Вашего уровня, делаете исследования, какие зарплатные вилки в каждой конкретной компании для специлистов Вашего уровня. Отсеиваете те, которые столько заплатить не могут. Может получиться так, что не найдете и надо будет пересмотреть X. Честное слово, почему это вообще надо проговаривать. Это не так, что пришел в любую рандомную компанию, открыл дверь с ноги и сразу просить заоблачную зарплату. Если Вы дошли до этой компании и прособеседовались, надо уже иметь понимание, смогут они Вам столько платить или Вы просто тратите и свое, и их время.
Так зачем эти варианты заранее искать? Как понадобятся — так и найдутся.
Хотя бы потому, что 1) как отмечалось ранее, к собеседованиям надо готовиться; 2) мы рассматриваем ситуацию, что Вы находитесь в активном поиске и надо найти новую работу за конечное, обозримое время; если Вы сидите на свое текущем месте и Вас все устраивает, можно вялотекуще собеседоваться… или вообще не собеседоваться; 3) у Вас в городе более двух-трех мест работы и город не достаточно маленький, чтобы все друг друга знали; 4) есть больше одной потенциальной конторы, где хотелось бы работать (с интересными проектами/технологиями и т.п.). Так вот, при всем при этом, делать одно интервью за раз, потом ждать ответа, потом при отказе делать следующее интервью и т.д. очень долго. и противоречит второму предположению (что надо быстро). Далее, на протяжении всего этого долгого процесса надо поддерживать свои знания алгоритмов, структур и вот этого всего свежими… Если процесс растянется на месяца 4, то к концу можно уже все позабыть. Поддержания себя в тонусе — занятие утомительное (да и в целом интервьюирование — это стрессовое занятие, поэтому хочется сделать его побыстрее). Поэтому люди освежают свои знания и начинают ходить на интервью, не дожидаясь результатов. Также, не все офферы и компании одинаковые: в каких-то более интересные технологии, где-то платят чуть больше, где-то работать престижнее. Поэтому сравнивать офферы не просто сравнить TC (total compensation). И также, если Вы ищите новую работу, чтобы получить прибавку к ЗП (например, потому что на старой работе Вам уже лет 5 не индексировали ЗП и получить прибавку очень сложно) хочется максимизировать прибавку, а не просто найти первое же место, где платят на 5-10% больше (к вопросу про «просто скажи сумму»).
Тот факт, что Вася заплатил за арбуз стотыщрублей, никак не влияет на вашу готовность самому платить за этот арбуз больше. Понимаете? Если он вам за 35 рублей не нужен, то вы его за 35 покупать не станете.
Я же говорил, надо выбирать компании, которым нужен сильный специалист, такой как Вы. Если Вы, например, разрабатываете высоконагруженные сайты, Вы же не пойдете в CMS странички верстать, а в такой конторе не будут готовы платить много, потому что для их нужд Вы — переквалифицированы (overqualified). А если компания полгода не может закрыть вакансию, потому что все кандидаты отказываются работать за такие деньги, хочешь-не хочешь, а задумаешься, не поднять ли ЗП.
Вы же не пойдете в CMS странички верстать, а в такой конторе не будут готовы платить много, потому что для их нужд Вы — переквалифицированы (overqualified).
Чуть ли не самые частые предложения ко мне: "у нас несколько лет работает сайт на коробочной CMS, но с ней мы в тупик зашли — надо как-то допилить"
Просить больше — вполне удобно, мне просто искренне непонятно, как можно прийти логически к тому, что для этого нужен контроффер.
Можно и без оффера. И да, Вам, скорее всего накинут сколько-нибудь. Но торговаться имея другие офферы выгоднее потому что у Вас будут пути к отступлению: если в какой-нибудь конторе начальник самодур и вместо того, чтобы не повышать оффер, отзовет его совсем, или другие офферы будут выше, можно будет по крайней мере принять те. Торговаться с одним только оффером гораздо сложнее и опаснее. Например, у меня были ситуации, когда я попросил поднять оффер, мне подняли, но на меньше, чем я просил, и я сказал, что я вежливо отказываюсь от их предложения. И вот тогда «подожди-подожди» и начинается второй раунд. А может и не начаться.
Своего рода доказательства того, что «вооон я скока стою»? А кому это доказательство нужно и зачем? Ну и с-но сам факт необходимости такого «доказательства» как раз и есть холопство какое-то.
Вы все неправильно понимаете. Другие офферы — это не только возможность показать, что «а вот там меня больше ценят», но и запасные (или основные) варианты, на случай, если другие офферы отвалятся.
Торговаться нормально, но вот бряцать другими офферами непонятно зачем. Этот оффер сделан неадекватным работодателем, не знающим сколько мне заплатит рынок? Так с ним проблемы постоянно будут — для повышения зарплаты надо будет опять искать другие офферы. А вот если в ответ на "мы можем предложить вам Х", говоришь "я соглашусь на X+10%" и тебе говорят "ок", то вероятность что через годик в ответ на "я теперь хочу X+10%+12,1%" услышишь "ок" выше.
Затем, что можно поторговаться.
А кто вам мешает торговаться не имея оффера? оО
Спросите, может ли компания А заматчить офер компании Б/предложить какие-то дополнительные бенефиты?"
Ну просто говорите в А: "я хочу Х денег". Никакого оффера в Б для этого не требуется. И либо А соглашается, либо тогда уже ищите другую компанию.
А вот «у меня тут предложение от конкурентов» — это сразу безвозвратное «до свидания». В хороших местах крайне редко бывают востребованы люди с таким менталитетом.
Все искусство в том, как это сказать. Вообще, проблема в менталитете людей с постсоветского пространства, где такое поведение считается чем-то плохим.
Также учитывайте, что часто люди ищут новую работу, чтобы получить прибавку к ЗП и, естественно, люди хотят получить больше. Также, поиск хорошего кандидата — это часто долго и дорого. Очень дорого.
Я в курсе, как компании ищут хороших кандидатов. Мы собрали лучшую команду в нашем стеке в двухмиллионнике.
У меня есть право вето на кандитата и я им воспользовался однажды — ровно в такой ситуации. Хочет кандидат играть в кошки-мышки вместо внятного разговора «ожидаю вот столько» — «что ж, обидно, вы неплохой специалист, наверняка у вас не будет проблем с поиском работы в другом месте».
И это не постсоветское, ровно наоборот: постсоветское — это как раз хитрожопость, которую не любят нигде. Шеф у меня американец, если что, ему даже объяснять не пришлось, почему я завернул довольно неплохого, в сущности, специалиста. Попросил бы он ртом сколько хотел — вопросов бы не возникло.
Не знаю, что там Вам кандидат сказал, что такая реакция. Конечно, когда просишь больше и грозишься уйти в другую контору надо быть готовым, что какие-то конторы таки соскочат. Поэтому, как я говорил ранее, надо иметь несколько офферов.
Я думаю, для того кандидата отказ Вашей конторы не был концом света и он благополучно трудоустроен.
Поэтому, как я говорил ранее, надо иметь несколько офферов.
Кому надо-то? Чтобы что? Если вопрос упирается исключительно в деньги, и вам вообще фиолетово, где именно работать — лишь бы платили побольше — можно просто согласиться в Штаты поехать (а если надо еще больше — то в Китай).
для того кандидата отказ Вашей конторы не был концом света и он благополучно трудоустроен
Наверняка. Просто если бы он попросил, сколько хотел, а не юлил, как уж на сковородке — работал бы в гораздо более сильной команде.
Когда оцениваются офферы, люди, обычно, учитывают много разных факторов. И технологии, и проекты, и компенсация, и команда, и расположение офиса, и перспективы роста, и, что немаловажно, адекватность начальства. Если начальство не умеет вежливо отказывать, например, запросам на повышение заработной платы и вместо этого увольняет сотрудника, это большой красный флаг.
Если начальство не умеет вежливо отказывать, например, запросам на повышение заработной платы и вместо этого увольняет сотрудника, это большой красный флаг.
Несомненно. У нас и не отказывают, более того, ежегодно индексируют з/п на 10%, и это прописано в договоре. Но уж подавно никто не увольняет сотрудников за мыслепреступления и любые речи. А при чем тут это?
Ну а остальное — это то, что данный конкретный кандидат и потерял своей неэтичной игрой на повышение при приеме на работу: технологии, и проекты, и компенсация, и команда, и расположение офиса, и перспективы роста.
С соответствующими скиллами это можно делать и имея только один оффер :)
Вы что, на работе сами стек имплементируете?
знание основных структур данных
Стек подразумевает некоторый контракт, абстракцию, его знания вполне достаточно для использования.
видение утечек памяти
Одного случая из миллионов других? Откуда уверенность, что дернув у испытуемого узкое знание по написанию определенной структуры и он не справится с имплементацией, вы удостоверитесь что он не обладает опытом в поимке утечек? Наверное, проще показать уже написанный код и найти утечку?
программистский скилл (невыход за границы массива, расширение массива при добавлении)
Ну дайте ему мелкий сниппет на ревью, где выход за границы массива (ага, ручное расширение массивов в 2020), пусть покажет пальцем.
написание тестов к коду
Можно писать тесты на что угодно.
ну и просто, что кандидат умеет кодить
Умеет кодить стек. Остальное это не выявит.
При этом его достаточно быстро можно написать, задачка элементарная.
Вы абсолютизируете свои субъективные представления. Кто-то может считать другие знания элементарными, которыми Вы не обладаете.
Кто-то может считать другие знания элементарными, которыми Вы не обладаете.
Конечно! Кто-то, может, отличный повар или умеет ездить на лошади. И это замечательно! Но на собеседовании конкретные люди ищут конкретных программистов в свою команду, чтобы писать конкретные проекты. И у них могут быть конкретные требования, под которые не подходят большинство программистов. И можно сколько угодно обижаться, что у Вас на собеседовании спросили написать какую-то дичь типа фильтра Калмана… или, скажем, стэк. Просто Вы, скорее всего, туда не подходите.
Спросите лучше, какое время поиска в стеке, как реверснуть содержимое, как обойти граф с его помощью и т. д. Инженерия — это в первую очередь наука о том, как из старых запчастей собрать новый механизм.
Зачем пытать людей бессмысленным написанием одного и того же? Стеки, хешмапы, деревья.
Чтобы проверить владение базовыми навыками.
Вы что, на работе сами стек имплементируете?
Нет, посложнее задачки. Которые бессмысленно давать человеку не способному даже простейший стек имплементировать. С другой стороны, давать сложные задачки на собеседовании тоже бессмысленно — задача более, чем на пол-часа — это уже не собеседование, а издевательство. Поэтому только так — проверка самой способности писать код. Ничего лучше не придумано.
Которые бессмысленно давать человеку не способному даже простейший стек имплементировать.
С чего вы взяли, что знание как имплементировать стек как-то приближает к выполнению любой другой задачи? Это говорит только о том, что человек владеет знанием (или зазубрил) как написать стек и не более того.
Чтобы проверить владение базовыми навыками.
Это крайне субъективный и ограниченный подход, набор базовых навыков для чего? Для решения олимпиадных задачек?
Сейчас мейнстрим это или лезть в дебри языка и библиотек или писать код на доске.
Что лучше сложно сказать. Писать код скорее лучше. Дебри у всех бывают разные, кандидат мог в другие залезать.
Самое смешное что меня спрашивали про дебри библиотек: Количество способов создать бин в Спринге. Я честно не знал вот про этот способ. Ни разу не использовал и до сих пор не использую. Не взяли. До сих пор смешно.
А вы что на собеседованиях спрашиваете?
Я не спрашиваю, но мельком видел список из вопросов, которые давали кандидатам. В принципе, там были какие-то общие вопросы на адекватность – помимо основных это сети, потоки, подходы к написанию кода, REST/HTTP. Вопросы ранжировались от легких, до сложных, можно было выбирать любые и отвечать.
Писать код скорее лучше.
Лучше, но в IDE.
Я за практичные задачки типа обработать (группировка, фильтр, собрать в коллекцию) список из объектов через Java Streams или Kotlin, можно с каким-нибудь непростым компаратором.
Количество способов создать бин в Спринге. Я честно не знал вот про этот способ.
Неприятный вопрос, думаю было бы верно попросить назвать основные способы, либо те, которые лично использовал, а не маргинальные типа groovy.
Вопросы ранжировались от легких, до сложных, можно было выбирать любые и отвечать.
Интересный подход. Надо быстро поправлять кандидата который выберет свое любимое из самого простого и начнет рассказывать о нем долго и со вкусом. Он может и знает все остальное, но вот это ему интереснее и знает ли он все остальное мы рискуем не узнать.
Готов выкатить 15 минутный рассказ о double. Если можно рисовать и писать код то и час протяну.
Я за практичные задачки типа обработать (группировка, фильтр, собрать в коллекцию) список из объектов через Java Streams или Kotlin, можно с каким-нибудь непростым компаратором.
Приходит к вам великолепный специалист работавший много лет в банке на шестой джаве. Про стримы он в курсе, но не использовал на практике. Котлин тем более. Он вашу задачку не решит. Опыта именно в этом месте не хватит. Но при этом за пару недель практики он во всем точно разберется и будет писать без проблем.
И когда пытаешься конкретно сформулировать что-то такое и чтобы оно писалось хотя бы в 5 значащих строк а не в одну приходишь к тем же самым задачкам. Все что проще вырождается в однострочник и не интересно.
Лучше, но в IDE.
Сейчас на удаленке все в IDE собеседуют. Похуже vim, но тоже нормальные обычно. Не блокнот и не доска.
Надо быстро поправлять кандидата который выберет свое любимое из самого простого и начнет рассказывать о нем долго и со вкусом.
Так разная разбалловка, ценность ответов на сложные вопросы выше. Ограничение по времени точно не помню, но достаточно чтобы ответить процентов на 70 довольно подробно. Ну и выбор вопросов уже говорит о том, где кандидат «шарит», а где нет.
Приходит к вам великолепный специалист работавший много лет в банке на шестой джаве.
У нас в требованиях Джава8+, либо выше. Ей уже лет шесть. Если «великолепный специалист», не занимался актуализацией своих знаний, не такой он уж и великолепный. Джава6 это даже не четвертый спринг, о чем тут может идти речь.
На крайний случай можно попросить сделать тоже самое, но в SQL, либо в JS, либо на чем угодно. На дворе 2020 и поддержка стримов (LINQ, Rx) есть в любом языке.
Сейчас на удаленке все в IDE собеседуют. Похуже vim, но тоже нормальные обычно.
Причем тут vim? Есть определенные стандарты в JVM мире, никаких vim'ов там нет.
Сейчас на удаленке все в IDE собеседуют.
Одноклассники собеседуют в онлайн текстовом редакторе. Это не IDE.
С чего вы взяли, что знание как имплементировать стек как-то приближает к выполнению любой другой задачи?
Интересно, вы необходимость подменили достаточностью от того, что не владеете базовым математическими знаниями или в качестве демагогического приёма? Я не утверждал, что этого достаточно.
Это говорит только о том, что человек владеет знанием (или зазубрил) как написать стек и не более того.
В принципе, я допускаю, что существуют такие экземпляры человеческого рода, которые могут зазубрить значки в басне Крылова и воспроизвести её, не умея при этом читать или зазубрить как написать стек не умея совсем программировать, но за моё присутсвие на планете Земля не попадалось ни разу первое и за мою карьеру в айти, начиная с эпохи БЭСМ-6 не попадалось так же и второе. А вот за необходимостью имплементировать стек с довольно высокой вероятностью следовало умение программировать и более сложные вещи. Собственно, необходимость — это же просто проходной тест. Если человек не способен написать даже такую простую вещь, как стек, дальнейший разговор бесполезен. Если же способен, то это повод узнать на что он способен ещё. Достаточность в математике доказывается куда сложнее необходимости, но если не выполнено условие необходимости, то браться за достаточность вообще нет смысла.
Это крайне субъективный и ограниченный подход, набор базовых навыков для чего?
Как минимум для продолжения разговора. Вот вы, как мы выяснили, не владеете базовыми знаниями мат логики, поэтому дальнейшая беседа с вами малоинтересна для меня. Вы просто не поймёте более сложных концепций. Так и человек не способный к написанию простых вещей не сможет писать и более сложные. И даже осознать этого (привет Даннингу с Крюгером!). Вряд ли такого человека стоит брать на работу где это требуется. Но если вам нужен человек для написания на каком-нибудь похапе сайтов-визиток по готовому шаблону, то, возможно, он и пригодится. Просто речь о более высоком уровне.
А вот за необходимостью имплементировать стек с довольно высокой вероятностью следовало умение программировать и более сложные вещи. Собственно, необходимость — это же просто проходной тест. Если человек не способен написать даже такую простую вещь, как стек, дальнейший разговор бесполезен.
Если вы продолжаете разговор только с теми, кто может — то откуда у вас вообще понимание «необходимости»? Почему вы считаете, что вы наблюдаете реальное положение вещей, а не ошибку выжившего а-ля «100% прошедших наш опрос в интернете подключены к интернету»?
Если вы продолжаете разговор только с теми, кто может — то откуда у вас вообще понимание «необходимости»?
Очевидно, предыдущий опыт, который показал, что с высокой долей вероятности, с человеком, не справившемся с простейшим заданием продолжать разговор не о чем — ни на что более сложное он не способен. Да, мне правда было бы крайне интересно узнать что именно может вызвать затруднения в имплементации стека хоть сколько-нибудь программистом (не говоря о хоть сколько-нибудь опытном)?
Почему вы считаете, что вы наблюдаете реальное положение вещей, а не ошибку выжившего
Так ведь ни у кого не стоит задача выявить всех способных программировать, в том числе маргинальных личностей, способных делать сложные вещи и не уметь в простые (они в любом случае негодные — что с ними потом делать, если окажется, что очередная задача для них недостаточно сложна, а простые, как мы выяснили, они по какому-то дефекту развития неспособны решать?). Задача, скорее, отбросить неспособных. Туда могут попасть и немного вышеописанных маргиналов. Ну, так и фиг с ними. Ложноотрицательный результат в случае найма лучше (дешевле) ложноположительного.
а-ля «100% прошедших наш опрос в интернете подключены к интернету»?
Разве тут есть проблема? Вы, возможно, не поверите, но ситуация обстоит ровно так — 100% моих коллег-программистов умеют программировать. Если это результат ошибки выжившего, то это ОЧЕНЬ хороший результат! Именно его при найме программистов и добиваются. Или вы нанимаете или, хотя бы, собеседуете "программистов" не умеющих программировать? Мгммм, и… зачем?
Готов поспорить, что мне удастся выдумать пяток-другой задач, сопоставимых по сложности с имплементацией стека, которые половина из ваших 100% решить (особенно прямо на собеседовании) не смогут. Просто потому, что никогда конкретно с похожими проблемами вообще не сталкивались.
Сделает ли это их специалистами, с которыми «дальше продолжать разговор бессмысленно»?
Да, сделает. Но я не был бы уверен, что там и правда будет "половина из 100%". Всё-таки программист обязан уметь решать любые задачи, а не только те с которыми он ранее сталкивался. Да, в том числе прямо на собеседовании, если задача достаточно простая для этого.
Ну вот если не сталкивались, проверьте себя на расстоянии Левенштайна.
Расстояние Левенштейна определяет, сколько раз необходимо добавить/удалить/заменить символ, чтобы одну строку превратить в другую.
Там все в десять раз проще, чем стек.
А основная сложность — это ресайз при добавлении элемента.
Расстояние Левенштейна таки требует более серьезного подхода.
Хотя возможно я просто не знаю как просто и эффективно считать его, а в голову ничего не приходит (no hire, дада).
Все таки в стеке не так много методов: push, pop, isEmpty, size.
Вот по опыту работы с некоторыми аппаратными стэками нет там ни isEmpty, ни size. Если уж сильно хочется, то можно запоминать начальное значение головы и сравнивать с текущим.
А основная сложность — это ресайз при добавлении элемента.
Смотря как реализовывать, на динамических массивах в JS если, например, это совсем не проблема :)
по опыту работы с некоторыми аппаратными стэками нет там ниisEmpty, ниsize
Ни у какого стека нет size, ему неоткуда взяться и его, главное, негде хранить. empty? легко реализуется через pop, поэтому можно без потери общности считать, что он есть бесплатно.
Ну а Левенштайн — одна строчка кода, если мы говорим про сравнение слов и квадратичный алгоритм годится (рекурсия). Или пять, если нужно добиться O(N×M).
Показательно, что люди хором утверждают, что он сложнее стека, хотя в стеке (который изоморфен аппаратному, а не тупое LIFO), в отличие от Левенштайна, подводных камней полно́. В принципе, признание «Левенштайн сложнее стека» — уже говорит о том, что что такое «сложнее» — каждый понимает по-своему.
основная сложность — это ресайз при добавлении элемента
В стеке, изоморфном аппаратному — такой проблемы нет. См. stack overflow. Это статический массив, а не список.
Это все — отличные темы для разговора на собеседовании и возможность показать Вашу осведомленность про разные особенности реализации стеков и уточнить какие компромиссы мы хотим сделать в разрабатываемом стэке. Будет ли он фиксированного размера или будет расти безгранично. Какая сложность должна быть у операций (например, если стэк не фиксированного размера, будем ли мы просто делать realloc на внутренний массив (O(n)) или надо выделять память чанками (O(1)), будем ли мы возвращать память обратно, если она не нжна).
Показать мою кого?
Я не хожу по собеседованиям, а осведомленность как-то привык показывать кодом в открытом доступе, холлоффеймами на стековерфло, блогом, конференциями и т. п.
P. S. если меня кто-то спросит «какая сложность должна быть у операций на стеке», я мгновенно переведу разговор на более гуманитарную тему, типа футбола или рыбалки. О разработке я разговариваю только с теми, кто хоть что-то в предметной области понимает.
P. P. S. Кстати говоря, про сложность. Вон там господа в соседних ветках предлагают Левенштайна сложностью O(N×M) — что тоже сразу же нам говорит о том, что господа за деревьями леса ни хрена не видят. Считать расстояние Левенштайна на непомерно длинных строках просто бессмысленно, поэтому ни один профессионал (если он, конечно, не пишет библиотеку, которая умеет только считать расстояние Левенштайна, зато хорошо) — не станет городить огород, и возьмет неоптимальное, зато простое и внятное рекурсивное решение.
А вот если функция вызывается на большом тексте на каждом слове (в цикле, там, например) — то нужно и правда написать библиотеку, O(N×M), с матрицей переходов букв, плохо читаемую, и обложенную бенчмарками. И скрыть ее от использующих этот код за фасадом интерфейса.
Да у Вас, судя по всему, ЧСВ зашкаливает. С такими диагнозами в любой приличной конторе завернут по софт скилам. И даром все Ваши стэки оверфлоу..
Не dp подход дает 3^N. Уже на 15 символов это ~15 миллионов итераций и код станет нерабочим под любой минимальной нагрузкой.
Такое в прод нельзя. Взорвется точно. На паре слов буквально.
Ну а Левенштайн — одна строчка кода, если мы говорим про сравнение слов и квадратичный алгоритм годится (рекурсия). Или пять, если нужно добиться O(N×M).
С каких пор сложность задачи измеряется числом строчек кода?
Показательно, что люди хором утверждают, что он сложнее стека, хотя в стеке (который изоморфен аппаратному, а не тупое LIFO), в отличие от Левенштайна, подводных камней полно́.
Вообще-то под "стеком" как структурой данных всегда понимали тупое LIFO, и обсуждается в этой ветке именно этот вариант.
Хотя возможно я просто не знаю как просто и эффективно считать его, а в голову ничего не приходит (no hire, дада).
Да никак там не посчитать эффективно, там O(NM) во всех алгоритмах. Правда, если точного ответа не требуется — вроде бы есть более быстрые приближенные алгоритмы. Ну и если ответ ограничен сверху, желательно небольшим числом, можно просто перебрать возможные правки и получить что-то вроде O(N + M * ?K)
Справедливости ради, расстояние Левенштайна — гораздо сложнее стека. Эта задача на динамическое программирование, когда как стек вообще никакой computer science не требует.
К сожалению, я помню алгоритмы нахождения расстояния Левенштейна, а один из них даже использовал в реальном проекте, так что тут я плохой подопытный.
Ну а про то, что расстояние Левенштейна сложнее стека, в то время как вы обещали схожую сложность, вам уже написали выше.
мне удастся выдумать пяток-другой задач, сопоставимых по сложности с имплементацией стека, которые половина из ваших 100% решить (особенно прямо на собеседовании) не смогут.
Воу! Будьте так любезны, сделайте мне это! Прям хочу-хочу!
Только обращаю ваш внимание — "решить" — означает имплементировать. То есть алгоритм должен быть либо тривиальный (как стек), либо даваться вместе с задачкой или уточняться по запросу. Речь не о алгоритмической секции, а именно о кодировании.
Просто потому, что никогда конкретно с похожими проблемами вообще не сталкивались.
Вы знаете, за мою 30+ жизнь в программировании мне приходилось решать не так уж много проблем, с которыми я ранее сталкивался. Как правило, ни все сколько-то новые. Именно поэтому я до сих пор этой теме — нет повода заскучать.
Это точно почти никто не напишет. Уж лучше стек спрашивать. С ним хотя бы есть шанс что кандидат напишет то что надо.
Придумано.
Проверка умения читать код. На лучшем из моих собеседований у меня именно код ревью было. Бизнесовое текстовое описание и написанный примерно по нему код.
Хотя может это и специфика — я не пишу новую систему с нуля, а развиваю существующую, но кажется такая специфика очень распространена.
Собеседование в форме код-ревью (умышленного говнокода) неплохая практика, слово за слово и о языковых конструкциях поговорить, и об архитектуре.
Придумано.
Проверка умения читать код.
Прекрасный метод! Если вам нужен человек, умеющий читать код. Но ведь задача была найти человека, умеющего писать код. Я абсолютно точно знаю, что из первого не следует не только хорошего второго, но и вообще не следует второго — я знавал человека с феноменальным умением читать код. Он быстро врубался в то, что код делает и находил такие ошибки, которые сложно было и придумать. Но он НЕ умел писать код. Вот совсем. Из него вышел бы прекрасный код-ревьюер. Или эдакий хитрый тестировщик. Но программист — неа.
я знавал человека, он НЕ умел писать код.
Не знаю, какая патология была у Вашего персонажа, может, у него были недоразвиты руки и он до клавиатуры не дотягивался, или ему религия не позволяла писать код, но это скорее исключение, чем правило. Чтобы быстро разбираться в чужом коде, нужна инженерная интуиция, знания и большой опыт.
Кстати, интервью, когда тебе дают код и надо в нем пофиксить ошибки или добавить функциональность — IMO, одни из самых интересных и полезных, чтобы понять, как человек сможет выполнять свои обязанности.
Но ведь задача была найти человека, умеющего писать код
А это было выделено? Я воспринимаю вакансию разработчика как поиски специалиста, который будет развивать существующую систему. Так как если вы пришли в проект не в первую неделю разработки, то система уже существует.
И значит, что читать код придется столько же, сколько и писать. А если это не продуктовая разработка, а развитие существующей уникальной системы, то читать нужно гораздо больше, чем писать.
И не умеющий читать писатель это гораздо большая опасность, чем не умеющий писать читатель. Второй хоть не угробит ничего.
Не знаю, какая патология была у Вашего персонажа, может, у него были недоразвиты руки и он до клавиатуры не дотягивался, или ему религия не позволяла писать код, но это скорее исключение, чем правило.
Гм. А вы романы писать пробовали? Сколько опубликовано? Или у вас какая-то патология — может руки недоразвиты и до клавиатуры не дотягиваются? Или религия? Или все вокруг могут писать книги (все же могут читать) и только вы такое вот патологическое исключение?
По моим наблюдениям читателей на несколько порядков больше, чем писателей. Причём вполне "профессиональных" читателей — они вполне способны оценить книгу, стиль написания, степень раскрытия характеров персонажей, описаний сцен, развития сюжета, восторгаться глубиной мысли или, наоборот, с первых же глав понять, что КГ/АМ и даже рассказать почему именно. Не говоря, что существует аж несколько профессий вокруг книгописательства либо помогающего писанию книг, либо отлавливающих ошибки, но при этом не связанные напрямую с самим процессом написания книги. Вы думаете, литературоведы и прочие литературные критики имеют дефекты рук? А корректоры исповедуют специальную религию?
Я полагаю, программирование является областью деятельности, как минимум, сравнимой сложности с книгописательством (вообще, лично я считаю, что даже посложнее). И вполне нормально, что далеко не все "профессиональные потребители" и того и другого не могут так же и писать на должном уровне — что код, что романы.
Чтобы быстро разбираться в чужом коде, нужна инженерная интуиция, знания и большой опыт.
Разумеется. Поэтому существует очень уважаемая профессия, скажем, тестировщиков. Лучшие из них способны залезть в код и найти в коде ошибок больше, чем программист способен наделать себе представить. Но при этом они не могут сами писать код. По разным причинам. Может быть им это не интересно. А может по той же причине, по которой я не могу писать романы. Читать могу, писать — нет. И это точно не потому, что не дотягиваюсь до клавиатуры. У меня вполне выходят приличные произведения эпистолярного жанра (руки дотягиваются, а пальцы даже владеют слепым десятипальцевым). А романы — нет. Вы считаете это патологией? Можно повторно попросить список ваших опубликованных книг? :)
Ваше сравнение — херня на постном масле. Умение читать — это базовый навык, которому учат в первом классе школы. Никаких дополнительных навыков для чтения художественной литературы не требуется. Умение читать код (как и понимание основ CS, знание синтаксиса языков программирования) — это далеко не базовый навык, которому учат всех. Чтение кода — это отнюдь не праздное развлечение, чтобы «пойду-ка я кода перед сном почитаю». Это специальный навык, которому люди учатся целенаправленно. Болле того, чтение кода — это не отдельная дисциплина, чтобы этому учиться. Нет отдельных классов для обучения чтению кода, а отдельных — для написания кода. Это все — часть обучения программированию. Также, чтобы хорошо запоминать как работают вещи, ими надо пользоваться. Никакое обучение, не подкрепленное практикой, не будет эффективным.
И если Вы говорите, что не практикующий программист находит ТАКИЕ баги, которые не может найти практикующий программист (одинакового уровня, давайте не сравнивать лид тестировщика с джуниор программистом), то это или патология, или, я не знаю, обезьянка, обученная находить конкретные типовые проблемы, не понимая, что в целом происходит.
Ну и напомню, что мы таки говорили про отсечении плохих программистов на собеседовании. Если у Вас мега звезда в, например, тестировании, зачем ей идти собеседоваться на программиста?!
Ваше сравнение — херня на постном масле.
Разве? А почему?
Умение читать — это базовый навык
Абсолютно, нет. Даже речь — не очень базовый навык, но ей (native), хотя бы, обучаются спонтанно. Чтение же — специальный навык, требующий целенаправленного обучения.
Чтение кода — это отнюдь не праздное развлечение, чтобы «пойду-ка я кода перед сном почитаю». Это специальный навык, которому люди учатся целенаправленно.
Опа! Вы говорите теми же словами! Подозрительно…
В любом случае, в подавляющем большинстве случаев, человек одновременно с чтением обучается и письму.
Болле того, чтение кода — это не отдельная дисциплина, чтобы этому учиться. Нет отдельных классов для обучения чтению кода, а отдельных — для написания кода.
Ух, ты! Вы опять говорите то же самое!
Кажется логичным, если так много совпадений, то раз вы утверждаете, что человеку, умеющему читать код только какой-то дефект может помешать писать код, то и человеку, умеющему читать книги только какой-то дефект может помешать писать книги. Так, где, говорите, список опубликованных вами книг?
то это или патология, или, я не знаю, обезьянка, обученная находить конкретные типовые проблемы, не понимая, что в целом происходит.
Стало быть, в отсутствии списка опубликованных вами книг вы признаёте себя дефективной обезьянкой, видящей буквы, но не понимающей, что за ними написано (вон, человек в параллельном комменте уже сделал такой вывод — я немного более человеколюбив, предоставляю вам удостоверится в этом самому :) — неопровержимые доказательства приведены выше.
Если у Вас мега звезда в, например, тестировании, зачем ей идти собеседоваться на программиста?!
Конкретно этот человек — нет, не собеседовался даже на тестировщика, у него просто был такой талант. Любительский. Но вы даже представить не можете КАКИЕ странные люди приходят порой собеседоваться на программистов не умея программировать от слова совсем. Я не знаю зачем они это делают, но они есть и их НЕОБХОДИМО отсекать. Способ "напиши немножко простенького кода" их отсекает, хотя далеко не всех. Способ "прочти немножко кода" — нет вообще.
Да, даже здесь на хабре посмотрите сколько людей (видимо, считающих себя программистами) яростно протестуют против предложения написать элементарный код. Казалось бы, это не должно вызывать затруднений, но вызывает. Смешно, но это так.
В любом случае, в подавляющем большинстве случаев, человек одновременно с чтением обучается и письму.
Разве? Что я сам в 80-е, что дети недавно в первый класс шли: навыки чтения проверяли на "собеседовании", письма — нет.
Что я сам в 80-е, что дети недавно в первый класс шли: навыки чтения проверяли на "собеседовании", письма — нет.
С этой проверкой что-то не так.
- Взять они должны и не умеющего читать ребёнка
- Вне зависимости от умения читать учить читать (и, одновременно, писать) всех будут заново. При этом тем, кто читать умеет на уроках будет запредельно скучно. Говорю как очевидец у которого в первом классе половина замечаний была — отвлекал всех в классе, а вторая половина — читал под партой журнал "Наука и жизнь" :)
Чисто теоретически, интересно было бы посмотреть, какой у этого уникума потенциал по работе в паре с программистом-писателем. Тот пишет, а этот на ходу выявляет потенциальные косяки.
Ну и кстати, интересно, каким образом его проверяли на умение писать код. Может, его банально заглючило, потому и ни одной строчки не смог выдать? Проблема с хорошим чтением кода ведь в том, что ты и у собственной писанины сразу видишь уйму недостатков. Особенно сложно становится, когда не знаешь точно, чего от тебя хотят. Идеально чистого кода? Решения всех боковых веток в тестовом задании? Использовать конкретные техники или парадигмы (типа "труъ-ООП")? Если на таком выборе переклинит, то и я бы ни строчки написать не смог, хоть за плечами годы опыта.
Чисто теоретически, интересно было бы посмотреть, какой у этого уникума потенциал по работе в паре с программистом-писателем. Тот пишет, а этот на ходу выявляет потенциальные косяки.
А как-то так и происходило. Было круто :). Но это не в промышленных масштабах — так баловство.
Ну и кстати, интересно, каким образом его проверяли на умение писать код.
Да, не его не проверяли. Просто знакомый такой был. Он и не хотел писать код.
А вообще, написание кода — это ведь не просто набор без синтаксических ошибок, это тщательное продумывание всех возможных вариантов развития событий и установка ограждений для них. Прямолинейный код для happy path написать легко, сложно предусмотреть все варианты того, что может пойти не так.
Особенно сложно становится, когда не знаешь точно, чего от тебя хотят. Идеально чистого кода? Решения всех боковых веток в тестовом задании?
Я, обычно, не заморачиваюсь и пишу первое придуманное решение. Если есть вариант лучше, интервьюер скажет и иногда подскажет куда думать. Если и так хорошо и осталось немного времени и я об этом внезапно вспомнил (что случается редко), то пишу пару тестов или голосом озвучиваю, что вот я написал, сейчас на бумажке проверю некоторые граничные случаи — интервьюеров это либо впечатляет либо, хотя бы, воодушевляет :).
Кстати, помимо того читальщика кода любителя :) знал пару вполне профессиональных тестировщиков (которые именно работали тестировщиками), умели в код и хотели заапгрейдится до программеров. Один точно перешёл в программеры, не знаю, правда, насколько он хорош, надеюсь на лучшее, а другого я как раз менторствовал в его желании стать программером. Так вот он на тот момент писал реально настолько хреновый код, насколько только можно себе вообразить. Читать мог, писать — мама дорогая, у меня волосы шевелились :). Может потом научился, конечно, не знаю. В общем отбирать разработчиков только по умению читать код и не проверяя способность к писанию — крайне странная, на мой взгляд, затея. Не к добру :)
happy path включал в себя все варианты, как частные случаи
Это противоречит общепринятому определению happy path, которым воспользовался предыдущий оратор.
«happy path, включающий в себя все варианты» — это как «натуральные числа, включающие в себя отрицательные, иррациональные и комплексные».
А еще есть смешная «патология» реверсного типа: когда человек (вот как ваш оппонент, например) — аргументы выдумывать из вакуума может, а понимать чужие — нет.
Такой write-only pattern, в пику вашему литературному read-only.
Отличная аналогия, не слушайте дурачков. Читать и писать — это просто разные навыки, которые не нужно смешивать на том лишь основании, что они работают с одним и тем же источником. Как микрофон и динамик — гнезда рядышком, все остальное — порознь.
Да, а я прекрасно помню, как в яндексе затупил с пузырьком на бумажке. Смешно это, но блин, стресс штука сильная, мешает думать.
Посмотрел бы я на этих людей окажись они в таком же положении
Они же собеседуют так постоянно. Им надо понимать что кандидат пишет где он прав, а где нет. Понимать сразу в процессе написания, а не потом.
Навык лайвкодинга оттачивается достаточно быстро.
Полагаю, они были в таком же положении, раз получили там работу?
Вне IDE смысла не вижу вообще никакого, программист это прежде всего ремесло, умение обращаться с инструментами.
IDE – главный инструмент (ну, наравне с поиском инф-ции в поисковике) и владение им должно проверяться наиболее тщательно: знание хоткеев, быстрое ориентирование в написанных классах, перемещение по дереву проекта, автогенерация кода, воспринимание и вдумчивый анализ тех же javadoc'ов. Все это куда важнее очередной заученной тыканины с индексами в дереве, которая выветрится через 30 минут после собеседования до следующего открытия книги «Cracking the Coding Interview».
Спешу Вас расстроить: знание тонкостей IDE — это далеко не самый важный навык программиста. Важно — быстро выдавать качественный результат. А в чем человек работает не имеет значения, пусть хоть в блокноте.
Спешу Вас расстроить: знание тонкостей IDE — это далеко не самый важный навык программиста. Важно — быстро выдавать качественный результат
Какой-то слишком диалектический подход, IDE и разрабатывалась для того, чтобы быстро выдавать качественный результат. Качественный результат в блокноте выдать невозможно.
Звучит так, как будто обход дерева — это что-то невообразимое, хотя деревья встречаются в повседневном программировании постоянно.
Много чего в программировании встречается постоянно, но вы считаете, что то чем именно вы занимались в свободное время, алгоритмами и структурами данных, по какой-то причине ценнее того, чем занимались другие программисты, не считающие это заслуживающим внимания или интересным.
Нет, это конечно хорошая позиция «за все хорошее, против всего плохого», знать лучше, чем не знать и так далее, но, к сожалению, мы ограничены свободным временем. Тот, кто потратил 8 часов на дрессировку у себя навыка как лучше вертеть индексами в дереве и массивах – не потратил эти 8 часов на что-то другое.
А в чем человек работает не имеет значения, пусть хоть в блокноте.
Наверное для уровня программ laba1.cpp это актуально, но не в современной разработке.
Наверное для уровня программ laba1.cpp это актуально, но не в современной разработке.
Система контроля версий достаточно сложный проект? А некоторые мои знакомые разрабатывают его в ViM.
И ваши подходы к разработке могут не совпадать с подходами другого человека. Даже если он пишет на том же языке и фреймворке.
P.S.: Уточню, что я то как раз привык писать код в IDE.
Вообще выбор vim для мейнстримного языка уже говорит о многом, такие люди обычно не очень хорошо уживаются в командной разработке, хотя есть и исключения и в собеседовании в этом случае нужно проверить является ли кандидат этим исключением.
Работает простое правило, неправильно объявили тип неважно, тут долго писать try / catch поставь 3 точки. Зато без IDE человек лучше мыслит абстрактно.
Обычно план такой:
Сперва чтобы просто хоть как-то заработало, потому что главное, чтобы скрипт начал выполнять основную задачу.
Затем я уже его рефакторю.
Понятно, что за годы опыта я пишу не просто чтобы заработало, а делаю какие-то архитектурные заготовки на будущий рефакторинг, подразумевая что тут я накидаю интерфейс поудобнее, тут я в функции буду заворачивать. Много лишних строк для отладки момента, который я еще не очень понимаю как реализовать.
Но в любом случае, первый скрипт на финальный похож в лучшем случае на 10-20%.
Можешь гуглить все что хочешь.
Что правда что ли? Рука сразу потянулась написать в поисковике boost::spirit.
Простой, но очень действенный лайфхак: первым делом пишем не код, а комментарий в коде, что за задачу мы решаем. Во-первых, это позволит привести мысли в порядок и понять, как выглядит цель. Во-вторых, задаёт почву для общения с интервьювером: "а в этом случае мы должны вывести вот такой результат — верно?". В-третьих, поможет потом при реализации: если постановка задачи выписана своими словами и находится перед глазами, то её можно не держать в голове — соответственно, там освободится место, нужное при кодинге.
В общем я очень сильно волновался, руки потеют, стал немного заикаться, на удивление прошло нормально, решил задачку fizz buzz, потом попросили показать работу с библитеками requests и json, написать простенький скрипт получения данных с сайта и сохранения в БД, в общем 2 из 3 заданий на написание кода я сделал, при чем собеседующий не торопил, разговаривал как друг, в паре мест даже подсказал как лучше сделать, за что ему большое спасибо и вагон здоровья. В общем техническое собеседование я прошел, но Епам меня не взяли, сказали английский у меня слабый, а проектов для людей с моим уровнем английского у них нет. Так что тут много зависит от собеседующих, если обстановка дружелюбная то и код не напрягает написать.
А вот был случай больше года назад, сходил на собеседование в местную компанию, при чем сами меня позвали, хотя я сразу сказал опыта разработки нет, в итоге позвали и поглумились в опенспейсе при всех, я в центре сидел, собеседовал тимлид, грузил вещами которые начинающий программист знать не может, грузил по уровням данных БД, по абстракциям и т.д, при чем люди вокруг посмеивались, когда я отвечал не знаю, а он мне говорил что нибудь язвительное в ответ и по всей видимости смешное для окружающих, вышел как в пелене и как будто оплеванный, но нечего, спустя полгода работы разработчиком, они снова на меня вышли, но были вежливо посланы.
Это навык, который вырабатывается только повседневной практикой.
Поэтому вот так прям сразу писать в стиле TDD, да ещё под стрессом, вряд ли у кого получиться.
ИМХО это был не лайвкодинг, а просто проверка навыков TDD.
У ТС их не было, поэтому он и провалил собеседование.
Захотят работодатели, чтобы соискатели хорошо писали код на бумажке — будут соискатели прокачивать этот навык — сидеть месяцами писать код на бумажках. Любой навык прокачивается.
Да, вместо этого можно было бы заниматься чем-то полезным для работы, да, уровень программистов для решения конкретных бизнес-задач снизится, да, опять начнутся разговоры о том, что программисты умеют только проходить собеседования, но не работать — но тут, как говорится, что хотели, то и получите.
Было одно собеседование, онлайн, по скайпу, имитация парного программирования. Именно что имитация, ибо я должен был играть роль Сеньора, а "напарник" — Джуниора. Актер из меня никудышный, но да ладно. "Джуниор" пытался изображать полного идиота, аля "ой, а тут деструктор виртуальный должен быть или нет". После десятка подобных вопросов я, подзабыв что это лишь игра, в нелестной форме спросил у "напарника" — кто тебя вообще нанял, если ты ни хрена не знаешь?
Короче, в контору эту не взяли, а на подобные "сексуальные игры" я с тех времён смотрю очень косо
У меня был опыт собеседования с игрой в руководителя(роль подразумевала рост через годик то некрупного тимлида). И это было вполне полезно для меня, потому что я тупо от стресса свалился в усвоенные в детстве и от прошлого руководства шаблоны руковождения которые сам же яро ненавижу.
Так что как минимум иногда такой ролеплей на собесе выглядит уместным. Хотя да, переигрывание оппонента в стиле "я работник и упрямо стою на своём "нихачу", пусть потенциальный начальник выкручивается"(человек отыгрывал зазвездившуюся "звезду", не желавшую быть на командном стендапе, в принципе вполне возможный случай) знатно мешают.
Это гораздо проще. Нет отвлекающего бубнежа «почему так?», «давай сделаем это».
Почему все так не делают?
Это так же лучше чем задания, на которые тратишь много часов, а потом получаешь отказ, так как потраченное время — фиксировано.
А некоторые вообще не палятся и в качестве вступительного задания предлагают сделать на халяву ресерч и выдать готовый прототип (я не про стандартные болванки, а именно про то что требует времени на ресерч).
Недавно вот проходил собеседование с лайвкодингом — задачка была небольшая, но вплоне интересная, в отличие от тестового задания она усложнялась по ходу интервью, что и весело и реалистично.
В целом это куда лучше чем подход в стиле — вот тебе дико упоротый кусок кода (который точно не пройдет ни одно вменяемое код-ревью) на бумажке, расскажи что он делает. С одного такого собеседования я ушел — откуда я знаю что этот код делает, мне не интересно думать о хреновом коде.
вот тебе дико упоротый кусок кода (который точно не пройдет ни одно вменяемое код-ревью) на бумажке, расскажи что он делает. С одного такого собеседования я ушел — откуда я знаю что этот код делает, мне не интересно думать о хреновом коде
С точки зрения собеседующего, это может являться признаком человека, который пишет Write-Only-Code.
Второе — явная проблема, а первое — ну просто никак.
Наоборот — понимание такого кода может говорить или о том что человек натренировался на таких штуках для собеседования или о том что он так и пишет.
… или о том, что человек умеет разбираться в чужом кривом коде. И вы сильно недооцениваете количество работодателей, которым среди кандидатов этот навык очень сильно нужен.
Или о том, что он регулярно приводит такой код к потребному виду.
Помню не так давно решил пособедоваться на С++ разработчика, меня начали грузить всякими подводными камнями из серии "что на самом деле произойдет, если написать вот такой вот говнокод", на мои резонные замечания о том, что давно уже есть тонна гайдлайнов, где множество раз написано, что так писать нельзя и так пишут только мудаки, мне возражали, что им важно знать насколько хорошо я понимаю, как работает память в плюсах.
Одна проблема, вопросы не то чтобы касались именно вопросов памяти, а скорее всяких граничных случаев, возникающих из за корявого проектирования самого языка.
Сами ведь они никогда такой говнокод точно писать не станут и в этой сложности нет никакого рокет сайнса, просто неудачный дизайн.
Тогда то я понял, что больше я уже никогда не смогу работать С++ разработчиком, а меня закономерно не взяли.
Помню еще был момент, когда меня просили рассказать, что же делает компилятор, когда сталкивается с виртуальным наследованием, которое как подход к проектированию уже давно предали анафеме и осталось оно лишь из за обратной совместимости, зачем спрашивать понимание в устаревшем говне, если оно годится только для того, чтобы его выкинуть на свалку и не прикасаться к нему?
зачем спрашивать понимание в устаревшем говне, если оно годится только для того, чтобы его выкинуть на свалку и не прикасаться к нему?
Чтобы не выкидывать, а переписать нормально.
Так давно уже переписали, сейчас это все уже сказки из склепа, куски виртуального наследования остались в каких-то стандартных классах типа ios, нигде в реальном коде я его уже лет 12 как не видел.
Но из за его наличия как раз вся эта пляска с this, когда указатель на метод != указатель на функцию, потому что нужно хранить еще таблицу переходов.
Так что используется, но делать так, конечно, не надо. Просто собеседования проводят те же программисты и в голове у них шаром покати обычно(на эту тему). Приходит HR и говорит, вот собес — давай придумывай как тестировать. Ну и что делать, вспоминают всякую хрень которую давно сами не используют.
Хуже того, они очень а детали зарываться любят, когда вместо сути проблемы начинается докапывание до мелочей, специфичных для какого то компилятора, при этом интервьювер может даже не задумываться о том, что UB то компилятороспецифичная вещь и просто без задней мысли просить рассказать, что в результате него случится.
наверное, если бы мне пришлось бороться с такими эмоциями я бы начал больше рассказывать о том, что хочу сделать, чем писать, просто чтобы поймать на крючок интереса.
Наверное, не все могут совмещать режимы написания кода и даже думания о чьих-то там интересах...
Просто отложите наушники и выключите микрофон. Дальше сидишь и пишешь код, как знаешь. Как закончил, берешь наушники и говоришь, что закончил.
Я именно так и делал.
habr.com/ru/company/deliveryclub/blog/522326
Представьте, что вы — блоггер. Поставьте программу для записи видео с экрана (плюс накладывание видео с вебки), включите запись, возьмите микрофон, откройте первую попавшуюся задачу на литкоде и решайте её как-будто вы это видео потом зальёте на ютюб. Объясняйте своим «слушателям» что вы делаете и почему. По окончанию этого процесса откройте полученное видео и посмотрите. Сразу вылезет десяток очевидных ляпов: тут камера не настроена, тут свет плохой, тут микрофон низы вырезает, тут я что-то бекаю-мекаю. Исправляем косяки. Записываем второе видео с другой задачей.
После 5-8 итераций можно идти на лайф-кодинг.
Для меня лучший вариант собеседование это лайвкодинг. Не люблю когда показывают вырваный из контекста, какой-то кусок гавнокода, который я бы никогда не написал в здравом уме, и спрашивают как оно работает, всегда хочется пошутить «это вы из проекта надергали?». Я сам могу столько трики-кода нагенерить что хватит уволить всю вашу команду.
Последние 5 лет я ни разу не использовал финалайзер. Стажером он мне тем более был побоку. Это со мной что-то не так или «это необходимое знание даже для стажера» только потому, что этопрос с золотого (коричневого) фонда вопросов на собеседовании?
Я пришел на собеседование с лайвкодингом — и меня с позором размазали