WbICHA

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

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

Твоя цель - оффер, и все посторонние мысли о справедливости, какая компания, какое тестовое и т.д. Они только отвлекают и мешают.

когда тебе говорят выполнить ТЗ, которое не является для тебя вызовом и занимает всего час времени, а потом не отвечают вообще - это довольно грустно

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

Стоит ли пытаться "удивить" проверяющего? Есть ли прок от того, что в задании, где просят написать коротенький код, я его дополняю, подключая celery, меняя базу данных с локальной на более релевантную, засовывая приложение в докер образ?

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

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

Инкапсуляция защищает не от хакеров, а от неправильного использования объектов.
Как пример - у тебя может быть класс "Заказ" и у него может быть какой-то статус (оплачен/ждёт оплаты/отменён итд).
При этом у тебя могут быть правила типа: уже оплаченный заказ не может стать вдруг неоплаченным, а отменённый заказ нельзя взять обратно в работу.
Тогда логично будет сделать поле статуса приватным (не доступным для изменения извне напрямую), а менять его только через методы, где будет происходить вся валидация.
(В некоторых языках такие правила принято описывать на уровне типов, чтобы даже валидаций никаких было делать не нужно)

Приватные поля объекта - это его состояние.
Методы объекта - это способы его использования.

Если у тебя в объекте появляется поле x и методы getX / setX (или авто геттеры/сеттеры в C#), то значит, что у тебя и нет явных причин делать это поле приватным, кроме соблюдения общепринятых соглашений.

А ведь и правда есть термин для них (но не тип, конечно): Well-Known Intrinsic Objects

Если же вы спрашиваете как затипизировать что-то, что может быть "RegExp, Array, Function и другим" (и не указывая при этом каждый тип явно), то должен, наверное, подойти только object (не смог в доке TS найти отличается ли TS-тип object от базового JS-объекта; например, в TS есть явная типизация функций, но можно ли её заменить на object?). Но это максимально странная задача, которую явно надо решить каким-то другим способом.

Нет. Всё, что попало в интернет - остаётся там навсегда. Особенно все изменения в git репозитории - копии его есть не только на сервере, который вам не принадлежит и в организации, в которой вы вряд ли админ/владелец, так еще и у всех остальных разработчиков тоже есть копия.

По моим личным наблюдениям для более стабильной работы лучше бы взять минимум 1 гб, но и на 0,5 должен работать. Я заметил, что чем больше скорость вашего интернета - тем сильней нагружается процессор.

Для личных целей держу для себя - 1 ядро, 1 гб озу. Этого в целом достаточно что бы пользовалась вся семья - 5-6 человек.

Решим задачу в общем виде - сделаем функцию, находящую количество совпадающих элементов у любых итерируемых объектов. Причём под совпадением будем понимать не обязательно непосредственное равенство (оставим это как вариант по умолчанию), а равенство некоторых производных значений. Так что к чёрту filter (а ещё Safari - говорят, яблочные уроды пока не реализовали поддержку методов итераторов; впрочем, сделать обычный for...of вместо reduce не проблема):

function countIntersections(data1, data2, key = n => n) {
  const getKey = key instanceof Function ? key : n => n[key];
  const keys = new Set(Array.from(data2, getKey));
  return data1[Symbol.iterator]().reduce((acc, n) => acc + keys.has(getKey(n)), 0);
}

В вашем случае применять так: const result = countIntersections(newWord, glas);.

Другие примеры использования:

countIntersections(Array(7).keys(), Array(4).keys()) // 4
countIntersections('abCdE', 'ACe', n => n.toLowerCase()) // 3
countIntersections([ { id: 1 }, { id: 2 }, { id: 3 } ], [ { id: 3 } ], 'id') // 1

Потому что для рабочей версии сайта чаще всего используют минифицированные версии файлов.

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

В самом компоненте остаётся обезжиренный вариант, не требующий тестов:

import {myFunc} from '....';

........
const handleChangeRoadCosts = (id: number, keyVal: string, val: string) => {
    return myFunc(id, keyVal, val, data);
};

На каждом уровне проверять, что значение не string и не number. Иначе никак, ты сам задал такой тип, и ts не даст тебе совершить ошибку.

Если у тебя только 2 уровня, то не надо рекурсии:

interface CSS {
    [k: string]: {
        [k: string]: string | number 
    }
}

Если ты хочешь сузить тип при создании констатны, можно сделать так:

const css = {
    default: {
        color: '#676767',
        border: '1px solid',
        border_color: '#C4C4C4',
        border_radius: '110px',

        padding: '16px 21px',
    }
} satisfies CSS;

можно через infer:

type Schemas<P extends keyof paths> = paths[P]['post'] extends {requestBody: infer R} ? R : never;

playground