dou.ua :: коментар - чому не дивляться мій GitHub

 

Disclaimer: я лише з пару разів співбесідував, і то, лише початківців, і навіть не на продакшн проекти, тож мій досвід дуже обмежений.

Пріоритети

1. Теорія, досвід - багато практики (це одна з причин для чого Вам може бути потрібен Ваш проект на github)

2. Якісна підготовка до співбесіди

3. У тому числі - лайв кодінг

4. github (хоча, якщо у Вас є дуже важливий для Вас хобі проект і Ви шукаєте якогось особливого роботодавця/проект схожого/пов'язаного напрямку, то пріоритети можуть бути іншими, тоді це пункт 2)

Clean code, читабельність

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

але, власний проект має цінність, якщо код readable/clean, та має лаконічну адекватну документацію (не має її там, де вона не є необхідною), нормальне форматування.

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

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

ось, наприклад, недавно, людина пише на DOU про своє резюме:
"зробив акцент не на «розробляв компоненти», а на тому, що саме зробив і як це працює."

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

Рев'ю

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

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

AI

або ж, згодуйте шматки коду ШІ, щось на кшталт
Clean code. Typescript. What wrong with this code?
але теж - обережно з цим, не впевнений що воно завжди дасть адекватну пораду, або зайву.

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

проблема в тому, що зовсім не не факт що запропонований ШІ код буде кращим або clean.

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

Приклади з книжок, open source проектів, офіційних сайтів

Manning, O'Reilly, APress/Springer, Manning, No Starch, Pragmatic Programmer, Packt, тощо ...

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

буває, що автори книжок публікують безкоштовні туторіали.

і, мабуть, ще краще - переглянути на github/etc. source code відомих відкритих проектів.

якщо є, то якісь з проектів того ж Mic**soft-а або якогось відомого фреймворку (але, знову ж таки, там де є широко вживаний публічний API, коментарів буде набагато набагато більше, ніж на звичайних продакшн проектах в коді без публічного API).

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

але, обережно, дуже бажано без фанатизму. використовуйте Ваш common sense.
якщо намагатися досягти ідеалу, то можна взагалі ніколи не завершити проект і ніколи не влаштуватися на роботу)

Співбесіда

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

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

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

з іншої сторони - на справді "просунутих" проектах Ваші завчені відповіді можуть мало зацікавити, бо вони дають лише обмежене уявлення про Вас. а от код може бути якраз "те" що треба і підґрунтям для розмови (ну, якщо його писав не ШІ).

на останній моїй співбесіді (думаю, просто звичайний проект) теж ніхто не запитав про мій github (але, у мене там і немає зараз проектів "для показу", лише хобі).

ще, буває на співбесіді online/live coding... але, це теж напів-міра, бо деякі набивають руку на leetcode. втім, тут можу помилятися, не користувався leetcode.

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

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

P.S. посилання на DOU