Задачи с собеседований. Напишите кастомный метод массива.

Что от вас ждет собеседующий:

1. Понимания прототипного наследования.
2. Нюансов работы с экземпляром массива.

Возьмем для примера кастомный метод Array.some:

Array.prototype.customSome = function(func) {
    const result = [];

    for(let i = 0; i < this.length; i++) {
        if(func{this[i]}) result.push(this[i])
    }

    return result;
}

Leetcode 69: Sqrt(x).

Задача проста: написать свою функцию нахождения квадратного корня.

Что нужно знать из математики:

- Для 0 и 1 нужно возвращать их самих.
- Решение всегда в меньшей половине числа, если оно больше 2.

Что по алгоритму:
- Массив создавать не нужно! Для больших чисел это вызовет переполнение памяти.
- Быстрее всего работает двоичный поиск.
- Для случая, когда точного корня не найдено, возвращать надо правый указатель: он всегда на шаг меньше целевого числа.

Хотите потроллить интервьюера? Дайте ему такое решение: Math.floor(x ** 0.5) 😁

function mySqrt(x) {
    if(x < 2) {
        return x;
    }
    
    let rightPointer = Math.floor(x / 2);
    let leftPointer = 1;
    
    while(leftPointer <= rightPointer) {
        let midPointer = Math.floor((leftPointer + rightPointer) / 2);
        let value = midPointer * midPointer;
        if(value === x) {
            return midPointer;
        } else if(value > x) {
            rightPointer = midPointer - 1;
        } else {
            leftPointer = midPointer + 1;
        }
    }

    return rightPointer;
}

Все точки над SOLID

Лао-Цзы учил:

"Одно породило два.
Два породило три".

В случае с SOLID одно породило пять. За всеми принципами SOLID стоит один замысел:

Low coupling, high cohesion.

Coupling - это связанность. Cohesion - это связность.

Связанность - это уровень зависимостей в коде.
Высокая связанность - случайные, циклические зависимости.
Низкая связанность - минимальные зависимости.

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

Каждый принцип SOLID выражает low coupling, high cohesion.

- SRP ограничивает сущности одной областью ответственности.

- OCP ограничивает модификацию сущность (но позволяет модифицировать в рамках ее ответственности).

- LSP позволяет пользоваться разными модификациями одной сущности, ничего принципиально не меняя.

- ISP помогает SRP: одна сущность не принимает 10 разных аргументов. Одна сущность принимает несколько интерфейсов, разделяющих принимаемое логические.

- DIP безупречно выражает low coupling. Зависимость должна приспосабливаться к клиентскому коду через интерфейс, а не наоборот. Результат - легкая подмена глобальной БД на локальную или продовской зависимости на моки для тестов без боли.

Подумайте об этом, чтобы не смущаться ни на собеседовании, ни в работе.

Leetcode 67: Add Binary.

В этой задаче, как и в прошлой, есть ожидаемое решение, а есть тролльский однострочник:

var addBinary = (a, b) => (BigInt('0b' + a) + BigInt('0b' + b)).toString(2);

Оставлю разбираться с его тонкостями для вас. 😁

Один из вариантов ожидаемого решения представлен ниже. В нём мы нормализуем данные, добавляя нули в более короткое. Это нужно, чтобы обойтись только одним циклом. Затем мы на каждой итерации проводим несколько вычислений:

- Что прибавить к результату
- Остаток от двоичного сложения

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

Одна из оптимизаций этого решения - заранее создавать массив длиной maxLength, чтобы сэкономить на операциях вставки (в данном алгоритме мы каждый раз создаем новую строку).

var addBinary = function(a, b) {
    const maxLength = Math.max(a.length, b.length);
    a = a.padStart(maxLength, '0');
    b = b.padStart(maxLength, '0');
    let carry = 0;
    let result = '';

    for(let i = maxLength-1; i >= 0; i--) {
        const currentSumBits = Number(a[i]) + Number(b[i]) + carry;
        result = (currentSumBits % 2) + result;
        carry = Math.floor(currentSumBits / 2);
    }

    if(carry) result = carry + result;

    return result;
}

Задачи с собеседований. Путаница с ключами.

Вас спрашивают: что выведет в консоль?

const a = { a: 5 }
const b = { b: 10 }

const c = {};

c[a] = a;
c[b] = b;

console.log(c[a].a, c[b].b)

На первый взгляд, будет 5 и 10. Но это не так! Почему?

Дело в том, что стандартный объект в JS - это хеш-таблица. Почему? Чтобы обращаться к ключам объектов за O(1).

В стандартном объекте реализация хеш-таблицы простая: ключи (кроме символов) приводятся к строкам, строки - к хешу, по хешу движок ищет ключи.

Если привести объект к строке, будет 'Object object'.

В задаче мы дважды присваиваем объекту "c" поле 'Object object' со ссылкой на объект. Что происходит, когда одному полю значения присваиваются несколько раз? Сохраняется только последнее присвоенное значение.

В итоге, в поле c['Object object'] будет храниться ссылка на объект b. Поля "a" в объекте "c" не существует.

Поэтому результат такой: "undefined 10".

Изучите, к какому виду строки приводятся структуры в JS. И запомните принцип, что любая не-строковая структура, кроме Symbol, используемая как ключ объекта, приводится к строке.

Leetcode 70. Climbing Stairs.

Эта задача - база рекурсии и динамического программирования.

Запомним:
- ДП всегда итеративно и работает за O(n) по скорости и O(1) по памяти. Работает по принципу Bottom-Top: разворачивает задачу от базовых случаев к заданному пределу.
- Рекурсия с мемоизацией работает за O(n) по скорости и O(n) по памяти. Работает по принципу Top-Bottom: идет сверху вниз, пока не встретит базовый случай.

Рекурсивное решение на каждом шаге вычисляет комбинацию шагов для n-ной ступеньки, после чего спускается вниз и считает снова. Те, кто решал задачу чисел Фибоначчи, найдет код знакомым:

const memo = {};
var climbStairs = function(n) {
    if (n <= 1) return 1;

    if(memo[n]) return memo[n];

    const currentCalc = climbStairs(n-1) + climbStairs(n-2);
    memo[n] = currentCalc;
    return currentCalc;
};

Leetcode 70. Remove Duplicates from Sorted List

Эта задача не станет сюрпризом для тех, кто писал свой Linked List.

Дан указатель на голову листа. Создаем на него указатель. В цикле перебираем ноды: пока есть текущая и следующая ноды, проверяем, совпадают ли значения. Если совпадают - следующая за следующей нода становится на место следующей. Иначе следующая занимает место текущей.

Можно решить и рекурсивно, однако решение займет O(n) по памяти.

var deleteDuplicates = function(head) {

    let temp = head;

    while(temp && temp.next) {
        if(temp.next.val !== temp.val) {
            temp = temp.next;
        } else {
            temp.next = temp.next.next;
        }
    }

    return head;
};

Leetcode 94. In-order обход дерева.

Это простой рекурсивный обход бинарного дерева. О деревьях и типах обхода (DFS, BFS, In-Order, Post-Order, Pre-Order...) уже писал ранее.

Чтобы понимать этот код, нужно уяснить, как работает стек при рекурсии.

Функция traversal вызывается на корне дерева. Далее в стек помещаются последовательно все вызовы на левых нодах - до тех пор, пока в вызов не будет передан null. После этого наполнение стека закончится. Произойдет неявный возврат undefined. Интерпретатор сможет выполнить следующую операцию - закинуть в массив значение предыдущей ноды. Затем вызывается та же функция на правой ноде, и процесс повторяется до исчерпания дерева.

var inorderTraversal = function(root) {
  const result = [];

  function traversal(node) {
      if(node) {
        traversal(node.left);
        result.push(node.val)
        traversal(node.right)
      }
  }  

  traversal(root)

  return result;
};

Мои главные ошибки в программировании за 5 лет

Накопились, скажем так, точки роста. :) А именно:

1. Поверхностный анализ задач.
Чтобы решить задачу на 100%, нужно:
- внимательно прочитать задачу
- понять, какого результата ожидает заказчик
- понять, откуда брать данные и готовы ли они
- провести небольшой ресерч, как решать такую задачу
- обсудить с заказчиком все непонятные тонкости
- брать задачу в работу

Но моя автоматическая реакция - бегло прочесть задачу и сразу взять в работу. Заказчик ожидает, что я все понял. Если повезет и задача типовая, ожидания и реальность совпадают. Если нет - я запрашиваю информацию по ходу дела и ставлю задачу на паузу. Она переезжает в следующий спринт.

Что изучить, чтобы так не делать?

Лекция по анализу задач: www.youtube.com/watch?v=ugGT4T5HcsI&t=9263s
Курс по софт-скиллам: https://youtube.com/playlist?list=PLfDKoUW4baOdVtmuBkfLt649c2L8KqZmx&si=CVc2ekvITCVBIqlN

2. Программирование реализаций, а не интерфейсов.
Сначала пишу код, потом подгоняю интерфейс.
Это неверный подход. Ни о каком LSP или DI не может быть и речи, когда ты не знаешь заранее, что код принимает и возвращает. Ты не видишь место кода в системе.
Напротив, спроектированный заранее интерфейс создает Black Box, который задает написанию коду понятные рамки.
Теперь я проектирую систему заранее, а реализации пишу после.

3. Изучение решений вместо проблем.
Например, учу TypeScript, а не теорию типов и область применения типов данных.
Так можно стать мидлом, но не синьором.

4. Развитие только в технологии.
Скачок в карьере дает только понимание, как код конвертируется в ценность (например, выручку компании). Это помогает расставлять приоритеты, выбирать технологии не по хайпу, а по потребностям домена, и общаться с коллегами от бизнеса на их языке.

Чистая архитектура - зло?

В блоге "Кодируем" (@koduryem) узнал, что кто-то из нас говорит: чистая архитектура - творчество университетских программистов, раньше писали без них и все летало!

Я прокомментировал:

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

Более того, накидывать абстракции заранее - нормально. Опытный разработчик может предсказать, в какую сторону будет расти проект, и заранее абстрагировать пару фабрик. Остальное применит в ходе рефакторинга. Неопытный абстрагирует все, что может, потому что хочет показать свой профессионализм. Другие споткнутся об его код, упадут и закричат на весь интернет, что чистая архитектура - зло. :)

Этим постом ставлю точку над срачем, зло чистая архитектура или нет ✅

ChatGPT уже заменил программистов?

Встречал на vc.ru статьи от СЕО маленьких компаний, которые с восторгом отзывались о GPT:

"Бот написал код по моему ТЗ, и я сам собрал его по инструкции. Мой программист мне больше ни к чему!"

Что здесь не так?

- Нет времени. Запустить продукт - мало, его нужно поддерживать, рефакторить, чинить и развивать.
- Нет экспертизы. Даже старшие разработчики не всегда понимают, как задать ChatGPT вопрос. Ответы O1-preview (лучшая модель OpenAI) слишком общие, и даже она ошибается.
- Нет ответственности. Бот ни за что не отвечает, юридическая база ответственности компаний-провайдеров ИИ отсутствует.

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

You don't know React

После 5 лет в разработке с радостью узнал, что Реакту еще учиться и учиться. Например:

- Compound Components Pattern, который реализует Open-Close Principle.
- Provider hell - лесенку оберток вокруг App - легко избежать через хелпер, принимающий массив компонентов и параметров.
- Каррирование коллбэков помогает делать чище JSX.

Это лишь мелочи из того, что я узнал. С одной стороны, заставляет усомниться в своем профессионализме. С другой - воодушевляет: пробелы в знаниях понятны, будущий уровень - тоже понятен.

Я продолжу инвестировать время в обучение: амбиции требуют больших компетенций. Заканчиваю материал по TypeScript, начинаю воркшоп по React от Anthony Alicea. В планах - "The Software Architect Mindset" от ArjanCodes и продолжить книгу Luca Mezzalira о микрофронтах.

Правда ли, что в 2025 работу во фронтенде найти сложнее?

Еще недавно было так: закинул резюме на HH, и HR сами пишут пачками. Но в 2025 всё поменялось.

Я сам столкнулся с этим, когда искал позицию синьора в конце 2024. Критерии были простые:

- Х2 к зарплате.
- Возможность в будущем стать тимлидом.

Делал, как раньше: написал резюме левой пяткой, выложил на Хабр Карьеру и hh. Думал, HR сами будут писать пачками. Но… компании смотрели - и не звали на собеседования.

Начал откликаться сам - впервые за всю карьеру. За неделю получил всего 2 приглашения - и не прошел даже HR-собеседование.

Этот результат сильно встревожил. Я не понимал, что делаю не так.

Решил разбираться и вложился в процесс:

- 50 тысяч рублей на карьерные консультации.
- 15 тысяч на подписки и Boosty экспертов, чаты «паровозиков»...
- 40+ видео с интервью.

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

Главное - научился, как не бояться того, что чего-то не знаю. Как грамотно говорить с HR и на техническом интервью - как специалист, а не студент на экзамене.

Вот тогда пошли офферы.

Я настолько обнаглел, что отказался от оффера на почти 300К, потому что они не захотели торговаться выше. :)

И наконец вышел на отличную работу синьором - по ТК, с классным ДМС и карьерными перспективами.

Так что да, стало сложнее. Но если подходить с умом — всё возможно!

Зачем айтишнику свой блог?

Привет! Поделюсь, зачем я шесть лет веду этот канал.

Кроме написания кода, я решал две задачи:

1. Как устраиваться на работу.
2. Как развиваться, когда устроился.

Для этого я качал тех скиллы. Посмотри выше примеры решений задач с Leetcode, конспекты по SOLID и другие посты. Когда объясняешь другим, сам понимаешь еще лучше! Это не шутки, оно так работает. :) А если ты новенький, читай пост приветствия, познакомимся!

Недавно я понял, что накопил большой опыт и в том, как фронтенд-разработчику делать карьеру, расти в доходе. И решил вести канал больше про это. Делиться проверенными лично лайфхаками. Канал поможет тебе:

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

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

И это нефигово заряжает! Жизнь приобрела еще один смысл.

Как улучшить резюме фронтендера в 2025?

Смотри, 50% резюме программистов - полная шляпа. Моё старое - не исключение :)

Чтобы повысить грейд и зарплату во фронтенде в наше время, мало написать от балды и ждать. HR не будут откликаться на такое резюме! Ведь конкуренция высока, и другие уже освоили навыки самопрезентации.

Давай расскажу, как оптимизировал резюме на HH.ru - и за 14 дней получил несколько вкусных офферов :)

- расписал свое последнее место работы, остальные - схематично.
- описал по формуле "проект, обязанности, достижения, стек" каждую работу.
- начал с глагола каждый пункт: так проще читать.
- подтвердил все навыки.
- оформил раздел “обо мне” по правильной структуре, добавил туда список навыков для поисковой оптимизации.
- убрал лишние навыки из тегов.

Прикрепил к посту пример. Это одна из предыдущих работ.

Пользуйся и находи работу быстрее, бро 🔥

Топ 5 карьерных ошибок фронтендера ❌

Почему у тебя не получается быстро расти в доходе во фронтенде, хотя вроде бы делаешь всё правильно? В чём секрет?

На самом деле секрета нет. Есть однотипные, базовые ошибки, которые многие допускают по неопытности. Давай разберем:

– Не качать софт-скиллы. Представь, ты сидишь на одном месте годами, делаешь однотипные задачи, перерабатываешь. Зарплата не растет, здоровье падает. А другие получают повышение. Жиза, да? Это исправляется софт-скиллами.

Ты можешь бояться общения - это нормально. Но на работе, ради себя самого, научись говорить с командой! С тимлидом можно аргументированно спорить о спринтах и сроках. С дизайнерами и менеджерами - договариваться, а не тихо ненавидеть.

– Учить все подряд. Ты фронтендер, тебе не нужны Python и C++ “на всякий случай”. Это прокрастинация. Углуби экспертизу в своей отрасли, изучай софт-скиллы и AI-инструменты (но, пожалуйста, не уходи в машинное обучение!).

– Не качать смежные технологии. Да, тебе не нужен C++, но тебе пригодится общее понимание бэкенда, баз данных, паттернов проектирования, архитектуры. Так ты сможешь проходить интервью на крутые должности.

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

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

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

Как меня уволили 😱

Записал кружочек о том, как меня однажды уволили и какие уроки я вынес 💚

Как просить прибавку, если страшно услышать "нет"?

Сколько раз ты думал: "Хочу больше денег, но если попрошу – вдруг откажут, и я стану в глазах начальства жадным нытиком?"

Логика понятна. Но знаешь, кто точно не получит прибавку? Тот, кто её не попросит.

Разбираем по шагам, как просить повышение дохода грамотно – без страха, с максимальными шансами на успех.

1. Подготовь аргументы

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

Какие проблемы ты решил?
Как улучшил процессы?
Что сделал сверх ожиданий?

Пример: "За последние 6 месяцев я оптимизировал процесс сборки фронта, ускорив CI/CD в 2 раза. Это сэкономило 15 часов работы команды ежемесячно".

2. Выбери правильный момент
Не в середине дедлайна, когда у всех горит.
Лучше после удачного проекта или квартального ревью.

Если рукль доволен результатом – шансов больше.

3. Покажи ценность, а не потребности
Ошибка новичков: "Мне нужна прибавка, потому что инфляция".
Лучший подход: "Я увеличил ценность компании – логично, если моя зарплата это отражает".

4. Как сказать?
Допустим, твоя цель – +50% к зарплате. Пример диалога:

Ты: "Я хочу обсудить свою роль в компании и пересмотреть уровень компенсации. За последние 6 месяцев я [список достижений]. Считаю, что мой вклад увеличился, и хочу предложить пересмотр зарплаты".

Если слышишь: "Пока нет бюджета", не падай духом. Уточни:

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

5. А если всё-таки "нет"?
Главное – не воспринимать отказ лично. Это не значит, что ты плох. Это значит, что в компании может не быть ресурса или тебе нужно доработать аргументы.

Но если твои заслуги очевидны, а денег всё нет – начинай искать новую работу.

Вывод:
Бояться — нормально. Но если не просишь – точно ничего не изменится. Подготовься, уверенно обсуди – и получишь то, что заслуживаешь.

Пост знакомства для новеньких

Я Дэн, senior frontend-разработчик с 6 годами опыта и твой будущий ментор. В своем блоге помогаю расти профессионально и в деньгах.

На старте, в 2019 году, моя зарплата была 50 тысяч рублей. Вскоре я вырос как специалист - но не понимал, как повысить доход. Целый год я учился и собирал систему. С тех пор тестировал и улучшал свой подход. Я повторял конкретный набор шагов - и каждый раз делал х2 к зарплате.

В итоге, 2025 моя зарплата стала в 6.5 раз выше, чем на старте.

Я нашел ответы на вопросы:

- Как оформить резюме, чтобы пригласили на собеседование?
- Как вести себя на HR и техническом, чтобы дали оффер?
- Как действовать системно, чтобы повторять рост х2 каждые несколько лет?

А еще подготовил для тебя гайд, как за 5 шагов прокачать свое резюме. ✅

Лови! ⬇️⬇️⬇️