Наскільки важливо бути синтаксично правильним під час співбесіди? [зачинено]


40

Просивши кандидата на співбесіду написати програму на дошці, чи очікуєте ви кандидата написати код, який синтаксично правильний?

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

Я виступаю за першого кандидата.


75
Ваш вибір має сенс, якщо ви очікуєте їх кодування в Блокноті, я думаю.
Бенжол

20
Як може бути неправильним синтаксис псевдокоду? Або ти просиш їх написати якоюсь реальною мовою?!?
SK-логіка

6
Залежить від опису завдання… редактор копій?
Конрад Рудольф

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

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

Відповіді:


125

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

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

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


6
+1, але іноді це гідний показник того, наскільки комфортно комусь у певній мові. Особисто я ніколи не надавав цього великої ваги (напевно погоджуюся, що алгоритм є важливим), але це не шкодить.
Дем'ян Брехт

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

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

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

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

46

Я би віддав перевагу другому кандидату. Логіка може бути важкою ( дуже важкою, іноді) отримати точно правильно. Синтаксис може бути дуже простим, коли допомогти IDE, компілятору та іншим різним інструментам.

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


1
Саме так. Ви можете навчити синтаксису (особливо, якщо вони вже знають якийсь інший синтаксис). Ви не можете навчити звукові міркування майже так просто.
Трид

19

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

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

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

Як дещо штучний приклад, щоб зрозуміти крапку: розглянемо програміста python, який префіксує всі свої змінні $, або записує for-loop як for list as item. Технічно обидва є синтаксичними помилками, але навіть при обмеженому впливі на python слід знати, як щодо юридичних символів та циклу for. Добре було б здогадатися, що кандидат знає php (чи perl?) І намагається блефувати щодо своїх навичок пітона


15

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


15

Я пишу SQL та CSS (найпростіші та основні мови, які я знаю) майже 13 років, і не завжди можу запам’ятати синтаксис.

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

Ми обидва потрапили на W3CSchools , я думаю, нас слід збентежити (він має ступінь, а я доктор наук).

Однак, якщо чесно, я вважаю, що наші пріоритети є правильними. Синтаксис - не важливий навик.


13

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

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

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

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

Я думаю, що тут я думаю, що синтаксичні помилки допустимі в межах.


5

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


5

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


5

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


5

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

Крім того, ваші очікування щодо ідеального коду (на дошці!) Можуть не відповідати інтерв'юерам - наприклад, на одному з інтерв'ю, яке я відвідував, мене попросили написати клас, що я і зробив, лише для того, щоб інтерв'юер міг би мене не ставити у конструкторі копій. Тож я написав один в, який нічого не робив, але встановив a = b, але цього було достатньо, щоб його задовольнити. Мої очікування проблеми не вимагали копію копії, тому я залишив це стороннім шляхом вирішення проблеми - я не очікував, що доведеться писати повністю сумісний, компілюючи код (до його прихованих стандартів кодування), просто показати моє розуміння рішення. (цьому ж інтерв'юєру не сподобалось і моє рішення. Це було не так, як він би зробив це так, очевидно, я зрозумів це неправильно, зітхаючи).

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

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


3

Під час інтерв'ю інтерв'юер більше зацікавлений бачити вашу

  1. Підхід до проблеми
  2. Навичка, що використовується для вирішення проблеми та
  3. Час, необхідний для ефективного надання правильного рішення

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

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

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

Більше того, може бути доступний IDE, який міг легко створити синтаксис навіть будь-якого у належній формі. Але користуватися яким методом, де і коли, а головне ЧОМУ , було б відомо хлопцеві лише з належною логікою та знаннями фактичного предмета.

Сподіваюсь і закликаю вас надати щось більше, ніж біла дошка чи блокнот для написання коду.

Я б пішов з другим кандидатом. ..


2

Ну, а деякі люди хочуть великих розробників Java, чудових розробників C #, чудових розробників C ++ і т. Д. Якщо це так, тоді вам подобається потужність A і більше. Я б мав занепокоєння, якщо вони не зможуть вирішити проблему, як ви можете розраховувати на їхнє вирішення та вирішення ваших бізнес-проблем?

Інші люди просто хочуть чудових розробників, які можуть працювати будь-якою мовою. Вони думають / моделюють проблему, а потім реалізують її будь-якою мовою. Якщо ви раптом вирішите .NET смокче і переходить на Java або навпаки, це ті розробники, які не скачуть корабель і не відмовляться вчитися. Крім того, якщо ви отримуєте певний тип пакета автоматизації / розрахункового пакету, який має власну мову і вам потрібні деякі завдання автоматизовано, це типи розробників, які можуть це зробити. Приклад із реального життя ... Мені потрібно було розробити власну власну мову скриптів для програмного пакету для картографування, щоб отримати старі роботодавці поштові індекси для областей, намальованих на замовлення. Ще один приклад .... мій поточний роботодавець має власну систему управління майном, яка містить власну мову для написання звітів ... У будь-якому випадку,

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

Також знання кількох мов може працювати проти вас. C # і Java мені заважають. Але знання кількох мов також може розширити вашу перспективу, особливо якщо ви знаєте мову сценаріїв та функціональну мову на додаток до C # / Java.

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

Тим не менш, якщо хтось претендує на досвід експертів у Java і не може оголосити масив використання оператора if або циклу, він може брехати. Але я можу зрозуміти, якщо хтось є експертом у Java, але останнім часом робив багато C # і намагається зробити Map чи щось подібне .... Також якщо ви потрапляєте в специфіку бібліотеки, або хтось робить myArray.length замість myArray .Length або string.length () / string.Length / string.length замість string.length () ... Незначні речі я б пробачив. Або якщо вони забудуть порядок аргументів якогось виклику бібліотеки. Або друкарська або напівкрапка тут чи там ....


1

Я не візьму жодної з них.

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

У будь-якому випадку логіка набагато важливіша за синтаксис.


3
Я ніколи не пам'ятаю жодних деталей синтаксису навіть мов, які я створив сам. І я не пам’ятаю синтаксису мов, якими я користувався також десятиліттями. Це зовсім не проблема, я завжди можу це шукати, у мене є надрукований BNF для всіх мов, якими я користуюся. Синтаксис - найменш важлива частина будь-якої мови, семантика - спосіб набагато важливіший.
SK-логіка

@ SK-логіка: Я цілком погоджуюся, але занадто багато разів хлопці приходили сюди, кажучи, що вміють програмувати на мові xxx, тоді вони навіть не змогли згадати, потрібні крапки з комою чи ні. Вивчити синтаксис нової мови досить просто, але якщо я шукаю когось, хто вільно володіє певною мовою, він повинен бути таким. Крім того, я вже вказував, що логіка набагато важливіша за синтаксис.
Хосе Фаети

1

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

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


1

Це, безумовно, залежало б від посади, на якій опитується інтерв'ю, і, мабуть, і від мови.

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

Щоб відповісти на ваше запитання, тоді:

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

Є лише одне застереження: люди визнають відсутність досвіду. В ідеалі люди повинні кодувати своєю мовою на вибір або псевдокодом, якщо вони цього бажають (наприклад, студенти).


1

Правда, я все ще забуваю синтаксис подій C #, коли мені доводиться їх виписувати вручну. Буває в інтерв'ю іноді. У мене немає проблеми, коли я кодую на клавіатурі.

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


0

Коли я пишу код на папері / дошці, навіть для співбесіди, я в основному пропускаю величезний фрагмент синтаксису. Я не використовую напівколонок, я підбираю виклики методів і т. Д. Я швидше за все пишу речення, що пояснюють 4 рядки дійсно базового коду, ніж сам код. Дійсно, я використовую псевдокод, схожий на php, і розмовляю над тим, що я роблю, поки це роблю, і записую швидкі коментарі, щоб пояснити речі, за якими я замовчуюсь (які, теоретично, нічого, що насправді важливо для програма)

Моя мета при кодуванні в інтерв'ю - показати, як я вирішую проблему, а не диктувати те, що машиністка могла б увійти в Блокнот і запустити.

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


0

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

Друга особа може бути або не бути кваліфікованою залежно від типу та кількості помилок та складності того, що ви очікуєте від них. У термінах SQL (мовою, якою я пишу) особа, яка не може запам'ятати синтаксис для явного приєднання, не кваліфікується для роботи, яка вимагає від вас запиту бази даних - не виняток; той, хто не може пригадати, як перемогти CTE (але хто знає, що вони існують і намагається його використовувати), це не так. Іншими словами, я б очікував, що синтаксис буде більш правильним для основного коду, який ви постійно пишете, але не для речей, які виконуються лише зрідка, а не для складного синтаксису.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.