Научиться программировать ...

Умеете ли вы программировать? Сам факт того, что вы сейчас читаете данный текст, скорее всего означает что вы имеете какое-то отношение к программированию. И уж точно у вас есть к нему интерес, иначе вы бы просто не знали про существование этого блога. Ну или в крайнем случае у вас есть друзья или знакомые программисты. Так или иначе многие сейчас задаются вопросом "как научиться программировать?".

Это сложный вопрос и я конечно не смогу на него ответить, так что я разочарую тех, кто надеялся получить какой-то готовый рецепт. Когда-то давно я прочитал замечательное эссе Питера Норвига на эту тему. Эссе называется "Научитесь программировать за 10 лет". Его можно прочитать в первоисточнике, а также в русском переводе. Эссе посвящено тому, как по мнению Норвига нужно подходить к (само)обучению программированию, а название это естественно пародия на многочисленные книги типа "Научитесь XXX за 21 день".

Сегодня я ещё раз перечитал это эссе, и заметил там для себя что-то, чего не замечал раньше. Ну, точнее замечал, но как-то не придавал должного внимания. А именно, отношение Норвига к поверхностному обучению. В самом начале эссе, он в шутку разбирает что бы могло на самом деле обозначать название книги "Изучите Паскаль за 3 дня". В частности, Норвиг пишет: "... за три дня вы можете получить только поверхностное представление о языке, а не глубокое понимание. Как говорил Александр Поуп - "Недостаточное обучение - это очень опасная вещь".

Это очень верное замечание, на которое стоит обратить внимание. Именно поэтому в одном из своих предыдущих постов, посвящённом вопросам на собеседовании, я и писал что необходимо проверять базовые знания. Задавать "простейшие" вопросы(в кавычках, поскольку это вопросы на самом деле не простые, просто мы настолько привыкли давать на них ответы-"отписки", что не очень задумываемся о сути). Проверять именно глубину знаний. Проверять что человек умеет программировать, и не впадёт в ступор, когда закон
"закон дырявых абстракций" (The law of leaky abstractions") покажет себя.

Перечитайте ещё раз статью Норвига (ну или прочитайте её, если не читали раньше). На самом деле она ведь не только про программирование ;-)

С праздником!

Поздравляю!

Хорошие вопросы

Про вопросы на собеседовании очень многие уже писали. Но мне кажется все писали неправильно :-) Вообще-то я глубоко убеждён в том, что собеседование - процесс практически безнадёжный и что единственный способ понять подходит ли человек для работы - это поработать с ним. Ну поскольку этот способ слишком дорогой, то приходится прибегать к собеседованию.

Все соображения на тему "Как проводить собеседование" напоминают мне одну известную шутку.

Молодую девушку пригласили на свидание и она спрашивает маму - "Как вести беседу?" Мам отвечает - "Ну поговорите сначала о погоде, потом, к примеру, о музыке, а потом скажи что-нибудь остренькое". Во время свидания сразу же после встречи девушка и говорит: "Какая чудная погода, училась музыке три года, бритва."

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

Поэтому я просто приведу примеры вопросов, которые могли бы спровоцировать дискуссию, раскрыть насколько хорошо человек понимает основы (не сгруппированы по тематике):

1. Что такое порт? (в смысле TCP/IP порт) Зачем он нужен? (В смысле - для чего используется)
   
2. Зачем нужна операционная система? (В смысле - для чего используется)
   
3. Зачем нужны точки в ip-адресе?
4. Как определить в какую сторону растёт стек?
   
5. Зачем нужен компилятор?
6. Ведь микропроцессор оперирует исключительно двоичными числами? А как же получаются буквы?
7. Что такое программа? (компьютерная программа)
8. Что такое "сложность вычисления"?
9. Зачем нужны системы управления базами данных? Да и сами базы данных?
10. Что такое ASP (или JSP, или PHP, или ... )? На самом деле этот вопрос не совсем то, чем кажется. Я вероятно просто не смог его аккуратно сформулировать. В качестве ответа я конечно ожидал бы не расшифровку аббревиатуры и даже не краткое описание самой технологии. Я ожидал бы беседы о том, как работает типичный web-сайт.
    

Замечание: некоторые из вопросов могут показаться слишком лёгкими или слишком "общими" или даже оскорбительными чтобы задавать их человеку с серьёзным опытом работы. Мне кажется, что это не так.

1. Вопросы являются лёгкими, если ты знаешь правильные ответы. Это прекрасно!
2. "Общими" или даже "расплывчатыми" вопросы сделаны специально - чтобы спровоцировать обсуждение.
   
3. А насчёт того можно ли задавать человеку с 10-летним опытом работы вопрос "что такое программа"... Ну понимаете, представьте себе на секундочку, что он не ответит.
   (кстати, в качестве ответа на такой вопрос вполне могут послать в края отдалённые и всем известные ... в большинстве случаев я бы считал это правильным ответом :-))
   

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

Более того, мне хотелось бы надеяться, что эти вопросы полезны сами по себе. Что я имею ввиду? Многие вопросы для собеседований ценны только до тех пор, пока кто-то не прочитал на них ответ. В частности, такой проблемой страдают многие "каверзные" вопросы, такие как задача о взвешиваниях 8 монет, перевозе разных тварей через реку и так далее. В большинстве случаев, при задавании подобных вопросов проверяется не столько "логическое" мышление, сколько слышал раньше человек этот вопрос (и ответ на него) или нет.

Я же надеюсь, что вопросы, подобные тем которые я здесь привёл, не теряют своей ценности после того как человек узнал на них ответ. Если я не знал ответа на вопрос зачем нужна операционная система, не понимал этого для себя, принимал её существование как данность, не задумываясь о причинах, по которым люди решили создать подобную сущность, то обсуждение всего этого меня обучит. А это и есть самое главное. А уж научиться отвечать на вопрос о том как в С++ при помощи шаблонов (templates) посчитать факториал на этапе компиляции я смогу позже. Да и нужно ли это?