Леонид Царев leotsarev

Нет, все правильно. Сеньоры в Яндексе естественно есть. Просто они не с рынка их нанимают

Система грейдов — чтобы удерживать людей со знанием «Яндекс.Велосипедофреймворк» в компании.

И да, система найма Яндекса устроена так, что сеньоров с рынка они почти не нанимают.

P.S. На всякий случай — я не из Яндекса, инсайдов нет, это мои наблюдения.

В том-то и дело, что Яндексу не нужен опыт. Нужна голова и способность принять условия игры. Несколько раз сказали — выучи, повтори алгоритмы. Если (а) согласишься (б) успешно и быстро подтянешь — то потом, когда тебе скажут разобраться с «Яндекс.Велосипедофреймворк», ты (а) не будешь спорить (б) быстро разберешься.

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

Про то, что спрашивать про джанго на собеседованиях не нужно, я как раз с Яндексом согласен. Если ты крутой, дадут методичку, выучишь.

Про ваш пример про парусник. Интересно, что развитие показало, что авторы парусника были концептуально правы.
Сейчас гигантские корабли почти полностью автоматизированы, и там, где была раньше толпа кочегаров и сменные on-call механики, на судне ровно один механик, который вахту не стоит, а занимается обслуживанием, профилактикой и ремонтом.

Единственное в чем ASP.NET серьезно уступает Node.js — это простота развертывания. Node нужен только движок и прокси-сервер или Docker

Что за хрень? ASP.NET Core это докер образ + перед ним нужно прокси-сервер.

Ну, у меня есть мой кластер, где я храню всякое.

А есть helm-chart или что-нибудь такое, чтобы без геморроя поставить в k8s? У меня есть кластер...

Любое решение, подразумевающее форк, выкидывает все разговоры о децентрализации в корзину

Изначально в Rust был встроенный GC, и есть разные варианты GC для Rust.

Например, Торвальдс приводит вот в своей автобиографии две причины:

1. Отношение к успешным. Положим, у А были средние результаты за год, у Б — очень хорошие. В США: А з/п останется такой-же, Б получит большую премию, новый грейд, + 30% к зарплате. В Финляндии: А получит +1% к зарплате, Б получит +1.5%

   
   

2. «После 16-00 на улицах темно и страшно, ходят только напившиеся водки старушки»

   
   

И еще надо добавить, что эти заказчики, пользуясь своей рыночной силой, потом будут выкручивать тебе руки на раздувание скоупа проекта.

1. Вовсе не добился, как видно из статьи.
2. Почему «забыла»? А вот веб-фреймворк от MS держит первое место по бенчмарку https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=plaintext Этот аргумент имеет ТАКОЕ ЖЕ отношение к ядру, как и просмотрщик фото (то есть никакое), но если вы воспринимаете аргумент про просмотрщик фото, то примите и этот.
3. А с ядром-то какая связь?

Попробуйте добиться детерминированности поведения Windows 10 по аналогии с описанным в статье на XP. Покажите время реакции на уровне десятков-сотен миллисекунд, как в XP.

Как я и говорил, Windows — не RTOS.

В огороде бузина, а в киеве дядька.

1. Windows никогда не была, не будет и не планируется RTOS.
2. Какая разница. сколько весит просмотр фотографии? Может наоборот за счет того, что меньше ресурсов программистов потрачено на создание просмотрщика фотографий, удается освободить больше ресурсов на вылизывание ядра?
3. Современные браузерные движки (к разговору про Electron) сложные программы, активно использующие низкоуровневые API и предъявляющие жесткие требования к ядру. Так что курсу на производительности это опять не мешает.

Мы же тут не на пикабу прости господи, а технические люди. Какие аргументы есть за «Windows плевать на качество ядра»?

Я не фанат Electron. Но при чем тут это к обсуждению про ядро?

При чем здесь Electron, если разговор про ядро?

Хранят-хранят.

1. Я поддерживаю в принципе ваш подход мол DbSet это репозиторий. Но практика показывает, что ВООБЩЕ говоря этот подход далеко не единственный, и (а) есть много людей, который предпочитают делать абстрации над EF и (б) есть например подход clean archirecture, который предусматривает, что бизнес-логика не может зависеть от репозитория (а репозиторий должен уметь загружать и сохранять доменные объекты).

   
   

2. Опять же про интерфейс. Во-первых, есть подход clean architecture (например в домене объявляются интерфейсы, а в зависимых проектах DAL реализуются). Во-вторых, моки, тестирование etc

   
   

3. Про IRepository<T>. Его-то как раз кмк нет смысла объявлять (потому что это полный аналог DbSet), а вот в IAlbumRepository могут начать появляться методы вроде LoadAlbumsByAuthor и тогда его использование станет более оправдано.

   
   

4. Disposable И тут скорее согласен. При DI подходе не дело управлять временем жизни объекта вручную, САМ контекст при этом может быть вполне IDisposable, но ни к чему этому знанию протекать в интерфейс.

   
   

Итого я скорее с вами согласен, но не согласен в том, что это прям ужас-ужас. Многие так пишут, и могут быть причины так писать в рамках многих подходов.

Расскажите, что тут не так с вашей точки зрения. А то много идей

А почему тут заминусован коммент? Мог бы кто-нибудь аргументированно возразить? Кажется, важный вопрос поднят.

Славные были времена, с ностальгией вспоминаю регионы внутри регионов.
Только ник у меня сходится Глеб Л., а фамилия в профиле нет.

А название исследовательского центра не начинается с P?

Ну и дайте своему будущему начальнику шанс, вдруг он тоже этого хочет.

Как правило работать приходится не с теми людьми, которые принимают решение об оффере и осуществляют фильтрацию кандидатов

Кмк это очень странно. Принимать решение о найме должен начальник

И ответьте на вопрос, пожалуйста. Взяли бы вы работника, который не любит работу «я начальник — ты дурак»?

Вы почему-то рассматриваете только вариант false-negative (вас не наняли в компанию, куда вы хотели). А есть еще вариант false-positive (вас наняли в компанию, где вам будет плохо). И False-positive значительно хуже для вас как для кандидата (если верить всей этой теме про рынок работника и хороший специалист всегда работу найдет). Потратите кусок жизни безвозвратно.

Примерьте свои ответы на себя. Вы бы взяли человека, который на работе не любит, когда на него орут, а любит, когда по человечески все объясняют? Почему вы думаете, что hiring manager глупее вас? Если думаете, зачем позволяете себя нанимать дураку?

На билд агентах стараются временные папочки покороче называть.

12 лет назад в ДатаАрт меня продавали заказчику как сеньора.
По мне, мой тогдашний уровень навыков называется «джун».

дооооо, люди по полгода «на скамеечке» в потолок плюют получая зарплату за ничегонеделание

Растущий рынок просто. Помнится в кризис на одной галере на падающем рынке объявили «клиенты не хотят столько же работы за меньше денег, клиенты хотят меньше работы за столько же денег. На бенче сокращаем зарплаты вплоть до 0,3 вашей ставки».

1. В продуктовой компании — совсем не требуется писать хороший код. Если продукт заходит — всем до лампочики что у него под капотом. И ан-масс — пишут так себе. Используя зачастую — дико устаревшие технологии
   3.1 В аутсорсинговую или сервисную компанию (типа ЕПАМа, да) заказчик приходит для того что бы ему написали самый лучший код на всех последних современных технологиях о которых они услышали на последней конференции. И деваться — некуда т.к. в спину дышат индийские

Тут мой опыт скорее обратный. Продуктовая компания будет жить при успехе продукта с этим кодом дальше. Его понадобится переписать и зарефачить. Именно тем же людям, именно за счет тех же боссов.

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

Но пассажи про качество процессов в аутсорсерах верны. Процессы в аутсорсерах максимально отлажены и красивы, потому что любой такой косяк сделает для вашего босса ваш проект из прибыльного — убыточным, и с шансами напрямую скажется на его компенсации месячной.

Аутсорсеры на растущем рынке держаться за людей всеми силами. Пусть разработчик известно дурак, но выдает какой-то код, трекаются часы, они биллятся в счет. Каждый лишний день, как дурак поработает на проекте — прямая финансовая выгода компании. Если заказчик заметит что человек дурак (зачем? почему? как? Менеджеры, аккаунты и тимлид бьются всеми силами, чтобы этого не допустить), то его выведут из этого проекта и введут в другой — на это есть отлаженные процессы перевода в другой проект. Там авось тоже не сразу разоблачат.

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

В аутсорсерах опыт и стаж ничего не значат. Тебя не удается продать, биллить не получается? Твоя зарплата слишком выросла, потому что ты крутой специалист, а ставка, по которой тебя продают, выросла не очень? Прости, ты не выгоден. Вот финансовая модель, ты два месяца без проекта или на случайных неудачных пре-сейлах? Давай до свиданья, счастья здоровья. Заказчику не нравится твоя рожа? Прости, ты покидаешь проект, это не обсуждается, ищем новый. Ой, нового сейчас нет, давай до свиданья (процессы суперотлажены, напоминаю).

В продуктовых чем дольше ты работаешь, тем лучше. Ты сидишь на проекте 5 лет, приносишь результат и хорошо в нем разбираешься? Замечательно, вот тебе еще +10% каждый год, сиди, пожалуйста, до пенсии родной. Кто тебя обидел, давай плохого мальчика накажем. Продакту что-то не нравится? Давайте менеджер вас помирит, вы ценные специалисты, вам вместе тут еще век куковать. Новых крутых не сразу найдем еще, а ты вроде ничего.

Как-то так.

Добавьте в пост ссылку на hacker news https://news.ycombinator.com/item?id=24684813

Внезапно оборудование для цензуры продано кому-то, кто использует его для цензуры. ШОК-КОНТЕНТ!

Дефолтный null! в основном раздражает.

А про валидатор — по логике DataAnnotations должен бы реагировать на nullable/не nullable, если они есть — это ведь тоже стандартные атрибуты. Надо бы проверить

Слушайте, IValidateOptions полезная штука, но не понятно, как он решает проблему nullability.
Все равно придется писать там код типа

public sealed class SomeClientOptions
{
    public string Login { get; set; } = null!;
}

Ну и плюс надо писать [Required] видимо, чтобы Microsoft.Extensions.Options.DataAnnotations срабатывал.
Или я еще чего-то не учитываю?

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

Обычно у меня идет так:

1. Я называю на предварительном обсуждении комфортный минимум. На этом этапе со многими прощаемся.
2. Техническое и нетехническое.
3. Тут HR торгуются

Еще есть два момента.

1. Нет, процесс подбора разработчиков не такой, как на красивой картинке. Реально он такой. Есть 10 кандидатов. 5 из них провели всю карьеру в НИИ говна и торфа и в ИТ отделах автосалонов (или в банке на букву А. — дотнетчики оттуда это отдельная песня). Остается 5. Из них собес проходят на уровне «ну вроде норм» 1-2 человека. Обоим делаешь оффер и молишься. В крайнем случае наймем обоих. Такого чтобы 2 кандидата нормальных и выбираешь — очень редко было.
2. Люди категорически не умеют оценивать себя. У нас висела вакансия миддла, на нее было 0 откликов (все шли на сеньора). Даже люди уровня джун и джун+. Хорошего миддла взять можно, но не по цене сеньора, естественно. А ситуация, где человек откликнулся на сеньора и ему потом — предлагаем на миддла, вот его вилка и оффер — обидная и конфликтная.

P.S. Ищу тимлида дотнет. Удаленка (лучше с проживанием в Питере, чтобы в бар можно было ходить), продуктовая компания, продукт интересный. Контакты и вакансия в профиле.

У меня оказалось, что рекрутер просто скрыл мой минимум от работодателя :-)

1. Если HR не устроит, они вам скажут — у нас верхняя планка такая-то. Будут торговаться. Или сдвинут верхнюю планку, если вы сильно нужны.
2. Если вам не очень нужна работа, пролететь мимо верхней планки не страшно. Останетесь на другой хорошей.
3. Если очень нужна (потеряли работу, срочно нужна новая) — ну сэкономят на вас 20К. Потом вы уже окажетесь в ситуации, где работа нужна не сильно, и сможете искать спокойно с нормальной позицией и «тылом». Или здесь договорится.