×

Вопрос по PHP на собеседовании

Навеяно обсуждением в теме «Вопрос по C\C++ на собеседовании».

На собеседованиях я задаю вопрос:
Как получить первый элемент массива?

Правильного, с моей точки зрения, ответа я пока не слышал.
В теме «Вопрос по C\C++ на собеседовании» мне были даны типично неправильные ответы. по моему мнению конечно.
с пояснением что такая потребность почти никогда не возникает, а поэтому программисты на PHP не знают, да и вообще-то и не обязаны сходу давать ответ на этот вопрос. если понадобится — прочтут в документации, или нагуглят.

Пример 2
В тестовом задании встретил применение array_push($a, ’foo’) хотя по коду прекрасно подошел бы $a[] = ’foo’
Это пример — правильной привычки, безопасного программирования? так принято в мире PHP?

Пример 3
Задача — выбрать из массива объектов такие, у которых поле равно одной из пяти строк.
Человек пишет код, в котором помещает эти строки в массив, и для каждого объекта вызывает in_array с значением поля.
Я зря пристебался что array_flip а затем array_key_exists для каждого объекта — будет более правильным ответом, ввиду более высокой скорости работы?

Поэтому у меня вопрос к программистам на PHP.
Какие по вашему мнению вопросы по работе с массивами показывали бы степень опытности программиста, и не были бы придирками, а основаны на типичном применении массивов в PHP.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

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

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

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

Когда я слышу/читаю «массив» — я себе представляю [’a’, ’b’, ’c’].

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

Вы — нет, а РНР-программист — да.

По моему скромному мнению, если у вас возникла потребность в микрооптимизациях типа тех, что указаны в топике, то имеет место один из вариантов (в порядке субъективной вероятности):
1. Проблема решается более эффективно другими способами (кеширование, изменение алгоритма, оптимизация работы с БД и т.д.)
2. Проблема решается более эффективно с помощью других инструментов/языков
3. Вам действительно это нужно. В таком случае нужно это специально указать, ибо это самый редкий случай.

O(1) среднему разработчику на PHP непонятна. я уже понял.
В мире РНР действительно не принято таким заниматься. Не потому, что это плохой язык или тупые разработчики, просто в 90% случаев это не нужно, а значит в остальных 10% нужно явно указать необходимость таких оптимизаций. Это как взять молоток и спросить: «Неужели тут не принято предварительно вычислять траекторию и силу удара?». Нет, не принято! Такой это инструмент. А если таки приперло, то с адекватным разрабом об этом договориться не проблема (за 2к думаю должен быть достаточно адекватный). И это уж точно не повод отсеивать кандидатов из-за ваших неверных представлений об экосистеме РНР.

не перестаю удивляться вопросам, которые здесь мелькают... дивная у нас страна... и народ у нас такой... дивный...
«Какие по вашему мнению вопросы по работе с массивами показывали бы степень опытности программиста, и не были бы придирками, а основаны на типичном применении массивов в PHP».
По моему мнению — никакие.
Определять «степень опытности программиста» на основании ответов на «вопросы по работе с массивами» — попытка составить определение «сферического коня в вакууме».

На собеседованиях я задаю вопрос:
Как получить первый элемент массива?
Правильного, с моей точки зрения, ответа я пока не слышал.
И какой же с вашей точки зрения правильный? Мой вариант примерно такой:
$el = isset($arr[0]) ? $arr[0] : null;
Можно сделать не так, можно проверить длину массива и например выбросить исключение, если длина 0. Зависит от того, какая реакция программы должна быть на нестандартную ситуацию с пустым массивом.
Пример 2
В тестовом задании встретил применение array_push($a, ’foo’) хотя по коду прекрасно подошел бы $a[] = ’foo’
Это пример — правильной привычки, безопасного программирования? так принято в мире PHP?
Нет, так принято у автора кода. У меня принято $a[] = ’foo’, так как эта запись читается лучше, чем array_push. Особенно когда таких строчек будет несколько подряд.
Пример 3
Задача — выбрать из массива объектов такие, у которых поле равно одной из пяти строк.
Человек пишет код, в котором помещает эти строки в массив, и для каждого объекта вызывает in_array с значением поля.
Я бы тоже так сделал, просто и понятно.
Я зря пристебался что array_flip а затем array_key_exists для каждого объекта — будет более правильным ответом, ввиду более высокой скорости работы?
Зря. Я например даже не понимаю, как предложенное вами решение будет работать. Станут объекты ключами после array_flip, и что дальше? Как поможет array_key_exists? А прикиньте, как потом эту магию поддерживать. Даже сам забываешь через время что делает этот кусок кода, про другого разработчика я вообще молчу. И все ради скорости, которая не так критична, как вы думаете. Или ты обрабатываешь десятки-сотни объектов и +/-0.001с на каждом не играет роли, или нужно обрабатывать миллионы объектов и такая магия уже не поможет, нужны другие подходы.
Магия допустима для упрощения кода. При этом нужно убедиться, что магия не высшего уровня и достаточно понятна среднему разработчику. Или снабжать такую магию комментарием.

С точки зрения своего опыта девелопмента и собеседований имею такие наблюдения:
1. Оптимизация алгоритма дает больший прирост производительности, чем знание тайных заклинаний получения первого элемента массива.
2. Тайные заклинания написания супер производительного кода либо тормозятся медленным каналом у юзера либо дешевле доплатить хостеру, чем переплачивать девелоперу. Более того, можно разные приложения захостить на разных хостах, иногда это дешевле, чем докупать ресурсы у прова.
3. Вопросы на собеседованиях о синтаксисе языка это для джуниоров или мидлов. Для сениоров уже должны быть вопросы о методологии разработки, подходах к решению типичных и не типичных ситуаций из жизни (!).
4. Очень хорошо садит на попку интервьюера когда он знает, что соискатель видел профайл интервьюера — они (интервьюеры) тогда не такие злые и меньше знают о том, как проводятся собеведования там :) Более того, когда интервьюер не может показать свое порфолио...
5. Дайте реальную задачу из жизни и послушайте подход к решению: что понадобится, как будет решать, как соискатель намерен разрулить возможные проблемы и какие возможные проблемы видит соискатель в предложенном решении.

З.Ы. Лет 10 назад я тоже был таким перфекционистом, потом понял, что когда меняются (добавляются) девелоперы на проекте и времени не хватает, то уже важнее, чтобы код был написан понятно, а не заумно.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Я зря пристебался что array_flip а затем array_key_exists для каждого объекта — будет более правильным ответом, ввиду более высокой скорости работы?

потратил 10 минут.

написал тупой тестик, массив из простых чисел, заполняемый рандомно.
и две функции — одна ищет рандномное число в нем с помощью in_array
другая array_flip, а потом ищет с помощью array_key_exists

ну и трижды их попарно вызвал

PHP 7.0.18

in_array 3.6461319923401
array_flip 0.029288053512573
===
in_array 3.6519708633423
array_flip 0.029279947280884
===
in_array 3.663969039917
array_flip 0.032021999359131

Встретил хорошую итоговую статью по reset($arr)

Готовимся к собеседованию по PHP: Всё об итерации и немного про псевдотип «iterable»

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

про reset, после прочтения данного топика использую очень часто, когда известно точно что получу коллекцию из одного єлемента.

Если надо получить первый элемент массива — то что-то уже пошло не так) Первый вопрос: Зачем использовать массивы? Не знакомы с SPL библиотекой

И вообще рассуждать о производительности и использовать массивы — стыдно

Не знакомы с SPL библиотекой
это да, разработчиков Zend надо гнать из отрасли :)
И вообще рассуждать о производительности и использовать массивы — стыдно
как по мне — стыдно не знать как устроены массивы в PHP.

а уж использовать их, или SPL — то уже второй вопрос.

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

обязательно пойду учить мат часть.
и резюме вам пришлю конечно.

мне не надо) я тоже ее плохо знаю)
отчитаетесь об успехах на форуме)

отчитаетесь об успехах на форуме)
да, обязательно.
мнение форума — важно.

Вы можете говорить сколь угодно, что оно не важно, но все же вы приходите на форум и задаете тут вопросы, а значит отчасти важно)

ну, раз вы не поняли

мнение таких как вы — меня не интересует :)

о маркерах в постах я уже на доу писал — как быстро и эффективно «ставить в игнор» подобных советчиков и оценщиков :)

хотя надо было просто сразу ваш битбакет открыть)
Реально совет — научитесь форматировать код и перестаньте использовать массивы
Я Вас не тролю, а вполне серьезно говорю
Делать такое недопустимо
$connection = @mysql_connect(DB_HOSTNAME, DB_USERNAME, DB_PASSWORD)
в 2016 году
$resource = mysql_query($sql, $this->link);

а это вообще страшно

Делать такое недопустимо
$connection = @mysql_connect(DB_HOSTNAME, DB_USERNAME, DB_PASSWORD)
обратитесь к разработчикам MantisBT. они не в курсе вашего мнения.
в 2016 году
$resource = mysql_query($sql, $this->link);
угу. вы ни асилили что код мантиса писал не я, но уверенно даете советы по рефакторингу кода мне.

да, ваше мнение очень важно, пишите есче.

Мои добавочки, для работы mysqli, PDO, расширенный логер, DebugBar и Kint, ... в версии 1.5.5.1.2 DebugBar и Kint в ветке debugbar

вот что я прочитал в описании и называется этот проект ocStore
Я не хочу никого обидеть, я просто защищаю права тех, кто приходит на собеседование а им начинают задавать подобные вопросы и прикалупываться к мелочам

Мне непонятно зачем рассуждать о разнице между PHP5 и PHP7 (для простого девелопера ее нет — просто плюшки типо стрикт мода) или о скорости массивов и в тоже время у себя в репозитории писать @mysql_connect или даже форкать такое)

ocStore
а, то вы все же типо читатель.

правда как-то все равно не дочитали.

что ocStore это сборка OpenCart’а.

Но вы пишите, пишите. чукча ж писатель, а не читатель.

Но вот это ваше творение
global $debugbar, $debugbarRenderer;
Причем сам debugar НЕ РЕКОММЕНДУЕТ так делать)

DI бы сейчас
$debugbar->setStorage(new DebugBar\Storage\FileStorage(DIR_LOGS));

Инициализация класса в конфиге это очень интересное занятие

+global $debugbar;
+if (isset($debugbar)) {
+ $debugbar["messages"]->addMessage($setting);
+}

это откровенная пичаль, можно было бы хотя бы проверить на isset($debugbar[’messages’])
bitbucket.org/…​b6ce2d9070eed?at=debugbar

if (isset($debugbarRenderer)) echo $debugbarRenderer->render();

Echo в конфиге, это тюнинг такой) Сразу чтобы печатало, если что-то не так)
Правда пофиг куда печатать надо — просто пусть печатает

Вы топите за PHP7 но банально исподьзуете array() вместо []
не вижу стрикт мода и форматирования, вообщем я открыл один файл — увидел тоже самое что в остальном сфорканном вами коде)

Чукча чукчу не поймет, ибо ни я один тут такой писатель

Так что просто не обижайте интервьюверов, они не заслужили таких сложных вопросов

Искренне Ваш,
Борец за права собеседующихся PHP ремесленников

Но вот это ваше творение
да.

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

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

но вот пейсателям типа вас конечно не угодить.
а если и угодить — то и копейки с этого не получить.

то на кой мне вам угождать?

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

Ах да, велосити комманды не зависит от аутсорсеров
Есть книжка, называется «Совершенный код» — советую почитать
И да, если у вас все проекты подобные, зачем спрашивать у собеседующихся такую дичь?

Есть книжка, называется «Совершенный код» — советую почитать
как и ожидалось, мои маркеры работают на отлично :)

что еще вы мне посоветуете перечитать из изученного за 20+ лет программерской карьеры?

И да, если у вас все проекты подобные, зачем спрашивать у собеседующихся такую дичь?
у меня проекты разные.
сейчас вот проект с интеграцией развесистого сервиса на PHP и фронтендового на Meteor.js

но да, я обязательно с вам посоветуюсь, что мне читать и как делать
наконец то я нашел себе гуру. да :D

вот тот пропущенный isset в конфиг файле и echo там же считают по-другому)

вот тот пропущенный isset

* $debugbar = new DebugBar();
* $debugbar->addCollector(new DataCollector\MessagesCollector());
* $debugbar[’messages’]->addMessage("foobar");

@see

github.com/…​src/DebugBar/DebugBar.php

там же считают по-другому)
так что мнение чукчей писателей — по боку :)
Борец за права собеседующихся PHP ремесленников
ремесленники меня не интересуют. хотя доводится конечно сотрудничать, мир пыха он да, пестрый.
Так что просто не обижайте интервьюверов, они не заслужили таких сложных вопросов
не обижаю, зачем? для ремесленников полно работы на фриланс биржах, зачем я им нужен?

боритесь дальше :)

Странная дисскуссия. Я ремесленник на ПХП и использую ПХП для тех целей для коих он предназначен, писать сайты. Мне нет нужды знать какого его внутреннее устройства и что там сбрасывается на момент запуска функции. Я же не иду на собеседование в команду разработчиков ПХП. Но мне нужны навыки для того чтобы выполнить конкретную задачу, желательно быстро и безглючно. Поэтому я учу ООП и различные решения по архитектуре и оптимизации т.е. те решения, которые получаются с помощью языка , но я не учу 100500 функций с php.net. Так как знаю, что мне там искать при возникновении такой надобности.

расскажешь это на собеседовании)

на кого собеседование? куда?

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

Если я открою пхп.нет и найду ответ (при этом, разумеется, без доки я этого не сделаю, зачем мне такое помнить)?
Если я просто расскажу примерное решение (что массив позволяет вытащить из него упорядоченный список ключей или значений, или что можно сбить внутренний итератор и получить первый элемент через current() )?
Если я скажу, что если есть потребность доставать именно первый элемент и это нельзя сделать через $arr[0], то такого быть не должно и вы что-то делаете неправильно?

вообще-то все уже есть в обсуждении.

а если кто-то думает что все 40 минут я задаю подобные вопросы — то что с ними поделать. пусть считают кого-то другого таким кретином :) им, типа умным это ж утешение в жизни.

при этом, разумеется, без доки я этого не сделаю, зачем мне такое помнит
что еще вы не знаете о языке на котором пишете — без доки?
можно сбить внутренний итератор и получить первый элемент через current()
без доки? неплохо.
последует вопрос — есть ли различия, и если есть то какие в работе внутреннего итератора в php 5 и php 7
Если я просто расскажу примерное решение (что массив позволяет вытащить из него упорядоченный список ключей
то есть вы без доки не знаете что массив в php является еще и очередью?
Если я скажу, что если есть потребность доставать именно первый элемент и это нельзя сделать через $arr[0], то такого быть не должно
помечу как два минуса. один за незнание. второй за наглость оправдывать свое незнание — такого быть не должно.
потому что использовать предлагаемый ЯП php список — это нормально.

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

с пометкой — ремесленник, если так выйдет, для директора. чтобы сбивал желаемую ЗП, если нам — и ремесленник подходит.

вы ж встречали в вакансиях — «зп по результатам собеседования»?
вот так эти результаты и формируются :)

что еще вы не знаете о языке на котором пишете — без доки?
очень много чего не знаю. Регулярки по памяти не напишу, например. Никак не могу запомнить, в каком порядке должны стоять haystack & needle в многочисленных функциях поиска. Вот вам, кстати, еще идейка для вопросов на собеседовании.
есть ли различия, и если есть то какие в работе внутреннего итератора в php 5 и php 7
А вот это наверное хороший вопрос. Можно увидеть понимание/непонимание внутреннего устройства массивов. Хотя если человек недавно пишет на пхп7, и собеседуется на пхп7 стек, зачем ему знать про различия с пхп5? То же самое, если он всю жизнь работал с пхп <= 5 и у вас нет семерки в стеке. Т.е. может лучше просто порасспрашивать про масивы и итераторы?
то есть вы без доки не знаете что массив в php является еще и очередью?
а вы уточняйте, что вам конкретно нужно, и ответы будут более правильные. Задачу нужно решить как можно оптимальнее по времени? По памяти? Написать как можно более простой и читаемый код? Не изменить при этом состояние исходного массива? Сохранить ключи-значения, но допустимо изменить внутренний поинтер? Ведь в пхп, наверное, не зря есть несколько способов достать первый элемент?
потому что использовать предлагаемый ЯП php список — это нормально.
То, что он оптимизирован сразу под несколько структур данных — не означает, что нужно юзать сразу несколько. ИМХО одновременное импользование его как хеш-таблицы и упорядоченного списка — это нарушение single responsibility, и такое допустимо только в исключительных ситуациях. На собеседовании я бы так и заявил (но при этом я все равно бы попытался правильно ответить на вопрос).
и буду спрашивать дальше, по языку. чтобы выявить что вы еще не знаете о ЯП на котором пишете без доки. так может все собеседование и пройдет, не добравшись до паттернов ООП, фреймворков, и прочих нюансов системного окружения.
Ну спрашивайте. А вообще я не понимаю, зачем вы тогда тратите свое время на собеседования. Можете нанять рекрутера из соседней темы, написать ей на листочке вопросы и правильные ответы к ним, и спокойно заниматься своими делами.
Регулярки по памяти не напишу, например.
регулярки — не является частью языка PHP.

то есть — еще минус — человек толи не понимает этого, толи еще хуже — склонен додумывать смыслы, которых не было в тексте.

в каком порядке должны стоять haystack & needle в многочисленных функциях поиска.
так это известная каша. смысла ее помнить нет. на то IDE есть, подскажет.
Можно увидеть понимание/непонимание внутреннего устройства массивов.
на самом деле суть вопроса в другом

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

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

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

А вообще я не понимаю, зачем вы тогда тратите свое время на собеседования.
поручили, вот и трачу. а что, вам не поручают?

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

потому что — еще раз — это влияет на зп, которую мы готовы дать. ведь конечно соискатель хочет побольше. но за такой набор минусов — смысл переплачивать? пусть идет себе к конкуренту, и тот ему переплачивает :)

ИМХО одновременное импользование его как хеш-таблицы и упорядоченного списка — это нарушение single responsibility,
а как массив и хеш-таблицу — разрешаете использовать?

это не будет нарушением single responsibility?
(хотя чует мое сердце — слышал звон, да не знает где он. но то потом, раз засветился, спросится и о том — что же он знает о single responsibility)

регулярки — не является частью языка PHP.
это core расширение, повсеместно используемое. Что это за пхп-программист такой, что не знает основных вещей в экосистеме пхп? Хотя для занижения зп придраться к «является частью языка» можно.
на то IDE есть, подскажет.
т.е. вы без ide не умеете программировать на пхп? Вам же будут давать писать код на листочке, когда будут пытаться сбить вам рейт на собеседовании. И вообще, у вас странная избирательность — программист должен знать как достать первый элемент массива (это же показатель знаний своего инструмента), но при этом его не надо спрашивать про физзбазз и балансировку деревьев (такого же на работе не встречается) и про порядок аргументов в стандартных функциях знать не надо (если что, подсмотрит)
человек читает ченджлоги о новых версиях — или нет.
обращает внимаение на несовместимости — или нет.
если программист делает свитч в пхп в марте 2017-го — ченджлоги до какой версии ему рекомендуется прочитать?
а может мне и отвечать за соискателя сразу?да и код за него педалить, чтобы он зарплату получал.
тем более что вопрос — плевый. а вот если человек не понимает слова «первый», то ой. он и тех задание так прочтет. ему его разжевывать сколько придется. а это — время специалиста.
так что — минус с его зарплаты, для уплаты времени разжевывания.
Сравнение совершенно не к месту. Те ответные вопросы, что я задал, в любом случае возникнут при решении такой задачи в реальной ситуации. И ответ на них будет очевиден из контекста, а в вашем вопросе это неочевидно совершенно.
задача собеседования — добраться до уровня некомпетентности соискателя
я согласен, но уровень некомпетентности определяется не только тем, сколько неверных ответов он дал на вопросы.

«The second worst kind of interviewer is the Quiz Show Interviewer. This is the kind of person who thinks that smart means „knows a lot of facts.“ They just ask a bunch of trivia questions about programming and give points for correct answers.»

а как массив и хеш-таблицу — разрешаете использовать?
а что такое, по вашему, массив (в этом контексте)?
это core расширение, повсеместно используемое
это DSL. а вы о реализации :)

еще минус. ведь речь была о ЯП — а не о реализации.

т.е. вы без ide не умеете программировать на пхп?
конечно нет. я в IDE сижу еще с Turbo C 2.0
Вам же будут давать писать код на листочке
да, есть такие :) им обычно хватает псевдокода. мне бы точно хватило, но я такие задания не даю. дурная трата времени.
но при этом его не надо спрашивать про физзбазз
там уже пояснил.
добавлю — если программист не освоил инструмент, а умеет только физбазы писать — то нафик он нужен такой на практике. а если освоил инструмент — то физбаззы можно научить писать.
если программист делает свитч в пхп в марте 2017-го
ну я использую свитчи. и не только в пхп. и на джаве использовал, и на С. это что, очередная какая-то молодежная фенечка, что я пропустил? свитч уже под запретом как goto?
а в вашем вопросе это неочевидно совершенно.
я чего не пойму. допустим я не взял вас на работу. так вы радоваться должны что с таким придурком не придется работать :)
чего вы мне доказать то хотите? проводите свои собеседования как считаете нужным, да и все.
а что такое, по вашему, массив (в этом контексте)?
у меня правило, давно. в интернетах я отвечаю на вопросы интересные МНЕ.

а не на любые, особенно которые косят под собеседование :)

не вижу почему я ради вас должен сделать исключение :)

ну я использую свитчи. и не только в пхп
я имел в виду «человек переходит из какого-то другого языка в пхп»

ок.

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

но вы таки не врубаетесь.

хорошо, еще раз

вопрос о ченджлогах это вопрос о самомотивации, проактивности. примерно с того же разряда — а у вас есть пет-проект? а блоги каких разработчиков вы регулярно читаете? и т.п.

хотя те же ченджлоги по секьюрити используемых продуктов — обязан читать.
недавно кстати один мной принятый меня огорчил. он прислал в покет новость что в версии X.Y есть дыра. для которой вышел секьюрити патч. Опоздал правда немножко. на 2 недели. то есть он дал хакерам 2 недели на использование этой дыры.
а я — сутки. потому RSSподписка сообщила :)

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

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

но ведь мы все же тут дискутируем о вопросах, которые показывают уровень технических навыков и опытности, разве нет? Зачем тогда вы мне написали вот это:

последует вопрос — есть ли различия, и если есть то какие в работе внутреннего итератора в php 5 и php 7
зачем мне знать, какой вопрос последует, если он напрямую не относится к обсуждаемой теме, а показывает самомотивацию и проактивность? Это вы показываете, как умеете гнобить кандидатов?
зачем мне знать, какой вопрос последует, если он напрямую не относится к обсуждаемой теме
так вы и не должны ничего знать заранее. кандидату что — нужно высылать список вопросов заранее?

и опять же — почему я знаю? это что, трудно прочесть в доке? тем более когда оно там — выделено!
а-а-а, доку не читаем ни разу. ведь это ж — раз пробежать по диагонали. 1 раз. и пусть смутно — но в голове останется. потому что выделена — частая ситуация, частый паттерн который описан во тьме блогов. а для 7ой версии — он не актуален. «Ух ты», сказал себе я, когда прочел. и все. и запомнилось.

Это вы показываете, как умеете гнобить кандидатов?
это я показываю что кандидаты бывают — разные. одни почему-то могут ответить на вопрос, а другие нет. но почему-то хотят одинаковую зарплату.
а я считаю — что несправедливо платить одинаковую зарплату — таким разным кандидатам. поэтому одному + к зарплате, а другому — из зарплаты.

вы за уравниловку? ваше право. так сразу на собеседовании и скажите — независимо от ваших вопросов и моих ответов я требую зп в Х килобаксов!
и не надо тут меня гнобить своими вопросами!

и все будет пучком.

но вы ж не скажете, правда? ;) а почему?

это я показываю что кандидаты бывают — разные. одни почему-то могут ответить на вопрос, а другие нет. но почему-то хотят одинаковую зарплату.а я считаю — что несправедливо платить одинаковую зарплату — таким разным кандитам. поэтому одному + к зарплате, а другому — из зарплаты.
я считаю, справедливость тут ни к чему — вы должны заплатить как можно меньше, но при этом достаточно много, чтобы не отпугнуть всех, кто сможет справляться с работой. Если на работе ваши задачи подразумевают, что надо отвечать на вопросы без подглядывания в документацию — тогда я абсолютно согласен с вашим подходом.
но вы ж не скажете, правда? ;) а почему?
а я именно так и скажу: независимо от ваших вопросов и моих ответов я требую зп в Х килобаксов. И предоставлю вам право решать любым удобным для вас способом, брать меня на работу за такие деньги, или не брать.
если программист не освоил инструмент, а умеет только физбазы писать — то нафик он нужен такой на практике. а если освоил инструмент — то физбаззы можно научить писать.
так как все остальное — просто обоюдный троллинг, а реально подискутировать с вами мне хотелось именно касательно этого — отвечу в первую очередь только на это.
Мне почему-то кажется, что все наоборот — программист должен знать и понимать программирование, а не языки. А находить элементы массива при наличии понимания программирования можно научить еще легче, чем физбаззы.
Если я правильно понял, то лично у вас очень много опыта программирования, но конкретно в пхп вы перешли относительно недавно. И шо, разве вы потратили много времени, чтобы разобраться в пехапешных массивах? Человек с 10+ годами опыта с находжением первого элемента разберется очень быстро, когда оно ему понадобится
разве вы потратили много времени, чтобы разобраться в пехапешных массивах?
вот потому и вопрос возник — что конечно доку прочел, и все понятно.
и с внутренним указателем.

а вот почему

Человек с 10+ годами
на пхп этого не знает, да еще вот массово возмущаются некорректностью вопроса да, удивительно.
А находить элементы массива при наличии понимания программирования
ну, если за 10+ на пхп человек не научился, то — можно научить еще легче...
когда оно ему понадобится
да, согласен. бывает, за 10+ лет в пхп ни разу не понадобился первый элемент массива :D
а вот почему Человек с 10+ годами на пхп этого не знает
потому что забыл уже)

да ну нах.
я про С до сих кучу таких вещей помню.

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

а я наизусть помню кучу консольных команд в гите и докере
а я не помню.
Может я просто хорошо к собеседованию подготовился?
поэтому вопросов на зубрежку не задаю :)

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

так что вот и на собеседовании вопросы у меня не на зазубривание и настаканность на физбазах.

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

разве вопрос про первый элемент массива — не на зубрежку? Да, есть минимальные требования к пониманию пхп, но в основном надо знать функции для работы с массивами, разве нет?

разве вопрос про первый элемент массива — не на зубрежку?
нет :)

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

я ж не зубрил. потому что там нечего зубрить.

но в основном надо знать функции для работы с массивами,
ну да. а вопрос то про что :D

я вот, как мне кажется, в общих чертах понимаю, что такое массив в пхп (а если нет, то в этой теме точно должно быть несколько человек, которые реально понимают). При этом я не могу ответить на этот вопрос без гугления, чтобы соблюдались следующие условия (в версии 7.1):
+ выполнялось за О(1)
+ не изменялся данный массив, включая значение внутреннего указателя
+ не использовались костыли типа break внутри foreach (в 5.х этот метод вообще не подойдет из-за использования внутреннего указателя) и вообще чтобы постороннему было сразу понятно, что тут именно берется первый элемент

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

Да, вы можете сказать, что вы не требовали того, что я отметил плюсиками. Но при этом вы говорите, что array_shift($a) — неправильно (или может он не первый элемент возвращает?), что array_values($a)[0] — неправильно (тоже не первый элемент будет?). На предложение конкретизировать условия задачи вы говорите «мне шо, может и закодить за тебя?». Поэтому тут даже зубрежка библиотеки ни к чему не приведет — от собеседуемого просто требуется угадать, что же вы имели в виду.

Я даже не нашел ответа в этой теме
в этой теме ответ был дан другими.
array_shift($a) — неправильно
есть в теме не мои ответы — почему.
array_values($a)[0] — неправильно (тоже не первый элемент будет?).
есть в теме не мои ответы — почему не совсем то. но можно и так.

то есть читать вы таки не умеете :)

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

а вы все мне пытаетесь доказать мою неправоту :)

ну доказали уже, доказали. шли бы уже подальше ;)

какой интерестный пост. недавно меня посетила мысль что 90 процентов тут сидящих — они никогда на олимпиады и не ездили. они типа ремесленики — учили все потихоньку и так и стали програмистами и поэтому наблюдается такая как это сказать «отсуствие блеска в глазах» когда обсуждается програмистакая какая нибудь задача

чего вы мне доказать то хотите
хочу доказать, что вы таким образом можете взять на работу ремесленников, которые вызубрили library reference, но совсем не понимают, что под капотом, и как со всем этим добром работать.
Вам же это интересно прежде всего?
Какие по вашему мнению вопросы по работе с массивами показывали бы степень опытности программиста, и не были бы придирками, а основаны на типичном применении массивов в PHP.
Так вот, по моему скромному мнению, этот вопрос не показывает степень опытности программиста (как раз наоборот, студент, недавно перечитавший документацию, ответит лучше), и не основан на типичном применении массивов в РНР. Все сопутствующие ваши вопросы как раз являются придирками.

Похожие вопросы должны задаваться после того, как кандидату выдадут ноут с открытой ide и подключенным интернетом. Ну можно закрыть еще доступ ко всему кроме php.net. Не успевает за определенное время — зовете следующего

хочу доказать, что вы таким образом можете взять на работу ремесленников ... но совсем не понимают, что под капотом
вот как раз вопрос про array и про то что под капотом :D
этот вопрос не показывает степень опытности программиста
что он показывает, и ПОЧЕМУ он это показывает — уже ответил сто пицот раз.
Все сопутствующие ваши вопросы как раз являются придирками.
как вам угодно :) с каких это пор обидки соискателя волнуют тех кто ему отказал?

нелепость какая — готовить вопросы которые удобны соискателю, и на которые он знает ответы :)

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

нет. и не волновало.

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

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

«ни один осужденный не согласен с приговором» :)

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

в питоне заменял огромные свичи
А можно поподробней? В питоне появились свитчи?

исходник был на пхп, его переводили в питон, наверно засилие if else if и было решающим, уже гдето пол года прошло — поэтому могу ошибаться в деталях

понятия не имею, сколько они занимают процессорного времени в php.

обычно такие вещи оптимизированы авторами транслятора.

но, может быть в php с ними плохо. я не парюсь по этому поводу, потому что switch применяю редко. не потому что низя, плохо, а как-то редко он требуется.
но что точно — гирлянды ifelse меня раздражают больше :) опять же потому что — я представляю как транслятор может соптимизировать набор case. а вот как соптимизировать гирлянду ifelse — слабо.

ну я использую свитчи. и не только в пхп. и на джаве использовал, и на С. это что, очередная какая-то молодежная фенечка, что я пропустил? свитч уже под запретом как goto?
ну, скорее как «плохое знамение», «code smells». Не факт, что альтернатива окажется лучше, но точно повод присмотреться к коду внимательнее.
Либо в другом месте назревает идентичный switch — и тогда лучше рефакторить во избежания копи-паста.
Либо часть case-веток имеют повторяемые фрагменты — и тогда лучше либо рефакторить структурно(отдельная сущность? стратегия? фабрика?), или хотя в последовательность if’ов(early return может помочь с читаемостью).
Либо если речь о однозначном маппинге — использовать хэшмап с парами «значение флага-из-switch->необходимое для использования значение», тем более, РНР позволяет хоть даже методы по имени вызывать, хоть объекты по имени создавать(inline-вариант Factory).

(прим.) Думаю, вы и так про эти приемы знаете. Но было бы классно, если бы вы привели пример switch, который нет смысла в что-то другое рефакторить.

копипаст с свичем ли, без — пахнет одинаково. Так что свитч в нем не повинен.

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

Глупым применением можно считать случаи прямой тождественности. Например свитч который по номеру месяца возвращает его название.

Правильные случаи применения — когда нужно сделать несколько вызовов плюс применяется проваливающийся case

case ’x’: first_func();
case ’y’: second_func();
break;
case ’zz-top: foo_func();
break;

Конечно, можно реализовать это правильными ооп патернами.
Или написать транслятор DSL.
Чтобы потом перед пацанами похвастать.

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

Правильные случаи применения — когда нужно сделать несколько вызовов плюс применяется проваливающийся case
согласен, что изящно выглядит.
Но.
во-1, читаемость ухудшается: найти нужный блок среди прочих недостаточно, надо убедиться, что выше есть break; или нет; или он там с условием;
во-2, модифицируя один блок можешь затронуть и те, что ниже(если отсутствует break или условный, например), что усложняет как модификацию
в-3, в некоторых случаях будет провоцировать дублирование. В вашем примере, если я захочу только для варианта ’x’ выполнять дополнительно third_func(), мне придется модфицировать секцию ’y’, так как breakthrough уже не прокатит.
Конечно, можно реализовать это правильными ооп патернами.
Или написать транслятор DSL.
Чтобы потом перед пацанами похвастать.
жаль, что я создаю такое впечатление. спасибо за ответ, энивей.

1. Явные вызовы читабельнее косвенных.
2. Модифицировать ооп код — не проще чем очевидный
3. Предусмотреть код под все случаи в будущем — невозможно. А вот вспухшая от этого голова да, способна сотворить ребус, на пределе интеллектуальных способностей, и который все равно придется выбросить в будущем, потому что появится непредусмотренный этим ребусом случай.

Мнения о вас у меня нет. Но не могу воспрепятствовать вам считать что оно есть, да еще вот такое-то. Это ваше неотъемлемое право — выбирать в свой адрес то что вас задевает. И считать что это был не ваш выбор, а мое целеполагание.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Ну если задача нанять php программиста, — то берется и нанимается программист.

А если повыделываться, то после получения результатов этих задачек, скачать что всё это фигня, открыть ассемблер, вбить туда push/pop и сказать с гламурным видом, что просто надо было положить/извлечь значение из стека

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

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

неужели они его не знают?:))))

я бы сказал — многие неспособны к изучению программирования. И поэтому свойства что array что симфони — одинаково им нe подъемны. Вдумайтесь — не смог асилить про array но разобрался с ленивой загрузкой моделей в доктрине?

А знают ли они php — тестов в инете полно. Желающий может себя оценить

Коротше вся суть пхп — щоб вибрати перший елемент масиву треба запамятовувати різні варіанти просто упоротих по своїм назвам функцій які хрен зна що роблять по суті. Боже упаси і сохрани від стандартної бібліотеки пхп. Амінь.

Коротше вся суть пхп
not even close

На одной из PHP Framework Days выступал Расмус и из зала спросили: какого хрена настолько не согласованные сигнатуры массы функций? названия по разным паттернам, порядок аргументов — везде каша. Расмус сказал, шо когда РНР только начинался — он просто повторял паттерны функций-аналогов из С, шоб разработчикам было проще свитчнуться. Так шо претензии к разработчикам standard library в C.
Ну, а спустя годы, никто обратную совместимость ломать ради красоты не станет.

Дякую тобі боже, що я не знаю С? Хоча знаєте подивитися на нове в бібліотеці то там теж треш всюди. Так що поганим творцям С заважає.

Только как язык очень продвинут, разве что асинка не хватает

$arr = array(’a’=>’ass’, ’b’=>’bss’, ’c’=>’css’);

method 1.
$first = $arr[’a’];

method 2.
$first = array_shift($arr);

method 3.
$values = array_values($arr);
$first = $values[0];

method 4.
$indexes = array_keys($arr);
$first = $arr[$indexes[0]];

method 5.
foreach($arr as &$val) { $first = $val; break; }

method 6:
$first = false;
array_walk($arr, ’getFirst’);
function getFirst($val) {
global $first;
$first = $val;
return false;
}

echo $first;

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

Схоже, що тут універсально треба взяти перший елемент масиву.
$first = reset($arr);

$arr = array(’a’=>’ass’, ’b’=>’bss’, ’c’=>’css’);

method 1.
$first = $arr[’a’];

$arr = array(’b’=>’bss’, ’a’=>’ass’, ’c’=>’css’);
$first = $arr[’a’] - будет первым?
method 2.
$first = array_shift($arr);
через несколько строчек я опять хочу получить 1ый элемент из $arr...
и?

method 3.
$values = array_values($arr);
$first = $values[0];
годится конечно. только зачем нам создавать массив для этого.
method 4. — туда же.
method 5.
foreach($arr as &$val) { $first = $val; break; }
а что будет с первым элементом $arr, если мы ниже напишем
$val = «ggg»;
Главный вопрос какую задачу нужно решить?
получить первый элемент И только :)
с учетом специфики array в PHP — он еще и очередь. и поэтому термин «первый элемент» — означает тот, который был помещен в очередь — первым. а не тот кто имеет индекс 1, «First», «Первый», «А»
Если задача стоит показать как можно больше вы знаете о языке
ну, то что вы показали — так это

1. непонимание условия задачи
2. подставились на более тонкие вопросы :)

например еще на такие о методе method 5 (из документации)
когда оператор foreach начинает исполнение, внутренний указатель массива автоматически устанавливается на первый его элемент Это означает, что нет необходимости вызывать функцию reset() перед использованием цикла foreach.

1. если foreach использует внутренний указатель как и reset, то зачем вы его использовали? (с прищуром — или вы не читали документации?)
2. описанное поведение относится ко всем версиям PHP начиная с 4ой? если нет, то к какой версии относится это поведение?

Да! Вы правы спасибо за пояснения :)

А я все равно считаю что нефиг создавать зависимости на порядок ключей в асоциативных масивах :):)

если массив используется как очередь — то другой выбор — это только использование SplQueue::bottom() или аналогичного своего или фреймворка.

method 5.
>foreach($arr as &$val) { $first = $val; break; }
а что будет с первым элементом $arr, если мы ниже напишем$val = «ggg»;
Там было почти правильно, только референс лишний:
foreach ($arr as $val) { $first = $val; break; }
по вкусу приправлен $first = null; перед циклом.

Можно сократить до:

foreach ($arr as $first) break;

Преимущества перед reset’ом — null вместо false’a в случае пустого массива; работает с итераторами/traversable.

Если бы у меня на собеседовании по С/С++

Вопрос по C\C++ на собеседовании".
спросили бы
Как получить первый элемент массива, на PHP?
я бы подумал, что ошибся дверью...

Какие странные проблемы у «динамических» ребят.

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

вторая причина по которой $arr[0] плохой выбор.

потому что это — хрупкий код.

для того чтобы он работал и отвечал условиям задачи, от конкретной переменной типа array требуется
1 наличие цифровых ключей
2 «первый» должен быть «нулевым» элементом

в итоге, если в результате какое-то из условий не будет соблюдено, наш код сломается.

особенно интересно второе условие:
считать ли работу кода $arr[0] корректной для случаев:

1 $arr = array(’first’, ’second’);
2. $arr = array(1=> ’first’, 2=> ’second’, 0 => false);
3. $arr = array();
$arr[1] = ’first’;
$arr[0] = ’second’;

а почему reset или array_values()[0] дадут одинаковый ответ?

то есть, код использующий избыточную информацию, предположения которые НЕ нужны для решения задачи — более хрупок, чем тот который не опирается на предположения.
по другому
(осторожно: тролинг)
код $arr[0] в сравнении с array_values($arr)[0] — написан «гуманитарием». потому что array_values($arr)[0] (или reset) — это необходимое и достаточное(!) условие для получения первого элемента. а использование 0 — это уже избыточно, и, как в примерах выше — еще и «хрупко»

Мда... А если массив вообще пустой? Что там выдаст

array_values($arr)[0]
?

для reset — false, для array_values()[0] — null (+ NOTICE undefined offset)

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

Вы уходите сильно в техническую часть забывая о здравом смысле

Под здравым смыслом обычно подразумевается скопище предрассудков
Кто то с великих.

Памятуя наш диспут о прилагательном первый — не удивительно что вы прибегли к этому аргументу ;)

лично я под здравым смыслом подразумеваю бритву оккамы

Нельзя подразумевать то чем вы категорически не пользуетесь. Но, вы философ? Хотите со мной подискутировать о философии?

Ну вам виднее конечно.
Уже отвечал что не философ

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

Выше там не с вашей стаи жужжит муха что я задрот? Не стесняйтесь, при соединяйтесь к нему. Вы ведь тоже так считаете, правда ж ? ;)

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

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

Насчет срача, как следствия моего стиля полностью согласен с замечанием.

А вот насчет смешивания понятий, как раз наоборот. Мой способ, стиль мышления виискивания аксиоматической базы, сведения набора сущностей к минимуму, и замена остальных сущностей набором правил их создания принято называть — математическим мышлением. Как и порождение с аксиоматики с помощью тех же правил — бесполезных сущностей, отсутствующих в длействительности. В этом математика сродни идеалистистическим направления философии.
Этот метод можно встретить много где и у кого, и он не является лучшим безусловно. У него есть ограничения, фундаментальные изъяны.

Но

Все это выглядит задротством в глазах большинства :-)

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

А про срач да ваше замечание вполне верно.

Одно замечание насчёт заметки о хрупкости кода
В ней вообще три части
Тезис
Пример
Эмоциональная зацепка

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

Но, лень писать статьи как положено. Это ж время, не хватает мотивации его тратить таким образом

Пример, я давно говорил, тролил что патерн MVC превратили в догму, напрочь не видя что не к месту вне создания GUI причём в таких системах где уникальность элементов практически аппаратная.
И вот, уже и в мире фронтенда разработчики второго известнейшего фреймворка в открытую послали это патер нафик.
То что в куче фреймворков НЕ MVC а просто использование бренда....

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

для того чтобы он работал и отвечал условиям задачи

Можно условия задачи, для которой array_values($arr)[0] будет правильным, если $arr[0] даёт warning или отличное от array_values($arr)[0] значение? Чтобы при этом $arr[0] было «хрупким кодом», а не просто грубой ошибкой. Типа получить минимальное значение после сортировки.

Писать array_values($arr)[0] там, где имелось в виду $arr[0] это просто некорректно.
Вы тихо, без warning’ов получите левое значение.

Если имелось в виду array_values($arr)[0] — можно на эту задачу посмотреть?
Именное array_values($arr)[0], не foreach($arr) в какой-то форме.
Тривиальная постановка типа «написать array_values($arr)[0]» (или получить «первый элемент хеша») не считается.

Я поставил задачу. Её стали додумывать, выдумывать, а вы так вообще решили её не считать.
Замечательно, ни асилив условия задачи потребовать её заменить на другую!

Можно условия задачи, для которой array_values($arr)[0] будет правильным, если $arr[0] даёт warning или отличное от array_values($arr)[0] значение?
Конечно можно. RTFM

Ну, всё же для справедливости, это не соответстует требованию:

Чтобы при этом $arr[0] было «хрупким кодом», а не просто грубой ошибкой.

Однако, по-моему, эта «грубая ошибка» (попытка получить начальный элемент ассоциативного массива через …[0]) легко превращается именно в «хрупкий код», если в данном фрагменте кода по каким-то причинам ключами массива чаще всего (но не обязательно) являются именно (0, ...). Тогда, да, fail early перестаёт спасать.

я вот вообще не понимаю где может пригодится такое извращение как array_values($arr)[0].
Более того, этот код противоречит твоим же принципам написания быстрого кода, т.к. будет та же O(n) сложность.
И более того — код все равно нормально не рабочий, т.к. для пустого масива надо будет писать свою проверку (внезапно, да).
Там ниже написали варианты, но в целом вот 2 быстрых и правильных:
1) $firstValue = $arr[0] ?? null;
2) foreach($arr as $value) { $firstValue = $value; break; }
И тут уже можно упражняться в обработке ошибок.
Вот кстати результат моего мини бенчмарка между foreach методом и array_values

Total time for array_values for array size 10 :0.0006 seconds
Total time for foreach for array size 10 :0.0001 seconds
Total time for array_values for array size 50 :0.0021 seconds
Total time for foreach for array size 50 :0.0001 seconds
Total time for array_values for array size 1000 :0.0372 seconds
Total time for foreach for array size 1000 :0.0001 seconds
Total time for array_values for array size 50000 :4.2694 seconds
Total time for foreach for array size 50000 :0.0002 seconds

Моим взглядам он не противоречит. А то что вы прочли и не поняли моих взглядов, это да.

а в чем смысл использования данной конструкции, которая дает сложность O(n), при том, что можно использовать конструкцию со сложностью O(1)?
При этом еще затраты памяти существенно меньше.

По мне так как раз использование array_values для получения первого элемента избыточно. Вот если бы надо было получить все элементы по порядку — то ок, а так — зачем?

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

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

Кто предлагает? Вы от чьего имени вещаете? От имени миллионов мух которые не ошибаются в мнении о собственном глубоком знании ООП ;)

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

Вопрос по PHP на собеседовании
Что, дружок, плюсы не осилил?)))

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

а так да, ты догадлив как и толпы остальных телепатов
это я так допился что по мне чертики так и прыгают, так и скачут.

наврядчи :)
але то байдуже.

дурні вважають що такими коментами вони когось шиють у дурні. ось у чому комізм ситуації :)

Угу))). Видимо, наступил на больной мозоль.

А вообще советую использовать SPL, а не задавать глупые вопросы

угу. это у нас в джаве называется
плодить абстрактные фабрики прокси объектов стратегий для вывода: Hello world!

или более универсально
ООП головного мозга.

Вижу, и Java ты знаешь только на уровне анекдотов...

от вас телепатов да, ни спрятаться, не скрыться :D

Зря вы так. Человек дельный совет дал. Дело в том, что для каждой задачи нужно пользоваться подходящим инструментом и для многих (да, не для всех) задач в SPL инструменты есть.
А по поводу

ООП головного мозга
не всегда это так плохо как принято считать. Например для детерминированых наборовгораздо лучшим решением будет обьект, чем ассоциативный массив. Пруф

Где-то на ДОУ я уже писал что массив в пхп хотя и универсален и мощный, приводит к плохо читаемому коду и трудно отлавливаемым ошибкам при описании иерархических, не симметричных сущностей с вложенностью больше двух, и я бы предпочёл читать код где эти сущности описаны с помощью pojo обьектов.

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

крутая инфа по ссылке, спасибо

не читал остальных, но предполагаю
reset($array);
echo current($array);
Это по первому вопросу

reset помимо установки указателя возвращает первый элемент массива

в случае с reset не нужно делать проверку на isset

вы, наверное, остальное не читали.
потому что
$arr = array('a'=> 4, 'b'=> 11);
и даже
$arr = array('a' => 4, 0=> 21);

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

Тому що:
$array = [2 => 2, 3 => 3, 0=>0];
echo $array[0]; // виведе 0 а не 2

а ты разрабатываешь код для того что бы он работал со всеми существующими дата старкчерами ? если выбран ассоциативный массив — то пишется код под него (тут где то было фор ич) , если обычный массив то $array[0].

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

попробую в третий раз:
дело не в скорости работы массивов

а в автоматизме программиста пишущего код. в навыке, привычке.

если вы так любите холивары,
я не люблю такие холивары.

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

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

Гораздо чаще проблема возникает в результате использования некорректных или медленных алгоритмов
да. и поэтому у меня просто автоматическая привычка использовать более быстрые алгоритмы вместо более медленных. привычка, понимаете? при чем тут ЧСВ, это просто — мой автоматизм.
я не задумывался о разнице ни в три миллисекунды, ни в три часа, когда впервые мне понадобилось написать код подобной функциональности.
и далее в обсуждении видно, что вот если бы задумался, начал бы считать такты процессора, да написал тест, то использовал бы isset или array_intersect.
а я — не думал. и нет у меня автоматизма phpиста на использование isset, и по описанию array_intersect я не додумался что эта функция подходит. то есть я обычный человек — я не знаю наизусть ни одну библиотеку из тех что использовал. и я не провожу научных изысканий по каждой строчке кода которую написал.
а как и всякий другой программист, выбираю паттерны, который избавляют от необходимости думать «как мне сейчас вдохнуть? придумал. так, теперь — а как мне выдохнуть? получилось. так, надо опять вдохнуть, как мне сейчас вдохнуть учитывая что мир вокруг стал немножко другим?... ».

и повторю суть вопроса:
мажно ли по гримитностя дилать выводы ап общай грамитности пишущего и в остальных вапросах?

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

А мне вопросы понравились, но считаю, что в таких вещах стоит разрешать гуглить :)
В плане, я считаю, что ответ $arr[0] неприемлем, но, если человек это понимает без объяснений и через 10 секунд нагугливает reset, то все ок, аналогично дальше по списку. Другое дело, что небольшое разнообразие в темах не помешало бы :)

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

Другое дело, что небольшое разнообразие в темах не помешало бы :)
весь список вопросов для собеседования у меня получается где-то размером с 20-30, и последующие вопросы зависят от ответа на предыдущие. и от общего хода собеседования конечно.
цель подборки вопросов — добраться до уровня некомпетентности собеседуемого.
так что разнообразие уж точно есть :D
А мне вопросы понравились, но считаю, что в таких вещах стоит разрешать гуглить :)
вопросы типа
— в какой «букве» паттерна MVC нужно помещать бизнес-логику?
— какие паттерны, подходы для динамического изменения схемы реляционной БД вы знаете?
тоже есть.

Мда, мабуть, мене б швидко відправили додому вчитися і не заважати людям працювати :)

разгадка подвоха моего любимого вопроса:
в какой «букве» паттерна MVC нужно помещать бизнес-логику?
Why Do PHP Developers Think MVC Is An Application Architecture?

Вопросы простые, не считаю, что вопросами по массивам можно показать знания. Это самые основы.

Там не знания, а кто круче

Шо ж это за язык такой ? :D Элемент массива первый достать и стоко хоботов...
a[1] #вот и фсе + пофиг на размерность, тип и т.д :D

Это внезапно второй элемент будет :)

ну в «пытоне» да, я для «R» писал :)

не, это внезапно будет элемент с ключом 0)

a[1] — это a[0]? Вы противоречите написанному выше (если a — массив с автоматически заполненными числовыми ключами).

В PHP говорим «массивы», подразумеваем hash-таблицы.

Не говорите за всех. Массив есть массив. Он может иметь строковые ключи, но по умолчанию не должен.
Кроме того, если ставится задача на обработку каких-то данных — формат входящих данных должен быть определен, а не угадываться программистом. Или давайте я вас попрошу написать парсер, который будет вытягивать из отчета брокера сделки, а самого отчета не покажу. И даже не скажу в каком он формате. И какого брокера. Потому что если разжевывать — проще сделать самому.

Потому что если разжевывать — проще сделать самому.
совершенно верно.
поэтому у кучи компаний — открытые вакансии есть всегда. например в нашей всегда открыты вакансии для Java и JavaScript программистов.
но не закрываются они потому что подавляющее большинство соискателей не подходят по одной из двух причин:
— запрашиваемый уровень оплаты превышает финансовую выгоду для компании
— уровень знаний программиста указывает на то что разжевывать ему всякую задачу придется не один месяц, т.е. тратить человеко-часы опытных программистов, вместо того чтобы эти часы были потрачены опытными программистами на написание кода. т.е. глобально — «трансакционные издержки» сведут на 0 выгоду брать на работу программиста которому все придется разжевывать.
у больших компаний, в сотни программистов — с этим полегче, поэтому они даже курсы трейни организовывают

если точнее то Ordered hash-таблицы

В чем разница между ассоциативным масивом и хешмапой ?

пусть будет так))

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

Ну есть словарик и шо ? Например

Ы <- list(lol = 1, b = «ololol», c = 1:10, «24» = 34,
hhh = summary(lm(cars$speed ~ cars$dist)))

Типа первый элемент — число, во втором строка, потом элемент с полностью идиотским именем и последний элемент — суммарный отчет качества регрессионной модели для «встроеного» датасета.
Хош достать 1 элемент — Ы$lol или Ы[["lol" ]] или тот же Ы[[1]]. Только нахер те словари надо ??? :))

У меня вообще шутливый пост был, при чем тут твой словарь вообще не доганяю ?

З.Ы. Когда прыгаю с R на Питон хочется убивать — с той же дыбильной нумерацией с «0». С тем же дбильными «ссылками», а не норм обьектами, с тем что Все не вектор и т.д.

Ну про array_push некритично, но можно глянуть в доку, где написано, что лучше вставлять «по-простому».

А про array_flip/in_array , ну может стоит поглубже копнуть функции работы с массивами (а то у меня почти фейспалм), ибо там есть вообще array_intersect, который решает задачу «в лоб» без перебора. Вот только не каждый объект сразу преобразовывается в массив, поэтому иногда просто перебор + проверка значения быстрее чем перебор не всегда предсказуемого результата после array_flip.

Погуглив как работает array_intersect, могу сказать, что он как раз таки сделает полный перебор второго массива для каждого элемента первого, что несомненно является наивным решением «в лоб» со сложностью O(n x m). Я бы предпочел использовать array_intersect_key, или решение предложенное топик стартером, чтобы уменьшить сложность до O(n). Конечно многие тут возразят или уже возразили, что для 5 элементов это не играет большой роли. Это правда. Только на практике со временем объем данных в этом массиве обычно вырастает и потом все удивляются почему все стало так дико тормозить.
Вы просто не представляете сколько подобного дерьма приходится потом разгребать после таких «синьоров», которые считают оскорбительными для себя вопросы по массивам. Какой смысл спрашивать человека про технологии, если он даже не может простой фрагмент кода написать на бумажке и обосновать почему он именно так написал?
В моей практике были примеры, когда лучшие практики, методологии и технологии разбивались об обычную компьютерную безграмотность: в проекте и аджайл самый что ни на есть аджайлистый, и паттерны вроде бы везде правильные, и домейн-дривен дизайн, и десятки тысяч юнит тестов с покрытием под 95%, и код красивый и читаемый (дядюшка Боб заплакал бы от умиления), и задокументировано всё, только когда копаешь чуть глубже — обнаруживаешь сложность O(n^4), там где она могла быть линейной и тихо охреневая, понимаешь зачем тут прикостылили три уровня кэширования, без которого можно было бы вообще обойтись, если б люди просто знали основы.

ОК, хотя (про intersect), возможно решение на Си нативной функцией php будет побыстрее самого php-кода. Принципиальной же разницы между object-> toArray() и последующим in_array() (с перебором 5 проверочных значений против массива значений из объекта) против flip+array_key_exists() + такой же перебор, но по ключам, вообще не вижу.

Ну или приведите, пожалуйста, код/псевдокод, чтобы было понятно, чем array_key_exists тут «правильнее» in_array.

А я разницу вижу: O(n + m) в варианте топик стартера против O(n * m) в вашем варианте :) Так как сложность выполнения array_key_exists — константная O(1) и не зависит от количества элементов в массиве, имеет смысл построить вначале хэшсет для массива сравниваемых значений, это займет O(m), а затем для каждого элемента оригинального массива проверить есть ли элемент в хэшсете, функцией array_key_exists, что в итоге даст сложность O(n).
В вашем же варианте для каждого элемента из первого массива будут проходы по массиву образцов, где асимптотическая сложность — O(n * m).

Кстати, открою секрет: array_intersect, так же как и другие стандартные функции в PHP и так является нативной функцией на C:

github.com/...1d8e/ext/standard/array.c

большинство стандартных PHP функций — всего навсего байндинги для сишных функций.

P.S. Я не PHP программист, поэтому пример писать мне лениво.

Хэшсет O(m) вы все равно как-то будете строить? Все равно ключ или значение придется сравнивать с образцами, нет?

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

Небольшой бенчмарк:
gist.github.com/...leur/b0b4233e7e3b5bc23527

Words: 18080
==========
Search words: 2
isset(): 0.016212463378906
empty(): 0.0059604644775391
array_key_exists(): 0.0059604644775391
in_array(): 0.57697296142578
array_intersect(): 5.141019821167
array_intersect_key(): 0.0028610229492188
==========
Search words: 10
isset(): 0.0059604644775391
empty(): 0.0030994415283203
array_key_exists(): 0.010013580322266
in_array(): 2.5861263275146
array_intersect(): 5.911111831665
array_intersect_key(): 0.0050067901611328
==========
Search words: 100
isset(): 0.044822692871094
empty(): 0.029087066650391
array_key_exists(): 0.10418891906738
in_array(): 22.525072097778
array_intersect(): 4.8739910125732
array_intersect_key(): 0.025033950805664
==========
Search words: 1000
isset(): 0.26512145996094
empty(): 0.24914741516113
array_key_exists(): 0.81014633178711
in_array(): 227.10299491882
array_intersect(): 6.4878463745117
array_intersect_key(): 0.42605400085449
==========
Search words: 10000
isset(): 4.3151378631592
empty(): 4.1048526763916
array_key_exists(): 9.9759101867676
in_array(): 2156.7180156708
array_intersect(): 10.092973709106
array_intersect_key(): 2.2311210632324
==========
Search words: 15000
isset(): 5.3508281707764
empty(): 4.5459270477295
array_key_exists(): 12.995958328247
in_array(): 3131.2470436096
array_intersect(): 12.935161590576
array_intersect_key(): 2.439022064209

Вот это уже интересно! Во-первых, не ожидал, что empty / isset быстрее всего прочего. Во-вторых может мне кто-то объяснит, почему функции «_key» быстрее обычных (типа in_array)? С точки зрения «и там и тут строки, массивы строк», алгоритм должен быть одинаковым. К сожалению, я программирование больше как вычислительные приложения в ВУЗе учил (специальность не программистская), а дальше (несколько позже) — довольно много вещей просто делал на php.

Во-первых, не ожидал, что empty / isset быстрее всего прочего.
может из-за «хака» в их релизации.
надо смотреть опкод а потом сишный. для обычного программирования на php это не требуется. достаточно просто знать это свойство.
Во-вторых может мне кто-то объяснит, почему функции «_key» быстрее обычных (типа in_array)?
Хеш-таблица
Ассоциативный массив
К сожалению, я программирование больше как вычислительные приложения в ВУЗе учил
ничего страшного. будет желание — доучите по дороге.
не будет — то и диплом по программиской специальности не поможет :)

В мире Java хороший джун или даже подготовленный trainee может нарисовать чуть ли не всю иерархию коллекций по памяти и знает все 23 шаблона GOF, но....в коде не может их показать и использовать, также как и не чувствует слои кода, фреймворки и т.д. Есть ли смысл в таких вопросах по отдельности? мне кажется что нет. Они сами по себе не показывают опытность разработчика.

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

для таких случаев существуют дополнительные и наводящие вопросы. Хотя «ненужного» джуна видно и так

Перечитай.

В мире Java хороший джун
. В мире PHP хорошие джуны тоже знают весь GOF, SPL и стандартные функции и как они работают.

Проводил кучу собеседований, но не встречал таких людей даже синьеров. Наверное не везло.

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

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

Когда я слышу/читаю «массив» — я себе представляю [’a’, ’b’, ’c’].

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

Вы — нет, а РНР-программист — да.

По моему скромному мнению, если у вас возникла потребность в микрооптимизациях типа тех, что указаны в топике, то имеет место один из вариантов (в порядке субъективной вероятности):
1. Проблема решается более эффективно другими способами (кеширование, изменение алгоритма, оптимизация работы с БД и т.д.)
2. Проблема решается более эффективно с помощью других инструментов/языков
3. Вам действительно это нужно. В таком случае нужно это специально указать, ибо это самый редкий случай.

O(1) среднему разработчику на PHP непонятна. я уже понял.
В мире РНР действительно не принято таким заниматься. Не потому, что это плохой язык или тупые разработчики, просто в 90% случаев это не нужно, а значит в остальных 10% нужно явно указать необходимость таких оптимизаций. Это как взять молоток и спросить: «Неужели тут не принято предварительно вычислять траекторию и силу удара?». Нет, не принято! Такой это инструмент. А если таки приперло, то с адекватным разрабом об этом договориться не проблема (за 2к думаю должен быть достаточно адекватный). И это уж точно не повод отсеивать кандидатов из-за ваших неверных представлений об экосистеме РНР.
По моему скромному мнению, если у вас возникла потребность в микрооптимизациях

у меня не возникла.

у меня просто правило, на любом ЯП
при одинаковой читабельности выбирай вариант более эффективный по выполнению.

и все. еще раз ПРИ ОДИНАКОВОЙ ЧИТАБЕЛЬНОСТИ

мне говорят что это правило идиотское. почему оно идиотское — я пока не понял.

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

а ПРИ ОДИНАКОВОЙ ЧИТАБЕЛЬНОСТИ почему выбирать алгоритм с O(1) вместо O(n) идиотизм?
не понял....

Из-за этого не совсем адекватно формулируются вопросы, исходя из неверных «умолчаний», ибо в мире РНР умолчания другие.
да.
за 2к думаю должен быть достаточно адекватный
почему 2к? думаю предложив 20к любую вакансию можно закрыть очень быстро.
странно, почему до этой идеи не додумались ни у нас в компании, ни в других.
у меня просто правило, на любом ЯП
при одинаковой читабельности выбирай вариант более эффективный по выполнению.

и все. еще раз ПРИ ОДИНАКОВОЙ ЧИТАБЕЛЬНОСТИ

вполне нормальное правило. Только по-моему всякие array_flip’ы в данном контексте явно не более читаемы, чем in_array. А значит в каком-то плане вариант с in_array даже более правильный, ведь читаемость выше, а про производительность требования не было.

Из-за этого не совсем адекватно формулируются вопросы, исходя из неверных «умолчаний», ибо в мире РНР умолчания другие.
да.
вот и я говорю :)
почему 2к? думаю предложив 20к любую вакансию можно закрыть очень быстро.
А, сори, это не вы в комментах про 2к упоминали, перепутал.
Только по-моему всякие array_flip’ы в данном контексте явно не более читаемы, чем in_array.
учту.
что array_flip в таком кейсе должен быть обязательно прокоментирован
// array_flip создает хэш из списка значений для использования при поиске по ключу.

Парни, вы издеваетесь? array_shift($ar) или reset($ar) (если речь идёт таки о _нулевом_ элементе).
Во второй задаче пофигу, что так, что так. В третьей делал бы точно так же.
Все три максимум могут показать, что человек знаком с синтаксисом и базовыми средствами, а не вчера установил вордпресс и пришёл на собеседование.
На нормальных собеседованиях на РНР спрашивают с какими фреймворками работал, какие в них плюсы и минусы, что такое ORM и какие реализации знаешь, какие использовал СУБД, работал ли с мемкеш и NoSQL... В общем, что вам надо чтобы он делал, то и спрашивайте.

Що робити людям, які постійно працюють з

ORM и какие реализации знаешь, какие использовал СУБД, работал ли с мемкеш и NoSQL
але уявлення не мають як працює
array_shift($ar) или reset($ar)
?

ХЗ. Сказать «я больше не заинтересован в этой позиции, до свиданья»? )

Чи ви сумніваєтесь, що він не осилить ці дві функції?
так, я сумніваюсь що людина яка не читає документацію малого розміру, в пару сторінок — читає та пам’ятає зміст, суть документації у сотні сторінок.
Якщо трохи перебільшити,
то я шукаю перекладача з англійської, який вміє перекладати з англійської самостійно, а не гугл транслейтом, або перепитуючи у інших перекладачів що поруч.
і який не відповідає що знати англійські слова та граматику йому впадлу, не обов’язково, бо все це можно знайти у словнику.

вакансій же повно(зиркнув — PHP 181 у розділі на доу), і якщо той перекладач такій успішний, то він знайде кращу компанію аніж моя. компанія в який я працюю — недостойна мати такого перекладача.

Чи бачите ви в такому проекті перспективу?
для вас особисто так, проект буде дуже корисний. AngularJS у тренді. з його знанням зможете самі обирати проекти, нехтуючи нецікавими.

для пошука кандидатів — навряд чи. наскільки мені відомо — переважна більшість програмістів майже нічого ніде не пише. в моєї компанії наприклад, наскількі я знаю, навіть на доу заходять раз в місяць. на 15-20 хвилинок.

тобто — більшість програмістів у «тіні», і мають тільки профіль у лінкедіні який теж поновлюють раз чи два на рік. і все. нічого інетрнет про їх фахові здібності не знає.

ну, мені 40+, тобто за канонами я вже пливу по Дніпру у труні... і вона, труна,, дешевенька. не те що мільона долярів не маю, а навіть 5к зарпалтні не маю.

тому, навіщо мені розказувати комусь про «смерть»?

Ваша історія не буде цікава джуніорам
вона й мені не цікава. я що, її не знаю, враховучи на рефлексію завище норми?
що бум ІТ-шників почався десь приблизно з 2000-их...
то немає значення. для суспільної думкі.
Але впевнений що будь-чия публікація може знайти своїх читачів
так. просто я ж про те і сказав — більшість не публікує нічого. ніде. і на гітхабі теж.
неможливо зробити індекс неопублікованих статей.
Я в шоці від того, що до цих пір немає такої платформи
оце добре! шок — оце ознака життэздатності!
можливо вони помиляються, час покаже =).
так. якби ото слухали «мудреців» які пояснювали що коні засруть усі лондони і парижі...

я без сарказму.

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

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

Я бы как-то неудобно себя чувствовал: пришёл вроде в серьёзную фирму, в рекваерментсах писали про ларавел, мемкеш и другие профессиональные инструменты, и тут вдруг про массивы скрипты писать
А потом в коде встречаем foreach внутри foreach для того чтобы найти пересечения, запросы к базам в циклах и использование гидрации там где не надо только потому что «работать с обьектами удобнее» и тд, а оптимизация заключается в том чтобы побольше мемкеш вызовов натыкать.

Если девелоперу все равно что применить для операции лукапа: массив(список) или хэштейбл — его никакой мемкэш не спасет.

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

Спорно. Memcached это ассоциативный массив по сути.
Проверить понимание принципов кеширования можно простой задачей про массив.
Вопрос именно про memcached намекает на должность code monkey либо для спрашиваемого, либо спрашивающего. Ср. jquery programmer.

Мне больше нравятся что на собеседованиях любят задавать «умные» вопросы, а на деле им надо шаблоны для WP крутить (типа пока проект не зашел, вот тебе что бы не просиживал), но зато на словах у них компания таких крутых инженеров что фуфайка заворачивается. Качество программиста определяет читабельность его кода, и способность находить и исправлять ошибки в нем и в чужом коде. Преждевременная оптимизация это зло, про которые даже дети в школе знают. Когда массивы начнут тормозить (если начнут), вот тогда и будете решать эти проблемы. К тому времени может или проект в трубочку свернутся, или вас там уже не будет, или тормозить будет все что угодно кроме массивов (возможно даже не пхп).

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

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

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

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

или тормозить будет все что угодно кроме массивов (возможно даже не пхп).
так и будет. тормозить будут наверняка не массивы. а понакрученная дата модель в ORM, потому что великий спец по PHP массивы не знает, но зато знает как работает ORM и базы данных.
да, верю. массивы это ж сложно. столько доки нужно перелопатить, столько лет практиковаться. а ORM к реляционке — делов то, гуглянул на стековерфлов — скопипастил, и все пучком.
за чей счет будут тогда решаться проблемы? программиста который к тому времени работает в другой компании?

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

вот именно. вот он да, подход — насрал код, передай копаться в говне другому.

Стандарты кодирования и код ревью. Решет эту проблему.

потому что великий спец по PHP массивы не знает, но зато знает как работает ORM и базы данных.

Зато проект вышел в продакшен на пол года раньше, и уже принес пару миллионов прибыли, что можно потратить на сервера, рефакторинг, или даже разработку проекта с нуля на Java, Net. А если не принес, то его можно слить в унитаз и без оптимизации.

ps: Собственно по этой причине и набирает популярность всякие orm, фуллстек фреймверки и node.js с его тоннами говнокода, оптимизированный код никому не нужен, сервера дешевые, важна только скорость разработки. Сейчас такое время, что кто первый вышел в продакшен того и тапки.

вот именно. вот он да, подход — насрал код, передай копаться в говне другому.

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

Не скатиться на дно, может помочь только налаженные процессы разработки. Все остальное ерунда.

Программисты работники за ЗП, они не мотивированны писать качественный код и им обычно плевать на продукт и компанию.. Только наивные джуны работая в бодишопе на оутсорсе будут вкладывать душу.
ваша философия понятна :)
я так понимаю проверена на практике, выкатили дохрена продуктов принесшим вам миллионы прибыли, и теперь ржете с идиотов кодящих за ЗП :)

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

Это философия всего современного мира. Скорость выхода продукта в свет и количество полезных фич гораздо важнее идеальной архитектуры и божественного кода. Потому что не существует второго Гугла, второго Амазона, второго Фейсбука и так далее. Восточных тигров в расчёт не берём, это другой мир. Применимость того или иного подхода в получении первого элемента массива в какой-то там строчке файла проекта на миллион строк будут обсуждать на Гитхабе десяток гиков. Остальные тысячи клиентов, которые никогда в глаза не видели этот код, будут приносить деньги. За эти деньги проект будет допиливаться и захватывать рынок. Рефакторинг должен производится только в случае тогда, когда этого или требует рынок, или стоимость саппорта гавнокогда по тем или иным причинам начинает превышать стоимость рефакторинга, тестирования и деплоя.
Программист, проходящий собеседование, должен уметь решать практические задачи и быть нацеленным на конечный результат — помочь кастомеру решить его проблемы и заработать на этом бабла. Всё. Спрашивать о нюансах применимости массивов программиста из мира пыхпыха, где большая часть проблем решается количеством серверов и раз в год переписывается половина кода проекта,- это расписываться в собственном непонимании конечной цели разработки ПО. Это же касается и энтерпрайзников, как бы там джависты не раздували щёки. Знание базовых алгоритмов и умение посчитать сложность — это добавляет ценности конкретному разработчику и несколько уменьшает количество последующего рефакторинга, но крайне слабо отражается на финальной стоимости продукта, в разработке которого участвует 1000 девов, половина из которых гавняет с точки зрения другой половины. Многодневные холивары на кодревью из-за синтаксиса трёх строчек кода — это лютый звиздец.
Конечно, когда собеседование проходит дев на разработку новой БД, или реалтайм системы, или эмбдед с экономией каждого такта и байта — неумение на листочке написать мёрж и квик сортировки — это фейл. Остальные херачат код, средняя продолжительность жизни которого — пару лет, и рубят на этом бабло. Спуститесь с неба на землю, наконец.

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

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

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

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

но и переписывание запросов к EAV таблице в цикле — тоже может отодвинуть тот прекрасный момент — релиз!

Многодневные холивары на кодревью из-за синтаксиса трёх строчек кода — это лютый звиздец.
бывает наверное. но чаще — окончательное решение за программистом более «высокого звания». а оно заслуживается знаниями и хорошим кодом. и зарплата другая.
где большая часть проблем решается количеством серверов и раз в год переписывается половина кода проекта
ой вопрос, согласен ли клиент увеличивать ежемесячные расходы, или предпочтет заплатить разово за устранение тормозов. в реале недавно клиент выбрал второе, и разорвал контракт с ит компанией поставившей свое решение, потому что следуя их совету — перейдите на более дорогие VDS он так и не решил своей проблемы. а цена хостинга у него выросла в несколько раз от начальной.
Остальные херачат код, средняя продолжительность жизни которого — пару лет, и рубят на этом бабло.
по уровню зарплат, не только в опросниках доу, как-то плоховато рубит бабло средний php программист :) на вылизывание кода время ж не тратит, должен бы выдавать его тогда больше, за тот же 1час.
Спуститесь с неба на землю, наконец.
я так понимаю те 180 вакансий по PHP тоже от компаний витающих в облаках?
чего ж они к соискателям пристебываются, раз не могут их закрыть?
как раз потому что — скорость выхода продукта важнейший критерий успеха проекта, переписать код ни у «плохого» ни у «хорошего» программиста не будет времени.
Я и не пытаюсь оспорить факт, что хороший дев сделает больше и лучше плохого дева.
Основная мысль в том, что хороший дев знает, где можно приподзабить на красоту и сделать так, чтобы работало с возможностью недорого рефакторинга/расширения функционала _когда_ это потребуется. Отличить хорошего дева от плохого, задавая ему вопросы о массивах, невозможно.

ЗЫ. Хотя, возможно. Надо брать тех, кто пошлёт интервьера с такими вопросами нахрен.

Кстати, что в этом плохого? Почему программист должен быть мотивирован писать оптимизированный и качественный код? Работает и ладно
Потому что ему за это деньги платят?

Не скатиться на дно, может помочь только налаженные процессы разработки. Все остальное ерунда.
Качество кода перекладываем на старших разработчиков. Пусть тратят время на ревью, нравоучения, потом отправляем на доработку и разраб опять правит и так по кругу. А если задача вот прям горит, прототип надо сделать и пофиг как оно будет работать — тут даже ревью тебе не поможет. Ах да, задача уйдет в беклог, технический долг и тд. Тут следом заходит новая, а потом еще и еще. Тут система начинает тормозить, падать, вместо 10 запросов к базе делается 200+. Менеджеры виноваты, процессы не такие?
Потому что ему за это деньги платят?

Конечно если требования к задаче что код должен отдавать 1M запросов в секунду, то да, говно не пройдет. А так если решены поставленные задачи, то какие проблемы? Деньги платят кстати за отработанные часы, а не за качество и количество кода, в договоре обычно так и написано.

Кто такие старшие разработчики? В нормальных условиях их не должно быть, разработчиков нет — есть только команда где все равны и продакт овнер, еще может быть скрам мастер. Ревью делают все и всех, без этого задача не может считаться завершенной, всякие прототипы это такие же задачи которые обязаны пройти ревью и соответствовать поставленным требованиям (но не более). Так же твой прототип ты сам завтра передашь допиливать другому разработчику, а сам займешься более приоритетной задачей. Суперменов не должно быть по определению.

Если система начала тормозить, значит это задача с высоким приоритетом, и ее решают в порядке очереди. Не бывает задач которые горят (тем более прототипы), если у вас такие есть, значит у вас проблемы с планированием.

Среди достаточного количества проектов, в которых я участвовал, ни разу не видел, чтобы затык был в скорости работы массивов, или, если вы так любите холивары, разницы между echo $a . '-' . $b; и echo "{$a}-{$b}";. Все эти проблемы надуманные и больше нужны для поднятия ЧСВ в поиске разницы в три миллисекунды в работе двух разных конструкций одного языка. Гораздо чаще проблема возникает в результате использования некорректных или медленных алгоритмов, где разница может составлять уже минуты.

Мне кажется, или топик создали для того чтобы потроллить пхпшников и тут же начать говорить «какие же они тупые и ничего не понимают»?

большинство пхпешников действительно ничего не понимают, но если отсеять тех кто сидит на ЦМСках, то соотношение непонимающих будет такое же как и в других языках. проблема в том что к PHP программистов причисляют... веб-мастеров что ли

давайте мы тогда всех студентов, которые делают лабы на c#/java будем приписывать к профессиональным разработчикам и тыкать пальцами. концентрация таковых больше будет чем «мастеров вордпресса», а javascript разработчиков называть «jquery мастерами»

Студенты не работают, а вебмастера работают, говорят что они php программисты. Да в js мире это отдельая огромнейшая каста jquery программист, и поэтому все печально

когда я 1Сничал — тролили что 1Сники тупые, и никакие не программисты.
когда основным языком стала Java — троллили что это для ни асиливших настоящие языки.
теперь когда пыхаю — да, тоже тупой. и вот сам себя решил потроллить :)

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

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

Вот некоторые углы большинства собеседований:
1. Биг боссы делают подбор новых сотрудников в команду, чтобы «промотивировать» работать тех, кто уже нанят. Не факт, что наймут, но страху наганяет.
2. Собеседуют, те кто уже нанят, они понимают, что новые люди в команду не нужны. Соответственно и собеседуют на знание «тайных практик майя», чтобы завалить кандидата. Иногда Собеседование слушает еще 1-3 человека в скайпе и здесь собеседователь не может упасть лицом в грязь. Кандидат нещадно «рвется» на куски.
Если еще добавить, что собеседовать назначают человека, который в этом не заинтересован,то и вопросы задаются те, которые найдены в инете...
3. Сам процесс собеседования вызывает когнитивный диссонанс у кандидата, которого на собеседование заманила ХР рассказав о дружном коллективе...

Вот в результате и имеем такое хождение по кругу: соискатели полагают, что интервьюеры такие себе задроты особого вида, кандидаты на собеседования смотрят как на мини пытку ибо нужно «помнить все».

Конечно, если в компании уже работают друзья кандидата, то собеседование намного по другому и проходит и другое спрашивается :)

когда я 1Сничал — тролили что 1Сники тупые, и никакие не программисты.
когда основным языком стала Java — троллили что это для ни асиливших настоящие языки.
теперь когда пыхаю — да, тоже тупой. и вот сам себя решил потроллить :)

Не нужно все принимать на свой счет.
Есть направления которые уже «обгавняли» тонны желающих «кушать сыр по 500 грн».

Не нужно все принимать на свой счет.
я давно и не воспринимаю :)

«слова ап Павла об ап Петре нам говорят больше о самом Павле, чем о Петре» Ницше.

слушаешь аргументацию, и все понятно с троллящим 1С, Джавы и PHP

или как я недавно писал о троллящих GoLang.

не перестаю удивляться вопросам, которые здесь мелькают... дивная у нас страна... и народ у нас такой... дивный...
«Какие по вашему мнению вопросы по работе с массивами показывали бы степень опытности программиста, и не были бы придирками, а основаны на типичном применении массивов в PHP».
По моему мнению — никакие.
Определять «степень опытности программиста» на основании ответов на «вопросы по работе с массивами» — попытка составить определение «сферического коня в вакууме».

Ну давайте еще про кавычки, жгите уже на полную )))

а программисты на PHP и про них, в PHP не знают???
афигеть.

А вы знаете когда двойные работают быстрее одинарных?

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

интерполяция быстрее конкатенации..

а-а-а, речь была о «сложении» строк...

речь о работе с переменными: в одинарных кавычках не работает интерполяция
то есть, речь о разнице
«You are at the page #$pageNumber»
и
’You are at the page #’ +$pageNumber

речь о работе с переменными: в одинарных кавычках не работает интерполяция
так это в спеке языка написано.

я так понял вопрос уедающий и был в разнице применения.
я погуглил после него сразу php concatenation vs interpolation
но результаты оказались противоречивыми.
надо то ли самому проверять, либо смотреть в код интерпретатора.
очень уж разные оценки, и даты статей

кстати, по наивности я спросил пару раз в начале — что там такого и как изменили в php 7 что по синтетическим тестам получился прирост быстродействия вырос почти в 2 раза.
я то следил (уже) прошлый год.
ввиду того что размер увеличения глаз скатился до опасного для здоровья соискателя, и я, скатился, до вопросов про массивы, без спроса совета где либо, и у кого либо.

но, как писал уже, у меня самого глаза стали выпучиваться как у Шварца в «Вспомнить все»

в гугле больше ссылок ссылок по запросу

php concatenation vs interpolation
;)

но другие то:
Inlined: 0.9793s
Concatenated: 0.9252s

в цикле
“these are $foo” 0.0035568
these are {$foo}" 0.0035388
these are " . $foo 0.0025394

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

присваивание:
+ 100 %single (’) quotes. 20 bytes Text : $tmp[] = ’aaaaaaaaaaaaaaaaaaaa’;Total time: 68 µsview code
+ 119 %double (“) quotes. 20 bytes Text : $tmp[] = “aaaaaaaaaaaaaaaaaaaa”;Total time: 81 µsview code

я доверюсь core разработчику zend engine, а не рандомным ссылкам из гугла

про конкатенацию будет время покопаю.

до этого не интересовался, исходя из предположения что движок яп который предназначен для перемолачивания строк — заооптимизирован для операций со строками до предела. если не в «этой», то в «следующей версии»

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

Дожили... судя по ответам ниже «Зря» на третий пример, hashtable для украинского программиста стал магией... :)

Вот пара кейсов, вполне вероятных:
Чувак кодил всю жизнь на другом стеке и не факт что это веб стек(геймдев и прочее), но тут решил перейти на пхп. Естественно он не будет знать все ньюансы и документацию наизусть, но за месяц-два втянется и будет писать на уровне старших разрабов. Из-за незнания массивов мы его сразу отшиваем?
Другой кейс, чувак был пхп разрабом, так сложилось ему пришлось заниматься активно еще java/scala/etc для обработки данных допустим, или 90% времени проводить на фронте, проект закрылся и вот он сидит напротив вас и не может рассказать в деталях о массивах. Разраб тоже отпадает?

указанные варианты будут отсеяны еще на уровне рассмотрения резюме эйчарами.
так что меня эти два случая никак не интересуют.
я не столкнусь на интервью с такими :)

погибнуть под навалой соискателей «вайтивайти» — да, доблесть :)

То есть чувак с другого стека — это «вайтивайти»?

ну я в php пришел с другого стека. и?

Значит вы тоже были " вайти-вайти"? по вашей логике

моя логика к вашей способности читать и понимать — не имеет отношения.
так что как вам удобно, так себе и думайте :)

так же верно и обратное:)

Другой кейс, чувак был пхп разрабом, так сложилось ему пришлось заниматься активно еще java/scala/etc для обработки данных допустим, или 90% времени проводить на фронте, проект закрылся и вот он сидит напротив вас и не может рассказать в деталях о массивах.

Очень даже реальная ситуация, особенно если человек имеет опыт в АйТи больше чем 10ть лет.
Более того, он может кодить сразу на нескольких языках...

Очень даже реальная ситуация, особенно если человек имеет опыт в АйТи больше чем 10ть лет.
у меня больше 20ти. на разных языках. правда на функциональных опыта нет.
кстати, тоже прикольно, в русскоязычных статьях php программисты сплошь употребляют «функциональный стиль» в значении, принятом в остальном программерском мире — «процедурный стиль». потому что «функциональный стиль» — это соовсем другое.

у каждой тусовки свой жаргон. иногда весьма непривычный.

думаю, просто люди не правильно используют устоявшийся термин.
и можно цеплять и бить по башке :)

и можно цеплять и бить по башке :)
или просто выучить жаргон.
я выбрал второе, и просто перевожу на лету.
комьюнити у PHP огромно. не перевоспитать :)
кстати, тоже прикольно, в русскоязычных статьях php программисты сплошь употребляют «функциональный стиль» в значении, принятом в остальном программерском мире — «процедурный стиль»
а можно пример какой-нибудь (видимо давно я не читал русскоязычные статьи про php, пока слабо понимаю о чем речь)?

на хабре сплошь и рядом, особенно в коментариях.

но, нагуглил:
Семинар «ООП в PHP — введение в объектно-ориентированный подход»
...
Цель данного курса — научить разработчиков на PHP, использующих функциональный подход, создавать веб-приложения с использованием объектно-ориентированного подхода.
...
План семинара:

Функциональный подход
1. Подход «все в одном файле». Недостатки.
2. Разбитие кода в файле на функции. Группировка функций по файлам.
3. Недостатки полученного решения.
it.rabota.ua/...02/seminar_OOP_v_PHP.aspx

таки да, умудрились перепутать с модульностью, раньше как-то и не замечал такого

С точки зрения своего опыта девелопмента и собеседований имею такие наблюдения:
1. Оптимизация алгоритма дает больший прирост производительности, чем знание тайных заклинаний получения первого элемента массива.
2. Тайные заклинания написания супер производительного кода либо тормозятся медленным каналом у юзера либо дешевле доплатить хостеру, чем переплачивать девелоперу. Более того, можно разные приложения захостить на разных хостах, иногда это дешевле, чем докупать ресурсы у прова.
3. Вопросы на собеседованиях о синтаксисе языка это для джуниоров или мидлов. Для сениоров уже должны быть вопросы о методологии разработки, подходах к решению типичных и не типичных ситуаций из жизни (!).
4. Очень хорошо садит на попку интервьюера когда он знает, что соискатель видел профайл интервьюера — они (интервьюеры) тогда не такие злые и меньше знают о том, как проводятся собеведования там :) Более того, когда интервьюер не может показать свое порфолио...
5. Дайте реальную задачу из жизни и послушайте подход к решению: что понадобится, как будет решать, как соискатель намерен разрулить возможные проблемы и какие возможные проблемы видит соискатель в предложенном решении.

З.Ы. Лет 10 назад я тоже был таким перфекционистом, потом понял, что когда меняются (добавляются) девелоперы на проекте и времени не хватает, то уже важнее, чтобы код был написан понятно, а не заумно.

так ви что предлагаете про O начать спрашивать и алгоритмы? Ну тогда думаю совсем грусняво будет с набором PHP шников мидлов :)
на самом деле собеседования тема большая — есть над чем подумать

все зависит от того, что Вы хотите получить в результате :)

если у человека есть портфолио, то можно поспрашивать что он использовал в каких своих разработках + пусть расскажет о каждом приложении подробности.

по его ответам будет ясно он писал тот код или нет.

спрашивать сениора о синтаксисе языка — это из серии «не учите маму писять» :)

если использование определенных подходов свято, то пишется меморандум с примерами кода для типичных задач. некоторые такое называют «лучшие инженерные практики» :)

На собеседованиях я задаю вопрос:
Как получить первый элемент массива?
Правильного, с моей точки зрения, ответа я пока не слышал.
И какой же с вашей точки зрения правильный? Мой вариант примерно такой:
$el = isset($arr[0]) ? $arr[0] : null;
Можно сделать не так, можно проверить длину массива и например выбросить исключение, если длина 0. Зависит от того, какая реакция программы должна быть на нестандартную ситуацию с пустым массивом.
Пример 2
В тестовом задании встретил применение array_push($a, ’foo’) хотя по коду прекрасно подошел бы $a[] = ’foo’
Это пример — правильной привычки, безопасного программирования? так принято в мире PHP?
Нет, так принято у автора кода. У меня принято $a[] = ’foo’, так как эта запись читается лучше, чем array_push. Особенно когда таких строчек будет несколько подряд.
Пример 3
Задача — выбрать из массива объектов такие, у которых поле равно одной из пяти строк.
Человек пишет код, в котором помещает эти строки в массив, и для каждого объекта вызывает in_array с значением поля.
Я бы тоже так сделал, просто и понятно.
Я зря пристебался что array_flip а затем array_key_exists для каждого объекта — будет более правильным ответом, ввиду более высокой скорости работы?
Зря. Я например даже не понимаю, как предложенное вами решение будет работать. Станут объекты ключами после array_flip, и что дальше? Как поможет array_key_exists? А прикиньте, как потом эту магию поддерживать. Даже сам забываешь через время что делает этот кусок кода, про другого разработчика я вообще молчу. И все ради скорости, которая не так критична, как вы думаете. Или ты обрабатываешь десятки-сотни объектов и +/-0.001с на каждом не играет роли, или нужно обрабатывать миллионы объектов и такая магия уже не поможет, нужны другие подходы.
Магия допустима для упрощения кода. При этом нужно убедиться, что магия не высшего уровня и достаточно понятна среднему разработчику. Или снабжать такую магию комментарием.
И какой же с вашей точки зрения правильный? Мой вариант примерно такой
угу, окажется что нужно первый элемент ассоциативного массива достать
Я бы тоже так сделал, просто и понятно.
тут речь идет о 18тыс массиве, тоже как оказалось

Ну, другая задача — другое решение. А «игра в шахматы» (продумай все-все варианты развития задачи) ни на собеседованиях, ни в процессе работы меня не привлекает.

Ну, другая задача — другое решение. А «игра в шахматы» (продумай все-все варианты развития задачи) ни на собеседованиях, ни в процессе работы меня не привлекает.

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

и точно, такие «шахматы» первый признак проблем в работе под шефством такого «босса»

А «игра в шахматы» (продумай все-все варианты развития задачи)
не выдумывай, не подменяй условия задачи.
вы — подменили. но виноват конечно тот кто ее ставил. и потом вопли по инету о плохом менеджменте.

а разжевывать задачу до таких деталей — так дешевле заказывать разработку у фрилансера.

хотя и с этим проблема:
пишешь в задании — результат работы выложить в приватный репозиторий на Битбакете (в любом типе сис контроля версий) и предоставить доступ для userfoo.
чел шлет зип исходников мылом, с припиской, — ну если очень надо, то я выложу на битбакете.
а нафуя я тогда писал вообще про битбакет если оно мне не надо?

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

а разжевывать задачу до таких деталей
В магазине возле дома тоже ни за что не признавайтесь, какой хлеб вам подать. Ведь если так разжевывать задачу — проще пойти в супермаркет и взять нужный хлеб самому.
хотя и с этим проблема:
пишешь в задании — результат работы выложить в приватный репозиторий на Битбакете (в любом типе сис контроля версий) и предоставить доступ для userfoo.
чел шлет зип исходников мылом, с припиской, — ну если очень надо, то я выложу на битбакете.
а нафуя я тогда писал вообще про битбакет если оно мне не надо?
в резюме стояло — знает гит.
Отсеивайте без эмоций — он не знает гит и битбакет и не хочет ради этой работы изучить. Нечего обсуждать тут даже, человек не прошел тест. Если все такие приходят — значит условия работы недостаточно привлекательны для других.
В магазине возле дома тоже ни за что не признавайтесь, какой хлеб вам подать.
В вакансиях часто можно встретить фразу
— Способность к принятию самостоятельных решений.

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

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

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

Если все такие приходят — значит условия работы недостаточно привлекательны для других.
да, есть такое дело. эйчары пересылают иногда вопросы — а что конкретно за проекты, чем буду заниматься. я знаю что можно ответить чтобы заинтересовать. но врать то зачем? не будет у нас Symfony2 и Yii в ближайший год. полностью понимаю тех кто на этом ответе больше не появляется.
В вакансиях часто можно встретить фразу
— Способность к принятию самостоятельных решений.
Вот я и принял решение, что массив не ассоциативный, а самый обычный. И вообще, проблема вопроса в том, что работнику вы будете давать более комплексные задания. А большинство массивов в его коде будут сформированы его же кодом и ему будет известно что именно у него за массив. То есть вы морочите голову вокруг микрозадачи, которая на практике не возникнет. Фактически проверяете знание синтаксиса.
от я и принял решение, что массив не ассоциативный, а самый обычный.
ошибка. подбор абстракции должен быть адекватен входящим данным, а не собственному удобству.
И вообще, проблема вопроса в том, что работнику вы будете давать более комплексные задания.
да стопицот раз можно давать такие задания. только будет мое давнее
«реальная программа вычисляющая корни квадратного уравнения отличается от лабораторной работы с той же формулировкой количеством кода инфраструктруы и обработки ошибок»

вы что же думаете, свою карьеру программиста я начинал с супер-бупер програмера?
не. я был самым пресамым младшеньким, которого взяли «по блату» (служили вместе), и который с год сидел на написании внутренних утилит конвертации. и за каждый баг крыл меня .ями не шеф, а сослуживец. а потом приходил, и пояснял за что.
и Суботника «Язык программирования С» я в итоге перечитал раза три. и сам удивлялся, что я там находил новые абзацы, новые примеры кода.

То есть вы морочите голову вокруг микрозадачи
то есть вы решили, что полтора часа собеседования — это вот эти три вопроса?
как уже в другом посте написал — двоих!
два долботятла, рекомендованые ПМами, ейчарами, сношают в митинг руме невинного соискателя вопросами про массивы php
так и есть!
Фактически проверяете знание синтаксиса.
тут правида. какия розница, што чилавек напашат. кампилятор, а вперед ниго идоё зкажет, иде абшипка.

хашая правдо.

ошибка. подбор абстракции должен быть адекватен входящим данным
Какие данные, такая и абстракция.
тут правида. какия розница, што чилавек напашат. кампилятор, а вперед ниго идоё зкажет, иде абшипка.
хашая правдо.
В php нет компилятора. Но с ошибками синтаксиса IDE справляется на ура. Даже проверяет имена переменных по словарю и опечатки подчеркивает.
то есть вы решили, что полтора часа собеседования — это вот эти три вопроса?
Какая разница какую часть собеседования занимает этот, ничего по сути не показывающий вопрос?
В php нет компилятора
да вы что???
может прочтете определение компилятора и включите головной мозг? ;)
ну там про опкод вспомните...
Но с ошибками синтаксиса IDE справляется на ура
да, и PHP Parse error:
поэтому исчезли как класс. аха.
Даже проверяет имена переменных по словарю и опечатки подчеркивает.
да, это круто. ошибся в букве переменной, получилась другая переменная, IDE говорит — молодец, грамотно!
а ты — опечатался.
Какая разница какую часть собеседования занимает этот, ничего по сути не показывающий вопрос?
он уже показал, исходя из обсуждения, что в мире пыха
не принято читать документацию

а то что вы пишите, показывает что с вами о php не о чем говорить.

PHP — интерпретируемый язык, если вы не знали.

конечно не знал. откуда мне было знать :D
я ж вообще полный неуч, факт!

но вы все же прочтите определение компилятора в вики.

З.Ы. свежайшая информация от
JAN 19, 2008

PHP (and it’s actual compiler/executor component, the Zend Engine) are going to go through a multi-stage process:

Scanning (a.k.a. Lexing) — The human readable source code is turned into tokens.
Parsing — Groups of tokens are collected into simple, meaningful expressions.
Compilation — Expressions are translated into instruction (opcodes)
Execution — Opcode stacks are processed (one opcode at a time) to perform the scripted tasks.
blog.golemon.com/...nderstanding-opcodes.html

тут речь идет о 18тыс массиве, тоже как оказалось

как я люблю такие уточнения по факту :)

угу, окажется что нужно первый элемент ассоциативного массива достать
конечно. если в задаче ничего не сказано о ключах, то откуда взялось предположение у исполнителя что в массиве будет ключ — 0
тут речь идет о 18тыс массиве, тоже как оказалось
речь шла о привычках.
чтобы потом не профайлить и не переписывать.
речь шла о привычках.
чтобы потом не профайлить и не переписывать.
Golden hammer in practice

Есть массив и ассоциативный массив, или массив со строковыми ключами. Или хешмап, как некоторые его называют. Когда я слышу/читаю «массив» — я себе представляю [’a’, ’b’, ’c’]. И когда я буду решать реальную задачу — я уж точно буду знать сразу, какого вида массив приходит.

чтобы потом не профайлить и не переписывать.
Ну, вы заказчику расскажите, что для решения простой задачи перебора 10 элементов пишете очень оптимальный код, рассчитанный на перебор 18000 элементов, поэтому заняло в 3 раза больше времени и стоит в 3 раза больше денег. Вам спасибо скажут, ага.
Есть массив и ассоциативный массив, или массив со строковыми ключами
давайте сразу перейдем к обсуждению что такое первый элемент :D
Когда я слышу/читаю «массив» — я себе представляю [’a’, ’b’, ’c’].
а я нет. ибо это не массив — а список. а раз список, то мне нет никакой нужды использовать специфические свойства списка в PHP чтобы получить — первый элемент.

ошибку свою понял. вопросов про массивы больше не будет :)

ошибку свою понял. вопросов про массивы больше не будет :)
Лучше ничего не спрашивайте. Ответы все равно анализировать не умеете.
Ответы все равно анализировать не умеете.
руководство компании считает по другому.
но да, вам видней :)

Мне не видней, у меня сложилось такое впечатление от ваших ответов в теме. Может это и не так, но вы мне представляетесь таким интервьюером-экзаменатором, который ставит вопрос с подвохом и такой потом «Ага! Неправильно!». Как в этом анекдоте:

Идёт экзамен по логике.
Профессор:
— На борту самолёта 500 кирпичей. Один кирпич выпал из самолёта. Сколько на борту осталось кирпичей?
Студент:
— Ну, это легко! 499!
— Правильно. Следующий вопрос. Как поместить слона в холодильник в три приёма?
— 1. Открыть холодильник. 2. Поместить туда слона. 3. Закрыть холодильник.
— Дальше. Как поместить оленя в холодильник в четыре приёма?
— 1. Открыть холодильник. 2. Вынуть оттуда слона. 3. Положить оленя. 4. Закрыть холодильник.
— Отлично! У царя зверей льва день рождения! Поздравить его пришли все животные, кроме одного. Почему?
— Потому что олень всё ещё находится в холодильнике.
— Великолепно! — говорит профессор. — Пойдём дальше. Может ли бабуля пройти через болото с крокодилами?
— Конечно, может! Ведь все крокодилы ушли праздновать день рождения льва.
— Хорошо! А теперь последний вопрос. Бабуля прошла через пустое болото, но всё равно умерла. Что с ней случилось?
— Э-э-э... Может быть, сердечный приступ?
— А вот и нет! На неё упал кирпич, который, как вы помните, выпал из самолёта. Через недельку, голубчик, придёте ко мне на пересдачу!..
Мне не видней, у меня сложилось такое впечатление от ваших ответов в теме.
ну, на доу у меня определенная репутация. а так как в инете я много где заработал «подобную» репутацию, и после обретения оной лучшие по «карме», админству предлагали встретится в реале, покалякать о томе о сем, и после встречи — еще взаимно назначали встречи, то я себе так думаю, за годы с конца 90ых в релкоме, а потом инете — наверное НЕ стоит реагировать на типичную оценку себе :)
но вы мне представляетесь таким интервьюером-экзаменатором, который ставит вопрос с подвохом и такой потом «Ага! Неправильно!».
я не люблю собеседовать. и не только я. в моей нынешней компании народ клянет эйчаров что суют фуфло и в итоге — потерю времени.
и в предыдущих так было.
может и есть среди коллег по цеху, кому нравится проводить собеседования.
но мой житейский опыт говорит о том что у программистов основной девиз:
да пошли вы нах, соиксатели тупорылые!

это я так упростил чтоб долго не объяснять.

бывают исключения конечно. в итоге которых человека берут на работу. ну так получается, что технарь-социопат отстаивает человека ПОСЛЕ собеседования. и перед ПМами, и перед техлидами. любовь что-ли возникла у них там, в «митинг руме»...

в нынешней компании поэтому собеседуют всегда двое. и все равно, основной ответ:
да пошел ты нах!

и редко — да вы все нифига не поняли в человеке! дайте ему месяц испытательного!

Первый элемент обсудили вдоль и поперек...

прикиньте, как потом эту магию поддерживать.
в чем магия поиска значения в массиве?
в замене названия применяемой функции?
При этом нужно убедиться, что магия не высшего уровня и достаточно понятна среднему разработчику.
O(1) среднему разработчику на PHP непонятна. я уже понял.
в чем магия поиска значения в массиве?
Я не понял вашего решения. Вообще. Покажите код.
Я не понял вашего решения. Вообще. Покажите код.
И да будет холивар! :)

Не будет — мне пора идти, нет больше времени сегодня на доу.

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

не будет. потому что решение в этой теме уже обсуждалось.
почему-то Sergey Zolotov его понял, хотя и высказал замечания.

Понял. Я просто ещё не долистал... :)

Я взагалі не зрозумів, у чому проблема отримати перший елемент масиву? Тут більше проблема у формулюванні самого питання, бо якщо стоїть задача просто отримати — ну так $Array[0], чи я помиляюсь?

$Array = [’fruit’ => ’apple’, ’vegetables’ => ’carrot’, 0 => ’spagetti’, 1 =>’tort’]
Что вы думаете вам $Array[0] выдаст?

А зачем получать первый элемент ассоциативного массива? Тем более, зачем использовать и строковые, и числовые ключи? Это какой-то особый вид извращений?
P.S. $Array[0] выдаст ’spagetti’

В треде про C++ был большой холивар на эту тему

Я не читал, потому что никогда не писал на плюсах

а там не про плюсы.
а про абстрактное мышление был разговор.

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

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

Вы им еще скажите, что в разговоре программистов «первый элемент массива» и «нулевой элемент массива» подразумевают одно и то же :-)

Вы им еще скажите, что в разговоре программистов «первый элемент массива» и «нулевой элемент массива»
нумерация массивов в языках программирования бывает и с 1цы. а бывает и интервальная, при описании типа.

во-вторых абстракция «первый» применима и к «первый элемент списка». и «первый ключ хэшмапы».

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

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

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

Шановна, ТС не писав саме такого масиву, а, отже, я взяв на себе сміливість використати як приклад звичайний масив зі стандартними елементами

Це традиційна гра на свпівбесіді, 90% інтерв’юерів її люблять. «Вгадай, яке доповнення до простої задачі я собі задумав і тобі ще не сказав». Якщо так ставляться і реальні робочі задачі — то до дупи такого роботодавця.

Дякую, тепер я буду знати, яких роботодавців посилати у дупу 😊

так, у trainee PHP — величезний вибір роботодавців. :D

Авжеж 😁А якщо серйозно, то майбутнього мене ніхто не позбавляв, а, отже, будь-яка інформація стане у нагоді

просто, зазвичай в житті так — в дупу посилають частіше того, хто сам любить посилати у дупу :)

А якщо серйозно, то майбутнього мене ніхто не позбавляв,
так. якщо нема війни, чи якихось катаклізмів — то майбутнього зазвичай себе позбавляє сама людина.
так що — і мене шли в дупу! і так дій завжди у випадках коли тобі щось десь у когось не подобаєця. і матимеш — велике дупне майбутнє! ;)

Ем...це був занадто складний жарт. Дупне майбутнє?Шо?Ні, дякую.

Ні, дякую.
кому? я тут ні до чого. ви самі оберете те, чи інше майбутнє.
я просто про деякі правила його формування.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

То була дупна абстракцiя. Видно з контексту)))

Я зря пристебался что array_flip а затем array_key_exists для каждого объекта — будет более правильным ответом, ввиду более высокой скорости работы?

Зря.

В тестовом задании встретил применение array_push($a, ’foo’) хотя по коду прекрасно подошел бы $a[] = ’foo’

Чем прекрасно то?

Зря.
из
www.youtube.com/watch?v=n9fzugqAHKE
array_key_exists 0.11 сек vs 268 сек array_search vs 311 сек у in_array
Чем прекрасно то?
отрывок из документации — php.net/...u/function.array-push.php
Замечание: Вместо использования array_push() для добавления одного элемента в массив, лучше использовать $array[] = , потому что в этом случае не происходит затрат на вызов функции.

Ага... Только вот тот, кто приходит к вам не обязан знать ВСЮ документацию. Если он решает задачу по-другому, то на то должны быть свои причины: ему так удобнее, он так делал постоянно, так делал человек, у которого он учился и т. д. и т. п.

Можно просто спросить почему он выбрал именно этот путь. И всё. Или вы хотите сказать, что ваше решение «правильное», а его «не правильное»? =) Не думаю что хотите, а поэтому понимаете о чём я говорю.

P. S. Если уж вы ссылаетесь на этот документ, то каких именно затрат? Сколько это? 1 сек? 1 мин? Нет, это всего-то миллисекунды.

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

Ага... Только вот тот, кто приходит к вам не обязан знать ВСЮ документацию.
а нафига ее знать всю?

— знаешь как работают мэпы
— знаешь про тип данных array в PHP
— открываешь один раз страничку — функции работы с массивами на php.net, читаешь описания, чтобы — «а помню есть функция, которая делает то-то и то-то, как там ее название, не помню, минуточку ...»

по крайней мере я так узнал. да и по джаве — я что, помню все системные функции, иерархии классов, и т.д.? зачем?

Вы противоречите сами себе. Сначала вы ссылаетесь на то, что на php.net написано что якобы «это» лучше «того», но тут же говорите, что не нужно всё знать. Тогда зачем вы спрашивали про «должен ли»? =)

Вы противоречите сами себе. Сначала вы ссылаетесь на то, что на php.net написано что якобы «это» лучше «того»,
прочесть по диагонали документацию — это не знать на память названия, параметры и нюансы системной библиотеки.
Тогда зачем вы спрашивали про «должен ли»? =)
да я понял что это немодно, читать документацию.
Сколько это? 1 сек? 1 мин? Нет, это всего-то миллисекунды.
пруф? вы замеряли, чтобы оспорить это замечание?
я не проверял. поверил на слово рекомендации документации.
вы не верите, наверное проверили?

Сергей, я дальше не буду отвечать на ваши реплики. Думаю вам моя точка зрения понятна =) Вы же за этим сюда пришли =)

Уверен, что у вас достаточно опыта, чтобы прислушиваться или нет, дело ваше.

P. S. Помню как на собеседовании меня спросили о паттернах, а я сказал: «Я их не применяю и их не знаю, потому что:

— я их не обязан знать и использовать;
— я и без них пишу норм код;
— они имеют как плюсы, так и минусы, зачем же их использовать?»

И там ещё пару доводов, уже всех не помню. И меня взяли. В хорошую фирму с хорошим окладом.

Думаю умение «завернуть» свои посылы намного важнее того, знаю ли я что там написано в документации или не знаю.

P. P. S. Через пол года я всё таки научился применять паттерны, т. к. на том проекте они были слошь и рядом и понял что ошибался :D

Экономить на вызовах функций — это обычно плохая практика. Лапшу никто не любит.

Лапшу никто не любит.
при этом массово код на php перемешан с html кодом, хотя ж не надо никаких ООП с MVC чтобы вынести логические блоки в отдельные функции в этом же файле, и передавать им параметры, для формирования конечного кода html для вывода...

любят лапшу в мире php, очень любят :)

А где ее не любят? те жи java программы на 80% состоят из говнокода и лапши, и ничего Энтырпрайзззз...

да, есть мнение что везде говно.
я такое мнение и у хаскелистов встречал — «понаехали, и хаскель превратили в гавно! а потому будущее за — Agda! туда еще рукожопые не понабежали!»

array_key_exists 0.11 сек vs 268 сек array_search vs 311 сек у in_array
как бы в условии нужно указывать что речь идет об 18тыс элементах
как бы в условии нужно указывать что речь идет об 18тыс элементах
все так. или 8 тыс вызовов на 1ой тысяче элементов.

но по обсуждению я уже понял, вопрос этот задавать больше не буду.
использование алгоритма O(1) вместо O(n) при той же читабельности, в мире PHP считается глупостью

использование алгоритма O(1) вместо O(n) при той же читабельности
в целом — да. но.
для array_flip значение должно быть либо строкой, либо числом. false, null, вложенные массивы и объекты предсказуемо приводят к warning’у и игнорируются(in_array пофиг, хотя, в случае с объектами там уже вылезет боком проверка по ссылке)
’1′ и 1 считаются идентичными при проверке array_key_exists(in_array позволяет строго учитывать типы)
потому как точечная оптимизация в определенном кейсе очень даже ок
но как реализация проверка «по умолчанию» — добавляет рисков.
и точно не «с той же читаемостью» — да, можно привыкнуть как к паттерну, но в принципе «in_array» выглядит как проверка «входит в массив». в то время как конструкцию array_key_exist(key, $flippedArray) надо еще парсить мозгом, выискивая «$flippedArray = array_flip($source)» строчками выше
для array_flip значение должно быть либо строкой,
да. потому что в доке так и написано.
в задании тоже так написано — строка.
’1′ и 1 считаются идентичными при проверке array_key_exists
не знал что при И проверке ключей пых приводит типы. проверю.
но, не знал.....
в то время как конструкцию array_key_exist(key, $flippedArray) надо еще парсить мозгом, выискивая
принимается.
в случае когда программист не в курсе эффективности «hashtable» — будет доооолго думать.

в одном из вариантов выполнения тестового задания была конструкция
if ($obj->field == «firstValue» || ...)
и так шесть строк.
в код ревью я написал что лучше в масив, и array_key_exist использовать.
чел переделал, и — в in_array
мне стало интересно, почему он «ослушался», и я задал всего один вопрос:
«Почему?»

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

ну, я не спорю насчет эффективности.
с учетом, что 1 тыщ элементов — отличное решение.
сам в JS использую хеши, если поиск часто или по большим структурам проводится.
я только хотел вставить, что по дефолту такой подход использовать не получится(хотя бы из-за ограничения на входящие данные — только массив строк и чисел — даже вне фишки с приведением типов — вполне валидный кейс когда еще встречаются null, например, вперемешку с числами).
а в результате оно не будет «настолько же читабельно» — бо не привычно.

ну, я не спорю насчет эффективности.
та с ней всегда беда, в плане объективности.

недавно с другом обсуждали
вот вышел MySQL 5.7 в changelog ж написано почти по русски ...
и? сколько лет еще будут перепощивать статьи и тесты которые показывают
низя использовать подзапросы если вы хоть как-то задумываетесь о быстродействии!

я по джаве помню, только года три, четыре тому исчезли вумные статьи о том в JVM
«зеленые треды». млин, они исчезли в Java 1.3. но — «аргумент!»

сам в JS использую хеши
та я тут как-то нарвался на нюанс, который нутром чуял.
нюанс — транслятор CoffeeScript дурень, он генерит js код, в «некоторых» случаях, не зная что массивы в js — это синтаксический сахар. и индекс и проперти обрабатываются — одинаково.
ну правильно ж, они ж не писали свой парсер лексем. а взяли стандартный, отлаженный годами на других ЯП, в которых индекс массива и пропертя объекта — разные вещи
а в результате оно не будет «настолько же читабельно» — бо не привычно.
даже из обсуждения в этой теме, из советов, я окончательно понял, что
есть два «совершенно» разных PHP
PHP 5.4-
PHP 5.4+
(PHP 5.4+ + PHP 7 — это вообще тема)

и что, ты сам то(то есть я) определись-
ты по какому пыху вопросы спрашиваешь?

array_key_exists 0.11 сек vs 268 сек array_search vs 311 сек у in_array
array_intersect 0.01 сек в этом кейсе

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

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

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

но тут тоже есть сложность — когда человек рассказывает что он делал несколько в проекте который был лисапедом к какому-то давно умершему фреймворку стандарта php 4, — остается только кивать головой, потому что ничего не понятно :)

А вы уверены что вам нужен легаси програмист на php4 и что его стоит слушать?)

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

Ага, именно оно

да я уже понял, что это мое джавовское прошлое виновато.
в Джаве такие вопросы — норма жизни.
подразумевать какую-то из Мап (и не уточнять, какую именно реализацию), и спрашивать про «массив»? нихрена себе у вас нормы!
Впрочем, выше вы уже говорили, что для «Хеллоу ворлда» фабрики любите делать... я вам намекну, array[0] вернет именно то, что нужно, если речь о массиве. а если о мапах — то получать значение по индексу ключа... это у вас своя реализация, с индексами? и это должен угадать собеседуемый?
я вам намекну, array[0] вернет именно то, что нужно, если речь о массиве
дело в том, что в PHP с точки зрения синтаксиса нет разницы между массивом и мапой.
ни в инициализации, ни в вытягивании элемента, ни в применении.
это достаточно удобно. обычно. но бывают и неожиданности.

спасибо, буду знать. у меня как-то с пыхом не срослось... но в данном случае я аппелировал именно к съезду ТСа на джаву, но ведь в ней «массив» и «ассоциативный массив» — две большие разницы.

хм.
то есть, вы интерпретируете

По тому что соискатель расскажет о системной библиотеке коллекций, можно довольно точно узнать — стоит ли с ним дальше общаться на тему — а что он делал.
как «для джавы я бы тоже спрашивал о том, как получить первый элемент массива, хотя это на самом деле была бы мапа»?
а то выглядит, будто вы просто придираетесь :)

смотрю, под вашим ответом мое имя, но по содержанию выходит, что это ответ ТСу.

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

но в данном случае я аппелировал именно к съезду ТСа на джаву
и не могу поверить, что вы всерьез подумали, будто ТС в контексте Джавы хочет провернуть то же — получить первый элемент мапы, считая массивом.
мне очевидно, что он имел в виду «в джава я бы тоже спрашивал о ньюансах использования встроенных структур данных, чтоб выяснить уровень понимания».
потому и предположил, что вы просто придираетесь.
и не могу поверить, что вы всерьез подумали, будто ТС в контексте Джавы хочет провернуть то же — получить первый элемент мапы, считая массивом.
напрасно не верите :)

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

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

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

напрасно не верите :)
то есть ТС именно так и хотел:
в контексте Джавы хочет получить первый элемент мапы, считая массивом.

Если бы он хотел спросить «о нюансах использования встроенных структур данных, чтоб выяснить уровень понимания», то мог бы начать, например, с вопроса, можно ли засунуть в мапу пару, в которой ключ == null и посмотреть, что ему расскажет претендент...
а у него «красный» ассоциируется сразу с «мячик», «красный» без мячика он себе не представляет, да и Бог с ним. хуже, что он полагает и ожидает, что это у всех так. в данной теме он проявляет удивительную косность мышления, не желая признавать даже возможность наличия альтернативных мнений на кодинг.
ЗЫ. видел мастера, который 20 лет автоэлектрикой занимается и этим кичится. когда после него до нормального электрика доехал, тот так матерился, что мне хотелось записывать для истории! но за пару часов переделал все как надо.

в данной теме он проявляет удивительную косность мышления, не желая признавать даже возможность наличия альтернативных мнений на кодинг.
ваша старательность в прочтении обсуждения поражает!
видел мастера, который 20 лет автоэлектрикой занимается и этим кичится
да, и с тех пор ко всем непонятым вы лепите звание такого мастера.
дельный подход! :D
то он полагает и ожидает, что это у всех так.
телепатия, да. главный арумент.
телепату всегда лучше знать, что полагает и ожидает телепатируемый.
особенно после многократного пояснения и старательного прочтения этим телепатом разъяснений — что же полагал и ждал телепатируемый.

все так господин Телепат, все так.

дело в том, что в PHP с точки зрения синтаксиса нет разницы между массивом и мапой.
но меня в этой теме некоторые опытные программисты на PHP доказывают что есть!
это достаточно удобно. обычно. но бывают и неожиданности.
да.
когда я потом глянул на SPL в PHP — то не нашел вменяемого ответа — а зачем она?
если для написания серьезных фреймворков — то там наверняка разработчики напишут свой вариант.
для малых приложений — она избыточна, в сравнении с array

единственное что пришло на ум — для использования тайпхинтинга, и улучшения работы автокомплита в IDE.
сложно добиться читабельного представления развесистых вложенных структур с помощью array
а если добавить использование $$key в качестве ключей — ото ребусы будут! :)

если для написания серьезных фреймворков — то там наверняка разработчики напишут свой вариант.
зачем? ведь хороший стабильный кусок. ну, не Boost, положим, но все равно.
кучу всего реализовали.
зачем? ведь хороший стабильный кусок.
да, я совсем поверхностно его смотрел. просто после JRE показался каким-то маленьким и несерьезным.
но все равно. кучу всего реализовали.
учту на будущее.
пройдусь глубже. хотя бы до уровня — «уверенно отвечать на собеседованиях на вопросы по SPL»
(и не уточнять, какую именно реализацию)
в PHP одна реализация — array.
На самом деле массив в PHP — это упорядоченное отображение, которое устанавливает соответствие между значением и ключом. Этот тип оптимизирован в нескольких направлениях, поэтому вы можете использовать его как собственно массив, список (вектор), хэш-таблицу (являющуюся реализацией карты), словарь, коллекцию, стек, очередь и, возможно, что-то еще.
php.net/.../language.types.array.php
Впрочем, выше вы уже говорили, что для «Хеллоу ворлда» фабрики любите делать...
ну вы да, делайте их всегда. чтобы больше никогда не думать. компанию себе найдете, где иерархии классов плодят по всякому поводу.
я предпочитаю команды где понимают минусы и недостатки и фабрик, применения паттернов и просто бенефиты дизайнов:
object is ... vs object has
я вам намекну, array[0] вернет именно то, что нужно, если речь о массиве.
речь шла о типе данных PHP который называется — array.
а если о мапах — то получать значение по индексу ключа...
я вам открою великую тайну
чтобы получить нечто по ключу — нужно знать этот ключ.
и что между «получить по ключу» и «получить первое значение» — есть крохотная разница.
и это должен угадать собеседуемый?
в стопицотый раз отвечу
я предполагал что люди читают основополагающую документацию. в частности о типе данных — array

так объясните, пожалуйста, бестолковому, смысл фразы «первый элемент хэшмапы»? в джава-контексте.

в РНР, как ни странно, порядок тоже сохраняется.
вот такой вот гибридный массив-мапа.

в РНР, как ни странно, порядок тоже сохраняется.
мегапупер тру оопшному джависту Aleksandr Shchur виднее, что есть array в PHP :D

говорю, ж — намальна все. меньше знаешь, быстрее телепатируешь.

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

да-да.
когда тебе уже прозрачно намекнули, что твои вопросы по пыху — говно, то что ты ответил?

да я уже понял, что это мое джавовское прошлое виновато.
в Джаве такие вопросы — норма жизни.
когда спросили
подразумевать какую-то из Мап (и не уточнять, какую именно реализацию), и спрашивать про «массив»? нихрена себе у вас нормы!
так объясните, пожалуйста, бестолковому, смысл фразы «первый элемент хэшмапы»? в джава-контексте.
то уже опять «мы говорим про PHP»
знаешь, если от всех вокруг воняет говном, то посмотри — может это ты обосрался...
когда тебе уже прозрачно намекнули, что твои вопросы по пыху — говно, то что ты ответил?
мне что, копипастить ответы? разные — разным отвечающим?

и какое отношение ты имеешь к тем ответам?

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

но говорил не раз и тебе повторю:
именно говно мнит себя — всеми.
и именно говно считает себя — всем доу.

так объясните, пожалуйста, бестолковому, смысл фразы «первый элемент хэшмапы»? в джава-контексте.
объяснение и примеры джава кода, и пояснения к нему есть в теме о «вопросах С++»

не милок, все проще.

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

ты кто такое что я тебе должен копипастить свои ответы из той темы?
ты хотя бы чем-то заслужил мою симпатию? уважение? ты сразу стал — блевать на мои посты, и после такой тактики ты что ждешь?

так что — телепат и мегапупер джавист — мои разъяснения тебе все равно не нужны.
ты уже всего достиг и все постиг.

А как Вы, уважаемые профессионалы , заполняли пробелы в портфолео на первых парах. Поделитесь экспертным мнением.

Какие по вашему мнению вопросы по работе с массивами показывали бы степень опытности программиста, и не были бы придирками, а основаны на типичном применении массивов в PHP.
Степень опытности вопросы по массивами да и вообще API php и фреймворков мало что покажет. Если человек вместо array_column/filter/reduce/etc использует аналог на foreach — от этого в принципе никто не умрет. А вот взять реальные кейсы с проекта, которые Вы решали и предложить человеку найти и описать решение — тут уже можно узнать об опыте и в правильную ли сторону человек думает

Можно еще спросить какие книги читали и знакомы ли с такими именами как Мартин Фаулер, «Дядюшка Боб», Кент Бек

Как получить первый элемент массива?
1)reset($arr);
2)isset($arr[0]) ? $arr[0] : null;
3)array_values($arr)[0]
4)foreach($arr as $key => $value) { $firstValue = $value; break; }
Вариации с list, array_shift и прочие. В основном используют 2й вариант
В тестовом задании встретил применение array_push($a, ’foo’) хотя по коду прекрасно подошел бы $a[] = ’foo’
Это пример — правильной привычки, безопасного программирования? так принято в мире PHP?
В принципе вопрос из разряда array(1,2,3) vs [1,2,3]. В «мире PHP» array_push используют только если нужно больше 1 элемента добавить. Возможно человек занимается параллельно еще другими языками где используются такие конструкции, Golang и тому подобные, либо загнался просто :)
Задача — выбрать из массива объектов такие, у которых поле равно одной из пяти строк.
Человек пишет код, в котором помещает эти строки в массив, и для каждого объекта вызывает in_array с значением поля.
Я зря пристебался что array_flip а затем array_key_exists для каждого объекта — будет более правильным ответом, ввиду более высокой скорости работы?
array_intersect в помощь. array_flip оставит только уникальные значения
array_intersect в помощь. array_flip оставит только уникальные значения
читаем условие задачи:
выбрать из массива объектов такие, у которых поле равно одной из пяти строк.
нам в задаче важны неуникальные значения, как по вашему?

в той теме, по С++, мне и сейчас рассказывают о задаче которую я не ставил.
придумывают какие-то дополнительные условия себе.

нам в задаче важны неуникальные значения, как по вашему?
тогда array_intersect хватит с головой
выбрать из массива объектов такие, у которых поле равно одной из пяти строк.
да вот перечитал, обьекты с полями же. Тогда array_filter(function($object) use ($allowedValues) { return in_array($object->getMyField(), $allowedValues) ; }, $arr) и получаем обратно массив обьектов :)
array_filter(function($object) use ($allowedValues) { return in_array($object->getMyField(), $allowedValues) ; }, $arr)
почему не:
return array_key_exist($object->getMyField(), $allowedValues) ;

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

не знаю, может джавовский опыт. но дампы бывают и на гигабайты, и даже если это XMLина, на автомате уже все равно используешь stream XML либы... джава медленная. PHP наверное просто намного шустрее.

(сарказм ессно :)

почему не:
return array_key_exist($object->getMyField(), $allowedValues) ;
Я б не передавал $allowedValues как hashmap, string[] как-то практичнее. а вообще isset($allowedValues[$object->getMyField()]) будет быстрее по сравнению с array_key_exists
в том тех задании объекты формировались из текстового дампа на сотни мегабайт.
если человек всегда работал только в рамках веба, а по другую сторону отправлял только эмейлы по крону — то нет смысла ожидать что будут рассказывать про потоковую обработку, буферизацию, как делать всю обработку параллельно на кластере и тд

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

Я б не передавал $allowedValues как hashmap, string[] как-то практичнее
а чем в PHP string[] отличается от hashmap? я думал что это одно и тоже.

и почему не стоит передавать массивы в конструкции

use ($allowedValues)
isset($allowedValues[$object->getMyField()]) будет быстрее по сравнению с array_key_exists
пожалуй что да :) все забываю что в пыхе много операторов которые имеют синтаксис функций.
а чем в PHP string[] отличается от hashmap? я думал что это одно и тоже.
и почему не стоит передавать массивы в конструкции
$map = [’a’ => 1, ’b’ => 1, ’c’ => 1];
ну либо $map = array_flip([’a’,’b’,’c’]);
$plainArray = [’a’,’b’,’c’] // string[]

array_key_exists будет проверять в ключах, т.е подойдет только содержимое $map
in_array проверит значениям — $plainArray

очевиднее и чище же передать в $allowedValues только значения, чем делать array_flip + array_key_exists/isset из-за незначительного увеличения скорости.. это попахивает преждевременной оптимизацией и экономией на спичках. Хотя если массив по которому нужно идти большой(100к+) — тогда есть смысл

$map = [’a’ => 1, ’b’ => 1, ’c’ => 1];
я к тому спросил что в PHP нет отдельного типа hashmap.
а есть тип array, который можно использовать и как массив, и как map, и как очередь
это попахивает преждевременной оптимизацией и экономией на спичках.
мой сарказм про тормознутость джавы в сравнении с php был и вызван тем что у нас, в джава мире, в случае одинаковой читабельности кода нужно выбирать более эффективное по выполнению решение.
недавний пример — коллега в 4ре строчки написал обработку коллекции, приходящей с фронтенда на лямбдах. код ревьювер забраковал, потому что там каждый ключ обрабатывался дважды.
коллекции с фронтенда, в данном случае приходят смешные по размеру, пара сотен элементов максимум.

но в джава мире так принято :)

Хотя если массив по которому нужно идти большой(100к+) — тогда есть смысл
ИМХО, философско-программерское — правильные привычки написания кода экономят массу времени.

а насчет «преждевременной оптимизации» то мое многолетнее — лучше уменьши число запросов к БД, чем вылизывай код.

просто, как-то уж совсем все подряд стали записывать в «преждевременную оптимизацию» ...

опять же, как понял, в PHP в мире проблемы решаются кешированием. Как кто-то на хабре написал — у нашего эл-магазина при размере базы в гиг — уже 8 гиг кеша из html фрагментов. и ничё, летает же!

другой язык, другое мышление, другие подходы....

я к тому спросил что в PHP нет отдельного типа hashmap.
а есть тип array, который можно использовать и как массив, и как map, и как очередь
ну уж простите что нет отдельных классов для map, set, генериков.. array + phpdoc в принципе отлично справляются. при сериализации в BSON/JSON если ключи идут не по порядку — будет попа-боль и сразу появится map. для очередей и стеков есть отдельные оптимизированные spl классы, не на столько гибкие как в java, но все же
опять же, как понял, в PHP в мире проблемы решаются кешированием. Как кто-то на хабре написал — у нашего эл-магазина при размере базы в гиг — уже 8 гиг кеша из html фрагментов. и ничё, летает же!
язык тут не при чем, я видел уйму гавна в .net и java проектах. если руки кривые то и результат такой же
язык тут не при чем, я видел уйму гавна в .net и java проектах. если руки кривые то и результат такой же
в том и проблема. если вопросы по .net и java отсеивающие криворуких известны, то вот по php оказалось нужно задавать какие-то другие вопросы.
вернее — только синьорам можно задавать такие вопросы как по .net и java

причем в сборниках типа «PHP в вопросах и ответах» www.kobzarev.com/...ads/books/php/PHPbook.pdf ложь и провокация! «PHP программист не обязан знать!» — будет ответ :)

ну уж простите что нет отдельных классов для map, set
а зачем они, если array в PHP справляется с основной частью задач?

никаких претензий к PHP, что он не Java у меня нет. он таков какой есть. как и любой другой. Python он такой какой есть. С++ такой какой он есть.

и, ИМХО, ООП часть у PHP 5.4+ богаче чем у Java. насобирали со всех ЯП.
как и callable позволяет легко писать код в стиле function is first-class citizen.

ООП часть у PHP 5.4+ богаче чем у Java
Ой, на сколько не согласен! Но нужно ещё уточнит версию Java. Functional interfaces справляется с
function is first-class citizen
на ура, далее чего дико не хватает в PHP — внутренние классы (приходится юзать @internal), final параметры, да много чего. Уже не говоря о том что тот же array — примитив и как следствие не Traversable

Да, конечно мой тезис дискуссионный.

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

Я и сейчас, после выхода 8ой джавы слышу ещё голоса что зачем эти лямбды, хватало ж анонимных классов.
И другие голоса — так все таки, когда наконец сделают перегрузку операторов?

коллега в 4ре строчки написал обработку коллекции, приходящей с фронтенда на лямбдах. код ревьювер забраковал, потому что там каждый ключ обрабатывался дважды
Конечно не видякода судить сложно, но только из того что вы написали видно что или коллега или ревьюер понятия не имеет о том, как работают стримы и о чём они. Да, именно стримы, а не лямбды. Их суть в том, что вся их обработка цепочки вызовов любой длинны пока возвращается стрим она lazy, а ваш коллега явно использовал редьюс, коллекторы, гет или что-то в этом роде что впринципе не логично. Например если использовать коллектор то далее в коде явно будет ещё один проход по полученой коллекции — возрастает сложность решения. Вернув стрим, а ещё лучше получив его на вход и вернув можно просто присоединить свою обработку получив O(n) в худшем случае. Есть объяснение по этому поводу и насчёт
случае одинаковой читабельности кода
Тот же спикер по-моему в «The art of simplicity» говорил на сколько важно различать «привычно» от «ясно» и «читаемо». Обработка коллекции, основаная на стримах в большинстве случаев гораздо более читаемая, чем при использовании декларативного подхода

После этого случая я поделился ссылкой на доклад через тернии к лямбдам
Чтобы поняли нюансы реализации

Задача — выбрать из массива объектов такие, у которых поле равно одной из пяти строк.
Человек пишет код, в котором помещает эти строки в массив, и для каждого объекта вызывает in_array с значением поля.
Я зря пристебался что array_flip а затем array_key_exists для каждого объекта — будет более правильным ответом, ввиду более высокой скорости работы?

Да в суровом украинском аутсорсе не модно знать чем O(n) от O(n*n) отличается. Так что все нормально

Если хочется поговорить, то OOP и паттерны (SOLID).
Часто просто даю распечатку вопросов, и мы обсуждаем, что выведется и почему..
$something = strval(TRUE-TRUE); echo empty($something);
output? __________

var_dump('0' != 0);
output? __________

$a = '11'; $b = 'a'; $c = 2; echo ($a < $b) . " " . ($b < $c) . " " . ($c < $a);
output? __________

function trick() { static $var = 1; echo $var++; unset($var); } array (trick(), trick());
output? __________

$j=30; $k=0; $k=$j++/++$i; $output = $i . " " . $j . " " . $k . " ";
output? __________
...

Это вопросы на позицию Trainee?

Код выше для джуно-мидлов. Для «синьоров» больше общаемся по паттернам и антипаттернам и примеры кода более каверзные, типа
$a = 0.1+0.7;
echo floor($a*10);
output? __________

Или такое вот, (обратите внимание на округление глаз «синиора»):
$some_array = array (0 => 1, ’x’ => 1, 2 => 1, ’a’ => 1, 1 => 1, ’z’ => 1);
ksort($some_array);
echo(join("", array_keys($some_array)));
output? __________

Я бы встал и вышел, получив такой вопрос на собеседовании.

+ Меня бы тоже возмутило, если бы такое задали мне), но попробовал бы проверить свои знания (и заодно проверить сообеседующего) Вообще этот вопрос специально для тех «звёзда-дартаньянов» которые заявляют что они «твой пыхапэ круче Расмуса знают» и вообще, «для вас это большая честь, что я спустислся на собеседование в ваше стойло»

в чем же загадка таинственной кривой сортировки по ключу, поделитесь?

Тут важен совсем не ответ кандидата, а его реакция. Посмотреть, как ведёт себя человек в стрессовых ситуациях, в частности, когда не понимает как будет работать код (а это с каждым может случиться). Кто-то «встала и ушла», кто-то просто «завис» и затем честно и спокойно сказал «не уверен, не знаю как сортировка будет работать по смешанным ключам», а кто-то даже слышал про аргумент $sort_flags который по-умолчанию SORT_REGULAR и может объяснить, что такая сортировка поставит 1 после a, но 0 перед x (хотя такие кандидаты не попадались, да как я уже сказал, это и не ожидается). С сеньорами это большая проблема, каждый считает что если он в бодишопчике 5 лет «отсидел», то он уже мега-стар и все ему должны. В скандинавских странах, где холивары и разборки на работе не приемлимы (такой тут менталитет неконфликтный) на первый план выходят софт-скиллы (насколько приятно с человеком работать), а уже за этим следуют его проф знания.

что такая сортировка поставит 1 после a, но 0 перед x
 Зачем засорять бошку такими «знаниями» ?
С сеньорами это большая проблема
То есть это «стресс-тест» ? Чел типа убежит или нет ? :)

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

каждый считает что если он в бодишопчике 5 лет «отсидел», то он уже мега-стар и все ему должны
И это говорит тот, кто 15 лет пилит что-то на друпале.

Мне в 2010м подобные вопросы задавали на одну Delphi вакансию перед тем как я решил окончательно забросить Delphi. Целей у таких вопросов могут быть три — одна, озвученная выше (типа поведение в стрессовых ситуациях ага) и две менее явных. Одна это придать ощущение, что собеседующий якобы много превосходит собеседуемого по скилам, раз знает детали работы даже такой хрени. Собеседуемый по задумке должен смирится с таким положением вещей. А если не смирится, то "

с такими людьми тяжелей на проекте, ибо они и атмосферу портят
«. Между строк, если вы например тимлид, и собеседуете специалиста, который круче вас, то, в случае приема, кто может занять ваше тимлидское кресло? Вот-вот. И вторая это конечно же показать, что «на миддла/синьера ты не тянешь и потому мы можем предложить тебе только сумму меньшую чем ты просишь».
Одна это придать ощущение, что собеседующий якобы много превосходит собеседуемого по скилам
не знаю, когда проходил собеседования, а уж с середины 90ых — не скажу сколько — не замечал такого как нормы.
понятно, что у собеседующего всегда пятый и козырный туз в рукаве найдется, как я это называю
«собеседование нельзя сдать на отлично, как экзамен. тебя все равно завалят.
но вот от того на каком уровне тебя завалят, и будет зависеть — будет тебе офер или нет, и если будет, то на какую должность и зп.»
в нынешнюю компанию, на должность pure Java программиста меня в конце концов завалили на тонкостях JavaScript

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

да, через пару недель будет 3 года как я работаю в этой компании.
пока — никак не пожалел.

Между строк, если вы например тимлид, и собеседуете специалиста, который круче вас, то, в случае приема, кто может занять ваше тимлидское кресло?
тоже как-то везло, страшащиеся соискателя тимлиды... хм...

тимлиды они ж не менеджеры. они как правило по уровню компетенции пост занимают. и если их кто подсиживать начнет, подло, — что, вакансий мало на серьезные позиции с серьезными зарплатами?

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

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

то либо он такой «везучий» по жизни

либо это как раз у него болезненной спеси выше крыши, и ему поэтому во всех эпизодах мерещится желание его унизить, оскорбить, с одновременным — «вона как засцали то меня! вона как перепугались что через месяц они у меня в подчиненных будут! вот и не взяли потому»

Если вы о мне, то я на таких собеседователей натыкался всего пару раз, а на собеседованиях был около полтора десятка раз. Причем реагировал я на такое, естественно спокойно, только в уме делая заметку: «тим лид тут похоже не уверен в себе или фирма, возможно, сильно экономит на кадрах». В те же места куда я устраивался и где работал долго (2-4 года) у меня вообще на собеседованиях ничего такого не спрашивали. На первом месте работы спустя полтора года я и сам как-то пару раз проводил собеседования — я считаю достаточным посмотреть уже существующий код собеседуемого (желательно пет-проект) и поспрашивать по разным местам о том как и почему были выбраны такие решения. Считаю что таким образом сразу все или почти все становится понятно относительно его навыков как программиста. Можно еще дать тестовое задание, чтобы оценить зависимость качества кода от времени. Можно попробовать подискутировать затронув спорную тему. Большинство коммуникационных качеств можно определить при помощи простого общения и прямых вопросов. Любые стресс тесты считаю категорически неприемлемыми. И в частности те, в которых собеседующий задает такие вопросы, на которые он сам узнал ответ пол часа назад — то есть вопросы, знание ответа на которые никак не говорит о способности собеседуемого решать практические задачи.

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

у самого тоже, никакого пет-проекта нет. времени нет просто.

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

я к тому что — стоит ли показывать такой код?

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

Интересно, кривая FP арифметика на PHP это у вас паттерн или антипаттерн o.O

я даже выполнил ваш последний пример.
в старых PHP результат оказался для меня неадекватным, в новом хоть на что-то похоже

но, каким надо быть умным человеком чтобы с одним массивом работать и как с ассоциативным и обычным?

Это у вас в проектах так пишут? Спасибо, не надо.

function trick() { static $var = 1; echo $var++; unset($var); } array (trick(), trick());
Еще б с global пример привели. Вы такие конструкции используете в коде?

Что плохого в статическом кешировании? Кстати, засчитывается за плюс, если кандидат правильно отвечает, но говорит что такой код не приемлим для реального проекта. И два плюса, если кандидат не плюётся на примеры кода, а спокойно и правильно отвечает, замечая, что люди есть разного уровня, а плохой код и слабая архитектура — частые последствия быстрого выхода MVP на рынок и сложностей найма персонала.

Что плохого в статическом кешировании?
на сегодняшний день все ООП используют, и static никому не нужен, для этого есть приватные свойства объекта

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

даже клипер где-то наверное используется. но народ такого может просто не знать, ибо в основном это устаревший код. где-то 3 года с 2011 я был частично PHP разработчиком, и не встречал процедурного кода который надо оптимизировать, то что писалось это были всякие скрипты миграции.

не, я знаю что всякие вордпрессы вроде как в таком стиле написаны, но вордпресс это не для PHP разработчиков, а для веб-мастеров

static было раньше полезным инструментом, имеется ввиду когда работаешь без ООП, но... это давно было

Блин, я ни на один из этих вопросов не отвечу (включая ООП в вашем понимании и паттерны проектирования). Пойду переквалифицируюсь в дворники.

это все вопросы из разряда «смотрите какой я умный, а собеседуемый дегенерат», так что не расстраивайтесь :)

empty(’0′) === true может встретиться в редких случаях и доставить неудобств, тут да
’0′ != 0, в принципе очевидно, но сравнивать разные типы и опираться на свои знания того как это сделает движок — изврат
echo (’11′ < ’a’) - пригодится только при сортировке по хешу
pre инкременты.. для пхп это экзотика и кейсы очень редкие. а в примере там вообще будет ошибка undefined variable $i

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

дегенерат

А вот понять суровый легаси код, который писался до появления стандартов и ревью какими-то инду инопланетянами — такое вот быстро понять и переписать может только действительно
умный

Рад, что вы увидели, куда расти =)

А смысл? Это покажет в основном только то, готовился ли человек заранее к таким вопросам. Перед первым интерью думаю многие готовятся, а потом...
За 5+ лет работы с PHP видел очень много кода, в том числе говнокода еще на PHP4, написанного в начале 2000х, но ничего подобного даже там не было. Сейсас точно не на все вопросы отвечу.
Понятно, что с одной стороны как бы проверяет знания особенности работы с типами с другой стороны общую сообразительность, но общая практическая ценность мне кажетс сомнительна.
Какие у вас результаты, поделитесь, если можно: какой процент правильно отвечает на все вопросы, как коррелирует со знанием ООП и паттернов или с какими-то другими вопросами?

Вопросы нужно писать свои, которые отражают частые проблемы на вашем проекте. Помогает увидеть, разбирается ли человек в _основных_ моментах. И да, как уже заметили, также позволяет понять, насколько логически грамотно рассуждает человек.
Про SOLID и паттерны с джунами поговорить не получается.
Вобщем корелляция знаний/самооценки в мире PHP неплохо отражены на диаграмме raw.githubusercontent.com/...e_learning_curves/php.png

Вобщем корелляция знаний/самооценки в мире PHP неплохо отражены на диаграмме raw.githubusercontent.com/...e_learning_curves/php.png
Ну это вы совсем жестко. Про корелляцию знаний/самооценки между собой в принципе можно согласиться, но что от экспериенса const и там и там — это уже какой-то совсем запущенный случай.

Зачем это? Нет смысла в таких вопросах

задавайте вопросы на основе того с чем человеку работать.
ООП — полностью, это то с чем современные PHP программисты работают в рамках фреймворков
спрашивайте работу с памятью (передача по ссылке / по значению, особенно то как передается массив)
спрашивайте понимание MVC в рамках бекенд разработки
спрашивайте паттерны
проектирование REST — простые задачки

но самое главное спрашивайте то, с чем им придется работать в рамках вашего проекта

спрашивайте понимание MVC в рамках бекенд разработки
И развяжите холивар на тему применимости MVC в рамках бекенда :)

та чего, я пару спросил.

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

ну примерно как
ты ему про Бога предлагаешь поговорить
а он все на бухающего батюшку сводит.

ТС, простите конечно, но я считаю, что Вы — некомпетентны, чтобы оценивать знания PHP-программистов, если знаете язык поверхностно.
Получить первый элемент массива? Серьезно? Это так важно для (бугага) низкоуровневой оптимизации в PHP?
Спросите про миграции, юниттесты, виды таблиц в MySQL том же, какие средства предоставляет язык/фреймворк для доступа к БД.

З.Ы. сам пишу на питоне; и без обид, вышеизложенное — имхо

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

И да, про магические методы и что оно такое тип Callable — перестал спрашивать.
как и про паттерны ООП :)

Это так важно для (бугага) низкоуровневой оптимизации в PHP?
понятия не имею. я спустился к такому уровню потому что вообще стало не понятно про что спрашивать.
Спросите про миграции, юниттесты, виды таблиц в MySQL
спрашивал. ответ — не знаю, не использовал, а MySQL настраивает сам ОRM фреймворка, CMS, ..., «сосед», «хостер», — мне было достаточно.
Или вы думаете мне сложно спросить про использование Doctrine или Eloquent, после лет с Hibernate?
А ответ — какой будет?

Вот на доу, и думаю еще в паре мест поспрашиваю, про что вообще спрашивать PHP программистов. про ЯП — низя. Про ООП в PHP — низя. Про БД — а оно и так работает.
про PHPUnit -а он массово используется в мире PHP? мне показалось что только в очень крупных проектах.

а про что тогда спрашивать?
и вообще — а кто тогда все эти Symfony2 и Yii пишет и главное — для кого???

например на собеседованиях по Java ого го как обязательно пройтись и по спеке Java, и по библиотеке JRE, а дальше и по паттернам, а дальше по Спрингу православному. и да, по инфраструктуре, и сборочной и тестирования.

а на PHP как понял, так не принято.
а как принято?

Спросите про миграции, юниттесты, виды таблиц в MySQL том же, какие средства предоставляет язык/фреймворк для доступа к БД.
У нас на проекте yii/yii2, и это базовый список вопросов, после которых становится понятно: спрашивать дальше или нет.
Если кандидат (мидло-синьор) не представляет как работать с гитом, миграциями и не знает чем исам таблицы отличаются от инно — нам такой не нужен. Ну или не за те деньги, на которые он заявляет.
Если кандидат (мидло-синьор) не представляет как работать с гитом, миграциями и не знает чем исам таблицы отличаются от инно
кандидат юзает mercurial/svn, работал на хайлоад проекте где миграции запрещены и выполняются в полумануальном режиме и вместо мускуля использовал только постгре или nosql вариации и уже не помнит различия исам от инно :)

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

Тобто, такі кандидати просять «від $2800»? Якщо так, то треба показати ваш пост директору, може, зарплату підвищить.

И да, про магические методы и что оно такое тип Callable — перестал спрашивать.
как и про паттерны ООП :)
Зря. Не понимать/не знать этого как по мне — плохо.
ООП в PHP — низя
Разве? Не знал.
Про БД — а оно и так работает.
Ага, а потом находим запросы в цикле и ошибки маппинга, или попытку транзакций на движке, что их не поддерживает...
кто тогда все эти Symfony2
Себастиан сотоварищи — ваш К.О.
для кого
для того, кто знает что знание как работать с этими инструментами стоит дорого. Для того, кто пишет проект что должен быть надёжнее обычной визитки.
Просто посмотрите на сколько ваши заказчики оценивают месяц работы — может тогда поймёте что вам, в вашем случае экономической целесообразности, единственный выход — нанять вчерашнего студента что сделает кое-как, неоптимально и потенциально подвержено ошибкам, а то, что вы хотите стоит дороже.
Ну, по крайней мере мне так показалось исходя из всего этого треда. Очередной раз убеждаюсь что самая большая проблема языка — это то, что ставится ему в достоинство. Низкий порог входа. Очень быстро можно начать давать какой-то результат, писать странички работающие кое-как. Таких людей будет очень много. И чем больше таких людей тем выше будут ценится те, кто знаю тгораздо больше, копают глубже, развиваются постоянно.
то усі б вони легко справились із цими завданнями маючи доступ до інтернету і документації.
у мене тому й питання
якщо справа у доступі до інтернету та документації — то чому є поділення на джунів-сеньорів? і як виявити того, хто зможе справитись с завдянням з доступом до інтернету, а хто — ні?
відмінно пам’ятати якісь конкретні пару-трійку функцій — не показник.
так. але ж при виконанні тестового завдяння доступ до інтернету був.
Щоб показати картину прогалин у знаннях, такі питання треба задавати сотнями.
наврядчи це можливо за півтори години.
та й навіщо, якщо — відмінно пам’ятати якісь конкретні пару-трійку функцій — не показник і вони легко справились із цими завданнями маючи доступ до інтернету і документації.

виходить що технічна співбесіда немає аніякого сенсу.
і тільки тестове завдання — більш менш виявить знання...

поддержу, пишу переменно на пхп и питоне, пуш и пулл иногда пользую в питоне, в пхп не помню что бы пользовал. Если гуглить и знать что гуглить то можна найти правильные функции но обычно пользуют то что знают. Посмотреть уровень сеньйорства можна попросив показать акаунт на кодилити или на кодевар, при этом можна обсудить пару строк кода. Там сразу видно кто пишет код профессионально а кто только пару лаб делал.

обычно пользуют то что знают.
да, похоже что так...

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

уровень сеньйорства
с синьорами, любыми, мне кажется проще.
Предлагаешь обсудить дизайн чего-нибудь. собственного кода, или какого-нить фреймворка что он использовал.
но у нас пока в отделе «типичной веб-разработки» синьорам интересного ничего нет и не предвидится. поэтому и не ищем такого уровня.
мы ж классические ынтырпрайзники, Java + Sencha JS причем в сторону продуктовости. потребность в веб-разработке возникла вначале как просто из внутренних, вспомогательных потребностей, а сейчас оказалось можно и на самоокупаемость выйти. а дальше и ...

кстати, я уровень вопросов подбирал учась у наших фронтендщиков. тоже беда с соискателями: «jQuery — знаю. JavaScript, не, не знаю. Слышал конечно. нагуглю если надо». Они таких не берут совсем.

Підписатись на коментарі