Комментарии 74
А что за компания или чем вы занимались?
Требования и вопросы сильные, и, хотя, вряд ли они были заданы джуниору-мидлу, но востребованы ли они родом деятельности?
Требования и вопросы сильные, и, хотя, вряд ли они были заданы джуниору-мидлу, но востребованы ли они родом деятельности?
Стоит отметить, что это не полный список вопросов, который задаём, и не факт, что будем задавать вообще что-то из какой-то темы.
Задаём вопросы и junior-ам, и отвечают, и здесь больше хочется понять, как кандидат ведет себя тогда, когда попадает за границы области своей компетентности.
Что касается востребованы — что-то непосредственно востребовано, что-то скорее модельное в виде сильно упращённого тем, чем занимались.
Задаём вопросы и junior-ам, и отвечают, и здесь больше хочется понять, как кандидат ведет себя тогда, когда попадает за границы области своей компетентности.
Что касается востребованы — что-то непосредственно востребовано, что-то скорее модельное в виде сильно упращённого тем, чем занимались.
Могу предположить: Deutsche Bank.
Да, ЛинкедИн выдал человека с потрохами :)
Но мой вопрос в основном о востребованности знаний.
Понятно, что люди хотят посмотреть будущего сотрудника в нестандартных ситуациях, но, в то же время, тема алгоритмов и прочего теоретического материала сейчас весьма популярна, и, хоть и используется очень редко, к собеседованиям приходится её изучить, что занимает драгоценное время.
А людям, которые и так их знают, вполне может быть не комфортно на той работе, где эти знания не нужны.
В итоге получается, что если эти знания не востребованы, то поиск работы и сотрудников можно грубо приравнять к похожей на флирт игре.
Но мой вопрос в основном о востребованности знаний.
Понятно, что люди хотят посмотреть будущего сотрудника в нестандартных ситуациях, но, в то же время, тема алгоритмов и прочего теоретического материала сейчас весьма популярна, и, хоть и используется очень редко, к собеседованиям приходится её изучить, что занимает драгоценное время.
А людям, которые и так их знают, вполне может быть не комфортно на той работе, где эти знания не нужны.
В итоге получается, что если эти знания не востребованы, то поиск работы и сотрудников можно грубо приравнять к похожей на флирт игре.
Моей задачей был не PR, а рассказать о интервью подробней.
Я бы не сказал, что знания алгоритмов и прочей теории востребовано на 100% каждый день, но такие задачи возникают периодически — будет как-то неловко, когда надо решать какую-то проблему, а знаний и понимания нет. С другой стороны мы не спрашиваем педантично как именно, допустим работает j.u.HashMap как солится hashCode, скорее в общих чертах.
Я бы не сказал, что знания алгоритмов и прочей теории востребовано на 100% каждый день, но такие задачи возникают периодически — будет как-то неловко, когда надо решать какую-то проблему, а знаний и понимания нет. С другой стороны мы не спрашиваем педантично как именно, допустим работает j.u.HashMap как солится hashCode, скорее в общих чертах.
«Среди первых всегда возникает вопрос — почему решили именно работать в нашей компании?»
потому что _Вы_ меня позвали? я никогда не понимал этот идиотский вопрос.
потому что _Вы_ меня позвали? я никогда не понимал этот идиотский вопрос.
Я бы тоже понял вопрос, если бы это была компания уровня Гугла, Фейсбука, или любого другого гиганта в своей области.
Развивая эту тему — много ли вы можете перечислить компаний подобного уровня, которые имеют свои центры разработки в России? И удельная доля людей из сектора IT, которая работает там?
Я из Украины, но сразу в голову приходят Google, Яндекс, Mail.ru, Вконтакте.
Я ни в коем случае не пытаюсь унизить компанию, в которой вы работали, но собеседование — это диалог, и ожидая различных вопросов на собеседовании, хотелось бы, чтобы компания имела аргументацию задавать такие вопросы, не считая желания выбрать кандидата посильнее для перекладывания данных из формочки в базу данных и обратно(да-да, именно этим я занимался большую часть своей карьеры разработчика).
Я ни в коем случае не пытаюсь унизить компанию, в которой вы работали, но собеседование — это диалог, и ожидая различных вопросов на собеседовании, хотелось бы, чтобы компания имела аргументацию задавать такие вопросы, не считая желания выбрать кандидата посильнее для перекладывания данных из формочки в базу данных и обратно(да-да, именно этим я занимался большую часть своей карьеры разработчика).
Если вы ходите по собеседованиям просто потому что «позвали» — то это и есть ваш честный ответ на такой вопрос. Если же вам кажется, что это не тот ответ, который добавит вам плюсов в глазах собеседующих — возможно, это и так, а возможно и нет — все зависит от того, кого люди ищут.
Мое личное мнение — специалист действительно высокого уровня знает, где он хочет специализироваться, и сам выбирает, куда ему идти пробоваться. И не по принципу «какие компании на слуху», а по принципу «чем я действительно хочу заниматься, и где этим занимаются». И у такого специалиста найдется ответ на этот вопрос.
Нет ничего плохого в том, что вы ищете работу просто по критерию «где я буду продавать свое время за деньги». Но и больших плюсов в глазах работодателя в этом тоже нет (как правило). Действительно сложную работу невозможно делать хорошо только за зарплату — нужно, чтобы у человека была какая-то внутренняя мотивация эту работу делать. Поэтому на сложную задачу предпочтут взять пассионария, ясно понимающего зачем для самого себя он это хочет делать — нежели карьериста.
Мое личное мнение — специалист действительно высокого уровня знает, где он хочет специализироваться, и сам выбирает, куда ему идти пробоваться. И не по принципу «какие компании на слуху», а по принципу «чем я действительно хочу заниматься, и где этим занимаются». И у такого специалиста найдется ответ на этот вопрос.
Нет ничего плохого в том, что вы ищете работу просто по критерию «где я буду продавать свое время за деньги». Но и больших плюсов в глазах работодателя в этом тоже нет (как правило). Действительно сложную работу невозможно делать хорошо только за зарплату — нужно, чтобы у человека была какая-то внутренняя мотивация эту работу делать. Поэтому на сложную задачу предпочтут взять пассионария, ясно понимающего зачем для самого себя он это хочет делать — нежели карьериста.
Логично. я знаю где я хочу специализироваться. Мне приходит отклик. Я смотрю вакансию. Написано то что мне интересно. Я иду. Но эта конкретная компания мне не известна. Попал так на свою нынешнюю работу. Оказался крутой интегратор, интересные проекты по тем направлениям что мне интересны. чяднт?
Если вы шли в эту компанию потому, что увидели направление А, Б и Жо в их вакансии, а вы ищете работу как раз с этими направлениями — разве это не является ответом на вопрос «почему именно к нам»? «Я ищу такие-то вещи, у вас они — по крайней мере в вакансии — есть, вот и пришел к вам сориентироваться на месте».
Вы думаете, что от вас ждут ответа в духе «вы крупная и перспективная, динамично развивающаяся компания с твердыми лидирующими позициями на мировом рынке»? — да побойтесь бога, техническим специалистам все эти маркетинговые изыски глубоко параллельны.
Вы думаете, что от вас ждут ответа в духе «вы крупная и перспективная, динамично развивающаяся компания с твердыми лидирующими позициями на мировом рынке»? — да побойтесь бога, техническим специалистам все эти маркетинговые изыски глубоко параллельны.
Согласитесь, далеко не всегда именно так происходит — не редкость, когда кандидаты приходят по рекомендации знакомых или тех, кто работает.
Вы знаете, на раннем этапе своей карьеры мне тоже этот вопрос казался глупо-пафосным — потому что я ходил на те собеседования, на которые звали.
Сейчас он мне уже не кажется глупым — потому что я реже хожу «куда позвали», и чаще туда, где я бы хотел работать — т.е, как минимум, у меня есть какие-то причины предполагать, что я хотел бы работать именно здесь. И я с удовольствием расскажу людям об этих причинах, и послушаю, что они мне скажут в ответ на мои фантазии.
Сейчас он мне уже не кажется глупым — потому что я реже хожу «куда позвали», и чаще туда, где я бы хотел работать — т.е, как минимум, у меня есть какие-то причины предполагать, что я хотел бы работать именно здесь. И я с удовольствием расскажу людям об этих причинах, и послушаю, что они мне скажут в ответ на мои фантазии.
Подкину не дающий мне покоя вопрос в тему. Есть кандидаты, прекрасно пишущие Фибоначчи на доске, но когда они приняты на работу и им надо разобраться в имеющемся коде, понять где именно вон то ломается и почему, они сидят неделю, бормочат на дейли скрамах что пока не нашли решение, в итоге приходится их задачу передавать коллегам с исследовательскими задатками.
Что вы спрашиваете на собеседованиях, чтобы понять, насколько хорошо и быстро человек способен разобраться в незнакомом коде/среде/продукте, проявить инициативу и найти решение проблемы?
Что вы спрашиваете на собеседованиях, чтобы понять, насколько хорошо и быстро человек способен разобраться в незнакомом коде/среде/продукте, проявить инициативу и найти решение проблемы?
Хороший вопрос. Толково и правдиво узнать это за время собеседования не реалистично, тем более, что вы говорите, что не может разобраться неделю.
Обычно в процесс вливания новичка в команду ему много что объясняется, показывается, даются не убийственные задачи по проекту, и стараемся объяснить что и как, если не понятно. О том, что у человека есть проблемы или нет стараемся держать на уровне часов, а не дней и тем более не недель.
Обычно в процесс вливания новичка в команду ему много что объясняется, показывается, даются не убийственные задачи по проекту, и стараемся объяснить что и как, если не понятно. О том, что у человека есть проблемы или нет стараемся держать на уровне часов, а не дней и тем более не недель.
Это понятно, но человек должен уметь самостоятельно решать проблемы, а не потыкать и развести руками. Этот скил — наверное самый важный, ибо выучить очередной язык программирования можно, а вот научиться решать проблемы — наверное нет. Нет ли какой-то модельной задачи для собеседования, выявляющей этот скил?
Решать проблемы и копаться в чужом коде это все-таки немного разные уровни вопроса. Скилл решать проблемы мы проверяем усложняя кандидату задачу до предела его способностей. В простейшую задачу вычисления Фибоначчи можно поднакидать real-life issues столько, что никто не сможет решить все и одновременно — отличная возможность посмотреть, как человек умеет простраивать технические компромиссы.
А копаться в чужом коде — это конкретная область применения навыка решения проблем. Как я уже писал, мое мнение, что это вопрос больше мотивации — человек просто не ощущает достаточной мотивации чинить чужой код, потому что не видит, как это связано с его собственными персональными целями.
Это я прежде всего по своему собственному опыту говорю — я считаю себя довольно неплохим problem solver-ом, но я несколько раз сталкивался с ситуацией, когда мозг просто отказывается даже начинать решать задачу «как починить этот адовый пи#$ец». Это происходит тогда, когда, по моей личной интуитивной оценке (которая, конечно, может не совпадать с оценкой руководства проекта) починка этой конкретной проблемы просто пустая трата времени, потому что ситуация в целом настолько поганая, что ложка меда только ухудшит общий вкус бочки дегтя.
А копаться в чужом коде — это конкретная область применения навыка решения проблем. Как я уже писал, мое мнение, что это вопрос больше мотивации — человек просто не ощущает достаточной мотивации чинить чужой код, потому что не видит, как это связано с его собственными персональными целями.
Это я прежде всего по своему собственному опыту говорю — я считаю себя довольно неплохим problem solver-ом, но я несколько раз сталкивался с ситуацией, когда мозг просто отказывается даже начинать решать задачу «как починить этот адовый пи#$ец». Это происходит тогда, когда, по моей личной интуитивной оценке (которая, конечно, может не совпадать с оценкой руководства проекта) починка этой конкретной проблемы просто пустая трата времени, потому что ситуация в целом настолько поганая, что ложка меда только ухудшит общий вкус бочки дегтя.
Лично я — никак не проверяю.
Мне кажется, если человек показал себя умеющим думать, но не может разобраться в незнакомом коде/среде/продукте — это вопрос мотивации а не способностей. Человек не хочет этим заниматься, вот и все. Вопросы мотивации — это вопросы project screening-а больше, хотя, конечно, мы на tech-screening стараемся примерно обрисовать кандидату возможные области работы.
Мне кажется, если человек показал себя умеющим думать, но не может разобраться в незнакомом коде/среде/продукте — это вопрос мотивации а не способностей. Человек не хочет этим заниматься, вот и все. Вопросы мотивации — это вопросы project screening-а больше, хотя, конечно, мы на tech-screening стараемся примерно обрисовать кандидату возможные области работы.
1) Я, конечно, не ваш кандидат, но можно поподробнее про проблему голландского флага?
Вроде бы у Дейкстры это «просто задачка», без философии глубинной проблемы быстрой сортировки.
2) А почему вы настойчиво спрашиваете про справочные данные? И живой опыт.
Справочные данные скорее знают джуниоры («свежебывшие» студенты), а живой опыт — сеньоры, почти что взаимоисключающие параграфы.
Паркинсона почитали?
Вроде бы у Дейкстры это «просто задачка», без философии глубинной проблемы быстрой сортировки.
2) А почему вы настойчиво спрашиваете про справочные данные? И живой опыт.
Справочные данные скорее знают джуниоры («свежебывшие» студенты), а живой опыт — сеньоры, почти что взаимоисключающие параграфы.
Паркинсона почитали?
«Сколько будет 2*2? — Я что, все константы помнить обязан?»
Что для вас «справочные данные», которые помнят только юниоры?
Что для вас «справочные данные», которые помнят только юниоры?
«т.н. проблема национального голландского флага.»
«и какие бывают коллекции, и какие контракты использования»
«поиск в hash структурах делался с использованием простых чисел,»
«Gang of Four»
Я всем эти интересовался только в студенчестве. А в бою было проще — почему не пользовать TTable, как тестировать, взаимоотношения блокировок, правила VISA, как заставить DAC работать в филиале на Win95, какие ошибки ввода пользователя к чему приводят в конкретных ситуациях, как структурировать поток заявок подрядчику, нахера нам X.25, и прочие критичные и некритичные знания, которые в универах не проходят, и универы вообще не знают. Зато очень ценилось умение быстро разобраться на практичном уровне. К слову, пятитомник правил VISA я и не читал «от корки до корки». Времени не было.
И поток практики быстро и напрочь смывает универскую справочную инфу из головы.
Остаётся только тщательно воспитанная универом вера в то, что справочники, солюшны и кейсы «где-то есть» и умение раздобыть и усвоить инфу в требуемые сроки.
«и какие бывают коллекции, и какие контракты использования»
«поиск в hash структурах делался с использованием простых чисел,»
«Gang of Four»
Я всем эти интересовался только в студенчестве. А в бою было проще — почему не пользовать TTable, как тестировать, взаимоотношения блокировок, правила VISA, как заставить DAC работать в филиале на Win95, какие ошибки ввода пользователя к чему приводят в конкретных ситуациях, как структурировать поток заявок подрядчику, нахера нам X.25, и прочие критичные и некритичные знания, которые в универах не проходят, и универы вообще не знают. Зато очень ценилось умение быстро разобраться на практичном уровне. К слову, пятитомник правил VISA я и не читал «от корки до корки». Времени не было.
И поток практики быстро и напрочь смывает универскую справочную инфу из головы.
Остаётся только тщательно воспитанная универом вера в то, что справочники, солюшны и кейсы «где-то есть» и умение раздобыть и усвоить инфу в требуемые сроки.
Всё больше прихожу к выводу, что программирование / информатика разрозлись к нынешнему моменту настолько, что подобное собеседование может разве что выявить степень близости интеллектуальных путей собеседующего и собеседуемого. Ну и отсечь полных обалдуев, которые не знают, чем регистр отличается от реестра, а хэширование от кэширования.
Конечно, можно утверждать, что всегда есть некий общий фундамент — алгоритмы, структуры данных, основы языков программирования. Всё так, без этого фундамента хорошее здание не построишь, но начиная с какого-то момента ты постоянно живёшь на четвёртом-пятом этаже этого здания, вниз спускаешься лишь изредка, а уж как фундамент выглядит, лучше не спрашивайте.
Причём планомерное развитие всё больше отдаляет от фундамента. Ну да, хорошо бы помнить, что быстрая сортировка может «провалиться» до O(N*N), а хэширование по умолчанию тоже не всегда годится. А чему нас учат книги «для продвинутых»? Не оптимизируй раньше времени! Сначала профилируй. Я вот не помню, когда в последний раз у меня бутылочным горышком оказалось хэширование или быстрая сортировка. Соответственно, и думать о них не приходится. Ну или мониторы в Java. Добрый день, с какой радости мне в 2013 году пользоваться мониторами из Java 1, если в Java 5 появились высокоуровневые средства работы с потоками, да и раньше сторонние библиотеки существовали.
Конечно, можно утверждать, что всегда есть некий общий фундамент — алгоритмы, структуры данных, основы языков программирования. Всё так, без этого фундамента хорошее здание не построишь, но начиная с какого-то момента ты постоянно живёшь на четвёртом-пятом этаже этого здания, вниз спускаешься лишь изредка, а уж как фундамент выглядит, лучше не спрашивайте.
Причём планомерное развитие всё больше отдаляет от фундамента. Ну да, хорошо бы помнить, что быстрая сортировка может «провалиться» до O(N*N), а хэширование по умолчанию тоже не всегда годится. А чему нас учат книги «для продвинутых»? Не оптимизируй раньше времени! Сначала профилируй. Я вот не помню, когда в последний раз у меня бутылочным горышком оказалось хэширование или быстрая сортировка. Соответственно, и думать о них не приходится. Ну или мониторы в Java. Добрый день, с какой радости мне в 2013 году пользоваться мониторами из Java 1, если в Java 5 появились высокоуровневые средства работы с потоками, да и раньше сторонние библиотеки существовали.
Согласен, и злостных обалдуев тоже надо отсчечь, и всё же понять насколько фундамент прочен — я уже приводил аналогию про инженера-автомобилестроителя.
И давайте про мониторы не будем, не о том статья — ведь на дворе 2013 год и ой как многое было сделано.
И давайте про мониторы не будем, не о том статья — ведь на дворе 2013 год и ой как многое было сделано.
Согласен, но всё равно сложно. Вот взять ваш пример с сортировкой очень большого файла. Мне никогда не приходилось заниматься сортировкой такого файла, который не влезет в современную оперативную память.
Соответственно, моих инженерных навыков и информации с подкорки студенческих времён хватит на то, чтобы сообразить:
1) Нельзя просто взять и применить quicksort.
2) Если нет серьёзных ограничений, проще взять готовую базу данных, сунуть свои данные туда и пусть сортирует как умеет.
3) Если (2) не годится, надо почитать книжку Вирта «Алгоритмы и структуры данных», в которой такой пример разбирался. Но в чём конкретно был алгоритм — не помню. Что-то связанное с лентами.
Может, вас такой ответ и устроит. А может, скажете, что фундамент слаб. Тоже не поймёшь, чем интервьюер удовлетворится :)
Соответственно, моих инженерных навыков и информации с подкорки студенческих времён хватит на то, чтобы сообразить:
1) Нельзя просто взять и применить quicksort.
2) Если нет серьёзных ограничений, проще взять готовую базу данных, сунуть свои данные туда и пусть сортирует как умеет.
3) Если (2) не годится, надо почитать книжку Вирта «Алгоритмы и структуры данных», в которой такой пример разбирался. Но в чём конкретно был алгоритм — не помню. Что-то связанное с лентами.
Может, вас такой ответ и устроит. А может, скажете, что фундамент слаб. Тоже не поймёшь, чем интервьюер удовлетворится :)
Побойтесь бога!
Какие ещё базы данных. Зачем атомной бомбой гвозди-то забивать?
Какие ещё базы данных. Зачем атомной бомбой гвозди-то забивать?
0) Да, файл неимоверно большой 64Гб, оперативки 16Гб
1) Какие у quick sort есть ограничения? В чём его слабость, если мы говорим о его специфике применения к данной задач?
Словом, хочется, чтобы кандидат сделал анализ, посмотрел, покрутил и подумал — и вот его размышения и соображения интересны — это если мы говорим про очное интервью.
Если же домашнее задание… когда у человека есть и google, и wikipedia, и всё на свете — и он не может решить — я с вами согласен — он обалдуй и оболтус — и таких надо гнать.
1) Какие у quick sort есть ограничения? В чём его слабость, если мы говорим о его специфике применения к данной задач?
Словом, хочется, чтобы кандидат сделал анализ, посмотрел, покрутил и подумал — и вот его размышения и соображения интересны — это если мы говорим про очное интервью.
Если же домашнее задание… когда у человека есть и google, и wikipedia, и всё на свете — и он не может решить — я с вами согласен — он обалдуй и оболтус — и таких надо гнать.
А дополнительное место на диске есть (и сколько)? Или надо сортировать прямо по месту?
Кстати, спасибо за идею. То, что можно в этих условиях применить quicksort, двигаясь по файлу двумя окнами, я пока не осознавал — думал, что без многих файлов и слияния не обойтись.
А не утомиться ли дисковая система бегать туда-сюда в начало-конец файла перемещая элементы относительно опорной точки?
Прочитаю 6 ГБ с начала, и столько же с конца. Выберу из них какой-нибудь разделяющий элемент и начну тасовать элементы в памяти. Когда дойду до конца одного из этих буферов — скину его на диск и загружу следующие 6 ГБ — пока окна не сольются. Итого, на один проход уйдёт 11 чтений/записей буфера. Если на следующих этапах надо будет сортировать кусочек меньше 12 ГБ — сделаю это прямо в памяти. В общей сложности каждый фрагмент файла придётся прочитать/записать 4 раза (если не будет большого невезения) — не такая уж большая нагрузка.
Ok. И что это за сортировка?
Обычный quicksort. С ручной реализацией дополнительного уровня кэш-памяти (её роль играет RAM).
А теперь можете оценить его сложность? либо мне кажется, либо пахнет O(N2)
Оно полностью эквивалентно quicksort, все элементы перемещаются, как если бы массив целиком находился в памяти. Так что действительно, в худшем случае O(N^2).
Можно, конечно, считать файл кусочками по 13 ГБ, отсортировать, записать в 5 отдельных файлов, а потом сливать их. Но писать такое слияние, с буферизацией и на входе и на выходе — не самое приятное занятие. Объём общения с диском будет вдвое меньше, но потребуется дополнительное дисковое пространство.
Можно, конечно, считать файл кусочками по 13 ГБ, отсортировать, записать в 5 отдельных файлов, а потом сливать их. Но писать такое слияние, с буферизацией и на входе и на выходе — не самое приятное занятие. Объём общения с диском будет вдвое меньше, но потребуется дополнительное дисковое пространство.
Если задача разовая, я не постесняюсь сунуть всё в БД и получить на выходе результат.
Согласитесь, использовать Excel для большинства ежедневных задач вроде подсчёта суммы чисел в столбце — это тоже атомная бомба.
Если домашнее задание, думаю, любой не-оболтус должен справиться, конечно.
Но в целом я не то что бы критикую ваши методы, просто сокрушаюсь, что задача отбора сложная.
Как технарь я вообще иногда думаю, что задача отбора кандидатов — это по сути ранжирование, то есть отображение сложной суммы знаний и умений человека на одномерную координатную ось. И какой бы алгоритм не применялся, его всегда можно раскритиковать.
Согласитесь, использовать Excel для большинства ежедневных задач вроде подсчёта суммы чисел в столбце — это тоже атомная бомба.
Если домашнее задание, думаю, любой не-оболтус должен справиться, конечно.
Но в целом я не то что бы критикую ваши методы, просто сокрушаюсь, что задача отбора сложная.
Как технарь я вообще иногда думаю, что задача отбора кандидатов — это по сути ранжирование, то есть отображение сложной суммы знаний и умений человека на одномерную координатную ось. И какой бы алгоритм не применялся, его всегда можно раскритиковать.
Почему это нельзя применить quicksort?
mmap-им файл целиком, при помощи madvise говорим системе не кэшировать результаты чтения (MADV_RANDOM), и сортируем на здоровье. А дальше ядро само разберётся, что держать в памяти, а что не держать.
mmap-им файл целиком, при помощи madvise говорим системе не кэшировать результаты чтения (MADV_RANDOM), и сортируем на здоровье. А дальше ядро само разберётся, что держать в памяти, а что не держать.
Опять же — как при таком подходе будет себя вести дисковая подсистема. Данные никак не умеющатся в памяти — т.е они буду выгружаться на диcк. Т.о. будем бегать взад-вперёд по всему диску и убивать время именно на нахождение нужного куска.
Я с удовольствием приму такой ответ, если кандидат сумеет объяснить, как примерно работает mmap, как будет ОС кэшировать содержимое файла, как согласуется страничная организация памяти со структурой обхода данных quicksort-ом, и сколько примерно «лишних» операций доступа к диску будет сделано.
И отдельный плюс если сумеет рассказать, как все это масштабируется до файла в 1Tb при наличии памяти в 1Gb.
И отдельный плюс если сумеет рассказать, как все это масштабируется до файла в 1Tb при наличии памяти в 1Gb.
Я готов обсудить этот вопрос с адекватным работодателем.
Адекватным — т.е. не тем, у которого этот вопрос — всего один из 50 вопросов собеседования. Иначе это не оценка профессионализма кандидата, а стресс-интервью.
.
С устраивающими стресс-интервью для программистов я не готов обсуждать даже погоду.
Адекватным — т.е. не тем, у которого этот вопрос — всего один из 50 вопросов собеседования. Иначе это не оценка профессионализма кандидата, а стресс-интервью.
.
С устраивающими стресс-интервью для программистов я не готов обсуждать даже погоду.
И отдельный плюс если сумеет рассказать, как все это масштабируется до файла в 1Tb при наличии памяти в 1Gb.
И что вы выберете в такой ситуации? Миллион раз читать по мегабайту (прямым доступом), или 20000 раз по полгигабайта? Или знаете более эффективное решение?
Ну вот в этом и состоит вопрос:
1. Понимает ли кандидат инструменты, которые использует — или для него они просто «магия»?
2. Сможет ли он понять, какой на самом деле у него получится алгоритм сортировки — если убрать условные границы абстракций? Что получится, если quicksort реализовать поверх страничной организации памяти?
3. Как следствие из 2 — как будет масштабироваться решение?
И ваши вопросы тоже любопытны. Знает ли кандидат, как зависит скорость чтения от размера прочитываемого за раз буфера? Догадался ли он когда-либо это измерить, может ли он объяснить получившуюся зависимость?
Понимает ли кандидат, чем лимитируется скорость сортировки в разных условиях? Можно ли ускориться распараллеливая задачу, и когда это может сработать?
Если мы говорим о яве — там есть свои тонкости использования отображения файлов, и всяких новомодных технологий IO…
Вот так вот из одной-единственной «справочной» задачи можно кучу всего узнать про то, кто из себя кандидат как инженер.
1. Понимает ли кандидат инструменты, которые использует — или для него они просто «магия»?
2. Сможет ли он понять, какой на самом деле у него получится алгоритм сортировки — если убрать условные границы абстракций? Что получится, если quicksort реализовать поверх страничной организации памяти?
3. Как следствие из 2 — как будет масштабироваться решение?
И ваши вопросы тоже любопытны. Знает ли кандидат, как зависит скорость чтения от размера прочитываемого за раз буфера? Догадался ли он когда-либо это измерить, может ли он объяснить получившуюся зависимость?
Понимает ли кандидат, чем лимитируется скорость сортировки в разных условиях? Можно ли ускориться распараллеливая задачу, и когда это может сработать?
Если мы говорим о яве — там есть свои тонкости использования отображения файлов, и всяких новомодных технологий IO…
Вот так вот из одной-единственной «справочной» задачи можно кучу всего узнать про то, кто из себя кандидат как инженер.
А потом, послушав кандидата, сообщить ему, что в данной файловой системе скорость обращения к далёким секторам файла при прямом доступе линейно зависит от их смещения в файле. И посмотреть, как он будет выкручиваться…
Это одна из причин, по которой я предложил делегировать всю возню с памятью ядру.
Оно знает, в какой файловой системе оно лежит (привет, tar-подобные), и кэширует соответственно.
Конкретно — обнаружив уйму рандомных запросов (много чтений после MADV_RANDOM), оно начнёт держать в кэше весь хвост файла.
Оно знает, в какой файловой системе оно лежит (привет, tar-подобные), и кэширует соответственно.
Конкретно — обнаружив уйму рандомных запросов (много чтений после MADV_RANDOM), оно начнёт держать в кэше весь хвост файла.
но начиная с какого-то момента ты постоянно живёшь на четвёртом-пятом этаже этого здания, вниз спускаешься лишь изредка, а уж как фундамент выглядит, лучше не спрашивайте.
geek-and-poke.com/geekandpoke/2013/7/13/foodprints
Во-первых, я не понимаю противопоставления «либо основы либо практика». Лично я считаю, что должны быть и твердые основы, и наличие обширной практики. Но если уж выбирать, то я категорически не согласен с тем, что наличие кучи практических знаний при давно забытом фундаменте предпочтительно — для меня все как раз наоборот, и тому есть масса причин.
Во-первых, есть вопрос собеседования как такового. На нем предпочтительнее интересоваться фундаментом, потому что это такой общий знаменатель. Про VISA и X.25 человек может знать или не знать — это ровным счетом ничего не говорит о его способностях, а только лишь об истории его карьеры (я, например, совершенно не понимаю о чем вы :). А вот с основами человек не мог не сталкиваться за годы работы — и отсутствие знаний в этих областях действительно говорит о человеке — об отсутствии любопытства, например, отсутствии дотошности и желания разбираться в деталях.
Кроме того, мне кажется очень показательным что вы называете этот фундамент «справочными данными» — т.е. чем-то статическим, что надо просто зазубрить. Для меня это вовсе не тупая информация для зазубривания, а кладезь идей, методов решения задач. «Математику уж затем учить следует, что она ум в порядок приводит» — вот примерно то же самое я могу сказать про те «справочные данные» о которых мы спрашиваем: они формируют определенный — инженерный --способ мышления. Дело ведь не в том, знает ли человек уже готовые ответы — дело в том, сможет ли он решить указываемые проблемы. Если он сможет генерировать сильные идеи сам, прямо из воздуха — отлично, может, ему и правда не нужно учить основы раз уж он такой гений. Только такие гении совсем не часто встречаются.
Еще раз — важно не то, знает ли человек готовые ответы. Важно то, как он будет решать указанные проблемы (еще лучше, если человек сам замечает эти проблемы). Мы не экзамен в вузе принимаем — мы смотрим на вполне практический навык, навык решения проблем.
Во-первых, есть вопрос собеседования как такового. На нем предпочтительнее интересоваться фундаментом, потому что это такой общий знаменатель. Про VISA и X.25 человек может знать или не знать — это ровным счетом ничего не говорит о его способностях, а только лишь об истории его карьеры (я, например, совершенно не понимаю о чем вы :). А вот с основами человек не мог не сталкиваться за годы работы — и отсутствие знаний в этих областях действительно говорит о человеке — об отсутствии любопытства, например, отсутствии дотошности и желания разбираться в деталях.
Кроме того, мне кажется очень показательным что вы называете этот фундамент «справочными данными» — т.е. чем-то статическим, что надо просто зазубрить. Для меня это вовсе не тупая информация для зазубривания, а кладезь идей, методов решения задач. «Математику уж затем учить следует, что она ум в порядок приводит» — вот примерно то же самое я могу сказать про те «справочные данные» о которых мы спрашиваем: они формируют определенный — инженерный --способ мышления. Дело ведь не в том, знает ли человек уже готовые ответы — дело в том, сможет ли он решить указываемые проблемы. Если он сможет генерировать сильные идеи сам, прямо из воздуха — отлично, может, ему и правда не нужно учить основы раз уж он такой гений. Только такие гении совсем не часто встречаются.
Еще раз — важно не то, знает ли человек готовые ответы. Важно то, как он будет решать указанные проблемы (еще лучше, если человек сам замечает эти проблемы). Мы не экзамен в вузе принимаем — мы смотрим на вполне практический навык, навык решения проблем.
Но теперь-то ваша названная позиция оказалась мягче: «как собеседуемый применяет воспитанную у него систему подходов», нежели она поставлена в статье «что сказал Кнут о хэшировании и на какой странице какого тома».
Я, признаюсь, Дейкстру не читал. Нам по верхам классические алгоритмы дискретный математик прочёл — и этого мне стало достаточно, чтобы знать «алгоритмы изобретать не надо. Есть монстры до меня, которые уже вложили в них кучу математики. Главное — знать на каких полках библиотеки они находятся». Да и то, всё равно дважды накололся, изобретая самостоятельно «подсчёт площади участков диаграммы Вороного» и «интеграл по контуру для вычисления принадлежности точки полигону». Что послужило дополнительным сигналом, что гуглить надо тсчательнее, а вести себя внимательнее и скромнее.
Я, признаюсь, Дейкстру не читал. Нам по верхам классические алгоритмы дискретный математик прочёл — и этого мне стало достаточно, чтобы знать «алгоритмы изобретать не надо. Есть монстры до меня, которые уже вложили в них кучу математики. Главное — знать на каких полках библиотеки они находятся». Да и то, всё равно дважды накололся, изобретая самостоятельно «подсчёт площади участков диаграммы Вороного» и «интеграл по контуру для вычисления принадлежности точки полигону». Что послужило дополнительным сигналом, что гуглить надо тсчательнее, а вести себя внимательнее и скромнее.
ваша названная позиция оказалась мягче… нежели она поставлена в статье
Ну так затем-то (среди прочего) у нас и два собеседущих — у каждого немного свой взгляд, каждый дает свою независимую оценку.
Вообще, у меня создается ощущение, что вы думаете — мы тут весь курс алгоритмики спрашиваем. Нет конечно — я сам его не помню. Мы берем 2-3 далеко не самых сложных примера, масштаба quicksort, и пляшем вокруг них. На практике этого более чем достаточно — стиль мышления уже виден, а конкретные сложные алгоритмы можно и в википедии нагуглить, это совершенно верно.
алгоритмы изобретать не надо
Я тут не соглашусь — для меня готовый ответ действительно полезен только тогда, когда я сам потратил какое-то время на попытки его изобрести. Работающий ответ должен запоминаться не сам по себе, а в комплекте с несколькими неработающими — чтобы было понятно, почему именно он рабочий, а другие — нет. Иначе никакого «формирования образа мышления» не происходит, происходит просто тренировка памяти.
Да и то, всё равно дважды накололся, изобретая самостоятельно «подсчёт площади участков диаграммы Вороного» и «интеграл по контуру для вычисления принадлежности точки полигону».
Если мне удается переизобрести какой-то алгоритм — для меня это много радости, и повод собой погордиться. Во-первых теперь его хрен забудешь, а во-вторых — значит мозг-то еще работает :)
Поясню — типичное домашнее задание — отсортировать большойогромный файл.
Модельная задача? Модельная, хорошо изученная? Да.
Что пишут кандидаты? Пишут и quick sort поверх огромного файла, кто-то выдаёт спагетти, а не код.
Мы не занимаемся клепанием болванок по принципу лишь бы как-нибудь, лишь бы спихнуть и забыть — т.е лишь бы в какой-то разумный срок найти какое бы ни было решение.
Так, что прежде всего это уровень образования и остаточные данные.
Кроме того, далеко не все учились по специальности CS — очень многие из смежных областей пришли.
Проведу нехитрую аналогию — инженер-автомобилестроить — не поверю, что можно допустить, что хотя бы в общих чертах не знает как работает двигатель внутреннего сгорания или дизель. Не верю.
Чем инженер-программист сильно отличается от другого инженера?
Модельная задача? Модельная, хорошо изученная? Да.
Что пишут кандидаты? Пишут и quick sort поверх огромного файла, кто-то выдаёт спагетти, а не код.
Мы не занимаемся клепанием болванок по принципу лишь бы как-нибудь, лишь бы спихнуть и забыть — т.е лишь бы в какой-то разумный срок найти какое бы ни было решение.
Так, что прежде всего это уровень образования и остаточные данные.
Кроме того, далеко не все учились по специальности CS — очень многие из смежных областей пришли.
Проведу нехитрую аналогию — инженер-автомобилестроить — не поверю, что можно допустить, что хотя бы в общих чертах не знает как работает двигатель внутреннего сгорания или дизель. Не верю.
Чем инженер-программист сильно отличается от другого инженера?
Приведу в пример. Я знаю, как устроен ДВС «в общих чертах». Равно как и в общих чертах все авиадвигатели: турбореактивный, турбовинтовой, прямоточный, двухконтурный, турбовентиляторный, турбовальный, твердотопливный ракетный, ракетный на жидком топливе на давлении, на насосе, и, по случаю, даже импеллерный. Чем фенестрон лучше или хуже. Зачем нужен компрессор, чем он отличается от турбокомпрессора, для чего интеркулер и что делает закись азота или водометанола в цилиндрах. В курсе, что кроме цикла Карно для любых названных двигателей есть свои термодинамические циклы. Какой от этого толк на вакансию?
Что касается сортировки гигабайт «в лоб без гугла, при этом лично в рукопашную без сторонних утилит», то порезать файл на сегменты для оперативки, отсортировать быстро, затем слить сегменты в единый выходной файл. Кроме «быстро» можно таки нагуглить новейшие алгоритмы, которые на единичные проценты лучше «быстрой», если это дело принципа.
Но, всё-таки, не проще ли как-то побыстрее вывести уровень диалога с собеседником на его потолок компетенции? Не более одного-двух вопросов на каждый уровень, и, выяснив точный уровень разойтись уже вширь. Выяснение уровня можете организовать дихотомией. Она логарифмической сложности.
Что касается сортировки гигабайт «в лоб без гугла, при этом лично в рукопашную без сторонних утилит», то порезать файл на сегменты для оперативки, отсортировать быстро, затем слить сегменты в единый выходной файл. Кроме «быстро» можно таки нагуглить новейшие алгоритмы, которые на единичные проценты лучше «быстрой», если это дело принципа.
Но, всё-таки, не проще ли как-то побыстрее вывести уровень диалога с собеседником на его потолок компетенции? Не более одного-двух вопросов на каждый уровень, и, выяснив точный уровень разойтись уже вширь. Выяснение уровня можете организовать дихотомией. Она логарифмической сложности.
Поясните — зачем в ширь?
Взять те же базы данных — у нас в проекте они если и использовались, то в очень простом виде — типа хранить какие-то плоские структуры. Смысл спрашивать как писать триггер или прочую экзотику для базы данных, если мы это не далаем?
Или взять ещё шире — web? Но у нас его тоже почти нет.
Мы определили для себя широту используемых у нас знаний для кандидата — как хороший уровень java core — т.к. это у нас используется. Смысл спрашивать его узкоспециализированные вещи из нашей области, или какие-то хитрые продукты, которые мы используем — тоже не вижу смыла.
Так, что мы в общем-то и так стараемся пройти по тем темам, которые нам интересны.
Взять те же базы данных — у нас в проекте они если и использовались, то в очень простом виде — типа хранить какие-то плоские структуры. Смысл спрашивать как писать триггер или прочую экзотику для базы данных, если мы это не далаем?
Или взять ещё шире — web? Но у нас его тоже почти нет.
Мы определили для себя широту используемых у нас знаний для кандидата — как хороший уровень java core — т.к. это у нас используется. Смысл спрашивать его узкоспециализированные вещи из нашей области, или какие-то хитрые продукты, которые мы используем — тоже не вижу смыла.
Так, что мы в общем-то и так стараемся пройти по тем темам, которые нам интересны.
Затем, что вы своём повествовании не прояснили профиль и технологии тех проектов, но заглавие выбрали универсальное (для среднестатистической по больнице программистской фирме во всём многообразии фирм и проектов).
Если бы вы назвали статью «создаём на java realtime mmo rpg с использованием готовой графлибы и сетевой либы, БД используем NOSQL-имярёк, в ядре игры приходится применять классические алгоритмы для обеспечения игровой механики и т.д. и т.п., и как мы на эту специфику нанимаем людей» — вот тогда я бы и не заикался.
Если бы вы назвали статью «создаём на java realtime mmo rpg с использованием готовой графлибы и сетевой либы, БД используем NOSQL-имярёк, в ядре игры приходится применять классические алгоритмы для обеспечения игровой механики и т.д. и т.п., и как мы на эту специфику нанимаем людей» — вот тогда я бы и не заикался.
Уровень наверняка будет неровным, и его придётся выяснять в каждой точке. За очередной логарифм…
Верно. За K*log(Nk), где K — количество техник и принципов, набранных в этом данном проекте. Кому-то STL, кому-то Spring, кому-то EE; кому-то потребуется хорошо знать DDL и проектирование хранилищ, а кому-то планировать DML, и не знать DDL, причём знать исключительно в специфике мускула или сайбейса. Другие пользуют Qt, третьи Unty3D, а есть даже апологеты wxWidgets.
Сейчас любое рыночное решение в 60% случаев сборная солянка личных предпочтений древних архитекторов данной конкретной программерской конторы, и почивших на момент.
(40% конфигурируют или просто поддерживают чужое интегрированное решение, типа сиськи, оракула, маздая, 1С, R/3 и иже. Там совсем другие критерии профпригодности, и там не спросят про «О большое», «задачу коммивояжёра» и «генерацию лексикографически упорядоченного списка счастливых билетов только с помощью операции перестановки». Да и за «три проблемы вычислимости» там никто не в курсе, очень подозреваю)
K уменьшить нельзя, согласен. Именно поэтому.
Сейчас любое рыночное решение в 60% случаев сборная солянка личных предпочтений древних архитекторов данной конкретной программерской конторы, и почивших на момент.
(40% конфигурируют или просто поддерживают чужое интегрированное решение, типа сиськи, оракула, маздая, 1С, R/3 и иже. Там совсем другие критерии профпригодности, и там не спросят про «О большое», «задачу коммивояжёра» и «генерацию лексикографически упорядоченного списка счастливых билетов только с помощью операции перестановки». Да и за «три проблемы вычислимости» там никто не в курсе, очень подозреваю)
K уменьшить нельзя, согласен. Именно поэтому.
(не в ту реплику)
Как у него получилось «15 десятичных цифр»?
А мне кажется, что вы просто наслаждаетесь минутным моментом власти над интервьюируемым, т.е. временно зависящем от прихоти вашего настроения человеком.
Проверка знания Gang of Four при приеме на работу в IT-отдел Дойче Банка?
Кто тут говорил о неправильном распределении ресурсов АКА стрельба из пушки по воробьям?
Не, все понятно. Тщательный отсев кандидатур, всегда приятней работать с профессионалами — это все ясно. Но мне кажется, крайности всегда неуместны, а метод золотого сечения, можно применять не только в поиске N-ного члена ряда Фибоначчи, но и в поиске специалиста подходящего конкретному рабочему месту.
Это ваше личное право, но вы серьёзно заблуждаетесь про момент власти — мы люди взрослые и нам люди нужны, с которыми мы хотим работать. Хотя это российская компания (юридически по другому не может быть), но фактически менталитет не российский, поэтому на кандидата изначально смотрим как на сильного и себе равного.
Проверка знания GoF? Вы о чём? Явно же сказано:
Я не считаю, что вопрос рода Чем отличается Adapter от Wrapper может что-то сказать, как впрочем и то, что его вообще следует задавать.
И почему вы сделали вывод, что крайности — столько же раз упоминал про исключения, исключения и исключения.
Общий посыл был примерно такой: что-то не знает — не беда, если знает другое или что-то не знал, но сообразил, смог подумав найти ответ, даже если ему дали подсказку и навели.
Проверка знания GoF? Вы о чём? Явно же сказано:
Если вы не слышали, что такое Gang of Four, вероятность, что будет трудно общаться, велика.
Я не считаю, что вопрос рода Чем отличается Adapter от Wrapper может что-то сказать, как впрочем и то, что его вообще следует задавать.
И почему вы сделали вывод, что крайности — столько же раз упоминал про исключения, исключения и исключения.
Общий посыл был примерно такой: что-то не знает — не беда, если знает другое или что-то не знал, но сообразил, смог подумав найти ответ, даже если ему дали подсказку и навели.
т.е. временно зависящем от прихоти вашего настроения человеком.
А в чем именно человек зависит от моей прихоти? Собеседования, вроде, дело добровольное, с пистолетом у виска никто не стоит. Что-то не нравится — скажи. Кажется, что тебя спрашивают не о том, что ты считаешь своей сильной стороной — скажи. Кардинально не нравятся люди и атмосфера — скажи и уходи.
Мне кажется, что вы просто перекладываете ответственность за свой комфорт на других людей. Собеседование — это обоюдный процесс. Да, есть определенные традиции — не принято, например, чтобы кандидат спрашивал собеседующих знают ли они quicksort :) — но смысл их именно в том, что компания-то покупает его навыки, поэтому имеет право товар посмотреть. А кандидат навыки продает — поэтому должен их показать, а покупает зарплату/соцпакет/возможность самореализации/общую атмосферу/т.п. — и про это он имеет полное право спрашивать, а мы стараемся отвечать.
Я могу сказать про свои ощущения от собеседований. Собеседование с умеющим думать кандидатом — это очень драйвовый процесс. Наблюдать за тем, как умный человек решает проблемы — очень приятно, и очень подхлестывает, свой собственный мозг сразу ускоряется :) А собеседование со слабым слабым кандидатом вызывает ощущение неловкости. Как будто человек просто не в том месте оказался. Наслаждения от власти нет ни там, ни там.
Знаете почему, кстати? Потому что у нас, программистов, власти и так хватает :)
Готовьтесь к собеседованиям. Не день, и не неделю. Работайте, решайте модельные задачи — на это может уйти и не один месяц, и инвестиции окупятся достойным местом работы.
Я так понимаю автор уверен, что у него самое лучшее место работы, и все кто попали в ту компанию, где он работает — счастливчики. Заметил такую особенность, хороший инженер, получающий чуть больше рыночной цены и имеющий возможность реализоваться (в виде сложных задач или комлпексных задач) всегда уверен в том, что очень тяжело найти что-то лучше.
Но это так, к слову.
Я удивлен вашей внимательности — перечитайте еще раз начало — особенно третий и четвертый параграф.
И что касается того, что я уверен, что самое лучше — тут вы лукавите — я знаю, что существует много интересных мест — и это не только компании, которые на слуху типа Google или Вконтакте. Почему-то многие забывают про то какие мощные ребята работают в Oracle, кроме того есть просто огромный пласт компаний работающих в gamedev-е — на мой взгляд, чертовски интересных задач там вагоны. Словом список можно продолжать долго.
Но то, что мне нравилось то место работы и я его мог без стеснения рекомендовать друзьям и знакомым — факт.
И что касается того, что я уверен, что самое лучше — тут вы лукавите — я знаю, что существует много интересных мест — и это не только компании, которые на слуху типа Google или Вконтакте. Почему-то многие забывают про то какие мощные ребята работают в Oracle, кроме того есть просто огромный пласт компаний работающих в gamedev-е — на мой взгляд, чертовски интересных задач там вагоны. Словом список можно продолжать долго.
Но то, что мне нравилось то место работы и я его мог без стеснения рекомендовать друзьям и знакомым — факт.
хороший инженер, получающий чуть больше рыночной цены и имеющий возможность реализоваться (в виде сложных задач или комлпексных задач) всегда уверен в том, что очень тяжело найти что-то лучше.
А разве он не прав? Может быть, что-то лучше есть, но найти это что-то действительно тяжело…
Пример вопросов в Deutche Bank на позицию .Net разработчика
.NET/C#:
Common language features (value types, exception handling, events)
Nullable implementation
GetHashCode() and Dictionary
.NET memory model and garbage collection
Multithreading:
Synchronization primitives: locks, pulse/wait, mutex etc. Why is a bad practice to lock(this)
What is the techniques to avoid deadlocks.
GUI
WPF, styles/templates, Dispatcher, Invoke/BeginInvoke.
Design patterns (Singleton + implementation, decorator, explanation of MVVM and MVC/MVP)
Задач на логику может и не быть.
По ощущениям ищут идеального прораммиста, который пишет идеальный код. Если вы достигли уровня team lead или architect, то работать наверное вам будет не очень интересно, только если из-за денег.
.NET/C#:
Common language features (value types, exception handling, events)
Nullable implementation
GetHashCode() and Dictionary
.NET memory model and garbage collection
Multithreading:
Synchronization primitives: locks, pulse/wait, mutex etc. Why is a bad practice to lock(this)
What is the techniques to avoid deadlocks.
GUI
WPF, styles/templates, Dispatcher, Invoke/BeginInvoke.
Design patterns (Singleton + implementation, decorator, explanation of MVVM and MVC/MVP)
Задач на логику может и не быть.
По ощущениям ищут идеального прораммиста, который пишет идеальный код. Если вы достигли уровня team lead или architect, то работать наверное вам будет не очень интересно, только если из-за денег.
> Если вы достигли уровня team lead или architect, то работать наверное вам будет не очень интересно, только если из-за денег.
Деньги деньгами, а вообще там для тимлида есть отличный бонус, судя по данному посту. Можно здорово измываться над соискателями. Есть люди, для которых это большой плюс.
Деньги деньгами, а вообще там для тимлида есть отличный бонус, судя по данному посту. Можно здорово измываться над соискателями. Есть люди, для которых это большой плюс.
Как же вы любите высасывать из пальца того, чего и близко нет.
Мы ищем сильных людей — и изначально смотрим на них как на себе равных, приятным сюрпризом становится, что когда человек выходит на работу и работает месяц-другой он существенно превосходит наши ожидания.
Да, и кроме того, ни я, ни месье Черёмин не являются team leader'ом — и уж точно не стоит цели измываться над кем-то. Я на все 200% согласен с Русланом, что очень неловко становится, когда приходит кандидат и говорит, что поиск в hash структуре имеет сложность O(log N) и предлагает вариант дерева. Мы же не священная инквизиция, чтобы засовывать под ногти горячие гвозди и спрашивать его о чём там писал старина Кнут? Побойтесь бога, милейший. Мы гуманные люди, мы стараемся понять, что человек в самом деле такой, или он просто случайно перепутул что-то от волнения.
Как-то через чуз преувеличены слухи о «идеальном» программисте…
Мы ищем сильных людей — и изначально смотрим на них как на себе равных, приятным сюрпризом становится, что когда человек выходит на работу и работает месяц-другой он существенно превосходит наши ожидания.
Да, и кроме того, ни я, ни месье Черёмин не являются team leader'ом — и уж точно не стоит цели измываться над кем-то. Я на все 200% согласен с Русланом, что очень неловко становится, когда приходит кандидат и говорит, что поиск в hash структуре имеет сложность O(log N) и предлагает вариант дерева. Мы же не священная инквизиция, чтобы засовывать под ногти горячие гвозди и спрашивать его о чём там писал старина Кнут? Побойтесь бога, милейший. Мы гуманные люди, мы стараемся понять, что человек в самом деле такой, или он просто случайно перепутул что-то от волнения.
Как-то через чуз преувеличены слухи о «идеальном» программисте…
Ваше интервью можно сократить раз в 10 по времени — спрашивать только про Concurrency. Если человек не знает элементарных вещей вроде wait, notify и synchronized — прекращаете разговор. И всё :)
Именно на этот случай и делается телефонное интервью — оценить насколько не безнадёжен кандидат.
Нет, я говорю про основное интервью. Нет смысла спрашивать про Фибоначчи и сортировки. Просто спрашиваете про Concurrency. Либо человек знает, либо не знает. Такое техническое собеседование занимает всего 10-20 минут.
Провели телефонное — поняли, что вроде знает коллекции, wait/notify/HB и прочее по мелочёвке. На основном можно уже спрашивать о том как работает COWAL, CHM.
Однако, если это junior то никто не требует, чтобы он знал Concurrency, а тем более хорошо. Этому вполне можно и научить(ся) за время работы у нас под чутким руководством.
В этом отношении лучше смышленный и командный игрок пусть даже и junior, чем знающий всё senior, но с которым просто тяжело общаться. Если первого можно научить многому, то второго уже не переделать.
Однако, если это junior то никто не требует, чтобы он знал Concurrency, а тем более хорошо. Этому вполне можно и научить(ся) за время работы у нас под чутким руководством.
В этом отношении лучше смышленный и командный игрок пусть даже и junior, чем знающий всё senior, но с которым просто тяжело общаться. Если первого можно научить многому, то второго уже не переделать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интервью как процесс с точки зрения собеседующего