Неоплачиваемые стажировки: за/против

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

Прежде всего нужно понять: проект проекту рознь. Это - самый главный фактор, который определяет, есть ли смысл вписываться в какой-либо проект на волонтерских началах. Для того, чтобы вы могли прокачать свои навыки на проекте, на этом проекте вы должны получать обратную связь от опытного разработчика, который подсветит вам ваши пробелы и ошибки. Например, блоггер S0ER периодически набирает ребят в проект Naris. Я сама участвовала в этом проекте, будучи уже далеко не джуном, и подчерпнула для себя много интересных разработческих фишек. Также многие крупные компании - например, Газпромбанк, Озон, ЦФТ, KTS - периодически набирают учеников на бесплатные курсы, в рамках которого вы также будете делать какой-либо учебный проект и получать обратную связь от менторов. Прокачка скиллов на таких проектах позволит вам не просто писать работоспособный код, но и сделать его гибким, поддерживаемым и масштабируемым.

Однако сейчас на рынке появилось много предложений бесплатных стажировок от мелких работодателей. Часто в таких вакансиях обещают нанять вас в штат после бесплатной стажировки. За редким исключением, такие проекты не способны вас ничему научить, потому что у них нет такой цели, на них не применяются best practices, часто формальное ревью. По сути, это просто бесплатная работа. Я советую вам избегать таких проектов и не надеяться, что после бесплатной стажировки вас обязательно возьмут в штат, потому что у работодателя есть прекрасная возможность этого не делать. На таком проекте вы просто потеряете время и мало чему научитесь.

Короче говоря: не стоит вестись на обещания «устроить в штат после бесплатной стажировки». Соглашайтесь только на те проекты, которые выгодны прямо здесь и сейчас. Выгода в бесплатных проектах заключается в возможности прокачать свои навыки и получить обратную связь от опытных коллег. Если проект не предлагает вам ни прокачки скиллов, ни денег, то не стоит тратить на него ни минуты своего времени.

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

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

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

<Frontend вдохновляет/> - авторский канал Александра для тех, кто хочет получить заряд мотивации. Истории с работы, юмор, разбор примеров кода и советы новичкам (и не только им) - все здесь 🙂

{ Снежные строки } — канал о фронтенд разработке, где можно учиться вместе с автором. Здесь разбирают JavaScript, React и другие технологии, делятся опытом прохождения собеседований, тестируют новые подходы в разработке. Всё, чтобы развиваться в профессии и прокачивать навыки!

Коучинг для ИТ с Анной Бикеевой — канал коуча с 17-летним бэкграундом в ИТ, где автор рассказывает на своем опыте и опыте клиентов, как работа с мышлением помогает расти в карьере и громко заявлять о себе!

В АйТи из Уфы - канал о буднях во Frontend разработке без технических деталей.
Раушан рассказывает как перешёл из другой сферы, проходит собесы и собирается в web3 разработку.
Делится чем интересуется вне работы, чтобы держать кукуху на месте 🙃

IT Инсайты — канал лида разработки с 12-летним опытом в ИТ-сфере, где публикуются полезные мысли и советы для сотрудников ИТ и их руководителей. Канал будет интересен как начинающим, так и опытным специалистам 🤗

Как новичку дебажить? Часть 1.

Я довольно много занимаюсь менторингом джунов и заметила такую вещь: практически все джуны не умеет дебажить. На курсах учат писать код и делать фичи, а не дебажить уже имеющийся код и лечить баги. Потом, когда такой джун выходит на свою первую работу, чаще всего в качестве первых задач он получает багофикс и смотри на него как баран на новые ворота в полной растерянности, не понимая, что с ним делать. К счастью для джунов, они могут подписаться на мой канал, где я постепенно буду раскрывать эту тему😊

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

Второе, что критически необходимо понять, если вы фронтендер: современный фронтенд по большей части использует реактивные фреймворки, такие как React, Vue, Angular (в этом посте мы не будем душнить про то, что React - библиотека, а не фреймворк, оки?☺️). Реактивные - означает, что сначала меняются данные, а затем фреймворк реактивно обновляет свой ui (обратный процесс тоже возможен, пока не будем об этом). Если вы пишете на jquery, то для вас это не работает, вам нужно обновлять ваш ui ручками.

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

Например: вы столкнулись с проблемой, что данные из профиля пользователя неверно отображаются. Вам нужно найти место, где они хранятся (например, стор приложения), вывести их в console.log, затем посмотреть, через какую цепочку функций и компонентов они попадают в ваш ui элемент, вывести их в лог так же в этих звеньях, и, наконец, вывести их в лог в самом ui компоненте. Необязательно ставить лог прям в каждом звене, на весь путь достаточно 2-3 логов, а дальше можно ставить дополнительные логи по мере того, как будет проясняться, в каком куске программы данные передаются неверно. В следующих посте я покажу на примере, как это можно сделать.

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

#дебаг

Как новичку дебажить? Часть 2.

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

1️⃣ Помните, в прошлой части мы говорили о том, что приложение - это данные, которые меняются по ходу жизни приложения? Тема - это тоже данные. Наша первоочередная задача - найти, где они хранятся. Хранятся они в какой-то переменной в коде. Эта переменная может читать данные из local storage, из параметров урла, она может выглядеть как поле в redux или значение в useState, но она точно существует. Наша задача ее найти. Как? Для этого надо найти в коде тоггл, посмотреть его обработчик onchange и посмотреть, куда этот обработчик пытается писать данные. Так вы найдете место, где хранится значение темы.

2️⃣ Допустим, на предыдущем шаге вы выяснили, что тема хранится, например, в контексте. Теперь наша задача - проследить весь путь этих данных от провайдера контекста до конкретных компонентов. Возьмите для примера один какой-нибудь компонент. Пусть это будет какая-нибудь панель. Затем посмотрите, откуда она получает данные о теме. Она может получать данные из провайдера напрямую, из пропсов, возможны разные варианты.

3️⃣ Допустим, наша панель получает данные из пропсов. Получается, данные передает родитель. Теперь надо найти, откуда получает данные родитель. Нам нужно распутать всю цепочку, как данные из места, найденного в п.1, попали в наш компонент. (Примечание: со временем вам не нужно будет разбирать всю цепочку, достаточно будет нескольких звеньев, но поначалу такой полный разбор эффективен для обучения)

4️⃣ Вы выяснили путь, по которому данные попадают из контекста в панель. Теперь наша задача - определить, на каком шаге данные искажаются неверно. Для этого ставим console.log в панели и в том месте, где один из родителей получает данные из контекста, и в панели тоже.

5️⃣ Вы снова воспроизводите баг и видите: ваш родитель получает верную тему из контекста и передает ее вниз по дереву компонентов, но сам компонент панели получает от своего родителя старую тему! Добавляем console.log в промежуточных компонентов по цепочке передачи данных.

6️⃣ Вы обнаружили, что последний компонент, который получил данные верно, был компонент, скажем, Wrapper, а дальше уже данные передаются неверно. Отлично, мы нашли проблемное место - это компонент Wrapper!

7️⃣ Теперь нужно посмотреть, как именно Wrapper передает данные вниз. Скорее всего, на этом этапе вы уже сможете вручную заметить ошибку в коде - например, компонент может мемоизировать данные и передавать мемоизированные данные. Достаточно будет заново вычислять мемоизированное значение при смене темы и баг будет пофикшен🎉

#дебаг

Продолжаем тему дебага при помощи логов. Как вы думаете, что мы увидим в консоли?

const obj = {};
console.log('1', obj);
console.log('2', obj.a);
obj.a = 'aaa';

Предыдущий пример логирования дает очень интересный результат. В браузере вы увидите объект, в котором при раскрытии будет поле "a", записанное уже после лога. Так происходит потому, что в javascript объект - это ссылка, и при раскрытии объекта по ссылке в некоторых браузерах - например, в хроме - вы можете увидеть уже измененное состояние объекта. Таким образом, слепое доверие консоли браузера при логировании ссылочных типов может стоить вам нескольких часов бесплодного дебага. Это особенно актуально, если вы используете описанный мной в предыдущих постах способ "проследить, как меняются данные на своем пути от источника к моменту вывода".

Так как же надежно логировать объекты? Я логирую объекты, преобразуя их в строку при помощи JSON.stringify:

JSON.stringify(obj, null, 4)

Такой код преобразует объект в примитивную строку и отформатирует 4 пробелами. Используя данный способ, вы гарантированно выведете актуальное на момент лога состояние объекта.

P.S. В комментариях справедливо заметили, что в примере из опроса в лог выведется пустой объект, а уже на момент раскрытия в него допишется свойство. Признаю свою вину за неверную формулировку в вопросе. Единственной целью этого опроса было показать, как вы можете ошибиться при логировании объектов в javascript, и, надеюсь, мне удалось достичь этой цели 😊

#дебаг

Почему программисты ненавидят работать с чужим кодом?

Вот представь, что тебе доверили достроить за другим прорабом лабораторию на острове. Ты приходишь на объект, а там кроме недостроенного здания: огромный вентилятор (размером со здание), большой воздушный шар и комната набитая швабрами. Почесав голову, ты разбираешь этот хлам и доделываешь лабораторию. Сдаешь объект ученным, но через 5 минут они выбегают с криком: "УТЕЧКА ЯДОВИТОГО ГАЗА!!!".
— Как так–то, б..ть! Должно же работать! — в отчаянии кричишь ты и звонишь прошлому прорабу:
— Вася, у нас ядовитый газ потёк! В чем проблема?
— Не знаю, должно было все работать. Что–то в проекте менял?

— Немного, швабры вынес...
— Швабры потолок держали!
— Что??? Что, б...ть, извините???
— Говорю, швабры потолок держали. Над ними цистерны с газом были. Очень тяжелые, пришлось в комнату снизу швабры напихать.

— Ты хотя бы записку на двери повесил бы, что швабры для держания потолка! У нас тут ядовитый газ течет! Что нам делать?
— Включай вентилятор. Он сдует газ с острова.
— Я его, б...ть, демонтировал сразу же!
— Зачем?
— Зачем ты построил 120 тонный вентилятор? Ты не мог положить ящик бл...ских ПРОТИВОГАЗОВ?
— Ящик противогазов искать нужно, а вентилятор у меня с прошлого заказа оставался.

— Вася, я убрал твой вентилятор! Мы тут задыхаемся!
— Херли вы тогда там делаете? Садитесь на воздушный шар и у..бывайте!

—-
Баян, но каждый раз смеюсь

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

The pit of Failure (or Success)

Часто при проектировании API кроме того что нам важно думать не только о фичах и возможностях которые он дает, но и какой импакт этот API несет при использовании. И тут есть 2 противоположных концепта: Falling Into The Pit of Success/Failure или при переводе Упасть В Яму Успеха/Неудачи.

Какие же ключевые принципы разработки за этим скрываются? Если сократить и упростить, то выйдет: Делай так чтобы правильно было использовать легко, а неправильно сложно. Те наша задача мотивировать людей и поощрять правильное использование API и делать так, чтобы некорректное использование всем видом кричало, что тут дела обстоят не так (fall into the pit of success). Обратный пример, когда API словно подталкивает использовать себя грязно, а использовать корректно больше похоже на тернистый путь или полосу испытаний (Я думаю каждый сталкивался с таким ощущением)

Давайте возьмем пару примеров из API и рассмотрим их:
React:

<div dangerouslySetInnerHTML={{ __html: "Hello" }} />

И тут нам интересно API dangerouslySetInnerHTML, видите что оно делает? Да, оно всем своим видом кричит, что вы делаете что-то опасное и нехорошее, а громоздкость с { __html: "Hello" } дополняет картинку. В добавок вам еще будет сложнее точно сходу вспомнить правильное написание и вы пойдете в документацию, где вам еще раз дадут понять: "скорее всего ты делаешь что-то не то". Это прекрасный пример того, как с помощью API вам не дают применить нечто потенциально опасное.

И вот сегодня я увидел обратный пример из мира Svelte:

let double = $derived(count*2);
double = 3.14;

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

В реактивной системе необходимость делать writable вычислимые поля достаточно редка. Кроме того нам дали возможность делать только прямую запись, а не условный сеттер который бы позволил сделать two way connection, нет, это не тот случай! Те мы можем просто лезть в кэш вычислимого свойства и подменять его до изменения значения. Ну надо же людям эту фичу, в чем проблема? А в том, что в 99% случаев эта фича не нужна, а вот все 100% $derived полей стали вместо read-only теперь writable. И никакой вас TypeScript не спасет от записи в него случайно (например, при рефакторинге) и вы больше видя перед собой $derived не можете быть уверены записывают что-то в него или нет, эта информация лежит где-то в другом месте компонента и пока вы не прочтете код компонента полностью вы больше не можете быть в этом уверены.

Таким образом эта возможность не подталкивает к правильному использованию сигналов, делает так что допускать случайные ошибки стало проще и при этом осталось относительно скудным по возможностям (как и написал это не дает возможность делать two way connection). С другой стороны мы покрыли возможность 1% от случаев. Вот это пример, когда мы видим собой pit of failure, да нас не мотивируют прямым образом использовать этот функционал неправильно, но "заборчик" рядом с ямой куда-то унесли.

Как этого можно было избежать?
Использовать отдельный нейминг

let double = $writableDerived(count*2);
double = 3.14;

Или использовать отдельный параметр

let double = $derived(count*2, { writable: true }); // или любая другая явная модификация
double = 3.14;

Или на худой конец если мы хотим оставить магию в нашем мире, то создать явное API

let double = $derived(count*2);
$modifyDerivedCache(double, 3.14); // мы сделали неудобное, но однозначное API

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

Не думайте что это "написать плохо на чем угодно можно" /"вопрос прямых рук". НЕТ! Вы, как автор API, должны формировать у людей прямые руки, а кривые выпрямлять. Пожалуйста, прикидывайте в голове эти сценарии: "мотивирую ли я делать что-то плохое" и "поощряю ли я правильное использование". Спасибо...

Интерактивный ребейз. Часть 1.

В разработке довольно часто возникает необходимость отредактировать историю коммитов. Запутанная история комиттов осложняет ее чтение, когда требуется выяснить, какие изменения происходили с продуктом в течение последних нескольких версий. В некоторых командах принято нажимать галочку “squash commits” перед мерджем. Эта опция собирает все коммиты из мердж реквеста в один. Но что, если я не хочу собирать все коммиты в один? Например, в мердж реквесте я сделала один багфикс и одну фичу и хочу поделить эти правки на два разных коммита. В этом случае, если в моей фиче окажется баг, я смогу быстро откатить ее при помощи реверта коммита, не затронув багфикс. В этом случае можно легко отредактировать историю коммитов при помощи интерактивного ребейза.

Итак, допустим, у меня есть следующая история комиттов:

commit db75a1b15cddea5cae2dd047db04dfce69ff5186
  Add feature
commit 76d6818aa1ad6d68e27306b541ff7ab04090bc5b
  Bugfix

После чего я поняла, что в bugfix нужно добавить еще код. У меня получилась вот такая история комиттов:

commit ea5ed9f0245f70853069454d19d53e661679dfa3
  Bugfix too
commit db75a1b15cddea5cae2dd047db04dfce69ff5186
  Add feature
commit 76d6818aa1ad6d68e27306b541ff7ab04090bc5b
  Bugfix

Держите рецепт, как слить первый и третий коммит в один:

1️⃣ Заходим в интерактивный ребейз при помощи git rebase -i. Нам потребуются только три последние коммита, поэтому указываем git rebase -i HEAD~3.

2️⃣ Видим историю наших коммитов. В отличие от истории, которую пишет нам git log, сверху будет самый старый коммит.

  pick 76d6818 Bugfix
  pick db75a1b Add feature
  pick ea5ed9f Bugfix too

3️⃣ В текстовом редакторе меняем места третий и второй коммит

  pick 76d6818 Bugfix
  pick ea5ed9f Bugfix too
  pick db75a1b Add feature

4️⃣ Теперь нам нужно сделать слить два коммита по багфиксу в один. Подсказка в текстовом редакторе говорит нам, что мы можем использовать fixup:

# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
#                    commit's log message, unless -C is used, in which case
#                    keep only this commit's message; -c is same as -C but
#                    opens the editor

Указываем флаг f для коммита, который мы хотим слить:

pick 76d6818 Bugfix
f ea5ed9f Bugfix too
pick db75a1b Add feature

5️⃣ Выходим из вима с сохранением (не буду писать про это подробно, в интернете много мемов на тему выхода из вима) и вуаля, ваша история перезаписана, два коммита слиты в один🎉

#интерактивный_ребейз

Зачем нужны @types/node во фронтовом приложении

И правда, зачем? Мы ведь не на node.js приложение пишем. Но тайпинги ноды могут нам потребоваться, например, в конфиге сборщика, если мы хотим задать альясы путей.

Допустим, мы указываем альясы путей как-нибудь так: '~components': path.resolve(__dirname, './src/components’). Для этого нам нужно импортировать в файле конфига стандартный модуль path. И тайпскрипт сругается на него, потому что он не знает, что такое path. Для того, чтобы решить эту проблему, необходимо установить @types/node в ваше приложение как dev зависимость. В этом же пакете будут тайпинги и для других стандартных модулей ноды, например, fs.

Как организовать компоненты в ui kit?

При разработке ui kit многие команды применяют storybook, который позволяет наглядно отобразить компоненты дизайн системы как для дизайнеров, так и для разработчиков, а также позволяет писать простые скриншотные тесты. Однако почти все команды рано или поздно сталкиваются с необходимостью как-то группировать компоненты в сторибуке, чтобы он не превратился в свалку, в которой сложно что-то найти. Мне нравится подход atomic design.

Atomic design делит компоненты на пять уровней: атомы, молекулы, организмы, шаблоны, страницы. В разработке ui kit я обычно использую первые три. Ниже поговорим про уровни компонентов подробнее.

1️⃣ Атомы. Самые маленькие строительные блоки компонентов. Это кнопки, инпуты, лейблы, радиобаттоны, иконки.

2️⃣ Молекулы. Композиции атомов. Простые группы UI, функционирующие вместе. Например, Search - компонент, состоящий из инпута, лейбла и кнопки.

3️⃣ Организмы. Сложные группы молекул, атомов, других организмов. Представляют собой отдельные независимые участки интерфейса. Организмами могут быть шапка сайта, подвал сайта, форма авторизации, форма покупки и тд.

4️⃣ Шаблоны. Компоненты, которые определяют структуру страницы. Например, компонент Layout, в котором есть шапка и подвал, и который позволяет использовать его с любым конвентом.

5️⃣ Страницы. Отдельные страницы системы.

Поскольку шаблоны и страницы обычно являются частями конкретной системы и не переиспользуются между проектами, они часто не выносятся в ui kit (хотя я встречала проекты, в которых используется общий компонент Layout для нескольких систем, но все же это довольно редко). В ui kit выносятся переиспользуемые между проектами компоненты - атомы, молекулы, организмы. Такое разделение на три части довольно удобно для сторибука, потому что позволяет отделить атомарные компоненты от компонентов-фич, представленных организмами.

Выше на рисунке представлены примеры атомов, молекулы и организма: атомами являются простой текст, инпут, кнопка, молекулой - компонент поиска, организмом - шапка сайта.

Сохраняем настройки UI в local storage.

Предположим, у вас есть некоторая таблица товаров, которую пользователь может сортировать и фильтровать. Вы хотите, чтобы выбранные пользователем фильтры не сбрасывались после перегрузки страницы, а сохранялись. Где хранить эти данные? Отправлять их на бекенд кажется избыточным: это настройки UI, а не данные какой-либо модели. Хорошим вариантом для хранения таких данных является local storage: он позволяет персистентно хранить данные на устройстве. Если пользователь зайдет на сайт с другого устройства, то он не увидит своих сохраненных фильтров, но это не выглядит критичной ситуацией. Поэтому local storage является хорошим решением нашей проблемы.

Держите рецепт:

1️⃣ Нам нужен ключ, в котором будут храниться наши фильтры. Например, PRODUCTS_FILTER. Будет хорошим решением вынести ключ в константу, чтобы гарантированно использовать во всем приложении верный ключ. В файле, где хранятся константы приложения (например, const.ts) создаем константу: const PRODUCTS_FILTER = 'PRODUCTS_FILTER'.

2️⃣ В том месте, где мы кликаем на фильтр, необходимо записывать обновленные данные в localStorage.

const saveFilters = (filters) => {
  localStorage.setItem(
    PRODUCTS_FILTER,
    Object.entries(filters)
      .map(([key, value]) => `${key}: ${value}`)
      .join(', ')
  );
};
...

onChange=((filterId, filterValue) => { 
    const newFilters = {…filters, [filterId]: filterValue};
    setFilters(newFilters)
    saveFilters(newFilters)
}

3️⃣ Теперь при загрузке загрузке нам достаточно инициализировать наши фильтры из localStorage

const initFilters = () => {
    const savedFilters = localStorage.getItem(PRODUCTS_FILTER);

    If (!savedFilters) {
         return [];
    } 

    return savedFilters.split(',').reduce((acc, item) => {
         const [key, value] = item.split(': ').map((str) => str.trim());
         acc[key] = value;
         return acc;
     }, {});
}


const [filters, setFilters] = useState(initFilters())

Таким же образом можно сохранять в localStorage и другие настройки UI: параметры сортировки, тему сайта, выбранные/скрытые колонки в какой-либо таблице тд

Мой хороший друг Саня написал пост про идиотские задачки, которые дают эйчары на скрининге.
Задачки и впрямь идиотские. Я работаю разработчиком больше восьми лет, решила тысячи задач и среди них не было ни одной, в которой бы черепашка влезала на столб. Тем не менее, моя точка зрения заключается в том, что на такие задачки можно реагировать двумя способами:

❌ Злиться на профнепригодность эйчаров и нанимающих менеджеров (непродуктивно)
✅ Просто решить эти задачки да и не париться из-за ерунды.

Ниже приведу решения двух задач из поста Сани.

Задача про черепаху и холм.

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

const dayDistance = 50;
const nightDistance = 30;

function getDays(distance) {
  if (distance <= dayDistance) {
    return 1;
  }

  let result = 1;
  let passed = dayDistance;

  while (passed < distance) {
    passed -= nightDistance;
    result++;
    passed += dayDistance;
  }

  return result;
}

Задача про рукопожатия.

Еще проще. Очевидно, что каждому новоприбывшему с номером n необходимо здороваться со всеми присутствующими, чье количество равно n-1. К этому мы прибавляем рукопожатия всех, кто уже был в комнате. Итого очевидно, что нам всего лишь нужно посчитать сумму арифметической последовательности (n-1) + (n-2) +…+ 1. Считаем по теореме Гаусса. Изи.

function calcHandshakes(n) {
  if (n < 2) {
    return 0;
  }

  const prevNumber = n - 1;

  return ((prevNumber + 1) * prevNumber) / 2;
}

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

P.S. В этом году надеюсь успеть сделать курс по алгоритмам на Stepik. Не изучала эту платформу, но курс будет либо бесплатный, если Stepik даст такое создать, либо по той стоимости, которую с меня запросит платформа - чтобы не работать себе в убыток. В курсе буду рассказывать про подход, которым можно пользоваться при решении задач + практические примеры. Stay tuned.