З чого ви вирішили, що хтось має безкоштовно вам писати якісні професійні статті?
Таких авторів дуже мало, і DOU не є пріоритетним місцем для їх публікацій.

Такі випадки, звичайно, є в українському ІТ.
Найчастіші серед них:

1) Відсіювати надто вікових, які тільки потрапили до ІТ
2) Перевіряти вік, щоб, наприклад, не було дисонансу між віком членів команди та віком кандидата. Тобто команда 20-25 років, а кандидату вже 45.

Абсолютно правильно. У резюме не повинно бути віку чи року народження.
А будь-яке питання рекрутера на цю тему — це ознака вікової дискримінації.

У мене були випадки, коли саме питали роки навчання у ВНЗ, без зазначення цих років відмовлялися продовжувати спілкування

Тому що ви не Штучний Інтелект

А в чому проблема потренуватися і навчитися швидко кодувати і навіть під тиском, якщо це потрібно?

Пишіть прямо, які українські ІТ-компанії відмовляють ветеранам у роботі.

Згоден із тими коментарями, де писалося, що автор просто навів документацію по сигналам, але не розповів про причини переходу на них.
Я вже давно використовую сигнали в Angular, з мого досвіду наведу три причини, чому використовую їх і чому замість Observable:
1) Вони завжди мають початкове значення (на відміну від Observable)
2) Там є чіткий поділ на WritableSignal і просто Signal (read-only)
3) Якщо ми використовуємо сигнали в компонентах, то Angular відразу дізнається про те, що ми змінили значення сигналу, і це означає, що не потрібно проходити по всій моделі та порівнювати поточні та попередні значення, можна робити компоненти OnPush тощо.

// Метод для збільшення значення лічильника на 1
increaseCounter() {
this.currentCount.set(this.currentCount() + 1);
}

Ось цей приклад якраз некоректний.
Angular документація рекомендує використовувати тут не set, а update:
this.currentCount.update( (current) => current + 1);

Якщо людина всі 20 років працювала в одній компанії, на тому самому проекті, з однією і тією ж технологією, з одним і тим же набором обов’язків, то її резюме і на півсторінки вміститься.
Але тут же про інші випадки запитують. Чи ні?

А ось і ні. У мене були випадки, коли рекрутери цікавилися досвідом роботи, який був і 10, і 20 років тому, причому там потрібно було докладно розписувати технології та обов’язки.
Тож ваш приклад не показовий.

Ми практикуємо домашні завдання, щоб не створювати зайвого стресу кандидату та водночас перевірити якість виконання й уважність.

У цьому пості багато говорять про тестові завдання, але автори скромно обходять питання оплати.
Якщо людина робила тестові завдання, тобто фактично виконувала роботу, чому вона має робити це безкоштовно? Компанія Master Of Code Global настільки бідна, що не може сплатити за кілька годин роботи?

Є люди, які не знають стримів, і це можуть бути навіть сеньйори. Вони використовували старішу версію Java, де стримів не було.

Насилу віриться, що в 2024 є люди, які не знають Stream API (Java 8), тобто вони досі працюють на Java 7 або старіших версіях

2015 рік. «Програмісти не матимуть успіх у новому світі, якщо відмовлятимуться від використання мікросервісів.»
2025 рік. «Моноліти насправді не такі вже й погані.»

Пишуть лише ті айтішники, які хочуть розвивати, розкручувати свій персональний бренд.
А у більшості стереотипне мислення — побудувати кар’єру цілком у ІТ. А якщо ви пишете книги чи технічні статті, це ніяк не підвищить ваших шансів на успішну кар’єру. Рекрутерам та менеджерам все це банально не цікаво, вони навіть вас слухати не будуть на цю тему.

Java

Висловлю власну думку.
Тестові завдання дають тільки там, де інтерв’юерам ліньки витрачати час на live coding.
Фактично організувавши live coding на 20-40 хвилин, можна перевірити всі знання, навички та досвід, що вас цікавлять.
Більше того, можна ставити запитання, можна допомагати та підказувати, тобто це емуляція того, що відбувається на роботі.

XSS (Cross-Site Scripting)

Cross-Site Scripting (XSS) — це тип вразливості безпеки веб-додатків, який дозволяє зловмисникам вставляти шкідливі скрипти на вебсторінки, що можуть виконуватися на стороні клієнта (у браузері).

Який стосунок все це має до REST API?
Після прочитання даного посту створюється враження, що автор вирішив в одному місці написати все, що він знав про Web, а для того, щоб отримати більше переглядів, вигадав клікбейтний заголовок «Повний огляд REST»

Величезна проблема багатьох технічних статей на DOU у тому, що люди, які їх пишуть, або погано розуміються на темі, або не можуть точно описати матеріал. Наприклад:

Сам REST запит складається з таких частин:

Метод HTTP.
Посилання.

REST/REST API — архітектурний принцип, який не пов’язаний з реалізацією. І там ніяк не описується, з чого має складатися запит. А те, що перераховує автор — це витяг зі специфікації HTTP.

А компанія була українська, польська, міжнародна?