Комментарии 189
>спраливали
поправте в заголовке.
имхо, а такие тесты дают просто для проверки знаний основ и принципов языка и уменб думать. всему остальному можно научить по ходу работы.
поправте в заголовке.
имхо, а такие тесты дают просто для проверки знаний основ и принципов языка и уменб думать. всему остальному можно научить по ходу работы.
Спасибо! уже )
«О чем меня спрашивали на собеседовании» — или я идиот (убейте меня кто-нибудь и т.д.)? ))
О чем я ел на обед
Что я ел на обед
Я говорил, что меня спрашивали на собеседовании?
Я говорил, о чем меня спрашивали на собеседовании?
О чем я ел на обед
Что я ел на обед
Я говорил, что меня спрашивали на собеседовании?
Я говорил, о чем меня спрашивали на собеседовании?
Все, кто успел поставить минус — видимо не сумели разобраться в сути комента ) Поясню для бронетанковых войск: таки нельзя так говорить по-русски —
«о чем я ел на обед» или
«что меня спрашивали на собеседовании»,
зато, если немного поменять местами, то получим вполне удобоваримые варианты вида:
«что я ел на обед»
«о чем меня спрашивали на собеседовании»
таки я идиот и придрался к фигне?
«о чем я ел на обед» или
«что меня спрашивали на собеседовании»,
зато, если немного поменять местами, то получим вполне удобоваримые варианты вида:
«что я ел на обед»
«о чем меня спрашивали на собеседовании»
таки я идиот и придрался к фигне?
НЛО прилетело и опубликовало эту надпись здесь
А может у них полно такого говнокода и никто не может с ним разобраться.
Реально этот вопрос мне кажется был задан для другого, и в человеческом языке звучит примерно вот так «А сколько реально у Вас опыта?». Если ты знаеш что это выражение делает значит ты с этим встречался, а обычно с таким не встречаются за пол года работы и 3 года клепки сайтов клонов за 100$. Легкий «парсинг» таких выражений это годы опыта которые в свою очеред говорят что ты знаеш как писать код. что такое ОО и все остальное…
Ну это естесно мое ИМХО.
Ну это естесно мое ИМХО.
У меня опыт больше 10 лет в Perl, но, тем не менее, у меня на компе висит читшит, где приоритеты операторов прописаны. И то, что оператор = слабее ?: я подсмотрел в нём, а не помнил, ибо такие конструкции с присваиванием после? я не использую.
Ибо Perl придуман, что бы код читался легче. Тогда как некоторые считают, что это для того, что бы обфусцированные программы можно было писать.
Ибо Perl придуман, что бы код читался легче. Тогда как некоторые считают, что это для того, что бы обфусцированные программы можно было писать.
А пробел в слове «чтобы», чтобы коммент было проще читать?
а предыдущий оратор всё-таки дело сказал — тут именно проверка опыта. Вся эта теория, что в посте дана, она нафик никому не нужна. Книжки читать любой дурак умеет. А разобраться в говенном коде в критический момент — вотэто какраз и есть ценное качество.
Ну и соответственно в таком можно разобраться только имея опыт.
Ну и соответственно в таком можно разобраться только имея опыт.
И вы навскидку знаете, какие операторы входят в любой из 23 уровней приоритета операторов Perl (кстати цифру 23 я тоже взял в perldoc perlcheat, а не из памяти)? Я думаю, что тема с «проверкой опыта» — это то, чем защищались такие задачи перед руководством. А на самом деле их автор хотел, например, самовыразиться, или оградить себя от конкурентов.
я думаю, отладчик в такой критической ситуации в любом случае поможет лучше.
а если человек писал только хороший код, и разбирался в хорошем коде, то «нафиг он нужен»? :)
Да потомучто люди из паралельного мира должны оставатся там для сохранения баланса.
Это утверждение основано на том что в наше ммире ситуация когда в команде из 20 кодеров которые постоянно под дедлайнами никто никогда не пишет подпорки которые потом перерастают в костыли обыденность и в фазах рефакторинга их как раз и подчищают.
А если человек никогда не работал в комманде 20 человек то очень важного мемента опыта уже нет а именно — «не все знают все что знаеш ты и думают как ты» и знать что эту фразу нужно применить поочереди используя в качестве «я» каждого из комманды.
Если человек никогда не работал под дедлайнами то о том есть ли у него «професиональный» а не «любительский» опыт судить сложно. Потомучто бизнесу всегда все нужно вчера
Это утверждение основано на том что в наше ммире ситуация когда в команде из 20 кодеров которые постоянно под дедлайнами никто никогда не пишет подпорки которые потом перерастают в костыли обыденность и в фазах рефакторинга их как раз и подчищают.
А если человек никогда не работал в комманде 20 человек то очень важного мемента опыта уже нет а именно — «не все знают все что знаеш ты и думают как ты» и знать что эту фразу нужно применить поочереди используя в качестве «я» каждого из комманды.
Если человек никогда не работал под дедлайнами то о том есть ли у него «професиональный» а не «любительский» опыт судить сложно. Потомучто бизнесу всегда все нужно вчера
В приведённом коде перл работает так же, как и Си. За исключением наверное inline if'а.
Недавно попал в аналогичную ситуацию, только вместо вопросов был коротенький тест и собеседование проводил один только HR…
Однажды мне устроили стрессовое собеседование где помимо проверки технических знаний началось такое давление, что я чуть не плеснул стаканом воды в лицо собеседнику…
Оказалось все намного проще. Они помимо технических знаний проверяли стрессоустойчивость будущих кандидатов, а человек оказался очень добрым и веселым. А водой в него плескали довольно часто именно поэтому возле меня не было тяжелых предметов и стаканчик был пластиковый. Заказчики с которыми работала та конторы по большей части были довольно неадекватные и проджект менеджер должен буы уметь держать себя в руках.
Оказалось все намного проще. Они помимо технических знаний проверяли стрессоустойчивость будущих кандидатов, а человек оказался очень добрым и веселым. А водой в него плескали довольно часто именно поэтому возле меня не было тяжелых предметов и стаканчик был пластиковый. Заказчики с которыми работала та конторы по большей части были довольно неадекватные и проджект менеджер должен буы уметь держать себя в руках.
А ведь кто-то может и побить :) Самый не адекватный претендент. Или там стул тоже к полу прикручен?
У меня был случай, когда я кидал в человека стулом :-)
Правда это был админ, весил он втрое больше меня (не от жира, а конституция такая и борьбой в студенчестве занимался), мы были знакомы год и он реально достал :-)
Правда это был админ, весил он втрое больше меня (не от жира, а конституция такая и борьбой в студенчестве занимался), мы были знакомы год и он реально достал :-)
судя по тому, что вы с нами сейчас тут разговариваете, стул таки попал в цель? :-)
Конституция? Поясните, пожалуйста.
Ну… телосложение, другими словами )
Мне почему-то вспомнился Довлатов:
«Пожилой зек рассказывал:
— А сел я при таких обстоятельствах. Довелось мне быть врачом на корабле. Заходит как-то боцман. Жалуется на одышку и бессонницу. Раздевайтесь, говорю. Он разделся. Жирный такой, пузатый. Да, говорю, скверная у нас, милостивый государь, конституция, скверная… А этот дурак пошел и написал замполиту, что я ругал советскую конституцию.»
«Пожилой зек рассказывал:
— А сел я при таких обстоятельствах. Довелось мне быть врачом на корабле. Заходит как-то боцман. Жалуется на одышку и бессонницу. Раздевайтесь, говорю. Он разделся. Жирный такой, пузатый. Да, говорю, скверная у нас, милостивый государь, конституция, скверная… А этот дурак пошел и написал замполиту, что я ругал советскую конституцию.»
ну видимо просто крупного телосложения, кость широкая :)
slovari.yandex.ru/dict/ushakov/article/ushakov/11-1/us1144315.htm?text=конституция&stpar1=1.1.7
«Правда это был админ» — попытка оправдаться?
можно сразу руки в наручники перед собеседованием :)
Есть мнение, что такой тест лучше провалить, чем работать на такой работе.
а как это? я вот не представляю, как можно меня выбесить на собеседовании…
Казахстанская компания, занимающаяся разработкой для госсектора. Финты у заказчиков могут доходить до паранои… опыт после той организации остался огромный и сейчас изрядно помогает.
Недели три назад изрядно подвыпиший руководитель организации с которой мы работаем позвонил в час ночи и пытался несвязно наехать почти с матами… одним словом пьяный бред… И вот здесь как раз и пришлось повести себя корректно и не послать куда подальше сразу а мягко разойтись… на утро по трезвости уже были извинения с его стороны. Если бы послал, то могли потерять постоянного клиента, который приносит около 10% всего дохода компании.
Кто то щас начнет говорить, что гордость превыше всего… и будет кипятится… а сотрудникам нужно кормить семьи и бонусы все хотят… вот именно для этого и нужны стресоустойчивые руководители, что бы основной удар брать на себя и поддерживать хороший климат в коллективе.
Недели три назад изрядно подвыпиший руководитель организации с которой мы работаем позвонил в час ночи и пытался несвязно наехать почти с матами… одним словом пьяный бред… И вот здесь как раз и пришлось повести себя корректно и не послать куда подальше сразу а мягко разойтись… на утро по трезвости уже были извинения с его стороны. Если бы послал, то могли потерять постоянного клиента, который приносит около 10% всего дохода компании.
Кто то щас начнет говорить, что гордость превыше всего… и будет кипятится… а сотрудникам нужно кормить семьи и бонусы все хотят… вот именно для этого и нужны стресоустойчивые руководители, что бы основной удар брать на себя и поддерживать хороший климат в коллективе.
Ха. Ха. Ха. Мне на собеседовании задавали правильные вопросы. Те самые, которые нравятся и автору. И я, воодушевленный, давал правильные ответы. А в реальности пришлось разгребать тонны индус-стайл кода, которые мои новые коллеги все продолжали и продолжали клепать. И комменты в стиле //костыль!!11 гыгыгы. И сотни коммитов с комментариями «upd» и «ыыы». И тысячи одинаковых строк кода по всему проекту. Это хорошо, что автору дали понять, с чем придется иметь дело. Не обманули хотя бы.
Хотя и несколько опасаясь задеть чью-то святыню, всё же выражу согласие с основным тезисом этой статьи: Перл содержит сразу несколько конструкций, вызывающих нравственную деградацию программиста в сторону стремления к деятельному усложнению читаемости программы во имя самоотчленения от «профанов».
Вот пара-тройка моих любимых примеров:
if (a) { b; } else { c; } → (a)?b:c;
if (!a) { b; } → a || b;
if (a) { b; } → a && b;
Все они выглядят ещё более или менее невинно и даже убедительно, когда блоки «a» и «b» и «c» просты и однострочны; но когда идея становится силой и овладевает массами, тогда совершенно тушите свет, опускайте занавес.
Интересно, что значительная часть перлового трюкачества возможна и в джаваскрипте, но на джаваскрипте так почти никто не пишет.
Какой-то эффект традиции, вероятно.
Вот пара-тройка моих любимых примеров:
if (a) { b; } else { c; } → (a)?b:c;
if (!a) { b; } → a || b;
if (a) { b; } → a && b;
Все они выглядят ещё более или менее невинно и даже убедительно, когда блоки «a» и «b» и «c» просты и однострочны; но когда идея становится силой и овладевает массами, тогда совершенно тушите свет, опускайте занавес.
Интересно, что значительная часть перлового трюкачества возможна и в джаваскрипте, но на джаваскрипте так почти никто не пишет.
Какой-то эффект традиции, вероятно.
a || b; — очень распространённая конструкция в джаваскрипте.
глупо не использовать удобные шорткаты.
глупо не использовать удобные шорткаты.
В условных присваиваниях, когда пишут width = paramWidth || global.width || "5px" — тогда она полезная; но если ею обычный оператор ветвления заменяют, то меня с души воротит.
Да ну. В Perl можно написать 'or' вместо || b получить очень понятный код:
do_something() or die;
Сравните его с
if (!do_something) { die };
А написать плохой и нечитабельный код можно практически в любом языке.
do_something() or die;
Сравните его с
if (!do_something) { die };
А написать плохой и нечитабельный код можно практически в любом языке.
можно написать 'or' вместо ||
Не всегда. У этих операторов разные приоритеты.
Кстати, можно написать ещё прикольнее:
do_something(), return $result if condition;
# или
condition and do_something(), return $result;
Только в обычном коде злоупотреблять этим — моветон, но в кусках написанных в функциональном стиле позволяет сократить десятки строк кода.
do_something(), return $result if condition;
# или
condition and do_something(), return $result;
Только в обычном коде злоупотреблять этим — моветон, но в кусках написанных в функциональном стиле позволяет сократить десятки строк кода.
Ну эти примеры не только к перлу относятся :) Это совершенно нормальные вещи, читаемы и удобные.
Если ими заменять все подряд, это конечно пипец, такой код видеть доводилось. А классические примеры в стиле open(...) or die имхо достаточно симпатичны, по сравнению с засовываением команды open в условие if. Так что — каждому приему свое место.
ЗЫ кстати, считается хорошим тоном использовать для таких целей and/or вместо приведенных Вами операторов. Приоритет ниже и меньше шанс забыть про скобки.
ЗЫ кстати, считается хорошим тоном использовать для таких целей and/or вместо приведенных Вами операторов. Приоритет ниже и меньше шанс забыть про скобки.
Может, это был только первый этап собеседования? =)
Похоже автор хотел увидеть в работодателе то, что хотел увидеть…
Вам второе собеседование назначили? На работу взяли?
Вам второе собеседование назначили? На работу взяли?
Думают пока. (Разговаривали-то вчера поздно вечером.)
Всё понятно. Своим постом вы готовите себя к отказу.
Посмотрим. (я им ссылку отправил :-))
Я считаю, что любые чувства обоюдны. Если они сочтут, что я им не подхожу, значит мне у них будет трудно/плохо, значит и они мне не подходят… В данном случае, они лучше знают, что меня ждёт у них; им и оценивать.
Спасибо им за труд поговорить со мной, закинуть в меня мысли для новых постов, оценить меня…
Я считаю, что любые чувства обоюдны. Если они сочтут, что я им не подхожу, значит мне у них будет трудно/плохо, значит и они мне не подходят… В данном случае, они лучше знают, что меня ждёт у них; им и оценивать.
Спасибо им за труд поговорить со мной, закинуть в меня мысли для новых постов, оценить меня…
Когда-то давно, когда я программирвал на перле, я выработал для себя такой стиль. Чтобы можно через месяц было прочитать то, что написано, программировать максимально дубово, обязательно ставить скобки, отступы, чаще назначать переменные, вместо прямой подстановки возвращаемых результатов. Обязательно перед определением функции описание назначения, аргументов и возвращаемого значения. И никаких фокусов!
Иначе — задница.
Иначе — задница.
Что хотели узнать эти люди?
Они не спросили меня про мои ОО-убеждения.
Они не спросили про элементы функционального программирования (map vs. for; что когда лучше).
Они не спросили про регулярные выражения.
Они не спросили про алгоритмы (хотя бы классическая оптимизация встроенной сортировки от Рендала-Шварца).
Они не спросили, как я отношусь к goto;
Каковы, по моему мнению, должны быть комментарии и документация;
Хорошо ли копипастить код.
Есть ли у меня представления о шаблонизаторах и прочем.
Есть ли у меня представления о патерах (итераторы, адаптеры...).
Что я знаю про ленивые вычисления.
Хм… Не в обиду Вам, но вы уверенны, в том, что все данные вопросы имеют смысл? ООП — это не самоцель, а средство. При том, в очень крупных проектах, часто функциональное программирование полезнее. Я говорю именно про высоконагрузочные проекты.
Про goto — за него руки мне отбивали еще в школе.
А все остально можно свести к двум типам вопросов: помните ли Вы институтскую программу и умеете ли читать документацию и книги… :)
Вот-вот! Неужто им было неинтересно узнать самоцель ли для меня ООП? И так далее.
Перечисленные вопросы не допускают однозначного ответа. Как раз, как мне кажется, самое интересное — узнать, где человек (соискатель) проводит границы, как он оценивает эффективность разных приёмов…
Перечисленные вопросы не допускают однозначного ответа. Как раз, как мне кажется, самое интересное — узнать, где человек (соискатель) проводит границы, как он оценивает эффективность разных приёмов…
Все это нормальные вопросы, потому как в перле к ОО можно подойти с такого количества сторон, сколько есть для этого модулей на CPAN'е.
Про алгоритмы я бы спрашивал, если это действительно применимо к проекту.
Спросил бы про то как человек тестирует свой код, чтобы понять есть ли у него опыт в этом.
Ну и остальные вопросы наверное касались бы библиотек/фреймворков используемых на проекте.
Так без фанатизма, просто понять уровень, потом небольшое тестовое задание и всё :)
Про алгоритмы я бы спрашивал, если это действительно применимо к проекту.
Спросил бы про то как человек тестирует свой код, чтобы понять есть ли у него опыт в этом.
Ну и остальные вопросы наверное касались бы библиотек/фреймворков используемых на проекте.
Так без фанатизма, просто понять уровень, потом небольшое тестовое задание и всё :)
> Я говорю именно про высоконагрузочные проекты.
Это те которые своей запутанности очень сильно грузят мозг? :))
> Про goto — за него руки мне отбивали еще в школе.
В принципе верно, хотя даже тут не все однозначно на самом деле.
Это те которые своей запутанности очень сильно грузят мозг? :))
> Про goto — за него руки мне отбивали еще в школе.
В принципе верно, хотя даже тут не все однозначно на самом деле.
> Про goto — за него руки мне отбивали еще в школе.
Лично я не стесняюсь использовать goto в языках, которые не поддерживают (или поддерживают, но неэффективно) исключения. Не знаю, что в этом может быть плохого — иметь один блок обработки ошибок, а не стопицот веток «else»…
Лично я не стесняюсь использовать goto в языках, которые не поддерживают (или поддерживают, но неэффективно) исключения. Не знаю, что в этом может быть плохого — иметь один блок обработки ошибок, а не стопицот веток «else»…
Плохо то, что на одну метку вы можете попасть из множества мест. Восстановить, откуда произошёл переход, часто невозможно. Диагностировать ошибки — тоже.
Хотя, конечно, если использовать goto аккуратно, руководствуясь какой-то логикой, то они не опасны… только логику лучше записать на бумажку… или высечь на камне для потомков… а то они вас проклянут :-)
Хотя, конечно, если использовать goto аккуратно, руководствуясь какой-то логикой, то они не опасны… только логику лучше записать на бумажку… или высечь на камне для потомков… а то они вас проклянут :-)
Есть такая очень хорошая вещь как
do {
if (error)
break;
} while(0);
//HERE error handling
do {
if (error)
break;
} while(0);
//HERE error handling
Как раз это очень плохая вешь. Потому что не «семантично».
Наверно поэтому весь код ядра линукс такими финтами и усыпан. Что конкретно вам не нравится? В каком месте это не семантично?
Семантически цикл предназначен для повторения кода несколько раз, а не для обрамления транзакции. Я понимаю, что в Си иного способа нет, но это не делает данную «вещь» хорошей и рекомендуемой в массы.
У меня речь касательно Си и возможно языков в которых нет Exceptions. Иной способ есть — это goto. Семантически с goto все отлично, но вот с практической точки зрения do while(0) более применим. Если есть какие-то более корректные способы, то рад послушать.
Кстати, возможно кто-то начнет кидать камни но
#define TRY do =
#define THROW break;
#define CATCH while (0);
TRY {
if (error)
THROW;
} CATCH;
семантика уже лучше?
Кстати, возможно кто-то начнет кидать камни но
#define TRY do =
#define THROW break;
#define CATCH while (0);
TRY {
if (error)
THROW;
} CATCH;
семантика уже лучше?
плюсик кстати вам поставил. просто интересно стало, что кому-то такая вещь не нравится. Я лично решил в своей жизни гору проблем используя данную конструкцию. Например, у меня всегда один return в коде функции и без всяких goto. А вы на каком вобще языке работаете?
И вам и автору.
Процедурное или императивное, а не функциональное. Хотя ООП это тоже процедурное программирование, так что скорее то о чем вы говорите правильнее называть «лапшой».
Процедурное или императивное, а не функциональное. Хотя ООП это тоже процедурное программирование, так что скорее то о чем вы говорите правильнее называть «лапшой».
Выразитесь яснее, вы о чём? К каким именно словам это относится? (Предложение «Процедурное или императивное, а не функциональное.» не содержит ни подлежащего ни скажемого)
Вы еще скажите, что мое предложение неграмотно потому что в нем нет в явном виде подлежащего :)
«функциональное программирование полезнее»
Ставлю 10 баксов, что вы имели ввиду нифига не функциональное программирование, а вот то самое «процедурное или императивное». Т.е. иными словами нифига не в теме терминологии.
«функциональное программирование полезнее»
Ставлю 10 баксов, что вы имели ввиду нифига не функциональное программирование, а вот то самое «процедурное или императивное». Т.е. иными словами нифига не в теме терминологии.
что ж, вы только что продули 10 баксов
Серьезно? Ну ка покажите мне кусок функционального кода на перле :) Желательно что-нибудь поинтереснее map
Я отвечу притчей.
Много лет назад, я разместил резюме на hh.ru. На меня довольно быстро вышло одно крупное информагенство. Оно мне написало «вы отличный парень, но чтобы у нас не осталось сомнений, решите эту задачку» и прислали просто ТЗ конвертера из одного формата в другой. Со спецификациями форматов, чёткими требованиями… страниц на 10. Я им сказал «эм… а вы не офигели совсем», на что они ответили «мы согласны заплатить вам $500 за это». Я больше им не отвечал.
Если вы не готовы платить мне деньги, то вам придётся утешиться чем-нибудь из интернетов. На пример вот этим "нет препятствий для написания программ в функциональном стиле на языках, которые традиционно не считаются функциональными".
Много лет назад, я разместил резюме на hh.ru. На меня довольно быстро вышло одно крупное информагенство. Оно мне написало «вы отличный парень, но чтобы у нас не осталось сомнений, решите эту задачку» и прислали просто ТЗ конвертера из одного формата в другой. Со спецификациями форматов, чёткими требованиями… страниц на 10. Я им сказал «эм… а вы не офигели совсем», на что они ответили «мы согласны заплатить вам $500 за это». Я больше им не отвечал.
Если вы не готовы платить мне деньги, то вам придётся утешиться чем-нибудь из интернетов. На пример вот этим "нет препятствий для написания программ в функциональном стиле на языках, которые традиционно не считаются функциональными".
Ой да ладно, вам, мне ведь линка было бы достаточно на хоть что-то написанное на перле как на функциональном языке. Но вот нет такого, правда? :)
Комментировал я кстати, преимущественно комментатора, а вас упомянул, потому что показалось, что вы тоже не в тему про фунциональность упомянули. Однако посмотрел, вполне в тему ) Так что с меня пиво за 10 баксов при встрече :)
Комментировал я кстати, преимущественно комментатора, а вас упомянул, потому что показалось, что вы тоже не в тему про фунциональность упомянули. Однако посмотрел, вполне в тему ) Так что с меня пиво за 10 баксов при встрече :)
Ладно :) отработаю пиво:
причём, обратите внимание, нет ни одной изменяемой переменной! даже присвоений нет! не хуже хаскеля! :-)
Можно написать объекты для всего, чего угодно, и сделать из перла сколь угодно функциональный язык :-)
print join(' ', # типа редьюс как бы (убогий, конечно :-))
(
sort # типа функция высших порядков, принимает на вход функцию
{ abs($a) <=> abs($b) } # типа labda a, b:...
(-3, 1, -5, 10) # ...и входные данные
)
);причём, обратите внимание, нет ни одной изменяемой переменной! даже присвоений нет! не хуже хаскеля! :-)
Можно написать объекты для всего, чего угодно, и сделать из перла сколь угодно функциональный язык :-)
вам вот непонятно почему такие вопросы, а мне девушка-программер-руководитель-группы рассказывала как к ним на собеседование приходили «юные гуру ПХП ака создатели мегасайтов», которые были не в состоянии написать на бумажке какие значения принимает логическая XOR в зависимости от аргументов (табличка 2х2)
вас там до ночи прессовали ?:)
Нее… я пришёл поздно вечером; и слово «прессовали» не подходит, просто мило поговорили в очень уютном, красивом и чистом офисе.
Мне понравилось. Условия там очень хорошие. Только вопросы настораживают :-)
Но может быть люди просто устали, их оторвали от чего-то и они поспрашивали наспех… Что-то мне не верится, что всё так плохо :-)
Мне понравилось. Условия там очень хорошие. Только вопросы настораживают :-)
Но может быть люди просто устали, их оторвали от чего-то и они поспрашивали наспех… Что-то мне не верится, что всё так плохо :-)
ну вот :)
Если условия хорошие — я бы не стал заморачиваться.
Заморачиваться по поводу плохого кода в проектах должен прежде всего работодатель. Это он несет дополнительные расходы из-за того что работа идет не так быстро. А все потому что разработчики тратят многое времени на понимание того что сделано раньше.
Заморачиваться по поводу плохого кода в проектах должен прежде всего работодатель. Это он несет дополнительные расходы из-за того что работа идет не так быстро. А все потому что разработчики тратят многое времени на понимание того что сделано раньше.
Это глупый вопрос, который можно проверить на компе.
Человек — не компилятор.
Человек — не компилятор.
На мой взгляд, подобные вопросы призваны помочь понять работодателю на сколько глубоко знание, по большей мере, семантики языка. А то как вы его примените- другое дело:)
Не согласен.
Вот вопросы на понимание семантики:
1. как работают варианты:
2. что вы скажете про это:
Вот вопросы на понимание семантики:
1. как работают варианты:
@a = map { {$_ => $_} } qw/a b/;
@a = map { $x=$_; {$x => $_} } qw/a b/;
2. что вы скажете про это:
my $fh = $self->{'file'};
my $m = <$fh>;
и это
my $m = <$self->{'file'}>;
взорвало мозг просто
Чёт никак не допру почему в первом пункте результат различается.
map работает в списковом контексте, но почему в одном случае хеш превращается в список, а во втором нет — не пойму.
^( А думал ведь, что хорошо perl знаю…
map работает в списковом контексте, но почему в одном случае хеш превращается в список, а во втором нет — не пойму.
^( А думал ведь, что хорошо perl знаю…
Тогда, может быть дело не контексте? ,-)
~$ perl -MO=Deparse, -e 'print map {{$_=>$_}} 1..10'
print map({+{$_, $_};} 1..10);
-e syntax OK
~$ perl -MO=Deparse, -e 'print map {;{$_=>$_}} 1..10'
print map({{
$_, $_;
}} 1..10);
-e syntax OK
Ещё можно
my $m = < $fh>; # (пробел перед $fh)
my $m = < $fh>; # (пробел перед $fh)
Навеяло… В курсе по сям в intuit.ru (когда-то) была куча вопросов в тестах с подобными +±-, равномерно раскиданным по строчке, причем и в левой, и в правой частях. Так вот, читатели были немного недовольны. Те, кто проверяли пример gcc и поклонники Visual Studio получали афигенно разные результаты :)
К перлу это конечно же не относится, но бредовость части примеров иллюстрирует. По идее уже за первый экзампл можно было плеснуть водой в лицо: «Да как вы могли подумать, что я буду писать в таком стиле!» :)
К перлу это конечно же не относится, но бредовость части примеров иллюстрирует. По идее уже за первый экзампл можно было плеснуть водой в лицо: «Да как вы могли подумать, что я буду писать в таком стиле!» :)
моё отношение к интервью полностью выражает следующий комикс:
www.phdcomics.com/comics/archive.php?comicid=993
www.phdcomics.com/comics/archive.php?comicid=993
Случай из жизни: мне собеседовании дали листок с простенькими задачками. Причём первой шла типа «поменяйте местами значения двух целых переменных, не используя третью». Итогом стала фраза «узнаю математический факультет!»
Но оказалось, что только такие задачки я и умел решать после вуза, а всё остальное уже было не по зубам!
Но оказалось, что только такие задачки я и умел решать после вуза, а всё остальное уже было не по зубам!
Да уж… Я тоже быстро решил эту задачку, хоть и не программист.
a = 2;
b = 4;
a = a+b;
b = a-b;
a = a-b;
Можно еще придумать к таким тестам отвлекающие маневры — бегать вокруг с маракасами. Опять же узнать глубину знаний в нестандартных ситуациях.
Собеседования, для того, чтобы беседовать, а тесты — тестировать. Я против тестов на собеседовании, тем более таких.
a = 2;
b = 4;
a = a+b;
b = a-b;
a = a-b;
Можно еще придумать к таким тестам отвлекающие маневры — бегать вокруг с маракасами. Опять же узнать глубину знаний в нестандартных ситуациях.
Собеседования, для того, чтобы беседовать, а тесты — тестировать. Я против тестов на собеседовании, тем более таких.
К счастью, в перле это делается просто: ( $a, $b ) = ( $b, $a ); :)
вы уверены, что при этом не создаётся временных переменных? ,-)
Переменных в полноценном перловом смысле (pad) — да, уверен. :) На стеке, конечно, размещается ссылка на массив ( $a, $b ), но refcount у него 0. :)
P.S. неточно выразился: на стеке размещается сами ссылки на $a, $b, refcount у $a, $b неизменны, а по refcount по отношению к «массиву» неприменим.
Рефкаунт=0, а он есть! Мортализация в дейстии, однако :-)
Это мега фича перла: У него есть не только механизм сборки мусора, но специальный механизм, подавляющий действие механизма сборки мусора! Неее, вы не ослышались, механизм сборки мусора нельзя выключить, можно включить его подавление.
Когда Чак Норрис входит в комнату, он не включает свет — он выключает темноту.
В каждой шутке есть доля шутки )
Это мега фича перла: У него есть не только механизм сборки мусора, но специальный механизм, подавляющий действие механизма сборки мусора! Неее, вы не ослышались, механизм сборки мусора нельзя выключить, можно включить его подавление.
Когда Чак Норрис входит в комнату, он не включает свет — он выключает темноту.
В каждой шутке есть доля шутки )
Кажется, я угадал компанию: )
И, судя по всему, им нужен человек, который хорошо понимает семантику Perl.
И вам дали хороший тест, который это проверяет.
Потому что если человек не понимает достаточно хорошо как Perl работает внутри — то уже неважно как он относится к goto, к какой объектно-ориентированной религи он принадлежит и всё прочее тоже не самое важное для данной вакансии.
И, судя по всему, им нужен человек, который хорошо понимает семантику Perl.
И вам дали хороший тест, который это проверяет.
Потому что если человек не понимает достаточно хорошо как Perl работает внутри — то уже неважно как он относится к goto, к какой объектно-ориентированной религи он принадлежит и всё прочее тоже не самое важное для данной вакансии.
Возможно, подобные тесты и проверяют глубину знания Perl, но это абсолютно ничего не говорит о качестве программиста.
Конечно, если им нужен «Perl-переводчик-синхронист», или просто оптимизатор кода, эти тесты самое то… Тогда для автора эта не та работа, слишком амбициозен, будут проблемы.
А работающих тестов на перфекционизм и «здравую голову» я пока не видел.
Конечно, если им нужен «Perl-переводчик-синхронист», или просто оптимизатор кода, эти тесты самое то… Тогда для автора эта не та работа, слишком амбициозен, будут проблемы.
А работающих тестов на перфекционизм и «здравую голову» я пока не видел.
> Возможно, подобные тесты и проверяют глубину знания Perl, но это абсолютно ничего не говорит о качестве программиста.
По-моему как раз говорит что знания не настолько глубокие, наскольок это требутся работодателю. В этом случае остальные качества уже неважны. Нет ручек — нет варенья.
По-моему как раз говорит что знания не настолько глубокие, наскольок это требутся работодателю. В этом случае остальные качества уже неважны. Нет ручек — нет варенья.
Пример из профессионального.
Если работодателю, скажем, нужно идеальное знание фотошопа (я сам дизайнер), а как он рисует — потом посмотрим… Тогда другое дело. Правда, обычно собеседуют дизайнеров не перед «станком». Шашечки или ехать…
Конечно, если совсем не может даже разобраться в примере, это одно.
На мой взгляд, если компания серьезная, могли бы потратить время на более интересные и сложные тестовые задания, пускай даже на дом…
А эти тесты встречаются с завидной регулярностью, как было сказано ниже.
Если работодателю, скажем, нужно идеальное знание фотошопа (я сам дизайнер), а как он рисует — потом посмотрим… Тогда другое дело. Правда, обычно собеседуют дизайнеров не перед «станком». Шашечки или ехать…
Конечно, если совсем не может даже разобраться в примере, это одно.
На мой взгляд, если компания серьезная, могли бы потратить время на более интересные и сложные тестовые задания, пускай даже на дом…
А эти тесты встречаются с завидной регулярностью, как было сказано ниже.
если компания хорошая, то вам даже не обязательно было давать ответ, а просто начать рассуждать про приоритет операторов и пообещать что подобного кода от вас они не увидят. после этого все вопросы бы отпали и вы бы просто рассказали с чем работали и сколько хотите получать. в первую очередь работадатель присматривается к человеку и лишь затем к специалисту. хотя опыт подсказывает, что большие успешные компании — это конвеер, где переплачивают менеджерам и экономят на программировании.
Недавно я искал работу и прошёл несколько собеседований на старшего PHPшника. Сначала меня встретили вопросами наподобие
$x=1;
$x = $x++ + ++$x;
а также «чем отличается абстрактный класс от интерфейса», «собери хитрый SQL-запрос», «что выдаст хитрый SQL-запрос» и куча вопросов по ООП.
Потом я ходил на другие собеседования, но вопросы удивительным образом повторялись.
$x=1;
$x = $x++ + ++$x;
а также «чем отличается абстрактный класс от интерфейса», «собери хитрый SQL-запрос», «что выдаст хитрый SQL-запрос» и куча вопросов по ООП.
Потом я ходил на другие собеседования, но вопросы удивительным образом повторялись.
а чем отличается-то? :)
Действительно, сначала написал, потом подумал :) Просто раньше я не пробовался на такую специальность, а нанимался и работал непосредственно (без собеседований и непосредственного начальника).
дак он потом на другие собеседования ходил ;)
У интерфейсов нет членов (members), только методы.
Насчет инкрементов пример… мы с другом с пхп не знакомы и мнения разошлись, я считаю 5, он — 4. Рассудите :)
Меня всегда до глубины души поражали такие вопросы и такие конструкции… Никакой реальной пользы. Конечно, я понимаю, что смысл этих вопросов — выявить понимание языка на глубоком уровне. Но, простите, нахрена? Чем это поможет в будущей проф. деятельности? Я не встречал задач, где подобные вещи были бы применимы…
1) Префиксный и постфиксный инкремент — простите, но это же основы. Это даже в школах учат.
2) Сложные вопросы задаются для того, чтобы посмотреть, как вы рассыждаете. Вы можете даже не прийти к правильному ответу, но если рассуждения будут грамотными, то вопрос зачтётся.
3) Как правило, те люди, которые принимают собеседования имеют больше опыта и знают, о чём говорят.
Если человек умеет рассуждать, то он решит и нестандартную задачу. А идиот останется идиотом и со знанием ООП.
2) Сложные вопросы задаются для того, чтобы посмотреть, как вы рассыждаете. Вы можете даже не прийти к правильному ответу, но если рассуждения будут грамотными, то вопрос зачтётся.
3) Как правило, те люди, которые принимают собеседования имеют больше опыта и знают, о чём говорят.
Если человек умеет рассуждать, то он решит и нестандартную задачу. А идиот останется идиотом и со знанием ООП.
> А идиот останется идиотом и со знанием ООП.
Звучит как «неуч останется неучем, даже если выучится»… Звучит странно… я с вам не согласен. Идиот просто не был никогда идиотом, если он знает ООП. (именно знает, когда что использоваться и так далее)
Звучит как «неуч останется неучем, даже если выучится»… Звучит странно… я с вам не согласен. Идиот просто не был никогда идиотом, если он знает ООП. (именно знает, когда что использоваться и так далее)
Если префикс и постфикс в одном предложении — понятные даже школьникам основы, тогда скажите, что выведет printf в следующих кусках на C99 (естественно, в литературу или консоль не заглядывать):
int x = 1;
x = x+++++x;
printf( "%d", x);
int x = 1;
int *y = &x;
x = *y+++++*y;
printf( "%d", x);
int x = 1;
x = x+++++x;
printf( "%d", x);
int x = 1;
int *y = &x;
x = *y+++++*y;
printf( "%d", x);
4) знать приорететы операторов. Это тоже очень нужно.
Похоже, у вас больше ничего не спросили лишь потому, что вы не знаете базовых вещей. О каких ООП вообще может идти речь.
PS: посмотрите вопросы для собеседования Яндекса. Там такие же вопросы.
Похоже, у вас больше ничего не спросили лишь потому, что вы не знаете базовых вещей. О каких ООП вообще может идти речь.
PS: посмотрите вопросы для собеседования Яндекса. Там такие же вопросы.
Знание приоритетов операторов может быть и не помешает. Но на практике, если порядок их выполнения не очевиден — все нормальные прогаммеры ставят скобки. Таким образом код становится более понятным и устраняется возможность потенциальных ошибок. Поэтому приведенный пример не несет большой пркатической ценности. Кто как — а я не сторонник таких вопросов на собеседовании.
Причем тут, блин, приоритеты.
Проблема подобных задачек с подъеколкой в том, что в одном выражении переменная так или иначе модифицируется несколько раз. Я не знаю и знать не хочу как такие ситуации разруливаются в каждом отдельно взятом языке/интерпритаторе/компиляторе. Писать надо по-человечески.
Проблема подобных задачек с под
вы предлагаете для каждого из известных языков выучить наизусть таблицу приоритетов?! вот вы сами, можете для языка котрым пользовались вчера прямо сейчас нарисовать табличку (не заглядывая в маны :)
4) знать приоритеты операторов. Это тоже очень нужно.
Похоже, у вас больше ничего не спросили лишь потому, что вы не знаете базовых вещей. О каких ООП вообще может идти речь.
PS: посмотрите вопросы для собеседования Яндекса. Там такие же вопросы.
Похоже, у вас больше ничего не спросили лишь потому, что вы не знаете базовых вещей. О каких ООП вообще может идти речь.
PS: посмотрите вопросы для собеседования Яндекса. Там такие же вопросы.
my $x=1;
$x = $x++ + ++$x;
Классическая задача на знание ассоциативности операций. Более сложный вариант, когда учавствуют не два слагаемых, а три.
print(print «A», print «B», print «C»);
Для начала надо знать, что
print [FILEHANDLE] LIST — prints a string or a list of strings. Returns true if successful… То есть что операция print — операция списковая, а во вторых, он ещё возвращает TRUE если всё прошло удачно. Далее надо аккуратно расставить порядок выполнения операций здесь. Если знаешь print на уровне пхп-шного echo — не получится.
my $x=0;
(1)?$x=1:$x=2;
print $x;
Ну и здесь опять же надо чётко представлять себе как работает тернарный оператор. В противном случае всё получится очень печально. Кстати, вместо (1) можно поставить и (rand) — результат не изменится.
Так что учите матчасть, молодой человек. Если всего этого не знать, то и разработчиком сильным не стать. Увы.
И, кстати :) Из той же серии задачка на понимание того, как работает Perl. Чем отличается конструкция
от конструкции
Не зная про стадии работы perl-а, про это ничего нельзя сказать. А надо бы.
eval { my $a = 'b'; print $a; };
от конструкции
eval q{ my $a = 'b'; print $a; };
Не зная про стадии работы perl-а, про это ничего нельзя сказать. А надо бы.
>> my $x=1;
>> $x = $x++ + ++$x;
> Классическая задача на знание ассоциативности операций. Более сложный вариант, когда учавствуют не два слагаемых, а три.
Дурацкая задача, т.к. она не только на ассоциативность, но и на знание правил токенизации и обработки операций над временными переменными. Такого (двух унарников над одной переменной в одном предложении в Perl) никогда в реальной жизни не происходит, а помнить это вредно, т.к. в C на таком же коде другой результат получается, понятно почему.
>> $x = $x++ + ++$x;
> Классическая задача на знание ассоциативности операций. Более сложный вариант, когда учавствуют не два слагаемых, а три.
Дурацкая задача, т.к. она не только на ассоциативность, но и на знание правил токенизации и обработки операций над временными переменными. Такого (двух унарников над одной переменной в одном предложении в Perl) никогда в реальной жизни не происходит, а помнить это вредно, т.к. в C на таком же коде другой результат получается, понятно почему.
Гггг :) Классика она и есть классика.
Переведу. В зависимости от полученных неверных результатов очень легко понять — какими категориями мыслит чел — пхпшными, си++, си#, java…
Переведу. В зависимости от полученных неверных результатов очень легко понять — какими категориями мыслит чел — пхпшными, си++, си#, java…
На Ваше «гггг» могу ответить одно: людей, которые пишут код с подобными конструкциями, как раз нельзя принимать на работу: возвращаемое значение print'а — бесполезное знание, отсутствие скобок в ситуациях, допускающих несколько трактовок, — это ужасный стиль программирования — в командной работе использование хаков просто обязано быть сведено к минимуму, Perl-хакерам же таким место — на унылой кухне.
Да ладно :) С таким подходом и замыкание можно считать «хаком» :)
Нельзя. И очень странно, что Вы путаете божий дар и яичницу — после всех тех «прописных истин», которые преподнесли выше.
Перл — очень гибкий инструмент. И в этом одновременно его прелесть и его беда. Программы на Перле можно написать такими, что никто, кроме автора, никогда не сможет их прочитать. И он даже сможет гордиться этим где-нибудь в каментах на Хабре. Но это не сделает его хорошим программистом. Это лишь покажет гигантские масштабы нереализованных юношеский комплексов такого горе-хакера. Настоящие хакеры как раз пишут код максимально понятно.
Буквально вчера я просто зачитывался этим документом:
search.cpan.org/~sri/Mojo-0.991236/lib/Mojo/Manual/CodingGuidelines.pod#RULES
Думаю, Перл-коммьюнити не станет спорить, что писал его человек ну очень грамотный в нашей сфере. Заметьте, из всей документации на пока что разрабатываемый Mojo этот документ — единственный непустой. А это значит, что стиль программирования для грамотных людей — это первый приоритет. Потому что они знают, что такое работа в команде.
Перл — очень гибкий инструмент. И в этом одновременно его прелесть и его беда. Программы на Перле можно написать такими, что никто, кроме автора, никогда не сможет их прочитать. И он даже сможет гордиться этим где-нибудь в каментах на Хабре. Но это не сделает его хорошим программистом. Это лишь покажет гигантские масштабы нереализованных юношеский комплексов такого горе-хакера. Настоящие хакеры как раз пишут код максимально понятно.
Буквально вчера я просто зачитывался этим документом:
search.cpan.org/~sri/Mojo-0.991236/lib/Mojo/Manual/CodingGuidelines.pod#RULES
Думаю, Перл-коммьюнити не станет спорить, что писал его человек ну очень грамотный в нашей сфере. Заметьте, из всей документации на пока что разрабатываемый Mojo этот документ — единственный непустой. А это значит, что стиль программирования для грамотных людей — это первый приоритет. Потому что они знают, что такое работа в команде.
Ну, вопрос с print`ом — самый неплохой (и потенциально могущий пригодиться) в списке, т.к. кроме возвращаемого значения он требует понимания разницы между именованными унарными и списковыми операторами и знания того, каким из них является print. Но первый и последний пример — нерелевантный треш, кроме ситуации, если они ищут какого-то особого спеца.
А можно пример, когда знание о возвращаемом значении print'а может пригодиться? Прямо вот кусочек кода, плиз :).
А я переведу: получать кореллирующие со знанием человека ответы на такие вопросы без доступа к машине (а такие простые вопросы, наверное, предполагается решать без этого) — можно только у людей типа Ларри Волла, и то, вряд ли. К примеру, сишный вариант, который более по смыслу похож на перловый, чем 100% калька:
int $x=1;
int *$y = &$x;
>> $x = *$y++ + ++*$y;
даст третий вариант. :)
И если для C-шников такой вопрос на собеседовании имеет смысл (всё таки они работают с unmanaged областями памяти), то для перловика — нахер.
int $x=1;
int *$y = &$x;
>> $x = *$y++ + ++*$y;
даст третий вариант. :)
И если для C-шников такой вопрос на собеседовании имеет смысл (всё таки они работают с unmanaged областями памяти), то для перловика — нахер.
не очень разбираюсь в перле, но любопытно… какие ответы все таки у задачек? =)
my $x=1;
$x = $x++ + ++$x;
Ответ: 4.
print(print «A», print «B», print «C»);
Ответ: CB1A11
my $x=0;
(1)?$x=1:$x=2;
print $x;
Ответ: 2
спасибо, а не обидетесь, если я попрошу объяснить, почему в первом не 5, а в последнем не 1? =)
my $x=1;
$x = $x++ + ++$x;
Сначала выстраиваем приоритет операций. Всего их пять — присваивание в левое значение (пл1), постинкрементирование (пои), преинкрементирование (при), сумма слагаемых (сс), присваивание в левое значение (пл2). По убыванию приоритетов получается: «при», «пои», «сс».
«пл1» — присваиваем в переменную $x значение 1.
«при» — слагаемое вычислилось как 2 (предварительно инкрементировав $x= $x+1=2)
«пои» — слагаемое вычислилось как 2 (после этого $x=$x+1=3)
«сс» — сумма двух слагаемых 2+2=4.
«пл2» — в переменную $x записываем значение 4.
my $x=0;
(1)?$x=1:$x=2;
print $x;
Это можно переписать как:
( 1?($x=1):($x) ) = 2
То есть "= 2" выполняется ПОСЛЕ работы тернарного оператора, приоритет у которого больше.
Все-таки по первому не очень понятно из объяснения, почему именно 4.
В документации к перлу про инкременты говорится:
«Note that just as in C, Perl doesn't define when the variable is incremented or decremented. You just know it will be done sometime before or after the value is returned. This also means that modifying a variable twice in the same statement will lead to undefined behaviour.»
Тем более что вариант:
my $x=1
$x = ++$x + $x++;
Выдаст результат 5.
По-моему это возможно в том случае если обработка выражения идет справа налево и постинкремент выполняется уже после присвоения в левое значение. Упрощено можно так переписать:
Вариант ($x = $x++ + ++$x)
x = (2 + 1) ++ # преинкремент только первого слагаемого, постинкримент на весь результат
Вариант ($x = ++$x + $x++).
x = (2 + 2) ++ # преинкремент второго слагаемого, следовательно первого тоже. постинкремент на весь результат.
В документации к перлу про инкременты говорится:
«Note that just as in C, Perl doesn't define when the variable is incremented or decremented. You just know it will be done sometime before or after the value is returned. This also means that modifying a variable twice in the same statement will lead to undefined behaviour.»
Тем более что вариант:
my $x=1
$x = ++$x + $x++;
Выдаст результат 5.
По-моему это возможно в том случае если обработка выражения идет справа налево и постинкремент выполняется уже после присвоения в левое значение. Упрощено можно так переписать:
Вариант ($x = $x++ + ++$x)
x = (2 + 1) ++ # преинкремент только первого слагаемого, постинкримент на весь результат
Вариант ($x = ++$x + $x++).
x = (2 + 2) ++ # преинкремент второго слагаемого, следовательно первого тоже. постинкремент на весь результат.
и ещё — совет. Не стоит выставлять напоказ то, что Вы не прошли собеседование :-)
Знаю я одного такого «собеседника»… Задаёт перловикам вопросы, по своей тупости (читай: бесполезности) очень близкие к приведённым примерам, — а всё потому, что сам — убеждённый плюсовик и категорически против интерпретируемых языков как явления. Собственно, одно то, что он норовит переписать любые веб-приложения на C++ (и что ни разу ещё ему не удалось), уже говорит о многом.
Желаю Вам другого работодателя :).
Желаю Вам другого работодателя :).
> Собственно, одно то, что он норовит переписать любые веб-приложения на C++ (и что ни разу ещё ему не удалось), уже говорит о многом.
Ну это совсем уж клинический случай.
Ну это совсем уж клинический случай.
На мой взгляд компании был нужен не столько Perl программист, сколько просто грамотный программист. Причем не обязательно с глубокими знаниями ООП.
Вопросы взяты вообще из стандартных вопросов по Си.
Скажу честно. На Perl я не писал, но погу понять (хотя может и не совсем верно) как работают операции из предложенных на собеседовании по аналогии с языком Си. А вот примеры, приведенные в других комментах мне так просто понять уже не получается. Нужно учить мат часть.
Но такие вопросы на собеседованиях довольно распространены и к ним нужно быть готовым.
Вопросы взяты вообще из стандартных вопросов по Си.
Скажу честно. На Perl я не писал, но погу понять (хотя может и не совсем верно) как работают операции из предложенных на собеседовании по аналогии с языком Си. А вот примеры, приведенные в других комментах мне так просто понять уже не получается. Нужно учить мат часть.
Но такие вопросы на собеседованиях довольно распространены и к ним нужно быть готовым.
Тогда скажите, в чём разница между значением, выведенным C[++] и Perl в вопросе про унарные ++? Не подглядывайте в доки и не делайте примерчиков.
в Си++ возможны варианты в зависимости от компилятора (знаю из разных статей, да и тут в комментах это упоминалось. сам не проверял).
Но сути самих операторов что в Perl, что в Си одинаковые.
Скорее всего на примере этого кода работодатель просто хотел услышеть последовательность операций в понимании испытуемого, а не точный ответ.
Просто узнать, а знает ли это человек что такое префиксные и постфиксные операции в принципе.
Но сути самих операторов что в Perl, что в Си одинаковые.
Скорее всего на примере этого кода работодатель просто хотел услышеть последовательность операций в понимании испытуемого, а не точный ответ.
Просто узнать, а знает ли это человек что такое префиксные и постфиксные операции в принципе.
Для проверки префиксных/постфиксных операторов достаточно примеров $i = ++$i; и $i = $i++; или примеры с for(;; ) {}. Всё таки, вариант $i = $i+++++$i весьма нетривиален: во-первых, как объяснить, пользуясь знанием официального мануала, почему это ($i++)+(++$i), а не (($i++)++)+$i? Ну а во-вторых, — собственно последовательность постфиксных инкрементов в предложении.
Я не понимаю удивления автора.
Если вам задали такой вопрос, значит им необходимо, чтобы вы знали ответ. Возможно у них Тим лид постоянно такие финты пишет и обожает их, т.к. считает себя МегаГуру программирования. Или возможно у них весь код в таком стиле написан.
Если вам задали такой вопрос, значит им необходимо, чтобы вы знали ответ. Возможно у них Тим лид постоянно такие финты пишет и обожает их, т.к. считает себя МегаГуру программирования. Или возможно у них весь код в таком стиле написан.
${q=q=}-=${q-q-}; # ПЫЩ! ПЫЩ!!!111
как программист микроконтроллеров, я бы этого кодера действительно убил.
И дело даже не в том, что читать тяжело.
Вместо одноадресной операции сделать жуткое вычитание с присвоением. И еще не факт, что компилятор поймет что от него хотят и упростит это выражение. Скорее всего он всетаки будет делать вычитание через аккумулятор и займет это в лучшем случае в 9(!) раз больше памяти.
как программист микроконтроллеров, я бы этого кодера действительно убил.
И дело даже не в том, что читать тяжело.
Вместо одноадресной операции сделать жуткое вычитание с присвоением. И еще не факт, что компилятор поймет что от него хотят и упростит это выражение. Скорее всего он всетаки будет делать вычитание через аккумулятор и займет это в лучшем случае в 9(!) раз больше памяти.
НЛО прилетело и опубликовало эту надпись здесь
Я Perl программист, я никогда не самовыражаюсь таким способом, мои коллеги тоже. Когда наша компания набирала программистов меня приглашали в качестве эксперта посмотреть на кандидатов.
Скажу сразу не приняли не одного :-).
Ибо 95% из них не знали даже элементарных вещей, а про перл имели крайне отдаленные представления(хотя в описании вакансии было четко и ясно написано «знание Perl, SQL»). Простые примеры вызывали лютую чудовищную, но безрезультатную работу мозга. Но даже те кто кое-как логически объяснял путь решения той или иной проблемы, заваливались на SQL опять же не зная основ.
Скажу сразу не приняли не одного :-).
Ибо 95% из них не знали даже элементарных вещей, а про перл имели крайне отдаленные представления(хотя в описании вакансии было четко и ясно написано «знание Perl, SQL»). Простые примеры вызывали лютую чудовищную, но безрезультатную работу мозга. Но даже те кто кое-как логически объяснял путь решения той или иной проблемы, заваливались на SQL опять же не зная основ.
знание SQL обычно нужно постольку-поскольку ибо есть ORM =) Я на ORM-фреймворке чего только не писал, а вот вручную написать это ни в жизни не смогу (и не захочу). Приоритеты операторов упрощаются их форсированием (скобочками). Если грамотно писать, то можно довести код до состояния когда ни одна из его особенностей не будет как-то сильно влиять на выполнение, и код будет примерно одинаково выглядеть и работать подо всеми общеупотребительными языками. На питоне вот только отступы вместо скобочек.
я перлом не увлекаюсь, только пхп.
а что за my? объявление переменной???
Я кстати тоже однажды устраивался пхп-кодером и мне выдали листок с кучей таких заданий, штук 30.
а что за my? объявление переменной???
Я кстати тоже однажды устраивался пхп-кодером и мне выдали листок с кучей таких заданий, штук 30.
Вообще я согласен с автором, по моему мнению, собеседование такого формата не самые лучшие.
Скажу сразу, эти вопросы меня поставили в некоторый тупик.
Особенно первый вопрос: «Вы знаете что такое use strict;?».
Честно, я не знал, что ответить, т.к. это звучало как издевательство, с учетом того, что они прекрасно знали о моем опыте.
Следующие вопросы, те, что написал автор, и много всякой фигни не в тему.
Я считаю, что данные примеры — элементы экстремального программирования, причем самые яркие и показательные. Именно примеры с подковыркой. Я с ходу на такие не отвечу, мои коллеги, тоже не ответили. Все потому, что так никто из нас никогда не пишет.
И я на 90 % уверен, что если человек с ходу на них (на эти вопросы) отвечает, что его код примерно так и выглядит. Все это конечно прикольно и здорово, но в большинстве случаев не решает главной задачи веб разработчиков; «Давать ЩАСТЬЕ пользователям». Это такие онанисты, которые дрочат на свой код и умиляются своей крутости. При этом сопровождение и поддержка этого кода им же осуществляется в несколько раз медленнее, так как ему тоже часто надо разобраться самому в своем говнокоде.
Я согласен на подобный код только в одном случае: когда этот код находится на уровне прототипа, причем прототипа, чей алгоритм отработан, вылизан и не подвержен изменениям. Только тогда можно в качестве развлечения поиграть в perl-гольф и бесконечно оптимизировать.
Очень обидно, что компания проводящая такого рода собеседования — это mail.ru (нефиг тут кривляться).
А еще более обидней, что проект, на который так набирают разработчиков — это «Единый школьный портал».
Это проект который предназначен в первую очередь для пользователей, уровня ниже среднего, причем заведомо ниже. Так как он будет обязательным для использования преподавателям всех предметов, а так же рекомендуемым для использования всем родителям школьников. Школьников — не считаем, им проще, они дети, быстро схватят все.
Первую реализацию «Единого школьного портала» все видели, все знают. Ждем очередную говнореализацию.
P.S. Я собеседование это проходил, но результатом не интересовался, для меня это была экскурсия в эту компанию.
P.P.S. Тут еще сказали что-то насчет Яндекса, что мол у них то же самое. Так вот нет, я у них на собеседовании тоже чай пил. В Яндексе мне задавали вопросы исключительно по реальным задачам, без абстракций.
Скажу сразу, эти вопросы меня поставили в некоторый тупик.
Особенно первый вопрос: «Вы знаете что такое use strict;?».
Честно, я не знал, что ответить, т.к. это звучало как издевательство, с учетом того, что они прекрасно знали о моем опыте.
Следующие вопросы, те, что написал автор, и много всякой фигни не в тему.
Я считаю, что данные примеры — элементы экстремального программирования, причем самые яркие и показательные. Именно примеры с подковыркой. Я с ходу на такие не отвечу, мои коллеги, тоже не ответили. Все потому, что так никто из нас никогда не пишет.
И я на 90 % уверен, что если человек с ходу на них (на эти вопросы) отвечает, что его код примерно так и выглядит. Все это конечно прикольно и здорово, но в большинстве случаев не решает главной задачи веб разработчиков; «Давать ЩАСТЬЕ пользователям». Это такие онанисты, которые дрочат на свой код и умиляются своей крутости. При этом сопровождение и поддержка этого кода им же осуществляется в несколько раз медленнее, так как ему тоже часто надо разобраться самому в своем говнокоде.
Я согласен на подобный код только в одном случае: когда этот код находится на уровне прототипа, причем прототипа, чей алгоритм отработан, вылизан и не подвержен изменениям. Только тогда можно в качестве развлечения поиграть в perl-гольф и бесконечно оптимизировать.
Очень обидно, что компания проводящая такого рода собеседования — это mail.ru (нефиг тут кривляться).
А еще более обидней, что проект, на который так набирают разработчиков — это «Единый школьный портал».
Это проект который предназначен в первую очередь для пользователей, уровня ниже среднего, причем заведомо ниже. Так как он будет обязательным для использования преподавателям всех предметов, а так же рекомендуемым для использования всем родителям школьников. Школьников — не считаем, им проще, они дети, быстро схватят все.
Первую реализацию «Единого школьного портала» все видели, все знают. Ждем очередную говнореализацию.
P.S. Я собеседование это проходил, но результатом не интересовался, для меня это была экскурсия в эту компанию.
P.P.S. Тут еще сказали что-то насчет Яндекса, что мол у них то же самое. Так вот нет, я у них на собеседовании тоже чай пил. В Яндексе мне задавали вопросы исключительно по реальным задачам, без абстракций.
Если я как вообще «не перловик» этот тест понял, даже без раздумий,
то они искали молодого студента или школьника на работу в течении годика или проекта, пока не повзрослеет, и на маленький окладик, так сказать за портфолио)
то они искали молодого студента или школьника на работу в течении годика или проекта, пока не повзрослеет, и на маленький окладик, так сказать за портфолио)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что меня спрашивали на собеседовании