Senior Flash Engineer в Evolution Gaming
  • Эйчар-девочки: теория и практика происхождения

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

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

    підвішаних язиків іноді теж можна виводити на чисту воду, і задачки не всі в гуглі найдеш =)

    вміння читати по очах тут часто корисне — воно має бути у ейчара обов’язково, як математичні здібності у програміста чи слух у музиканта.

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

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

  • Эйчар-девочки: теория и практика происхождения

    я працювала на багатьох фірмах — львівські DevCom, Lohika, BLStream, Elex (для справедливості скажу — в їх eDesign-і), київські Daxx і нарешті best company ever — Cognianсe =)

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

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

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

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

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

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

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

    мій попередній проект був переписаний відсотків на 90 бекенд і 150 — фронтенд, постійно мав дублюючі і взаємносуперечливі баги, бо замовниці задорого було оплачувати менеджера, писати ТЗ, малювати вайфрейми, оплачувати фул тайм тестера, виділити 1 день на автоматизацію білдів %)

    Поддержал: Commandor
  • Эйчар-девочки: теория и практика происхождения

    лікування зубів не зробить тебе щасливим-здоровим-сильним, але не ходити до зубного тільки тому, що він хоче лікувати не той зуб, який в тебе, як тобі здається, болить — дурість =)

    платити зубному, який буде лікувати тобі той зуб, який ти скажеш — теж дурість )))

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

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

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

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

    автоматизація білдів — срібна куля? тестування — срібна куля? svn, jira... ні, це просто інструменти. без них переважно — ніяк, з ними — не факт, що теж не ніяк )))), якщо правильно ними не користуватись, і то може вийти ніяк)) — бо всеодно ще ж і кодати треба.

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

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

  • Эйчар-девочки: теория и практика происхождения

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

  • Эйчар-девочки: теория и практика происхождения

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

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

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

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

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

    Поддержали: Marina Sokhn, Iurii Potehin
  • Эйчар-девочки: теория и практика происхождения

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

    як журналісти умудряються проводити свої незалежні повноцінні розслідування різних інцидентів?

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

    от тут якраз робота HR — бачити всі ці фактори (навіть не розуміючи їх і не знаючи в деталях), розуміти/виясняти, на скільки кожен з них впливає на загальну ефективність, і вже на скільки в межах «свого фактору» ефективно працює конкретна людина. звучить це все дуже складно, але на практиці це значно простіше, і не потребує аж надто великих зусиль. просто іноді потрібен «погляд збоку», не технічний і глобальний. так само, як програміст не може (навіть при всьому чесному бажанні) ефективно тестувати свій продукт, так само технар не може глобально бачити ефективність роботи компанії.

    і це окрема робота — старатись виявляти якісь тонкі характеристики людей, які потенційно можуть бути ефективними в роботі на даній конкретній фірмі (підкреслюю!).

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

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

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

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

  • Эйчар-девочки: теория и практика происхождения

    я завела свій блог по AS і його тепер рідко підтримую :(, мені ще на ДОУ закинутої колонки не вистачало )))) - собака без вигулів здохне )))))

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

  • Эйчар-девочки: теория и практика происхождения

    мені недавно в блогу доводили, що ефективність співбесіди — 20% і що тільки випробувальний термін — єдиний вихід. пост я якраз про співбесіди і писала, тут про не них писати хочу, а про інше: на практиці співбесіди проводять технарі, виключно по технічних моментах, після яких такі важливі речі, як конфліктність людини, вміння освоювати нову інформацію, швидко шукати потрібні рішення, працювати в команді, алгоритмічне і «ооп-паттернове» мислення і т.п. лишаються невідомими. тобто дійсно маєм 20% дієвості інтерв’ю. але на тій же практиці після випробувального терміну майже нікого не звільняють — це дорого: знову шукати нову людину, вже проведена і оплачена робота по введенні людини в проект, заведення екаунтів і роздача прав і т.д.

    тобто маєм процес: неправильно поставлений (фактично HR-івський) процес з ефективністю в 20% і важке дороге розгрібання його наслідків, але всеодно повне небажання запровадити якийсь дієвіший підхід, бо він «в наших реалиях может быть губителен»

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

    і так відбувається у всьому, що стосується HR в ІТ.

  • Эйчар-девочки: теория и практика происхождения

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

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

  • Эйчар-девочки: теория и практика происхождения

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

    робота в них така — працювати з ефективністю людей не залежно від їх спеціальностей.

    Поддержал: Святослав Люшня
  • Эйчар-девочки: теория и практика происхождения

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

    Поддержали: Petya Mas, RredCat, Stas Dovgodko
← Сtrl 1... 345678 Ctrl →