Понятно, что некорректно сравнивать условия на собеседовании (явный стресс) и трёп в курилке, где все свои, и фейл ни к чему нехорошему не приведёт, но тем не менее.
Имея рабочую программу, привести её к красивому виду довольно легко. Написать простые тесты, «причесать» код и т.д. — допустим, на это уйдёт ещё полчаса. Неплохой результат в любом случае. Тут с самого начала речь шла о скорости, а не о том, чтобы написать код, который можно выдавать за эталон.
Угу. Моё «решение программиста» примерно так и устроено. Только операции вычисляются сразу по мере считывания очередного токена до тех пор, пока это возможно. Суммарно должно получиться О(N), насколько я понимаю.
На самом деле там даже стек для поиска парных скобок не очень нужен.
Привет!
Я — автор «кода разработчика». Попробую прокомментировать свой вариант, вернее то, как и почему я его писал.
Disclaimer 0: я на самом деле тоже уже не совсем разработчик, скорее, какая-то странная смесь из маленького начальника/менеджера/админа/тестировщика/ну и разработчика, да. Но код пишу по большим праздникам, и уже начал немного отвыкать.
Вообще, как тут где-то отвечал anatolix, основная цель заключалась в проверке, может ли обычный программист «с улицы» написать такое задание за приемлимое время, — чтобы на нас не посыпалась волна упрёков, что задания слишком сложные. Вот я и попробовал — в первую очередь для себя — воспроизвести условия, как они бывают на собеседованиях. В основном это касалось временных рамок и ограничений по использованию справочных ресурсов. Если поискать, то легко можно найти и алгоритмы и даже готовые программы, но так не интересно. Теорию последний раз вспоминал лет 10 назад, тогда же и читал Dragon book.
Но полностью воспроизвести условия не получилось — в первую очередь временные: конец года, как всегда некоторая запарка + личная жизнь. семья и всё такое. В результате пришлось разбить всё на два куска — 40 минут и 1:10 где-то — в нерабочее время, разумеется.
Тем не менее это во многом оказалось полезным в контексте данной статьи, и вот почему. Понимая, что я очень ограничен по времени, я старался сделать минимально простое решение задачи. Чем меньше кода, тем проще его и писать и отлаживать. И вроде как это получилось.
На что я обращал внимание:
— во-первых, я не стал разрабатывать большую иерархию классов, продумывать красивые интерфейсы и прочий сахар. Да, я могу спроектировать достаточно сложные вещи — но зачем это в данной задаче? Очевидно же, что задача тестовая, и по завершении код пойдёт в корзину (ок, в данном случае это не так, решение опубликовали — но когда я писал код, об этом не думал)
— во-вторых, я не стал закладываться на будущие возможные изменения. См. п.1. Если бы на реальном собеседовании потом мне сказали бы, а что ты будешь делать, если потом потребуется… — очевидно, что это повод поговорить, а не предложение к дальнейшему программированию.
— в третьих, я не стал писать комментарии по коду. Это несколько спорный момент, на самом деле. Очень возможно, что от меня хотели бы получить «продакшен код», где какие-то разумные комментарии приветствуются. Но это определённо бы существенно замедлило написание, а главное, пришлось бы даже в такой маленькой программе эти комментарии изменять по ходу дела — я несколько раз что-то переписывал даже в этих трёх с половиной функциях. И даже в них, как тут потом выяснилось, я ухитрился накосячить.
В общем, повторюсь, я старался сделать всё как можно проще. Зачем? А затем, что
Disclaime 1: моё мнение может не совпадать с мнением других коллег, проводящих собеседования в Яндексе, и даже с автором этой статьи.
… затем что, в действительности практически всегда интервьюер в конце такого собеседования хочет увидеть работающую программу, а не красивый «канонический», но не работающий код. Для «канонического» кода эта задача или слишком маленькая или, наоборот, слишком большая, если делать всё совсем-совсем правильно. И да, для неё есть уже много готовых инструментов. Если бы можно было или воспользоваться, ими надо было обязательно пользоваться. Это же относится и к другим задачам, которые предлагаются на собеседованиях.
Соответственно, давая кандидату написать на собеседовании код, хочется увидеть не только то, насколько кандидат знает те или иные особенности языка/компилятора/whatever, а может ли он решить заданную ему задачу. Некрасивое работающее решение лучше красивого неработающего. Как тут уже писали, в реальной работе есть множество ограничений: и на используемые библиотеки и style guide, да и сами задачи не все и не всегда носят характер rocket science. Я бы даже сказал, что настоящий rocket science — это объединение сотен и тысяч таких маленьких кусочков, написанных десятками, а то и сотнями людей. Этот процесс может длиться не один год — и как-то странно пытаться интерполировать маленькую тестову/ задачу до такого уровня.
Disclaimer 2: да, бывают люди, способные в одиночку сделать что-то охрененно крутое. Но таких единицы на миллион, и уж по ним обычно и так всё понятно.
Вернусь к исходному вопросу о допустимости того или иного говнокода сомнительного кода в «крупнейших компаниях». Конечно, в идеале надо было бы всё причесать, написать тесты, прогнать через профайлер. И так обычно и делается — в крупных командах даже есть специальные позиции для этого. И у нас (я говорю про поисковый отдел Яндекса) тоже. Но весь код действительно большого проекта не может быть идеальным — это экономически не выгодно.
Единственное, не стоит судить по моему наколеночному решению о том, что происходит внутри нашего репозитория. А что там в действительности творится — подражая anatolix'у, скажу: есть простой способ это узнать.
ЗЫ. Прошу прощения за простыню текста. Я отвечал не только на коментарий выше, а скорее по совокупности всему этому треду.
Понятно, что некорректно сравнивать условия на собеседовании (явный стресс) и трёп в курилке, где все свои, и фейл ни к чему нехорошему не приведёт, но тем не менее.
Имея рабочую программу, привести её к красивому виду довольно легко. Написать простые тесты, «причесать» код и т.д. — допустим, на это уйдёт ещё полчаса. Неплохой результат в любом случае. Тут с самого начала речь шла о скорости, а не о том, чтобы написать код, который можно выдавать за эталон.
На самом деле там даже стек для поиска парных скобок не очень нужен.
Я — автор «кода разработчика». Попробую прокомментировать свой вариант, вернее то, как и почему я его писал.
Disclaimer 0: я на самом деле тоже уже не совсем разработчик, скорее, какая-то странная смесь из маленького начальника/менеджера/админа/тестировщика/ну и разработчика, да. Но код пишу по большим праздникам, и уже начал немного отвыкать.
Вообще, как тут где-то отвечал anatolix, основная цель заключалась в проверке, может ли обычный программист «с улицы» написать такое задание за приемлимое время, — чтобы на нас не посыпалась волна упрёков, что задания слишком сложные. Вот я и попробовал — в первую очередь для себя — воспроизвести условия, как они бывают на собеседованиях. В основном это касалось временных рамок и ограничений по использованию справочных ресурсов. Если поискать, то легко можно найти и алгоритмы и даже готовые программы, но так не интересно. Теорию последний раз вспоминал лет 10 назад, тогда же и читал Dragon book.
Но полностью воспроизвести условия не получилось — в первую очередь временные: конец года, как всегда некоторая запарка + личная жизнь. семья и всё такое. В результате пришлось разбить всё на два куска — 40 минут и 1:10 где-то — в нерабочее время, разумеется.
Тем не менее это во многом оказалось полезным в контексте данной статьи, и вот почему. Понимая, что я очень ограничен по времени, я старался сделать минимально простое решение задачи. Чем меньше кода, тем проще его и писать и отлаживать. И вроде как это получилось.
На что я обращал внимание:
— во-первых, я не стал разрабатывать большую иерархию классов, продумывать красивые интерфейсы и прочий сахар. Да, я могу спроектировать достаточно сложные вещи — но зачем это в данной задаче? Очевидно же, что задача тестовая, и по завершении код пойдёт в корзину (ок, в данном случае это не так, решение опубликовали — но когда я писал код, об этом не думал)
— во-вторых, я не стал закладываться на будущие возможные изменения. См. п.1. Если бы на реальном собеседовании потом мне сказали бы, а что ты будешь делать, если потом потребуется… — очевидно, что это повод поговорить, а не предложение к дальнейшему программированию.
— в третьих, я не стал писать комментарии по коду. Это несколько спорный момент, на самом деле. Очень возможно, что от меня хотели бы получить «продакшен код», где какие-то разумные комментарии приветствуются. Но это определённо бы существенно замедлило написание, а главное, пришлось бы даже в такой маленькой программе эти комментарии изменять по ходу дела — я несколько раз что-то переписывал даже в этих трёх с половиной функциях. И даже в них, как тут потом выяснилось, я ухитрился накосячить.
В общем, повторюсь, я старался сделать всё как можно проще. Зачем? А затем, что
Disclaime 1: моё мнение может не совпадать с мнением других коллег, проводящих собеседования в Яндексе, и даже с автором этой статьи.
… затем что, в действительности практически всегда интервьюер в конце такого собеседования хочет увидеть работающую программу, а не красивый «канонический», но не работающий код. Для «канонического» кода эта задача или слишком маленькая или, наоборот, слишком большая, если делать всё совсем-совсем правильно. И да, для неё есть уже много готовых инструментов. Если бы можно было или воспользоваться, ими надо было обязательно пользоваться. Это же относится и к другим задачам, которые предлагаются на собеседованиях.
Соответственно, давая кандидату написать на собеседовании код, хочется увидеть не только то, насколько кандидат знает те или иные особенности языка/компилятора/whatever, а может ли он решить заданную ему задачу. Некрасивое работающее решение лучше красивого неработающего. Как тут уже писали, в реальной работе есть множество ограничений: и на используемые библиотеки и style guide, да и сами задачи не все и не всегда носят характер rocket science. Я бы даже сказал, что настоящий rocket science — это объединение сотен и тысяч таких маленьких кусочков, написанных десятками, а то и сотнями людей. Этот процесс может длиться не один год — и как-то странно пытаться интерполировать маленькую тестову/ задачу до такого уровня.
Disclaimer 2: да, бывают люди, способные в одиночку сделать что-то охрененно крутое. Но таких единицы на миллион, и уж по ним обычно и так всё понятно.
Вернусь к исходному вопросу о допустимости того или иного
говнокодасомнительного кода в «крупнейших компаниях». Конечно, в идеале надо было бы всё причесать, написать тесты, прогнать через профайлер. И так обычно и делается — в крупных командах даже есть специальные позиции для этого. И у нас (я говорю про поисковый отдел Яндекса) тоже. Но весь код действительно большого проекта не может быть идеальным — это экономически не выгодно.Единственное, не стоит судить по моему наколеночному решению о том, что происходит внутри нашего репозитория. А что там в действительности творится — подражая anatolix'у, скажу: есть простой способ это узнать.
ЗЫ. Прошу прощения за простыню текста. Я отвечал не только на коментарий выше, а скорее по совокупности всему этому треду.