Pull to refresh

Comments 142

Вы ведь даёте людям при этом пользоваться интернетом?
Думается, что задача номер 3 точно не для «Senior PHP», а каких-нибудь «Junior PHP».
Вообще Senior PHP должен уметь решать сложные задачи правильно проектировав структуры объектов, данных, вызовов и т.п. архитектур. Поэтому не совсем ясно что призваны выявить данные вопросы?
3-я задача, скорее, для Junior MySQL :)

А вот про вторую… Чего-то я не понял… При чем здесь PHP?

2-я задача на владение unix'ом и не имеет ничего общего с программированием на PHP. Много лет писал на ПХП. Сложные вещи. Но никогда не знал, как добавить выполнение какого-то скрипта в крон — это всегда было задачей админа. Прописать в крон, выставить какие надо права…
то что это задача админа не отменяет того факта, что немного знать средства среды нужно.
скорее всего человек который давно программирует знает что такое крон.
ведь автор не предлагает слиться на первой минуте разговора, пока речь не дошла до кронтаба, и не пришли к мнению, что там только по минутам, еще не конец вопрос. конец настал, тогда, когда человек не придумал простейшего варианта например запускать другой скрипт каждую минуту, который будет запускать в цикле N раз скрипт с задержкой в 13 секунд.
правда этот вариант несет в себе много проверок излишних. и необходимо знать насколько важно попасть именно в 13 секундный интервал(а то ведь десят-пятнадцать тоже может устроить).

Большинство моих проектов используют Windows (ну, вот так надо). Серверные решения на Linux я знаю плохо. Я в принципе бы не ответил на вторую задачу.
Хотя, прошу прощения, на винде я б смог реализовать ^^
runas /netonly /user:WORKGROUP\Сергей-ПК «rundll32 url.dll,FileProtocolHandler mail.ru/»
Когда шел ответить, на почте прочел только первый комментарии и хотел написать что в любой среде есть средства для реализации.
но Вы уже сами нашли вариант.
я бы не использую гугл, решил бы под виндой это так. запустил бы демона, как вариант снимаем ограничение на время работы скрипта и запускаем в цикле.
это к тому, что вариант всегда есть. и важно понять ищет его человек или нет.а не зная варианта как он выкрутится, ведь задача должна быть сделанна, либо должен быть предложен обходной вариант. вот такие люди на работе нужны.
Правда я скосячил: открывается в браузере по умолчанию =)

Проще было бы сделать обычного демона…

Но вот на третий вопрос я бы не ответил, если честно, т.к. в БД немного плаваю и пользуюсь стандартными запросами (учился на лету, так что мне учиться еще и учиться).
учи-учи. потому что в большинстве своем веб-программирование. это есть работа с базой. чаще всего задачи именно такого плана достать из базы показать, показать получить записать.внимание! УДАЛИТЬ Ж-).
нет тут как такового: разработки алгоритмов, сложных вычислений. и прочего присущего программированию в некоторых языках.
поэтому задача нормализации базы это первичная задача, потом за ней правильного написания запросов. а далее за ними оптимизация запросов и кэши. потом денормализация. (но это уже на этапе тяжелых баз)
конечно парралельно, основная задача программирования на пхп Ж-): писать легкочитаемый код.(для группы программистов, для себя можно писать по сути как попало, но один раз запустишь этот вопрос потом тяжело будет вернуться обратно)
Спасибо, что объяснили мне то, что я знаю.
ну не надо так нервничать. и минусовать в карму за заботу о людях.
если мое сообщение было для Вас бесполезным, я думаю от этого никто не пострадал.а если Вы так раздражаетесь, по таким пустякам, то я даже не знаю стоили вступать в обсуждение, того что Вы знаете или нет.
ладно я могу писать много. но это добавит только минусов.
тяжелая пятница выдалась…
Под виндой можно использовать порт wget и назначенные задания :-)
Не гуглить — глупость.
Чем лучше кандидат гуглит — тем сеньйористей из него сеньйор…
Кстати, то КАК кандидат гуглит тоже позволяет сделать некоторые критические выводы
Согласен по поводу общего умения пользоваться информацией в интернете.
Хороший специалист не тот, кто все умеет, а тот, кто может найти нужную информацию и правильно ей воспользоваться.

Хотя, приведенные выше задачи достаточно просты что бы решить их без поиска. Уж набросать план действий можно легко.
Разве что, задача 2 требует чуть-чуть дополнительных знаний в сторону от Web-PHP, но все равно не так сильно сложна что бы начинать что-то «гуглить».
Согласен 100%. некоторые кандидаты спрашивают «можно погуглить?» я говорю «можно, только скажи что вбиваешь в гугл».
А задачи то элементарные… Вы если в Нижегородской области решите вдруг филиал открыть -дайте знать, приду устраиваться =)

И мне одному кажется что все же на Senior PHP это не тянет?
У нас работа удалённая. Эти вопросы — лишь начало. "… Если кандидат предлагает какое-то простое решение,… я усложняю условия, например говрю «логи выключены», или «давайте использовать базу», или «а сколько уникальных?». "
Правильный кандидат сначала спросит полные условия вопроса, а потом уже приступит к решению.
Жизнь учит, что начальные условия по мере работы изменяются, поэтому первая формулировка задачи и есть полные условия. Последующие усложнения вполне тянут на коррективы вносимые в проект в процессе его жизненного цикла.
если у меня бы кандидат спросил «можно по-гуглить», я его не раздумывая принял бы в работу, как человека, которые всегда найдет решение в отличии от индивидуумов, которые на собеседовании пытаются показать какие они крутые перцы с лицом, необезображенным интелектом.
Мне эти задачи не кажутся сложными? ЧЯДНТ? Гуглить тут нечего, хотя я считаю, что умение гуглить тоже важно.
Исключение — 3 задача. Мне понадобилось написать пару запросов и после этого она была решена.
Хотя нет — вру. В 3й тоже все элементарно. Где вы таких программистов находите?
В том то и дело, что эти простые задачи отсеивают 9 из 10 Senior PHP
Афайк, «Senior PHP» — это человек, который знает PHP на довольно хорошем/высоком уровне. А таких отсеивать подобными задачами — все равно что отсеивать плотника вопросом «ты можешь забить гвоздь?» Лучше бы задавали вопросы по оптимизации, паттернам, масштабируемости, умению работать с какими-либо фреймворками. Эти три вопроса могут отсеять только тех, кто на PHP ничего толком не писал, либо у кого самомнение выше IQ.
Да, и среди прочего нужно учитывать умение находить и усваивать информацию. Если кто-то чего-то не знает, но может быстро узнать это (найдя где-нибудь или раскопав код), это будет лучше, чем всезнайка, отрицающий мануалы.
Как можно знать «на высоком уровне» не зная основ? Такие программисты рождаются со знанием архитектурных паттернов? А оптимизировать низкоуровненвый код под высокие нагрузки кто будет? джуниор?
Каждый плотник умеет забивать гвозди, ибо это — основа. Но мастер может собрать дом без единого гвоздя, а новичок забьет этот же гвоздь, только погнув два других. Нет смысла отбирать Senior Кого-То-Там, задавая вопрос «ты можешь забить гвоздь?» Надо спросить «ты можешь собрать дом?»
Дело не гораничивается лишь этими 3мя вопосами. Я же написал, если кандидат предагает хоть какое-то решение, я начинаю усложнять, чтобы понять, может он «построть дом без гвоздей» или он просто мастер по забиванию :) Например первый вопорс можно «довести» до условий когда у нас распределенное приложение, а изображения кешируются на прокси.
> Как можно знать «на высоком уровне» не зная основ?
Да ладно вам, может это PHP-джедай, который использовал только NoSQL решения? :)
Я вот сходу не вспомню, как выставить корректные заголовки для любого изображения, скрытого за banner.php.

Второе решение можно сделать через sleep, но это не очень хорошо. Лично я не сталкивался с посекундным запуском задачи, потому даже не задумывался над этим. Как бы вы решили этот момент?

Третий как раз достаточно просто, учитывая, что у нас есть таблица author_id=>book_id, сгруппировать по book_id и посчитать author_id, но с таким решением при большой базе будут тормоза.

А как вы «элементарно» решили эти задачи?
1. header('Content-Type: image/jpeg');
А вообще, тут другое надо было. Определение количества уникальных посещений действительно лучше сделать с помощью сессий или кукисов. А хранить лучше всего это в NoSQL базе данных.
2. Самое простое — использовать не cron, а anacron.
3. Три таблицы: authors, books и authors_books. В первой и второй ключи author_id и book_id соотв. Третья состоит из двух колонок author_id и book_id, которые вместе являются составным ключом.
1. А если banner.php отдаёт png?

2. Я никогда не слышал про anacron. Я — плохой php-прогер?

3, это элементарно. а запрос где?
1. Написал для примера. Если у вас png — ставите image/png. Если gif — image/gif. И так далее. Если содержимое просто берется из какого-то файла — можно проверить его расширение и установить тип содержимого по нему.
2. А подобные задачи вообще не из области php. Этим системных администраторов проверять можно :) А про anacron я нашел в википедии, по ссылке со страницы cron.
3. Просто влом писать :-)
1. ИМХО под такие вещи надо использовать соответствующие инструменты вроде C++
2. Аналогично
3. Присоединяюсь к вопросу
SELECT b.book_name, COUNT(*) cnt
FROM authors_books ab
JOIN books b USING (book_id)
GROUP BY book_id
HAVING cnt >= 3;

На какую зп я могу рассчитывать? :)
Если там многие-ко-многим то 2-мя таблицами не обойтись, иначе будут одинаковые записи о книгах с разными авторами.
Лучше использовать 3 таблицы. Авторы, Книги и связная таблица.
Я и не говорил, что там 2 таблицы. Там 3 таблицы на самом деле (authors_books — это и есть связная таблица), просто авторов я не стал выбирать (в условии сказано — получить отчет «книга — количество соавторов»)
на этом собеседование не заканчивается а чаще всего только начинается :) если Вы справились скажите — что, если у нас огромная таблица, а запрос нужно выполнять каждые 3 минуты? Что можно сделать?
Вариантов много. Навскидку:
— кеширование;
— денормализация базы;
— NoSQL;
Производительность — плачевная.
Про производительность в условии ничего не было сказано. Это уже, как говорится, другой вопрос :)
Как вариант — денормализация. Всё зависит от конкретных условий и требований
Ну так в условиях часто много недосказанно, с расчётом на посмотреть, как это будет решать автор.
Когда недостаточно информации — невозможно придумать оптимальное решение. Я исхожу из того, что есть и придерживаюсь правила «не усложняй без необходимости». Когда появятся дополнительные условия — решение можно будет пересмотреть
Сходу примерно так:

SELECT b.name,count(b.bookid) AS cnt FROM t_books AS b,t_authors_books AS ab WHERE b.bookid=ab.bookid GROUP BY b.bookid HAVING cnt=3

P.S.: В задаче написано «у кого три соавтора», а потом про фильтрацию сказано что три и больше. То есть, если три и больше, то просто будет «HAVING cnt>2»
2. Самое простое — использовать не cron, а anacron.
насколько я вижу в манах по анакрону там период в минутах измеряется
Пардон, подумал, что интервал 13 минут, а не 13 секунд. Тогда могу предложить еще два варианта:
1. Вызывать скрипт каждую секунду через crontab, в начале скрипта написать что-то типа этого:
if (time() % 13) return;

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

#!/bin/sh

while true; do
/path/to/php /path/to/file.php
sleep 13

done
* * * * * /script
* * * * * sleep 13; /script
* * * * * sleep 26; /script
и т.д. можно такой вариант еще.
а разве крон вам позвонит запускать с интервалом меньше 1 минуты?
Если допилить напильником — да. И anacron наверняка тоже. Без напильника — вряд ли. Но ведь можно же? :-)
Если бы задачи ставились четко, а не «а если будет так, а если так», я бы в таблице с книгами добавил поле count_author и по нему бы сортировал.

Терпеть не могу такие вот задачи с вымышленным будущем
кому как =)
я не претендую на звание Senior PHP.
но погуглил бы вторую на вариант решения без программирования (мне было бы полезно найти готовый посекундный крон), хотя скорее написал бы код на JavaScript (я про Node.js)
а решать третью несколькими запросами Senior SQL не будет =)
Почему-то задачи 2 и 3 больше похожи на задачи при приеме на работу системного администратора и DBA соответственно. Либо вам нужен всё таки не Senior PHP а человек-оркестр, что немного разные вещи.
если ко второй подходить с точки зрения программирования (если не искать аналоги крона), то в ней нет ничего выходящего за рамки программирования на РНР.
а третья — слишком проста, да и вообще — писать запросы к БД — обыденность практически всех кодеров.
Может быть имели ввиду вакансию Senior LAMP Developer?
Вам не хватает еще одной подобной задачи, чтобы отсеивать 10 и 10 кандидатов.
Память человека устроена так, что он хорошо помнит только то, чем занят постоянно. И если он перестает работать с какой-то технологией/фреймворком/реализацией и т.д., то постепенно начинает забывать её. Сначала тонкости, а потом и более базовые вещи.

Например, я где-то около полугода не писал запросов на SQL и не работал с MySQL — и на третий вопрос я вот так сразу не отвечу. Т.е. я себе представляю структуру запроса и знаю где я могу быстро посмотреть тонкости, но вот взять и написать запрос сразу не смогу. Это не значит, что я плохо знаю SQL вообще и MySQL в частности. Если мне придется с ними работать, то я очень быстро «вспомню» все тонкости и ньансы. Просто сначала я буду работать не на все 100%, а поменьше.
Отличные вопросы! Многим стоит взять на заметку. Но надеюсь вы понимаете, что многие из тех кто не ответит на ваши вопросы, подготовившись, тоже смогут придумать три таких же какбы real life вопроса на которые вы сходу не ответите. ;) Еще я считаю, что всегда необходимо как можно подробнее до собеседования рассказывать кандидату, что от него хотят услышать и к чему следует быть готовым. В конце концов все гуглится и решается, а вот хорошие и полезные человеческие качества не подучишь и не нагуглишь.
Самые главные качества — умение решать проблемы самостоятельно и умение докопаться до сути, а не спустить всё на тормозах и сделать заплатку (хотя её тоже важно сделать =)). Вот как выявить их — это уже дельный вопрос…
Решил все три. Могу ли я считать себя Senior PHP и обязательно ли знать PHP?
не обязательно. например, во второй задаче от php — только расширение имени скрипта.
и в начале строчка вида #!/usr/bin/env perl, к примеру :)
мне больше по душе #!/usr/bin/env escript :)
гм. расширение файла со скриптом, конечно же.
Обожаемая задача: «Есть массив из миллиона байт. Проверить, если ли повторяющиеся значения.»

Как думаете, чем она так хороша? :)
Первый бит значащий? :)

Хотя в данном случае это не имеет значения.
Мне больше нравится эта:
«Есть массив из 999999 чисел. Все числа кроме одного имеют пару. Найти одинокое число быстрее чем за О(n2
Сортировка за O(nlogn) + один проход за O(n), итого O(nlogn).
Ну как минимум так, да. Но задача решается и за О(n) =)
Если диапазон ограничен [0; k], то за O(k) памяти можно сделать подсчётом за O(n+k).

Ok=)
Но есть еще более элегантное решение)
Сложить все числа от 1 до 999999, предварительно их удвоив. Далее пройтись по массиву и вычитать из той суммы значение текущего элемента массива. Под конец останется только одно, нужное нам число.
В условии не сказано, что массив это перестановка чисел из промежутка [1; 999999].
Оу, пардон. Тогда если числа целые, можно взять дополнительную переменную, затем пройтись по массиву и каждое значение поXORить с этой переменной. Под конец в переменной останется нужное число.
трюк с битами ) к счастью, обычно они не нужны )
кто их использует, достоин кола )
в массиве 1, 1, 1, 2, 2, 2, 3 все числа кроме одного имеют пару? если нет, какие ещё числа кроме «3» не имеют пары?
Все верно, данный массив подходит под условия задачи и повторяющиеся пары тоже аннигилируются XOR'ом)
Вас не затруднит проверить свои рассуждения на этом моём примере? 0 ^ 1 ^ 1 ^ 1 ^ 2 ^ 2 ^ 2 ^ 3 = 0, а не 3. Может ertaquo не совсем верно изложил алгоритм?
Оййййй.
Гоню же конечно. Почему-то воспринял пары 1-2, 1-2, 1-2 0_о
Нет, условие задачи действительно не совсем корректно.
Наверное следует уточнить так:

Все числа кроме одного, встречаются четное число раз))
Очень заинтересовало, смысл очевиден, но попытался реализовать, не получается. Где я ошибся?
MacBook-vas3k:~ vas3k$ cat xor.cpp
#include <stdio.h>

int main() {
int a[] = {45, 23, 12, 67, 23};
int b = 0;
for (int i = 0; i < 5; i++) {
b = b xor a[i];
}
printf("%d\n", b);
return 0;
}

MacBook-vas3k:~ vas3k$ gcc xor.cpp
MacBook-vas3k:~ vas3k$ ./a.out
98
Вот черт, хабрапарсер побил все мои с любовью расставленные отступы. Вот так более читаемо.
Чтобы хабрапарсер любовно относился к пробелам, используйте разметку <source>…</source> вместо <code>…</code>:

MacBook-vas3k:~ vas3k$ cat xor.cpp 
#include <stdio.h>

int main() {
    int a[] = {45, 23, 12, 67, 23};
    int b = 0;
    for (int i = 0; i < 5; i++) {
        b = b xor a[i];
    }
    printf("%d\n", b);
    return 0;
}


MacBook-vas3k:~ vas3k$ g++ xor.cpp 
MacBook-vas3k:~ vas3k$ ./a.out 
98
«Все числа кроме одного имеют пару»
Ааа, вот я дурак, я прочитал наоборот. Всегда говорил себе: в третьем часу ночи ложись спать, а не решай задачки с хабра :(
Кстати, задача может ставиться и так: «Только одно число имеет пару». Возможно для неё тоже можно придумать интересное решение
Не совсем вас понял. Вы исходите из предположения, что в массиве содержатся только числа от 1 до 999999? Вношу уточнение: там лежат инты, скажем от 0 до 2147483647)
Категорическое уважение.
Мне в свое время потребовалось больше времени чтобы перейти в правильную плоскость размышлений)
Объявляем переменную, равную 0. Проходимся по массиву. Первое значение прибавляем к переменной, второе — вычитаем и так далее. Конечная переменная по модулю покажет нужное значение.
Как у вас все просто.
3 2 3 2 1
0+3-2+3-2+1 = 3
Олимпиадная задача. Ещё на турбо паскале решали. Называлась «хитрое жюри» или для начинающих «ХитрОе жюРи».
Столько, сколько сам назовёт. Мы не торгуемся.
У нас все работают удалённо ;) Но рабочие часы Штатовские, EST
Я тоже жалею, замечательный работодатель…
У меня подобные вопросы были на собеседовании джуниора, когда я начинал только. Вот на вопросе о шедулере точно бы завалился, за всю мою уже долгую практику приходилось его ковырять всего один раз из чистого интереса, что за зверь такой? Хотя уверен, что сейчас нагуглю без проблем мануал по правильной настройке.

Вообще из этих вопросов видно, что уровень «новых» разработчиков падает. К нам в компанию тоже приходят ребята, которые не сильно блещут знаниями и умениями. Их берут на работу и потом из них вырастают хорошие спецы (видимо везло компании на таких перспективных разработчиков). Надеюсь, у вас ситуация схожая.

И еще пара вопросов: а что тогда у вас должен уметь Junior? Какие вопросы ему задаются?
Мы не набираем Джуниоров. Вернее не так — мы не ставим лэйбы на программистов Senior/Junior. У нас есть две открытые позиции — Junior для тех кто не очень уверен в себе и Senior для тех, кто думает что он совсем профи. Технический директор одного из наших подразделений присылал файлы на позицию Джуниора, потому что у него море опыта в Си и совсем чучуть в PHP.
странный набор задач. все простые и требуют минимальных познаний в администрировании.
кроме SQL — это точно по теме.
Ответил на все вопросы, какая зп?) надеюсь, больше 3к?%)
В Минске реальный потолок который я пока что встречал это 1,5 от мск компаний -(
Вилен, ну это наглость Ж-) за такие задачки просить 3килобакса Ж-). хотя наша столица многим впечатляет.
кстате насколько я помню, ты на и более изащренные вопросы. причем имея 30килорублей, в далеких и темных годах.
эх молодо-зелено, запросы растут :)))
дело не в столице, это я так намекнул, что зп может быть указана такой, что на нее идут такие же сеньйоры
ну, и вообще, не хочу я снова пхп;)
Ужас. Мы бы такого и на работу не взяли.
НА превую задачу навскидку 4 решения, с базой/без, вторя решается двумя способами, третья тривиальная.
Я могу рассчитывать на тимлида, если приплюсовать знание аддминистрирование, сертификат Cisco и соавторство в Cake/Symfony? )
Считать количество показов баннеров лучше наименее ресурсоемким способом: в движке (не в веб-морде же считать всё это) завести dictionary (он же map, он же hash), в котором ключом будет являться id баннера, а значением счетчик показов этого баннера и обеспечить к нему thread-safe доступ для инкремента счетчика. Периодически дампить статистику показов в файл, если нужно.
Для второй задачи там же (в движке) отцепить поток, который будет спать максимум 13 сек, выходить, если движок зашатдаунили или делать, что надо. С монструзными cron-ами можно не связываться.
Что первая, что вторая задача очень изящно решаются на node.js =))
Вот с этим согласен полностью. Тоже первая мысль про баннер была — node.js
да и на PHP тоже. Достаточно использовать его в «демоническом» режиме.

просто 80% используют его строго как mod_php.
Кстати, Майк, догадаетесь, в чем вы неправы про вариант решения по времени?

Хотя я считаю скорее постановку неверной, но это уже вторично.
Не учел время выполнения некоего действия, но это, наверное, мелочи для задававшего вопрос. Можно его и учитывать.
Если время выполнения больше 13 сек, в случае cron-а мы сожрем всю оперативу и ресурсы, а в моем случае ничего не запустится вообще — ну тут нужны уточнения от автора вопроса.
в этом топике можно набрать кучу прогеров =)
Автор, у вас проблема в описании вакансии и требованиям к ней, раз 90% людей приходится отсеивать на собеседовании, а даже не на этапе просмотра резюме. Ответить на вопросы не проблема (на второй гуглиться за секунды), а вот недоумение «зачем мне, претендующему на должность senior'a, задают такие вопросы и какие же тогда там junior'ы» у адекватных соискателей возникнет точно.
Адекватных соискателей мы нанимаем :) Хотя про неверное описание вакансий это мысль, спасибо.
У нас тест является обязательным при наборе, идет вдобавку к резюме.

Беглый взгляд на тест (5 задачи, пхп, базы, ксс+js, архитектурная) позволяет отсеять 90% людей, которые не подходят.

Зачем тратить свое время на собеседование, у вас других задач мало?

Дайте 3-5 задач типа тычки-галочки + две такие свободные, где надо порассуждать, и не принимайте на собеседование без них.

А тех, кто по тесту нравится, гоняйте по опыту и бэкграунду. Я обычно по кода теста общаюсь + 15 блиц вопросов, остальное спрашиваю, чего человек по жизни делал, к чему стремится и так далее.

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

В этом и прелесть простых и вольных на ответ задач.
Сразу видно, к примеру
— в задаче про JS, стоит упоминание «заюзайте фреймворк».
если jQuery знает — ок. если только document.getElementById — первый триггер

— в задаче про SQL ищу left join + group by… having ..., либо where (select… > 3)

— в задаче про алгоритмы тупо на адекватность решения

— в задаче про ООП смотрю на знание SOLID. и просто текст задачи ДЛИННЫЙ, насколько человек умеет читать 1 кб текста (четко написанный, разбитый по абзацам).

реально, глаз наметан, проверка теста это 1 минута взгляда.

а бэкграунд очень важен, и опыт тоже. он может писать отличный код, но если человек не работал в команде, конфликтный по натуре, не любит брать на себя ответственность, или банально не любит программить и идет тупо ради денег и тд — а часть из этих элементов можно понять на собеседовании — не факт, что он нужен.
Смотря как вести беседу. я сейчас ищя программиста, работаю с КА, и получаю от них оценку эксперта, когда человек приходит на собеседование, я просто говорю о том что меня очень прикалывает вопрос по мусклу который задает КА.
отвлекаясь: они задают вопрос про 1 джойн в связке 1 ко многим. и оценивают ответ по 10 бальной шкале, причем многие оцениваются на 4 балла. хотя там вариантов немного на мой взгляд такой вопрос это 0 или 1 балл из 10.

чаще всего соискатель соглашается с этим мнением. реакция моего замечания.уже большой показатель, после я говорю так как совершенно непонятен Ваш уровень знаний Мускл исходя из этого теста я даю простой вопрос: есть база: фильмы и страны, у одного фильма может быть много стран производителей, надо построить базу.(обычно все строят Ж-)) нерадивый программист используя myisam(например) не имея связей, удалял фильмы, но не подчистил таблицу связи. надо найти все мусорные записи которые остались в таблице связи. на мой взляд это вопрос который установит планку, для обсуждения, если сразу, да еще и два варианта, да еще и напишет сразу is null. тогда можно пообщаться о сложных вещах, но как правило 80% при решении имеют много запинок и с ними тяжело вести разговор о сложном
Я бы сильно засомневался в адекватности конторы, которая бы мне на собеседовании начала задавать подобные вопросы.
Вполне себе нормальные задания, решаются минут за 15, я при устройстве видел более идиотские задачи на которые требовалось еще к тому же около 3-4 часов, вот таких я сразу посылал, а здесь все реально и нормально.
Не бойтесь вы никого не упустили ;)
>> Возможно, кандидаты волнуются и у них «вылетают из головы» простые вещи, но тогда что будет когда они попадут в команду — «завтра релиз а у нас конь не валялся»?

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

А задачки, бывает и хуже… :)
У нас таких «героев» — 200 человек, работать среди таких людей — удивительно. Никто никогда не юлозит вульвой — есть задача — есть решение, втечение 3 минут. Есть несколько решений — выбрали лучшее, открыли редактор и погнали. А менеджеры у нас как консультанты больше — разработчики у них спрашивают, как должно всё работать.
>юлозит вульвой
крутое выражение, надо запомнить
UFO landed and left these words here
>Т.е. теоретически можно гуглить, хоть я и прошу этого не делать.
Почему этого нельзя делать? В условиях решения реальных проблем (не собеседования) вы тоже не гуглите, а сидите и думаете пока не придумаете свой велосипед и не наступите на все грабли?
3ий вопрос на знание нормализованной формы хранения данных и на знание HAVING.

2рой вопрос на знание какой то узкоспециализированной фишки в мире Linux. Такие задачи, как правило называются задачами на исследование. И решаются за часа два, уж точно, при наличии интернета под рукой.
Ценность такого вопроса на собеседовании, у меня как у программиста вызовет большие подозрения в том, что вы как мой тим лид(или тех дир) будете нести ахинею. И скорее всего я к вам не пойду работать.

1-вый вопрос на знание чего? Вообще не понятно.
— Итого:
Если я проходил собеседование у вас. И были бы(!) только эти три вопрос, то я бы не пошел к вам работать. Т.к. скорее всего вы, как мой начальник, заставляли меня делать совершенно не ту работу, на которую я рассчитывал. И зачастую высказывали бы, какой нибудь не нужный тезис, с видом, что это знает каждый уважающий себя программист. А это в свою очередь, не вызывало бы у меня никаких положительных эмоций в работе.
>2рой вопрос на знание какой то узкоспециализированной фишки в мире Linux

Улыбнул
3ю задачу можно и без HAVING решить. На большом объёме библиотеки и популяции авторов и маленьком ожидаемом количестве трёхавторных книг может даже и эффективнее будет ;-)
UFO landed and left these words here
Я с легкостью реализую первую и третью задачи. Но вчера я слил собеседование на должность джуниора…
Only those users with full accounts are able to leave comments. Log in, please.