Google Recruiter

[Zorkus]

Кстати, может кто-нибудь еще приведет интересные (на его взгляд) вопросы для интервью

[fruit6]

интересные для кого? для Вас, для кандидата?

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

[АццкоМото]

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

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

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

хмм. я вот не могу что-то проверять параллельно с телефонным разговором. если только интервьюер дает время и замолкает нафиг на 10 минут. даже элементарные вещи не могу

Психологический аспект (в том, подвергнет ли человек сомнению слова интервьювера, или будет отвечать на вопрос так, как он поставлен "быстрее, потому что 1) a 2) b 3) c) важен, показывает умение не поддаваться на ложную авторитетность. Но даже если его опустить, и задавать вопрос в виде "как вы думаете, будет ли рандомный доступ быстрее или медленнее, или таким же по скорости, для данного примера" - вопрос все равно будет интересным. Его можно упростить, задав наводящие вопросы вида "а если бы массив был не интов. а String[], как бы изменилось поведение?" и прочие. Но это уже вариации.

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

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

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

[dotcom]

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

Да вот уже давно руки чешутся разобраться с JVM. Кстати, забавно ведь получается. Забавная вещь ведь получается с проверкой на нижнюю границу. Был бы unsigned в Java - все было бы проще. Ведь даже signed к unsigned не сконвертируешь, чтобы одной проверкой обойтись.

[АццкоМото]

Да вот уже давно руки чешутся разобраться с JVM. Кстати, забавно ведь получается. Забавная вещь ведь получается с проверкой на нижнюю границу. Был бы unsigned в Java - все было бы проще. Ведь даже signed к unsigned не сконвертируешь, чтобы одной проверкой обойтись.

char - двухбайтное беззнаковое целое

[Alexandr]

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

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

мой ответ был на вот это сообщение

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

смысл моего сообщения был в том, что безотносительно языка этот вопрос имеет смысл, потому что вопрос о понимании среды в которой происходит разработка и эксплуатация систем
что касается жабы, то проход по массиву снегерит примерно такой же код, какой сгенерировал бы С\С++, т.е. буду проявляться абсолютно те же паттерны, поэтому выражение adda_ "Если для задачи критично время доступа к элементу массива размером в 1000 штуков то надо использовать какой то другой язык вместо Жабы" бесмысленно, а соответственно с кругозором Зоркуса все в норме и я согласен с ним, что такие вопросы на жаба интервью задавать можно

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

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

[Alexandr]

mov eax, const - вообще никакого обращения к памяти, константа лежит как часть инструкции (mov + immidiate)

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

Prefetcher контролируется branch/execution prediction модулем.

это совсем совсем не правда, префетчер вообще никакого отношения не имеет к branch prediction

Замечательные prefetcher'ы делают, если они загружают шину трафиком независимо от того, что нужно процессору.

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

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

Замечательные prefetcher'ы делают, если они загружают шину трафиком независимо от того, что нужно процессору.

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

[Alexandr]

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

да ладно вам, нормальные же вопросы, не?

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

[АццкоМото]

поэтому выражение adda_ "Если для задачи критично время доступа к элементу массива размером в 1000 штуков то надо использовать какой то другой язык вместо Жабы" бесмысленно

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

[Alexandr]

поэтому выражение adda_ "Если для задачи критично время доступа к элементу массива размером в 1000 штуков то надо использовать какой то другой язык вместо Жабы" бесмысленно

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

мысль adda_ не верна, так как данные, которые нужно обработать могут быть существенно больше, чем 1000 интов, и там уже будут далеко не 7 микросекунд, а гораздо больше, во вторых я уже писал выше почему никаким сборщиком мусора мы прерваны не будем

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

именно! и эта задача по сути задача о структурах данных

[Zorkus]

интересные для кого? для Вас, для кандидата?

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

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

[Zorkus]

хмм. я вот не могу что-то проверять параллельно с телефонным разговором. если только интервьюер дает время и замолкает нафиг на 10 минут. даже элементарные вещи не могу

+1, я сам в реалтайме не люблю такие вещи делать. Такое вопрос можно или дать в оффлайн, попросив перезвонить или ответить скажем через полчаса, или как закончит человек, или на живом интервью дав ему ноут (или заранее попросить принести свой с IDE) и посадить в уголке поковыряться.

[valchkou]

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

сколько вам нужно, чтобы вы захотели у нас работать?

[Zorkus]

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

сколько вам нужно, чтобы вы захотели у нас работать?

Тогда может быть - "Мы предлагаем вам 300к в год, этого хватит, или добавить еще столько же?"

[АццкоМото]

мысль adda_ не верна, так как данные, которые нужно обработать могут быть существенно больше, чем 1000 интов, и там уже будут далеко не 7 микросекунд, а гораздо больше, во вторых я уже писал выше почему никаким сборщиком мусора мы прерваны не будем

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

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

именно! и эта задача по сути задача о структурах данных

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

[scorpion]

Кстати, может кто-нибудь еще приведет интересные (на его взгляд) вопросы для интервью

Для поддержания разговора за жизнь попросить "извлечь" кубический корень из семи с более или менее приличной точностью (под настроение интервьюера-ирода)

[olis]

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

Там смещение либо регистр включен прямо в тело команды, так что никакого предсказания, похоже, нет.
Я смотрел на стр 4-26 http://cseweb.ucsd.edu/~kastner/cse30/a ... ionset.pdf

В общем для меня совершенно не очевидно что последовательный доступ всегда будет быстрее случайного.

Что несколько LDR операций с автоинкрементом базы , что то же количество LDR с той же базой но разным immediate offset займет одинаковое время (1S + 1N + 1I) * кол-во операций (по вашей же ссылке)
Другое дело burst memory read блока памяти в несколько регистров командой LDM. В этом случае будут использоваться sequential cycles
http://infocenter.arm.com/help/index.js ... badhj.html

По моему так.

[Zorkus]

Кстати, может кто-нибудь еще приведет интересные (на его взгляд) вопросы для интервью

Для поддержания разговора за жизнь попросить "извлечь" кубический корень из семи с более или менее приличной точностью (под настроение интервьюера-ирода)

Я надеюсь вы такие разговоры за жизнь ведете редко Примерно 1.87 будет думаю.

[Alexandr]

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

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

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

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

сами то проводите интервью? что спрашиваете?

[scorpion]

Примерно 1.87 будет думаю.

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

[fruit6]

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

сколько вам нужно, чтобы вы захотели у нас работать?

Тогда может быть - "Мы предлагаем вам 300к в год, этого хватит, или добавить еще столько же?"

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

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

[valchkou]

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

сколько вам нужно, чтобы вы захотели у нас работать?

Тогда может быть - "Мы предлагаем вам 300к в год, этого хватит, или добавить еще столько же?"

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

[АццкоМото]

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

А мы что, в одном потоке по определению? Да и опять же, какая разница, будет ли прерван проход по массиву, суть все равно та же - 7 миркосекунд экономим тут, 7 миллисекунд теряем там. Никакого смысла и все абсолютно непредсказуемо. А как только мы начинаем думать про то, что массив может быть на 1000, а мульен или мульярд элементов, так сразу встает вопрос, а нужен ли нам именно массив? А не можем ли мы какие-то промежуточные данные подсчитывать прямо во время заполнения массива данными? И так далее

сами то проводите интервью? что спрашиваете?

я провел пару сотен энторвью в России, но там достаточно просто убедиться, что чел адекватен: в 99% случаев достаточно просто попросить рассказать про свой опыт и задать пяток-десяток уточняющих вопросов, чтобы убедиться, что опыт не придуманный и чел примерно понимает, о чем говорит. ну и иногда слово за слово если услышалось что-то интересное. а, коронный вопрос был: если чел заявляет, что говорит или пишет по-английски, перевести "идет дождь". вот это ржака была. у 80% кандидатов такие судороги наступают, что только на заржать
в Штатах я проводил только 3 энторвью на одну позицию, но это ондроед в гей эрии консалтить на хорошую компанию через плохую. соответственно, вероятность найти хорошего чела - чуть ниже нуля. фактически решение можно было принимать по одному вопросу: как одно приложение может расшарить данные с другим. двое с "многолетней экспертизой в ондроеде" не смогли выжать ничего. остальные вопросы уже так - для порядка, ибо понятно сразу, что ондроед эти эксперты видели по телевизору
третий смог, его и взяли. но тоже мягко говоря так себе чел, но на безрыбье и щуку раком
в общем, никаких тонкостей

[АццкоМото]

Примерно 1.87 будет думаю.

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

В гугле, на калькуляторе и в экселе? Я могу, да

[Zorkus]

Примерно 1.87 будет думаю.

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

Ааа я сначала подумал не численным метод поиска написать с заданной точностью, а в уме посчитать и сразу ответить Shame on me.