По-третє, якщо тестове велике та займає певний час, треба подумати над оплатою, щоб додати мотивації виконувати його
Жодного разу ще не зустрічав українські ІТ-компанії, які платили б за виконання тестових завдань.
Більше того, багато хто дратується при згадці про оплату.
І на останок: кандидати, не бійтеся співбесід — це теж досвід,
Ось після цих слів я чомусь почав боятися співбесід
Як давати негативний фідбек за результатами співбесідиНайголовніше правило: фідбек треба давати завжди, і бажано із цим не затягувати
В Українському IT це скоріше виняток, ніж правило.
Я б вас зрозумів, якби ви написали «нарада в неділю пізно ввечері»
Я вважаю, що рекрутер (або компанія, яку він представляє) зобов’язані розкривати причину відмови, якщо кандидат пройшов щонайменше стадію технічної співбесіди.
Тому що іноді пишуть так: «У нас було багато кандидатів, і ми обрали більш придатного. Але незрозуміло, чому їм не виявилися ви, якщо успішно пройшли технічну співбесіду».
Декілька разів таке було. Зазвичай компанії не морочаться і вигадують стандартну причину для відмови.
Як на мене, у реаліях українського ІТ, overqualified — це людина, яка просить надто багато грошей (на думку замовника).
Дякую за пост, але дуже багато недоліків та неточностей
Spring пропонує два видатні підходи: Spring JDBC та Spring Data JPA.
А чому Spring JDBC видатний підхід, а Spring Data JDBC чи Spring Data R2DBC не видатні?
Прямий контроль над SQL-запитами: Spring JDBC дозволяє вам явно писати ваші SQL-запити, надаючи повний контроль над взаємодією з базою даних
Ну так і Spring Data JPA дозволяє використовувати native (SQL) запити
Мінуси:Менше контролю над SQL-запитами: іноді абстракція може бути надто великою, і так приховувати необхідні деталі для оптимізації.
Це не так. У Spring Data JPA можна також писати SQL і JPQL запити.
Потенційно знижує продуктивність: шар абстракції може знизити продуктивність, особливо якщо використовувати його необережно.
Spring Data JPA не може знизити продуктивність сам по собі, він просто транслює код у запити JPQL, а що там з ними робитиме JPA провайдер (Hibernate) ніхто не знає.
Spring JDBC вимагає явної конфігурації для кожного запиту та ручного відображення результатів у доменні об’єкти. Spring Data JPA з його шаблоном репозиторію зменшує цю потребу, надаючи стандартні методи та створення SQL-запитів через назви методів.
Черговий набір слів. Плюс автор не сказав найголовніше — що Spring Data JPA вимагає mapping для моделі даних і без неї працювати не може.
Є й жорсткіші умови.
Коли не тільки тайм-трекер, але ще й вимоги до включеної веб-камери, яка періодично тебе фотографує.
У них навіть у вакансіях вказується: Тільки віддалено. І тільки не Україна.
Не знаю як назвати такий пост, але це точно не «Docker бест практіс», тому що дуже багато понять не пояснюється або просто помилкові.
Наприклад:
Використовуйте офіційні образи як базу. Наприклад, якщо ви працюєте з Node.js, почніть з node:14-alpine.
Добре, якщо я пишу на Java? Офіційно Java розробляється компанією Oracle, але вона забороняє використовувати JDK в Docker images. Є open-source images від OpenJDK, але вони вже кілька років не підтримуються.
Таким чином, мені потрібно вибирати між images від Eclipse Temurin, Amazon Corretto, Liberica і т.д. Де тут «офіційні»?
Мінімізуйте розмір образу, з’єднуючи команди разом:
Дивно, але в наведеному прикладі якраз 6 інструкцій і жодного об’єднання там немає.
Визначте обмеження ресурсів у вашому файлі Docker-Compose.
У цьому прикладі використовується атрибут deploy, але автор «забув» вказати, що він застосовується тільки якщо ви розміщуєте контейнери в Docker Swarm. Тобто, якщо просто запустити через docker compose up, то все це проігнорується.
Я senior, і що тепер?
Відсвяткувати
Що ви тоді робите на українському сайті, якщо ненавидите Україну?
Курс долара
Справді, як це працює на економіку України?
Місяць тому була аналогічна стаття. Навіщо постити дублікати?
Насамперед потрібно визначитися, наскільки часто все це зустрічається в українському ІТ, щоб визначати це у червоні лінії?
1. Якщо компанія зі старту каже, що ФОП веде бухгалтер компанії і ніяк інакше, — run. То не є ок. Не кажучи про те, що ФОП відповідає своїм майном.
Ніколи про такі умови не чув на співбесідах.
2. Якщо трекають години, проведені на роботі. Коли роблять скріни в рандомний момент — run — вам того не треба. Ви варті кращого. Ця дурня не має жодного стосунку до якості виконаної роботи чи вашого перфоменсу.
За останні 5 років зустрілося лише одного разу.
5. Великі тестові завдання. Якщо тестове розраховане на пару днів чи його треба виконувати в робочий час і компанія це не оплачує, то це зазвичай даремна трата часу без жодного конструктиву. Хочете великі тестові? Платіть.
А автор мав досвід оплачених тестових завдань?
Я часто питав про це у компаній, ще жодна не погодилася платити.
Червоні прапорці:
6. Не людскі відносини.
7. Не людскі умови.
8. Лениві, токсичні, вперті або не досвідчені колегі.
9. Неповага к досвіду, та досягненям
10. Несправедливість в команді.
11. Скритність компанії.
12. Философія компании де є Начальник та лизун або цап відбувайло.
А як ви це визначите на співбесіді?
Я б напружився, якби мене запитали: «Навіщо потрібні люки?» або «Процес виготовлення люків»
Поки писалася ця стаття, вийшли Gradle 8.4 та Eclipse Temurin 21, тому зараз можемо використовувати в наших Dockerfile:
FROM eclipse-temurin:21-jre-alpine
FROM gradle:8-jdk21-alpine
Єдине обмеження для JDK 21 — Gradle 8.4 не підтримує скрипти збирання на Kotlin, якщо вони використовують плагін kotlin-dsl.
А чого його соромиться? Якщо код поганий, то його досить швидко перепишуть/замінять, а якщо хороший — то він так і працюватиме і нас переживе.