Щоб русня сдохла.
Персонально для себе — щоб з роботи не скоротили
якщо роботодавець тебе не візьме через тату — то скоріш за все ти б в такому місці і так не хотів працювати)
Не така велика проблема цінник, як мікротранзакції.
Заплатити 70 баксів за гру в яку приємно грати — норм, але коли ця гра не блокує прогрес одноманітним грайндом, і пропонує його скіпнути всього за пару баксів. Платити за гру, і потім ще раз за те, щоб пограти в цікаві частини гри, і пропустити бездумний філлер — от цього не хочеться
— пет-проект — можливо. не обов’язково «суспільно-корисний» або унікальний, але просто зацікавила технологія — видумав якусь штуку, яку прикольно було б зробити — пару тижнів просидів за проєктом, набив шишок — проєкт можна викинути, а досвід вже трохи з’явився
друга робота — складно. зате якщо добре піде, то можна зробити цю другу першою і єдиною :)
літкод — якщо цікаво — то круто, плюс непогана інвестиція для співбесід. якщо вирішення саме по собі не цікаво, і якихось прямих застосувань (співбесіди чи хз що) не видно на обрії — скоріше за все швидко заб’єш.
сертифікація — можливо. готуватись до сертифікації взагалі корисно, навіть якщо не проходити власне екзамен.
нічого не змінюючи у своєму резюме окрім досвіду роботи
ну так власне це і є основна зміна. Ейчар не може по резюме сказати, наскільки ти добре знаєш умовний Spring, але припущення що людина, яка працювала з ним 4 роки знає більше за людину, яка працювала рік — достатньо логічне.
Якщо в компанії вміють проводити співбесіду — то домальований досвід буде помічено дуже швидко (а враховуючи що ейчари між собою спілкуються — це може створювати проблеми і в майбутньому).
Якщо не вміють — то цілком можуть і взяти — і там або дуже швидко навчишся плавати, або потонеш. Якщо потрапиш в хорошу команду з шарящими людьми — то є шанс швидко і якісно навчитись, якщо потрапиш до таких же джунів — то скоріш за все буде все погано.
Робитиму, якщо цікава компанія і цікаве завдання.
от тільки «хороших руських» нам не вистачало
Не засиджуватись на проєкті, якщо він не дає нічого для особистого розвитку (принаймні перші років 10, може з 20+ роками досвіду я трохи зміню свою думку). Чітко розуміти, чого ти очікуєш від певного місця роботи — що вкладаєш, що отримуєш, і не боятись змінити місце, якщо змінились пріорітети, або якщо поточна робота не відповідає вимогам.
Активно розвиватись. Порадив би собі самому дивитись на розвитку «в ширину» раніше — хоч мені й подобається копати глибоко, але розуміння, що в продуктових компаніях не так важлива мова/фреймворк, як «загальні» хард (і софт) скілли — в мене з’явилось трохи запізно і випадково — могло б так не пощастити, і досі би веслав на галєрі
Лінк на якийсь інший Dragonfly, здається:
> Dragonfly is an open source python library for scalable Bayesian optimisation.
«Більшість розробників бачать свій шлях із стартапами як ще один крок у своїй кар’єрі, щоб потрапити в Google або Facebook»
І що в цьому поганого? Ви сподівались, що розробник працюватиме у вас до пенсії?
Наймаєте джуна, якому гугли ще не світять, навчаєте, прокачуєте, через рік-півтора у вас крутий девелопер, який вже зробив багато хорошого для вашого проєкту. Можливо він шукатиме нові виклики в більшій компанії, можливо ваш стартап так зростатиме, що йому цікавих задач вистачатиме і з вами — в будь-якому випадку це ок.
за 4ре года — «не смогли» ничего
Можливо, не «нічого», а «щось однозначно краще за існуюче рішення»? На створення і підтримку операційки явно потрібно немало вкладати, і якщо зараз окуляри добре працюють на андроїді, і туди можна додати усі потрібні фічі, не розробляючи нову платформу з нуля — то і не потрібно?
да, цілком можливо. Я більше мав на увазі різницю між пошуком «конкретно того, хто вам потрібен на конкретну позицію в конкретній ситуації» і «робота різна, її вистачить всім, головне створити однорідний процес відбору»
1) Десь там в теорії між «навичками літкода» і вирішенням реальних продуктових задач є кореляції (не причинно-наслідковий зв’язок). На об’ємах, якими наймають фаанги, якщо кореляція дійсно є — це може допомагати. Звісно, якщо компанія наймає 5 людей на рік, такі кореляції не дуже важливі.
2) Простота стандартизації, мінімум суб’єктивності. Такі задачі вже 100 разів розібрали, і інтерв’ювери знають, чого їм очікувати, що є позитивним сигналом, що негативним. Якщо в компанії 5000 людей проводять співбесіди, кожен сам щось видумує, то зрозуміти, де в нас «планка» для найму буде дуже важко.
3) «Чесність» для спеціаліста. Задачі достатньо абстрактні, їх має бути нескладно зрозуміти, виконання такої задачі не вимагає якихось попередніх знань, окрім знань алгоритмів і обраної мови — тобто того, що має бути в кандидати по дефолту.
Тобто такий підхід непогано може працювати, якщо ви наймаєте людей сотнями і тисячами на абстрактну позицію «програміст», але не дуже працює, якщо ви маленька компанія (у вас
Компанія виграла апеляцію у справі з Epic Games
Його не скасовано, та апеляційному суду потрібно більше часу на розгляд справи
здається, щось десь не стикується.
Хороша стаття, дякую!
Список доволі «некотроверсійний», але добре показує, що з іграми цього року було не дуже густо.
Ця мова має сувору типізацію
не впевнений, що це найкращий переклад. Українська вікіпедія пропонує «сильну типізацію» (uk.wikipedia.org/wiki/Система_типізаці)
Якщо відповідальність і коло обов’язків зросли — можна попросити більше грошей. Якщо обов’язки ті самі, що обговорювались на початку роботи, просто вас звуть лідом, а не сіньйором — то взагалі нічого не змінилось.
Ніколи не розумів, чому Майкрософт відсутні з цієї аббревіатури.. От і поправлять)