Насколько важно быть синтаксически правильным во время интервью? [закрыто]

Когда вы просите кандидата на собеседование написать программу на доске, ожидаете ли вы, что кандидат напишет код, синтаксически правильный?

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

Я поддерживаю первого кандидата.

Я бы предпочел человека, который смог решить проблему, найти хорошее решение, а затем объяснить мне свое решение. Даже если бы их логика не была на 100%, если они были на правильном пути и продумывали проблему, задавали правильные вопросы и шли по правильному пути, это было бы моим победителем.

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

Мой единственный вопрос к вам: почему ваши кандидаты пишут настоящий код на доске вместо того, чтобы сосредоточиться на алгоритмах, стратегиях проектирования и логическом мышлении? Языки программирования меняются, а решение проблем - нет.

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

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

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

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

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

В качестве несколько искусственного примера, чтобы понять суть: рассмотрим программиста на python, который ставит перед всеми своими переменными префикс $ или записывает цикл for как for list as item. Технически, оба являются синтаксическими ошибками, но даже при ограниченном воздействии на python нужно знать как о допустимых символах и цикле for. Было бы неплохо догадаться, что кандидат знает php (или perl?) И пытается блефовать о своих навыках Python

Я бы предпочел второго кандидата, исходя из теории, что доска имеет большее влияние на синтаксис, чем на логику, и что ошибки в синтаксисе легче исправить - обычно это может сделать IDE или компилятор.

Я пишу SQL и CSS (самые простые и простые языки, которые я знаю) в течение почти 13 лет, и я не всегда могу вспомнить синтаксис.

Мой друг (также разработчик) работает в хедж-фонде, он никогда не может вспомнить синтаксис оператора вставки.

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

Однако, честно говоря, я считаю, что у нас правильные приоритеты. Синтаксис не является важным навыком.

Несколько мыслей о синтаксических ошибках ... Мне было интересно, если вы ясно дали понять обоим, что синтаксис должен быть правильным. Иногда люди предполагают, что псевдокод в порядке.

Кроме того, если кто-то претендует на многолетний опыт работы с языком и не может сделать правильный синтаксис правильным, вы должны усомниться в этом утверждении.

Синтаксические ошибки могут различаться, поэтому, если кто-то забывает имя метода, это нормально (для меня), но если кто-то не знает, как ссылаться на метод в классе (точечная запись), или не знает базового мышления, такого как синтаксис для простой класс, то есть вероятность, что этот человек не использовал язык в течение длительного времени.

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

Я думаю, что я думаю о том, что синтаксические ошибки допустимы в определенных пределах.

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

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

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

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

Кроме того, ваши ожидания в отношении идеального кода (на доске!) Могут не соответствовать интервьюерам - например, на одном интервью, которое я посетил, меня попросили написать класс, который я сделал, только для того, чтобы интервьюер подтолкнул меня к тому, чтобы я не ставил в конструкторе копирования. Поэтому я написал один, который ничего не делал, кроме как установил a = b, но этого было достаточно, чтобы удовлетворить его. Мои ожидания в отношении проблемы не требовали копирования ctor, поэтому я оставил это как постороннее решение проблемы - я не ожидал, что мне придется писать полностью совместимый, компилирующий код (в соответствии со стандартами скрытого кодирования), просто показать мое понимание решения. (этому же интервьюеру тоже не понравилось мое решение, это было не то, как он это сделал, очевидно, я ошибся, вздох).

Если вы хотите рабочий код от собеседника, дайте им компилятор. Тогда не жалуйтесь, когда вам выставляют счет :)

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

Во время интервью интервьюер больше заинтересован в том, чтобы увидеть

1. Подход к проблеме
2. Навык, используемый для решения проблемы и
3. Время, необходимое, чтобы эффективно дать правильное решение

Хотя синтаксис не так важен, но он занимает видное место при решении проблемы, с большими ошибками в синтаксисе, которые вы не можете ожидать, чтобы впечатлить интервьюера.

Правильная логика и синтаксис, объединенные вместе, могут помочь вам в интервью.

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

Более того, может быть доступна IDE, которая может легко создать синтаксис любого в правильной форме. Но использовать какой метод, где и когда, а главное, ПОЧЕМУ , будет известно только парню с правильной логикой и знанием реального предмета.

Я надеюсь и призываю вас предоставить что-то большее, чем белая доска или блокнот для написания кода.

Я бы пошел со вторым кандидатом. ..

Ну, некоторые люди хотят отличных разработчиков Java, отличных разработчиков на C #, замечательных разработчиков на C ++ и т. Д. Если это ваш случай, используйте A и больше возможностей для вас. У меня есть одна проблема: если они не могут рассуждать, чтобы решить проблему, как вы можете ожидать, чтобы они рассуждали и решали ваши бизнес-проблемы?

Другие люди просто хотят отличных разработчиков, которые могут работать на любом языке. Они думают / моделируют проблему, а затем реализуют ее на любом языке. Если вы вдруг решите, что .NET отстой и переключитесь на Java или наоборот, это разработчики, которые не будут прыгать с места или отказываться учиться. Кроме того, если вы получаете какой-то пакет автоматизации / пакет вычислений, который имеет собственный язык, и вам нужно автоматизировать некоторые задачи, это типы разработчиков, которые могут это сделать. Пример из реальной жизни ... Мне нужно было найти собственный проприетарный язык сценариев для картографического пакета программ, чтобы извлечь почтовые индексы для пользовательских областей для старого работодателя. Другой пример .... у моего нынешнего работодателя есть собственная система управления собственностью, которая содержит собственный язык для написания отчетов ... В любом случае,

Также на белой доске есть дополнительное давление / нервозность, поэтому никто не в своих лучших проявлениях. Кроме того, я очень сомневаюсь, что при кодировании вы получаете его идеально каждый раз. Я подозреваю, что вы компилируете или просто запускаете и обнаруживаете некоторые ошибки. Кроме того, это зависит от языка. C достаточно мал, чтобы вы могли запомнить большинство библиотек языка / ядра (хотя я бы этого не потребовал). Java / C # имеют такие огромные библиотеки (с такими частыми изменениями), что о запоминании библиотеки не может быть и речи.

Также знание нескольких языков может работать против вас. C # и Java мешают друг другу. Но знание нескольких языков может также расширить ваши перспективы, особенно если вы знаете язык сценариев и функциональный язык в дополнение к C # / Java.

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

Тем не менее, если кто-то утверждает, что является экспертом по Java и не может объявить массив использования оператора if или цикла while, он может лгать. Но я мог бы понять, если кто-то является экспертом по Java, но в последнее время много занимался C # и пытается сделать Map или что-то в этом роде ... Также, если вы разбираетесь в особенностях библиотеки, или кто-то делает myArray.length вместо myArray .Length или string.length () / string.Length / string.length вместо string.length () ... Незначительные вещи, которые я бы простил. Или, если они забывают порядок аргументов некоторого библиотечного вызова. Или опечатка / точка с запятой здесь или там ....

Я не возьму ни одного из них.

Хороший синтаксис бесполезен, если программист не силен в решении проблем. А плохой синтаксис для данного языка означает, что кандидат не чувствует себя комфортно с этим конкретным языком, возможно, из-за отсутствия прямого опыта.

В любом случае логика намного важнее синтаксиса.

Это, как всегда, зависит. Если синтаксические ошибки относительно незначительны, я бы их проигнорировал. Если они потрясающе огромные, я бы обратил на них внимание и попытался бы понять, почему они там.

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

Это определенно будет зависеть от позиции, на которой проводится собеседование, и, вероятно, от языка.

Работать на C ++, иметь парня, заикающегося над синтаксисом, страшно. C ++ полон темных углов, ловушки в основном повсюду. Заикание в синтаксисе означает плохое изложение языка, и новички в C ++ допускают много ошибок (не говоря о том, что другие время от времени этого не делают).

Чтобы ответить на ваш вопрос, тогда:

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

Предостережение только одно: люди признают, что у них нет опыта. В идеале люди должны кодировать на своем языке или псевдокоде, если они того предпочитают (например, студенты).

Правда, я до сих пор забываю синтаксис событий C #, когда мне приходится выписывать их вручную. Это иногда случается в интервью. У меня нет проблемы, когда я пишу код на клавиатуре.

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

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

Моя цель при написании кода в интервью - показать, как я решаю проблему, а не диктовать что-то, что машинистка могла бы ввести в Блокнот и запустить.

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

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

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

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