• Тонкости собеседований при найме на удаленку
    0
    У каждого кандидата мы запрашиваем контакты людей с прошлых мест работы, которые могли бы дать рекомендации. Но чаще обратная связь положительная. Мы предполагаем, что кандидаты стараются давать контакты лояльных «сослуживцев» (иногда даже друзей). Откровенно говоря, мы даже не можем законно проверить, является ли этот человек, например руководителем. Допустим, кандидат дал телефон своего друга-коллеги, который во время звонка представится его начальником. Естественно, он даст о нем наилучший отзыв. А на расследования у нас нет ни времени, ни ресурсов. Для бизнеса проще и дешевле выработать собственную процедуру оценки кандидатов.
  • Тонкости собеседований при найме на удаленку
    0
    Нет, но и тут все определяется уровнем и навыками.
  • Тонкости собеседований при найме на удаленку
    0
    Вообще опасно полагаться исключительно на субъективное мнение в коротком разговоре, да еще и в удаленном режиме. Все эти лайфхаки по примеру сериала «Lie to me» научной базы под собой не имеют. Очень легко промахнуться из-за чрезмерной веры в собственную проницательность.
  • Тонкости собеседований при найме на удаленку
    0
    Напрямую — нет. Но мы ориентируемся на миддлов и сениоров, а опыт, который позволяет перейти на эти уровни, формируется не за один год. Поэтому к нам приходят в основном сотрудники старше определенного возраста. Но есть и исключения.
    Однако студентов у нас нет по понятным причинам.
  • Тонкости собеседований при найме на удаленку
    +1
    Забавная история.
    Кандидаты, с которыми мы общаемся, зачастую используют 2 монитора (как и большинство действующих сотрудников компании). Так что у нас фокус с наблюдением за глазами изначально не работает.
  • Тонкости собеседований при найме на удаленку
    0
    По личному опыту самую адекватную работу в it находил после десяти минут разговора с лидом...

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

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

    Такая проблема в рекрутинге действительно существует. Все просто — в таких компаниях у рекрутеров (менеджеров) есть KPI, завязанные на количество собеседований. А у нас такого нет.
  • Почему я сменил фриланс на удаленную команду
    +1
    5490 — со встроенным LTE-модемом, что немаловажно для удаленки.
  • Почему я сменил фриланс на удаленную команду
    +1
    Спасибо за отклик!
    Команды строятся по-разному — как и в офисах. Я сталкивался с теми, где ждут Middle+.
    На удаленке самому джуну будет тяжело, поскольку формат подразумевает определенную степень автономности, даже при работе в команде (по сравнению с офисом). Надо иметь достаточно опыта и уметь принимать решения.
    Лично я искал удаленную работу через хедхантер. Честно говоря, не помню, кто кого нашел первым: команда меня или я команду. Но это точно была не единственная полностью удаленная вакансия, на которую я откликался. Сама идея распределенных команд активно развивается.
  • Как и зачем поддерживать физическую форму, если ты ИТ-шник на удаленке
    0
    Приложение в App Store, называется «Раз в час».
  • Тест: подходит ли тебе удаленка (не фриланс!)?
    +1
    Тут дело, думаю, не в удалёнке.
    Если двигателем продуктивности была боязнь осуждения коллег… короче, тут нужен подробный самоанализ или обстоятельная беседа, но никак не один комментарий с Хабра.
  • Тест: подходит ли тебе удаленка (не фриланс!)?
    0
    Напрямую не связан, но это часть вопроса про самодисциплину и баланс между работой и отдыхом.
  • Тест: подходит ли тебе удаленка (не фриланс!)?
    +1
    Ой, действительно. Спасибо;)
  • Тест: подходит ли тебе удаленка (не фриланс!)?
    –3
    Либо «да» на все, либо «нет». Это же список стопов, один сработал — всё, на выход
  • Теория и практика хобби для ИТ-шника
    0
    В том и суть, что чувствовать приходится через отдачу руля и глазами (если можно так сказать). Понятное дело, что чем лучше оборудован симулятор — тем лучше симуляция :) Но мне точно F1 не светит. А для изучения траектории и базовой теории быстрого вождения даже такое бюджетное решение подходит более чем
  • Теория и практика хобби для ИТ-шника
    0
    При движении по гоночному треку едва ли ты когда-нибудь (кроме дрифта) выворачиваешь руль в лок. Суть симуляторов не повернуть руль на полтора оборота, а в том чтобы «прочувствовать» как «работает шина» и в какой момент начинается увод. Я, конечно, не эксперт, но например тот же Горбачев в гоночной теории никогда не завязывался на количество оборотов руля. А говорил о шине как таковой. В автоспорте все не так просто, как может показаться на первый взгляд…
  • Теория и практика хобби для ИТ-шника
    0
    Я бы не сказал «никто не использует». Большинство профессиональных гоночных команд все равно тренирует своих пилотов в межсезонье на симуляторах.
    И дело не в оборотах руля, а в качестве отдачи (ForceFeedback), которую обеспечивает контроллер. Есть разные типы приводов и рулей. Можно угореть и купить руль за 100+ тысяч (что-то от fanatech). Там будет и правда качественный привод, и более менее достоверная передача моментов.
    А «количество оборотов» можно понижать программно. Например g27 из коробки крутится на 900 градусов. В драйвере можно указать хоть 90 градусов, при этом руль станет «острее», хотя физически вращение ограничено не будет.
    Понятно, что 8 оборотов, как на Волге, не получить. Но оно и не надо. В реальных авто так же у всех разные редукторы на рулевых рейках. Можно получить как 180, так и 1440 градусов.
  • Обратной дороги нет: личный опыт тестировщика
    0
    Тестировщику точно нужны два качества: внимательность и усидчивость. Необходима база в ИТ. А остальному при желании можно научиться.
    Вы, вероятно, интересуетесь знаниями, необходимыми для старта карьеры? Рекомендую поискать стажировку в какой-нибудь компании и посмотреть список требований к кандидатам.
  • Обратной дороги нет: личный опыт тестировщика
    0
    Откровенно говоря, я не советовал бы использовать Jython с RF (как раз ту связку, что упомянута в моем рассказе).
    Robot Framework сам написан на Python, и под него есть много библиотек именно на Python, позволяющих реализовать практически все, что угодно (вообще RF — мощный инструмент, который лично мне очень нравится). Jython — это попытка адаптировать все это «богатство» под разработку на Java. Но в связке RF+Jython многие библиотеки Python не работают (а вместе с тем и все, что использует эти библиотеки — как некоторые библиотеки самого RF).
    Своих библиотек под Jython практически нет. Когда мы уперлись в это в «боевом» проекте, пришлось потратить время на ковыряния в тех немногих библиотеках, что все-таки существуют (как было описано выше), а остальные нужные нам библиотеки просто переписывать под Jython своими силами.
    Кстати, об этом проекте мой коллега писал статью: habr.com/company/maxilect/blog/424333. Правда, он не акцентировал внимание на том, насколько много усилий ушло на то, чтобы заставить все это корректно работать. Он пришел на проект, когда там была написана уже масса тестов.
    И даже несмотря на то, что я в итоге заставил все это работать, от RF на том проекте впоследствии отказались — перешли на стек, более подходящий для разработки на Java.
  • Обратной дороги нет: личный опыт тестировщика
    0
  • Обратной дороги нет: личный опыт тестировщика
    0
    Вы меня не так поняли. Про конференции подробнее ответил ниже.
  • Обратной дороги нет: личный опыт тестировщика
    0
    Выше я ответил уже про процессы. Не возьмусь их оценивать.
    Про конференции — я имел в виду немного иное.

    Тестирование — активно развивающаяся отрасль. Здесь все меняется довольно быстро, поэтому оставаться «в теме», ни на кого не оглядываясь, сложновато. Не получится сохранять квалификацию, не изучая ничего сверх текущей работы. Вообще зашоренность на работе — это плохой признак. Текущая задача обычно держит тебя в рамках одного направления, в то время, как отрасль развивается, условно говоря, «во все стороны».
    Чтобы компенсировать постоянно усугубляющийся перекос в конкретном направлении, можно следить за публикациями передовых команд, смотреть интересные именно технологические (а не 100% самопиарные) доклады на Ютубе. Но, честно говоря, я не встречал на собеседованиях кандидатов, которые бы действительно тратили на это время. Увы. Конечно же, я пытаюсь это обнаружить. Но чаще вижу огромные пробелы в казалось бы элементарных знаниях.

    Вопрос про конференции — это своего рода «последняя надежда». Если кандидат не интересуется ничем, но хотя бы съездил на конференцию — значит отрасль ему не безразлична (не все потеряно). Конференция — это не столько подборка конкретных докладов, сколько выбранный оргкомитетом список тем, на которые стоит обратить внимание (в изложении докладчиков конференции или других спикеров — это не так важно).
    Конечно же, отрицательный ответ на вопрос о конференциях с лихвой перекроют обширные знания, сертификация и т.п. — тут важно помнить про изначальную цель.
  • Обратной дороги нет: личный опыт тестировщика
    0
    Любопытно, что с «тонкой душевной организацией» я сталкивался далеко не на всех работах (и не зря сделал в статье акцент на прошедшем времени, поскольку последнее время я действительно такого не встречаю). При этом я не возьмусь оценивать, как именно были выстроены процессы разработки в тех компаниях — способствовали они «профилактике» недовольства тестерами или нет. Я лишь отметил, что такой факт имел место.
  • Практика тестирования бэкенда на Java + Rest-Assured
    0
    1. В рамках нашей задачи использованный подход себя оправдал.

    2. Не вырывайте слова из контекста. Ключевым инструментом выбрали то, что: работает и (что важно) удовлетворяет требованиям/ожиданиям.
  • Практика тестирования бэкенда на Java + Rest-Assured
    0
    1. В этом месте читаемостью немного пренебрегли в угоду гибкости и скорости составления входных объектов, как это делают, например, создатели гоночных болидов… Они не ставят внутрь кондиционер, хотя на треке жарко.

    2. Никакой масштабной оценки «всех инструментов на рынке», понятно, не было. Мы взяли первый же вариант, который подошел под требования и наши ожидания.
  • Практика тестирования бэкенда на Java + Rest-Assured
    0
    Отвечу по пунктам.
    Во-первых, проект у нас под NDA, соответственно никаких живых примеров за рамками приведенных скриншотов я показать не могу. Скрины — лишь иллюстрация подхода, но не готовые модули для использования в своих проектах. Поэтому и в код их переводить не имеет смысла.
    Во-вторых, мы рассматривали вариант хранения статичных данных в JSON-ах на этапе выбора подхода, но предпочли генерировать все на лету, а не держать коллекции. На мой взгляд, это вопрос личных предпочтений.
    В-третьих, мы отталкивались от собственного удобства в рамках условий конкретного проекта.
  • Практика тестирования бэкенда на Java + Rest-Assured
    0
    Суть проблемы с null была не на этапе десериализации Jackson'ом, а в момент вызова API: Rest-Assured просто не давал отправить null. Судя по этому issue (https://github.com/rest-assured/rest-assured/issues/942), сталкивался с данной проблемой не только я.
  • Как мы контролируем удаленных сотрудников
    0
    Спасибо за комментарий. Мы по-разному смотрим на вопрос командной работы.
  • Как мы контролируем удаленных сотрудников
    0
    Нет, Вы не правильно поняли. Такой смысл мы не закладывали статью.
  • Как мы контролируем удаленных сотрудников
    0
    Момент про «рабочие часы» прокомментирован выше.

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

    В статье описана некая общая схема командной работы. И команда здесь — ключевой момент. Членам этой команды для успешного достижения поставленных целей необходимо время от времени взаимодействовать между собой.
    Описанная вами схема — с задачами на несколько дней или даже на неделю — у нас тоже может существовать для разработчиков в рамках отдельных проектов (при соблюдении определенных условий), либо для тестировщиков. К примеру, последние могут взять задачи на тестирование на неделю, самостоятельно с ними справиться в любое удобное время, а результаты занести в трекер.
    Но мы делаем акцент именно на командной работе, поэтому и пишем о ней.
  • Как мы контролируем удаленных сотрудников
    +1
    Если сможете дать необходимый результат за 5 часов, то нас это устроит.
  • Как мы контролируем удаленных сотрудников
    +1
    Получается. В индивидуальном порядке — в зависимости от деталей каждого проекта.
  • Как мы контролируем удаленных сотрудников
    +2
    Мы не требуем 8 часов непрерывного кодинга, если вы об этом. Рабочий процесс включает планирование, изучение новых технологий, code review для разработчиков и автоматизаторов тестирования и т.п. Все это закладывается на этапе оценки проекта.
  • Как мы контролируем удаленных сотрудников
    +3
    В доступе к лучшим кадрам. В возможности не привязываться к физическому месту работы. Это многие уже считают роскошью 21 века. Мы ценим эту свободу, которая, безусловно, требует повышенной ответственности.
  • Как мы контролируем удаленных сотрудников
    0
    Основной стек, с помощью которого решаем задачи клиентов:
    1. Java / Kotlin / Scala.
    2. Angular 2 и выше, React.
    3. Python.
    4. QA Automation (Java и Python).
  • Мой опыт знакомства и работы с Robot Framework
    0
    Это по сути подход в котором идет отказ от робота. И тогда не понятно к чему эта статья была


    Статья просто об опыте столкновения с роботом, а не о рекомендации к использованию)

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


    Это подобно связке Java + Cucumber получается. Больше фишка для «манагеров»

    Вот это очень больно и даже через чур. Не уж то в роботе есть что-то такое чего нет в самом питоне?


    Неа. Полагаю, что так «исторически» сложилось
  • Ищу senior'а без офиса и печенек: как у нас организован поиск сотрудников на 100% удаленку
    0
    Спасибо за грамотный комментарий. Отмечу, что мы не перегибаем тут палку, и наши рекрутеры не программируют, поэтому такие вопросы в принципе не могут спросить.
    Про сравнение альтернативных решений — хороший вопрос для Senior. Передал нашему техн. директору идею, мне лично она нравится. Что-то подобное я делаю при собеседованиях РП: даю живой кейс, и пока только один из 30-40 кандидатов смог адекватно его решить.
  • Ищу senior'а без офиса и печенек: как у нас организован поиск сотрудников на 100% удаленку
    +1
    Коллега, чтобы делать такие жирные отверждения, надо знать нашу бухгалтерскую отчетность. Я ее знаю, мы анализируем рынок труда, но, признаюсь, я не видел объективных данных по уровням зарплат в РФ. Разве что про Москву и Питер понятнее, но на этих мегаполисах свет клином не сошелся. Я знаю одного разработчика, который при доходе в 250-300 тыр в Питере не может заставить себя работать уже не один год и удивляется, что его не уволили. Это к слову. Вот 2 утверждения с элементами инсайда: 1) некоторые наши сотрудники увеличили доход в 2 и более раз, перейдя к нам. Один пришел из СберТеха. 2) мы платим не ниже среднего по рынку, это чушь. Ну и третье утверждение добавлю: у нас есть система планирования долгосрочного взаимовыгодного сотрудничества, где мы открыто обсуждаем результаты, цели личные и компании и, конечно же, уровень дохода. При росте компании и повышении удельной прибыли (и снижении влияния рисков за счет экономики масштаба) будет расти доход тех, кто дает результат и растет профессионально вместе с компанией. А расти есть куда: большинство специалистов не говорят на английском, не думают о проектных рисках, не умеют точно оценивать трудоемкость задач (и проекта в целом), не умеют общаться с клиентами… я могу продолжить.
    Касательно плохо сделал работу: решает не менеджер, а коллеги (Code Review), тестеры (много багов) и product owner (не осилил требования, и сделал не то, что нужно).
    По срокам: их определяет сам разработчик. В случаях, когда выполняется дольше, происходит анализ ситуации. Есть и те, кто хронически перезакладывается, выполняя быстрее по факту. Навык оценки трудозатрат развит у большинства разработчиков.
    В таких случаях финансовых санкций не предусмотрено, у нас нет системы штрафов (одну такую я видел на последнем месте работы в роли наемного руководителя, и стоило немалых сил убрать эту глупость). При этом мы не позволим «вытирать о нас ноги». Мы расстанемся с теми, кто решит забить на свои обязательства и будет вешать лапшу, проваливая сроки. Один такой случай был, и мы чуть не потеряли клиента, спасибо другому специалисту, кто оперативно ликвидировал недочеты и закрыл проект. Мы стараемся очень аккуратно нанимать, это занимает время, это не дешево, но после ряда уроков мы будем быстро расставаться с теми, кто не способен выдержать взятые на себя обязательства и кого бесполезно сначала «полечить».
    Арбитраж происходит просто: я собираю факты, общаюсь со всеми сторонами и принимаю решение, потому что я, как генеральный директор и совладелец, буду за это решение платить.
  • Ищу senior'а без офиса и печенек: как у нас организован поиск сотрудников на 100% удаленку
    0
    Спасибо за комментарий. Писал выше, но повторюсь. Эта проверка нацелена на отсев тех, кто думать не хочет или не может. И вопросы простые, наши рекрутеры не дают кейсы из проектов, где надо искать оптимальное решение…
  • Ищу senior'а без офиса и печенек: как у нас организован поиск сотрудников на 100% удаленку
    0
    Спасибо за комментарий. Осталось понять, каких людей больше — кто мыслит как я или как Вы. :-) Но в целом тренд на конкретику очевиден. Мы учтем замечания насчет объединения Middle/Senior в 1 вакансию и отражения возможного уровня дохода. Также очевидно, что если бы мы платили Senior 70-100 тыр, как тут некоторые предположили, то не смогли бы делать проекты большой сложности. Еще раз благодарю за высказанное мнение.
  • Ищу senior'а без офиса и печенек: как у нас организован поиск сотрудников на 100% удаленку
    0
    Кратко: проекты одинаковые, задачи разные, скорость выполнения с учетом переделок после Code Review & Acceptance Testing — тоже разная, может в разы отличаться. В целом Senior мы понимаем так: способен самостоятельно сделать большой функционал. Пример: какая-то серверная компонента в высоко нагруженном распределенном приложении, взаимодействующая с другими компонентами решения. Middle это вряд ли сделает, ему задачи надо давать поменьше, его кругозор уже, опыта меньше, решения взвешенные принимать скорее всего не сможет. Но на ряде проектов найдется и для Middle задачи, если сроки и бюджет позволяют.