Reactify | Frontend Разработка

Грейд: Мидл+/Сеньор

Компания: Wildberries

Опыт: 3.5

Этап: Финал

Вилка: 250к - 300к

Пример собеседования, на котором копают опыт и софты. Куча вопросов. Собеседование проходило недавно

Вопросы:
- Можешь рассказать, почему решил уйти с текущего проекта?
- Что тебе больше всего нравится в твоей работе?
- Приходилось ли тебе взаимодействовать с другими командами, и что обычно включало это взаимодействие?
- Как вы получали задачи: был ли бэклог, кто их формировал?
- Какую роль ты играл в декомпозиции задач? Какие подходы предлагал, по какому принципу действовал?
- Можешь вспомнить задачу, которая была самой неопределенной? Как справлялся с ней?
- Что, на твой взгляд, важнее — интересы бизнеса или интересы пользователя?
- Продвигаешь ли ты свои идеи и новшества в команде? Как ты аргументируешь свои предложения?
- По каким признакам или метрикам определяешь, что команда действительно продуктивна и приносит ценность?
- Какой был состав команды, в которой ты работал?
- Как у вас проходило код-ревью? Что для тебя в нем важно, и что бы не хотелось видеть?
- Бывали ли сложности в общении с коллегами? Может, вспомнишь какой-то спорный случай?
- Сталкивался ли ты с неэффективными процессами? Как к этому относишься?
- Приходилось ли тебе принимать риски — продуктовые или технические? Как ты к ним подходил?
- Были ли ситуации, когда горели сроки? Как ты считаешь, кто в этом виноват?
- Как ты организуешь свое личное развитие, что читаешь? Какие видишь перспективы?
- Интересно ли тебе попробовать себя в роли менеджера?
- Был ли у тебя опыт самостоятельного ведения проектов?
- Какая из задач была для тебя самой сложной? Почему?
- Как ты организуешь работу над задачей? Используешь ли планирование?
- Получал ли ты развивающий фидбек по своим софт-скиллам? Как на это реагировала?
- Как оцениваешь задачи? Вспомни случай, когда пришлось работать с претензией или получать обратную связь — как действовал?
- Какие у тебя ожидания от новой команды?
- Какие ожидания у тебя к руководителю?
- Как ты оцениваешь качество своей работы?

Какие претензии у айтишников к новичкам?

Это дополнение к посту о Дедовщине в IT. Стрим про Гейткиперов)
Залетайте на стрим 🔥

https://www.youtube.com/watch?v=fGl689uzDuY

🚀 [Версия 1.0.0] - Релиз платформы!

Привет, друзья! 🎉 Мы рады сообщить, что первая версия нашей платформы готова и доступна! В этой версии:

✔️ Добавлен сервис подготовки к собеседованиям.

Мы сделали первый шаг и теперь работаем над новыми фичами, чтобы помочь вам ещё быстрее и эффективнее подготовиться к важным этапам в карьере. Ваши отзывы очень важны для нас, пишите, что вам нравится и что можно улучшить! 💬

🔥 Что дальше? Следите за обновлениями – скоро будет ещё больше интересных возможностей!

👍 Обучайтесь, общайтесь, растите вместе с https://yeahub.ru

#release #news #update #yeahub

👀 Контроль сотрудников на работе: история из личного опыта

Когда я впервые столкнулся с системой тайм-трекинга, работая в аутсорсинговой компании, это стало для меня настоящим испытанием. Я тогда занимался разработкой криптокошелька для лондонской компании, и это был мой первый проект на европейском рынке.

Рабочий день начинался с обязательного включения тайм-трекера. Программа фиксировала всё: время работы, активность на клавиатуре и мыши, а также записывала экран. Если активность снижалась, мог последовать вопрос от тимлида: "Почему у тебя так мало активности? Ты целый день ничего не делал?".

Самое сложное заключалось в том, что после 10 минут бездействия таймер сбрасывался на 10 минут назад и останавливался. Нужно было набирать ровно 8 часов активности — ни минутой меньше. Представьте, как я бегал в туалет, делал чай или обедал! У меня не было ноутбука, поэтому я буквально каждые 8 минут возвращался к компьютеру, чтобы не сбился таймер.

Работать в таких условиях было невероятно тяжело. Обычное чтение документации или размышления над задачей превращались в стресс: нельзя просто сидеть и думать, обязательно нужно было шевелить мышкой. Ты не сосредотачиваешься на задачах, а следишь за таймером.

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

А у вас был подобный опыт? Делитесь в комментариях!
Если интересна тема, рекомендую видео Антохи: https://youtu.be/3eMAc4Dc5sY.

Флешбеки до сих пор... 😬

🤫 Почему ИИ не заменит программистов

Ко мне часто приходят на консультации по фронтенд-разработке, и один из самых популярных вопросов звучит так:
"А стоит ли вообще начинать учиться, если ИИ скоро заменит программистов? Я боюсь, что выучу всё, а работы не будет, потому что всё будут делать машины."

Я решил поделиться своими мыслями на эту тему. Вот несколько причин, почему я уверен, что ИИ не заменит программистов:

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

Креативность и нестандартное мышление
Программирование — это не просто написание кода. Это поиск новых решений, генерация идей и эксперименты. ИИ отлично справляется с рутиной, но творческий процесс, интуиция и способность мыслить "вне коробки" остаются человеческой прерогативой.

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

Работа с неопределенностью
В программировании часто встречаются задачи, у которых нет очевидного решения. Здесь важно умение экспериментировать, анализировать результат и менять подход. ИИ действует строго в рамках заданных алгоритмов, а неопределённость для него — сложный барьер.

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

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

Недавно слышал мнение, что ИИ достиг своего "потолка эффективности". Увеличение мощностей больше не дает таких же резких улучшений, как раньше. Это отражает принцип Парето: 20% усилий дают 80% результата.

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

❓ А что вы думаете?

#ai

🥸 Дедовщина в IT

Я давно вышел из всех чатов, где "помогают" новичкам. Почему? Из-за дедов, которые самоутверждаются на начинающих. Сколько раз я видел, как новичка прессуют: "это не твое", "иди обратно на завод", "ты тупой". Как только начинаешь говорить о курсах, сразу: "Какие курсы? Ты чего? Книги читай, и только на английском! Документацию учи!"

IT — обычная сфера, как и все. Не надо делать из нее романтику или заставлять каждого изучать computer science, алгоритмы и т.п. Хороший фронтендер — это человек, который применяет технологии, справляется с задачами и умеет писать код.

Если будет время, посмотрите это видео на досуге. База 💯.

https://www.youtube.com/watch?v=MGWZP4OjCHM

👩‍💻 React Новости

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

Ставьте лукас, если смотрели React Новости 👍

🔗 Ссылка на видео

🥵 Стресс после трудоустройства

Трудоустройство в IT — это всегда вызов. Независимо от уровня опыта, у большинства возникают одинаковые опасения: "Разберусь ли в проекте?", "Не разочарую ли команду?", "Смогу ли выполнить ожидания?" Эти вопросы сопровождают нас не только в начале карьеры, но и спустя годы работы.

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

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

💡 Вот несколько советов для снижения стресса на новом месте:

1. Дайте себе время
Не требуйте от себя всего сразу. Привыкание к проекту занимает время.

2. Задавайте вопросы
Никто не ожидает, что вы всё знаете. Спрашивайте — это быстрее приведет к пониманию задач.

3. Осваивайте поэтапно
Беритесь за одну задачу за раз, избегайте перегрузки.

4. Найдите коллег для поддержки
Опытные сотрудники могут поделиться знаниями и упростить адаптацию.

5. Фиксируйте прогресс
Записывайте успехи, чтобы видеть результаты и укреплять уверенность.

6. Снимите самокритику
Ошибки неизбежны. Оценивайте свои усилия, а не только результаты.

7. Берегите здоровье
Режим сна и питания помогут избежать выгорания.

Антоха на стриме рассказал подробнее про трудоустройство и испытательный срок. Кстати, у него новый YouTube-канал — в ближайшее время он выпустит много годного контента 👍

https://www.youtube.com/live/KMsrfLvRLN0?si=TEFseo6--7wDmqGF&t=520

⛔️ Топ причин, по которым могут уволить во время испытательного срока

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

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

1. Невнимательность к качеству верстки
Представьте, что вы — мидл-разработчик в компании с зарплатой 200к. Если на проверку вы отправите верстку, не соответствующую макету, вас не только неоднократно отправят на доработку, но и запомнят как ненадежного сотрудника. Поверьте, никто не захочет тратить дни на тестирование вашего кода, если вы каждый раз правите только одно замечание, а следом появляются новые. Это загружает тестировщика, который гоняет вас с правками 4-5 дней, и раздражает коллег, вынужденных ревьюить один и тот же код снова и снова.

💡 Что делать:
- Проверяйте верстку на соответствие макету с помощью Pixel Perfect.
- Старайтесь устранять все замечания разом, чтобы не засыпать коллег бессмысленными коммитами.

2. Отправка неаккуратных Pull Request
Задача — отправлять чистый, аккуратный коммит с минимальным количеством файлов и изменений. Если в файле не было задачи или необходимости в правках, не вносите туда изменения, даже если это просто пробел, кавычка или отступ. Изменение структуры, не связанной с задачей, отвлекает и создает беспорядок в истории проекта.

💡 Что делать:
- Добавляйте в PR только те файлы, которые реально были затронуты задачей.
- Не меняйте стили и форматирование файлов, если это не связано с вашей задачей.

3. Отправка нерабочей функциональности
Если вы сделали кнопку для открытия меню, убедитесь, что меню действительно открывается. Когда тестировщик запускает ваше приложение и видит, что оно не работает, это считается серьезной ошибкой. Подобные ошибки сразу попадают в "черный список". Ошибки функциональности — это прямой показатель недоработки перед сдачей.

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

4. Игнорирование пограничных случаев
Ваш код должен обрабатывать все возможные случаи, в том числе и пограничные. Например, пустые данные, необычные пользовательские вводы, нестандартные разрешения экранов. Это позволяет избежать "неожиданных" ошибок на продакшене и сохранить положительную репутацию кода.

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

❗️ Следите за тем, что вы даете на проверку!

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

Учитесь работать над ошибками и доводить каждую задачу до идеала.

#frontend #work

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

В итоге не всегда самые компетентные и талантливые специалисты находят работу — часто именно те, кто умеет «адаптироваться» под автоматические фильтры и алгоритмы. Это ситуация, когда накрутка и ухищрения становятся частью игры. И все потому, что качественная работа выполняется лишь единицами. «Смузихлеб» — явление, где эффективность приносится в жертву потоку задач.

Накрутка, фильтры и нейронки не нужны, если каждый начнет выполнять свою работу на 100%.

Посмотрите видео Антохи, рекомендую 👍

🔗 https://www.youtube.com/watch?v=XMh6jFELLsw

🖥 Функция-конструктор в JavaScript

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

✏️ Создание функции-конструктора
Функция-конструктор выглядит как обычная функция, но она пишется с заглавной буквы по соглашению, чтобы отличаться от других функций. Внутри конструктора используется this для задания свойств создаваемого объекта.

function Person(name, age) {
    this.name = name; // свойство name
    this.age = age;   // свойство age
}

🎮 Создание объектов с помощью конструктора
Чтобы создать объект с помощью конструктора, используется оператор new. Он:

- Создает новый пустой объект.
- Связывает его с this внутри конструктора.
- Возвращает этот объект.

const person1 = new Person("Alice", 25);
console.log(person1.name); // Alice
console.log(person1.age);  // 25

➕ Добавление методов в конструктор
Если мы добавим метод прямо в конструктор, то он будет копироваться в каждый новый объект, что может тратить память.

function Person(name, age) {
    this.name = name;
    this.age = age;
    this.sayHello = function() {
        console.log(`Hi, I'm ${this.name}`);
    };
}

const person1 = new Person("Alice", 25);
person1.sayHello(); // Hi, I'm Alice

⚙️ Оптимизация с prototype
Для методов можно использовать prototype, чтобы метод существовал в одном экземпляре и не копировался для каждого объекта.

function Person(name, age) {
    this.name = name;
    this.age = age;
}

Person.prototype.sayHello = function() {
    console.log(`Hi, I'm ${this.name}`);
};

const person1 = new Person("Alice", 25);
const person2 = new Person("Bob", 30);

person1.sayHello(); // Hi, I'm Alice
person2.sayHello(); // Hi, I'm Bob

💭 Как работает this в конструкторе
В функции-конструкторе this указывает на новый объект, который создается при вызове через new. Это позволяет настраивать свойства и методы нового объекта.

💎 Продвинутые аспекты
- Наследование. Используя прототипы, можно создавать наследуемые свойства и методы.
- Проверка с instanceof. Для проверки, создан ли объект через конструктор, можно использовать instanceof.

console.log(person1 instanceof Person); // true

#javascript #this #function

👩‍💻 Принципы Redux

Redux основывается на нескольких ключевых принципах, которые помогают организовать и управлять состоянием приложения.

🔒 Единое хранилище (Single Source of Truth)

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

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

const initialState = {
    todos: [],
    user: null,
};

// Всё состояние хранится в одном объекте
const state = {
    todos: ['Задача 1', 'Задача 2'],
    user: { name: 'Иван', age: 30 },
};

👀 Состояние только для чтения (Read-Only State)

Единственным способом изменения состояния является отправка действия (action). Это гарантирует, что изменения состояния происходят только через определенные точки (actions), что делает их предсказуемыми.

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

// Действие для добавления задачи
const addTodo = (text) => ({
    type: 'ADD_TODO',
    payload: text,
});

// Изменение состояния только через действие
store.dispatch(addTodo('Новая задача'));

✨ Чистые функции редюсеры (Pure Functions)

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

Чистые функции делают состояние предсказуемым и упрощают отладку. Они не имеют побочных эффектов и не влияют на внешние состояния.

const todoReducer = (state = initialState, action) => {
    switch (action.type) {
        case 'ADD_TODO':
            return {
                ...state,
                todos: [...state.todos, action.payload],
            };
        default:
            return state; // Возвращаем новое состояние, не изменяя текущее
    }
};

⬇️ Однонаправленный поток данных (Unidirectional Data Flow)

Поток данных в Redux всегда односторонний. Это означает, что данные передаются от состояния к представлению, и изменения состояния происходят только через действия.

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

// Пример потока данных
const mapStateToProps = (state) => ({
    todos: state.todos,
});

// Компонент получает данные
const TodoList = ({ todos }) => (
    <ul>
        {todos.map((todo, index) => (
            <li key={index}>{todo}</li>
        ))}
    </ul>
);

// Связываем компонент с Redux
export default connect(mapStateToProps)(TodoList);

#redux #frontend #react #flux