Вхід і реєстрація
×
Про роботу · 7 червня 2020, 18:01 6188
Vova Adamenko, Java beginner

Отриманий оффер і почалась трудова діяльність в ІТ компанії. З чого почати?

Доброго дня.

Ось вже отриманий оффер і почалась трудова діяльність в ІТ компанії. Але перед новим, ще недосвідченим розробником виникає складність пов’язана з роботою над проектом, який він/вона бачить перший раз, з технологіями які використовуються в проекті.

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

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
LinkedIn

Найкращі коментарі пропустити

Natalia Riabokon 08.06.2020 10:31

1. Не стесняйся задавать вопросы. Лиду, рядом сидящему коллеге и т.д. Лучше, переборов собственный страх показаться некомпетентным, таки задать вопрос и решить задачу за два часа, чем потратить день-полтора на то же самое в попытках «сохранить лицо».

2. Но и по тридцать раз спрашивать то же самое лучше не надо. Заведи себе файлик, в который будешь записывать важную инфу, чтоб не забыть. Вообще любую инфу по работе: «по вопросам юнит тестов обращаться к Максу», «библиотека для аналитики называется так-то», «документация по сборке вот этой хитрой тулзовины находится здесь».

3. Тут на любителя, но, если дают выбрать таску, начинай с самых несложных, постепенно повышая левел. Лучше в приемлемый срок успешно справиться с простой задачей, чем долго и безуспешно пытаться сожрать мамонта в одиночку (а потом еще может оказаться, что сделал вообще не то и не так).

4. Не изобретай велосипеды. Если в голову ударяет гениальная идея одновременно с мыслью «до такого простого решения никто не додумался, а я молодец и сделаю сейчас красиво» — поинтересуйся, возможно готовое решение уже есть либо по каким-то причинам так делать нельзя.

5. Относись внимательно к общепринятому код стайлу: выражать свою индивидуальность способом написания some_var, когда везде someVar (или наоборот) лучше не стоит.

Перейти до дискусії
Євген Козлов 08.06.2020 02:04

окей, я так розумію, ніякого рамп-апа, тіммейти морозяться, або, що навіть гірше, просто закидали тебе мільонами посилань на джиру, конфлюенс, гугл доки та плейлисті на порнхабі, і з відчуттям «теперь все від нього залежить» розвернулись спиною. Я прав? Якщо так, то співчуваю, був в такому, то жопа.

Давай, подивимось, що в нас взагалі є.

1. технології(ну, це всі бібліотеки, концепції, архітектура, юніт тести я б сюди ж заніс)
2. домовленності(структура коду, код стайл, етк)
3. люди та комунікації(хто тестує баг, кого питати по тим питаннях, а кого по тим)
4. процеси(як саме заводити тікет, щоб нікого не бісити, як міняти статус етк)
5. енвайрномент локальний(як підняти локально)
6. енвайронмент(и) віддалені(доступ, контроль, логи)
7. скоуп робот(чи є у вигляді списка, чи лише в когось в голові)
8. пріорітети(хоча б — знати, в кого спитати, з ким узгодити)
9. domain area(нащо ви взагалі робите те, що робите — які проблеми бізнесу вирішує проект)

На мою думку, критично для старта розрулити питання 5 і 7.
Потім береш багу або сторі/функціонал(але за умови повного розуміння, як будеш її робити) і фігачишь.

Пункт 2 і 4 можна попершу робити «за прикладом того, що довкола».
Пункти 3 і 8 можна спершу взагалі рандомних тіммейтів питати. 6 і 9 трохи зачекають, то важливе, але для ефектвності. Спочатку і «не знаю, нащо їм оця кнопка тут, але сказали ж» прокатить.
Пункт 1 досить важкий, тут питання, чи ти там знаєш щось чи для тебе світч і по технологіям, тож не зрозуміло, з чого почати. Якщо щось вже знаєш, то буде поступово накопичуватись нові знання та досвід. Якщо не знаєш, краще б хтось накидав чек-ліст з оглядкою на потреби проекту.

Перейти до дискусії
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Artem Komisarenko C++ Software Developer в Zultys 10.06.2020 06:37

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

Відповісти
Підтримати
Jaroslav Shkarupilo епам-іді-***** 10.06.2020 15:42
але зазвичай десь присутня людина, яку знаєш по імені, бо бачив її на співбесіді

Чогось згадалося: на моєму досвіді, самий трешовий кейс був, коли виявилося, що на момент мого виходу от «тієї самої» людини вже не те що вже нема, а навіть не кожен може пригадати, чи був такий, і чим займався ) Як досить швидко виявилося — не дарма, адже тікучка була колосальна.

Відповісти
Підтримати
Artem Komisarenko
Anatoliy Rentgenovich 08.06.2020 17:48

звучит как начало фильма ужасов

Відповісти
Підтримати
Леголас Трандуилович 08.06.2020 12:03
з чого почати

Ну.. почніть працювати. (насправді жарти в сторону а питання дуже доречне)

як еффективно вчити проект чи технологію

З проектом, особливо джуніору мали б допомогти старші колеги. Вони мають підказати задачі, або частину проекту добру для новачка, для його вивчення. Якщо вони самі того не зробили попросіть про це, ліда, сіньйорів, чи взагалі на загальному мітінгу. Якщо є вибір чим займатись можете просто спитити «Підкажіть чим би мені краще зайнятись щоб зрозуміти проект і приносити на ньому користь». Про технології хороше питання «що використовуєте на проекті, що мені з моїм бекграундом треба підівчити в першу чергу?».

як вчитися розуміти процеси для вирішення задач?

Практикуватись в тих процессах і в вирішенні задач. Також важливо проявляти ініціативу тут я маю на увазі що треба в перешу чергу слідкувати за тим чи самому зрозуміло що ти робиш, як то роботи, як переконатись що зробив добре, і як розвиватись.

Відповісти
Підтримати
John Appleseed 08.06.2020 10:57

На этапе «проект запустился» ещё не помешает поинтересоваться, актуальная и свежая ли версия проекта досталась.

Відповісти
Підтримати
anonymous
John Appleseed 09.06.2020 10:59

У меня были странные ситуации на эту тему.
1. Пришёл iOS-разработчиком на проект к американцам, получил код в виде zip-архива по почте к началу рабочего дня. Удивился , но начал смотреть.
К вечеру назрели вопросы , что вот тут модуль еле дышит, тут заглушка, тут вообще конь ещё не валялся.
Заказчик просит показать , показываю экран и узнаю, что код трёхмесячной несвежести, ещё даже не альфа.
Получаю новый, но уже на гите, один модуль смотрит на закрытый приватный репозиторий предыдущей уволенной команды.
2. Прихожу на проект — код месячной давности в состоянии заглушек и подпорок.
Новее версия — у коллеги, который сильно срывает сроки и подводит людей.
Говорю руководству, чтобы не спугнули, а то убежит вместе с работой за месяц( которой практически не оказалось при рассмотрении вблизи) и вообще как так получилось?

Мораль: приглядывайте за подрядчиками и если уверенно вешают лапшу — наймите аудитора стороннего.
Иначе потом будут неприятности.

Відповісти
Підтримати
anonymous
Natalia Riabokon rainha da lua в gamedev 08.06.2020 10:31

1. Не стесняйся задавать вопросы. Лиду, рядом сидящему коллеге и т.д. Лучше, переборов собственный страх показаться некомпетентным, таки задать вопрос и решить задачу за два часа, чем потратить день-полтора на то же самое в попытках «сохранить лицо».

2. Но и по тридцать раз спрашивать то же самое лучше не надо. Заведи себе файлик, в который будешь записывать важную инфу, чтоб не забыть. Вообще любую инфу по работе: «по вопросам юнит тестов обращаться к Максу», «библиотека для аналитики называется так-то», «документация по сборке вот этой хитрой тулзовины находится здесь».

3. Тут на любителя, но, если дают выбрать таску, начинай с самых несложных, постепенно повышая левел. Лучше в приемлемый срок успешно справиться с простой задачей, чем долго и безуспешно пытаться сожрать мамонта в одиночку (а потом еще может оказаться, что сделал вообще не то и не так).

4. Не изобретай велосипеды. Если в голову ударяет гениальная идея одновременно с мыслью «до такого простого решения никто не додумался, а я молодец и сделаю сейчас красиво» — поинтересуйся, возможно готовое решение уже есть либо по каким-то причинам так делать нельзя.

5. Относись внимательно к общепринятому код стайлу: выражать свою индивидуальность способом написания some_var, когда везде someVar (или наоборот) лучше не стоит.

Відповісти
Підтримати
Vova Adamenko 08.06.2020 10:35

Спасибо, по поводу файлика — я его еще в первый день завел, такой обьем инфы просто нераально запомнить с первого раза, ну и где — то пытаюсь интуитивно по такому плану работать,

Відповісти
Підтримати
Natalia Riabokon
Andrii Shchurkov Senior Software Engineer 08.06.2020 15:15
по вопросам юнит тестов обращаться к Максу

Только с третьего раза понял, что это не к тому Маску

Відповісти
Підтримати
Natalia Riabokon
Ангуляров Реактин 08.06.2020 22:48

знаю одного «задавателя вопросов», продержался 2 месяца и уволили с комментарием «слишком много задаешь вопросов», нужно разбираться самому, и это был исключительный случай, т.к. на моей памяти еще никого не пинали по такому принципу

Відповісти
Підтримати
Natalia Riabokon
Ярослав Характерник Golang Developer в DocHQ 08.06.2020 02:26

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

Технології теж можуть бути застарілі.

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

Ефективний план ти можеш побудувати коли вже маєш досвід роботи то краще вибери собі комфортний ритм роботи і спокійно працюй.

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

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

З власного досвіду були ситуації що приходив на проект і 1-3 днів вчив щось за своїм бажанням, бо керівник був зайнятий якоюсь важливою задачою, і коли таке трапилось вперше то трохи переживав що потім будуть казати «а що ти робив увесь цей час?»
А на інших проектах було щось нове що відкривав відеоуроки чи конференції і вчився в робочий час.

Якщо ти вже налаштував проект і керівник каже що зайнятий то кажи, що або хай дає задачу або будеш вчити «назва технології».

Відповісти
Підтримати
Олексій Пєніє 08.06.2020 05:19
Зазвичай початківцям дають задачі на виправлення помилок

Але не тому що то просто, а тому що воно настільки складно, що ніхто не береться. Але за це не хвалитимуть, бо за планом то дуже просто та легко.

З компанії з такими «зазвичай» треба йти за першої ж нагоди, навіть без підвищення. Бо там можна втратити кваліфікацію та отримати дуже погану карму нізащо.

Виправлення помилок приблизно втричі довше написання коду заново. Бо потребує розуміти, що саме пішло не так, а для того треба знати всі аспекти того, як правильно. З коду вони не зрозумілі, лише з ТЗ та документації. Чи дали їх новачку — здогадайся. Чи дали на них час — сам скажи. Чи зрозумілі вони у відриві від інших документів проекту — сподівайся.
Тому навіть дрібна помилочка, що в автора зайняла б хвилин 15, коли правив би в той день, коли зробив — у новачка в кращому випадку займе місяць. Бо з великою вірогідністю ту помилку вже десь закостилили, сподівайся що нема костилів на стороні кастомера (які не працюватимуть після виправлення). Код без доків новачком читається ну дууууууже повільно. Як іноземна мова, де ти не знаєш 3 з 5 слів і дятел в темі розмови.

PS. Найсумніше, коли помилка не одна, а купа. І їх вже костилили по всьому коду, щоб пройшли тести.

Відповісти
Підтримати
Ярослав Характерник
Ярослав Характерник Golang Developer в DocHQ 08.06.2020 13:59

На другій своїй роботі в T4web з JS + PHP (перша робота була з Delphi) виправляв опечатки в функціоналі опитувань, виправляв прості помилки без написання нового коду, і десь через пару тижнів робив функціолнал по аналогії з вже існуючим: додавав нові поля у форми або додаткову логіку відправки листів і таких простих задач вистачало.

Але коли працював в T4web то було правило: «якщо вже 15 хвилин возишся то підходь і питай».

Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 08.06.2020 14:12

Ну, там просто було перевірити результат і відтворити помилку. Підкреслюю, якщо не костилили код.
Зараз би ті самі помилки завалилися на тестах одразу, їх би виправили ще при написанні тестів.

Відповісти
Підтримати
Ярослав Характерник
Ярослав Характерник Golang Developer в DocHQ 08.06.2020 14:25

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

Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 08.06.2020 15:22

В таких і персонал швидко змінюється, і дуже складно кудись влаштуватися після карми з цієї компанії, зазвичай всі відгуки від таких жорстко негативні. Бо ти «прєдал команду».

Відповісти
Підтримати
Ярослав Характерник
Denys Poltorak Embedded | C++ (opentowork) 09.06.2020 09:00

Ми вже 5 років (4 в продакшні) робимо телеком приблуду без тестів. Але команда маленька, а сусіди, що займаються управлінням роутерами, з тестами. Але багів в нас, здається, менше.

Відповісти
Підтримати
Олексій Пєніє
Леголас Трандуилович 09.06.2020 10:39

В смысле без тестов? Вообще без тестов или без Юнит-тестов? Хоть какой-то тест сетап у вас наверняка ведь должен быть? Или не дай бог живые тестеры.

Відповісти
Підтримати
Denys Poltorak
Denys Poltorak Embedded | C++ (opentowork) 09.06.2020 11:58

Вообще без тестов. Есть небольшое покрытие в рамках автотестов всего роутера (типа запустилось и позвонило туда-назад).
И да, все держится на живом тестере, который проверяет все отресолвленные задачи, включая баги (баг может бегать к тестеру и обратно несколько раз, в результате в названии одно, а в начинке — совершенно другое, обнаруженное при повторном тестировании) и на ассертах. Еще есть А/Б тестирование.

Відповісти
Підтримати
Леголас Трандуилович
Олексій Пєніє 09.06.2020 12:21

Є різниця — власний продукт чи аутсорс. Тести все одно є, але їх знааачно менше. І ключовий момент саме «команда маленька». І навряд чи у вас є

у нас швидко змінюється проект
Відповісти
Підтримати
Denys Poltorak
Denys Poltorak Embedded | C++ (opentowork) 09.06.2020 12:33

Ну як раз тести писати тут важко, бо дійсно зміни вглиб. Наприклад, останні півтора роки робили поліморфізм за залізом. При цьому автотести більш-менш вижили б (за винятком перейменувань в конфізі та CLI). А усі юніт-тести полетіли б, бо дофіга класів довелось розводити в ієрархію (телефон, від нього наслідується DECT чи FXS). Раныше там був просто DECT.

Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 09.06.2020 20:21

Тому методика тестування інша.
Яка справжня мета тестів: здешевшення контролю наслідків у великому масивному коді. Якщо код добре б′ється на модулі, якщо його читати легше, ніж писати тести, якщо його пишуть роками одні й ті самі люди — тести зайві. Багато з них знищується по мірі стабілізації коду — бо тести інвазивні, потребують тестової архітектури, і там дуже легко помилитися, запустивши на бойових даних якусь частини тесту, чи навпаки, пролити коди доступу в тестову архітектуру.

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

Автоматом тестують те, що простіше. Наприклад, тест оперативної пам′яті, якщо її небагато, найкраще робити щоразу у циклі POST, це збереже дані на носіях. Якщо багато — можна робити вибірково, намагаючись упіймати типові помилки, які можуть виникнути під час експлуатації — замикання, відсутність контакту, пошкодження добротності лінії передачі, завищення частоти, недостатня напруга чи її стабільність.

Відповісти
Підтримати
Denys Poltorak
Ангуляров Реактин 08.06.2020 22:53

а есть и такие компании, в которых тестами покрыто до половины кода, и скажу, они очень выручают, т.к. немало багов было отклонено еще на этапе CI/CD, раньше на тесты ложил с большй горы,а после проектов с таким покрытием тестами лично убедился в исключительной их полезности, и где их не используют — там говнокод или задачи, которые «надо было еще всегда вчера сделать»

Відповісти
Підтримати
Ярослав Характерник
Олексій Пєніє 09.06.2020 20:25
а есть и такие компании, в которых тестами покрыто до половины кода

Так говоришь, будто надо больше. Лучший тест — запрет вмешательства в то, что работает. Этим узлам тесты не нужны. И только когда изменения необходимы — приходится писать тесты, а если бы они уже были — то переписывать. То есть никакой выгоды.

PS. Если время, потраченное на написание тестов ради процента покрытия, потратить на перечитывание (и рефакторинг нечитаемого) кода — это будет лучше, чем куча непонятных тестов, которые тестируют что угодно кроме собственно потока данных.

Відповісти
Підтримати
Ангуляров Реактин
Євген Козлов Front-end developer в SoftServe 08.06.2020 02:04

окей, я так розумію, ніякого рамп-апа, тіммейти морозяться, або, що навіть гірше, просто закидали тебе мільонами посилань на джиру, конфлюенс, гугл доки та плейлисті на порнхабі, і з відчуттям «теперь все від нього залежить» розвернулись спиною. Я прав? Якщо так, то співчуваю, був в такому, то жопа.

Давай, подивимось, що в нас взагалі є.

1. технології(ну, це всі бібліотеки, концепції, архітектура, юніт тести я б сюди ж заніс)
2. домовленності(структура коду, код стайл, етк)
3. люди та комунікації(хто тестує баг, кого питати по тим питаннях, а кого по тим)
4. процеси(як саме заводити тікет, щоб нікого не бісити, як міняти статус етк)
5. енвайрномент локальний(як підняти локально)
6. енвайронмент(и) віддалені(доступ, контроль, логи)
7. скоуп робот(чи є у вигляді списка, чи лише в когось в голові)
8. пріорітети(хоча б — знати, в кого спитати, з ким узгодити)
9. domain area(нащо ви взагалі робите те, що робите — які проблеми бізнесу вирішує проект)

На мою думку, критично для старта розрулити питання 5 і 7.
Потім береш багу або сторі/функціонал(але за умови повного розуміння, як будеш її робити) і фігачишь.

Пункт 2 і 4 можна попершу робити «за прикладом того, що довкола».
Пункти 3 і 8 можна спершу взагалі рандомних тіммейтів питати. 6 і 9 трохи зачекають, то важливе, але для ефектвності. Спочатку і «не знаю, нащо їм оця кнопка тут, але сказали ж» прокатить.
Пункт 1 досить важкий, тут питання, чи ти там знаєш щось чи для тебе світч і по технологіям, тож не зрозуміло, з чого почати. Якщо щось вже знаєш, то буде поступово накопичуватись нові знання та досвід. Якщо не знаєш, краще б хтось накидав чек-ліст з оглядкою на потреби проекту.

Відповісти
Підтримати
Vova Adamenko 08.06.2020 10:13

Так — правий. Дякую — це приблизно те що я шукав.

Відповісти
Підтримати
Євген Козлов
Ваня 08.06.2020 11:51
закидали тебе мільонами посилань на джиру, конфлюенс, гугл доки та плейлисті на порнхабі

Іноді це вже дуже добре, був випадок, що дали посилання на те звідки стягнути проект і документ вордовський як його підняти(що далеко не тривіальне завдання було), точніше тільки як сервер підняти з 0 інфи по фронту(для якого по факту потрібно було ще один сервер підняти), яку потім окремо отримував в повідомленнях або при дзвінках з тими в кого то працює

Відповісти
Підтримати
Євген Козлов
Дима Дима 08.06.2020 01:07
почалась трудова діяльність

Підприємницька діяльність

Відповісти
Підтримати
Александр Шевченко 08.06.2020 00:49

Дают таску, делаешь.. что не понятно, гуглишь, не нагулил, спрашиваешь у тимлида. В чем проблема?

Відповісти
Підтримати
Євген Козлов Front-end developer в SoftServe 08.06.2020 01:48

предположу, что в ответе тимлида «а возьми себе что-нить из того длииииинного списка». Или «давай, позже, ща занят». Или даже «тыжпрофессионал, мы подумали, когда тебя брали, что сможешь и сам разобраться». и новичок в офиге от непонимания, за что хвататься в первую очередь.

Відповісти
Підтримати
Александр Шевченко
Олексій Пєніє 08.06.2020 05:21
Дают таску, делаешь.

Покажи мне хоть одного такого волшебника, особенно по цене «июня», да так чтобы в новом проекте (с глюками), да на технологии которую видит впервые.

Відповісти
Підтримати
Александр Шевченко
Vova Adamenko 08.06.2020 00:45

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

Відповісти
Підтримати
anonymous
Denys Poltorak Embedded | C++ (opentowork) 08.06.2020 00:55

1) На ввідний курс усім ліньки витрачати свій час. Зазвичай на проекті є якась вікі чи застарілі доки.
2) Зазвичай новачкам дають пару днів на розгортання проекту, а тоді, коли скомпілилось та запрацювало — можна йти до ліда й просити баги. Вже по конкретним багам — підходити з питанням, якщо нема сценарію з крешем, в котрому і так буде видно, де воно падає.
3) Буває, що менеджмент набирає джунів, щоб здерти з замовника більше грошей (платять за голово-часи), а реально в команду джуни не треба. Тоді — кепсько. Якщо не покажеш за 2 місяці, що можеш працювати самостійно (на рівні міда) — не пройдеш випробувальний період.

Відповісти
Підтримати
Vova Adamenko
Vova Adamenko 08.06.2020 01:00

Варіант за голово-часи, чому він кепський?

Відповісти
Підтримати
Denys Poltorak
Фрэнк Сайдботтом 08.06.2020 01:34

Тобі ж пояснили: ти Trainee/Entry-level, але ти повинен працювати на рівні Middle щоб пройти випробувальний період.

Відповісти
Підтримати
Vova Adamenko
Леголас Трандуилович 08.06.2020 12:09

Ну, якщо ти реально не потрібен не проекті ні зараз ні на виріст, а тільки щоб зайняти місце в «штатному роскладі», то в тебе в довгостроковій перспективі варіантів лише 2.
— ти самостійно навчишся бути там потрібен.
— ти звідтам звалиш, або самостійно або не дуже.
В будьякому разі намагайся взяти як умога білше за той час, що ти проведеш на тому проекті.

Відповісти
Підтримати
Vova Adamenko
Фрэнк Сайдботтом 08.06.2020 18:44
намагайся взяти як умога білше

І я б цю пораду сприймав не в сенсі крадіжок офісного паперу, а в сенсі навчання для досвіду.

Відповісти
Підтримати
Леголас Трандуилович
Леголас Трандуилович 08.06.2020 19:08

Ты знаешь, если других вариантов нету...
О! Кстати, надо бы заэкспенсить счета за спортзал и курсеру

Відповісти
Підтримати
Фрэнк Сайдботтом
Ярослав Характерник Golang Developer в DocHQ 08.06.2020 23:00

Так папір то $5, на одному з давніх проектів Senior PHP Developer з собою забрав крісло, бо спершу сказав що йде працювати в іншу компанію, потім офер відкликали і захотів залишитись, але вже CTO відмовив

Відповісти
Підтримати
Фрэнк Сайдботтом
Леголас Трандуилович 09.06.2020 10:41

Э... а как он кресло то из офиса вынес? До того как сказал что уходит или после.

Відповісти
Підтримати
Ярослав Характерник
Ярослав Характерник Golang Developer в DocHQ 09.06.2020 12:30
  • Senior-у компанія Undefined дала офер
  • Senior на початку грудня повідомив CTO що працює до кінця місяця
  • компанія Undefined відкликала офер
  • він повідомив CTO що залишається
  • CTO відмовляє
  • Останній робочий день Senior-а і забирає крісло з собою (офіс без турнікетів, охоронець біля шлагбаума, крісло легко вивезти через таксі)
Відповісти
Підтримати
Леголас Трандуилович
Yuriy Pavlenko Embedded Software Developer 09.06.2020 12:33

Взоржал. Измельчал синьйор... ))))

Відповісти
Підтримати
Ярослав Характерник
Ярослав Характерник Golang Developer в DocHQ 09.06.2020 13:13

Зараз то звісно вже його власність, але тоді крісло було власністю компанії, хоч техніку залишив компанії і монітор і то добре

Відповісти
Підтримати
anonymous
Ярослав Характерник Golang Developer в DocHQ 09.06.2020 14:10

Крісло ~$300, зарплата Senior-а на той момент $3000, просто відпустили цю ситуацію і все

Відповісти
Підтримати
anonymous
Denys Poltorak Embedded | C++ (opentowork) 09.06.2020 14:24

Та кому те б/в крісло треба

Відповісти
Підтримати
Леголас Трандуилович
Леголас Трандуилович 09.06.2020 14:55

Так говорю что странно что «апаратуру» не вынес.

Та кому те б/в крісло треба

Я вот прямо сейчас сижу дома на б.у. аэроне вынесенном с работы (с санкции начальства естественно по поводу короновирусного хоум офиса). Вот сижу и думаю — мне бы таки сгодилось.

Відповісти
Підтримати
Denys Poltorak
Леголас Трандуилович 09.06.2020 13:55
CTO відмовляє

shit happence.

Останній робочий день Senior-а і забирає крісло з собою (офіс без турнікетів, охоронець біля шлагбаума, крісло легко вивезти через таксі)

Ну красава, так их этих погонщиков! У вас наверно хорошие кресла.. и легкие :)

Відповісти
Підтримати
Ярослав Характерник
Ярослав Характерник Golang Developer в DocHQ 09.06.2020 14:15

Та компанія з хорошими умовами, і CTO був правий на мою думку, тоді навіть команда працювала без PM-а.

Просто коли жартують «що з офісу треба виносити щось хороше» то хтось серйозно сприймає ці слова.

Відповісти
Підтримати
Леголас Трандуилович
Natalia Riabokon rainha da lua в gamedev 09.06.2020 14:57
У вас наверно хорошие кресла.. и легкие :)

А сами виноваты, нечего искать для проекта «сильного программиста» :)

Відповісти
Підтримати
Леголас Трандуилович
Леголас Трандуилович 09.06.2020 15:05

На следующем собеседовании с ХР
— А какие ваши хобби?
— ну.. книжки читаю, литкод там на выходных гоняю.
— что-что гоняете?
— ну.. литкод
— а понятно, и это все?
— ну ещё в тренажерку хожу.
— а в тренажерку? Вы знаете, к сожалению в данный момент мы не можем Вам ничего предложить.

Відповісти
Підтримати
Natalia Riabokon
Олексій Пєніє 09.06.2020 20:31

Громким голосом:
— Тринажорка, иди сюда, мы тебе парня нашли.

Відповісти
Підтримати
Леголас Трандуилович
Олексій Пєніє 09.06.2020 20:29

Треба було викликати поліцію, і розповісти поліцайкам скільки бабла отримав сеньор за останній місяць. Щоб ім було зрозуміло, на скільки трусити «клієнта».

Відповісти
Підтримати
Ярослав Характерник
Леголас Трандуилович 08.06.2020 12:13
На моє запитання пояснити, отримав відповідь, типу розбирайся сам, роботи багато. Але мабуть я не настільки скіловий щоб розібратися, тому й запитую

Тоді задавай більш конкретні питання.
не «а як воно працює» а «Я поставив отту і отту фігню, але 1. не працює ото, 2. не розумію що і навіщо ото-от-третє». На питання «чому не працює ото» відповісти набагато легше ніж на «а як воно працює і які технології». І далі зробивши це буде ще легше задавати правильні питання і отримувати змістовні відповіді.

Відповісти
Підтримати
Vova Adamenko
Denys Poltorak Embedded | C++ (opentowork) 07.06.2020 23:07

Сусідів попитати

Відповісти
Підтримати
Олексій Пєніє 07.06.2020 19:37

А сама компанія не здатна відповісти? Я вже не кажу, чому нового гребця кидають на нову для нього технологію, коли моги взяти гребця саме з критерієм знання того, з чим доведеться працювати.

Відповісти
Підтримати
Vova Adamenko 08.06.2020 00:53

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

Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 08.06.2020 05:08

Нема. Те що правильний крок для одного проекту, є шкідливим для іншого. Особисто я б ризикнув робочим місцем та або витратив понаднормово час на RTFM (якщо є що читати), або шукав би того, хто може допомогти. Найвірогідніший варіант — швидкого шляху взагалі нема, тебе звільнять. Тому ти нічим не ризикуєш.

Якщо б у тебе був досвід, ти б не ставив таке питання.

PS. Дуже вірогідний варіант, що в страху очі великі. Може те що тобі дали взагалі потребує 1-2 дні на освоєння, а ти в паніку впадаєш. Бери перше ліпше джерело знань та пробуй.

Відповісти
Підтримати
Vova Adamenko

Підписатись на коментарі

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.