Google Recruiter

[Интеррапт]

Easbayguy

[fruit6]

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

ага, типа "а у вас нет вакансий? у меня есть знакомый, гениальный программист" (типичный базар с использованием комбинации "гениальный программист")

[Zorkus]

В гугле много разных интервьюиров с разными тараканами в голове. Еще обычно играет роль как вы быстро решаете задачи. Типа на atoi пол часа может оказаться много.

Я далеко не привередливый интервьюер, но если кандидат не напишет atoi за 5-10 минут (с поддержкой "минус" и с обработкой white spaces), то дальше разговаривать особо не о чем. Т.к. это задача вообще на пару минут и ограничена фактически только скоростью написания текста на доске.

Это все понятно, но мне лично крайне не нравятся интервьюверы которые задают такие задачки писать на интервью (тем более, на физической доске, рукой и физическим маркером). Они у меня идут на втором месте в хейт-листе после интервьюверов, которые дают очередь из 20 вопросов вида "чем отличается интерфейс от абстрактного класса", "в каких местах в Java может быть использован модификатор final", и подобное. Ну скажем так, можно натренироваться писать на доске задачки вида "отсортировать односвязный список на С в обратном порядке" за 1 минуту, но это не говорит особо о знаниях.

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

http://habrahabr.ru/post/112561/

И вот вполне годный ответ на нее

http://habrahabr.ru/post/112561/#comment_3605717

[crypto5]

В гугле много разных интервьюиров с разными тараканами в голове. Еще обычно играет роль как вы быстро решаете задачи. Типа на atoi пол часа может оказаться много.

Я далеко не привередливый интервьюер, но если кандидат не напишет atoi за 5-10 минут (с поддержкой "минус" и с обработкой white spaces), то дальше разговаривать особо не о чем. Т.к. это задача вообще на пару минут и ограничена фактически только скоростью написания текста на доске.

Это все понятно, но мне лично крайне не нравятся интервьюверы которые задают такие задачки писать на интервью (тем более, на физической доске, рукой и физическим маркером). Они у меня идут на втором месте в хейт-листе после интервьюверов, которые дают очередь из 20 вопросов вида "чем отличается интерфейс от абстрактного класса", "в каких местах в Java может быть использован модификатор final", и подобное. Ну скажем так, можно натренироваться писать на доске задачки вида "отсортировать односвязный список на С в обратном порядке" за 1 минуту, но это не говорит особо о знаниях.

А какие хорошие вопросы на интервью по вашему?

И вот вполне годный ответ на нее

http://habrahabr.ru/post/112561/#comment_3605717

Чистый вброс ))

[adda_]

В гугле много разных интервьюиров с разными тараканами в голове. Еще обычно играет роль как вы быстро решаете задачи. Типа на atoi пол часа может оказаться много.

Я далеко не привередливый интервьюер, но если кандидат не напишет atoi за 5-10 минут (с поддержкой "минус" и с обработкой white spaces), то дальше разговаривать особо не о чем. Т.к. это задача вообще на пару минут и ограничена фактически только скоростью написания текста на доске.

30 лет пишу код, а что такое atoi и уж тем более с поддержкой минусов и пробелов, не знаю..
Блин, как я низко пал!

[Zorkus]

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

Вот, например, хороший, годный вопрос (хотя и легко гуглиться, но если не гуглить - т.е. просить человека ответить на вопрос, имея только ноутбук со средой разработки и доками, но без инета - будет еще интереснее). По крайней мере мне он очень понравился). По глубине и развернутости ответа сразу отделяются те, кто имеет реальное понимание работы среды от тех, кто прочитал книжку типа "Cracking code interview: 100 алгоритмов, которые вы должны научиться писать вслепую на доске, и тогда интервьюверы вас полюбят и возьмут к себе":

http://www.coderanch.com/t/590180/Perfo ... lly-faster

Послал вам в личку еще пару примеров того, что я считаю хорошими вопросами по Java / JVM. Сорри, что пока в личку.

[adda_]

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

Вот, например, неплохой вопрос:
http://www.coderanch.com/t/590180/Perfo ... lly-faster

Послал вам в личку еще пару примеров того, что я считаю хорошими вопросами по Java / JVM.

На этот вопрос любой человек имеющий представление о том как сделан процессор (на уровне железа) легко ответит и без гугления..

[crypto5]

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

Вот, например, неплохой вопрос:
http://www.coderanch.com/t/590180/Perfo ... lly-faster

Послал вам в личку еще пару примеров того, что я считаю хорошими вопросами по Java / JVM.

Ну вот а любители atoi и инвертирования списков еще и проверяют умеете ли вы код писать ))

[Zorkus]

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

Вот, например, неплохой вопрос:
http://www.coderanch.com/t/590180/Perfo ... lly-faster

Послал вам в личку еще пару примеров того, что я считаю хорошими вопросами по Java / JVM.

На этот вопрос любой человек имеющий представление о том как сделан процессор (на уровне железа) легко ответит и без гугления..

На уровне железа хорошо, но вопрос еще на уровне Java. Забавный момент, что даже по такой постановке вопроса, многие люди начинают отвечать на него "Конечно быстрее, потому что ...1), 2), 3).".

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

[crypto5]

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

Вот, например, неплохой вопрос:
http://www.coderanch.com/t/590180/Perfo ... lly-faster

Послал вам в личку еще пару примеров того, что я считаю хорошими вопросами по Java / JVM.

На этот вопрос любой человек имеющий представление о том как сделан процессор (на уровне железа) легко ответит и без гугления..

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

[Zorkus]

Я предполагаю, что вы тему на кодеранче до конца прочитали ведь, да?

[Zorkus]

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

Вот, например, неплохой вопрос:
http://www.coderanch.com/t/590180/Perfo ... lly-faster

Послал вам в личку еще пару примеров того, что я считаю хорошими вопросами по Java / JVM.

На этот вопрос любой человек имеющий представление о том как сделан процессор (на уровне железа) легко ответит и без гугления..

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

Сейчас придут железячники и С++-ники и вас заклюют

[crypto5]

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

Вот, например, неплохой вопрос:
http://www.coderanch.com/t/590180/Perfo ... lly-faster

Послал вам в личку еще пару примеров того, что я считаю хорошими вопросами по Java / JVM.

На этот вопрос любой человек имеющий представление о том как сделан процессор (на уровне железа) легко ответит и без гугления..

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

Сейчас придут железячники и С++-ники и вас заклюют

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

[Zorkus]

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

Вот, например, неплохой вопрос:
http://www.coderanch.com/t/590180/Perfo ... lly-faster

Послал вам в личку еще пару примеров того, что я считаю хорошими вопросами по Java / JVM.

На этот вопрос любой человек имеющий представление о том как сделан процессор (на уровне железа) легко ответит и без гугления..

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

Сейчас придут железячники и С++-ники и вас заклюют

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

Так это adda сказал, что любой, знающий, как работает процессор, на этот вопрос легко ответит - вот он пусть и рассказывает Я-то подлый джавист.

[swimmer]

Сейчас придут железячники и С++-ники и вас заклюют

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

[dotcom]

Сейчас придут железячники и С++-ники и вас заклюют

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

Кэшь то как раз не важен. Важнее метод адресации. В random нам адрес надо загружать сам адрес перед чтением или записью. При последовательном доступе используем регистр и оффсет, который грузится один раз. Т.е., грубо говоря, несколько операций ldr r0, addr будут медленнее ldr r0, [r1, #offset] Ну и SIMD тоже можно вспомнить для порядка. На кеш я бы особо не рассчитывал. Не факт, что процессор будет грузить пачку последовательных слов в кешь на всякий пожарный. Зависит от размера участка памяти, блока предсказаний. Загрузка данных в кешь тоже имеет цену.

[adda_]

Сейчас придут железячники и С++-ники и вас заклюют

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

Кэшь то как раз не важен. Важнее метод адресации. В random нам адрес надо загружать сам адрес перед чтением или записью. При последовательном доступе используем регистр и оффсет, который грузится один раз. Т.е., грубо говоря, несколько операций ldr r0, addr будут медленнее ldr r0, [r1, #offset] Ну и SIMD тоже можно вспомнить для порядка. На кеш я бы особо не рассчитывал. Не факт, что процессор будет грузить пачку последовательных слов в кешь на всякий пожарный. Зависит от размера участка памяти, блока предсказаний. Загрузка данных в кешь тоже имеет цену.

Причем здесь кэш? В него один хрен надо будет записывать данные из той же памяти.
А так автоинкриментная выборка данных из памяти осуществляется одной командой. По крайней мере в нормальных процессорах..
Но с другой стороны для Жабы или дотнета, имхо где там всякие мемори менеджменты встроены которые запросто в любой момент могут повесить весь перформенс просто потому что им захотелось почистить память, эти рассуждения не имеют никакого смысла. Я не говорю уже о том что операционка занимается свопингом и где на самом деле находятся ваши данные (то ли в кэше, то ли в памяти, то ли в свап области на хардравйве) одному богу извсестно... И никакие тесты нихрена не помогут, потому что тест будет размером с гулькин хрен а реальная программа на порядки больше. И соответсвтенно как там все будет крутиться непонятно.
Эти рассуждения имеют смысл если кто то пишет что то на уровне ассемблера или максимум Си без плюсов для микропроцессоров где никакой операционки или минимум ее. А так - ну типа показать что вы крутой интервьюер..
Реальная оптимизация делается не на уровне адресации, а на уровне алгоритма. Ну скажем если кор функцию считать тупо в лоб или использовать быстрое преобразование Фурье (первое что пришло на ум).. И еще большая - на уровне системного анализа, когда можно ненужные финтифлюшки выкинуть в форточку.
Но крутые пацаны из гугла будут усилетнно требовать написания страндартных функций преобразования данных которые сто лет уже никто не пишет кроме студентов.

[adda_]

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

Вот, например, неплохой вопрос:
http://www.coderanch.com/t/590180/Perfo ... lly-faster

Послал вам в личку еще пару примеров того, что я считаю хорошими вопросами по Java / JVM.

Ну вот а любители atoi и инвертирования списков еще и проверяют умеете ли вы код писать ))

Тогда надо говорить досвидания. Потому что проверять умение писать код у человека который дцать лет его пишет глупо. За это время не умеющие писать код давно стали менеджерами.

[Интеррапт]

30 лет пишу код, а что такое atoi и уж тем более с поддержкой минусов и пробелов, не знаю..
Блин, как я низко пал!

Не важно, вам на интервью обьяснят, что такое atoi и попросят написать

[avitya]

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

Вот, например, неплохой вопрос:
http://www.coderanch.com/t/590180/Perfo ... lly-faster

Послал вам в личку еще пару примеров того, что я считаю хорошими вопросами по Java / JVM.

Ну вот а любители atoi и инвертирования списков еще и проверяют умеете ли вы код писать ))

Тогда надо говорить досвидания. Потому что проверять умение писать код у человека который дцать лет его пишет глупо. За это время не умеющие писать код давно стали менеджерами.

Вы невероятно неправы в этом.

[dotcom]

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

Уважаемый, вы бы сначала почитали внимательно, что я писал и по поводу чего. Любовь к процессорному кэшу показывают другие участники форума. Они правы в том, что блок предсказания "видит", откуда и куда будет писать цикл, поэтому погут делать prefetch памяти в кешь или писать напрямую в кешь с lazy writing последовательных блоков данных. Это не rocket science. Во-вторых, автоинкрементная выборка, как это вас не удивит, в "нормальных" процессорах со времен PDP-11 и Motorola 68k отсутсвует. По крайней мере в вышеупоминаемом ARM ее просто нет. Нет его и в классическом x86. SIMD - это другое дело. Однако выборка с оффсетом через регистр все равно быстрее в последовательных обращениях к памяти, чем "random" с загрузкой нового адреса в регистр или буфер исполнителя (при прямой адресации), т.к. сам адрес требуется еще считать откуда-то. Оффсет для регистровых операций уже сидит в кеше исполнителяющего модуля после предыдущего выполнения той же команды, но с другим значением регистра.

[dotcom]

Тогда надо говорить досвидания. Потому что проверять умение писать код у человека который дцать лет его пишет глупо. За это время не умеющие писать код давно стали менеджерами.

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

[Zorkus]

Сейчас придут железячники и С++-ники и вас заклюют

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

Кэшь то как раз не важен. Важнее метод адресации. В random нам адрес надо загружать сам адрес перед чтением или записью. При последовательном доступе используем регистр и оффсет, который грузится один раз. Т.е., грубо говоря, несколько операций ldr r0, addr будут медленнее ldr r0, [r1, #offset] Ну и SIMD тоже можно вспомнить для порядка. На кеш я бы особо не рассчитывал. Не факт, что процессор будет грузить пачку последовательных слов в кешь на всякий пожарный. Зависит от размера участка памяти, блока предсказаний. Загрузка данных в кешь тоже имеет цену.

Причем здесь кэш? В него один хрен надо будет записывать данные из той же памяти.
А так автоинкриментная выборка данных из памяти осуществляется одной командой. По крайней мере в нормальных процессорах..
Но с другой стороны для Жабы или дотнета, имхо где там всякие мемори менеджменты встроены которые запросто в любой момент могут повесить весь перформенс просто потому что им захотелось почистить память, эти рассуждения не имеют никакого смысла. Я не говорю уже о том что операционка занимается свопингом и где на самом деле находятся ваши данные (то ли в кэше, то ли в памяти, то ли в свап области на хардравйве) одному богу извсестно... И никакие тесты нихрена не помогут, потому что тест будет размером с гулькин хрен а реальная программа на порядки больше. И соответсвтенно как там все будет крутиться непонятно.
Эти рассуждения имеют смысл если кто то пишет что то на уровне ассемблера или максимум Си без плюсов для микропроцессоров где никакой операционки или минимум ее. А так - ну типа показать что вы крутой интервьюер..
Реальная оптимизация делается не на уровне адресации, а на уровне алгоритма. Ну скажем если кор функцию считать тупо в лоб или использовать быстрое преобразование Фурье (первое что пришло на ум).. И еще большая - на уровне системного анализа, когда можно ненужные финтифлюшки выкинуть в форточку.
Но крутые пацаны из гугла будут усилетнно требовать написания страндартных функций преобразования данных которые сто лет уже никто не пишет кроме студентов.

Вот именно. А главное что лекцию по адресации в CPU мы услышали, а ответа на простой (как тут сказали, для любого, знакомого с работой процессора) вопрос, который я предложил - нет Вопрос звучал почему в Java рандомный доступ к массиву интов из 1000 элементов (каждое слово matters) существеннее медленнее, чем последовательный. Боюсь, что некоторые на самом деле стали объяснять, почему он быстрее


"

[dotcom]

Вот именно. А главное что лекцию по адресации в CPU мы услышали, а ответа на простой (как тут сказали, для любого, знакомого с работой процессора) вопрос, который я предложил - нет Вопрос звучал почему в Java рандомный доступ к массиву интов из 1000 элементов (каждое слово matters) существеннее медленнее, чем последовательный. Боюсь, что некоторые на самом деле стали объяснять, почему он быстрее

И где вы нашли в вышесказанном, что random access медленнее? Ась?

[Zorkus]

Вот именно. А главное что лекцию по адресации в CPU мы услышали, а ответа на простой (как тут сказали, для любого, знакомого с работой процессора) вопрос, который я предложил - нет Вопрос звучал почему в Java рандомный доступ к массиву интов из 1000 элементов (каждое слово matters) существеннее медленнее, чем последовательный. Боюсь, что некоторые на самом деле стали объяснять, почему он быстрее

И где вы нашли в вышесказанном, что random access медленнее? Ась?

Так медленнее или не медленнее? Да или нет?