Все что вы пишите работает только при одном условии — если ваш работодатель думает, что без оффера вы блефуете и после его отказа не уйдете.
У Вас, наверно, рынок перегрет: вакансий мало, а желающих много, раз работодателям проще потерять кандидата и искать нового, чем немного поторговаться. Мой совет — если не хотите с этим мириться, переезжайте.
все мои работодатели всегда твердо знают, что если по вопросу условий работы мы не договорились, то можно сразу не терять время и переходить к обсуждению условий прекращения сотрудничества.
В смысле «не договорились»?! Я так понял, до обсуждений дело не доходит. Вы имели в виду «что если не взял что дают»? Это такое. Всех благ таким работодателям и успехов с поиском работников. Если, конечно, у Вас из достижимых мест работы только одна контора, то, да, ничего не сделаешь, надо переезжать.
Вот смотрите, Вы сами что-нибудь когда-нибудь продавали? Например, машину? Если нет, я Вам доложу: большинство людей первоначальный ценник ставят выше цены, которая бы их устроила, закладывая запас на торг. Приедет покупатель, начнет придираться: «тут скол, там затерто...» А Вы ему скидку. ВСЕ довольны: Вы получили свои деньги, покупатель заплатил меньше. Намного хуже, когда Вы упретесь рогом и ни сколько уступать не станете. Многих покупателей просто подход такой заставит уйти и поискать другого продавца. Торговаться — это нормально.
И с компаниями так же: когда дают оффер, обычно закладывают процент от него на торги: работнику намного приятнее будет работать, думая, что он «выбил» большие деньги, нежели когда ему в грубой форме отказали, «показав его место».
Я не знаю где Вам доводилось работать, но процесс переговоров насчет условий контракта во всем цивилизованном мире считается нормальным. В некоторых компаниях даже никаких контрофферов не надо, достаточно просто попросить немного прибавить (но надо таки уметь делать это вежливо, это тоже показывает уровень вашей адекватности). Но если есть контора, где Вы бы действительно хотели работать, но она Вам дала, по Вашему мнению, слабый оффер и есть другая, готовая дать больше, почему бы не попросить первую хотя бы заматчить оффер второй?! Все равно идти куда хотел работать за сколько дали не всегда возможно: во-первых, это демотивирует, во-вторых, есть внешние факторы (например, жена), которые могут давить на Вас взять самый денежный оффер не смотря ни на какие нематериальные бенефиты.
Ваше сравнение — херня на постном масле. Умение читать — это базовый навык, которому учат в первом классе школы. Никаких дополнительных навыков для чтения художественной литературы не требуется. Умение читать код (как и понимание основ CS, знание синтаксиса языков программирования) — это далеко не базовый навык, которому учат всех. Чтение кода — это отнюдь не праздное развлечение, чтобы «пойду-ка я кода перед сном почитаю». Это специальный навык, которому люди учатся целенаправленно. Болле того, чтение кода — это не отдельная дисциплина, чтобы этому учиться. Нет отдельных классов для обучения чтению кода, а отдельных — для написания кода. Это все — часть обучения программированию. Также, чтобы хорошо запоминать как работают вещи, ими надо пользоваться. Никакое обучение, не подкрепленное практикой, не будет эффективным.
И если Вы говорите, что не практикующий программист находит ТАКИЕ баги, которые не может найти практикующий программист (одинакового уровня, давайте не сравнивать лид тестировщика с джуниор программистом), то это или патология, или, я не знаю, обезьянка, обученная находить конкретные типовые проблемы, не понимая, что в целом происходит.
Ну и напомню, что мы таки говорили про отсечении плохих программистов на собеседовании. Если у Вас мега звезда в, например, тестировании, зачем ей идти собеседоваться на программиста?!
Не знаю, какая патология была у Вашего персонажа, может, у него были недоразвиты руки и он до клавиатуры не дотягивался, или ему религия не позволяла писать код, но это скорее исключение, чем правило. Чтобы быстро разбираться в чужом коде, нужна инженерная интуиция, знания и большой опыт.
Кстати, интервью, когда тебе дают код и надо в нем пофиксить ошибки или добавить функциональность — IMO, одни из самых интересных и полезных, чтобы понять, как человек сможет выполнять свои обязанности.
Это все — отличные темы для разговора на собеседовании и возможность показать Вашу осведомленность про разные особенности реализации стеков и уточнить какие компромиссы мы хотим сделать в разрабатываемом стэке. Будет ли он фиксированного размера или будет расти безгранично. Какая сложность должна быть у операций (например, если стэк не фиксированного размера, будем ли мы просто делать realloc на внутренний массив (O(n)) или надо выделять память чанками (O(1)), будем ли мы возвращать память обратно, если она не нжна).
Как уже сказали, что под NDA — зависит от условий контракта. У меня самого был такой случай: писали мы продукт на работе и в веб части пользовались известной библиотекой для валидации данных от пользователя. В какой-то момент нашли в продукте баг, оттрейсили его до этой библиотеки. Я сделал патч для нее и отослал PR в ее репозиторий. Мэйнтейнер согласился, что это была плохо продуманная функциональность, которая в определенных случаях ломает все остальное, но, поскольку эта фича была уже публчная, надо ждать мажорного релиза, чтобы убрать ее. В итоге мы на работе форкнули проект и поддерживали свой внутренний форк с нужным нам фиксом. Далее, после нескольких дополнительных проблем с этой библиотекой, я сел и за выходные написал свою библиотеку валидации, выложил на Github (под MIT лицензией), а потом на работе предложил перейти на нее. И последующие доработки моей библиотеки я уже делал на работе, потому что нужно было для нужд компании. У компании был код без багов, возможность чинить баги быстро (ибо мэинтейнер библиотеки работает в компании), у меня — еще один опенсорс проект в мое Github портфолио.
Когда оцениваются офферы, люди, обычно, учитывают много разных факторов. И технологии, и проекты, и компенсация, и команда, и расположение офиса, и перспективы роста, и, что немаловажно, адекватность начальства. Если начальство не умеет вежливо отказывать, например, запросам на повышение заработной платы и вместо этого увольняет сотрудника, это большой красный флаг.
Там выше цитату приводили, что надо писать мало того, что минимальный, но еще и production(не знаю, как на русский перевести), коим return 3 врядли является. Вот если бы return 42, но он тест не пройдет.
production он в том плане, что это не код тестов, а код, собственно, продукта. И это вполне валидный продакшен код, соответствующий спецификации (которая требует, чтобы в итоге результат был «3»).
если я сначала напишу набор тестов на граничные случаи, которые взбредут в голову, потом код, который их последовательно закрывает, то это все равно можно назвать TDD.
Лично я делаю так: пишем некий код. Потом задаемся вопросом: «делает ли этот код то, что я хочу?». Пишем тест. Проверяем. Поправляем, если не делает. А если я вот так позову, должно вот такое возвращать. Если вот так — вот такое. Нет этих глупых ограничений, что тест должен быть изначально сломан. Есть нюансы в том, чтобы убедиться, что Вы пишете правильные тесты, которые тестируют именно то, что Вы думаете оно тестирует. Обычно я просто изменяю тот кусок, который я думаю оно должно тестировать на заведомо неправильный и убеждаюсь, что тест сломался.
Не знаю, что там Вам кандидат сказал, что такая реакция. Конечно, когда просишь больше и грозишься уйти в другую контору надо быть готовым, что какие-то конторы таки соскочат. Поэтому, как я говорил ранее, надо иметь несколько офферов.
Я думаю, для того кандидата отказ Вашей конторы не был концом света и он благополучно трудоустроен.
Мы про TDD говорим, а не про интервьюеров. На интервью надо все руками писать, без библиотек, потому что вся суть задания — посмотреть, как кандидат пишет код руками, а не пользуется готовыми решениями или копирует со стэковерфлоу, даже если есть готовые решения.
Без оффера Вы можете просто уйти. Обычно компании не поднимают офферы на пустом месте. Скажете «хочу больше», чаще всего получите ответ «мы считаем, это адекватное и конкурентное предложение». Конечно, вы можете с порога заявить свой ценник и или с Вами даже разговаривать дальше не будут, или дадут ровно столько, сколько Вы попросили, и Вы, возможно, проиграете, если компания могла предложить Вам больше. Поэтому, фиксированную сумму считается невыгодно говорить. Говорят, обычно, диапазон. Далее, если Ваш диапазон пересекается с вилкой вакансии компании, они начнут процесс собеседования, а имея другие офферы можно подобраться к верхнему пределу вилки компании.
А вот «у меня тут предложение от конкурентов» — это сразу безвозвратное «до свидания». В хороших местах крайне редко бывают востребованы люди с таким менталитетом.
Все искусство в том, как это сказать. Вообще, проблема в менталитете людей с постсоветского пространства, где такое поведение считается чем-то плохим.
Также учитывайте, что часто люди ищут новую работу, чтобы получить прибавку к ЗП и, естественно, люди хотят получить больше. Также, поиск хорошего кандидата — это часто долго и дорого. Очень дорого.
Конкретно для реализации сложения и вычитания — да. А если Вам надо будет поддержать сложные выражения и/или оптимизацию выражения для частых вычислений и JIT компиляции прямо в машинный код, наколеночное решение тут же проиграет.
На парсер-генератора/модной парсинг либе это чтобы быстро написать, а не чтобы быстро работало.
Не согласен. Допустим, вы транслируете выражение в LLVM байткод, а LLVM генератор выдает Вам машинный код. И вот оно уже работает быстро.
Эм, с чего бы? Вероятно я вас не понимаю, вы не могли бы привести пример, какие «недоалгоритмы» понадобятся, чтобы написать тесты на калькулятор?
Ну, хотя бы, что на первый тест 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 — нездоровый фанатизм.
И если не секрет, то в чем здесь проблема? В .net я обычно пишу либо интерфейс без реализации, на него тест, и далее реализация. Либо метод с NotImplementedException, на него тест, далее реализация.
Здесь скорее отсылка к тому, что на первый простейший тест у Вас реализация будет простая — вернуть константу. Потом Вы реализуете какой-нибудь наколеночный парсинг выражений, потом будете добавлять-добавлять и в конечном итоге упретесь в то, что, чтобы это работало быстро, надо все выкинуть и переписать на каком-нибудь парсер-генераторе/модной парсинг либе. И получится, что в один шаг надо большую часть реализации переделать/выбросить все ранее написанное. Или, например, реализация более-менее понятна, известный алгоритм с небольшими модификациями. И тут TDD, и нельзя просто взять и написать алгоритм. Надо ментально нарезать его на какие-то мелкие шаги, которые бы работали инкрементально, но чтобы не писать лишнего для отдельного шага. Потому что по TDD нельзя писать лишний код и нельзя писать тесты, которые уже работают (не сломаны).
У Вас, наверно, рынок перегрет: вакансий мало, а желающих много, раз работодателям проще потерять кандидата и искать нового, чем немного поторговаться. Мой совет — если не хотите с этим мириться, переезжайте.
В смысле «не договорились»?! Я так понял, до обсуждений дело не доходит. Вы имели в виду «что если не взял что дают»? Это такое. Всех благ таким работодателям и успехов с поиском работников. Если, конечно, у Вас из достижимых мест работы только одна контора, то, да, ничего не сделаешь, надо переезжать.
Вот смотрите, Вы сами что-нибудь когда-нибудь продавали? Например, машину? Если нет, я Вам доложу: большинство людей первоначальный ценник ставят выше цены, которая бы их устроила, закладывая запас на торг. Приедет покупатель, начнет придираться: «тут скол, там затерто...» А Вы ему скидку. ВСЕ довольны: Вы получили свои деньги, покупатель заплатил меньше. Намного хуже, когда Вы упретесь рогом и ни сколько уступать не станете. Многих покупателей просто подход такой заставит уйти и поискать другого продавца. Торговаться — это нормально.
И с компаниями так же: когда дают оффер, обычно закладывают процент от него на торги: работнику намного приятнее будет работать, думая, что он «выбил» большие деньги, нежели когда ему в грубой форме отказали, «показав его место».
Я не знаю где Вам доводилось работать, но процесс переговоров насчет условий контракта во всем цивилизованном мире считается нормальным. В некоторых компаниях даже никаких контрофферов не надо, достаточно просто попросить немного прибавить (но надо таки уметь делать это вежливо, это тоже показывает уровень вашей адекватности). Но если есть контора, где Вы бы действительно хотели работать, но она Вам дала, по Вашему мнению, слабый оффер и есть другая, готовая дать больше, почему бы не попросить первую хотя бы заматчить оффер второй?! Все равно идти куда хотел работать за сколько дали не всегда возможно: во-первых, это демотивирует, во-вторых, есть внешние факторы (например, жена), которые могут давить на Вас взять самый денежный оффер не смотря ни на какие нематериальные бенефиты.
Ну, мы уже про Вас все поняли. Осталось только озвучить название компании и можно расходиться.
Ваше сравнение — херня на постном масле. Умение читать — это базовый навык, которому учат в первом классе школы. Никаких дополнительных навыков для чтения художественной литературы не требуется. Умение читать код (как и понимание основ CS, знание синтаксиса языков программирования) — это далеко не базовый навык, которому учат всех. Чтение кода — это отнюдь не праздное развлечение, чтобы «пойду-ка я кода перед сном почитаю». Это специальный навык, которому люди учатся целенаправленно. Болле того, чтение кода — это не отдельная дисциплина, чтобы этому учиться. Нет отдельных классов для обучения чтению кода, а отдельных — для написания кода. Это все — часть обучения программированию. Также, чтобы хорошо запоминать как работают вещи, ими надо пользоваться. Никакое обучение, не подкрепленное практикой, не будет эффективным.
И если Вы говорите, что не практикующий программист находит ТАКИЕ баги, которые не может найти практикующий программист (одинакового уровня, давайте не сравнивать лид тестировщика с джуниор программистом), то это или патология, или, я не знаю, обезьянка, обученная находить конкретные типовые проблемы, не понимая, что в целом происходит.
Ну и напомню, что мы таки говорили про отсечении плохих программистов на собеседовании. Если у Вас мега звезда в, например, тестировании, зачем ей идти собеседоваться на программиста?!
Не знаю, какая патология была у Вашего персонажа, может, у него были недоразвиты руки и он до клавиатуры не дотягивался, или ему религия не позволяла писать код, но это скорее исключение, чем правило. Чтобы быстро разбираться в чужом коде, нужна инженерная интуиция, знания и большой опыт.
Кстати, интервью, когда тебе дают код и надо в нем пофиксить ошибки или добавить функциональность — IMO, одни из самых интересных и полезных, чтобы понять, как человек сможет выполнять свои обязанности.
Прям даже интересно стало, в каких конторах так все хорошо.
Да у Вас, судя по всему, ЧСВ зашкаливает. С такими диагнозами в любой приличной конторе завернут по софт скилам. И даром все Ваши стэки оверфлоу..
Это все — отличные темы для разговора на собеседовании и возможность показать Вашу осведомленность про разные особенности реализации стеков и уточнить какие компромиссы мы хотим сделать в разрабатываемом стэке. Будет ли он фиксированного размера или будет расти безгранично. Какая сложность должна быть у операций (например, если стэк не фиксированного размера, будем ли мы просто делать realloc на внутренний массив (O(n)) или надо выделять память чанками (O(1)), будем ли мы возвращать память обратно, если она не нжна).
Когда оцениваются офферы, люди, обычно, учитывают много разных факторов. И технологии, и проекты, и компенсация, и команда, и расположение офиса, и перспективы роста, и, что немаловажно, адекватность начальства. Если начальство не умеет вежливо отказывать, например, запросам на повышение заработной платы и вместо этого увольняет сотрудника, это большой красный флаг.
production он в том плане, что это не код тестов, а код, собственно, продукта. И это вполне валидный продакшен код, соответствующий спецификации (которая требует, чтобы в итоге результат был «3»).
Лично я делаю так: пишем некий код. Потом задаемся вопросом: «делает ли этот код то, что я хочу?». Пишем тест. Проверяем. Поправляем, если не делает. А если я вот так позову, должно вот такое возвращать. Если вот так — вот такое. Нет этих глупых ограничений, что тест должен быть изначально сломан. Есть нюансы в том, чтобы убедиться, что Вы пишете правильные тесты, которые тестируют именно то, что Вы думаете оно тестирует. Обычно я просто изменяю тот кусок, который я думаю оно должно тестировать на заведомо неправильный и убеждаюсь, что тест сломался.
Не знаю, что там Вам кандидат сказал, что такая реакция. Конечно, когда просишь больше и грозишься уйти в другую контору надо быть готовым, что какие-то конторы таки соскочат. Поэтому, как я говорил ранее, надо иметь несколько офферов.
Я думаю, для того кандидата отказ Вашей конторы не был концом света и он благополучно трудоустроен.
Мы про TDD говорим, а не про интервьюеров. На интервью надо все руками писать, без библиотек, потому что вся суть задания — посмотреть, как кандидат пишет код руками, а не пользуется готовыми решениями или копирует со стэковерфлоу, даже если есть готовые решения.
И, да, не беспокойтесь, безработица мне не грозит.
Все искусство в том, как это сказать. Вообще, проблема в менталитете людей с постсоветского пространства, где такое поведение считается чем-то плохим.
Также учитывайте, что часто люди ищут новую работу, чтобы получить прибавку к ЗП и, естественно, люди хотят получить больше. Также, поиск хорошего кандидата — это часто долго и дорого. Очень дорого.
Не согласен. Допустим, вы транслируете выражение в LLVM байткод, а LLVM генератор выдает Вам машинный код. И вот оно уже работает быстро.
Ну, хотя бы, что на первый тест assertEqual(3, eval(«1+2»)); по TDD надо написать минимальный код, который починит тест, которым является return 3; Чтобы прийти к return a+b; надо написать минимум два теста. Соответственно, «return 3» тот самый выброшенный код.
Этот пример, конечно, упрощение, и в реальном мире все сразу напишут return a+b; что будет отступлением от канонов TDD. А если мы разрешаем пропускать шаги и писать больше кода, чем это требуют тесты, то легко пропустить юзкейсы, которые надо было бы зафиксировать в тестах (чтобы убедиться, что они все еще будут работать при последующих рефакторингах), потому что юзкейсы-то уже покрыты и тесты не сломаны.
Это может было озвучено немного неправильно, но, по сути, это так: в TDD 1) надо писать тест вперед, 2) тест изначально должен быть сломан, 3) надо писать минимальный код, чтобы сделать тест работающим. Если принять, что краевые случаи требуют отдельного кода для обработки, то вышесказанное верно.
Так что достали прямо из пузика TDD.
Ну, по TDD у Вас оно всегда должно быть 100%. Вывод: TDD — нездоровый фанатизм.
Здесь скорее отсылка к тому, что на первый простейший тест у Вас реализация будет простая — вернуть константу. Потом Вы реализуете какой-нибудь наколеночный парсинг выражений, потом будете добавлять-добавлять и в конечном итоге упретесь в то, что, чтобы это работало быстро, надо все выкинуть и переписать на каком-нибудь парсер-генераторе/модной парсинг либе. И получится, что в один шаг надо большую часть реализации переделать/выбросить все ранее написанное. Или, например, реализация более-менее понятна, известный алгоритм с небольшими модификациями. И тут TDD, и нельзя просто взять и написать алгоритм. Надо ментально нарезать его на какие-то мелкие шаги, которые бы работали инкрементально, но чтобы не писать лишнего для отдельного шага. Потому что по TDD нельзя писать лишний код и нельзя писать тесты, которые уже работают (не сломаны).