Що стосується мов програмування як суворих вимог до роботи? [зачинено]

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

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

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

Скажімо, я вже знаю Java, C ++, Smalltalk та Prolog ... чи справді робоче місце, яке покладається на Objective-C, вважає мене некваліфікованим, оскільки мені не вистачає досвіду з цієї мови? Чи є це недоліком у підборі методологій, і якщо він є, що я можу зробити, щоб переконати це робоче місце, що моя відсутність досвіду роботи з «Ціллю-С» не повинна мати значення? Я запитую гіпотетично, а не конкретно про згадані мови програмування.

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

На відміну від прес-релізів, це зараз ринок роботодавця .

Це означає, що вони можуть бути просто прискіпливими до своїх вимог. Це означає, що вони можуть вимагати досвіду .NET 4.0, а не лише 3,5 досвіду ... Це означає, що вони можуть вимагати досвіду роботи з Django, а не лише з Pylons тощо.

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

Але роботодавець може вибрати резюме людей, які вже володіють Ruby & Rails.

TL; DR: Econ 101 ... Не вірте шуму щодо дефіциту програмістів .

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

Враховуючи велику купу резюме, було б дуже приємно мати можливість прочесати їх і вибрати хороших програмістів, але ніхто не знає, як це зробити. Спосіб роботи більшості компаній, початковий сорт, як правило, здійснює HR. Людина з персоналу нічого не знає про Smalltalk або C ++, за винятком випадків, зазначених у списку вимог, на відміну від програмного забезпечення, який може подумати "C ++ AND Smalltalk - цей хлопець не матиме проблем з Objective-C".

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

Давайте розвернемо це - якби ви знали об'єктив C, чи не використовували б ви програміста на C ++? Я б сказав, ні, ви б цього не зробили, мови занадто різні. Навіть для таких простих мов, як C, я хотів би побачити досвід роботи 6 місяців, перш ніж когось найняти, протягом C ++ - кілька років.

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

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

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

Якщо ви можете кодувати імперативом, ви можете кодувати імперативом. Будь то Java, C #, C, C ++ або навіть javascript. З огляду на гідний довідник (і, можливо, трохи котла), ви повинні мати можливість вибити невелику програму в будь-якому з інших у другій половині дня.

Незалежно від вашої історії, ви знаєте про гілки та функції циклів, і синтаксис майже однаковий для всіх. Якщо ваша історія є OO, ви також знаєте про об'єкти, класи та інтерфейси.

Однак я бачив занадто багато імперативних програмістів, які намагаються писати прості програми декларативними або функціональними мовами. Якби я керував магазином Erlang, я б наголосив на тому, щоб хтось із Erlang, або принаймні Prolog, мав досвід когось із C ++.

Як це залежить від рівня ролі:

Рекрутинг на молодшу роль:

Якби я вибирав програміста для роботи на C ++, є певні підводні камені, які я б хотів бути впевненим, кандидат може уникнути, як, наприклад, необхідність звертати увагу на пам'ять або довжину масивів, просто так, щоб вони Не стріляй собі (і мені) у ногу. Якщо вони ніколи не робили C або C ++, то мені доведеться це попрацювати в інтерв'ю.

А для старшої ролі:

Одним із ключових завдань ефективного програмування є знання того, що не слід писати самостійно. Ключовим для цього є стандартні (і фактично стандартні) бібліотеки. Ключовим для цього є досвід. Ви не можете просто тиждень сидіти з "Навчіть себе Java" і миттєво перетворюєте себе з 10-річного програміста C ++ на 10-річного програміста Java.

Як це залежить від стану проекту / компанії

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

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

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

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

Наймати важко; наймати хороших людей ще важче. Я взяв на роботу там, де зіткнувся зі штабелем із понад 500 резюме. З cousre ми відфільтрували людей з найменшим досвідом у тому, що ми хотіли отримати стопку до розумного розміру. Чи справедливо це до відмінного кандидата, який, звичайно, не знає цієї мови, мабуть, ні. Але якщо я можу знайти 100 людей, які мають кваліфікацію, яку я шукаю, я дійсно не збираюся витрачати багато часу на тих 400, хто цього не зробив - незалежно від того, наскільки вони хороші.

Зараз у наймі, у мене може бути довгий перелік вимог, але зазвичай лише один або два є вимикачами. І якщо ви не знайдете когось із початковим списком кваліфікацій, які ви хочете взяти на співбесіду (або пізніше, якщо всі вони пройдуть інтерв'ю, яке я бачив) з менш критичної кваліфікації або людей, які мають щось подібне, але не те саме. У таких випадках ви часто шукаєте щось про досвід людини, що зробить їх кращими для вашої роботи, ніж когось із усіма технічними кваліфікаціями. Наприклад, я б розглядав аналітика даних, що має досвід роботи в іншій базі даних підприємств, якби вона мала досвід у моєму бізнесі (адже ця людина, мабуть, зробила б перший зріз, якби побачила всі резюме). Те ж саме з C # та Java. Якщо людина працює з подібним рівнем складності і особливо в подібній діловій сфері, вони можуть бути дуже хорошим кандидатом, навіть якщо вони володіють іншою мовою.

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

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

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

Чи слід? Ні . Чи має це? Так, на жаль. Це синдром "фіолетової білки": Компанія хоче випити їх торт і з'їсти його, і отримати кандидата, який може робити все під сонцем, що їм потрібно чи може знадобитися. Часто, але не завжди це відбувається тому, що вони або А) не мають поняття, що розвиває насправді, і просто припускайте, що хтось, що відповідає всім їх критеріям, може зробити цю роботу, B) Вони вибагливі, тому що можуть втекти від цього, або C) Вони планують подати H-1B / Зелену карту / просувати зсередини, але повинні зробити так, щоб вони рекламували справжню роботу.

"Скажімо, я вже знаю Java, C ++, Smalltalk та Prolog ... чи справді робоче місце, яке покладається на Objective-C, вважає мене некваліфікованим, оскільки мені не вистачає досвіду цієї мови?"

Якщо у вас є 20+ років досвіду роботи на 3-х чи 4-х мовах, які мають схожі функції з Objective-C, то я, мабуть, найму вас зробити Objective-C і очікую, що ви будете продуктивними через 6 - 8 тижнів. (це ґрунтується на моєму особистому досвіді вивчення об'єктива-C кілька років тому).

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

Objective-C - тут цікава солом’яна людина. Це вимагає, щоб ви дуже добре знали C, це вимагає, щоб ви добре знали об'єктно-орієнтований аналіз та дизайн, в більшості випадків вимагаєте, щоб ви знали C ++ нетривіально, оскільки є бібліотеки C ++, з якими ви, ймовірно, захочете взаємодіяти.

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

Це не лише Objective-C. Ви також повинні знати какао та POSIX, тому що вирішувати це, об'єктив-C для всіх практичних цілей марний за межами середовищ Apple, і ви також повинні знати какао.

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

Це також означає, що ви повинні знати Unix до певної нетривіальної міри.

Залежить від мови / особистості.

Якщо я є місцем C # і хтось із досвідом JAVA / J2EE застосовується, я зроблю знімок. Синтаксис між C # & JAVA НЕ НАДІЙ інший. Кодування - це кодування, і я вважаю, що коли вони звикають до деяких відмінностей, вони будуть добре.

Те саме стосується і JAVA -> C #.

Тепер, якщо ви були особою C # і ви подавали заявку на роботу на C ++, я хочу побачити досвід. Занадто багато відмінностей.

Так що, це залежить від ситуації

Хоча я думаю, що ОП мертвий щодо того, як програміст, який має багато парадигм, може легко додати ще одну, все це зводиться до відмови роботодавця до ризику. Потенційний прокат, який не знайомий із їхніми інструментами, - це wild card; вони можуть бути справді чудовими, але вони також можуть бути флопом, і інтерв'юєру буде важче сказати різницю, якщо вони не зможуть глибоко задати питання про технології, якими вони користуються.

Я точно не кажу, що це правильний погляд на це, але це так, як це роблять деякі роботодавці. Розумні використовують це і збирають дивовижних програмістів з 30-річним досвідом роботи на C ++, а дурні відмовляються від них, оскільки їм не вистачає необхідних 15 років досвіду Ruby on Rails. Програмісти можуть і цим скористатися, уникаючи працевлаштування з роботодавцями, які так погано інформуються. Зрештою, хто хоче працювати на місце, яке систематично приймає погані рішення щодо найму?

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

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

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

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

Просто, щоб навести конкретніший приклад щодо цього середовища, ось що у мене там, де я працюю: Visual Studio 2008 робить ASP.Net, використовуючи в основному C #, nUnit, Cruise Control.Net, Subversion, Agile / Scrum, із сумішшю процедурних, О.О. і функціональний залежно від того, куди хто дивиться. Якщо я хотів перейти на Java, це може означати звикання до нових інструментів для багатьох цих функцій, що може бути не тим, що працедавець хоче взяти на себе, як вартість найму мене на цю роль. Також можуть бути деякі хитрі моменти, що ті, хто має досвід у цій версії, можуть знати краще за інших та уникати деяких підводних каменів, які в іншому випадку можуть змусити когось піти: "Чому вони так побудували?"

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

Так вони кажуть "Що вам потрібно?" а випадковий шматок, який опиняється у відповіді, каже: "Програміст. Потребує кількарічного досвіду. Мовляв, я не знаю, 4? І було б добре, якби він знав. Ні". Розумна відповідь.

Але це перекладається на "4-річний досвід роботи в .Net 4", і це. NET 4, оскільки, коли ви Google .Net, перше посилання перенесе вас на сторінку, в якій йдеться про .Net 4.

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