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

Доброго дня.

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

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

LinkedIn

Лучшие комментарии пропустить

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

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

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

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

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

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

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

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

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

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

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

З написання теми на Доу. (Done)

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

з чого почати

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

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

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

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

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

Ставишь гита, стягиваешь проект, разворачиваешь среду, собираешь и запускаешь, смотришь, что как-то работает. Затем идешь к начальнику и говоришь, проект запустился и как-то шевелится — давай задачи. Начальник тебе в жиру накидывает задачек и ты начинаешь их делать, попутно не понятные места спрашивая у начальника и коллег.

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

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

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

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

Человеческая дурь безгранична © Энштейн.
Но если ты в хотя бы 50% контор, куда приходишь работать, на подобное нарываешься, то в этом случае нужно уже искать проблемы в себе.

Ставиш FileZilla, підключаєшся, відкриваєш папку prod, модифікуєш index.php, дивишся як зміни ефектяться на проект. Потім йдеш до керівника і кажеш, я підключився, давай задачки. Керівник тобі в скайпі кидає задачки, і ти їх починаєш виконувати, не забуваючи ділянку коду яку пишеш обгорнути в if($_SERVER['REMOTE_ADDR'] == "твій айпі адрес") { тут твій код }. Після виконання видаляєш цю обгортку коду і повідомляєш клієнта що ти все зробив. Не бійся якщо весь сайт впаде. З першого разу не завжди виходить.

Это я про что-то из 90-х читаю? Хотя... Скайп — это уже из совсем последних десяти лет.

Це я так починав! На ру фрілансі. Правда у продвинутих клієнтів була система копіювання змін вручну на бета сервер(я казав які файли змінив). А загалом, на проді воно веселіше кодиться!

На ру фрілансі

Это надо было первым предложением в посте выше писать.

Та то я по пріколу написав там.

Ты уж должен знать, что приколы и сарказм тут давно не отличимы от не приколов и не сарказма. Тут чаще вообще просто бредят.

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

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

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

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

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

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

А де тримаєте файлик? Можна в репозиторії на гітхабі(або вотевер), в форматі .md. Таким чином легше апдейтити файл без ризику щось не те витерти.

www.markdownguide.org/basic-syntax

Дока по формату. Зручно форматувати.

по вопросам юнит тестов обращаться к Максу

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

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

Если он по 10 раз задавал один и тот же, то ничего удивительного.
Но могли просто сильно своеобразные люди на конторе собраться — в этом случае челу повезло, что уволили, если сам послать их боялся.

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

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

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

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

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

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

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

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

Зазвичай початківцям дають задачі на виправлення помилок

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

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

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

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

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

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

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

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

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

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

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

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

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

у нас швидко змінюється проект

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

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

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

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

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

а есть и такие компании, в которых тестами покрыто до половины кода

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

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

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

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

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

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

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

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

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

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

почалась трудова діяльність

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

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

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

Дают таску, делаешь.

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

Выше написано делаешь, а не сделал.

гм, не було такого. Яка складність ?

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

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

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

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

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

намагайся взяти як умога білше

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

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

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

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

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

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

Так а чого своє крісло лишати комусь? Він же ж не власність галери виніс?

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

Жесть. А в суд не можна отримати позов за таке? Це ж як крадіжка.

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

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

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

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

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

CTO відмовляє

shit happence.

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

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

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

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

У вас наверно хорошие кресла.. и легкие :)

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

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

— ну ещё в тренажерку хожу.

— В тренажерку? Для нашей роли вы должны похудеть.

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

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

От це тема. Підзаробили б і поліцейські, і галера б крісло повернула.

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

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

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

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

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

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

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

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

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

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