Суть проблемы с null была не на этапе десериализации Jackson'ом, а в момент вызова API: Rest-Assured просто не давал отправить null. Судя по этому issue (https://github.com/rest-assured/rest-assured/issues/942), сталкивался с данной проблемой не только я.
Удаленная, как и очная работа бывает разной. В офисе вам могут предложить свободный график, а могут потребовать быть «от и до». Тут уж каждый сам решает, соглашаться ему на такие условия или нет.
Как и у других компаний на рынке, у нас есть некая отработанная схема, которую мы предлагаем кандидатам на вакансии. С удовольствием сотрудничаем с теми, кого она устраивает. Готовы к компромиссам в разумных пределах.
В статье описана некая общая схема командной работы. И команда здесь — ключевой момент. Членам этой команды для успешного достижения поставленных целей необходимо время от времени взаимодействовать между собой.
Описанная вами схема — с задачами на несколько дней или даже на неделю — у нас тоже может существовать для разработчиков в рамках отдельных проектов (при соблюдении определенных условий), либо для тестировщиков. К примеру, последние могут взять задачи на тестирование на неделю, самостоятельно с ними справиться в любое удобное время, а результаты занести в трекер.
Но мы делаем акцент именно на командной работе, поэтому и пишем о ней.
Мы не требуем 8 часов непрерывного кодинга, если вы об этом. Рабочий процесс включает планирование, изучение новых технологий, code review для разработчиков и автоматизаторов тестирования и т.п. Все это закладывается на этапе оценки проекта.
В доступе к лучшим кадрам. В возможности не привязываться к физическому месту работы. Это многие уже считают роскошью 21 века. Мы ценим эту свободу, которая, безусловно, требует повышенной ответственности.
Основной стек, с помощью которого решаем задачи клиентов:
1. Java / Kotlin / Scala.
2. Angular 2 и выше, React.
3. Python.
4. QA Automation (Java и Python).
Это по сути подход в котором идет отказ от робота. И тогда не понятно к чему эта статья была
Статья просто об опыте столкновения с роботом, а не о рекомендации к использованию)
Я не особо понял из поста в чем смысл второго подхода. То есть сами тесты пишутся на питоне и вызываются как киворды? Какой-то кейс не очень, не проще ли сразу что-то человеческое использовать для разработки тестов на самом питоне?
Это подобно связке Java + Cucumber получается. Больше фишка для «манагеров»
Вот это очень больно и даже через чур. Не уж то в роботе есть что-то такое чего нет в самом питоне?
Спасибо за грамотный комментарий. Отмечу, что мы не перегибаем тут палку, и наши рекрутеры не программируют, поэтому такие вопросы в принципе не могут спросить.
Про сравнение альтернативных решений — хороший вопрос для Senior. Передал нашему техн. директору идею, мне лично она нравится. Что-то подобное я делаю при собеседованиях РП: даю живой кейс, и пока только один из 30-40 кандидатов смог адекватно его решить.
Коллега, чтобы делать такие жирные отверждения, надо знать нашу бухгалтерскую отчетность. Я ее знаю, мы анализируем рынок труда, но, признаюсь, я не видел объективных данных по уровням зарплат в РФ. Разве что про Москву и Питер понятнее, но на этих мегаполисах свет клином не сошелся. Я знаю одного разработчика, который при доходе в 250-300 тыр в Питере не может заставить себя работать уже не один год и удивляется, что его не уволили. Это к слову. Вот 2 утверждения с элементами инсайда: 1) некоторые наши сотрудники увеличили доход в 2 и более раз, перейдя к нам. Один пришел из СберТеха. 2) мы платим не ниже среднего по рынку, это чушь. Ну и третье утверждение добавлю: у нас есть система планирования долгосрочного взаимовыгодного сотрудничества, где мы открыто обсуждаем результаты, цели личные и компании и, конечно же, уровень дохода. При росте компании и повышении удельной прибыли (и снижении влияния рисков за счет экономики масштаба) будет расти доход тех, кто дает результат и растет профессионально вместе с компанией. А расти есть куда: большинство специалистов не говорят на английском, не думают о проектных рисках, не умеют точно оценивать трудоемкость задач (и проекта в целом), не умеют общаться с клиентами… я могу продолжить.
Касательно плохо сделал работу: решает не менеджер, а коллеги (Code Review), тестеры (много багов) и product owner (не осилил требования, и сделал не то, что нужно).
По срокам: их определяет сам разработчик. В случаях, когда выполняется дольше, происходит анализ ситуации. Есть и те, кто хронически перезакладывается, выполняя быстрее по факту. Навык оценки трудозатрат развит у большинства разработчиков.
В таких случаях финансовых санкций не предусмотрено, у нас нет системы штрафов (одну такую я видел на последнем месте работы в роли наемного руководителя, и стоило немалых сил убрать эту глупость). При этом мы не позволим «вытирать о нас ноги». Мы расстанемся с теми, кто решит забить на свои обязательства и будет вешать лапшу, проваливая сроки. Один такой случай был, и мы чуть не потеряли клиента, спасибо другому специалисту, кто оперативно ликвидировал недочеты и закрыл проект. Мы стараемся очень аккуратно нанимать, это занимает время, это не дешево, но после ряда уроков мы будем быстро расставаться с теми, кто не способен выдержать взятые на себя обязательства и кого бесполезно сначала «полечить».
Арбитраж происходит просто: я собираю факты, общаюсь со всеми сторонами и принимаю решение, потому что я, как генеральный директор и совладелец, буду за это решение платить.
Спасибо за комментарий. Писал выше, но повторюсь. Эта проверка нацелена на отсев тех, кто думать не хочет или не может. И вопросы простые, наши рекрутеры не дают кейсы из проектов, где надо искать оптимальное решение…
Спасибо за комментарий. Осталось понять, каких людей больше — кто мыслит как я или как Вы. :-) Но в целом тренд на конкретику очевиден. Мы учтем замечания насчет объединения Middle/Senior в 1 вакансию и отражения возможного уровня дохода. Также очевидно, что если бы мы платили Senior 70-100 тыр, как тут некоторые предположили, то не смогли бы делать проекты большой сложности. Еще раз благодарю за высказанное мнение.
Кратко: проекты одинаковые, задачи разные, скорость выполнения с учетом переделок после Code Review & Acceptance Testing — тоже разная, может в разы отличаться. В целом Senior мы понимаем так: способен самостоятельно сделать большой функционал. Пример: какая-то серверная компонента в высоко нагруженном распределенном приложении, взаимодействующая с другими компонентами решения. Middle это вряд ли сделает, ему задачи надо давать поменьше, его кругозор уже, опыта меньше, решения взвешенные принимать скорее всего не сможет. Но на ряде проектов найдется и для Middle задачи, если сроки и бюджет позволяют.
Мы регулярно пересматриваем то, что работает, а что нужно изменить. Это предложение рассмотрим на очередной планерке, и, возможно, внесем коррективы, если коллеги его поддержат. В любом случае спасибо за комментарий.
Мы развернуто ответили по этой теме в комментарии к сообщению пользователя i360u. Тут лишь дополню, что про копирование массива int в цикле — из реального опыта. Помню также, что это вызывалось по событиям repaint, где надо было график перерисовывать. Написан этот код был до момента, как я начал руководить командой, но с разработчиком после короткого разговора, где я вскрыл целостный подход писать код так, лишь бы работало, я расстался незамедлительно.
Интересно было почитать ваше общение с VolCh. Позволю добавить пару моментов. Во-первых, решения, которые предложат в самом начале, скорее всего были в «кэше» мозга, т.е. взяты из статей или недавних проектов. Это быстрые ответы, их все дают, за редким исключением. А вот решения, которые надо еще предложить, рождаются в голове и требуют мозговых усилий. Во-вторых, для нас также важно смотреть на то, как человек мыслит. Это важнее предложенных ответов и их количества, как можно уже догадаться. В-третьих, в боевых условиях я предпочитаю обсуждать не проблемы, а получить изложение фактов и набор ПРОДУМАННЫХ решений с обоснованием использования одного из них. И чем больше будет вариантов проработано до общения со мной, тем качественнее будет решение.
Надеюсь, что я исчерпывающе ответил на все поднятые вопросы.
Спасибо за полезный комментарий. Мы такой формат совмещения Middle/Senior сделали не так давно. Если наша ЦА думает также, как и Вы (а мы протестируем гипотезу), то изменим подход и внесем коррективы. Мне с математическим багажом отсутствие ограничителя сверху говорит, что компания готовы общаться и обсуждать пожелания сотрудника. Если, к примеру, это окажется в 1.5 раза больше того, что мы готовы платить, и специалист с амбициями, то мы свяжемся после, если/когда у нас изменится ситуация. Мы — молодая компания, и к нам не стоит очередь из идеальных клиентов, желающих иметь с нами долгосрочные отношения на выгодных условиях. Да, мы много инвестируем в маркетинг и продажи, чтобы у нас были такие клиенты и проекты (тоже важно, чтобы без легаси, это отпугивает кандидатов), но пока что мы еще не в «эльдорадо» (если оно вообще есть). При этом у компании есть четкий фокус, стратегия, и в 2019 я ожидаю хороших результатов от наших инвестиций в маркетинг и продажи.
Удаленная, как и очная работа бывает разной. В офисе вам могут предложить свободный график, а могут потребовать быть «от и до». Тут уж каждый сам решает, соглашаться ему на такие условия или нет.
Как и у других компаний на рынке, у нас есть некая отработанная схема, которую мы предлагаем кандидатам на вакансии. С удовольствием сотрудничаем с теми, кого она устраивает. Готовы к компромиссам в разумных пределах.
В статье описана некая общая схема командной работы. И команда здесь — ключевой момент. Членам этой команды для успешного достижения поставленных целей необходимо время от времени взаимодействовать между собой.
Описанная вами схема — с задачами на несколько дней или даже на неделю — у нас тоже может существовать для разработчиков в рамках отдельных проектов (при соблюдении определенных условий), либо для тестировщиков. К примеру, последние могут взять задачи на тестирование на неделю, самостоятельно с ними справиться в любое удобное время, а результаты занести в трекер.
Но мы делаем акцент именно на командной работе, поэтому и пишем о ней.
1. Java / Kotlin / Scala.
2. Angular 2 и выше, React.
3. Python.
4. QA Automation (Java и Python).
Статья просто об опыте столкновения с роботом, а не о рекомендации к использованию)
Это подобно связке Java + Cucumber получается. Больше фишка для «манагеров»
Неа. Полагаю, что так «исторически» сложилось
Про сравнение альтернативных решений — хороший вопрос для Senior. Передал нашему техн. директору идею, мне лично она нравится. Что-то подобное я делаю при собеседованиях РП: даю живой кейс, и пока только один из 30-40 кандидатов смог адекватно его решить.
Касательно плохо сделал работу: решает не менеджер, а коллеги (Code Review), тестеры (много багов) и product owner (не осилил требования, и сделал не то, что нужно).
По срокам: их определяет сам разработчик. В случаях, когда выполняется дольше, происходит анализ ситуации. Есть и те, кто хронически перезакладывается, выполняя быстрее по факту. Навык оценки трудозатрат развит у большинства разработчиков.
В таких случаях финансовых санкций не предусмотрено, у нас нет системы штрафов (одну такую я видел на последнем месте работы в роли наемного руководителя, и стоило немалых сил убрать эту глупость). При этом мы не позволим «вытирать о нас ноги». Мы расстанемся с теми, кто решит забить на свои обязательства и будет вешать лапшу, проваливая сроки. Один такой случай был, и мы чуть не потеряли клиента, спасибо другому специалисту, кто оперативно ликвидировал недочеты и закрыл проект. Мы стараемся очень аккуратно нанимать, это занимает время, это не дешево, но после ряда уроков мы будем быстро расставаться с теми, кто не способен выдержать взятые на себя обязательства и кого бесполезно сначала «полечить».
Арбитраж происходит просто: я собираю факты, общаюсь со всеми сторонами и принимаю решение, потому что я, как генеральный директор и совладелец, буду за это решение платить.
Надеюсь, что я исчерпывающе ответил на все поднятые вопросы.