Pull to refresh
113
21.5

Глас компании Maxilect

Send message
По личному опыту самую адекватную работу в it находил после десяти минут разговора с лидом...

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

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

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

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

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

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

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

Information

Rating
254-th
Location
Санкт-Петербург и область, Россия
Works in
Registered
Activity