I hereby claim:
- I am gretchenfitze on github.
- I am gretchenfitze (https://keybase.io/gretchenfitze) on keybase.
- I have a public key ASAQkzBm5kmqj4wDhgON_sOe17SuAdjLnbIWGAFN2mkN8Qo
To claim this, I am signing this object:
gretchenfitze
/ keybase.md
Created
September 9, 2018 14:30
gretchenfitze
/ questions.md
Created
June 13, 2018 14:26
— forked from ozio/questions.md
Вопросы, которые мне задавали (или не задавали) на позицию Senior Frontend Developer (~10 их)
Я не пытался тут собрать все вопросы, которые хорошо бы задавать, а лишь те, что мне задавали (если не указано обратное), так что не неситесь жаловаться, что вы не нашли своих любимых и коварных. Так же, я не привожу список всяких логических задачек, которых, слава богу, было минимум и задачек с написанием кода на листке бумажки что, к сожалению, всё ещё распространено.
React:
- Жизненный цикл компонента? В какой метод какие аргументы приходят? Где и как лучше обновлять стейт?
- Что такое функциональный компонент и PureComponent? В чём разница?
- Что такое Redux?
- Что такое сайд-эффекты?
- Какие бывают миддлвары в Redux?
- Для чего нужен redux-thunk?
- На чём построена redux-saga (на генераторах) и для чего она нужна?
- Ревью - задача с наивысшим приоритетом. Желательно приступать к ревью как можно скорее. Это поможет избежать массового мержа задач в конце спринта и не будет тратить время коллег, особенно если задачи взаимозависимы. Начинаем ревью задачи при первом стабильном билде.
- Прежде всего нужно проверить соответствие указанного номера задачи, репозитория и версии указанным в Jira, а в ходе ревью обратить внимание, соответствуют ли внесенные изменения поставленной задаче.
- Названия коммитов и PR пишутся с большой буквы, они должны содержать номер задачи, описывать внесенные изменения и быть обезличенными. Плохой пример: “сделал правки”, хороший пример: “UFSUI-1111 Исправлена работа скролла в Select при открытии вверх”.
- На ревью обязательно нужно как посмотреть код, так и проверить корректность работы компонента с внесенными изменениями. Код стоит проверять досконально в каждом файле. При проверке работы нужно попытаться воспроизвести все возможные кейсы использования компонента. Не стоит пренебрегать одним из ш