Setup backend project
Спочатку налаштуй себе на роботу 😉
Нещодавно Настя розповідала про те, як вона сетапить frontend проекти. Сьогодні я хочу відмітити чи повторити найважливіше з її посту та розповісти про речі, що я додаю при налаштуванні бекенд проекту.
Я пропущу такі кроки як вибір мови та фреймворку, тут кожен обирає своє.
- Налаштуйте лінтери та форматтери - це справді допоможе зберігати один вигляд коду.
- Додайте git hook та github actions (або pipelines від bitbucket чи gitlab). Нехай перевірка форматування файлів запускається перед комітом, тести перед пушем. І навіть якщо хтось обійде цей захист, на GitHub все одно буде ще одна перевірка.
- Пограйтесь з Docker. Можете обгорнути свій застосунок в docker. Зараз майже будь-яка платформа може працювати з контейнерами. Якщо не сильно хочеться, все ж я раджу хоча б використовувати вже готові docker image з сервісами, які ви використовуєте (наприклад, базою даних). Припустимо, що ваш застосунок використовує postgres та redis, треба встановлювати їх собі на компʼютер і постійно запускати. Якщо ж напишете всього один файлик docker-compose - зможете однією командою це все запускати і використовувати.
- Налаштуйте змінні середовища. Зберігайте секретні дані у файлику .env (або .env.{середовище}). Швидше за все бібліотека/фреймворк автоматично будуть зчитувати його, але якщо ні, впевнений, що з легкістю зможете знайти рішення.
- Якщо працюєте з базою даних - налаштуйте зʼєднання з нею і додайте ORM (читати пост). Навряд чи вам захочеться писати прямі SQL-запити, тому додати Prisma, Sequalize для JS чи SQLAlchemy для Python буде хорошою ідеєю.
Старався коротко і по суті описати основні кроки. Тому, якщо вас цікавить щось детальніше - давайте обговорювати ⬇️
#experience
❗️До кінця розіграшу залишилось 5 днів - доєднатись
Спочатку налаштуй себе на роботу 😉
Нещодавно Настя розповідала про те, як вона сетапить frontend проекти. Сьогодні я хочу відмітити чи повторити найважливіше з її посту та розповісти про речі, що я додаю при налаштуванні бекенд проекту.
Я пропущу такі кроки як вибір мови та фреймворку, тут кожен обирає своє.
- Налаштуйте лінтери та форматтери - це справді допоможе зберігати один вигляд коду.
- Додайте git hook та github actions (або pipelines від bitbucket чи gitlab). Нехай перевірка форматування файлів запускається перед комітом, тести перед пушем. І навіть якщо хтось обійде цей захист, на GitHub все одно буде ще одна перевірка.
- Пограйтесь з Docker. Можете обгорнути свій застосунок в docker. Зараз майже будь-яка платформа може працювати з контейнерами. Якщо не сильно хочеться, все ж я раджу хоча б використовувати вже готові docker image з сервісами, які ви використовуєте (наприклад, базою даних). Припустимо, що ваш застосунок використовує postgres та redis, треба встановлювати їх собі на компʼютер і постійно запускати. Якщо ж напишете всього один файлик docker-compose - зможете однією командою це все запускати і використовувати.
- Налаштуйте змінні середовища. Зберігайте секретні дані у файлику .env (або .env.{середовище}). Швидше за все бібліотека/фреймворк автоматично будуть зчитувати його, але якщо ні, впевнений, що з легкістю зможете знайти рішення.
- Якщо працюєте з базою даних - налаштуйте зʼєднання з нею і додайте ORM (читати пост). Навряд чи вам захочеться писати прямі SQL-запити, тому додати Prisma, Sequalize для JS чи SQLAlchemy для Python буде хорошою ідеєю.
Старався коротко і по суті описати основні кроки. Тому, якщо вас цікавить щось детальніше - давайте обговорювати ⬇️
#experience
❗️До кінця розіграшу залишилось 5 днів - доєднатись
👍14❤6🔥3👏2🤔1
Я став лідом за 3 місяці
Цей пост мав би писати Юра, адже це він став лідом за 3 місяці своєї роботи на проекті, та й в компанії в цілому. Але він занадто сором'язливий, тому це зроблю я! Адже я зайшла на цей проект місяць тому і вже помітила, що Юра робить інакше, і чому швидко стає незамінним на проекті.
Вникає у всі процеси
Юра відразу сує свого носа у всі процеси на проекті. Він прийшов як frontend розробник, а вже став fullstack. Цим самим, він швидко вникає в проект, його архітектуру і, якщо що, відразу може посапортити багатьох членів команди, або навіть замінити їх.
Постійно моніторить, як можна покращити процеси та розробку
Як тільки Юра зайшов на проект, я вже чула від нього пропозиції, що можна покращити в плануванні, що потрібно порефакторити в коді, що можна замінити або взагалі видалити. Він завжди аргументує свою думку, а не просто "бо я так сказав, я знаю краще". І він це робить абсолютно ненав'язливо! А так, як він постійно багато читає і дізнається все першим, то це дійсно гідні поради.
СЛУХАЄ
Юра дійсно вміє слухати і швидко розуміти, що від нього хочуть. Він постійно задає правильні питання, тим самим дає зрозуміти замовнику, що він зацікавлений в якісному результаті. АЛЕ, якщо це відверто якась фігня, він завжди про це скаже і, знову ж, аргументує, чому те чи інше не варто робити, або взагалі неможливо.
Налагоджує теплі відносини з замовником (а не зі мною😭)
Я була вражена, коли побачила, як Юра спілкується з замовником. Він не заходить на дзвінок і відразу в лоб, ось я зробив те і те, від тебе мені треба ті і ті вимоги. Ні. Юра розпитає, як у нього справи, як його подорожі по бізнесу, трішки розповість про себе, про ситуацію в країні (а про це важливо говорити!) і тд. А потім вже на такій ноті говорить про проект і що потрібно зробити.
Сподіваюсь цей пост був корисним для вас і ви щось зможете винести для себе 💛
А ще можете привітати Юру з таким швидким підвищенням 🥳
#experience
Цей пост мав би писати Юра, адже це він став лідом за 3 місяці своєї роботи на проекті, та й в компанії в цілому. Але він занадто сором'язливий, тому це зроблю я! Адже я зайшла на цей проект місяць тому і вже помітила, що Юра робить інакше, і чому швидко стає незамінним на проекті.
Вникає у всі процеси
Юра відразу сує свого носа у всі процеси на проекті. Він прийшов як frontend розробник, а вже став fullstack. Цим самим, він швидко вникає в проект, його архітектуру і, якщо що, відразу може посапортити багатьох членів команди, або навіть замінити їх.
Постійно моніторить, як можна покращити процеси та розробку
Як тільки Юра зайшов на проект, я вже чула від нього пропозиції, що можна покращити в плануванні, що потрібно порефакторити в коді, що можна замінити або взагалі видалити. Він завжди аргументує свою думку, а не просто "бо я так сказав, я знаю краще". І він це робить абсолютно ненав'язливо! А так, як він постійно багато читає і дізнається все першим, то це дійсно гідні поради.
СЛУХАЄ
Юра дійсно вміє слухати і швидко розуміти, що від нього хочуть. Він постійно задає правильні питання, тим самим дає зрозуміти замовнику, що він зацікавлений в якісному результаті. АЛЕ, якщо це відверто якась фігня, він завжди про це скаже і, знову ж, аргументує, чому те чи інше не варто робити, або взагалі неможливо.
Налагоджує теплі відносини з замовником (а не зі мною😭)
Я була вражена, коли побачила, як Юра спілкується з замовником. Він не заходить на дзвінок і відразу в лоб, ось я зробив те і те, від тебе мені треба ті і ті вимоги. Ні. Юра розпитає, як у нього справи, як його подорожі по бізнесу, трішки розповість про себе, про ситуацію в країні (а про це важливо говорити!) і тд. А потім вже на такій ноті говорить про проект і що потрібно зробити.
Сподіваюсь цей пост був корисним для вас і ви щось зможете винести для себе 💛
А ще можете привітати Юру з таким швидким підвищенням 🥳
#experience
🔥59👍24❤9🎉8🥰2👏1👌1
Package Manager 📦
Якщо ви працюєте з Javascript або Node.js то, ймовірно, знаєте про npm. А які є альтернативи npm та які в них переваги/недоліки?
npm (Node Package Manager) - це менеджер пакетів за замовчуванням для Node.js, який ви отримуєте з інсталяцією Node.js. За допомогою цього інструменту ви можете встановлювати пакети, а також керувати ними та публікувати їх в npm-реєстр. В npm дуже широка спільнота, що теж дуже важливо. Також npm має кешування, що пришвидшує встановлення пакетів. А у файлі package-lock.json він зберігає інформацію, необхідну для правильної інсталяції та роботи пакетів.
yarn - це менеджер пакетів, створений Facebook і випущений у 2016 році. Yarn було створено для вирішення деяких проблем та обмежень npm, наприклад, повільне встановлення пакетів. Для цього yarn інсталює їх паралельно. Замість package-lock.json було введено yarn.lock. Ще yarn надає функціонал workspaces, за допомогою якого можна керувати кількома проектами одночасно, якщо у вас, наприклад, monorepo. А щоб зекономити трохи памʼяті, yarn використовує плоске дерево залежностей, завдяки чому уникає дублювання пакетів.
pnpm (скорочення від "performant npm") - менеджер пакетів, випущений у 2016 році. Як і в yarn, його мета усунути деякі обмеження npm, зокрема щодо швидкості встановлення та використання дискового простору. pnpm використовує унікальний підхід до керування залежностями, який може призвести до значного покращення продуктивності та економії памʼяті. Для цього він використовує спільне сховище в якому тримає пакети, і вони, відповідно не дублюються у кожному вашому проекті. Такий підхід дозволяє навіть встановлювати пакети без зʼєднання з мережею Інтернет.
Який з них використовувати?
Всі вони добре виконують свою роботу, тому можете вибирати будь-який і не прогадаєте. Від себе додам, що більшість попередніх проектів, на яких я працював, використовували yarn. Але зараз для мене найпривабливішою опцією виглядає pnpm і для наступного проекту я хочу спробувати використати саме його.
#experience
Якщо ви працюєте з Javascript або Node.js то, ймовірно, знаєте про npm. А які є альтернативи npm та які в них переваги/недоліки?
npm (Node Package Manager) - це менеджер пакетів за замовчуванням для Node.js, який ви отримуєте з інсталяцією Node.js. За допомогою цього інструменту ви можете встановлювати пакети, а також керувати ними та публікувати їх в npm-реєстр. В npm дуже широка спільнота, що теж дуже важливо. Також npm має кешування, що пришвидшує встановлення пакетів. А у файлі package-lock.json він зберігає інформацію, необхідну для правильної інсталяції та роботи пакетів.
yarn - це менеджер пакетів, створений Facebook і випущений у 2016 році. Yarn було створено для вирішення деяких проблем та обмежень npm, наприклад, повільне встановлення пакетів. Для цього yarn інсталює їх паралельно. Замість package-lock.json було введено yarn.lock. Ще yarn надає функціонал workspaces, за допомогою якого можна керувати кількома проектами одночасно, якщо у вас, наприклад, monorepo. А щоб зекономити трохи памʼяті, yarn використовує плоске дерево залежностей, завдяки чому уникає дублювання пакетів.
pnpm (скорочення від "performant npm") - менеджер пакетів, випущений у 2016 році. Як і в yarn, його мета усунути деякі обмеження npm, зокрема щодо швидкості встановлення та використання дискового простору. pnpm використовує унікальний підхід до керування залежностями, який може призвести до значного покращення продуктивності та економії памʼяті. Для цього він використовує спільне сховище в якому тримає пакети, і вони, відповідно не дублюються у кожному вашому проекті. Такий підхід дозволяє навіть встановлювати пакети без зʼєднання з мережею Інтернет.
Який з них використовувати?
Всі вони добре виконують свою роботу, тому можете вибирати будь-який і не прогадаєте. Від себе додам, що більшість попередніх проектів, на яких я працював, використовували yarn. Але зараз для мене найпривабливішою опцією виглядає pnpm і для наступного проекту я хочу спробувати використати саме його.
#experience
👍22🔥3🤔3❤2
Як швидко перейти з однієї технології на іншу? 🤯
Передісторія: на початку травня замовник вирішив, що нам терміново потрібен мобільний застосунок. Разом з командою ми обрали Flutter. Найцікавіше те, що він вирішив, що його повинні писати я та Юра, хоча я ніколи не писала на мобілку, і про це йому неодноразово говорила. Тому я повинна була швидко в ньому розібратись та почати допомагати Юрі в розробці. Проблема ще була в тому, що Flutter використовує мову програмування Dart, тобто я повинна була спочатку вивчити нову мову, а потім вже новий фреймворк.
В мене було зовсім мало часу і ось їм план дій:
1. Знайти статті, які допоможуть розібратись з новою технологією на базі тих, які ти вже знаєш. В моєму випадку, я почала читати статті, в яких пояснюється в чому схожість та відмінність JavaScript і Dart, Web-розробка і Flutter-розробка тощо. Ці статті швидко допомогли мені збагнути, які моменти я знаю зі свого досвіду, а які принципи для мене зовсім нові, і я повинна звернути на них увагу.
2. Почати писати невеличкий застосунок по гайду. Я думаю, вже всі давно зрозуміли, що нові знання по програмуванню потрібно відразу практикувати, бо толку буде мало. Так і в моєму випадку, я найшла в документації покрокову інструкцію розробки маленького застосунку, в якому, в принципі, були всі базові моменти, які я мала дізнатись про Flutter. Звичайно, перші кроки я повністю копіювала і вже потім розбиралась, що вони роблять. Далі поступово пробувала не дивитись на реалізацію, а писати невеличкі шматки коду самостійно.
3. Брати таски. Після того я відразу почала працювати над функціоналом, який не є початковим у нашому застосунку, тому я мала час повільно, але впевнено його робити. Було складно, вилазило багато моментів, про які я взагалі не здогадувалась, кожен новий елемент я гуглила, 100500 раз розказувала, що більше ніколи не проміняю JavaScript, але не дивлячись на це, завдяки практиці, я швидко вчилась.
Вкінці я отримала крутий досвід та результат - Mobile UI is absolutely epic! I can't believe you've only been working with Flutter for a few weeks. Both you and Yurii are incredibly talented. We always appreciate your help!!
#experience
Передісторія: на початку травня замовник вирішив, що нам терміново потрібен мобільний застосунок. Разом з командою ми обрали Flutter. Найцікавіше те, що він вирішив, що його повинні писати я та Юра, хоча я ніколи не писала на мобілку, і про це йому неодноразово говорила. Тому я повинна була швидко в ньому розібратись та почати допомагати Юрі в розробці. Проблема ще була в тому, що Flutter використовує мову програмування Dart, тобто я повинна була спочатку вивчити нову мову, а потім вже новий фреймворк.
В мене було зовсім мало часу і ось їм план дій:
1. Знайти статті, які допоможуть розібратись з новою технологією на базі тих, які ти вже знаєш. В моєму випадку, я почала читати статті, в яких пояснюється в чому схожість та відмінність JavaScript і Dart, Web-розробка і Flutter-розробка тощо. Ці статті швидко допомогли мені збагнути, які моменти я знаю зі свого досвіду, а які принципи для мене зовсім нові, і я повинна звернути на них увагу.
2. Почати писати невеличкий застосунок по гайду. Я думаю, вже всі давно зрозуміли, що нові знання по програмуванню потрібно відразу практикувати, бо толку буде мало. Так і в моєму випадку, я найшла в документації покрокову інструкцію розробки маленького застосунку, в якому, в принципі, були всі базові моменти, які я мала дізнатись про Flutter. Звичайно, перші кроки я повністю копіювала і вже потім розбиралась, що вони роблять. Далі поступово пробувала не дивитись на реалізацію, а писати невеличкі шматки коду самостійно.
3. Брати таски. Після того я відразу почала працювати над функціоналом, який не є початковим у нашому застосунку, тому я мала час повільно, але впевнено його робити. Було складно, вилазило багато моментів, про які я взагалі не здогадувалась, кожен новий елемент я гуглила, 100500 раз розказувала, що більше ніколи не проміняю JavaScript, але не дивлячись на це, завдяки практиці, я швидко вчилась.
Вкінці я отримала крутий досвід та результат - Mobile UI is absolutely epic! I can't believe you've only been working with Flutter for a few weeks. Both you and Yurii are incredibly talented. We always appreciate your help!!
#experience
👍28🔥9❤7😱2👏1
Частина 1. Наша перша технічна співбесіда.
… в якості інтерв’юерів 🫣
Так, ми раніше мали невеликий досвід у проведенні співбесід, але цього разу ми були повністю відповідальні за неї, повинні були провести її з початку та до кінця, самі продумати хід діалогу та питання.
На нашому проекті був потрібен розробник. Як ми раніше розповідали, зараз ми сфокусовані на розробці мобільного застосунку, тому потрібна була людина, яка підтримувала б веб. Нам підібрали кандидатів і від нас вимагалось тільки обрати найкращого.
Якщо чесно, спочатку ми думали, що це буде дуже легко, це ж не нас співбесідують, а ми. АЛЕ коли ми сіли скласти питання або хоча б якийсь хід розмови, ми розгубились. Що питати? Навіщо таке питати? А може це взагалі не потрібно дізнаватись?
І тоді ми почали згадувати наші співбесіди як кандидатів. Їх була достатня кількість, але лише від однієї у нас були дійсно тільки приємні спогади. Це була співбесіда на нашу попередню компанію і проводив її наш колишній (хах) тім лід. Він не питав по списку примітивні питання з першого сайту "що питати розробника". Це була розмова двох досвідчених програмістів. Він розповідав про себе, що він використовував, по ходу питав про наше відношення до тієї чи іншої методики. Він хотів почути не завчений матеріал, а саме нашу думку, що нам подобається і що ми б не хотіли використовувати в роботі. Питав про наш досвід, технології, наше відношення до цих технологій, чому ми обрали саме їх. Звісно були питання про патерни, алгоритми і тд, але ж знову, це була не теорія, а саме чи мали ми з ними досвід, і що реалізовували завдяки ним.
Після закінчення такої співбесіди, ти не виходиш як вижатий лимон, ти виходиш з новими поглядами на старі речі, та тільки з приємними емоціями і відчуттям якісно проведеного часу.
І нам максимально хотілось провести саме таку співбесіду, а не суху і чисто технічну.
Дуже багато тексту і не хочеться вас перевантажувати, тому далі буде…
#experience #interview
… в якості інтерв’юерів 🫣
Так, ми раніше мали невеликий досвід у проведенні співбесід, але цього разу ми були повністю відповідальні за неї, повинні були провести її з початку та до кінця, самі продумати хід діалогу та питання.
На нашому проекті був потрібен розробник. Як ми раніше розповідали, зараз ми сфокусовані на розробці мобільного застосунку, тому потрібна була людина, яка підтримувала б веб. Нам підібрали кандидатів і від нас вимагалось тільки обрати найкращого.
Якщо чесно, спочатку ми думали, що це буде дуже легко, це ж не нас співбесідують, а ми. АЛЕ коли ми сіли скласти питання або хоча б якийсь хід розмови, ми розгубились. Що питати? Навіщо таке питати? А може це взагалі не потрібно дізнаватись?
І тоді ми почали згадувати наші співбесіди як кандидатів. Їх була достатня кількість, але лише від однієї у нас були дійсно тільки приємні спогади. Це була співбесіда на нашу попередню компанію і проводив її наш колишній (хах) тім лід. Він не питав по списку примітивні питання з першого сайту "що питати розробника". Це була розмова двох досвідчених програмістів. Він розповідав про себе, що він використовував, по ходу питав про наше відношення до тієї чи іншої методики. Він хотів почути не завчений матеріал, а саме нашу думку, що нам подобається і що ми б не хотіли використовувати в роботі. Питав про наш досвід, технології, наше відношення до цих технологій, чому ми обрали саме їх. Звісно були питання про патерни, алгоритми і тд, але ж знову, це була не теорія, а саме чи мали ми з ними досвід, і що реалізовували завдяки ним.
Після закінчення такої співбесіди, ти не виходиш як вижатий лимон, ти виходиш з новими поглядами на старі речі, та тільки з приємними емоціями і відчуттям якісно проведеного часу.
І нам максимально хотілось провести саме таку співбесіду, а не суху і чисто технічну.
Дуже багато тексту і не хочеться вас перевантажувати, тому далі буде…
#experience #interview
👍43❤11❤🔥2
Частина 2. Наша перша технічна співбесіда.
👉 Читати частину 1
Ми вирішили, що складемо план розмови, але він буде з загальними питаннями про досвід, вподобання і прагнення на майбутнє.
Так як ми шукали full stack розробника, ми отримали такий план:
1. Знайомство. Спочатку ми розповіли хто ми є, трішки жартували (сподіваюсь, смішно), щоб кандидат відчував себе комфортніше. Потім розпитували кандидата про нього. Ось приклад питань (це далеко не всі). Так, але давайте за англійську не сваріться, тому що це все писалось на колінці 😅:
- What recent task was a challenge for you?
- Which tech stack do you prefer?
- Do you have some technologies you want to try?
2. Web.
- What state-management tools have you used (Redux, MobX)? Pros and cons.
- What third-party libraries/API’s have you used?
- How do you optimise your React code?
3. Backend.
- What frameworks/libraries have you used for your services?
- Have you used ORMs? Could you list them? Pros and cons.
- Where did you deploy your services? Did you use some CI/CD tools?
4. Питання від кандидата. Це дуже важливо поцікавитись чи в нього залишились питання і максимально чітко на них відповісти.
Так, в питаннях було багато "have you used", адже ми хотіли почути саме досвід, що вони вміють робити, з чим вони стикались на попередніх проектах, їх вподобання та те, з чим вони більше не хотіли б працювати. Завдяки таким питанням, співбесіда розвивалась у форматі розмови, а не "питання-відповідь".
Ви можете сказати, що цього дуже мало та не достатньо, щоб дізнатись, який рівень у даного розробника, тому уточнимо, що перед співбесідою кандидати виконували завдання і те, що писати код вони вміють, ми знали 🙂. Плюс, вони виконували таски в нашому комерційному проекті (відразу кажемо, що їм за це непогано заплатили, тому їх ніхто не використав) і ми могли ще поцікавитись як їм код, архітектура, що сподобалось, що ні, які виникли питання. Це також нам допомогло краще зрозуміти кандидата та його вподобання.
І питання звучали на англійській, тому що компанія американська і ми спілкуємось англійською. Один з кандидатів був з Казахстану і він знав росій**ку, але ми відразу порозумілись, що дану мову ми використовувати не будемо! Ну і вам не радимо 😉
Сподіваємось, вам цей пост був корисний, адже коли ми готувались, то не змогли знайти актуальних статей про те, як краще проводити співбесіду.
І, до речі, ми отримали хороші відгуки від кандидатів:
- It was a fun meeting. Thank you for your time today!
- Thank you for taking the time to have a meeting today. I could understand the current application and the roadmaps. I also really enjoyed speaking with you.
#experience #interview
👉 Читати частину 1
Ми вирішили, що складемо план розмови, але він буде з загальними питаннями про досвід, вподобання і прагнення на майбутнє.
Так як ми шукали full stack розробника, ми отримали такий план:
1. Знайомство. Спочатку ми розповіли хто ми є, трішки жартували (сподіваюсь, смішно), щоб кандидат відчував себе комфортніше. Потім розпитували кандидата про нього. Ось приклад питань (це далеко не всі). Так, але давайте за англійську не сваріться, тому що це все писалось на колінці 😅:
- What recent task was a challenge for you?
- Which tech stack do you prefer?
- Do you have some technologies you want to try?
2. Web.
- What state-management tools have you used (Redux, MobX)? Pros and cons.
- What third-party libraries/API’s have you used?
- How do you optimise your React code?
3. Backend.
- What frameworks/libraries have you used for your services?
- Have you used ORMs? Could you list them? Pros and cons.
- Where did you deploy your services? Did you use some CI/CD tools?
4. Питання від кандидата. Це дуже важливо поцікавитись чи в нього залишились питання і максимально чітко на них відповісти.
Так, в питаннях було багато "have you used", адже ми хотіли почути саме досвід, що вони вміють робити, з чим вони стикались на попередніх проектах, їх вподобання та те, з чим вони більше не хотіли б працювати. Завдяки таким питанням, співбесіда розвивалась у форматі розмови, а не "питання-відповідь".
Ви можете сказати, що цього дуже мало та не достатньо, щоб дізнатись, який рівень у даного розробника, тому уточнимо, що перед співбесідою кандидати виконували завдання і те, що писати код вони вміють, ми знали 🙂. Плюс, вони виконували таски в нашому комерційному проекті (відразу кажемо, що їм за це непогано заплатили, тому їх ніхто не використав) і ми могли ще поцікавитись як їм код, архітектура, що сподобалось, що ні, які виникли питання. Це також нам допомогло краще зрозуміти кандидата та його вподобання.
І питання звучали на англійській, тому що компанія американська і ми спілкуємось англійською. Один з кандидатів був з Казахстану і він знав росій**ку, але ми відразу порозумілись, що дану мову ми використовувати не будемо! Ну і вам не радимо 😉
Сподіваємось, вам цей пост був корисний, адже коли ми готувались, то не змогли знайти актуальних статей про те, як краще проводити співбесіду.
І, до речі, ми отримали хороші відгуки від кандидатів:
- It was a fun meeting. Thank you for your time today!
- Thank you for taking the time to have a meeting today. I could understand the current application and the roadmaps. I also really enjoyed speaking with you.
#experience #interview
👍32❤7🔥3
Давайте поговоримо про гроші.
За наш шлях в ІТ ми встигли попрацювати з різними формами оплати. Тому, сьогодні ми хочемо розібратися з плюсами та мінусами кожної з них і з'ясувати, в яких випадках краще обирати той чи інший варіант.
Фіксована ставка.
Фіксована ставка – це оплата за фіксовану кількість робочого часу (наприклад, місяць) незалежно від того, скільки роботи потрібно виконати. Чудово підійде, якщо ви працюєте в компанії. Маєте один чи кілька проектів, відпрацювали місяць, отримали зарплату. Всім все підходить.
АЛЕ, якщо ви працюєте за такою формою оплати, обов’язково потрібно обговорити те, як оплачується понаднормовий робочий час, і чи він взагалі можливий. Якщо цей час додатково не оплачується, то в мене є питання до компанії.
Погодинна оплата.
При такій формі працівник отримує фіксовану оплату за кожну годину роботи. Чудово підійде для part-time роботи. У свій вільний від основної роботи час, програміст виконує таски, записує витрачені години та отримує зарплату за формулою
Не рекомендуємо таку форму оплати, якщо це ваша основна робота. Ми мали такий досвід, коли працювали з трекером. Все, що можемо сказати - ніякої стабільності, багато нервів та різний розмір зарплати кожного місяця.
Оплата за виконаний проект.
Дуже вигідно замовнику, але не програмісту. Це тому, що незалежно від того, наскільки б детально ви не прораховували обсяг роботи та бюджет, завжди з'являються правки та підводні камені, про які ви не підозрювали, і в більшості випадків доведеться працювати за свій кошт.
Мали досвід, працювали над проектом пару місяців, отримали навіть не свою місячну зарплату. Тому, якщо вам пропонують зробити проект під ключ, який займе більше, ніж місяць часу, пробуйте домовлятись за погодинну оплату.
Сподіваємось, пост був корисним, хоча й дуже суб'єктивним! Чекаємо історії про ваш досвід і рекомендації про найкращу форму оплати 💛
#experience
За наш шлях в ІТ ми встигли попрацювати з різними формами оплати. Тому, сьогодні ми хочемо розібратися з плюсами та мінусами кожної з них і з'ясувати, в яких випадках краще обирати той чи інший варіант.
Фіксована ставка.
Фіксована ставка – це оплата за фіксовану кількість робочого часу (наприклад, місяць) незалежно від того, скільки роботи потрібно виконати. Чудово підійде, якщо ви працюєте в компанії. Маєте один чи кілька проектів, відпрацювали місяць, отримали зарплату. Всім все підходить.
АЛЕ, якщо ви працюєте за такою формою оплати, обов’язково потрібно обговорити те, як оплачується понаднормовий робочий час, і чи він взагалі можливий. Якщо цей час додатково не оплачується, то в мене є питання до компанії.
Погодинна оплата.
При такій формі працівник отримує фіксовану оплату за кожну годину роботи. Чудово підійде для part-time роботи. У свій вільний від основної роботи час, програміст виконує таски, записує витрачені години та отримує зарплату за формулою
кількість годин * рейт.Не рекомендуємо таку форму оплати, якщо це ваша основна робота. Ми мали такий досвід, коли працювали з трекером. Все, що можемо сказати - ніякої стабільності, багато нервів та різний розмір зарплати кожного місяця.
Оплата за виконаний проект.
Дуже вигідно замовнику, але не програмісту. Це тому, що незалежно від того, наскільки б детально ви не прораховували обсяг роботи та бюджет, завжди з'являються правки та підводні камені, про які ви не підозрювали, і в більшості випадків доведеться працювати за свій кошт.
Мали досвід, працювали над проектом пару місяців, отримали навіть не свою місячну зарплату. Тому, якщо вам пропонують зробити проект під ключ, який займе більше, ніж місяць часу, пробуйте домовлятись за погодинну оплату.
Сподіваємось, пост був корисним, хоча й дуже суб'єктивним! Чекаємо історії про ваш досвід і рекомендації про найкращу форму оплати 💛
#experience
👍49❤4🔥3👎1😢1
vim 🤓
Останнім часом я вирішив спробувати vim. І сьогодні я хочу коротко поділитись про перший досвід та враження.
Насправді, це сталось з другої спроби, бо перший раз я обрав трохи не той підхід. Я подумав, що просто залечу в нього і все почне само собою виходити. А виявилось, що це зовсім нелегко.
Одне з найскладніших місць у vim - це саме почати ним користуватись, адже це зовсім нове середовище. Одразу після того як ви зрозумієте основні вертикальні і горизонтальні рухи, режими роботи та команди, ви будете ставати все більш продуктивнішими.
У vim справді закладено певний сенс. Ви зможете будувати свої команди на ходу, оперуючи вже тим, що вивчили. Ось короткий приклад: delete word - dw, delete inside () - di(.
Поки я пробую комбінувати VSCode з розширенням vim та Neovim редактори. Ще не вирішив чи буду змінювати редактор коду, але думаю, що все таки vim залишу у будь-якому випадку (хоча б як розширення).
Тому, якщо вам зручно працювати з фокусом на клавіатурі, раджу хоча б спробувати.
Якщо ви зацікавились, поділюсь кількома ресурсами:
- Youtube плейлист від ThePrimeagen
- Learn Vim for the last time
- Vim Adventures
#experience
Останнім часом я вирішив спробувати vim. І сьогодні я хочу коротко поділитись про перший досвід та враження.
Насправді, це сталось з другої спроби, бо перший раз я обрав трохи не той підхід. Я подумав, що просто залечу в нього і все почне само собою виходити. А виявилось, що це зовсім нелегко.
Одне з найскладніших місць у vim - це саме почати ним користуватись, адже це зовсім нове середовище. Одразу після того як ви зрозумієте основні вертикальні і горизонтальні рухи, режими роботи та команди, ви будете ставати все більш продуктивнішими.
У vim справді закладено певний сенс. Ви зможете будувати свої команди на ходу, оперуючи вже тим, що вивчили. Ось короткий приклад: delete word - dw, delete inside () - di(.
Поки я пробую комбінувати VSCode з розширенням vim та Neovim редактори. Ще не вирішив чи буду змінювати редактор коду, але думаю, що все таки vim залишу у будь-якому випадку (хоча б як розширення).
Тому, якщо вам зручно працювати з фокусом на клавіатурі, раджу хоча б спробувати.
Якщо ви зацікавились, поділюсь кількома ресурсами:
- Youtube плейлист від ThePrimeagen
- Learn Vim for the last time
- Vim Adventures
#experience
👍14🤓6❤4😨1
Як знайти свою першу роботу в ІТ, частина 1.
Резюме 📄
Ми поставили собі запитання - як би ми зараз шукали свою першу роботу в ІТ взагалі без досвіду. І в нас вийшла невеличка підбірка порад, якою б ми хотіли поділитись. Все, що тут написано, чисто суб'єктивні ідеї з нашого досвіду або досвіду наших знайомих/друзів, які також працюють в ІТ.
Перше, з чого потрібно почати, це звичайно гарне, структуроване та інформативне резюме. Зараз є дуже багато статей, як правильно підготувати cv, наприклад, читайте пост. Тому, зараз хочемо виділити тільки ті речі, які для нас важливі в створенні резюме:
- Структурованість. Повинні бути чіткі секції/блоки, де описані конкретні дані про вашу освіту, досвід, проєкти тощо. Це дасть змогу роботодавцю/рекрутеру легко знаходити потрібну інформацію про вас.
- Стислість. Резюме не повинно бути на 20 сторінок, ніхто його читати не буде. В ідеалі все повинно поміститись на 1-2 сторінки, тим більше "в нас немає досвіду", а занадто багато розписувати про свої всі пет-проєкти і дипломи "Кенгуру" не варто.
- Дизайн. Його просто не має бути. Я пам'ятаю своє перше резюме: чорний фон, яскраво жовті вставки, білий текст, інформація розкидана як-небудь. Мені казали, що це крінж, а я - зате красіво! Ні, ні і ще раз ні. Резюме - це документ, не потрібно там нічого придумувати. Білий фон, чорний текст, чітка структура. Я чула, що деякі рекрутери радять навіть фото не ставити, напевно, вони програмістів не по красоті набирають 🙂
- Формат. Зберігайте своє резюме в двох форматах - doc i pdf. Doc - для себе, щоб швидко поправити/оновити інформацію. Pdf - для роботодавця, щоб в нього точно нічого не поплило/не переформатувалось. Також не забудьте чітко підписати файл, наприклад, CV_Junior_React_ Developer_Anastasiia_Tarasenko.
Тепер нам цікаво почути вашу думку, яке ж має бути те резюме 💛
#experience
Резюме 📄
Ми поставили собі запитання - як би ми зараз шукали свою першу роботу в ІТ взагалі без досвіду. І в нас вийшла невеличка підбірка порад, якою б ми хотіли поділитись. Все, що тут написано, чисто суб'єктивні ідеї з нашого досвіду або досвіду наших знайомих/друзів, які також працюють в ІТ.
Перше, з чого потрібно почати, це звичайно гарне, структуроване та інформативне резюме. Зараз є дуже багато статей, як правильно підготувати cv, наприклад, читайте пост. Тому, зараз хочемо виділити тільки ті речі, які для нас важливі в створенні резюме:
- Структурованість. Повинні бути чіткі секції/блоки, де описані конкретні дані про вашу освіту, досвід, проєкти тощо. Це дасть змогу роботодавцю/рекрутеру легко знаходити потрібну інформацію про вас.
- Стислість. Резюме не повинно бути на 20 сторінок, ніхто його читати не буде. В ідеалі все повинно поміститись на 1-2 сторінки, тим більше "в нас немає досвіду", а занадто багато розписувати про свої всі пет-проєкти і дипломи "Кенгуру" не варто.
- Дизайн. Його просто не має бути. Я пам'ятаю своє перше резюме: чорний фон, яскраво жовті вставки, білий текст, інформація розкидана як-небудь. Мені казали, що це крінж, а я - зате красіво! Ні, ні і ще раз ні. Резюме - це документ, не потрібно там нічого придумувати. Білий фон, чорний текст, чітка структура. Я чула, що деякі рекрутери радять навіть фото не ставити, напевно, вони програмістів не по красоті набирають 🙂
- Формат. Зберігайте своє резюме в двох форматах - doc i pdf. Doc - для себе, щоб швидко поправити/оновити інформацію. Pdf - для роботодавця, щоб в нього точно нічого не поплило/не переформатувалось. Також не забудьте чітко підписати файл, наприклад, CV_Junior_React_ Developer_Anastasiia_Tarasenko.
Тепер нам цікаво почути вашу думку, яке ж має бути те резюме 💛
#experience
👍24❤9🔥1
Як знайти свою першу роботу в ІТ, частина 2.
Пошук роботи 🔍
👉 Читати частину 1
Написали файне резюме, тепер можемо приступати безпосередньо до пошуку роботи. Наголосимо знову, що в даному списку тільки ті сервіси, які ми особисто використовували. Насправді, їх існує набагато більше.
Ну що ж, почнемо. А по всім канонам ІТ, перше, на що потрібно звернути увагу, це:
- LinkedIn. Дану соціальну мережу не можна на 100% назвати сервісом для пошуку роботи, це більше ваше портфоліо. І воно у вас має бути обов’язково! Саме тут ви можете написати максимально багато інформації про себе. Заповнюйте skills та проходьте тести, щоб їх підтвердити (вони взагалі не є складними + відповіді давним-давно злиті 🤫). Долучайтесь до знайомих і незнайомих, особливо до рекрутерів. Багато з них можуть пропонувати різні вакансії через LinkedIn. Також можете опублікувати своє CV з текстом, що ви шукаєте роботу. Можливо, воно розлетиться і хтось вас помітить.
- Djinni - суб’єктивно найкраща платформа для пошуку роботи. Детально та якісно заповнюйте свій профіль і постійно перевіряйте вакансії, які для вас релевантні. І ще така «порада» - подавайтесь навіть на ті вакансії, де є технології, які ви не дуже знаєте. Я не кажу подаватись на Angular, якщо ви знаєте React. Я кажу подавайтесь на ті вакансії, де в переліку є, наприклад, Tailwind, а ви його ще не знаєте, але ви розумієте, що походу зможете його швидко вивчити. Якщо б ми в свій час подавались лише на ті ваканасії, де ми знаємо 100% з переліку вимог, ми б сиділи без роботи.
- Dou - чесно, ми не шукали роботу через цю платформу, але чули, що це також дуже хороший сервіс. Ми там більше дивимось відгуки про компанії. Я в свій час була підписана на їх телеграм-канал, де вони діляться вакансіями, інтернатурами, стажуваннями для людей зовсім без досвіду. Ви зможете його знайти на сайті. І ще одна «порада» - не цурайтесь безкоштовної інтернатури чи стажування (якщо звичайно це не комерційний проект) - це хороший шанс потрапити в компанію. Майже всі наші друзі (в тому числі і ми) потрапили в свою першу компанію через стажування або інтернатуру. Плюс, це досвід, який ви зможете вписати собі в резюме.
- Сайти компаній. Шукайте та моніторте сайти різних компаній, а особливо розділ кар’єра. Там є список вакансій і, можливо, ви знайдете собі підходящу. Навіть, якщо такої немає, можете всеодно надіслати своє резюме, раптом воно їх зацікавить.
- Сарафанне радіо - це дуже недооцінений спосіб пошуку роботи і дуже даремно. Тому не стидайтесь і говоріть всім, що шукаєте роботу, особливо тим знайомим, які дотичні до ІТ. Зараз важка ситуація на ринку і буде дуже круто, якщо ваш знайомий зможе замовити словечко за вас у своїй компанії.
Напишіть про ваші способи пошуку роботи, нам цікаво 💛
#experience
Пошук роботи 🔍
👉 Читати частину 1
Написали файне резюме, тепер можемо приступати безпосередньо до пошуку роботи. Наголосимо знову, що в даному списку тільки ті сервіси, які ми особисто використовували. Насправді, їх існує набагато більше.
Ну що ж, почнемо. А по всім канонам ІТ, перше, на що потрібно звернути увагу, це:
- LinkedIn. Дану соціальну мережу не можна на 100% назвати сервісом для пошуку роботи, це більше ваше портфоліо. І воно у вас має бути обов’язково! Саме тут ви можете написати максимально багато інформації про себе. Заповнюйте skills та проходьте тести, щоб їх підтвердити (вони взагалі не є складними + відповіді давним-давно злиті 🤫). Долучайтесь до знайомих і незнайомих, особливо до рекрутерів. Багато з них можуть пропонувати різні вакансії через LinkedIn. Також можете опублікувати своє CV з текстом, що ви шукаєте роботу. Можливо, воно розлетиться і хтось вас помітить.
- Djinni - суб’єктивно найкраща платформа для пошуку роботи. Детально та якісно заповнюйте свій профіль і постійно перевіряйте вакансії, які для вас релевантні. І ще така «порада» - подавайтесь навіть на ті вакансії, де є технології, які ви не дуже знаєте. Я не кажу подаватись на Angular, якщо ви знаєте React. Я кажу подавайтесь на ті вакансії, де в переліку є, наприклад, Tailwind, а ви його ще не знаєте, але ви розумієте, що походу зможете його швидко вивчити. Якщо б ми в свій час подавались лише на ті ваканасії, де ми знаємо 100% з переліку вимог, ми б сиділи без роботи.
- Dou - чесно, ми не шукали роботу через цю платформу, але чули, що це також дуже хороший сервіс. Ми там більше дивимось відгуки про компанії. Я в свій час була підписана на їх телеграм-канал, де вони діляться вакансіями, інтернатурами, стажуваннями для людей зовсім без досвіду. Ви зможете його знайти на сайті. І ще одна «порада» - не цурайтесь безкоштовної інтернатури чи стажування (якщо звичайно це не комерційний проект) - це хороший шанс потрапити в компанію. Майже всі наші друзі (в тому числі і ми) потрапили в свою першу компанію через стажування або інтернатуру. Плюс, це досвід, який ви зможете вписати собі в резюме.
- Сайти компаній. Шукайте та моніторте сайти різних компаній, а особливо розділ кар’єра. Там є список вакансій і, можливо, ви знайдете собі підходящу. Навіть, якщо такої немає, можете всеодно надіслати своє резюме, раптом воно їх зацікавить.
- Сарафанне радіо - це дуже недооцінений спосіб пошуку роботи і дуже даремно. Тому не стидайтесь і говоріть всім, що шукаєте роботу, особливо тим знайомим, які дотичні до ІТ. Зараз важка ситуація на ринку і буде дуже круто, якщо ваш знайомий зможе замовити словечко за вас у своїй компанії.
Напишіть про ваші способи пошуку роботи, нам цікаво 💛
#experience
👍15❤8🔥2