Пользователь
0,0
рейтинг
21 сентября 2009 в 23:30

Как я провожу собеседования программистов

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

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

Что касается зарплаты. Обычно в подобных топиках пишут, мол, «зарплату вы предлагаете низкую, а требуете много». Так вот, ниже рассказывается про собеседование минимальной сложности, которое я провожу со всеми кандидатами на любую должность и при любой зарплате. Т.е. по моему мнению, это собеседование должен проходить любой человек, называющий себя программистом, независимо от зарплаты.

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

Я не задаю философских вопросов типа «Кем Вы видите себя через пять лет». Этим занимается отдел кадров. Я разговариваю с кандидатами исключительно на технические темы.

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

Здесь, как правило, кандидаты совершают первую ошибку — пишут в резюме то, чего на самом деле не знают. Классический диалог:

— Где Вы применяли XSLT?
— Ну… нам в универе че-то рассказывали про это…

Или (реальный случай):

— Вы знакомы с работой DNS?
— Ну да, че там, было дело…
— Хорошо, скажите, какого уровня домен vkontakte.ru?
— Ну… высокого уровня, наверное…

Я могу понять, если человек пять лет назад использовал в проекте какую-то редкую, малораспространенную технологию, и сейчас не помнит, как там оно работало. Но если у человека в резюме написано «хорошее знание MySQL» а на деле «да я уж не помню, давно было и если честно мало с мускулем работал...» то это — большой жирный минус. Не знаешь чего-то — не пудри мне мозг и не отнимай время.

Вообще, теоретическая часть сильно зависит от резюме кандидата. Независимо от резюме я обычно задаю два вопроса — «Какой самый сложный проект Вы делали» и «Приходилось ли Вам работать с какими-то внешними API, типа платежных систем или гуглокарт». Если дело имел и внятно рассказывает — это плюс. Замечание типа «прием уведомлений от яндекс-денег — отстой, у вебманей сделано гораздо удобнее (с обоснованием такого мнения)» — это большой жирный плюс.

Набор практических вопросов у меня давно уже устаканился и выглядит примерно так:

1) Проверка знания SQL

Задача: «Имеется таблица с двумя полями — Отдел и Сотрудник, требуется вывести те отделы, в которых работает более пяти сотрудников.»

Проверяется понимание кандидатом работы групповых функций и оператора HAVING.

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

SELECT otdel FROM table WHERE COUNT(sotrudnik)>5 GROUP BY otdel

Вариант этот, понятно, не работает, так как агрегатные функции нельзя использовать в операторе WHERE.

С трансцендентальным оператором HAVING вообще знакомы редкие единицы. На счет HAVING'а у меня бзик. Личные наблюдения показывают, что если человек знает и умеет применять HAVING, то это — толковый человек, почитавший документацию и порешавший практические задачи. Это как лакмусова бумажка.

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

2) Проверка знания рабочего окружения

Задача: «В браузере открыт сайт test.local, требуется найти директорию, в которой находятся файлы этого сайта.»

Проверяется знание кандидатом системы DNS (определить IP сервера), умение работать с SSH (зайти на сервер), понимание того, что сайты отдает некий веб-сервер (никаких хитростей, используется Apache), умение прочитать конфиг Apache и найти там директиву DocumentRoot, указывающую на искомую директорию.

У значительной части людей (меня это удивляет и смешит одновременно) мозг взрывается уже при попытке понять, что такое «test.local». Следующая часть теряется на этапе резолвинга этого хоста (не знают про host или хотя бы про банальный ping). Ну и не все оставшиеся умеют читать конфиг Apache. Особенно трудно дается прочтение конфига, в котором виртуальные хосты вынесены в отдельный файл директивой Include.

3) Проверка знания Perl

Здесь у меня такая позиция: я никогда не задаю хитрые вопросы, ответ на которые хрен сразу сообразишь, а сообразив — нигде с пользой не применишь. Т.е. это вопросы типа «что будет если написать print $i++ + ++$i» или «напишите рекурсивное регулярное выражение для проверки вложенных скобок».

Стандартная задача довольно проста: «Напишите скрипт, который читает текстовый файл, построчно его обрабатывает и результат выводит в браузер. В файле находятся e-mail'ы, обработка заключается в проверке e-mail'ов на валидность с помощью регулярного выражения.»

Проверяется умение создать исполняемый perl'овый скрипт, умение работать с файлами, опыт работы с регулярными выражениями и умение выдать результат в удобочитаемом виде в браузер.

Многие, написав скрипт «hello world», вызвав его из браузера и получив ошибку 403 Forbidden, встают в тупик. Я не знаю, как так получается, но многие не в курсе того, что скрипт нужно сделать исполняемым. А кто в курсе — те часто не могут вспомнить команду смены прав доступа chmod.

Дальше мистической загадкой становится чтение из файла. Если открытие дескриптора open знакомо практически всем, то сделать цикл по \<FILEHANDLE\> догадывается не каждый.

Регулярку для проверки e-mail'а я прошу написать сложную настолько, наколько кандидат способен это сделать за несколько минут. Если написание регулярки затягивается дольше пяти минут, я прошу остановиться на достигнутом. Почти в 100% случаев результат получается такой:

/\w+?@\w+?\.\w+?/

Этот результат я считаю неудовлетворительным. Обычно в таком случае я задаю «вопрос на засыпку» — «какой недопустимый символ пройдет эту проверку?». В ответ я хочу услышать «подчеркивание». Не отвечает практически ни один.

Ну и, наконец, очередным камнем преткновения становится вывод в браузер. Примерно половина не догадывается, что вывод собственно результата должен быть предварен выводом HTTP-заголовка. Другая половина, которая помнит, что надо что-то вывести, не помнит, что именно надо вывести.

По ситуации, я могу еще попросить усложнить скрипт — вынести проверку в отдельную функцию, функцию вынести в модуль, и, для самых толковых, модуль сделать объектно-ориентированным. До этих усложняющих этапов доходит примерно четверть кандидатов.

Результаты собеседований меня неизменно расстраивают. Подавляющее большинство кандидатов ужасны.
Михаил Иванов @ivanych
карма
–28,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (189)

  • +1
    просто и эффективно :)
  • +14
    > С трансцендентальным оператором HAVING знакомы редкие единицы. На счет HAVING'а у меня бзик.
    Хм, у меня на него тоже бзик, только наоборот, я его стараюсь не применять до последнего :)

    • +2
      Да не вопрос, если кандидат обоснует такую позицию — получит жирный плюс.
      • +1
        Если навскидку, то то что осталось в памяти — это что having используется в последнюю очередь и прореживаются данные уже вытянутые запросом.

        Потом глянул в документацию:

        Выражение HAVING может ссылаться на любой столбец или псевдоним, упомянутый в выражении select_expression. HAVING отрабатывается последним, непосредственно перед отсылкой данных клиенту, и без какой бы то ни было оптимизации.


        Сегодня тоже проводил заочное собеседование. Я люблю задавать вопрос на простановку индексов, часто о составных индексах не знают. Насчёт того, что хочется от собеседуемого услышать (увидеть, если в асе разговор) уверенность в теме — это да.
  • +5
    Так все-таки можете аргументировано объяснить, почему использование Having лучше приведенного ниже кода:
    SELECT otdel FROM table WHERE COUNT(sotrudnik)>5 GROUP BY otdel

    Кроме аргумента «если знает having то адекватный человек»
    • +1
      Никогда бы не написал WHERE COUNT(sotrudnik)>5, чисто интуитивно. Попробовал в mysql — а так по ходу нельзя, пишет Error Code: 1111, Invalid use of group function :-)
      • –2
        нет, ясно, что аггрегирующие функции нельзя применять в секции WHERE, тут нужно использовать подзапрос.
        Вопрос непосредственно про преимущества использования HAVING
        • –2
          Ну так… Подзапрос на КАЖДУЮ строчку основного запроса или просто перебрать выдачу одного запроса еще раз. В 99% HAVING будет быстрее.
          • 0
            так, придется все-таки написать запрос с использованием подзапроса.

            SELECT otdel FROM
            (SELECT otdel, COUNT(sotrudnik) AS kol
            FROM table
            GROUP BY otdel)
            WHERE kol > 5

            Тут один запрос, а другой фильтрует его результаты, собственно этим же занимается и Having
            • +1
              Такой ответ кандидата — это большой жирный плюс.
              • +5
                Так вы объясните мне, чем же Having лучше? )
                Я честно хочу понять, просто всегда обходил его стороной, считая, что он излишен.
                • –8
                  Лучше чего? Вложенного запроса? Не знаю, даже не задумывался.
                  • +7
                    Тогда ваш «бзик» на тему Having совершенно непонятен. У меня знакомые такие перлы писали с использованием этого оператора, что аж ужас.
                    • +3
                      HAVING демонстрирует умение проредить выборку, в которой используется агрегатная функция. Т.е. человек должен понимать, в чем принципиальная разница между прореживанием ДО группировки и прореживанием ПОСЛЕ группировки. Люди, не знающие HAVING'а, и вложенный запрос, как у Вас, написать не смогут, ибо не понимают сути процесса.
                      • +5
                        Верите — нет, но я совершенно до этого топика не представлял как работает Having. Точнее когда-то знал, но сразу же забыл, потому что никогда не сталкивался с ситуациями, в которых он был нужен.
                        Написать этот вложенный запрос элементарно, если помнить правило применения агрегатных функций, что их нельзя использовать в секции WHERE
                        • –3
                          Ваш первый вопрос был — «почему HAVING лучше неработающего запроса». Не знаю, что вы там раньше знали про HAVING, но если бы Вы мне на собеседовании написали неработающий запрос, да еще стали бы уверять, что HAVING ничем не лучше — работу бы Вы не получили.

                          Еще раз — я не требую обязательного использования HAVING. Напишете запрос без HAVING — зачет.

                          Просто так уж сложилось в жизни, что я привык использовать для решения этой задачи специальный, предназначенный именно для этой задачи оператор — HAVING.

                          И так уж сложилось, что люди, которые в состоянии решить эту задачку, они знают про HAVING и решают эту задачку с его помощью. А вот люди, которые эту задачку не решают — они не знают и про HAVING.

                          Отдельная категория людей, которые решают эту задачку, но при этом не используют HAVING — это редкие оригиналы, которые мне как-то не попадаются. Либо попадаются, но начинают разговор, видимо, с того, что пишут неработающий запрос и вопрошают «а чем он хуже HAVING?!».
                          • +1
                            Просто вы в топике привели неработающий запрос и написали, что Having лучше. Я не особо всматриваясь, сразу заинтересовался чем же он лучше.
                            • –1
                              хотел сказать, что неработающий запрос написали именно вы, я просто его скопировал, не убедившись в его работоспособности
                              • 0
                                Блин, елы палы. Это не я написал неработающий запрос, это я процитировал кандидатов, пишущих неработающие запросы.
                                • –1
                                  Не надо писать неработающий запрос, а потом фразу, что использование Having в данном случае предпочтительнее.
                                  Читающий интуитивно полагает, что с запросом все в порядке и не всматривается в нем, а акцентирует свое внимание именно на Having
                                  • –2
                                    Не надо приписывать мне лишнего, ага? Я не писал, что использовать HAVING предпочтительнее.

                                    Тем не менее, во избежание дальнейших подобных разночтений, я там вставил строчку, где явно говорю, что приведенный запрос не работает.
                          • 0
                            Смешно, но я как раз и оказался тем самым оригиналом, так как, решив задачку через вложенный запрос, полез в гуголь смотреть, как работает оператор Having
                      • +1
                        Сегодня только от Вас узнал о том, что бывает такой Having…
                        Сколько уже времени работаю с вложенными запросами…
                • +3
                  Разница вот в чем —

                  EXPLAIN SELECT otdel, COUNT(sotrudnik) as cnt
                  FROM table
                  GROUP BY otdel
                  HAVING cnt>5


                  id	select_type	table	type	rows	Extra
                  1	SIMPLE	table	ALL		9484	Using temporary; Using filesort


                  Explain вашего запроса:

                  id	select_type	table	type	rows	Extra
                  1	PRIMARY	<derived2>	ALL	40	Using where
                  2	DERIVED	table		ALL	9484	Using temporary; Using filesort
                  


                  имхо, тут бы начать с нормализации данных, разнести сотрудников и отделы по разным таблицам
                • 0
                  Я применяю HAVING для пост-обработки строк, полученных в результате работы выражений ROLLUP, CUBE или GROUPING SETS в конструкции GROUP BY.

                  Иначе их можно обработать только в конструкции WHERE запроса уровнем выше, что я уже в данном случае нахожу излишним.
            • 0
              А как вам такой? :)

              SELECT otdel, COUNT(sotrudnik) AS cnt
              FROM table
              GROUP BY otdel
              ORDER BY cnt DESC
              LIMIT 5


              • 0
                Бред, выведет 5 отделов с наибольшим количеством сотрудников. См. условие задачи )
                • 0
                  Черт, задача в голове в другую(весьма частую по жизни) трансформировалась, сорри :)
              • 0
                достаточно чуть подкорректировать:
                SELECT otdel, COUNT(sotrudnik) AS cnt
                FROM table
                WHERE cnt > 5
                GROUP BY otdel
                • 0
                  не будет работать, так как count срабатывает после группировки, а where до
                • 0
                  нет, так не выйдет. ссылаться из where на аггрегирующую ф-цию нельзя. mysql ругнется, что не знает столбца 'cnt'
                  • 0
                    точно, спасибо. как-то не было причин с этим сталкиваться.
                  • +3
                    не уверен на все 100% но думаю что ругнется любая СУБД
                    • 0
                      Я уверен на 100%, т.к. фактически это нарушение стандарта SQL.
            • 0
              У меня почему-то пишет ошибку
        • –2
          Вообще говоря, у HAVING нет преимуществ. Это просто способ удобно отфильтровать результаты в некоторых случаях, не самый лучший
          • 0
            Нет.

            Тут уже правильно написали, что WHERE используется ДО группировки, а HAVING после. Я вообще не понимаю — что значит лучше или хуже — это разные вещи. WHERE определяет условие выборки по которым уже дальше будет идти группировка. То есть это условие по которой будет идти сама группировка, это было бы более очевидно если бы нужно было посчитать не просто количество человек в отделе, а человек например с возрастом более 30-ти лет. После того, как выполняется выборка с условием WHERE идет группировка результата. И вот когда она уже сформирована — только тогда уже работает HAVING и только для этого он и нужен. Подзапросы никакого отношения к HAVING-у не имеют, хотя бы потому что это подзапрос, а HAVING — это фильтрция результатов текущего запроса. Да, сэмулировать можно подзапросами — только зачем?
            • +1
              Проблема HAVING в том, что его условие (cnt>5) не использует и не может использовать индексы. По сути это «вынуть всё, отдать чуть-чуть». Поэтому их необходимо по возвожности всячески избегать. Не буду утверждать за все случаи, но те, что попадались мне — решались рефакторингом БД. В данном случае поможет обычная нормализация+подзапрос (первое что пришло в голову) — разносим отелы и сотрудников в разные таблицы и пишем слудующее

              SELECT
              ,department
              ,(SELECT COUNT(*) FROM employees WHERE id_depart = department.id) AS cnt
              FROM departments
              WHERE cnt>5


              Имеем две маленькие таблички и шустрый запрос использующий индекс, вместо большой (относительно) таблицы и медленного запроса с having и без индексов. Может как то и с JOIN можно извернуться, но щас уже голова не очень работает
              • 0
                блин, понаопечатался :)
                SELECT
                    department,
                    (SELECT COUNT(*) FROM employees WHERE id_depart = departments.id) AS cnt
                FROM departments
                WHERE cnt>5

              • 0
                Макс, ну конечно агрегатные агрегатные функции не могут использовать индекс — как иначе-то? Но тут даже и подзапросы не помогут. Ты же сам выше приводил пример эксплейна, где ясно видно что условие с хэвингом обрабатывает меньшее количество строк. Так что твой вариант с подзаросом врят-ли будет быстрее чем с JOIN… ON и HAVING. Я честно говоря в этом уверен. Как и уверен в том, что индексы у тебя не используются (ну разве что при условии id_depart = departments.id — но в случае с джойном будет тоже самое)

                Но ты совершенно прав — это решается рефакторингом БД — только не так как написал. Иначе. А именно — если это самое значение COUNT хранить в отдельной таблице, а дальше при апдейте вешать триггер который будет изменять это значение в зависимости от запроса. Ну или запрос на изменение вручную делать — тут кто как хочет. Тогда при условии что на данное хранимое значение будет навешан индекс, сее будет работать. Опять же — в зависисмости от условий, а имеено выполнение запроса на получени с COUNT — операция очень частая, а обновление таблицы — редкая. Если наоборот — то заморачиваться бессмысленно.
                • 0
                  А еще можно у каждого сотрудника в отделе хранить id (для каждого отдела — своя табличка, в ней сотрудники, и если id > 5, то...)

                  Правда это будет хреново работать при увольнении сотрудников )
          • 0
            HAVING это наиболее короткий и удобный способ решить предлагаемую задачу. Хотя я не помню даже когда последний раз его применял, уже даже забыл как он называется. Вообще с группировкой приходится иметь дело не так уж и часто.
          • +1
            Зато HAVING работает на старых версиях mysql где подзапросов не было.
        • +3
          Какие преимущества у работающего запроса перед неработающим? Ну я даже не знаю…
    • +1
      Приведенный код не работает. Агрегатные функции нельзя использовать в операторе WHERE.

      Для наглядности — представьте, что Вам еще нужно выбрать только тех сотрудников, у которых фамилия начинается на «А».
      • –1
        Дамп базы: http://pastebin.com/f1521f3ca
        Запрос:
        SELECT `Division`.*, COUNT(`Division`.`ID`) as `Employees`
        FROM `Division`
        JOIN `Employee`
            ON `Employee`.`DivisionID` = `Division`.`ID`
        WHERE `Employee`.`Name` LIKE 'A%'
        GROUP BY `Division`.`Name`


        Выводит следующее:

        ID — Name — Employees
        1 — First — 3
        Без `Employee`.`Name` LIKE 'A%' выведет следующее:
        1 — First — 8
        2 — Second — 2

        Добавить в запрос условие WHERE `Employees` > 5 — проще простого.
        Так в чём недостатки такого очевидного, понятного и лёгкого подхода?
        • 0
          Хотя стоп, забираю свои слова назад, выше объяснили.
          Был неправ.
    • 0
      аргумент — тупо работать не будет
  • +1
    По-моему отличные вопросы на общее развитие. Но вы же не ограничиваетесь ими — дальше идут более специфичные?

    регулярка на email — это просто кладезь вариантов, crjkmrjвплоть то RFC-based
    • 0
      Идут ли дальше более специфичные — это зависит от того, насколько продвинутого сотрудника я ищу. В данном случае описаны базовые вопросы для всех.
  • +18
    Человек, который пишет
    SELECT otdel FROM table WHERE COUNT(sotrudnik)>5 GROUP BY otdel
    вместо
    SELECT department FROM table WHERE COUNT(employee)>5 GROUP BY department
    для меня сомнителен.
    • 0
      хрен редьки не слаще. не будет работать COUNT в выражении WHERE.
    • 0
      Видел в одной базе табличку Tovar_v_price_liste =)
      • +1
        А я видел таблицу ShapkiZay(Шапки заявки), которую иначе чем Шапки Заячьи никто не называл)
  • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Жаль, что я не веб-разработчик, а то бы пришел к вам на собеседование и тоже расстроил бы.

    А вообще, интересно даже стало — а на чем собственно ведется разработка? Никогда не поверю, что на перле.
    • 0
      Отчего же не поверите? На Перле ведется, и замечательно ведется:)
      • 0
        не верю, что на перле остались такие тупые разработчики, что не могут ответить на такие простые вопросы
        • 0
          А, да, я тоже в это не верю:) Однако ж имеются.
        • 0
          Легко. Просто есть люди которые считают что знают перл. Такие себе универсальные веб-кодеры. А что там, с-like синтаксис что в php что в perl. Библиотеки для работы с бд имеются, html тот же. А когда дело доходит до реальной задачи — тут и всплывает — нифига они не знают. А еще оказывается и не только в перле не соображают.
  • +12
    ну я без запар ответил на эти ваши вопросы с пол пинка
    какова моя зарплата?

    таких вот топиков было уже миллион, и согласен я лишь с двумя мнениями:
    0) каждое собеседование — как игра, в которой правила строятся в процессе
    1) экзаменующий самоутверждается =)
    • +1
      Ответив на эти вопросы — 30 000 рублей.

      Что касается топика — ну, что ж, мне хотелось рассказать, кому-то будет интересно прочитать. Я вот с удовольствием читаю, какие бывают собеседования.
      • 0
        В каком городе?
        • 0
          Питер.
    • –1
      > ну я без запар ответил на эти ваши вопросы с пол пинка
      > какова моя зарплата?

      Пока что у Вас есть право заработать на еду и проезд в общественном транспорте. Вопросы-то тривиальные ;-)
  • –1
    я бы в конфиг не полез, я бы сделал phpinfo() и в выводе посмотрел _SERVER[«DOCUMENT_ROOT»]
    • 0
      У нас нет PHP. Еще будут варианты не лезть в конфиг? :)
      • 0
        вероятно более эффективных не будет
      • –1
        Навскидку: если определение дефолтного DocumentRoot:

        grep -i 'DocumentRoot' /etc/apache2/apache2.conf

        Коль ничего не дало (определенно, виртуальные хосты — в отдельных файлах) — копаем:

        grep -i 'Include' /etc/apache2/apache2.conf

        С большой долей вероятности даст строчку:

        Include /etc/apache2/sites-enabled/

        Ага. По-быстрому пробегаемся по директории:

        ls -l /etc/apache2/sites-enabled/ | grep 'test'

        Снова-таки, если… гм… «каноничъно» и упорядоченно называются конфиги — ответ в руках :)

        Да, это все с точки зрения Debian-like десктопной системы :)

        В реальных же боевых условиях вариаций весьма достаточно.
        • 0
          мой ответ подразумевал согласие с тем, что да, DocumentRoot надо искать в конфигах, а не в методе поиска в конфиге.
        • +1
          grep -r -i test.local /etc/apache

          И всё… и ничего больше искать не прийдется.
          Разве что отдается дефолтный хост и ServerName test.local нигде не прописан
        • +1
          Если разработка на перле, то с высокой вероятностью на сервере стоит FreeBSD и смотреть надо в /usr/local/etc :)
          • 0
            Как бы да, потому ж и сделал оговорку в конце :)
          • –1
            Я обычно, при компиляции, указываю альтернативную директорию для Apache, плюс chroot'ую её, поэтому оптимально будет написать:

            $ sudo grep -Ri «DocumentRoot» --color=always /
        • 0
          Ну, это уже читерство.

          А вдруг там не апач?
      • –1
        #!/bin/sh

        echo -ne «Content-Type: text/plain\r\n\r\n»

        echo $PATH_TRANSLATED

        где-то так, если мне не изменяет память
      • –1
        Вот такой вот вариант.
        #!/usr/bin/perl
        print «Content-type:text/html\n\n»;
        print $ENV{DOCUMENT_ROOT};
        • 0
          Я могу очень сильно ошибаться, поскольку с перлом не имел дела уже лет 10, но, по-моему, $ENV{DOCUMENT_ROOT} будет определена только если этот скрипт положить в эту самую DOCUMENT_ROOT (или какую-нибудь её дочернюю директорию) и вызвать из браузера :)
          • 0
            Да, вы правы :)
          • 0
            Да, дочернюю в контексте веб-сервера, а не операционной системы :-D
    • +3
      и куда бы Вы свой phpinfo положили? :)
      • 0
        :)
        более того, не факт, что там вообще есть php, раз разработка идет на перле
      • 0
        тут вы правы, не подумал )
  • +2
    Забавно. Мне сложно проецировать конечно с веб разработки на свою область, но примерно понимаю.

    Если бы мне на собеседовании предложили бы с помощью регулярок выдергивать email я бы честно сказал бы что за столь сложную задачу как написание корректного регэкспа для этого я никогда не возьмусь (в соответсвии с RFC) да и не вижу смысла изобретать велосипед, и если вы хотите поговорить со мной о моем знание регулярных выражений то давайте поговорим на более жизненом примере.

    По поводу test.local я бы тоже скорее бы не стал делать это все — а просто бы словами сказал что мол сначало то, потом то, потом то. Если нужно понимание этого досточно, а уж чисто практически нахождение конфига апача на конкретном сервере ИМХО значение не имеет.

    Что бы вы сказали на такие ответы? Мне очень интересно.

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

    Как бы вы отреагировали?
    • –1
      >Если бы мне на собеседовании предложили бы с помощью регулярок выдергивать email

      Выдергивать не надо, они там в файле построчно записаны. Одна строка — один email.

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

      — Вовочка, иди к доске, решай задачу: автомобиль едет со коростью 50 км/ч, за сколько времени он проедет 100 км?
      — МарьВанна, это неправильная задача, автомобили ездят с другой скоростью, и тупо из А в Б не ездят и вообще давайте че-нить реальное посчитаем типа денег.

      Вы же должны понимать, что мне не нужен результат, который получится в результате пятиминутных усилий кандидата, никакой практической пользы от него нет. Смысл — просто в проверке кандидата на умение работать с регуляркой, на знание спецсимволов, классов и вообще на знание способов использования регулярки. Еmail там будет или что угодно другое — не имеет никакого значения.

      >По поводу test.local я бы тоже скорее бы не стал делать это все — а просто бы словами сказал что мол сначало то, потом то, потом то. Если нужно понимание этого досточно, а уж чисто практически нахождение конфига апача на конкретном сервере ИМХО значение не имеет.

      Чисто практически получается так:

      — Ну а дальше смотрим в конфиге путь к директории (вот и все, вот какой я молодец, у меня есть понимание!)
      — Ну, давайте, смотрите. Какой же путь к директории?
      — Э… я не знаю… забыл директиву…
      — Подсказываю — DocumentRoot
      — Точно! Я знал! Э… че-то нету такой директивы…
      — Подсказываю — виртуальные хосты вынесены в отдельный файл
      — Э… а как это?..

      Поэтому я прошу сделать на практике. На словах-то у всех красиво получается.

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

      По шагам — хорошо. Десять раз проверить в браузере, десять раз переставить скобки в скрипте, ни разу не посмотреть в лог — плохо.
      • +2
        > Почти в 100% случаев результат получается такой:
        >
        > /\w+?@\w+?\.\w+?/
        >
        > Этот результат я считаю неудовлетворительным. Обычно в таком случае я задаю «вопрос на засыпку» — «какой > недопустимый символ пройдет эту проверку?». В ответ я хочу услышать «подчеркивание». Не отвечает
        > практически ни один.

        > Смысл — просто в проверке кандидата на умение работать с регуляркой, на знание спецсимволов, классов и
        > вообще на знание способов использования регулярки. Еmail там будет или что угодно другое — не имеет
        > никакого значения.

        Что-то не сходится. Программист обязан знать какие символы в Email недопустимы после "@"?
        • +1
          Веб-программист — да. Еще программисту неплохо бы помнить, какие символы «накрывает» спецсимвол \w.
          • 0
            Вы сами знаете RFC по email?
            • 0
              Дословно — нет, конечно. Вы тут пытаетесь поймать меня на словах, что, мол, программист прямо таки обязан знать этот RFC? Нет, конечно. Это справочные данные, не нужно их помнить наизусть.

              Но нужно знать, что есть определенные ограничения. А написав "\w", и получив вопрос «какой неположенный символ тут прокатит» неплохо бы сообразить, что "\w" накрывает не только цифры-буквы.
              • +1
                Порочная связка — изучать некую вещь на том примере который решать этой вещью не просто не нужно, а еще и вредно. Я вам об этом. Замените пример на другой.
                • 0
                  О каком изучении Вы говорите? Это не курсы, где я говорю «смотрите дети, емейл проверяется вот такой регуляркой, но тут надо помнить, какие буквы можно, а я не помню».

                  Это проверка — в состоянии человек написать регулярное выражение или нет, в состоянии он рассказать, какие спецсимволы он задействовал, или нет.
                  • 0
                    Пффф… ну не изучать, проверять.
                    Какая разница.

                    Речь идет о том что вменяемый человек на такую задачу в первую очередь скажет что инструменты не верны.
                    Это как заставить человека копать яму ложкой мотивируя тем что хочеться посмотреть как он умеет пользоваться ложкой.

                    Регэкспы проверять лучше на другой задаче. А то есть шанс что после вашего собеседования растроенный товарищь научиться проверять емаилы регэкспом и будет так везде делать.
                    • 0
                      Что-то я Вас не пойму. Вы мне хотите сказать, что email проверяется каким-то другим способом? Каким же?

                      И ради бога, не надо аналогий. А то я щас скажу, что правильная аналогия — это дать человеку бочку борща и смотреть, как он пользуется ложкой.
                      • –1
                        написать регэксп для email — это убийственно. поверьте, регулярное выражение занимает несколько листов и я ни за что не буду его использовать в прикладной программе. именно потому, это некорректное задание. и я бы так и сказал на собеседовании.

                        предыдущий автор как-бы нам на это намекает.
                        • 0
                          Написать полноценную программу — это убийственно. Что, теперь не проверять умение кандидата писать скрипты?

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

                          Вы лукавите. Либо Ваша прикладная программа будет работать с email'ами неправильно, либо Вы все-таки будете использовать это регулярное выражение.

                          >именно потому, это некорректное задание. и я бы так и сказал на собеседовании.

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

                          • 0
                            мое решение тут — использовать стороннюю библиотеку.

                            и если кандидат скажет так, то по моим критериям — ему плюс.
                            • 0
                              Сторонняя библиотека будет использовать это зверское выражение.

                              По моим критериям ему, конечно, плюс, но умение работать с регуляркой все-равно нужно будет продемонстрировать.
                              • 0
                                на том и порешили :)
      • 0
        Практика может быть очень разная в каждом отдельном случае.
        Я вот думаю, что с весьма высокой степенью вероятности вы бы сами не смогли с ходу стандартными средствами определить кто слушает 80 порт на локальной винде и тем более куда именно «он» установлен.
        Так что, по моему, если человек знает общий принцип — этого вполне достаточно, нюансы он посмотрит в мане по ходу.
  • –2
    И еще вопросы если не сложно. По поводу test.local и прочего. Для меня это звучит так как если бы нанимая программиста я бы его спрашивал бы о настройках среды программирования, о умении создать инсталятор, о уменее настроить сервера для работы его приложения, о умении дизайнить гуи и прочее.

    В моем понимании программист должен уметь писать код.
    SQL запросы должен создавать человек которые работает с sql сервером, настраивать апач должен администратор сервера и прочее, прочее.

    Не обязан хороший программист на Perl даже знать html — не его это задача. Как не обязан программист под винду уметь задизайнить хорошую форму — это задача специалиста по юзабилити.

    Не находите?

    Если вы ищите хорошего программиста то может спрашивть его именно о вещах связанных с программированием? А то по собеседованию я бы решгил что мне нужно не разработкой заниматься, а деплоиментом и прочими вещами.
    • –1
      Ну веб-программирование без SQL запросов вряд ли получится, а в проекте скорее всего html генерируется прямо из кода.
      • –5
        быдлокодер детектед
    • –4
      Веб-разработка так уж устроена, что там все это весьма сильно смешано.

      Программисту на Perl нужно уметь настроить Apache (администратор ничего не знает про такую штуку, как mod_perl), нужно уметь написать SQL-запрос (а как Вы, собственно, обратитесь к базе, даже если все навороченные запросы вынесены в хранимые процедуры? процедуру тоже нужно уметь запустить), нужно уметь выдать HTTP-ответ (XML, например).

      Да, бывают, конечно, крупные проекты, когда все эти спецы сильно разделены, но больше все как-то получается все-в-одном.
      • +8
        вам следует поменять администратора
      • 0
        А вам не кажеться что если намешенно то это не очень верно? Я не много видел веб проектов, но те которые видел за генерацию html не юзая шаблоны, за доступ к sql данным из скрипта, а не через соответсвующий класс прокси и прочее бы отрывали руки у программистов.

        Вообщем я понимаю желание получить и «жнеца и на дуде ловца» — как-то там. Сам бы от таких не отказался, но практика показывает что если мы набираем джуниоров (а судя по вопросам у вас имеено так), то пускай уж лучше знают хорошо что-то одно. И лучше пускай это будет программирование.
        • +1
          >Я не много видел веб проектов, но те которые видел за генерацию html не юзая шаблоны, за доступ к sql данным из скрипта, а не через соответсвующий класс прокси и прочее бы отрывали руки у программистов.

          Разве я сказал, что html надо генерировать без шаблонов? Об этом вообще речи не шло, к чему Вы это?

          Что касается SQL — а в классе он, полагаете, чудесным образом появляется?

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

          Ну они и знают программирование. От них не требуется настройка Апача в виде бэкенда под nginx, не требуется тюнинг операционки, не требуется разруливание доступа в базе данных. Просто как-то так уж сложилось в веб-разработке — связи довольно плотные и программист знает много побочного.
          • 0
            Нет не говорили. Я в качестве примера. Поймите я не наежаю на вас, просто хочеться понять что нынче называеться веб разработкой.

            > Что касается SQL — а в классе он, полагаете, чудесным образом появляется?

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

            А что вы делаете когда меняеться формат базы, проводиться нормализация и прочее, прочее. Каждый из людей вспоминает где он там писал запрос и лезет править? Или есть специальны человек который правит за всех?

            • –2
              >Правильно я понимаю что вот есть одна база, к ней несколько скриптов которые далют разные люди. Эти люди когда им нужно получить данные каждый пишет свой Sql запрос?

              Есть некоторый набор стандартных запросов. Типа «получить список клиентов». Такие запросы написаны давно и засунуты в модуль Clients. Получение списка клиентов выглядит как вызов @clients = Clients::get_clients().

              И есть, допустим, всякие отчеты, которые меняются/добавляются/удаляются c некоторой периодичностью. Запросы для таких отчетов пишут разные программисты. «Сидоров — тебе сделать отчет по выручке, Петров — тебе отчет по расходам.»

              >А что вы делаете когда меняеться формат базы, проводиться нормализация и прочее, прочее. Каждый из людей вспоминает где он там писал запрос и лезет править?

              Ну как придется. Если каждый вспомнит что именно он писал — ну, прекрасно, может и исправить. Не помнит — ничего страшного, любой другой может исправить.
      • +1
        администратор ничего не знает про такую штуку, как mod_perl
        Господи, как страшно жить.
        • 0
          Тут просто некоторое недопонимание.

          Я рассказываю не про айтишную компанию, в которой толпа спецов и каждый отлично знает свое дело. Я рассказываю про медицинскую компанию, для которой я (в данный момент) делаю проект. У них нет админа, знающего mod_perl. Они не будут нанимать его только потому, что я решил использовать mod_perl. Поэтому я сам настраиваю Апач и не вижу в этом проблемы.
          • 0
            Т.е. медицинская компания разрабатывает in-house?
            • 0
              Да, это внутренний продукт, для себя, своими силами.
    • 0
      хороший программист вообще в целом отличается от плохого тем, что видит задачу чуть дальше кончика своего носа.

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

      если программист хороший, то он наверняка умеет и может в той, либо иной степени справиться с каждой из этих задач, поскольку их решение относится к логике и неким минимальным знаниям.
    • 0
      Не совсем так. Если подходить к вопросу именно так, как вы говорите — мы получим американского инженера, который специализируясь автодвигателям, не в состоянии починить розетку.

      Специализация хороша, но до определенного момента.

      Специализация без знания основ ведет к регрессу.
  • +1
    По вопросам, хотя я вообще не программист :)
    1. Пошел читать про HAVING. Никогда не юзал.
    2. А что, у вас программисты настраивают апач? работают непосредственно с файлами которые обрабатывает web-сервер? Всегда думал, что использование CVS и скриптов-инсталяторов для выкатки на вебсервер необходимы, если с проектом работает несколько человек.
    Как по мне, то программисту вообще нельзя знать путь по файловой системе. Пусть пишет с относительными путями.

    Хотя вопрос правильный. Настоящий программист конфигурял апач, хотябы для локального проекта… но это не их дело…
    Хотя с другой стороны — нельзя писать приложение незная как работает сервер.
    А кто нибуть делал из программистов хотябы grep, для поиска нужного файла конфига или втупую открывали и читали начиная с httpd.conf? :)

    3. Кто сказал, что "_" — (подчеркивание) недопустимый символ в email?

    Почему Вы не используете на собеседовании логические и математические задачи? Они помогут понять есть ли мышление и смекалка. А технологиям и обучить можно… Или используете?

    • 0
      символ подчеркивания недопустим после собаки.
      да и первым, ЕМНИП, он не может быть.
      • 0
        У до сих пор есть ящик на mail.ru, где первым символом является подчеркивание — зарегал еще тогда, когда это было можно.
        Как-то вроде работает (не знаю, давненько не проверял вообще), но иногда бывали проблемы с почтой.
    • –2
      >А что, у вас программисты настраивают апач?

      Настраивают. Что тут такого? Умеют и настраивают.

      >работают непосредственно с файлами которые обрабатывает web-сервер?

      Не понял.

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

      В контексте топика я не понял, к чему относится этот вопрос, но вообще — да, с проектом работает несколько человек, и спользуется система контроля версий.

      >Как по мне, то программисту вообще нельзя знать путь по файловой системе. Пусть пишет с относительными путями.

      Это для какого-то автономного скрипта. Система, управляющая файлами пользователей сервера просто вынуждена знать пути:)

      • 0
        >А кто нибуть делал из программистов хотябы grep, для поиска нужного файла конфига или втупую открывали и читали начиная с httpd.conf? :)

        Зачем? Местонахождение конфига Apache и так известно. А то, что виртуальные хосты вынесены — это нельзя догадаться, пока конфиг не прочитаешь.

        >Почему Вы не используете на собеседовании логические и математические задачи? Они помогут понять есть ли мышление и смекалка. А технологиям и обучить можно… Или используете?

        Нет, не использую. Я считаю, что это бессмысленно. Мне не нужны абстрактые мышление и смекалка, я не студентов на курсы набираю, мне нужны люди способные решать поставленную задачу. Учить мне их тоже некогда да и незачем — ко мне приходят уже умеющие, и я беру именно их.
  • +3
    Подход годится для ремесленников, обладающих нужным опытом здесь и сейчас. Супер-пупер спец в зрелости будет для вас дорогим и лишним, в молодости пролетит мимо.
    • 0
      Да. Такова специфика работы. Будь я владельцем айтишной компании с планами на годы, я бы все делал несколько иначе. Мне же нужны конкретные спецы для пыполнения конкретных проектов на конкретное ремя и за конкретные деньги.
  • +4
    use Mail::RFC822::Address qw(valid);
    
    if(valid('test_user@example.org'))
    {
        print "That's a valid address\n";
    }

    -->
    That's a valid address
    • –3
      Плюс за знание модулей с CPAN. Но свое личное знание регулярки все-равно нужно показать.
      • +1
        Тут не про наше знание, а про ваше незнание :)
        • 0
          Незнание чего?
          • 0
            Он про подчеркивание в email. Люди хотя на собеседования где их просят регэкспами парсить email, а потом выясняеться что почта вида blah.bal@dome не проходит валидацию. Или более сложные варианты.
            • 0
              А!
              Ну, пусть проверит test_user@e_xample.org
              • +1
                use Mail::RFC822::Address qw(valid);
                
                if(valid('test_user@e_xample.org'))
                {
                    print "That's a valid address\n";
                }

                -->
                That's a valid address
                • +2
                  Поздравляю. Вы нашли баг в модуле. Напишите Полю Варрену (автору модуля), чтобы он перечитал RFC 1034 и 1035, регламентирующие разрешенные в доменном имени символы.
                  • 0
                    > регламентирующие разрешенные в доменном имени символы.

                    Практка немного впереди этих RFC. На практике встречаются такие домены. Вот, к примеру, что сказано в squid.conf:

                    #  TAG: allow_underscore
                    #       Underscore characters is not strictly allowed in Internet hostnames
                    #       but nevertheless used by many sites. Set this to off if you want
                    #       Squid to be strict about the standard.
                    #
                    #Default:
                    # allow_underscore on
                    • –1
                      squid.conf — это не авторитет в DNS. Вот когда такие комментарии будут в named.conf — вот тогда да, будет о чем говорить.
  • +2
    опять садо-мазо. ну сколько можно?! дедовщина?

    нужно беседовать с кандидатами а не экзаменовать. ну хорошо, он не знает having — это как вы говорите «большой минус». Ну неужели вы считаете что разобраться с как обрабатывается оператор having займет больше 20-60 минут?

    кстати почему ни слова про javascript и при этом про перл аж превалило?
    • +2
      А в чем, собственно, проблема? Вы предлагаете мне тянуть кандитата, как троечника в школе, в надежде, что он потом со всем разберется? Зачем мне это? У меня за дверью переговорной сидят три других, и среди них будет тот, кто знает то, что мне нужно.
      • –1
        сурово. я ж говорю — Армия. :)
        • 0
          Ну да, в каком-то смысле:)
    • +1
      Да тут выше написал Becoming_Insane:
      0) каждое собеседование — как игра, в которой правила строятся в процессе
      1) экзаменующий самоутверждается =)
      Я —— ведущий разработчик. Напишу-ка я статью о том, как я рулю на собеседовании, а что соискатели все расстраивают по сравнению со мной, ведущим разработчиком.
      Было тысячу раз. Главное условие — одинаковое строение мозга с батьком в маленьком списке вопросов. Рандом.
      • 0
        Не понял претензию. Мне вот интересно читать, какие бывают собеседования в других местах. Мест много, вариантов собеседований тоже. Кому-то интересно будет прочитать мой вариант. Вон, люди про HAVING узнали и задачку порешали.
  • +3
    Ужас. Одни узнают про HAVING на хабре, другие говорят, что уже забыли, когда последний раз его использовали. Все-таки чувствуется огромная разница между разработчиками вебовских и больших корпоративных баз данных. Поддержка последних зиждется на использовании всего функционала, предоставляемого СУБД (за исключением случаев, когда вводится ограничение на стандартный синтаксис языка SQL).

    Все-таки с HAVING моя жизнь чуть-чуть проще.
    • –2
      ну если верить нескольким сообщениям выше — для «больших корпоративных баз данных» HAVING совершенно не подходит, только для незначительных запросов, а потому — понт не удался.
      • +1
        причем здесь понт.
        jinxal правильно написал. при работе с большими объемами данных для быстрого и эффективного решения задач просто необходимо знать и применять все возможности и функции используемой СУБД. средний запрос там занимает обычно больше 20-30 строк и это нормально. потому что идет работа с десятками связанных таблиц и гора условий и фильтров.
        если говорить о HAVING — его использование(при необходимости) помогает строить запрос с минимумом кода, не занимаясь перегрузкой запроса лишними подзапросами, так как они только читаемость ухудшают.
      • 0
        Почему ж не подходит?
    • +1
      разница прежде всего между разработчиками функционала и разработчиками баз данных. но если уж у автора в компании программисты настраивают апач и пишут регулярные выражения для проверки e-mail, то о чём тут дальше говорить? надо разворачиваться и уходить, у автора там ещё три человека за дверью ждут.
  • 0
    Автор, спасибо за статью, весьма познавательно для меня на будущее. Теперь буду примерно знать в каком направлении двигаться :)
  • 0
    «2) Проверка знания рабочего окружения» — рассмешило, представьте ситуацию что, test.local обслуживает сервер на котором установлен Front-End'ОМ nginx или lighttpd, замечательно, ну попингуем мы его получим адрес этого хоста, а дальше? будем лезть в конфиги искать адреса/пути — это лишняя трата времени, а если это ещё и HiLoad проект то наверняка Back-End'Ов будет не один сервер и чего? Мне интересно как бы Вы поступили в такой ситуации?! Нужно к каждому проекту вести документацию, это как минимум. Да вопрос бесспорно стоит внимания и человек должен понимать какими механизмами/средствами можно разрешить тот или иной вопрос.
    • 0
      Ну и в чем проблема, если там фронтенд?

      Кандидат не знает, как работает схема фронтенд-бэкенд? Очень плохо.
      Знает и может разабраться? Прекрасно.
  • +2
    Не хочется хвастаться, конечно, но я бы ответил на все вопросы :)

    Я когда набирал разрабов, я просто просил написать некий код и прислать мне. До чего же я был удивлен, что 99% людей не могут нормально написать код дома, когда есть и гугл и мануалы под рукой. Просто по качеству кода и вниманию к мелочам я могу уже стопроцентное мнение о кандидате сложить.

    Про HAVING.

    Часто приходилось видеть код, когда люби делали выборку, а потом обрабатывали ее в программе. Знали бы они про HAVING — такого бы делать не пришлось.

    Я лично люблю делать такие запросы, чтобы получать такую выборку, которую потом как можно меньше нужно обрабатывать в программе. Наиболее простой пример, когда вам нужно получить только кусок текста, так лучше его обрезать в запросе, а не получать целиком и потом обрезать.
    • 0
      Ну, если отрезать на определенно кол-во символов то можно, если же к примеру нужно скрыть данные пользователя после @ в email, то mysql такой запрос выполнит в 4-5 раз медленнее, чем я просто отрежу это кодом.
      • 0
        Да, я именно про простые случаи говорил.
  • 0
    в принципе хорошее базовое собеседование которое пройдет начинающий веб перл разработчик который написал хотя бы один скрипт с БД
  • 0
    Знатоки HAVING, подскажите в чем проблема, для моей таблицы выводит 0 строк при использовании HAVING

    SELECT depno, count( * ) AS count
    FROM emp
    GROUP BY depno
    HAVING count=max(count)

    Смысл, посчитать количество сотрудиков по отделам, и вывести отделы с самым большим количеством сотрудников )
    Без HAVING выводятся результаты нормально.
    • 0
      Вы тут пытаетесь сделать HAVING по HAVING'у:)

      HAVING не выполняет групповых операций, все групповые операции должны быть выполнены до того, как начнет работать HAVING. HAVING применяется к уже вычисленным групповым операциям.

      • –1
        >> HAVING применяется к уже вычисленным групповым операциям.

        пожалуйста, будьте точнее в словах, не вводите людей в заблуждение (невольно или по незнанию — не знаю). Итак многие не знают этого оператора.

        HAVING не применяется к групповым операциям, он вообще к ним никакого отношения не имеет. HAVING применяется к результату запроса, т.е. это как бы WHERE, только уже накладываемый на результат. Есть в запросе GROUP BY/DISTINCT или нет — неважно, так вот тоже можно

        SELECT * FROM table
        HAVING id = 5


        (Любой желающий посмотрев explain такого запроса увидит, что будет обработана вся таблица, а потом клиенту отдана одна строка, тогда как с WHERE будет заюзан индекс)
        • 0
          Да, конечно. Просто тут обсуждение идет в контексте группировки, поэтому я не стал вдаваться в детали.
        • 0
          SELECT * FROM table
          HAVING id = 5

          Из всех имеющихся в наличии СУБД у меня это сработало только в MySQL.
          В Oracle и MS SQL это не работает. Есть кто с PostgreSQL?
          • 0
            MySQL позволяет слишком много вольностей. PostgreSQL такого не разрешает.
        • 0
          О сколько нам открытий чудных…
          Разработчики Mysql вообще в курсе о существовании стандарта SQL?
        • 0
          billing=# select * from tasks having id > 5;
          ERROR:  column "tasks.id" must appear in the GROUP BY clause or be used in an aggregate function
          СТРОКА 1:select * from tasks having id > 5;
                          ^
          billing=# 
          

          Если MySQL позволяет так делать, это еще не значит, что так можно :)
          • 0
            Это Postgres, кстати.
    • 0
      > вывести отделы с самым большим количеством сотрудников )

      В какова нижняя граница? Вопрос-то не очень корректен)
    • +1
      Думаю, это то, что вам нужно:

      SELECT
      depno,
      count(*) AS `cnt`
      FROM emp
      GROUP BY depno
      HAVING `cnt` > 2
      ORDER BY `cnt`

      Что означает, вывести все номера отделов, в которых более 2-х сотрудников, отсортированные по кол-ву сотрудников, по-убыванию.
    • 0
      Я выше, совершенно не в кассу, написал запрос — это как раз ваш случай. Параметром LIMIT опередяется какое количество вам нужно. Если вы опечатались в описании задачи (судя по запросу) и хотели получить отдел(один!) где больше всего сотрудников, то вам LIMIT 1.

      Если несколько — то неясен критерий («самые большие» n-отделов или с числом сотрудников > n).
      • 0
        про LIMIT 1 я знал, но я имел введу если например два отдела с самым большим количеством сотрудников например 5, то вывести именно два отедла а не один
  • 0
    Странно немного, по-хорошему, вы бы проводили первичный отбор кандидатов по резюме.
    Например, если человек учится на факультете гостиннично-ресторанного бизнеса, в прошлом году работал вебмастером, и только половину этого года — «писал скрипты на пхп для кмс жумла» — то такого в серьезную контору приглашать на собеседование вряд ли имеет смысл. Я собеседую программистов (со стороны «отдела кадров»(С)), около 15-ти человек за полгода устроилось. При том что собеседований было около 50-ти: так вот может только 1-2 засыпались на «простых» вопросах. Остальные если и сыпались, то на гораздо более сложных вещах.
    • 0
      Это уже отобранные кандидаты. У каждого в резюме «хорошо владею» и опыт работы по теме.

      Просто у Вас, вероятно, изначально требования жестче. Например, зарплата сразу указана большая и поэтому приходят более опытные люди. У меня требования не очень высокие и зарплата не большая.
      • 0
        У нас «отличное знание ПХП, ООП, МуСКЛ, опыт работы не менее 2х лет, опыт разработки высоконагруженных систем».
        Ну, в принципе да, наверное.
  • +1
    habrahabr.ru/blogs/sql/27639/

    возьмете? :)
    • 0
      (грозным голосом) Почему там не используется HAVING?!

      :)
      • 0
        :)
      • 0
        Аналитические функции допустимы только в выражении SELECT :-)
        • 0
          Тест сдал:)
  • 0
    Многие, написав скрипт «hello world», вызвав его из браузера и получив ошибку 403 Forbidden, встают в тупик. Я не знаю, как так получается, но многие не в курсе того, что скрипт нужно сделать исполняемым. А кто в курсе — те часто не могут вспомнить команду смены прав доступа chmod.

    Возможно вы имели ввиду ошибку 500. 403 — это когда авторизацию сервера не прошел. А 500 — это внутренняя ошибка сервера.
    • 0
      403 — это когда нет доступа к указанному ресурсу. Непройденность авторизации — это только одна из причина отказа в доступе. Отсутствие у файла права на выполнение — это другая причина отказа в доступе.

      А 500 — это уже потом, если в исполняемом файле будут обнаружены ошибки.
      • 0
        Apache/2.2.11 (FreeBSD 7.0)

        Создал файл:
        #!/usr/bin/perl
        use CGI qw(:all);
        print header;
        print 1;

        Права у файла 644. Обращаюсь через браузер и получаю 500 ошибку. Меняю права на 755 и браузер выводит 1.
        Попробуйте сами.
        • 0
          Ну, готов поверить на слово, что Apache2 так делает. Apache1.3 выдает 403.
          • 0
            Может поэтому и встают в тупик? :-)
            • 0
              500 там, или 403 — в любом случае файл надо сделать исполняемым. И в лог не помешает заглянуть, посмотреть, чего там не так.
        • 0
          Не в курсе про mod_perl, но для mod_php не нужно делать файл исполняемым.
          А вот в случае с CGI будет 500, т.к. Premature end of script headers — у Вас не CGI часом?
          • 0
            Разумеется для mod_perl не обязательно делать файл исполняемым. Я говорил про CGI, также как и автор топика.
            mod_perl, насколько мне известно, через suexec не провести, поэтому если ты пользуешься виртуальным хостингом, то использовать можешь только cgi.
  • +1
    > Результаты собеседований меня неизменно расстраивают. Подавляющее большинство кандидатов ужасны.
    Можно перед приглашением на собеседование запросить примеры кода у человека, а возможно, и попросить решить заочно небольшую практическую задачку. На среднемировое качество кандидатов это, конечно, не повлияет, но снизит их количество раз в 5-10, а следовательно — будет и расстраивать меньше.
  • 0
    /\w+?@\w+?\.\w+?/
    Обычно в таком случае я задаю «вопрос на засыпку» — «какой недопустимый символ пройдет эту проверку?». В ответ я хочу услышать «подчеркивание». Не отвечает практически ни один.

    какой, допустимый символ, не пройдет эту проверку? =)
    • 0
      Это слишком очевидно, их дофига. Вот один недопустимый — это интереснее:)
      • 0
        так и в вашем варианте их так же дофига. вот строка:
        ivanych@vacancy.test@эта пров3рка п0лная %$#ня.
        каков же вывод? ^)
        • –1
          Вы не поняли. Это не мой вариант, это вариант от кандидатов, я этот вариант считаю неудовлетворительным.
  • 0
    Что за дурацкая привычка спрашивать регулярку для email?
    Можно и не только валидировать через ругулярку
    search.cpan.org/~rjbs/Email-Valid-0.182/lib/Email/Valid.pm

    Ещё календарь на SQL спросили бы.

    Я например mod_perl и Апач видел последний раз 4 года назад. Как-то больше пишу под fastcgi + nginx, lighttpd
    Можно ещё по спрашивать
    1.Писали ли вы модули для cpan.org
    2.Каким вы шаблонизатором пользуетесь.
    3.Каким модулем вы разбираете XML
    4.Что означает оператор ~~ (это так для тех кто продвинут в перл)
    5.Что нибудь про Data::Dumper;

    • +2
      Критика? Ну, ок.

      >Что за дурацкая привычка спрашивать регулярку для email?

      Постулируете что-то — приводите доказательства. Я полагаю вопрос про регулярку для email замечательным, если Вы возражаете — будьте добры обосновать свою точку зрения.

      >Ещё календарь на SQL спросили бы.

      Это абстрактная головоломка. Я там выше русским по белому написал — головоломки я не загадываю.

      >Можно ещё по спрашивать…

      Можно. И спрашиваю.

      Ну, а теперь моя очередь критиковать.

      Что за дурацкая привычка писать так, что вообще непонятно, что хотели сказать?

      >Можно и не только валидировать через ругулярку

      Что это значит? Что с помощью регулярки можно не только валидировать, но и еще что-то делать? Что именно? Я должен теперь перечитать весь модуль и сделать предположения о том, что именно Вы имели в виду?

      Или Вы имели в виду, что валидировать можно не только регуляркой, но криво изложили мысль? А почему тогда не исправили написанное? И валидация там, кстати, делается регуляркой.

      Программисты с таким запутанным изложением мыслей меня пугают больше, чем те, кто не знает оператора HAVING.

      Похвастались fastcgi? Ну, отлично, дали лишний повод задать вопрос на засыпку:

      Зачем вообще нужен fastcgi? Зачем Вам лишний элемент в связке фронтенд-бэкенд? Что мешает Вам проксировать HTTP-запрос сразу на бэкенд, не оборачивая его в fastcgi?

  • 0
    Вы злой, и аватарка у вас страшная… Шутка:) Оч. полезно. В этой сфере не кручусь, но многое знал.
  • 0
    у автора явно завышено ЧСВ. если видишь такого собеседующего, и есть другие варианты, надо попрощаться и уйти. ибо нервы, как и хардварные бэды — не восстанавливаются.

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

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

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

    Всёравно спасибо, ivanych, за потраченное на меня время и пинок под зад в нужном направлении саморазвития!

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