Что такое хорошо и что такое плохо. Как не превратить собеседование в кошмар

Спасибо за комментарий. Тут я рассматриваю именно технические собеседования, которые часто идут после интервью с рекрутером. Рекрутер рассказывает про проекты, позицию и условия. Если кандидат доходит до этапа техсобеса, то значит он заинтересован в позиции. Либо в прохождении собеседования 🤷‍♂️

Что такое хорошо и что такое плохо. Как не превратить собеседование в кошмар

Спасибо

Знание App insights для Junior в компетенции Cloud Services может быть немного избыточным

Я принимаю во внимание все топики, когда думаю над грейдом кандидата. В данном топике, например, я ожидаю, что джун, работающий с проектом в Azure, должен знать, где смотреть логи.

Что такое хорошо и что такое плохо. Как не превратить собеседование в кошмар

Мой комментарий ниже отвечает на ваш вопрос https://habr.com/ru/post/668382/#comment_24387948

Во время интервью я руководствуюсь шаблоном. О навыках сужу по уверенности в ответах из той или иной категории грейда

Что такое хорошо и что такое плохо. Как не превратить собеседование в кошмар

Dislclaimer: минутка саморекламы

Для того, чтобы вести шаблоны для интервью и чтобы вести заметки во время собеседования, я разрабатываю портал https://techinterview.space. На сайте вы сможете:

• Создать шаблон для себя. Например, вот мой для .net developer

• Вести заметки ответов кандидата во время собеседования

• Экспортировать фидбек для рекрутера и/или нанимающего менеджера в PDF и markdown

Для персонального использования сайт всегда будет free to use, а для компаний пока работаю над предложением и стоимостью.

Автоплатеж, автооплата или автопополнение? UX-кейс

Спасибо за статью, интересные выводы.

Пользователи Beeline Казахстан часто жаловались, что в момент списания ежемесячной платы... 

Как проводили сбор фидбэка?

Истоки мотивации в управлении по Agile и SCRUM

Спасибо за комментарий и ссылку на видео. Мне кажется, что чем больше такого контента, тем лучше мы будем понимать, почему Agile у одних работает эффективно, а у других – ухудшает процессы

EPAM Anywhere: как это работает. Субъективный взгляд изнутри

единственный плюс для тех, кто живет в городе, где нет офиса. В остальном сильно схожие условия, даже по оплате, хотя взамен гарантий (почти) нет

Как меня чуть не уволили из-за токсичного поведения и что было дальше

История о том, как миддл стал сеньором

Коммиты — это снимки, а не различия

Если писать приложение, используя "элементарные" хаки, то скоро можно обнаружить, что система ведет себя неожиданно и непрозрачно для его разработчиков

Коммиты — это снимки, а не различия

Затем.

Радикально. Если папка необходима в коде приложения, то можно создавать динамически:

if (Directory.Exists(path) {
  Directory.Create(path);
}

Если во время инициализации или иных операций, не связанных с кодом, то через bash-команду.

Зачем гит-то заполнять пустыми папками?

Have we ever been working by the Waterfall?

Hi! Thank you for the comment.

sprints and daily standups

I think you are right. But we should take into account that the environment was different 40 years ago. The market was not changing so fast as it does nowadays. It was acceptable when we get the market analytic/research reports after 6+ months after it started. No effective communication like we have now. That's why project managers didn't see a need to deliver software every 2 weeks but anyway they wanted to deliver it as fast as possible.

Also, I think there were daily meetings to sync up the progress of the work. No chances for remote work or slack bot 40-50 years ago, therefore everybody was sitting in the office and was available for direct offline communication. I believe daily meetings have been existing in IT since IT appeared because managers always want to know what is happening. In my opinion, Agile is just the next step of proper project management/

A little life hack when you work with Azure Service Bus and ASP.NET Core

You may just create a special controller action with the "robots.txt" route and generate a response as you wish.

[ApiController]
    [Route("/")]
    public class HomeController : ControllerBase
    {
        [HttpGet("robots.txt")]
        public IActionResult Index()
        {
            return Ok("Hello world");
        }
    }

Видео с Kolesa QA Meetup 3.0: QAцентризм, подготовка данных к тестам и независимые моки

Приведите, пожалуйста, примеры, что можно улучшить и как

Как изменить формат данных JSON на Snake Case в ASP.NET Core Web API

Если эти ребята не испытывали проблем с этой полусотней экстеншенов, то кто им судья.

Как изменить формат данных JSON на Snake Case в ASP.NET Core Web API

Если я в коде увидел что-нибудь типа SnakeCaseConverter.ToSnakeCase(s) то мне сразу ясно, что это чей-то метод, а если s.ToSnakeCase(), то первое что я подумаю: "WTF? Что это за новый метод у string?"

Это лишь на ваш вкус, что никак не делает его лучше или хуже, чем мой и любых других разработчиков, которые тоже пишут экстеншн-методы к классам в коде, хоть к стандартным из .NET, хоть к самописным

Как изменить формат данных JSON на Snake Case в ASP.NET Core Web API

Иначе говоря, использование переменной @string дозволительно. При этом нет правила в списке https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/style-rules/, использовав который можно было бы запретить это. Даже в приведенной цитате сложность упомянута, но вот в чем сложность заключается — не написано.

Получается, что @string никак не нарушает "хорошо стилизованный код" и является лишь вкусом автора.

Как изменить формат данных JSON на Snake Case в ASP.NET Core Web API

Если заранее список подобных мини-запретов на команду не определён, то каждый участник этой команды действительно может писать код как ему вкус позволяет. Конечно же, в рамках принятого код-стайла языка/фреймворка.

Как изменить формат данных JSON на Snake Case в ASP.NET Core Web API

придумано правило "расширяй только свои собственные типы"

Не слышал ранее о таком правиле. Тем не менее, замечание понятно. Но я думаю, что если кто-то пишет код в проекте "по незнанию", то его быстро поправят: либо IntelliSense, либо товарищ на код-ревью.

Какие-то команды действительно могут в своих проектах отказаться от экстеншенов в принципе, но это не повод называть "ужасом" использование экстеншенов в статьях, рассчитанных на широкую аудиторию

Как изменить формат данных JSON на Snake Case в ASP.NET Core Web API

Расширение чужого класса (да еще и string)

Какого "чужого"? А есть такие методы-экстеншены, которые расширяют нечужие классы?

на примере хорошо стилизованного кода

Напишите, пожалуйста, материал, где говорят о том, что именование переменных через с префиксом @ является примером плохо стилизованного кода. В docs.microsoft.com нет подобного "запрета"

Как изменить формат данных JSON на Snake Case в ASP.NET Core Web API

Спасибо за рекомендацию