Мені не потрібен лічильник, бо єдиний KPI, якщо можна так сказати, тут тільки офери на роботу, більше нічого.
Всім пофігу, ніхто не дивиться ваш GitHub при прийомі на роботу, якщо ви не рок-зірка з якимось проектом, не витрачайте на це час. Кажу як людина з таким GitHub — github.com/dmytrostriletskyi
Я, як людина, що має пару десятків статей на півмільйона переглядів, GitHub із зірочками, та подкаст на YouTube-каналі DOU, можу з повною впевненістю сказати, що це найгірше, що ви можете зробити, якщо хочете розвиватися саме карʼєрою в компанії.
Це ніхто не цінує: не відмічають на співбесідах, не скіпають раунди співбесід, це не те, що не є вирішальним в наймі, це просто має імпакт близький до нуля. А на це витрачається реально дуже багато часу, в перерахунки на витрачені роки, в мене, мабуть, на декілька набереться.
Найкраще, що ви можете зробити для карʼєри, в моєму випадку кажу за розробників, це жостко задротити DSA (алгоритми і структури даних) і системний дизайн, і їхати собі працювати в FAANG на гарні гроші, рости по карʼєрній драбині і насолоджуватися життям.
Якщо ж ви просто кайфуєте від ІТ, від проектів, від медійності і двіжа, то це інше, я кажду за саме розвиток по карʼєрній драбині. Але не будуйте мрії, що це хтось оцінить, ІТ та ж сама репрезентація всього на світі, якщо ти не граєш по правилам, тебе не сприймають.
Звісно, є виключення, коли ти реально рок-різка в медійності чи в опен сорсі, але які шанси, що це станеться з вами. По математиці, це лузова ставка, думаю.
Для кого ця книжка і яке велью пропонує? Цього не розумію з текста поста і огляду книжки.
Проблема співбесід не в тому, що питають не те і не так, а в тому, що люди, які будуються процеси в компанії, включно з співбесідами, не є самосвідомими.
Вони не здатні зрозуміти, що працює для них, а що ні, не здатні поглянути зі сторони, зробити висновки і поліпшити процес.
Як приклад, є купа різних компаній з різними продуктами і на різних стадіях, але якщо там працюють люди з досвідом роботи в FAANG, очікуй в 95% випадках алгоритми і структури даних на співбесіді — тому що люди, які відповідають за співбесіди, банально скриптовані і не розуміють реальні потреби конкретної компанії.
В мене теж саме зі статтями на Medium і інші англомовні ресурси, включно з Reddit та Hacker News.
Скільки б всього не постив і як би не експерементував, включно з тим, що перечитав сотню порад як і коли постити, нічого не працює.
Впевнений, що «взломати» це можна, там є алгоритми успіху в стилі алгоритмів ранжування сайтів у пошуку, але я не прошарив.
Але мене це бісить, бо у нас на DOU і, коли я ще писав на Habr, алгоритмів ніяких немає: написав гівно — нічого не отримав, написав топ-контент — отримав перегляди і зірочки/плюсики/закладки.
В нас напроти двору будинку теж є шлагбаум, але тепер він постійно відкритий. Тому що є протокол доручень КМВА № 23 від 22.05.2023 і розпорядження КМВА № 456 від 10.03.2022 щодо мінімізації ризиків загибелі та травмування мешканців будинків в разі виникнення надзвичайної ситуації. Типу треба оперативний доступ автомобілів екстрених служб. Це те, що я знаю на рахунок нашого будинку. Погугліть за номери вище, можливо, зараз ваш додаток не буде актуальним.
Розробка програмного забезпечення — це настільки складний та час від часу непередбачуваний процес, що дати більш-менш точну оцінку просто неможливо. Навіть один епік, навіть одну таску розробники з однієї команди, які вже мають досвід розробки цього ж проекту, можуть оцінюювати по-різному, що вже казати про цілі проекти.
Виключеннями можуть бути однакові проекти в компанії, як ви вказали.
Моя порада — це уникати або відкладати (чим пізніше, тим більше ви знаєте про сам проект, тим точніше може бути оцінка) будь-яких естімейтів, якщо вони потрібні саме для передбачення часу доставки функціоналу при кожній можливості.
Ось це може знадобитися для видалення ресурсів K8S для пулл реквеста, коли з ним вже ніхто не буде працювати — github.com/...e-feature-branch-operator
Не ідеально, але дуже просто.
Я работал вне рабочего времени, поэтому они просуммировались.
Не считал, так как делал это по часу-два в день на протяжении недели.
Если честно, даже в голову не пришло. Возможно, это из-за того, что на тот момент и до него не принимали пеших курьеров.
Я до выхода на работу в Rocket хотел поработать курьером (подписавши оффер), понять как работает сервис. Выбрал, что буду доставлять пешим, но мне не перезвонили/написали. Потом уже, когда вышел на работу, написал логистам и спросил почему мне не перезвонили/написали — ответили, что не нанимают пеших. И убрали плашку «пеший курьер» на сайт, поблагодарив.
Молодец, Артем!
Я сам занимаюсь бегом и плаванием, а в будущем подключу и велосипед, у меня 6 тренировок в неделю и я тоже встаю в 5:20. Хочу пройти IronMan, поэтому я отлично знаю какие трудности ты преодолеваешь каждый день, текстом выразить которые просто невозможно: когда твой же мозг штурмует тебя остановиться и пойти отдохнуть, и ты уговариваешь его заткнуться, когда ноги просто не слушаются и не поднимаются, когда задыхаешься в анаэробной зоне, когда бежишь через боль в связках, когда кроме тренировок нужно тратить время на разминку, заминку, массаж, баню, здоровое питание и нельзя лечь поздно спать.
Циклические виды спорта на уровне, чтобы пройти IronMan, это каждодневная борьба с самим собой и чувства, которые нельзя нигде в другом месте испытать.
Спасибо за статью и дополнительную мотивацию. :)
В JavaScript не разбираюсь, но разбираюсь в дебильных тестовых:
1. Нет форматирования текста.
2. Нет форматирования кода.
3. «Немножко текст по-дебильному написан».
4. Нет тестов, который ваш код должен проходить.
5. Нет написанного заранее готового решения, которое они ожидают от кандидата. Его можно присылать кандидатам, у которых низкое качество кода на их взгляд, чтобы не отказывать в развернутом фидбеке — лучше, чем ничего.
И так у них, скорее всего, не только в тестовом, но и в коде, документации и процессах.
Дмитро, привіт,
у відео ви казали про те, що у вас є адміністративна панель для A/B тестів, за допомогою якої можна розкатувати фічі, скейлити на юзерів і так далі. А не могли б ви поділись про це більш детально — це якісь готові практики, підходи, інструменти про якісь можна десь почитати чи внутрішня розробка с нуля? Цікавить як вся автоматизація технічно реалізована.
Дякую.
Когда человек меняет работу, он профессионально растет с каждым разом. Поэтому нет смысла писать что вы делали на первых работах, можно описать только несколько последних. Остальные можно не расписывать, только указать, что вы там работали.
Резюме містить низку граматичних помилок.
А я от, до речі, брав нейтіва. Але потім спеціально тільки один артикль забрав, бо так на одну сторінку не поміщалося. Дивно, що він не помітив багато чого, треба буде ще одного взяти.
Ще мені не подобається повна відсутність інформації щодо 1.5 років роботи в перших двох (трьох?) компаніях.
По-перше, я не бачу сенсу додавати опис про посаду, на якій я зробив в рази менше по кількості та якісності ніж на останніх. По-друге, попри перший пункт, моє резюме все одно гарно працює на будь-який тип компаній в різних локаціях.
Але дякую за коментар, я гадаю, що іншим буде корисно.
Це не про те як до цього відносяться у компанії, а про те, що якщо така інформація буде у резюме, його навіть ніхто не буде читати, одразу в смітник.
Я знаю только одну такую страну — Португалия. Здесь можно приехать туристом, зарегистрировать что-то типа ФОП, а потом на этой основе просить resident permit. Там даже какое-то количество времени (год, вроде), можно не платить налоги вообще (если заработок ниже определенной суммы). Но, насколько я слышал, это не стопроцентный вариант (могут отказать), особенно, если вы соглашаетесь не платить налог. В общем, подробности можно поискать в группе в Телеграм — t.me/EuAmoPortugal
В опен сорсі більше витратиш час на зрозуміння написаного коду, ніж на поліпшення навичок. Шукай якісь проекти, де можна по рекваірементам імплементувати щось і якось перевірити, чи правильно все зробив — може, таке хтось зробив. Опен сорс — втрата часу.