Всем привет!
Вопрос:
Всем известно, что Сodeforces очень помогает развивать свои способности в решении ординарных и далеко не очень [ординарных] задач. Спасибо за это огромное.
И никому не секрет, что часто подобные задачи спрашивают на собеседованих в компании такие как Amazon, Google, Microsoft etc.
Но также в, как правило, спрашивают задание, которыое относится к разделу тестирования или System Design. И тут вопрос:
Если тестирование можна где-нибудь здесь почитать, а интервьюшные задачки посмотреть (кроме Codeforces и TopCoder), например, еще тут, то вот как быть с System Design? Где можна поднатаскаться-потренироваться (или хотя бы почитать) о System Design, положим для разных уровней исходных знаний и умений?
Спасибо
Имхо это слишком размытый вопрос, либо слишком абстрактный особенно для новичка.
Если вас архитектура вообще интересует, гуглите "Мартин Фаулер", у него как минимум две книжки которые вам нужны.
Однако новичков и середнячков чаще спрашивают более простые вещи, в частности паттерны, реализации MVC (ну и для изврата MVP, CQRS).
Тут я отмечу что на деле подходы к архитектуре сильно различаются порой. Например Фаулер начинает ядом плеваться когда упоминают "анемичные модели", хотя по-моему 90% веб-приложений на джаве пишут именно с анемичными моделями
,,,>^.,.^<,,,(в то время как rich-models популярны в большинстве PHP, Ruby, Python фреймворков, а в Java например юзаются в Play)Фаулер это обзывает в отместку "general java anti-pattern".
В целом же в подобные вещи начинаешь вникать уже сменив контору-другую :)
Вот-вот. Вопрос как раз в том, как без опыта контор адекватно (для уровня, как вы выразились, новичка) отвечать на подобные вопросы? Меня несколько ставит в тупик даная тематика, как человека более, к сожалению,
гуманитарОбокогоконтест-ориентированого.За советы благодарен.
А какие именно вопросы вам задавали? Вы вообще на разработчика собеседовались? На какой язык?
Я бы на месте новичка больше внимания уделял в первую очередь средствам сборки и юнит-тестов, поскольку обычно когда вы устраиваетесь на новый проект (даже не обязательно если новичок) — вас сажают писать тесты. С одной стороны вы делаете важное дело — с другой, ничего не сломаете. :)
Ещё весьма полезен Роберт Мартин "Чистый Код" — ну там первая треть это в общем почти must have — а остальные две как раз в сторону тестов и архитектуры (правда не обязательно хватит терпения его рассусоливания читать).
Можете достаточно смело отвечать что "я интересовался данными вопросами, но конечно я понимаю что без реального опыта работы в серьёзных проектах (как ваш!) мои представления довольно туманны и дальше паттернов я не слишком продвинулся" (конечно на вопросы о самих паттернах нужно уметь отвечать бойко — википедия и книжки дают неплохую инфу)
Тут полезно понимать что из четырёх популярных грэйдов junior, middle, senior, lead обычно "этими вопросами" всерьёз занимаются только последние два :)
Если вы попадаете в контору где новичку предлагают архитектурить приложение — обычно это плохая контора. Ну т.е. новичок-то получит бесценный опыт и спокойно свалит дальше, а контора останется с его программулиной... Со мной такое было! :D
Ничего не задавали, потому что interview только в планах. Если я правильно помню, то язык не главное. Но если что, то С++ мне ближе
Вообще вопрос мой скорее о том, чего ожидают услышать от человека, учитывая его уровень, нежели чего бы выучить по теме (это далеко не значит, что я не учту ваши советы в долгосрочной перспективе конечно же)
P.S. как правильно цитировать собеседника? : )
http://codeforces.com/blog/entry/11696#comment-164976
Тогда заранее сильно не парьтесь. По крайней мере System Design для вас сейчас не главное я думаю.
Собеседование от собеседования сильно отличаются, и вопросы и т.п. Мне порой везло — давали небольшие тестовые задания (ну такие на два-три дня дома поделать).
Сходите на парочку — и уже будете гораздо лучше представление иметь :)
Ну... Как сказать... Вакансий где язык не главное довольно мало. Мне чтобы с Си на Джаву переключиться пришлось год усиленно практиковаться (я тогда и зарегался на CodeForces) и то взяли после десятка собеседований (правда сразу в два места).
Зачастую важно не знание самого по себе синтаксиса языка, а опыт с популярными в нём библиотеками, фреймворками и инструментами. В отношении C++ я тут не могу сильно много чего рассказать, так что вам стоило бы отдельный пост завести.
Про архитектуру новичка спрашивать не будут почти наверняка. Вероятно спросят о других языках, опыте с вебом, ну и дальше специфично по конторам — представлениях о TCP/IP, опыте разработки GUI, познаниях Qt или Windows API например. Это что меня обычно спрашивали когда я на Си писал. Три раза задавали вопрос о том как развернуть связный список. :)
Опять же для C++ с дизайном приложений и архитектурами дела чуть менее очевидно обстоят (на мой взгляд), поэтому там больше "знатоков" и противоречивых мнений, и к новичкам соответственно относятся снисходительно. :)
Могут спросить про подходы к командной работе, стиль оформления исходников, использование систем контроля версий.
Я ставлю значок
>в начале строки. Это вроде не маркдауновская фича но работает :)За вышеперечисленое благодарю, но об этом можно конечно говорить очень много по теме. Поэтому на сообеседовании вопросу полагается быть практическим. Например, спроектировать RSS feed для сайта.
Конечно, зная вопрос дома, добрые дяденьки google или yandex несомненно подскажут и дадут много действительно полезных ссылок.
Вопрос в том, как охватить класс подобных задач в краткие сроки? Есть идеи?
Извиняюсь, что влезаю. Мне кажется, Вы сильно пытаетесь срезать путь в этой теме. Задачи проектирования, так же как и многие вопросы "хорошего кода" приходят только с опытом. Вы не поймете, что такое хорошая архитектура, пока не начнете заниматься архитектурой (и не наступите на грабли несколько раз, скорее всего). Поэтому вопрос "как охватить класс подобных задач?" это примерно как "какие 5-6 алгоритмов надо выучить, чтобы стать красным?". Книги могут немного помочь, но в основном нужен опыт и здравая голова на плечах. Но даже если голова есть, то опыт нужен все равно.
Моя точка зрения — если вы новичок, то рано над этим париться. Если уже не новичок, а прогресса все ещё никакого, то поздно париться. Эти знания придут естесственным путем — через опыт. Так что, если хотите накачать этот навык, то надо просто начать писать что-то, что с архитектурной точки зрения будет хоть как-то нетривиально для Вас. Ну и плюс, так как это интервью, то надо еще уметь объяснять свою точку зрения собеседнику.
Надеюсь вы понимаете, что я ни разу не хотел спросить ничего подобного.
При всем уважении, вы предлагаете лучше игнорировать и не готовиться вообще по даному вопросу?
P.S. таки полезная штука
>=====================================================================
Понимаю. Просто мне оно звучит реально так. Не хотел обидеть.
Не то, чтобы я предлагаю не готовиться. Просто хорошие, систематизированные знания с пониманием Вы получите, скорее всего на своем опыте. С книг, статей, сайтов можно либо получить представление, либо освежить забытое, либо углубить, если уже знаешь что-то. Я себе это представляю, как экзамен в институте, есть два варианта — можно весь семестр учиться, готовиться и сдать спокойно и уверенно, а можно за час до экзамена прочесть шпаргалку и может даже тоже сдать хорошо, но знаний после этого вряд ли прибудет.
Я переформулирую, что я хотел сказать. Если вы толковый начинающий программист, то Вас возьмут на работу без этих знаний, а на работе вы эти знания сможете получить. Если Вы не начинающий, прошу извинить. Если Вы начинающий и фиолетовый на CF, то вы скорее всего достаточно толковый (по опыту тех студентов, которых я видел). Так что единственное исключение — это если вы пытаетесь запрыгнуть на должность, на которую не тянете, тут я советов дать не могу.
Может быть, имело бы смысл указать всё-таки свой примерный уровень/опыт, чтобы нам не приходилось угадывать. Конкретно по Вашему вопросу — "соответственно уровню", я не знаю ни одного ресурса, покрывающего все уровни.
P.S.: давайте, если хотите в личку, не люблю устраивать чат на КФ, он тут не выглядит круто :)
Мне к сожалению не удаётся вас убедить что вы не в ту сторону копаете. От джуниора не ждут проектирования частей сайта. От джуниора нужно чтобы он научился грамотно помогать. Понимать то что говорят, правильно выполнять, добросовестно отчитываться, уметь разбираться и т.п.
И что вы произведете гораздо лучшее впечатление несколькими небольшими проектами в вашем аккаунте на гитхабе, нежели сбивчивыми рассказами о том что вы читали книжки о проектировании приложений.
Ну и конечно "в краткие сроки" — это совсем перебор. Вы можете 10 раз прочесть про разницу между OOD и OOA, но без практического опыта вы никогда не сможете её донести.
Пожалуй главное что я бы осмелился порекомендовать — выберите для себя класс задач, тип проектов в которых вы для начала хотели бы участвовать. И попытайтесь хотя бы слегка охватить его.
Например я ставил перед собой примерно такие цели (с интервалом примерно в год):
Вы полагаете я мог бы опыт полученный за 6 лет "в краткие сроки" накопить перед первым собеседованием? И то я его сейчас расцениваю как весьма недостаточный, хотя зарплата за это время выросла раз в пять :)
Обязательно прислушаюсь к вашим советам в долгосрочной перспективе
о таких вещах на интервью надо заявлять с крайней осмотрительностью. В C++ есть адская объектная модель, многопоточность, особая шаблонная магия — и про что-то из этого вас наверняка спросят. Что такое RAII и/или виртуальные деструкторы, и для чего они нужны. В каком порядке обрабатываются исключения. Какая из спецификаций шаблона будет вызвана в том или ином случае, и так далее.
На контестах из всего этого используется только небольшая часть STL.
да, с вами пожалуй сложно не согласиться :D
Да уж, сложность C++ была для меня одним из поводов учить джаву. Правда джава тоже оказалась сложнее чем я думал :)
Here http://www.geeksforgeeks.org/about/interview-corner/
Thx, great site
But any precise links for System Design q&a?
We don't know any books that could help with that. (Google Recruiter)
Я прочитал следующие статьи:
The Google File System
Bigtable
The Google Cluster Architecture
Это всё оч интересные вещи (сюда можно добавить классный курс по BigData с Coursera — его проводит дядечка из IIT) — но я б сказал что вакансий куда это требуется очень-очень мало и "новичком" в них обычно считается разработчик с изрядным опытом в обычных проектах но не имеющий опыта именно в бигдата, хадупе и т.п. :)
Вопросы по дизайну систем типичны для Google. Думаю, неплохо будет ознакомиться с решениями, реализованными в этих системах. С чего Вы взяли, что это стоит читать на специализированные вакансии? Я про Map-Reduce забыл добавить в список.
Ну покажите по Минску или Питеру несколько вакансий куда это требуется? Я за год в Питере насчитал около 5 штук, на одну собеседовался и на пару отсылал резюме ещё.
Само по себе количество проектов где они используются в десятки раз меньше чем проекты более среднего уровня, типичной "многослойной" архитектуры со старыми добрыми реляционными базами внизу — этого добра в "энтерпрайзе" подавляющее большинство по-моему.
Ага, а также про Locality Sensitive Hashing, Message Queues, репликацию баз, Hadoop (внутри которого пусть будут YARN, Pig, Hive, HBase), распределённые кэши, OLAP и т.п.
Только я сомневаюсь что это всё новичку надо :)
Я же сказал, вопросы по дизайну систем типичны для Google. Общее представление о Map-Reduce не помешает.
Гугл не типичная контора, мягко говоря.
Да и для неё это не всегда типично. Подозреваю что в Питерском офисе будут спрашивать в основном про джаваскрипт и разные навороты на его основе. Шансов что поинтересуются биг-датой что-то около 1%.
В то же время просто от нечего делать вставлять умные слова в разговор я бы не стал. Например, заикнусь я про MapReduce — меня спросят какие я знаю реализации. А я знаю только что есть в хадупе здоровенная, убогая в MongoDB и учебных парочка для питона есть. И тут станет ясно что "слышал звон". Ну или попросят задачку через него показать как решать. Вы только собираетесь сказать "например TF-IDF" и тут они говорят "кроме TF-IDF"... В общем тут уж тогда надо готовиться к подвохам, а то случалось "накалываться"... :)
Зачем знать реализации? Никто не ожидает от Вас подробностей реализации. Определите каким образом будут обрабатывать данные mapper-ы и reducer-ы. Да и вообще, можете не вспоминать эти слова, просто пробуйте рассуждать в рамках данной концепции.
Отлично, спасибо
Здесь есть задачки с реальных интервью и обсуждения.
Спасибо конечно, но хотелось бы больше конкретнее по теме System Design (что бы под этим не подразумевали люди, анонсирующие задания для интервью)
Пожалуйста конечно, но просто здесь выберите "System design", "Distributed computing", "Large scale computing", etc. Так же может быть полезно посортить по дате.
ага, верно : )
Спасибо !
По-моему, Вы просто не умеете правильно ставить вопросы.
Из Вашего поста и комментариев очевидно, что Вы прошли на онсайт-собеседование в Google, в котором пятое интервью — как раз System Design. RodionGork дал Вам много полезных советов, и я могу подтвердить это, поскольку сходил на собеседования примерно в 30 питерских компаний, так что советую прислушаться к его советам, если будете искать работу в своем городе.
Что касается собеседования в Google, это совершенно нетипичный случай. System Design — это просто условное название, там не требуется никаких знаний архитектуры систем и всего, о чем говорили RodionGork и marat.snowbear.
Таким образом, резюмируя, Вы просто ввели людей в заблуждение тем, что побоялись или постеснялись сказать, что собеседуетесь именно в Google.
Правильным алгоритмом решения было бы найти на Codeforces тех, кто работает в Google, например RAD, RAVEman, Jacob, и спросить их, как подготовиться к этому интервью и какие вопросы задавали в свою очередь им, когда они устраивались работать в компанию.
Совет от меня — возьмите любой продукт Google (например, Google Maps, Google Search, YouTube, Android) и попробуйте ответить на вопрос, как его разработать. В поисковик можно вбивать вопросы вида "как сделать свои карты", "как написать свой поисковик", "как запрограммировать видеоплеер", "как создавался Android".