Як знайти свою першу роботу в ІТ, частина 3.
Співбесіда 🤯

👉 Читати частину 2

Дуже відповідальний момент - технічна співбесіда. Зазвичай (але не завжди), вона ділиться на три частини:

1. Знайомство. Якщо рекрутеру ви не могли розповісти всі технічні деталі вашого досвіду, то вже на цьому етапі ви можете зробити це в усій красі, адже перед вами сидять програмісти і вони вас розуміють. А взагалі, самопрезентація - це дуже важлива навичка, тому необхідно її також тренувати.

2. Теоретичні питання. Майже нереально здогадатись наперед, що вас будуть запитувати. Зазвичай, питають від простих питань до більш складніших. Але ж знову акцентуємо вашу увагу - не завжди. Юра якось проходив співбесіду чисто на frontend, а в нього почали відразу питати про бази даних 🙈 І також, якщо ваш колега проходив співбесіду в ту ж саму компанію, це не дає вам гарантію отримати такі самі запитання. В нас був такий досвід і сподівання, але питання виявились різними, тому що вели співбесіду різні програмісти.

На цьому етапі хочеться дати кілька порад:

- Не панікуйте. Знаю, це складно, але постарайтесь сприймати співбесіду як хороший шанс перевірити свої знання, а не останню можливість у вашому житті.

- Готуйтеся до співбесіди поступово. Не потрібно все вчити в останню ніч. Ви не виспитесь, все переплутаєте і зможете забути навіть ті поняття, які добре знали. Краще виділяти кілька годинок щодня і розбирати питання, в яких ви невпевнені.

- Знайдіть список питань для підготовки до співбесіди і розбирайте їх. Можете використовувати нашу рубрику #interview, де ми розбираємо питання різної складності. Також під цією рубрикою ми публікували багато підбірок питань та відповідей по різних технологіях. Можете використати FullStack Cafe, там є величезні списки питань, які можуть бути на співбесіді.

- Будьте готові до надто простих питань. Зараз ринок складний і від джунів вимагають те, що навіть не всі сіньйори знають. Але ніхто не відміняв фундаментальні поняття, які потрібно 100% знати.

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

3. Live coding. Як же я ненавиджу цей етап. Особисто в мене, коли хтось дивиться як я програмую, починається дуже сильний тупняк. Навіть було таке, що я відмовлялась від вакансії, бо там був етап live coding. Але зазвичай, від цього нікуди не дітись, потрібно опановувати себе і дивитись страхам в обличчя. Спробуйте знайти на сайтах HackerRank, LeetCode або Codewars приклади схожих задач і вивчіть алгоритми, які використовуються в їхньому вирішенні.

І на останок, обов'язково готуйте свої запитання. Це важливо і для вас, щоб розуміти особливості проєкту, продукту, команди, а також це показує співрозмовнику ваше серйозне ставлення до роботи.

Напишіть, як ви готуєтесь до технічної співбесіди, нам цікаво 💛

#experience

Як знайти свою першу роботу в ІТ, частина 4.
Фідбек 👻

👉 Читати частину 3

Ви молодці, вже все найгірше позаду, залишилось дізнатись результат ваших зусиль.

Найнеприємніше, що може статися на цьому етапі - це звичайно ж відмова. Найкраще, що ви можете зробити — це не сприймати відмову як кінець світу. Якщо компанія дала адекватний фідбек, чому ви їм не підійшли, то ви дізнались на що потрібно звернути увагу і на співбесідах з іншою компанією зможете проявити себе ще краще. Але якщо ви розумієте, що ви добре пройшли всі етапи, а компанія не може об'єктивно аргументувати свій вибір або просто впала на мороз - то є велика вірогідність, що проблема була не у вас. Зараз складний ринок і в один день може все змінитись. Тому не засмучайтесь і продовжуйте пошуки своєї першої роботи.

Якщо ж ви отримали позитивний фідбек, ми вас вітаємо. Єдині поради, це ще раз переконатись, що ви дійсно хочете в дану компанію, перечитати УВАЖНО всі умови та договір, ну і добре приготуватись до нової сходинки у вашій кар'єрі.

#experience

Чому [] в JS насправді не масив?

Масив - це набір елементів одного типу, що зберігаються в неперервному шматку памʼяті. Масив не можна просто взяти і розширити чи зменшити. Це можна побачити в традиційних масивах, наприклад, в С (int[3]).

А в JS те, що ми називаємо Array - насправді набагато складніша структура даних (яка насправді десь глибоко внизу напевно має справжні масиви). Все це зроблено для оптимізації та для спрощення роботи програміста. Тому, коли ви зробите щось на кшталт new Array(4 мільярди), то ваш компʼютер благополучно продовжить працювати далі. Ви навіть можете додати значення до першого та останнього елемента і все буде нормально.

Масив - одна з найпростіших структур даних. І ми вважаємо, що алгоритми та структури даних варто знати хоча б поверхнево, тому щоб тримати себе в тонусі, зараз проходимо безкоштовний курс від ThePrimeagen на Frontend Masters, який можемо і вам сміливо порекомендувати.

👉 Відкрити посилання

#experience

Коли і як ІТ-спеціалісту говорити про підвищення зарплати? 💰

Ми прекрасно розуміємо, що зараз складна ситуація на ринку і далеко не всім хочеться піднімати це питання. Але якщо ви вже достатньо часу працюєте в компанії і відчуваєте, що вже давно виросли, то можливо наші поради будуть вам в нагоді.

Почнемо з першого питання - коли потрібно говорити про підвищення зарплати?

1. Ви маєте сильне внутрішнє відчуття того, що ви гідні отримувати більше і вважаєте необхідністю, щоб вас підвищили. Ви взяли на себе багато відповідальності, багато чого навчились та зробили для компанії. Не потрібно плутати з банальним "хочу більше грошей". Це бажання має бути підкріплене вашим ростом як спеціаліста.

2. Не менш важливо підібрати правильний час для обговорення. Це може бути успішне завершення проєкту, вирішення важливої проблеми або збільшення робочого навантаження, з яким ви добре справляєтесь (тут важливо не затягувати, щоб не отримати вигорання).

Наступне питання - як підготуватись до розмови?

1. Ви повинні підготувати аргументи на свою користь - чого ви досягли за цей період, чого навчились, за що взяли відповідальність, скільки користі компанії ви принесли. Якщо коротко, нахвалюйте себе, але в міру 😅

2. Проаналізуйте ринок. Поцікавтеся, які зарплати отримують спеціалісти вашого профілю в інших компаніях. Можете використати статистику зарплат Djinni.

3. Називайте точну цифру. Так простіше. Всім.

4. Добре підготуйтесь перед обговоренням. Не чекайте, що під час розмови у вашій голові з’являться усі вагомі аргументи. Підготуйте їх заздалегідь. Наприклад, яка буде ваша реакція, якщо вам запропонують меншу суму або взагалі відмовлять.

Якщо ви залишились незадоволені від результатів обговорення, обов'язково узгодьте наступний перегляд і що ви повинні до цього часу зробити та навчитись. Чітко окресліть всі вимоги і працюйте над собою.

Якщо все дуже погано, ви можете завжди отримати контроффер і будувати розмову по-іншому. Не знаю, як зараз це працює, але раніше - це було дуже популярно. Але ми не рекомендуємо!

#experience

Next.js fallback 'blocking' 🧱

На проєкті ми використовуємо Next.js і деплоїмо застосунок на Vercel. І в певний момент проєкт перестав деплоїтись на сервер (при тому, що build проходив без проблем). Жодних деталей помилки ми знайти не могли, просто unknown error. Найвеселіше те, що спроба збілдити і задеплоїти старіші коміти теж викидала помилку.

На сайті в нас є досить довгий (дуууже довгий) список сторінок, що генеруються статично. Після довгої боротьби з помилкою, ми врешті спробували ще раз, але обмежили кількість цих сторінок, і, на щастя, це спрацювало! Тепер потрібно рішення, яке збереже ті ж сторінки, але дозволить деплоїти проєкт.

getStaticPaths дозволяє повернути параметр fallback, який може бути false, true або "blocking". Якщо ви повернете false, тоді всі шляхи, які не повернулись з цієї функції будуть повертати 404. А от якщо повернути "blocking", то Next.js спробує зарендерити цю сторінку при першому запиті, і у разі успіху, збереже її у кеші. Отож, тепер ми генеруємо невелику кількість сторінок, проте, як тільки хтось спробує відкрити сторінку, яка ще не згенерована, але дані для якої існують, Next.js одразу створить все необхідне.

#experience

Короткий відгук про Ghostty 👻

В цілому я задоволений і, швидше за все, буду використовувати його як основний (до цього я використовував WezTerm).

Він дійсно виглядає доволі шустрим, але що мені сподобалося ще більше — це те, що з ним зручно працювати і без жодних налаштувань. Все ж я дещо змінив і вклався в 9 рядків:

theme=catppuccin-mocha
font-family=Monaspace Krypton Var
font-variation=wght=300
window-padding-x=0
title=" "
macos-titlebar-proxy-icon=hidden
cursor-style-blink=false
shell-integration-features=no-cursor
keybind=cmd+t=unbind

#experience

Nix ⚙️

Минулого року ми відкрили для себе Nix. Спочатку було важко зрозуміти, що це таке, але воно виглядало досить незвично, тож ми вирішили дослідити, як це можна використати.

Nix — це інструмент для менеджменту пакетів і налаштувань. У нашому розумінні це ціла екосистема, адже тут є своя мова, застосунок та навіть операційна система. Якоюсь мірою це схоже на npm та package.json у JavaScript чи venv у Python.

Щодо NixOS — це операційна система на основі Linux, створена на базі менеджера пакетів Nix. Фактично вся система може бути налаштована та (головне!) відтворена за допомогою певного набору конфігураційних файлів.

Ми поки що тільки пробуємо його використовувати — наразі встановили лише на Raspberry Pi. У планах також налаштувати систему на macOS за допомогою nix-darwin. Має вийти доволі цікаво, адже тоді за допомогою кількох файлів можна буде відтворити всі налаштування на іншому комп'ютері.

Можливо, хтось із вас уже використовував Nix? Діліться своїм досвідом! 💛

👉 Відкрити посилання

#experience

WebP to PNG 🥴

У нашому проєкті виникла потреба генерувати PDF-файли. Для цього ми використовуємо бібліотеку react-pdf - інструмент для створення PDF. Працювати над таким типом завдань — це ще той квест, тому краще оминайте такі задачі.

Нам потрібно вставляти динамічні зображення (на даний момент підтримуємо лише JPG, PNG та WebP). Ми розчарувалися, коли виявилося, що PDF не підтримує формат WebP, а обробка таких зображень була надзвичайно необхідною.

Тому ми обрали, мабуть, найпростішу та найшвидшу стратегію — відмалювати WebP-зображення на canvas і отримати з нього PNG. Виглядає код приблизно так:

function toPNGUsingCavas(src: string) {
  const image = new Image()

  const { promise, resolve, reject } = Promise.withResolvers<string>()

  image.onload = function () {
    const canvas = document.createElement('canvas')
    canvas.width = image.naturalWidth
    canvas.height = image.naturalHeight

    const context = canvas.getContext('2d')
    if (!context) {
      reject(new Error('Could not get canvas context'))
    } else {
      context.drawImage(image, 0, 0)
      resolve(canvas.toDataURL('image/png'))
    }
  }

  image.onerror = reject

  image.src = src

  return promise
}

Тут, до речі, можете побачити приклад використання Promise.withResolvers, про який ми розповідали раніше.

#experience

"Неофіційні" правила в команді 👀

Ви напевно вже чули, що ми понад два роки працюємо над стартапом. За цей час наша команда значно виросла (спочатку працювали лише вдвох, а тепер нас уже 7 розробників із різних країн і часових зон). Разом із цим стало трохи складніше взаємодіяти у команді: кожен сфокусований на своїх тасках, вони часто переплітаються, виникають одні й ті ж питання, ті ж проблеми. А оскільки внутрішні процеси в нас майже не налаштовані, ми вирішили запровадити кілька "неофіційних" правил, які мають допомогти нам покращити взаємодію.

1. Обговорювати всі питання у спільному dev-чаті, а не в особистих повідомленнях.
Кожен член команди повинен мати доступ до обговорень, щоб за потреби допомогти або знайти потрібну інформацію. Вся важлива комунікація має бути відкритою та доступною для всіх. А ще це допоможе уникнути нескінченних однакових питань про логіку та архітектуру проєкту.

2. Ділити завдання на менші частини.
Оскільки це стартап, таски бувають дуже різними — від "підправити стилі таблички" до "розробити мобільний застосунок". Якщо завдання велике, намагаємось розбити його хоча б на backend і frontend або на окремі модулі. Адже якщо PR містить 100+ змінених файлів, його дуже складно перевірити — це займає купу часу, а якість рев’ю від цього тільки страждає.

3. Перевіряти PR-и колег.
Ми працюємо над великим проєктом, і важливо розуміти, що розробляють інші учасники команди. Якщо немає термінових завдань, намагаємось приділяти час рев’ю чужих PR. Це допоможе підтримувати якість коду, уникати конфліктів та краще розуміти загальний розвиток проєкту.

У нас немає бізнес-аналітика, ПМа, тестувальника і взагалі жодних "зайвих" людей. Так, звучить страшно, але це стартап, шо поробиш 😅 Сподіваємось, ці правила допоможуть нам трохи врятувати ситуацію.

Розкажіть, які "неофіційні" правила є у вас у команді? 💛

#experience

Aerospace Script 🪟

Window manager — це програма, яка керує вікнами ваших застосунків: їхнім розташуванням і розміром.

Серед таких програм (або схожих до них) можна виділити:
- Linux: i3, Hyprland;
- MacOS: Magnet, Rectangle, Yabai, Amethyst.

Зараз я тестую Aerospace. І в один момент я зрозумів, що мені дечого не вистачає.

#how_to втикати відосіки під час роботи, якщо у вас один монітор: двічі натискаєте праву клавішу на відео в YouTube та натискаєте Picture in Picture.

Проблема в тому, що через використання WM я розділяю вікна на різні воркспейси, а вікно Picture in Picture залишається тільки на одному з них. Оскільки fixed-режиму для вікон немає, єдиний варіант — змусити вікно автоматично переміщуватися під час зміни воркспейсу.

Ось як це зробив я:

exec-on-workspace-change = [
  '/bin/bash/', '-c',
  'aerospace move-node-to-workspace --window-id $(aerospace list-windows --monitor focused --app-bundle-id com.google.Chrome --format "%{window-id} %{window-title}" | awk "\$0 ~ /Picture in Picture/ {print \$1}") $AEROSPACE_FOCUSED_WORKSPACE'
]

#experience

Я тепер Vibe coder 💅

Нещодавно @Yurets7777 розповідав у чаті, що замовник хоче почути пояснення від тих, хто не використовує Cursor: як вони планують залишатися такими ж продуктивними, як ті, хто працює з ним?

ШІ настільки швидко розвивається, що важливо навчитися ефективно ним користуватися. Тож я вирішив спробувати й встановив Cursor, зараз тестую Free Trial.

Перше, що варто відзначити: Cursor побудований на базі VS Code. Тому, якщо ви працювали у VS Code, звикнути до нього буде легко. Передбачено імпорт налаштувань, хоча у мене виникли труднощі з перенесенням профілів. У VS Code я використовував різні конфігурації для різних проєктів, але перенести їх у Cursor не вдалося. Я спробував вручну відтворити налаштування, але зіткнувся з іншою проблемою: при відкритті не-default профілю всі параметри постійно скидалися. Загалом, останнім часом я працював у Neovim, тому перехід дався непросто.

Ще не до кінця розібрався з робочим процесом у Cursor. Тут є кілька режимів (chat, agent…), і підказки буквально вискакують на кожному кроці, навіть коли їх не просиш. Поки що ретельно перевіряю кожну зміну, яку він пропонує, і досить часто доводиться вказувати, що виправити. Також не до кінця зрозумів, як краще з ним працювати: давати одразу велику задачу й доопрацьовувати її частинами чи самому продумувати загальну схему, а потім просити імплементувати окремі шматки?

Загалом, враження поки змішані. Для мене ШІ — це інструмент, яким можна користуватися, але точно не той, що зробить усю роботу за мене. Водночас здається, що Cursor (разом із Windsurf, Trae та іншими) задає правильний напрямок. Vibe coder-ом я поки точно бути не хочу, але намагаюся знайти оптимальний спосіб інтеграції ШІ у свій робочий процес.

Подивимося, як ця технологія розвиватиметься далі.

А ви вже тестували щось подібне? Діліться враженнями! 💛

#experience

NixOS config 🔩

Раніше ми вже трохи розповідали, що таке Nix.

Мені було цікаво попрацювати з цим, і, нарешті, знайшлось трохи часу. Щоб не мучити Raspberry (бо на ньому зараз Pi-hole), я створив віртуалку і тестую все на ній.

Поки що тільки маленька перемога - воно хоча б працює. Прості налаштування вже наче освоїв, тому далі два важливих кроки:

1. Придумати, як нормально поставити .config/. Швидше за все, треба буде просто клонувати git-репозиторій, але потрібно ще розібратись.
2. Налаштувати GUI. Хочу спробувати i3 - чув про нього багато, але жодного разу не користувався.

Після цього думаю буде достатньо практики, щоб перенести це і на основний компʼютер. Загалом, поточний прогрес можна глянути тут. Багато натхнення і "позиченого" коду від Mitchell Hashimoto.

А якщо комусь цікаво або хтось уже мав справу з Nix - буду радий обговорити ⬇️

#experience

Як передати проєкт? 🎁

Ми завершуємо участь у поточному проєкті, однак його розробка триває, тож ми передали всі справи новій команді. Процес handover розбився на кілька етапів:

1. Завершення поточних задач.
На момент передачі у нас ще були активні таски та баги. Щоб не перекидати це на інших, ми доробили все, що могли — й лише після цього передали проєкт.

2. Передача доступів.
Тут усе просто: ми надали повні доступи до всіх сервісів і впевнились, що нові розробники змогли ними скористатися.

3. Коротка документація.
Чому коротка? Бо в нас її майже не було 🙂 Ми описали ключові речі: які фреймворки, бібліотеки та методи стилізації використовуються, як працюємо зі стейтом, формами, базою даних. Додали інформацію про інфраструктуру: де сервери, як білдиться проєкт, який сервіс відповідає за авторизацію тощо.
Окрему увагу приділили відомим багам, ризикам, технічному боргу, а також запропонували кілька ідей для покращення. Чесно кажучи, знаючи, у що це все виросте — ми б будували проєкт зовсім інакше 😅

4. Handover session.
На окремому дзвінку обговорили ключові частини проєкту та пояснили, на що звертати увагу. Зокрема, зараз у застосунку є waitlist, який частково потрібно обробляти вручну.
А ще це була просто тепла розмова з командою, яка підхоплює розробку. Ми раді завершити участь на хорошій ноті 💛

#experience