Дело в том, что на собеседованиях часто любят задавать вопросы как касающиеся каких — то синтаксических (довольно скучных задач (кросворды), вроде ++$i/$i++ находящихся в общем выражении), так и общих, например, ООП. Популярные моменты — это наследование интерфейсов, абстрактных классов, суть которых в общем то нарушить правильный ООП или выявить на особенностях (возможностях) глубину познания кандидатом. Вот именно эти моменты окрас и проверяют тесты, и поэтому, довольно полезно на мой взгляд просмотреть бегло тесты (в тестах пишется ожидаемый результат). Для большей убедительности попробовать выполнить аналогичный код. Прогуглить и узнать почему именно так реализовано (срабатывает) в PHP, а не по другому.
Вот для примера, базовый вопрос на собеседованиях и тест из исходников.
Файл: tests/classes/abstract_by_interface_001.phpt
--TEST--
ZE2 An abstract method may not be called
--FILE--
<?php
class Root {
}
interface MyInterface
{
function MyInterfaceFunc();
}
abstract class Derived extends Root implements MyInterface {
}
class Leaf extends Derived
{
function MyInterfaceFunc() {}
}
var_dump(new Leaf);
class Fails extends Root implements MyInterface {
}
?>
===DONE===
--EXPECTF--
object(Leaf)#%d (0) {
}
Fatal error: Class Fails contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (MyInterface::MyInterfaceFunc) in %sabstract_by_interface_001.php on line %d
Как видно из описания, класс Fails упадет в фатальную ошибку, так как наследовал интерфейс MyInterface, но не произвел определение тела функции из интерфейса MyInterfaceFunc(). См. документацию по интерфейсам.
Перейдем, к следующем тесту:
Файл: tests/classes/abstract_by_interface_002.phpt
В данном случае этот же интерфейс MyInterface, имеет определение сигнатуры метода, объявленного как static.
interface MyInterface
{
static function MyInterfaceFunc();
}
....
class Fails extends Root implements MyInterface {
}
?>
===DONE===
--EXPECTF--
object(Leaf)#%d (0) {
}
Fatal error: Class Fails contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (MyInterface::MyInterfaceFunc) in %sabstract_by_interface_002.php on line %d
Как видно из ожидаемой ошибки, в данном случае, метод также должен быть определен в классе, наследующий данный интерфейс.
Или вот довольно частый вопрос, о том, можно ли в обычном классе определить абстрактный метод.
Файл: tests/classes/abstract_derived.phpt
--TEST--
ZE2 A derived class with an abstract method must be abstract
Производный класс с абстрактным методом должен быть абстрактным
--SKIPIF--
<?php if (version_compare(zend_version(), '2.0.0-dev', '<')) die('skip ZendEngine 2 needed'); ?>
--FILE--
<?php
class base {
}
class derived extends base {
abstract function show();
}
?>
===DONE===
<?php exit(0); ?>
--EXPECTF--
Fatal error: Class derived contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (derived::show) in %sabstract_derived.php on line %d
Или вот один замечательный тест:
Файл: tests/classes/abstract_redeclare.phpt
<?php
class pass {
function show() {
echo "Call to function show()\n";
}
}
class fail extends pass {
abstract function show();
}
echo "Done\n"; // Shouldn't be displayed
?>
Метод show(), не может быть переопределен абстрактным.
Перейдем в каталог тестов func и как, пример, тест с использованием static и постфиксным инкрементом/декрементом.
Файл: tests/func/002.phpt
--TEST--
Static variables in functions
--FILE--
<?php
function blah()
{
static $hey=0,$yo=0;
echo "hey=".$hey++.", ",$yo--."\n";
}
blah();
blah();
blah();
if (isset($hey) || isset($yo)) {
echo "Local variables became global :(\n";
}
--EXPECT--
hey=0, 0
hey=1, -1
hey=2, -2
Напоследок, чтобы не сильно Вас утомлять, приведу интересный тест, по баге 28800
--TEST--
Bug #28800 (Incorrect string to number conversion for strings starting with 'inf')
--FILE--
<?php
$strings = array('into', 'info', 'inf', 'infinity', 'infin', 'inflammable');
foreach ($strings as $v) {
echo ($v+0)."\n";
}
?>
--EXPECT--
На этом все, спасибо за отнятое время.
Комментарии (48)
Yago
12.06.2016 06:55+17Никогда не понимал вопросов на собеседованиях в стиле «поиграй в интерпретатор». Как правило, они сопровождаются кодом за который по пальцам настучат при ревью, и который совсем оторван от реального кода проектов. К тому же о большинстве таких тонкостей при разработке предупреждает IDE.
malinichev
12.06.2016 11:13-13Ну… Не все же пользуются IDE… Я например пользуюсь sublime, и иногда, при крупном проекте Visual Studio Code. PHPStorm мне в корне не импонирует почему-то…
oxidmod
12.06.2016 11:44+9имхо, верх не профессионализма, задавать кандидату вопросы исходя из собственных предпочтений. Вам не нравится IDE — давайте будем задавать странные вопросы, которые с IDE даже не возникают.
malinichev
12.06.2016 12:33-9Вы сами то верите что многие разработчики профессионалы? У большей части просто зашкаливает самооценка, вот и всё…
Lure_of_Chaos
12.06.2016 16:36+3Влезу, пожалуй. Как же Вы определяете критерий профессионализма? Неужто профессионал — это тот чел, который вместо грамотного выбора инструментов (той же IDE) предпочтет писать код в блокноте\vim'е и знает phpdoc наизусть? Если так, то пожалуй, можно будет Вас пожалеть, когда такой «про» в работе с Вами понапишет такой код, который прочитать и подправить под изменяющиеся требования будет невозможно, такой код, который руками лучше не трогать, чтобы не развалился…
malinichev
12.06.2016 19:15-5Я ничего подобного не говорил… Спец — он и в Африке спец, и обычно он использует те инструменты, которые ускоряют процесс разработки! Я говорил про себя. Многие говорят, что если не юзаешь IDE — то ты совсем не спец, и даже не джуниор… Как по мне это ошибочное мнение, я например начинающий мидл, и я не хочу(и не могу) юзать IDE, от которой тормозит хром, и плеер с музыкой на компе…
8 гб оперативы, 4 ядра AMD. Я думаю, что этого вполне бы хватило для IDE, но нет, музыку слушать нереально, тормоза постоянные, и всё такое… Я не представляю какой нужен комп, для удобного юзанья PHPStorm…
Именно поэтому, я и юзаю VS Code, он лёгкий и удобный.
И так, по вашему мнению, я не специалист в разработке(я и не хочу таким называться, знаний маловато), ок, хорошо… Пусть будет такLure_of_Chaos
12.06.2016 21:16+3Многие говорят, что если не юзаешь IDE — то ты совсем не спец, и даже не джуниор…
Пусть говорят, жирные тролли :)
я не хочу(и не могу) юзать IDE, от которой тормозит хром, и плеер с музыкой на компе...8 гб оперативы, 4 ядра AMD
Как Java-разработчик (проект на GWT, будь он неладен) использую IDEA, в это время открыт Хром, Огнелис и IE11, в фоне работает 2 томкэта, сервисами крутятся Апач и Постгрес, играет AIMP, открыт TeamViewer, и вполне комфортно работать, если только не запущу еще Эклипс :) 2 ядра Интел по 2ГГц, те же 8Г ОЗУ — язык не поворачивается назвать это суперкомпом :) ЧЯДНТ?
Я не говорил, что Вы — не специалист, я говорил о том, что специалист подбирает подходящие инструменты для разработки, вместо того, чтобы кодить в нотпаде :) И нет ни одной причины не пользоваться IDE
AmdY
12.06.2016 22:49Кстати, отличный вопрос для собеседования. Разработчик претендующий хотя бы на мидла должен знать про профайлинг. phpstorm имеет встроенный инструментарий, чтобы самому определить тормоза, либо послать результаты разработчикам, чтобы они починили баг, вы же за это деньги платите.
PHPt
13.06.2016 07:24Странна. Занимаюсь разработкой на Java под WebSphere Application Server. На ПК 4 гб ОЗУ, 2 ядра 3ГГц, отлично себя чувствовали IDEA, Chrome, WebSphere Application Server Base 8.5.5, Wowza и несколько других программ. Даже видео на YouTube мог смотреть. Озу забито на 92% но тормозов не заметно.
Вероятно просто все от того, что я все таки решил открыть файлик idea.vmoptions и поправить Xmx и Xms параметры?VolCh
13.06.2016 09:23Возможно вы даже знаете, что эти параметры существуют, а то и примерно понимаете их смысл.
pavlick
13.06.2016 08:14работаю на 12" макбуке, то есть мобильный проц, 2 ядра 1.1ГГц.
Обычно приходится держать открытыми сразу несколько проектов в PHPStorm. Нормально, ничего не тормозит.
WaveCut
13.06.2016 10:45-1Многие говорят, что если не юзаешь IDE — то ты совсем не спец, и даже не джуниор…
А если валишь дерево бензопилой, а не топором, то вообще не лесоруб…
terryP
13.06.2016 12:10+1А если валишь дерево бензопилой, а не топором, то вообще не лесоруб…
Только аналогия наоборот, если профессиональный лесоруб принципиально не хочет использовать бензопилу, а пытается валить вековые деревья топором, при том что требуется заготовить как можно больше деревьев, то что-то с ним не так…
zzzmmtt
14.06.2016 11:558 гб оперативы, Core i5-4460, AMD Radeon R7 240 (2Gb), Ubuntu 16.04
Phpstorm 2016.1 в 2-3 окна, FF (десятка полтора вкладок), pgadmin, 2-3 терминала, Thunderbird, Teamviewer, Slack, Skype, Chrome иногда. Ни намёка на тормоза… ЧЯДНТ?malinichev
14.06.2016 17:44Не буду спорить… Может это и сам процессор допотопный(AMD Athlon X4 760K Quad), который греется до 105 градусов(F) при хроме, при этом чистка компа ежемесячная…
P.S. Уже боюсь писать что-то… Много любителей минусовать
Yago
12.06.2016 11:56+3Почти все современные редакторы используемые для написания PHP-кода имеют плагин или расширение статического анализатора кода. Это очень весомая экономия времени на обнаружение опечаток и каких-нибудь особенностей, непозволительных для использования в языке. Вы сами себе враг, если избегаете оптимизации процесса кодирования.
Fesor
12.06.2016 16:45за который по пальцам настучат при ревью, и который совсем оторван от реального кода проектов
В этом же соль. Посмотреть как человек рассуждает. Показываем код и спрашиваем почему он работает или не работает… или просим самостоятельно определить результат.
У меня есть парочка таких задачек которые я изредка даю. И код, как вы сказали, оторван от проекта и мне бы дали по шапке на код ревью. Но ситуации там взяты из реальных проектов, просто ужато все до размеров 10-ти строчек кода (что бы не перегружать человека). И даже если человек не может ответить почему так, мне намного важнее рассуждения человека послушать, пусть даже они и не верны. Грустное солнышко он за неверный ответ не получит.Yago
12.06.2016 17:14+5Я встречал такие вопросы, и часть из них была:
— Зависима от версии Php/MySQL или рабочего окружения.
— Ужасно преподнесена. Например:
$y = 10;
$z = 3;
$x = ( $y % 5 > 0 )? ( $z == 3)? $z * 2: $y + 3: ( $z < 3 )? $y — $z: $z++;
Чему равен x?
— Неполной. Т.е. иногда сам собеседующий путался в вопросе и примере кода.
И никогда не был полностью удовлетворен ответом на вопрос «зачем Вам нужен ответ на это?». Я не вижу преимуществ у людей, которые могут или не могут ответить на подобные вопросы. Игра в интерпретатор хороша при отлове сложных багов, но тут большую роль играет общее знакомство с проектом, а не отлов синтаксических или языковых ошибок (из них до кода проекта доходит лишь очень скромная и практически невесомая часть, т.к. обычно программист тестирует свой код хотя бы на ручном уровне).
Хотите понять мое мышление — дайте практическую задачу, и попросите меня изложить алгоритм решения на словах. Вы получите гораздо больше информации, и я получу минимум стресса и непонимания от вопросов, которые мне непонятны на идеологическом уровне.Fesor
12.06.2016 17:55Я не вижу преимуществ у людей, которые могут или не могут ответить на подобные вопросы.
Так я такой бред и не даю и сам отвечаю на такие вопросы в духе "у меня такой код тупо не пройдет код ревью ибо я не могу сходу его прочитать", причем никто не кочевряжется и мы просто переходим дальше.
дайте практическую задачу, и попросите меня изложить алгоритм решения на словах.
Тип стандартную? Когда я дохожу до этих задачек то собеседуемый уже выложил с чем он работал и я приблизительно представляю скоуп "стандартных" для него задач. А вот как человек будет мыслить при поиске проблем, при отладке и т.д. Или задачки где xdebug не поможет отловить проблемы и нужно предложить быстрое решение как проверить что-то.
И повторюсь, я прибегаю к этим задачкам когда мне не понятно из его других ответов как человек мыслит и насколько он адекватен. То есть далеко не в начале собеседования. И интерпритатором в этом случае выступаю Я а не собеседуемый, он просто делает предположения а я говорю так это или нет.Yago
12.06.2016 18:31К сожалению, не доводилось встречать Ваш подход на собеседованиях.
Что касаемо задач, они не обязательно должны быть стандартными. Главное, чтобы были из реального проекта и не слишком узкоспециализированные. Практически в любой компании появляются не совсем тривиальные задачи, которые могут представлять собой подпорку для задач на собеседовании с небольшой доработкой. И порой даже на решении стандартной задачи можно услышать очень оригинальные способы решения (как плохие, так и хорошие). Решение во-первых подкрепит или опровергнет то, что у человека в резюме, а во-вторых покажет, насколько развито у человека критическое мышление, если задача для него нова или он не сталкивался с подобным на прошлых работах.
Djeux
12.06.2016 15:24-6Из опыта. Самая лучшая проверка знаний, это попросить написать «фреймворк» при недостаточном времени (не обязательно при собеседовании). Сразу видно в каком направлении работает голова и знания ООП. К тому же будет что обсудить при повторном собеседовании.
Lure_of_Chaos
12.06.2016 16:19+2попросить написать «фреймворк»
Что, имхо, некорректно, ибо, во-первых, порождает тонну вопросов, что же на самом деле хотят, т.к. фреймворков много и разных, для различных нужд и трудно выяснить, что же на самом деле хотят от тебя как от кандидата, а во-вторых, запросто уводит в патовую ситуацию, когда субъективизм видения собеседующего и собеседуемого на то, каким должен и не должен быть фреймворк, просто зашкаливает — особенно в условиях недостатка времени, когда закончить такое «тестовое» задание априори невозможно, и что там должно быть, а что нет, чтобы называться «фреймворком».
К примеру, несколько месяцев назад некий парниша написал статью на Хабре, где описал свой «фремворк» — «легковесный ORM», состоящий из одного класса и был закидангов...камнямиразгромной критикой в духе «так писать нельзя», «это не ORM» и «выкини поделие на помойку» при том, что сам честно в начале статьи признался, что ставил целью разобраться с философией построения подобных фреймворков, а не создать «убийцу Doctrine/AdoDB/и проч.».
И к тому же, на какой уровень собеседуемого Вы предлагаете использовать подобное задание — джуник, миддл или сеньор?
Очевидно, что на каждый уровень должны быть различные вопросы. И если человеку без опыта действительно нужно задавать вопросы в стиле «что выведет echo ''+0?», то мучать подобными вопросами сеньора — уже не уважать ни его, ни себя, и лучше поспрашивать о его опыте работы, используемых технологиях, проблемах, с которыми он столкнулся и как решал, без конкретики «напишите на листочке классы A и B, чтобы один наследовал другой и можно ли будет на объекте одного класса вызвать метод, определенный в другом».
И еще немного, о тестовых заданиях. Помню я, как мне предложили создать «админку» в стиле CRUD для редактирования сотрудников и их зарплат, на 8 часов, после чего мне отказали на том основании, что я сделал функциональность и совсем не позаботился о том, как оно выглядело — без стилей, сверстано таблицами и проч. В другом случае тестовым заданием было: зайти в их багтрекер, выбрать по вкусу баг их системы и исправить его — чем я даже заниматься не стал :) А Вы предлагаете писать «фреймворк».Djeux
12.06.2016 16:42+1Видимо не правильно выразился. У меня как-то было задание, написать простую страницу с логином используя ООП и «clean url» что по сути включает в себя создание простейшего рутинга и слоя доступа к базе данных.
Уже на данном этапе можно понять в какую сторону понесет разработчика учитывая нехватку времени. Кто-то просто пихает весь код в статические методы и называет это ООП. Кто-то начинает лепить ненужные абстракции.
Это всё относится к мидлу.
Сеньёрство это вообще страшный субъективизм, т.к. есть немало руководителей для кого просто 5-7 лет работы по специальности автоматом причисляет к «лиге сеньёров». Юниоров заставлять писать такие задание перебор.Fesor
12.06.2016 17:00Сеньёрство это вообще страшный субъективизм
Все субъективно. У кого-то джуниор это человек без опыта, хотя это подразумевает что человек может самостоятельно решать стандартные задачи, а человек без опыта это стажер.
Например я не всегда могу определить пограничные категории, вроде "джун переходящий в мидла" или "мидл переходящий в синьера" и потому приходится оперировать "чего умеет, насколько быстро будет развиваться и сколько просит". Так например можно взять более слабого разработчика чуть дороже если видно что за пару месяцев сможет быстро втянуться. А можно взять дорогого синьера которого придется еще и переучивать.
Ну и еще момент… почему-то в PHP сообществе очень большая редкость джуны с опытом работы с юнит тестами. Хотя как по мне это обязательно для джуниоров.Lure_of_Chaos
12.06.2016 17:18очень большая редкость джуны с опытом работы с юнит тестами
добавьте сюда внимание к устойчивости системы (в смысле безопасности). Почему-то, джуники считают своим долгом «склеивать» запросы в строку с переменными, а даже миддлы\сеньоры совсем не видят пограничных ситуаций от «а что, если пользователь ввел букву вместо цифры» до «а не придет ли сюда null и не сломает ли нам все.» Заметьте, это никак не коллерирует с написанием юнит-тестов — юниты тоже надо еще уметь писать :)
В итоге, 90% (субъективно) сайтов содержат детские ошибки и подвержены элементарным sql injection, xss — я уж молчу про timed attack, csrf и проч.Fesor
12.06.2016 18:06Почему-то, джуники считают своим долгом «склеивать» запросы в строку с переменными
Ничего страшного. Если "джуник" адекватный, ему можно один раз объяснить почему это плохо и не переживать. Тем более что сегодня большая часть джуников работают только с объектым API и запросы компилятся (во всяком случае меня такие джуники интересуют, которые работают с фреймворками и т.д.)
а даже миддлы\сеньоры совсем не видят пограничных ситуаций от «а что, если пользователь ввел букву вместо цифры» до «а не придет ли сюда null и не сломает ли нам все.»
Побочные эффекты мало кто учитывает. Потому это один из основных источников багов.
Заметьте, это никак не коллерирует с написанием юнит-тестов — юниты тоже надо еще уметь писать :)
коррелируется. Это умение составлять тест кейсы, умение проверить качество своего кода. Писать юнит тесты легко, сложно писать тестируемый код. А пытаться "переучиться" еще сложнее.
В итоге, 90% (субъективно) сайтов содержат детские ошибки
90% сайтов написаны на wordpress и подобных штуках с кучей плагинов написанных школьниками. Так что это нормально. Меня такие не интересуют. Что до timed attack… я слышал что кому-то удалось провернуть такое при работе с удаленным сервером (пинги более 10-ти милисекунд) но честно я считаю что заморачиваться на этой почве нужно только если это прописано в требованиях. Как правило задачи где это критично — это редкость. Ну а для хэшей паролей есть устойчивый к этому виду атак password api.
VolCh
12.06.2016 22:42+1«а что, если пользователь ввел букву вместо цифры» — тут смотря что вы имеете в виду. Подсказывать пользователю, что он ошибся, указывать где и как, сейчас обычно задача фронтенда, наше же дело — привести к числу, пришедшую с фронта строку, если нет прямых требований выводить результаты валидации.
Lure_of_Chaos
12.06.2016 17:09написать простую страницу с логином используя ООП и «clean url»
Здесь «фреймворком» и не пахнет, вопрос только в разделении слоев и уровне абстракции, чтобы эта функциональность с наименьшей болью вписывалась в существующую архитектуру и\или подстраивалась под использование одного или нескольких фреймворков, в стиле «здесь вьюшку можно написать используя шаблонизатор вместо голого пхп» и «а методы этого класса переписываем, чтобы он обращался к Zend-DB или чему-то еще», а «clean url» вместо правила в .htaccess конфигим через методы, предоставляемые фреймворком.
Таким образом, и монолит в виде статических методов и подход «фабрика фабрик фабрик» с интерфейсом на каждый класс — это всегда решение, запросто не выдерживающее критики, но зато развязывает руки собеседующему принять чела или не принять, вне зависимости от того, что понаписал «испытуемый».
Сеньёрство это вообще страшный субъективизм
Ну почему же. Я выше привел пример нормальных вопросов, а к тому же, сеньор — это не тот, кто способен писать одному ему понятный код, используя одному ему известные хаки и особенности интерпретатора и растить фреймворк над фрейморком, а тот, который умеет видеть потенциальные проблемы и предлагать несколько решений одной проблемы, от «сделать быстро и грязно» до «долго, дорого, но надежно», чей код прост, читаем и гибок, а также умеет организовать команду. Кстати, недавно об этом проскакивала статья.
Fesor
12.06.2016 16:57и совсем не позаботился о том, как оно выглядело — без стилей, сверстано таблицами и проч.
Справедливости ради это говорит о том что вы решали задачу без учета пользователя вашей системы. Вы все же не для себя это делаете а для конечного пользователя, а ему должно быть удобно. Это многое говорит о разработчике. Тем более что для CRUD подобного и наличии Bootstrap-ов всяких 8-ми часов достаточно.
В другом случае тестовым заданием было: зайти в их багтрекер, выбрать по вкусу баг их системы и исправить его — чем я даже заниматься не стал :)
А вот это вы правильно сделали.Lure_of_Chaos
12.06.2016 17:32Почти согласен с Вами, но: не забываем, это было тестовое задание на 8 часов, а потом, я делал просто, и некрасиво, но не неудобно. Все-таки я программист, а не дизайнер и не верстальщик, и до сих пор считаю, что в первую очередь система должна работать правильно, а красивую картинку можно нарисовать и потом — главное, чтобы эта система позволяла себя легко «разукрасить» так, как душе угодно — хоть с многоязычностью и сменяемыми темами.
Да, Bootstrap бы меня тогда спас, если бы в то время он существовал :) К слову, сейчас как раз использую TwBs для разработки, в стиле «смотрится неплохо, но есть потенциал для вау-дизайна» при минимальных затратах на верстку.Fesor
12.06.2016 20:06Все-таки я программист, а не дизайнер и не верстальщик, и до сих пор считаю, что в первую очередь система должна работать правильно, а красивую картинку можно нарисовать и потом
Я знаю слишком много продуктов где внутри все очень плохо зато снаружи все хорошо, и наоборот знаю продукты где внутри все круто но на это ушло слишком много времени и в итоге продукты… умерли) Просто потому что предположения о том как пользователи будут использовать продукт провалились. Если бы сделали чуть проще, хватило бы времени на адаптацию.
Да, Bootstrap бы меня тогда спас, если бы в то время он существовал :)
А вот это уже другой разговор.Lure_of_Chaos
12.06.2016 21:26Просто потому что предположения о том как пользователи будут использовать продукт провалились
В том и дело, что красивая картинка — с изображениями, анимацией и пр. — это одно, а удобство, юзабилити — совсем другое, и если первое можно отложить на потом, то второе закладывается еще на этапе проектирования и в целом определяет поведение и функциональность системы. И если углы у кнопочки можно закруглить в последнюю очередь, то тот факт, есть ли кнопочка или нет, расположена она вверху и продублирована ли для удобства внизу или запрятана в угол — зачастую решает, можно ли в целом пользоваться системой или ее придется серьезно переделывать; туда же поддержка AJAX и проч.
Так вот, если на первое я плюю, то на второе я очень даже обращаю внимание, и пусть при этом проект выглядит будто родом из 90х, с ужасными квадратными серыми кнопками — ведь это всегда можно приукрасить :)
Fedot
13.06.2016 14:16Вопрос о том как пользователи будут использовать ваш продукт очень важен, без этого нельзя. Но всё же при тестовом задании для от программиста(если говорить о бэкэнде) требовать таких вещей странно.
И в первую очередь по тому что если разбираться как и кто будет использовать эту систему, то не может не возникнуть вопроса, а зачем писать своё? Есть ли готовые решения? А какую проблему должен решать наш продукт? А есть ли такая проблема? А кто пользователи? И так далее и тому подобное. В итоге ни одно тестовое задание не будет выполнено, ибо оно ни кому не нужно и не имеет смысла его делать.Fesor
13.06.2016 16:55Но всё же при тестовом задании для от программиста(если говорить о бэкэнде) требовать таких вещей странно.
Требовать — странно, согласен. Но если чувак заморочался — это будет плюсом. Нет — можно будет и на эту тему поговорить, узнать что важно для человека. Бывают люди которым важно что бы код был идеален, а все остальное мелочи. Вот таких людей надо вовремя определять и смотреть потом на общую адекватность.
Lure_of_Chaos
12.06.2016 16:27з.ы. не минусовал
потому, какэто недостойно, и изложил свою позицию. Но вижу, что и без меня с Вами не согласны :)Denis_Minin
12.06.2016 17:56Проблема в том, что работодатели не понимают различие между «php-программистом» «HTML-верстальщиком» и дизайнером. Поэтому складывается такое мнение если ты «web-программист то должен все эти три профессий, если по принятии на работу ты написал отличный код, но дизайн сайта не красив, то тебя могут и не принять на работу.
Mendel
12.06.2016 18:22Можно я чуть вброшу на вентилятор? Коллеги, а что вы думаете о тестах в апворк?
OnYourLips
12.06.2016 19:17Новые тесты по PHP, в которых надо писать код?
Примитивные тесты для уровня стажера или плохого джуниора.
Однако даже у опытного разработчика есть шанс не пройти тест полностью из-за того, что некоторые пограничные условия не пройдут.
Но все равно это лучше старых тестов, где надо было просто галочки ставить и размышлять, что же имел ввиду автор теста.Mendel
12.06.2016 19:40А есть новые?
Благодарю, гляну.
Я помню там был ад на «кто лучше зазубрит пхп.нет, тот и сеньор.
И да, помню были проблемы с пониманием задания.
Сдал с трудом „на троечку“, и хоть очевидно что решать надо с открытым на второй машине гуглом, но как-то не хочется еще раз проходить. Нафик.
Но если обновились, то попробую. Благодарю.
ganqqwerty
13.06.2016 11:23+1Для кандидата это хороший способ заранее узнать, надо ли будет работать с говнокодом в компании. Дали тебе задачку на i++ + ++i, а ты такой — «погодите, подобный код встречается в ваших реальных проектах? Так, ну я пошел!»
HaruAtari
13.06.2016 11:52В таких случаях начинают рассказывать, что таким образом они хотят узнать на сколько оптимальный код ты можешь писать. А то, что сэкономленные в данном случае такты — это капля в море по сравнению с оптимизацией, которой можно добиться правильно выбрав алгоритм, их не волнует.
VolCh
13.06.2016 12:14+1Именно. Ведь проверяем насколько оптимальный код кандидат может писать. И как оптимизации задокументирует.
ysaroka
13.06.2016 12:26+1tests/classes/abstract_redeclare.phpt
Какой-то странный тест, ожидается, что метод не может быть повторно объявлен абстрактным, а ошибка ловится вот эта:
«Class fail contains 1 abstract method and must therefore be declared abstract or implement the remaining methods»
VolCh
Не знаю как для прохождения собеседования поможет, но когда тебе говорят, что через 5 минут тебе нужно провести техническое собеседование, то хороший способ несколько вопросов подобрать :)