Тесты которые нельзя запускать параллельно (например с использованием буфера обмена) - запускать последовательно
Остальные разделить физически (отдельные докеры, отдельные БД) или логически (каждый юзер видит свои данные). Но тут не были упомянуты мульти-тенантные системы и тесты в рамках транзакций БД
Что-то как-то попадаются устаревшие вещи - очередь за забором опять появилась и на российском и на зарубежном рынке.
Рекрутеры не умеют в отбор
Ну допустим, а кто-нибудь проводил аналогичное исследование, но среди экспертов, а не рекрутеров? Сколько у них показало вероятность, намного лучше чем монетка?
профильное образование никак не повышало шансы кандидатов проходить техническое собеседование и получать оффер
Верно, но так же верно и другое - после того как кандидат вышел на работу разница между человеком с вышкой и без вышки есть. Благо у нас появились всякие курсы и всякие повара / курьеры / таксисты их проходят, потом пытаются устроится на работу, у некоторых даже получается, а вот потом начинаются проблемы с укладыванием в голове сложных систем и взаимосвязей. Да и в зарубежных вакансиях попадалось типа "вышка + 4 года опыта" или "без вышки + 8 лет опыта".
Я же обращу ваше внимание на такой нюанс. Большинство ATS не сравнивают новые резюме с присланными ранее. Потому, если вы хотите повысить шансы на прохождение этого криво работающего забора, после получения автоматического отказа создавайте новую заявку с резюме в новом формате.
Подтверждаю, сам так делал и со второго раза доходил до человека. То есть если ATS система в первый раз не пропустила, то люди об этом не знают. Только надо еще мелким шрифтом белым текстом на белом фоне догнать резюме до 70-80% совпадения.
А сейчас он по сути интерпретатор js + глобальные переменные + шаблоны/подстановки + моки + cli
Все это довольно глючное, но позволяет реально сделать автоматизацию тестирования API. Особенно, если еще прикрутить утилиту которая генерит API к бд по ее схеме.
И его коллекции не совместимы с git. Вот недавно только появилась тема у них.
Для поддержки и развития такой дуры нужны люди и деньги.
Но если рассматривать постман как curl - да, можно сказать что они зажрались.
Сейчас есть некоторые исследования в области квантовой запутанности, что по идее может привести к изобретению мгновенной связи и будет межзведный телеграф с азбукой Морзе. А это в свою очередь может повлиять на межзвездный финансовый рынок 🫠
На самом деле поднадоели такие статьи. Все довольно поверхностно. И они не отвечают на неудобные вопросы.
Я когда на более ооп-шном C# попробовал сделать DDD - там столько вопросов возникло. В реализации на Go из статьи они тоже есть. Вот например фабричный метод, в заказе может быть 100500 всяких бизнесовых полей - это вы все их пихать будете как параметры? То есть на каждый чих менять контракт? А не задолбаетесь?
Почему в таких статьях DDD рассматривается в отрыве от производительности? Автор, вы понимаете, что DDD со своим "восстановить сущность из хранилища и потом запускать на ней бизнес логику" - это жутко медленная штука? И если потребуется выжать больше 50 rps без деградации с ростом нагрузки, то придется переходить на нативный SQL / хранимки с логикой. А это уже ни разу не DDD.
Я уже давно видел ту статистику на another-it и проверил свой C# по России на xx (там поиск только в заголовке) - реально выдало около 300 вакансий, плюс минус.
В щасливые стародавние времена у меня по моим фильтрам так же по России (там куча всего было с NOT, но основное тот же C#) - выдавало 1000-1200 вакансий.
Так вам шашечки или ехать? Лучше вообще без шансов трудоустройства? И чем это отличается от времен до ковида?
Кстати, вспомнил, попалась вакансия типа с 32 откликами (вместо 300-500-1000) из условного Екатеринбурга. Там как раз было написано - работа в офисе, проживание в Екатеринбурге.
TLDR
Тесты которые нельзя запускать параллельно (например с использованием буфера обмена) - запускать последовательно
Остальные разделить физически (отдельные докеры, отдельные БД) или логически (каждый юзер видит свои данные). Но тут не были упомянуты мульти-тенантные системы и тесты в рамках транзакций БД
А как так вышло, что сократили, если не секрет? Российская или зарубежная компания?
Нет, не обольщайтесь, в северной америке, очередь в магазине на кассу - это не queue
Ведущий программист после института? 21 летний сениор? Расскажите как так вышло, жутко интересно.
И сейчас, к сожалению, не лучшее время для возвращения.
Напишите потом статью на хабр, интересно что и как у вас выйдет
А за что уволили, если не секрет?
Что-то как-то попадаются устаревшие вещи - очередь за забором опять появилась и на российском и на зарубежном рынке.
Ну допустим, а кто-нибудь проводил аналогичное исследование, но среди экспертов, а не рекрутеров? Сколько у них показало вероятность, намного лучше чем монетка?
Верно, но так же верно и другое - после того как кандидат вышел на работу разница между человеком с вышкой и без вышки есть. Благо у нас появились всякие курсы и всякие повара / курьеры / таксисты их проходят, потом пытаются устроится на работу, у некоторых даже получается, а вот потом начинаются проблемы с укладыванием в голове сложных систем и взаимосвязей. Да и в зарубежных вакансиях попадалось типа "вышка + 4 года опыта" или "без вышки + 8 лет опыта".
Подтверждаю, сам так делал и со второго раза доходил до человека. То есть если ATS система в первый раз не пропустила, то люди об этом не знают. Только надо еще мелким шрифтом белым текстом на белом фоне догнать резюме до 70-80% совпадения.
Postman раньше был как curl
А сейчас он по сути интерпретатор js + глобальные переменные + шаблоны/подстановки + моки + cli
Все это довольно глючное, но позволяет реально сделать автоматизацию тестирования API. Особенно, если еще прикрутить утилиту которая генерит API к бд по ее схеме.
И его коллекции не совместимы с git. Вот недавно только появилась тема у них.
Для поддержки и развития такой дуры нужны люди и деньги.
Но если рассматривать постман как curl - да, можно сказать что они зажрались.
Сейчас есть некоторые исследования в области квантовой запутанности, что по идее может привести к изобретению мгновенной связи и будет межзведный телеграф с азбукой Морзе. А это в свою очередь может повлиять на межзвездный финансовый рынок 🫠
Интересно и познавательно, но в пересказе опять ничего насчет производительности.
На самом деле поднадоели такие статьи. Все довольно поверхностно. И они не отвечают на неудобные вопросы.
Я когда на более ооп-шном C# попробовал сделать DDD - там столько вопросов возникло. В реализации на Go из статьи они тоже есть. Вот например фабричный метод, в заказе может быть 100500 всяких бизнесовых полей - это вы все их пихать будете как параметры? То есть на каждый чих менять контракт? А не задолбаетесь?
Почему в таких статьях DDD рассматривается в отрыве от производительности? Автор, вы понимаете, что DDD со своим "восстановить сущность из хранилища и потом запускать на ней бизнес логику" - это жутко медленная штука? И если потребуется выжать больше 50 rps без деградации с ростом нагрузки, то придется переходить на нативный SQL / хранимки с логикой. А это уже ни разу не DDD.
3) попросить оплату тестового
Еще одна причина чтобы не делать тестовые 😅
К сожалению нет, я последний раз искал работу в 2020
Кстати в статье было бы интересно прочитать как работают pass key и one-time password
Я uuid / guid-ы храню /s
Я уже давно видел ту статистику на another-it и проверил свой C# по России на xx (там поиск только в заголовке) - реально выдало около 300 вакансий, плюс минус.
В щасливые стародавние времена у меня по моим фильтрам так же по России (там куча всего было с NOT, но основное тот же C#) - выдавало 1000-1200 вакансий.
Так вам шашечки или ехать? Лучше вообще без шансов трудоустройства? И чем это отличается от времен до ковида?
Кстати, вспомнил, попалась вакансия типа с 32 откликами (вместо 300-500-1000) из условного Екатеринбурга. Там как раз было написано - работа в офисе, проживание в Екатеринбурге.
Где-то я такое уже слышал, про недостаток 1 млн айтишников...
Вам что мало 1000 откликов на хх? 😅
О_О, я открыл ссылку на вакансию и оно перекинуло на away.vk.com сначала