Питання на такій співбесіді можна умовно поділити на 3 категорії:

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

2️⃣ Мотивація та очікування від нової роботи — вивчіть інформацію про компанію, в яку влаштовуєтеся: хто керує, коли створена, яка сфера діяльності тощо, і чим будете корисні компанії та інше.

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

Є нюанси підготовки, які варто передбачити заздалегідь 👀

▪️Виберіть місце для зйомки. Килим на стіні, відкрита шафа та сушарка з білизною — не найкращі декорації для співбесіди. Знайдіть у квартирі максимально нейтральне тло і сховайте все зайве, що потрапляє в кадр.

▪️Налаштуйте техніку та платформу для відеозв'язку. Шукати інструкцію до мікрофона або писати в тех.підтримку Zoom за 5 хвилин до початку дзвінка - той ще стрес. Передбачте технічні моменти заздалегідь: розберіться в налаштуваннях гарнітури, зареєструйтесь у потрібному сервісі та протестуйте камеру та звук.

▪️Підготуйте одяг та речі першої необхідності. З вечора підготуйте чистий і випрасуваний одяг, в якому постанете перед камерою. Одягати костюм-трійку не потрібно, але виглядати охайно важливо. На дзвінку тримайте поруч пляшечку води, телефон та ручку із блокнотом.

▪️Продумайте освітлення. Щоб рекрутер розглянув вас по відеозв'язку, потрібне гарне освітлення. Ідеальне місце для дзвінка - недалеко від вікна, але якщо природного світла недостатньо, поставте поряд з монітором або ноутбуком невелику лампу для фронтального освітлення.

▪️ Порепетируйте перед камерою. Якщо ви не звикли до онлайн-дзвінків і відчуваєте скутість перед камерою – потренуйтеся. Увімкніть відеозапис і спробуйте відповісти на гіпотетичні питання рекрутера, начебто ви вже на співбесіді. Потім подивіться відео, пропрацюйте косяки та відрепетируйте ще раз.

▪️Забезпечте тишу під час співбесіди. Попередьте домочадців про майбутню співбесіду і попросіть вас не турбувати, а краще - щоб вони пішли з дому на пару годин і забрали з собою всіх дітей та тварин. Чим менше сторонніх звуків та руху навколо, тим простіше сконцентруватися.

Бажаю вам впоратися з хвилюванням перед камерою і показати себе з кращого боку ❤️

А також підписуйтесь на інші соціальні мережі 👇

TikTok | Instagram

#НапуттяВід_HR

Terraform: що це і як ним користуватися, які переваги IaC🧐

👉 Terraform - це інструмент для інфраструктурного програмування (Infrastructure as Code, IaC), розроблений компанією HashiCorp. Він дозволяє автоматизувати процес створення, налаштування та управління інфраструктурою, що дозволяє спростити та прискорити розгортання та управління хмарними інфраструктурами.

Основна ідея IaC полягає в тому, що інфраструктуру можна представити у вигляді коду, а цей код можна контролювати, ревізіювати, тестувати та зберігати в системі контролю версій (GitOps). За допомогою Terraform можна створювати, налаштовувати та управляти різними типами інфраструктури, як-от віртуальні машини, контейнери, мережі, бази даних тощо.

▪️ GitOps - це практики, які дозволяють перенести практики з області написання програмного коду в інфраструктурний код. Цей підхід дозволяє миттєво відтворювати інфраструктуру із системи контролю версій.

#codica_tech

Як Terraform працює?

▪️ Terraform (утиліта командного рядка) працює з файлами (кодом) і інтерпретує їх усередині cloud або on-premise платформи — створює, змінює або видаляє ресурси.

▪️ Terraform підтримує велику кількість платформ: від основних хмарних провайдерів (AWS, Azure, GCP) до більш скромних платформ, наприклад, Hetzner або 1 & 1. Крім того, він підтримує роботу з таким ПО, як Kubernetes, Ansible, що розширює функціонал і дозволяє використовувати їх у зв'язці. Тому Terraform такий популярний — це справжній швейцарський ніж у світі управління інфраструктурою.

Основні переваги використання Terraform та IaC охоплюють таке:

▪️ Автоматизація: IaC дозволяє автоматизувати процеси створення, налаштування та управління інфраструктурою, що дозволяє зменшити час і помилки, пов'язані з ручним розгортанням. Це робить інфраструктуру “repeatable”.

▪️ Простота: Terraform використовує просту мову конфігурації - HCL, що дозволяє швидко створювати, змінювати та управляти інфраструктурою. Також у Terraform є модулі, які можуть допомогти вам зекономити час і в зручному вигляді організувати ваш код, щоб він дотримувався принципів KISS, DRY та інших.

▪️ Відстежування змін: Terraform зберігає стан інфраструктури у становому файлі (state file), що дозволяє відстежувати зміни та легко відновлювати попередні версії. Зазвичай стейт-файл завантажують у S3 бакет, але у багатьох є свої інтеграції, як, наприклад у Gitlab.

▪️ Масштабованість: Terraform дозволяє створювати та управляти інфраструктурою будь-якої складності, включно віртуальні машини, контейнери, мережі, бази даних та інші складні системи.

▪️ Безпека: є багато різних утиліт, які тестують Terraform на безпеку, наприклад tfsec, checkov. А якщо додати зверху ще security-related сервіси на кшталт security hub і його інтеграції в AWS, то у вас вийде гарний результат (якщо ви звичайно не пропускатимете помилки).

▪️ Керованість: Terraform дозволяє описувати конфігурацію інфраструктури у вигляді коду, що дозволяє керувати процесом розгортання та зміни інфраструктури за допомогою кодових комітів та іншими методами контролю версій.

Щоб користуватися Terraform, необхідно встановити його на свій комп'ютер та налаштувати конфігураційні файли для кожного провайдера, з яким ви працюєте.

Але ми рекомендуємо налаштувати повний воркфлоу CI/CD для Terraform, де у вас уже й будуть різні тести. Також варто згадати, що у Terraform чудова документація з купою прикладів і відмінний get started гайд.

Підписуйтесь на інші соціальні мережі 👇
TikTok | Instagram

#codica_tech

👉 Підпишись на наш TikTok | Instagram

#codica_humor

Всім гарного недільного дня, ловіть невеличкий дайджест новин зі світу IT від @Mister_Cody 📲

🔍 В Україні запрацювала система блокування інтернет-ресурсів. Ні, не аналог Розкомнагляду

💰 Зарплатні рекордсмени в ІТ. DevOps за $15к та Front-end на чотирьох роботах

👨‍💻 Мінцифри запускає безкоштовний курс з кібербезпеки. Зареєструватись можна за посиланням

🤖 Повстання штучного інтелекту. Просунутий чат-бот Microsoft заявив, що хоче стати людиною

🧐 Гуманоїд від Tesla навчився ходити й переносити предмети.

👉 Підпишись на наш TikTok | Instagram

Доброго ранку та гарного тижня 😌

#codica_ruby

Prometheus: що це і для чого? 🤔

📌 Prometheus - це система моніторингу з відкритим кодом, яка використовується для збору та аналізу метрик з різних систем, застосунків та сервісів.

👉 Вона була створена компанією SoundCloud у 2012 році та зараз підтримується Cloud Native Computing Foundation (CNCF). Prometheus надає користувачам мову запитів, можливості зберігання і примітивної візуалізації. Система збирає метрики в реальному часі та записує їх в базу даних.

#codica_tech

💻 Система написана мовою Go і поширюється за ліцензією Apache 2 License, а вихідний код доступний на GitHub.

😌 Як проєкт з відкритим вихідним кодом Prometheus користується широкою підтримкою спільноти, тому має достатньо клієнтських бібліотек, які забезпечують просту взаємодію з ним.

☝️ Prometheus розроблений для високої масштабовності та адаптивності, що дозволяє легко впоратися з великими та складними середовищами. Для зберігання та запиту даних він використовує time-series базу даних, що дозволяє користувачам швидко та ефективно досліджувати свої дані та виявляти тенденції та аномалії.

🔖 Prometheus збирає метрики, які надають різні сервіси та системи. Він підтримує широкий спектр форматів та протоколів передачі даних, включно HTTP, SNMP, JMX та інші. Prometheus також може використовуватися для моніторингу інфраструктурних метрик, як-от використання CPU, пам'яті, мережевої пропускної здатності та використання диска і багато інших інтеграцій на будь-який смак, наприклад, domain_exporter дозволяє скрейпити час, коли закінчаться домени, blackbox_exporter моніторить downtime.

🖇 Окрім збору метрик, Prometheus + alert manager підтримує сповіщення на основі налаштовуваних правил у величезну кількість сервісів, що дозволяє командам швидко виявляти та розв'язувати проблеми зі своїми системами та сервісами.

Підписуйтесь на інші соціальні мережі👇
TikTok | Instagram

#codica_tech

30 березня запрошуємо на Cloud Builders: Java Conf з провідними Java & Cloud спікерами з Microsoft, Nortal та DataStax.

☝️ Cloud Builders: Java Conf 2023 об'єднає 12+ спікерів з Java та хмарних технологій: Adam Bien, Mark Heckler, Mohamed Taman, Mary Grygleski, Rory Preddy, Monica Beckwith та ін.

👉 AI зараз у топі, і ми детально заглибимось у тему OpenAI, який може допомогти мільйонам.

Також, поговоримо про Spring Cloud Function & Azure Functions, підводні камені Java 20, Event Streaming і Apache Pulsar та інші теми.

📆 30 березня о 10:00 (GMT +3)
Формат: одноденна онлайн-конференція
Участь – безкоштовна

👉 Дізнатися більше та зареєструватися

Тестова стратегія у процесах тестування 💻

📌 Стаття від нашого QA Lead - Олексія

В попередньому дописі ми розглянули ідеї, покладені в написання актуального тест-плану, і його можливі складові.

В порівнянні із тест-планом (а цими порівняннями повниться теоретична база QA), тестова стратегія є більш високорівневим, статичним і довгостроковим документом. Що це означає? 🤔

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

#codica_advice

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

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

💁‍♂️ Не дивлячись на слово “тестова” в назві, стратегію далеко не завжди пише саме QA. Зазвичай це залежить від змісту документу. В тому випадку, коли формалізовані рішення більш процесуальні, аніж технічні, за тестову стратегію цілком може відповідати PM, бо по суті така тестова стратегія буде прямим продовженням бізнес-вимог і загальних робочих воркфлоу.

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

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

🖇 Також розповсюдженою практикою є часткове внесення стратегії у тест-план. Фактично це просто означатиме додаткові розділи в тест-плані, оскільки нехай і буде розглянуто ідеї з формату тестової стратегії, але все одно лиш на рівні проєкту.

#codica_advice

📝 Як і у випадку тест-плану, теорія написання стратегії сформулювала певний набір класичних розділів/тем (багато з яких можуть дублювати розділи з тест-плану), чиє призначення варто розуміти із прив’язкою до практики, щоби уникнути проформеної бюрократії замість актуальної пам’ятки.

1️⃣ Скоуп робіт, який може нести в собі як домовленості щодо роботи над тестовою стратегією, так і домовленості стосовно типової послідовності тестових активностей. Типова послідовність всім відома з STLC (Software Testing Life Cycle), але на практиці далеко не всі етапи мають місце, і тим більше в тому ж порядку і в тих же часових діапазонах. Важливо вписувати сюди апроксимацію до реальної ситуації, а не бажану картину.

2️⃣ Типова структура команди і розподіл відповідальності дозволить уніфікувати початкові процеси для кожного нового проєкту. Зазвичай цей розділ пишеться у великих компаніях, де, власне, присутня ця типовість команди.

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

4️⃣ Типи тестування та підходи є зазвичай комплексним розділом, в якому детально формалізовано зібраний досвід тестувальних активностей. Сюди можуть входити і рівні тестування, і типи тестування, і домовленості щодо процесів, коли і як проводиться ре-тестінг, регресія, як заводяться баги, коли тестування вважають задовільним чи неможливим для продовження тощо. Це своєрідно ядро тестової стратегії, що збирає довкола себе найбільшу кількість колективних розмислів.

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

6️⃣ Перелік інструментів для тестування, що є списком ключових технологій та технічних рішень. Зазвичай містить і організаційні рішення типу Jira, Trello, TestRail, PractiTest, і суто технічні під різні типи тестування — корисні браузерні розширення, інструменти з автоматизації, з тестування навантаження, інтерсептори трафіку. Також може містити вартість і обґрунтування експлуатації платних додатків для подальшого прийняття рішень на рівні менеджменту компанії.

7️⃣ Робота з ризиками має містити практично відпрацьовані загальні ризики із приблизною оцінкою їх впливу та стратегією зниження можливості в разі необхідності.

8️⃣ Комунікація із клієнтом зазвичай містить загальні рекомендації із хорошого тону, ділової кореспонденції, форматів і способів обговорити із клієнтом щось. Зазвичай тут же може бути визначене посередництво, скажімо, PM у будь-якій комунікації, а також прописані типові екстрені ситуації, в яких необхідно негайно звернутися до клієнта.

Підписуйтесь на інші соціальні мережі 👇

TikTok | Instagram

#codica_advice

#CodicaTeam вітає всіх жінок з Міжнародним жіночим днем 🌸

Цього дня ми хочемо побажати вам відчувати себе поважаними, цінними та коханими, мати здоров'я, щастя та невичерпну енергію для реалізації усіх своїх мрій та бажань 😌

Нехай весна принесе вам нові можливості, яскраві події та незабутні враження. Бажаємо вам кожен день відчувати себе сильними та впевненими в своїх здібностях, знаходити радість та задоволення у кожному моменті життя ❤️‍🔥

Друзі, на нашому YouTube-каналі вийшло нове відео про ChatGPT 🦾

У цьому відео наш PR Manager Павло відповість на такі питання:
🔥 Що таке ChatGPT і як це працює?
🔥 Що він вміє?
🔥 Які обмеження має ChatGPT?

Сподіваємося, кожен з вас знайде застосування цієї технології у повсякденному житті 😏

Приємного перегляду та не забувайте ставити вподобайки ❤️

Що таке CORS❓

📌 CORS (Cross-Origin Resource Sharing) - це механізм, який дозволяє веб-браузерам дозволяти запити на доступ до ресурсів (наприклад, даних або зображень) з інших джерел, що знаходяться на інших доменах або піддоменах.

#codica_tech

👉 Коли веб-сторінка робить запит на доступ до ресурсу на іншому домені, браузер зазвичай забороняє такий запит заради безпеки. CORS дозволяє серверам вказувати, які домени можуть отримувати доступ до ресурсів з цього сервера, тим самим роблячи можливим доступ до ресурсів з інших доменів.

💻 Для налаштування CORS сервер може включати додаткові HTTP-заголовки у відповіді на запит. Заголовки можуть вказувати, які домени мають дозвіл на доступ до ресурсу, які HTTP-методи дозволені для запитів на ресурс, які HTTP-заголовки можуть використовуватися у запитах, тощо.

😌 За допомогою CORS можна забезпечити безпеку при доступі до ресурсів з інших доменів, збільшити масштабовність веб-застосунків і полегшити розробку застосунків, які використовують дані з різних джерел.

Підписуйтесь на наші👇
TikTok та Instagram

#codica_tech