Хотя я и не представляю, как разработчик может не оттестировав свой код лить его на прод.
Если лить код на прод, не проверяя ничем, уже ничего не поможет. :) Даже при наличии статических анализаторов можно на них забить — это крайности.
Обычно всё-таки проблемы бывают в случаях, когда правка затрагивает кучу сценариев и все их сложно проверить, либо есть какой-то неочевидный сценарий, о котором забыли.
Значит в руби интерпретатор свалится с указанием проблемы, и вы сможете быстро ее пофиксить. А вот в пыхе это может привести к неправильному расчету в какой-то формуле, что уже реально проблематично.
Поведение PHP и Ruby будет разным — это правда, но это не меняет сути.
Ключевой момент в обоих случаях: проблемный код должен кто-то
исполнить (человек/тест/автоматика)
проверить результат (есть ли ошибка).
Если что-то из этого не произошло, то код с ошибкой будут исполнять пользователи на продакшене в обоих случаях.
а сколько разработчик не был бы опытным и даже гениальным, все равно произойдет ситуация, когда авто приведение типа будет ломать логику.
Наличие или отсутствие автоматического приведения ничего не меняет — логика всё равно сломается. Например, для упомянутого вами Ruby будет что-то вроде:
+': no implicit conversion of Integer into String (TypeError) from main.rb:1:in `<main>'
Если у вас нет статического анализа, вы эту проблему в обоих случаях можете найти только во время выполнения. В обоих случаях остаётся только надеяться на то, что это место покрыто тестами, или его проверят вручную и найдут фейл.
В связи с большим количеством участников, процесс затянулся, не успеваем всем дать ответ. Вынуждены взять ещё несколько дней.
Планируем закончить до середины следующей недели: 7-8 февраля.
Это было сделано намеренно: мы решили оставить "близкие" к PHP языки, чтобы была возможность для прохождения тем, кто программирует на чём-то другом, но готов перейти на PHP.
На каком-то этапе Perl выпал из поля зрения, сейчас уже сложно сказать почему.
После анонса уже не будем менять список языков, чтобы те, кто уже прошли, и те, кто только собирается, были в равных условиях.
На Perl проходить тест, к сожалению, нельзя.
В новом тесте на написание PHP-кода всего 2 задачи. Если вы пишете на PHP хотя бы на базовом уровне и имеете хороший опыт с Perl, то у вас есть все шансы. Каких-то сильно специфичных для PHP вещей мы не спрашиваем в тесте.
Не проблема!
Можно было, например, прислать такое решение без strrev(), rtrim() и intval(). Мы бы его оценили максимальным баллом.
Для нас всё именно так, как вы говорите: в первую очередь важно умение решать задачи, а не энциклопедические знания.
Работодатель зачастую действует просто. Задают к примеру вопрос, знаешь ли ты какой-то там интерфейс в какой-то библиотеке (которых зачастую сотни). Не знаешь — всё, ты нам не подходишь! Т.е. вопрос не ставится, сможешь ли ты решить задачу и сколько времени тебе потребуется. Всё ставится с ног на голову!
Если с вами так поступил работодатель — приходите к нам. :) У нас противоположные ценности: мы впервую очередь обращаем внимание на способность адекватно мыслить, а не на специфические теоретические знания.
Насколько я понял, когда регистрировался здесь, что тут площадка для освещения технических, технологических проблем.
Технический разбор технических задач — разве это не техническое?
но вот некоторые функции, я за 8 лет в пхп ни разу не видел
Можете привести функции, которые вас смутили?
Это только примеры решений — можно обойтись без конкретных функций, применённых в них, или заменить другими. В любом случае, список будет полезен: мы стараемся приводить наиболее понятные решения — ваш фидбек помог бы этому.
Не переживайте! Если кто-то написал 43 975 482 млн, он так же мог получить максимальный балл.
Само число для решения не играет никакой роли, как я писал выше: важно то, как будет объяснён порядок действий и необходимое время.
Зануда mode
Хоть это и не играет никакой роли, справедливости ради, изначально в задании подразумевались именно статьи(Content pages из вашей ссылки), которых сейчас 5.5 млн. Оригинальный текст из задания: "download English version of Wikipedia (only pages with articles)"
Так же, как и вариант с постраничным скачиванием страниц:
если алгоритм достаточно объяснён и даны обоснованные расчёты, то максимально
если в задаче просто написано "скачаю дамп", то это плохое объяснение
Под "достаточно объяснён" я подразумеваю, что, например, в случае с дампом отсюда https://dumps.wikimedia.org/enwiki/latest/ ещё требуется пояснение, как из XML-файла с разметкой в Wiki-формате будут воссозданы исходные страницы в HTML-разметке, какие мы видим на сайте Википедии.
Но проще было бы просто спросить работал ли человек с большими числами.
Это не совсем то, что мы хотим проверить. Для нас работал ли человек с большими числами или нет — не так важно. Важно, сможет ли он сориентироваться, если работать придётся.
Во 2, ну ок… Надеюсь, никогда такого писать не придется в реальной работе.
Зависит от конкретной области.
Например, некоторые могут не знать о существовании pcntl_fork() в PHP и успешно решать большие крутые задачи, некоторым fork может быть жизненно необходим в повседневной работе.
До проведения мероприятия мы точно не будем выкладывать задачи.
После него возможно мы сделаем какой-то отчёт и возможно включим что-то про задачи. Но на данный момент это не решено.
Пока что могу сказать, что некоторые задачи были взяты из публичного пула HackerRank, поэтому вы можете попробовать порешать что-то оттуда.
Детали выдавать заранее только здесь было бы нечестно, т. к. увидят их не все => кандидаты будут не в равных условиях.
Представьте, что вы идёте на обычное интервью, и готовьтесь исходя из этого.
Если лить код на прод, не проверяя ничем, уже ничего не поможет. :) Даже при наличии статических анализаторов можно на них забить — это крайности.
Обычно всё-таки проблемы бывают в случаях, когда правка затрагивает кучу сценариев и все их сложно проверить, либо есть какой-то неочевидный сценарий, о котором забыли.
Поведение PHP и Ruby будет разным — это правда, но это не меняет сути.
Ключевой момент в обоих случаях: проблемный код должен кто-то
Если что-то из этого не произошло, то код с ошибкой будут исполнять пользователи на продакшене в обоих случаях.
Наличие или отсутствие автоматического приведения ничего не меняет — логика всё равно сломается. Например, для упомянутого вами Ruby будет что-то вроде:
+': no implicit conversion of Integer into String (TypeError) from main.rb:1:in `<main>'
Если у вас нет статического анализа, вы эту проблему в обоих случаях можете найти только во время выполнения. В обоих случаях остаётся только надеяться на то, что это место покрыто тестами, или его проверят вручную и найдут фейл.
Но не надо отчаиваться, для Ruby тоже есть тулзы для статического анализа https://github.com/mre/awesome-static-analysis#ruby
Пришлите, пожалуйста, в личку E-Mail, с которым вы проходили тест, проверим.
В связи с большим количеством участников, процесс затянулся, не успеваем всем дать ответ. Вынуждены взять ещё несколько дней.
Планируем закончить до середины следующей недели: 7-8 февраля.
Пока нет, но возможно мы передумаем в будущем.
Можно, например, просто порешать задания с hackerrank — у нас часть была из стандартного пула.
Это было сделано намеренно: мы решили оставить "близкие" к PHP языки, чтобы была возможность для прохождения тем, кто программирует на чём-то другом, но готов перейти на PHP.
На каком-то этапе Perl выпал из поля зрения, сейчас уже сложно сказать почему.
После анонса уже не будем менять список языков, чтобы те, кто уже прошли, и те, кто только собирается, были в равных условиях.
На Perl проходить тест, к сожалению, нельзя.
В новом тесте на написание PHP-кода всего 2 задачи. Если вы пишете на PHP хотя бы на базовом уровне и имеете хороший опыт с Perl, то у вас есть все шансы. Каких-то сильно специфичных для PHP вещей мы не спрашиваем в тесте.
Не проблема!
Можно было, например, прислать такое решение без strrev(), rtrim() и intval(). Мы бы его оценили максимальным баллом.
Для нас всё именно так, как вы говорите: в первую очередь важно умение решать задачи, а не энциклопедические знания.
Если с вами так поступил работодатель — приходите к нам. :) У нас противоположные ценности: мы впервую очередь обращаем внимание на способность адекватно мыслить, а не на специфические теоретические знания.
Технический разбор технических задач — разве это не техническое?
Сейчас пока рано об этом говорить.
Возможно вы хорошо решили остальное и по сумме баллов окажетесь в списке лучших.
Напишем что-то в любом случае, даже если это "отказ".
Можете привести функции, которые вас смутили?
Это только примеры решений — можно обойтись без конкретных функций, применённых в них, или заменить другими. В любом случае, список будет полезен: мы стараемся приводить наиболее понятные решения — ваш фидбек помог бы этому.
Смотря что вы подразумеваете под "нулевым этапом проверки на адекватность".
Это 3 задания из онлайн-теста. Всего в онлайн-тесте их было 6.
Те, кто успешно прошёл тест, попадали на очное интервью, на котором так же были разнообразные задачи и вопросы.
Не переживайте! Если кто-то написал 43 975 482 млн, он так же мог получить максимальный балл.
Само число для решения не играет никакой роли, как я писал выше: важно то, как будет объяснён порядок действий и необходимое время.
Хоть это и не играет никакой роли, справедливости ради, изначально в задании подразумевались именно статьи(Content pages из вашей ссылки), которых сейчас 5.5 млн. Оригинальный текст из задания: "download English version of Wikipedia (only pages with articles)"
В таком случае мы свяжемся с вами по email.
Для надёжности можете скинуть мне в Хабрапочту недостающие данные, по телефону всё же оперативнее.
Так же, как и вариант с постраничным скачиванием страниц:
Под "достаточно объяснён" я подразумеваю, что, например, в случае с дампом отсюда https://dumps.wikimedia.org/enwiki/latest/ ещё требуется пояснение, как из XML-файла с разметкой в Wiki-формате будут воссозданы исходные страницы в HTML-разметке, какие мы видим на сайте Википедии.
Это не совсем то, что мы хотим проверить. Для нас работал ли человек с большими числами или нет — не так важно. Важно, сможет ли он сориентироваться, если работать придётся.
Зависит от конкретной области.
Например, некоторые могут не знать о существовании pcntl_fork() в PHP и успешно решать большие крутые задачи, некоторым fork может быть жизненно необходим в повседневной работе.
Мероприятие завершено, всем спасибо!
По итогам мы пригласили 28 человек в офис на собеседование, 5 из них получили офферы.
До проведения мероприятия мы точно не будем выкладывать задачи.
После него возможно мы сделаем какой-то отчёт и возможно включим что-то про задачи. Но на данный момент это не решено.
Пока что могу сказать, что некоторые задачи были взяты из публичного пула HackerRank, поэтому вы можете попробовать порешать что-то оттуда.
Детали выдавать заранее только здесь было бы нечестно, т. к. увидят их не все => кандидаты будут не в равных условиях.
Представьте, что вы идёте на обычное интервью, и готовьтесь исходя из этого.