Здравствуйте, a7d3, Вы писали:
I>>Почему таких людей не надо нанимать?
A>Хорошие специалисты относятся к тем 90%, у кого мозг выключается сразу же, как только на собеседовании начинают тратить их время на такие вот задачки.
Непонятно, что это за специалист, у которого мозг выключается
A>Если же человек готов тратить время на эту мутоту, то значит он изрядно неуверен в себе и полагает, что слабо востребован на рынке труда, в силу тех или иных обстоятельств.
Битовые операции никакая не мутота. Оптимизации, протоколы, низкоуровневая работа с данными, системные функции — это неполный список того, где битовые операции не редкость.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, a7d3, Вы писали:
A>>Настолько, что даже не желают парсить чего конкретно за условия задачи и к чему это всё можно свести. A>>Оставшиеся 10% делятся на две группы, ни одну из которых на работу лучше никогда не нанимать.
I>Что за группы? Получается, ты не возьмёшь человека за знание сдвига?
I>Сдвиг обычно знают те, кто имеет опыт работы I>1. с битовыми операцими I>2. низкоуровневыми оптимизациями
I>Почему таких людей не надо нанимать?
Хорошие специалисты относятся к тем 90%, у кого мозг выключается сразу же, как только на собеседовании начинают тратить их время на такие вот задачки.
Если же человек готов тратить время на эту мутоту, то значит он изрядно неуверен в себе и полагает, что слабо востребован на рынке труда, в силу тех или иных обстоятельств.
Здравствуйте, sergey2b, Вы писали:
S>несколько хороших задачь которымиможно заменить разоворот списка
Уф, щас опять этот срач начнётся по новой.
Поищи лучше по форумам, каждый год эта тема всплывает с одними и теми же результатами.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, a7d3, Вы писали:
A>И надо быть редкостным идиотом, чтобы проверять умение этим пользоваться во время интервью-собеседования
Ну вот пришел к тебе товарищ, что заявляется экспертом по всякому низкоуровневому программированию, опыт в эмбеде и тд, и не может битовые операции.
Как быть? Простить, поощрить, дать глянуть конспект?
A>Подбор и найм людей не сводится к тому, чтобы взять и сравнить между собой кандидатов. Каждый год, последние 20 лет, подрастает очередное поколение, которое спотыкается на этом простом моменте. A>Каждый год подрастает очередная волна имбецилов, которые не осознают, что интервью-собеседование это не то самое, когда даёшь человеку задачки и смотришь как он с ними справляется. Крики, вопли, брызганье слюной по этому вопросу всегда сводятся к простой вещи — эти имбецилы понятия не имеют, а как ещё можно проводить собеседование и как вообще людей подбирать-нанимать
А как нужно интервью и что еще есть кроме как сравнить кандидатов?
Здравствуйте, a7d3, Вы писали:
A>И надо быть редкостным идиотом, чтобы проверять умение этим пользоваться во время интервью-собеседования
А никто не проверяет умение. Проверяют способность применять имеющиеся знания для генерации алгоритма решения задачи.
Грубо говоря это тест на наличие инженерного мышления.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, xarcass, Вы писали:
X>2. Повернуть прямоугольную картинку на произвольный угол (без сглаживания). Для простоты допустить, что 1 пиксель — 1 байт.
Очень просто.
Обходим попиксельно destination буфер.
Для смещений по X к координатам источника добавляем (сos;sin).
Для смещений по Y -//- (sin;cos).
Всё!
Если домножить на коэффициет (масштаб) — то ещё увеличиваться и уменьшаться будет. Если возвращать источник с обратной стороны при выходе за границу — то с эффектом "мозаики".
Можно в fixed point если регистров и скорости хватает.
Можно в целых, если развернуть цикл, и добавление заменить инкрементами в тех случаях, когда накопленная дробная часть округляется до целого (но это не позволит сильно играть с сильным уменьшением масштаба, начнутся проскоки на более чем 1 пиксель).
Крутили такое на 8 битах при 3,5мгц, при этом ещё ухитряясь синхриться с развёрткой луча на ЭЛТ, увеличивая цветовое разрешение вдвое.
Здравствуйте, Тёмчик, Вы писали:
Тё>Здравствуйте, sergey2b, Вы писали:
S>>несколько хороших задачь которымиможно заменить разоворот списка
Тё>Хорошая задачка, зачем заменять?
Именно так, дураков с идиотами должно быть видно из далека
Спросили подобное — встаёшь и уходишь. А в современно мире, просто «кладёшь трубку» и идёшь общаться с другими.
Здравствуйте, Тёмчик, Вы писали:
CC>>Это как раз именно что для выпендриться. Тё>Ну можно кидать подсказки, начать с простых вводов (без приоритета операций).
Да пофигу. Это в общем случае плохая задача для собеседования.
Тё>Неужели ты в работе ни разу с задачей преобразовать выражение не сталкивался?
Дитятко, у меня уже давно есть свой калькулятор с формулами и функциями, считает в big number fractions
И компилятор я писал ещё более давно, вместе с виртуальной машиной для пошаговой отладки для железки под которую это всё должно было работать.
Тё> Чем ты вообще занимаешься?
Системшиной.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, a7d3, Вы писали:
A>Хорошие специалисты относятся к тем 90%, у кого мозг выключается сразу же, как только на собеседовании начинают тратить их время на такие вот задачки. A>Если же человек готов тратить время на эту мутоту, то значит он изрядно неуверен в себе и полагает, что слабо востребован на рынке труда, в силу тех или иных обстоятельств.
Мозг у людей вообще очень часто выключается. Это обычная эволюционная адаптация — глюкозу надо экономить.
Но человек, который не напрягает свой мозг, мне на работе не нужен. Человек, который не может это сделать даже на собеседовании — биомусор. Можно нагрузить его какой-то несложной работой, чтобы не повышать преступность, но мне кажется, сразу в биореактор.
Идеально — набрать тех, кто хотя бы имеет привычку иногда мозг включать.
Здравствуйте, a7d3, Вы писали:
A>Этот тест не работает, потому что люди давно научились его обманывать.
Потому что применять его тоже надо умеючи а не как Артёмка пару лет назад, когда он про тест услышал а про что он собственно тестирует и на что надо смотреть — нет.
Решение как таковое никого не интересует, интересует рассуждение в процессе решения, потому что это не вопрос — ответ а повод поговорить, спросить об альтернативных вариантах решения той же задачи. Потому переворот списка плохая задача — там в общем то одно нормальное решение, можно придумать пачку плохих, как в той байке про барометры но лучше таки взять другую задачу, которую можно решить множеством способов.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, xarcass, Вы писали:
CC>>Если делать в лоб то будут глюки типа tearing.
X>Пять баллов! Тут и буксовали. А надо было просто заменить "в лоб" на "по лбу"
Что за бред? С какого боку тут tearing? Нужно аффинное преобразование. А это умножение матриц. Быстро умножать матрицы- отдельная, большая (больная) тема.
Здравствуйте, a7d3, Вы писали:
I>>Ну вот пришел к тебе товарищ, что заявляется экспертом по всякому низкоуровневому программированию, опыт в эмбеде и тд, и не может битовые операции. I>>Как быть? Простить, поощрить, дать глянуть конспект?
A>Не важно в какой сфере человек себя специалистом позиционирует, а проверять задачками не самозванец ли — это сильно лишнее.
Задача это способ показать квалификацию. Как у женглёра — показать мастерство в действии, а не рассказать про него.
I>>А как нужно интервью и что еще есть кроме как сравнить кандидатов?
A>В первую очередь стоит задуматься, а с чего вдруг эта идея возникла — сравнивать кандидатов между собой?
У кого эта идея возникла? И почему ты отвечаешь вопросом на вопрос?
A>Какая цепочка рассуждений с доводами и аргументами привела к такому ложному выводу?
Обычно хамство и уход от ответа есть достаточно сильный признак некомпетентности. А у тебя как с этим?
Здравствуйте, xarcass, Вы писали:
X>Какая там формула может быть? Школьная тригонометрия. Задача из реальной жизни.
Так вот именно! Школьная.
Я вот школу закончил 20+ лет назад. И с тех пор мне эта формула пригодилась один раз — когда учасвтовал в https://russianaicup.ru/
Зачем спрашивать эту формулу на собесе? Ну то есть ты правда хочешь понять, помнит ли кандидат эту формулу?
И давай будем честными. каждый из нас помнит или не помнит совершенно случайные вещи. И каждого можно завалить школьными вопросами.
Навскидку:
Назови основания ДНК (не гуглить).
Железо бросили в соляную кислоту, напиши реакцию.
Вычисли синус 15 градусов (без калькулятора)
Уровень воды в ванне — 50 см. с какой скоростью вода будет выливаться, когда откроют пробку?
Можешь ответить на эти, безусловно школьные вопросы?
Допустим, ответил. ЧТо это мне скажет? только то, что ты помнишь приблизительно те же вещи, что и я. О твоем профессионализме это не скажет ничего.
Здравствуйте, Skorodum, Вы писали:
I>>Битовые операции никакая не мутота. Оптимизации, протоколы, низкоуровневая работа с данными, системные функции — это неполный список того, где битовые операции не редкость. S>Замена умножения на сдвиг это разве оптимизация для стандартных CPU, компиляторов и С/С++? Я еще лет 10 назад пробовал разные варианты just for fun и выходило примерно шило на мыло
"Современных процессоров" довольно большое количество и устроены сильно по разному, соответсвенно качество компиляторов далеко не всегда не высшем уровне. Более того, не все ведь к С++ сводится. Часто это джыт, который, вобщем, сильно дохлый супротив обычного компилятора. А умножение и сдвиг до сих пор отличаются по производительности, как то так.
Здравствуйте, B0FEE664, Вы писали:
SVZ>>У нас в программе использовались односвязные списки. На основе стандартного вектора, с хранением удаленных элементов, с поддержкой Undo/Redo. SVZ>>Использовались для хранения полигонов, проводников на печатной плате. SVZ>>При объединении пары списков один из них нужно развернуть.
BFE>Зачем?
Чтобы из двух получить один, сохранив форму.
K
o---+L
|
|
|
M+-------+N
|
|
\|/
o Z
/|\
|
|
|
R+---------o P
Была дорожка K-L-M-N-Z, нарисовали еще одну дорожку P-R-Z.
В точке Z нужно обе дорожки объединить в одну. Для этого одну из них необходимо развернуть.
На выходе должно получиться либо K-L-M-N-Z-R-P, либо P-R-Z-N-M-L-K.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, xarcass, Вы писали:
S>>несколько хороших задачь которымиможно заменить разоворот списка
X>1. Найти смещение знакоместа в видеопамяти (для текстового режима — так проще). Количество знакомест в строке — константа (скажем, 80). Одно знакоместо — один байт. Операцию умножения — не использовать. X> странное дело, но мало кто может решить из тех, с кем я сталкивался
X>2. Повернуть прямоугольную картинку на произвольный угол (без сглаживания). Для простоты допустить, что 1 пиксель — 1 байт.
Только такие задачки нужно задавать в определенном контексте.
Ну то есть кандидату совсем неочевидно, почему "Операцию умножения — не использовать". И сходу хочется объяснить постановку задачи "придурью интервьювера"
А вот если сказать "операция критична по времени" — все сразу ясно.
С поворотами — тоже не все хорошо. Формулу поворота помнят не только лишь все. Ее придется выводить прямо на собеседовании.
В общем, задачи конечно интересные, но их нужно давать только в контексте поиска человека, который в работе должен жонглировать битовыми масками и выполнять другую акробатику. И при этом заранее озвучив, что вам нужно именно максимально эффективное по времени решение.
Здравствуйте, Gradiens, Вы писали:
G>Здравствуйте, xarcass, Вы писали:
S>>>несколько хороших задачь которымиможно заменить разоворот списка
X>>1. Найти смещение знакоместа в видеопамяти (для текстового режима — так проще). Количество знакомест в строке — константа (скажем, 80). Одно знакоместо — один байт. Операцию умножения — не использовать. X>> странное дело, но мало кто может решить из тех, с кем я сталкивался
X>>2. Повернуть прямоугольную картинку на произвольный угол (без сглаживания). Для простоты допустить, что 1 пиксель — 1 байт.
G>Только такие задачки нужно задавать в определенном контексте. G>Ну то есть кандидату совсем неочевидно, почему "Операцию умножения — не использовать". И сходу хочется объяснить постановку задачи "придурью интервьювера" G>А вот если сказать "операция критична по времени" — все сразу ясно.
G>С поворотами — тоже не все хорошо. Формулу поворота помнят не только лишь все. Ее придется выводить прямо на собеседовании.
G>В общем, задачи конечно интересные, но их нужно давать только в контексте поиска человека, который в работе должен жонглировать битовыми масками и выполнять другую акробатику. И при этом заранее озвучив, что вам нужно именно максимально эффективное по времени решение.
Задачи на то, что бы не использовать умножение, там где оно нужно и задачу повернуть картинку имеет смысл спрашивать, если предстоит работа с чем-то низкоуровневым.
Были процессоры, в которых команды умножения нет и умножать надо было с помощью команд сдвига и сложения. Возможно, сейчас есть какое-то специфическое железо, где это нужно, но в этом случае разработчики компиляторов уже позаботились об умножении.
Для поворота картинки нужно использовать матрицы поворота. Но наверняка есть библиотеки, в которых это реализовано и задача, скорее на понимание работы с графикой.
Но такие задания имеет смысл давать, если это связано с рабочими задачами.
Например, прочитав сообщение, я вспомнил, про то, что изучал что-то похожее, когда был студентом, но потом на практике не использовал. А могу и не вспомнить про то, что изучал, но не использовал. А получится ли самому додуматься до оптимального решения или нет — не знаю.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, a7d3, Вы писали:
A>>И надо быть редкостным идиотом, чтобы проверять умение этим пользоваться во время интервью-собеседования CC>А никто не проверяет умение. Проверяют способность применять имеющиеся знания для генерации алгоритма решения задачи. CC>Грубо говоря это тест на наличие инженерного мышления.
Этот тест не работает, потому что люди давно научились его обманывать. Появилась цела когорта таких обманщиков — хорошо показывают себя на решении подобных задач во время собеседований, но при этом неспособны работать. Таких специалистов называют рыбами лазающими по деревьям.
Здравствуйте, a7d3, Вы писали:
A>На данный момент, выявлено две жуткие дурости, т.е. придётся осознать две вещи: A>1. на собеседовании квалификацию не показывают, это не испытание кандидатов A>2. собеседование проводят не для того, чтобы кандидатов между собой сравнивать
Здравствуйте, Nuzhny, Вы писали:
N>>>А почему не перспективное? А почему матриц, а не матрицу на вектор? А нужна ли там вообще матрица? Тё>>Представить каждый пиксел как вектор координатами (x,y) и умножать на матрицу афинного преобразования, по аналогии с 3d.
N>А как будет выглядеть эта матрица? Вполне может быть так, что для оптимального решения тебе не понядобятся ни матрицы, ни вектора, а простая школьная тригонометрия даст результат и лучше и быстрее, да ещё и в целых числах (что круто, если это не на видеокарте делать).
Давай пример. Целых чисел там не будет, только fixed float можно попробовать для ускорения.
N>С такими ответами, как "применить афинное преобразование" для поворота картинки ты пролетишь, как не умеющий размышлять, а лишь применять типовые решения.
Матрица поворота — частный случай или составная часть матрицы афинного преобразования. Видишь, я не занимался этим 15 лет, но попал в точку. А ты готов изобретать велосипед.
Здравствуйте, Pzz, Вы писали:
Pzz>Но это не один разворот, а три. И в результате получается циклический сдвиг. Не в том смысле, что кто-то N раз сдвигает массив на один шаг, а в том, что результат эквиавалентен циклическому сдвигу.
2*O(N), элегантное решение за 5 минут. Или исписанная доска и нерабочее решение через 30 минут. Или нечитабельная портянка в функции на экран. Константой в большинстве случаев можно пренебречь.
Здравствуйте, Ikemefula, Вы писали:
I>На такие вещи даёт ответ профайлер. Обсуждать "быстрее или нет" без внятных требований к производительность это по моему редкий зашквар.
Мне не нужен профайлер, чтобы понять что десятки миллионов лишних операций на картинку — это плохо.
Но мы этот вопрос уже обсудили и выяснили, что была путаница в терминах. Так что проходи мимо, читай тред, а потом отвечай.
Здравствуйте, Ikemefula, Вы писали:
I>То есть, если функция ни разу не является узким местом, ты всё равно начнешь оптимизации, просто из чувства прекрасного?
Ты зануда. Мы сейчас говорим о задаче на собеседовании. Нет никаких реальных проектов.
Если бы они были, я бы взял готовую библиотеку, в которой наверняка есть реализация поворота с оптимизацией под разные архитектуры процессора, а также реализация на GPU.
Если бы библиотек не было, я бы сделал обобщённую функцию transform для преобразования изображения и передавал в неё функцию вычисления новых координат параметром шаблона. В таком случае не было бы никакой потери общности и никакого оверхеда. Хочешь — передай аффинное преобразование, хочешь перспективное (почему, кстати, ты его не предлагаешь, почему никто его не предлагает? Это же та же матрица, но с большими возможностями), хочешь поворот или просто сдвиг. Нет необходимости совершать преждевременную пессимизацию своего решения. Почему ты вообще думаешь, что матрица 3х3 решит все проблемы? Как ты с помощью неё исправишь перспективные искажения или дисторсию? А?
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Pzz, Вы писали:
Pzz>>"Придумать" != "придумать, когда у тебя над душой стоят" CC>Потому и задачка берётся весьма простая.
Чаще надо ходить по собеседованиям, а не отращивать задницу на одном месте.
Побудешь сам в роли кандидата лишний раз и станет понятно, чего именно стоят все эти «простые задачки», когда над душой стоят зеваючи.
Если человек по собеседованиям ходил лишь когда сам был вчерашним студентом, которых нанимают через отбор «сырых талантов». То ему потом крайне сложно научиться людей собеседовать. Поскольку он понятия не имеет как это можно и нужно делать, в том случае, если не «сырые таланты» ищешь.
Здравствуйте, a7d3, Вы писали:
I>>Каким образом понять, какой должен быть подход в данном случае? Чего тебе не хватает это самый подход продемонстрировать?
A>Бесполезно демонстрировать подобное когда у собеседника нет понимания базовых/элементарных вещей.
Подозреваю, если бы ты меньше хамил и строил из себя великого знатока, тебе было бы намного проще доносить свои идеи до адресата. Сильно думаю, что я проводил собеседования десятками в неделю когда ты еще программировать не умел
До сих пор у тебя исключительно общие фразы, без какой либо конкретики
A>1) Рабочей единицей является не отдельно взятый сотрудник, а команда. Человек нанимается в качестве сотрудника на некую роль в конкретную команду.
Это по разному. Иногда — просто в компанию. И чем больше контора, тем этот случай чаще.
Как быть, если нас устраивают ажно три кандидата а место одно?
A>2) Понятие роли в проекте/команде — это не тоже самое, что понятие квалификации у фрезеровщика или сварщика (пятый-шестой разряд).
Если комплектует проект, когда команды еще нет, это вообще не интересно, т.к. можно только предполагать какие у кого роли будут.
Крометого, как быть, если нас устраивают ажно три кандидата а место одно?
A>3) Если среди кандидатов оставить лишь профессионалов с хорошей квалификацией, годных на роль синьора, то далеко не каждый из них подойдёт в конкретную команду.
Если остались с хорошей, то остальные то с плохой Предлагаешь брать с плохой квалификацией? По моему, нужно брать тех, кто есть на рынке и проходит по квалификации и не является токсичным для команды. Нету таких — ищем дальше.
Что делать, если у нас ажно три годных кандидата?
A>Прописные истину тут в том, что люди в проектной работе не являются взаимозаменяемыми болтиками или одинаковыми кирпичами.
Ну вот есть три человека, которые подходят нас, проект устраивает их, работа интересная. Что делать?
A>Подбор строится на том, что нет понятия «незакрытая вакансия в компанию» — есть не полностью укомплектованный экипаж в конкретной команде.
Это тактика мелкой конторы. В крупной много команд находится в разной степени комплектации. Соответственно упускать человека с хорошей квалификацией никто не хочет.
A>Берём этих самых 10 кандидатов и смотрим, кто из них подходит на роль условного синьора вот в эту вот команду, а кого лучше туда не брать.
Трех нашли. Что дальше?
A>И общий вектор такой, что если кандидату по итогам собеседования не сделали оффера, то это ни в коем случае не про его профессионализм или квалификацию.
Здравствуйте, landerhigh, Вы писали:
A>>не считают нужным всех и вся сразу же допускать до system design interview,
L>И самое забавное, что сами же интервьюверы во время system design interview жидко обгаживаются, показывая полное непонимание особенностей system, которую они типа хотят design.
Это необоснованое обобщение. Куда ни вижу твой ник, у тебя нечто вида "все <категория> дураки"
Здравствуйте, Ikemefula, Вы писали:
I> [поскипано] I>Разумеется, потому в конторе, где все построено на интервью, матерый интервьюер в год проводит раза два три больше тех интервью, чем ты указалал. I> [поскипано]
Ясно — аргументы закончились, начался сплошной переход на личности с проявлением упёртости и придирками к собеседнику.
С моей стороны нет интереса вытащить тебя из болота твоих заблуждений. Основная масса которых, судя по всему, заложена тебе в голову менеджментом работодателя. Рынок есть рынок — конкуренция за ресурсы не предполагает мотивации к трате сил на альтруизм.
A>>Мозаичное панно выкинул, а ухватился лишь за пазл? Хорошо, можно и через него. A>>Большая часть команд напоминают пазл собранный лишь на половину, а то и меньше. А потому и «кусочков» понапихать туда можно ощутимо больше одного-двух.
I>Из этого следует, что сравнивать придется гораздо больше, ширше, и глубже. Вот у тебя три инженера и два места из пяти. Кого взять? Три кандидата, значит реально возможна ситуация "камень-ножницы-бумага", когда первый выглядит предпочтительнее второго, второй — третьего, третий — первого. I>Я тебе страшное скажу — эта ситуация возможна абсолютно везде, и в шахматах, и в боксе, и найме инженеров, и в найме дворников. I>Кого брать?
Да, есть такая вещь как многокритериальный анализ и множество Паретто.
Да, мощность этого множества может оказаться больше, чем хотелось бы.
Но и давно известны варианты как выходить из этой ситуации без «камень-ножницы-бумага». Очень странно, если человек не знает о таких элементарных вещах и потому с пеной у рта настойчиво пытается что-то там втереть собеседнику.
Здравствуйте, Ikemefula, Вы писали:
I>Фактически, это непрямой вопрос на тему какой у тебя опыт в UI. Разумеется, если это единственный вопрос, то смысла в нём нет никакого. Многие считают, что выталкивание вычислений в другой тред это всегда хорошо. На самом деле в большинстве случаев плохо Жизнь так устроена. Вытакивать нужно только тяжелые вычисления. Тяжелые — зависит от задачи. Нет требований ко времени отклика, то и секундная задержка не является тяжелым вычислением. Есть всякие драг-н-дропы — 100мс это уже дико много.
Какая связь между плавной анимацией драг-дропа и вычислениями? Плавная анимация делается на GPU. Вообще единственный рациональный способ держать UI плавным- это держать его в единственном потоке, а вычисления выкидывать в фон (фоновый пул потоков или обращение к бекенду). Переключение контекста в любом случае в винде достаточно быстрое, если сделано всё по уму. А если у тебя пачка потоков конкурируют за один-единственный мутекс- так это рукожопый дизайн, не более того.
Здравствуйте, Ikemefula, Вы писали:
I>>>Цитирую себя "не все ведь к С++ сводится" S>>Gnu Compiler Collection...
I>Я все время думал, что gcc это gnu c++
Здравствуйте, xarcass, Вы писали:
AN>>Но такие задания имеет смысл давать, если это связано с рабочими задачами.
X>Кто в своей повседневной работе использовал разворот односвязного списка — пусть первый бросит в меня камень.
Что такое "в повседневной работе"? По десять раз на дню?
У нас в программе использовались односвязные списки. На основе стандартного вектора, с хранением удаленных элементов, с поддержкой Undo/Redo.
Использовались для хранения полигонов, проводников на печатной плате.
При объединении пары списков один из них нужно развернуть.
Как и любой другой алгоритм разворот писался однократно, а потом использовался по необходимости.
Получи камень!
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Skorodum, Вы писали:
S>Замена умножения на сдвиг это разве оптимизация для стандартных CPU, компиляторов и С/С++? Я еще лет 10 назад пробовал разные варианты just for fun и выходило примерно шило на мыло
Помнится, во времена MS-DOS и 16-битных 80x86, был такой Watcom C Compiler, который считался очень крутым в плане кодогенерации. Так вот, он любил умножение на константу в виде последовательности сдвигов и сложений расписивать. Бывало, на полстраницы ассемблерного текста развернется. У древних x86 действительно был медленный умножатор, не то, что теперь.
Здравствуйте, Lazytech, Вы писали:
L>Здравствуйте, sergey2b, Вы писали:
S>>это когда надо слова поменять местами отночительно средины списка но порядок букв в слове оставить правильным
L>По идее, от выбора ЯП сильно зависит. К примеру, на Python или JavaScript подобные задачи решаются достаточно просто.
на Си тоже строк 10 кода
но к сожалению на американских собеседованиях работающее но не оптимальное решение это не зачет
Здравствуйте, sergey2b, Вы писали:
PM>>Или оставаться в 1D, но двигаться дальше — циклический сдвиг массива на k N позиций влево или вправо, само собой, тоже inplace.
S>эту задачку давали в google на разминке в 15 году
Ну-ну, кто бы в этом сомневался. Во что пишет про алгоритм block swap Дж. Бентли в "Жемчужинах программирования"
Б. Керниган и П. Дж. Плоджер пользовались именно этим методом для перемещения строк в текстовом редакторе в своей книге (В. Kernighan, P. J. Plauger, Software Tools in Pascal, 1981). Керниган пишет, что эта функция заработала правильно с первого же запуска, тогда как их предыдущая версия, использовавшая связный список, содержала несколько ошибок. Этот же код используется в некоторых текстовых редакторах, включая тот, в котором я впервые набрал настоящую главу. Кен Томпсон (Ken Thompson) написал этот редактор с функцией reverse в 1971 году, и он утверждает, что она уже тогда была легендарной.
Здравствуйте, sergey2b, Вы писали:
S>первая версия в среднем 5-10 строк S>в коцне собеседования у меня доходило до пару сотен на глаз
Задание было, что бы работало со всеми случаями — разное основание, целые, с фиксированной точкой, с плавающей точкой, ASCII/EBCDIC?
А про HR-фильтр я упомянул, потому, что судя по другим сообщениям Тёмчика, кандидаты к нему попадают после разговора с HR. Может быть HR у него не тех отсеивают и потом Тёмчик жалуется, что сеньор строку перевернуть не может.
Здравствуйте, diez_p, Вы писали:
G>>Остальные типы задач — от лукавого. Лично я не вижу, как другие типы головоломок помогут понять, подходит кандидат, или нет. G>>Да и задачи на мышление — спорная тема. Можно потратить кучу времени, завалить хорошего кандидата, который хорошо программирует но плохо решает задачи "про гномиков"
_>А потом вот эти люди пишут лютейшие интерфейсы c абсолютно не ортогональными методами, завязывают все компоненты в узел и перематывают это все скотчем. Вся алгоритмика задра..ся на раз. У меня знакомый чел, бывший UIщик, захотел писать под линукс на C++ и за 3 мес он алгоритмы выучил так, что сам порой мог интервьюверам вскипятить голову.
Задра..ся только базовый набор алгоритмов, а вот дальше нужно владеть мат-методами — например, вычислить, доказать ассимптотику. И вот это уже не задра..ся, а изучается долго и упорно при наличии знаний матана. Без матана эту тему не осилить.
_>Меня как-то спрашивали на UI, с какой частотой в винде таймер переключает потоки, я грю я хз,
Фактически, это непрямой вопрос на тему какой у тебя опыт в UI. Разумеется, если это единственный вопрос, то смысла в нём нет никакого. Многие считают, что выталкивание вычислений в другой тред это всегда хорошо. На самом деле в большинстве случаев плохо Жизнь так устроена. Вытакивать нужно только тяжелые вычисления. Тяжелые — зависит от задачи. Нет требований ко времени отклика, то и секундная задержка не является тяжелым вычислением. Есть всякие драг-н-дропы — 100мс это уже дико много.
Для UI Винды это была важная характеристика до недавних пор. Подчеркиваю — до недавних пор. Что бы правильно сорганизовать выталкивание вычислений в другой тред, нужно учитывать вот эту характеристику. Скажем, сделать годный плавный драг-н-дроп в тяжелом UI, нужно учитывать такие вот мелкие детали, соответсвенно часто в тяжелом софте драг-н-дроп написан через одно известное место. Плавный — отрисовка >25 кадров в секунду, что дает нам пространство в 40мс.
Все вычисления, которые занимают один-два кванта времени нет смысла выталкивать в другой тред, т.к. суммарные издержки будут только больше.
Например, 40мс ты считаешь чего, еще столько же уходит на всякие переключения и тд. В итоге, твой UI имеет лаг в 80мс что уже существенно для точной UI операции, тот же драг-н-дроп.
80мс это всего 12 кадров. В этом случае нужно отказаться от другого потока и тупо выполнять вычисления в основном. Лаг будет всего 40 мс и это те самые 25 кадров.
Почему до недавних пор — по моему в 8ке или 10ке поменялся шедулинг и теперь все немного не так.
Здравствуйте, Тёмчик, Вы писали:
Тё>Эту хрень можно знать, если однажды её сделал.
необязательно именно ее. Афинное текстурировние (а я его тоже упоминал) более общий случай той же самой задачи. И та же самая реализация — растеризатор заполняет построчно пиксели, шарясь по байтам текстуры.
Здравствуйте, xarcass, Вы писали:
X>1. Найти смещение знакоместа в видеопамяти (для текстового режима — так проще). Количество знакомест в строке — константа (скажем, 80). Одно знакоместо — один байт. Операцию умножения — не использовать. X> странное дело, но мало кто может решить из тех, с кем я сталкивался
AN>Для поворота картинки нужно использовать матрицы поворота. Но наверняка есть библиотеки, в которых это реализовано и задача, скорее на понимание работы с графикой.
Если представить, что у нас есть просто массив байтов (условно двумерный), то для того, чтобы его попиксельно повернуть достаточно базовых знаний тригонометрии. Из курса школы.
AN>Но такие задания имеет смысл давать, если это связано с рабочими задачами.
Кто в своей повседневной работе использовал разворот односвязного списка — пусть первый бросит в меня камень.
Здравствуйте, a7d3, Вы писали:
S>>>несколько хороших задачь которымиможно заменить разоворот списка
Тё>>Хорошая задачка, зачем заменять?
A>Именно так, дураков с идиотами должно быть видно из далека A>Спросили подобное — встаёшь и уходишь. А в современно мире, просто «кладёшь трубку» и идёшь общаться с другими.
Ну если ищется по принципу "5 за пучок", да. А на серьезные задачи будь добр хотя бы первый курс института осилить (разворот списка).
Здравствуйте, CreatorCray, Вы писали:
Тё>>Но вот к примеру, выпендриться: напишите на доске функцию, которая считает арифметическое выражение и печатает результат. CC>Это как раз именно что для выпендриться.
Ну можно кидать подсказки, начать с простых вводов (без приоритета операций). Неужели ты в работе ни разу с задачей преобразовать выражение не сталкивался? Чем ты вообще занимаешься?
Здравствуйте, CreatorCray, Вы писали:
Тё>>У меня были реально задачи разобрать выражение и построить дерево индикаторов (с зависимостями) и другая- разобрать regexp и потом отсортировать результаты по приоритету по количеству matched сегментов. CC>meh
Это всего лишь пример использования в работе.
CC>>>И компилятор я писал ещё более давно, вместе с виртуальной машиной для пошаговой отладки для железки под которую это всё должно было работать. Тё>>Может, ты там только кирпичи подносил, а написал другой человек? CC>Я это всё в одно рыло написал.
Ну если ты это делал "в одно рыло", в чём твоя претензия?
Вот развернуть или посчитать биты- этот вопрос уместен в embedded/drivers и неуместен everywhere else.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, a7d3, Вы писали:
A>>Этот тест не работает, потому что люди давно научились его обманывать. CC>Потому что применять его тоже надо умеючи а не как Артёмка пару лет назад, когда он про тест услышал а про что он собственно тестирует и на что надо смотреть — нет. CC>Решение как таковое никого не интересует, интересует рассуждение в процессе решения, потому что это не вопрос — ответ а повод поговорить, спросить об альтернативных вариантах решения той же задачи. Потому переворот списка плохая задача — там в общем то одно нормальное решение, можно придумать пачку плохих, как в той байке про барометры но лучше таки взять другую задачу, которую можно решить множеством способов.
Именно это и зовётся system design interview — несколько взаимосвязанных между собой задач, имеющих различные варианты решения. И при этом, все упакованные в одну небольшую «постановку», формулируемую одной фразой. От кандидата ожидается не только порассуждать на тему вариантов решения, но и вообще увидеть эти самые задачи путём диалога с интервьюером.
Адепты решения абстрактных задачек на собеседовании никогда не отрицают полезность system design interview. Они всего лишь полагают, что перед этим надо типа «разогреть кандидата». Или же не считают нужным всех и вся сразу же допускать до system design interview, а хотят как-то отфильтровать толпу народу. Классический случай, когда «благими намерениями» губят всю процедуру (найма), сводя на нет любую возможность диалога.
Отсобеседовав криво с десяток людей — автоматом лишаешь себя трёх-четырёх сотен потенциальных кандидатов. Фигово отсобеседованный кандидат приводит к тому, что в компанию не придёт 30-40 других, тех кому напрямую или через вторые руки расскажут об идиотизме. В итоге, компания обрекает себя на вечное ковыряние в абы каком человеческом материале.
Здравствуйте, Nuzhny, Вы писали:
N>А почему не перспективное? А почему матриц, а не матрицу на вектор? А нужна ли там вообще матрица?
Представить каждый пиксел как вектор координатами (x,y) и умножать на матрицу афинного преобразования, по аналогии с 3d.
Здравствуйте, Тёмчик, Вы писали:
N>>А почему не перспективное? А почему матриц, а не матрицу на вектор? А нужна ли там вообще матрица? Тё>Представить каждый пиксел как вектор координатами (x,y) и умножать на матрицу афинного преобразования, по аналогии с 3d.
А как будет выглядеть эта матрица? Вполне может быть так, что для оптимального решения тебе не понядобятся ни матрицы, ни вектора, а простая школьная тригонометрия даст результат и лучше и быстрее, да ещё и в целых числах (что круто, если это не на видеокарте делать).
С такими ответами, как "применить афинное преобразование" для поворота картинки ты пролетишь, как не умеющий размышлять, а лишь применять типовые решения.
Здравствуйте, Тёмчик, Вы писали:
Тё>Давай пример. Целых чисел там не будет, только fixed float можно попробовать для ускорения.
Пример чего? Я уже несколько раз намекал, что аффинное преобразование — это оверкилл. Ты никак не можешь этого понять.
Тё>Матрица поворота — частный случай или составная часть матрицы афинного преобразования. Видишь, я не занимался этим 15 лет, но попал в точку. А ты готов изобретать велосипед.
Я не готов изобретать велосипед, потому что никакого велосипеда тут нет. Никто в здравом уме не будет поворачивать картинку аффинным преобразованием. Если это надо делать быстро на CPU, то умножение матрицы (3х3) на вектор (3х1) будет слишком медленным, когда можно сделать в несколько раз быстрее (в целых числах в том числе). Если же на GPU, то float, но тоже не умножением матриц.
Призываю посчитать, сколько операций надо для поворота картинки, а сколько для аффинного преобразования: в аффинном случае у тебя для каждого пикселя будет 4 лишних умножения на 0, 3 лишних умножения на 1, 4 лишних операции сложения. Не оверкилл? Если мы будем пачками обрабатывать многопегапиксельные снимки, то вообще туши свет — я лично обвиню тебя в ускорении приближения глобального потепления.
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, sergey2b, Вы писали:
S>>Здравствуйте, Тёмчик, Вы писали: S>>Это задачка из К и Р S>>И человек знающий про обратную польскую Наталию решит ее за недолго
BFE>Сколько дней? С учётом входных данных, например таких: длина числа не более 1024 знака. Длина выражения не более 10 гигабайт. Ну, а что? В условиях про формат ничего не сказано.
А какие операции доступны и можно ли использовать скобки в выражениях
Здравствуйте, Nuzhny, Вы писали:
N>Я не готов изобретать велосипед, потому что никакого велосипеда тут нет. Никто в здравом уме не будет поворачивать картинку аффинным преобразованием. Если это надо делать быстро на CPU, то умножение матрицы (3х3) на вектор (3х1) будет слишком медленным, когда можно сделать в несколько раз быстрее (в целых числах в том числе). Если же на GPU, то float, но тоже не умножением матриц.
Не 3x3 на 3x1, а 2x2 на 2x1.
N>Призываю посчитать,
Призываю расписать здесь операции для поворота, основанные на школьных тригонометрических знаниях.
Как быстро будем считать гипотенузу, или можно сразу повернуть тангенс?
N> сколько операций надо для поворота картинки, а сколько для аффинного преобразования: в аффинном случае у тебя для каждого пикселя будет 4 лишних умножения на 0, 3 лишних умножения на 1, 4 лишних операции сложения. Не оверкилл? Если мы будем пачками обрабатывать многопегапиксельные снимки, то вообще туши свет — я лично обвиню тебя в ускорении приближения глобального потепления.
А разве алгоритмическая сложность не C * O(N)? Умножаем матрицу на каждую координату (0..N-1), N раз.
Здравствуйте, B0FEE664, Вы писали:
X>>2. Повернуть прямоугольную картинку на произвольный угол (без сглаживания). Для простоты допустить, что 1 пиксель — 1 байт.
BFE>Без искажений эта задача не имеет решения.
Картинка на пиксельном мониторе — это уже искажения
Хинт — у тебя вращение текстурированной херни протестов не вызывает ?
Здравствуйте, Skorodum, Вы писали:
I>>"Современных процессоров" довольно большое количество и устроены сильно по разному, соответсвенно качество компиляторов далеко не всегда не высшем уровне. S>Неплохо было бы подтвердить свои слова. Найдите компилятор и целевую архитектуру, когда x*80 не будут разложены на сдвиг и сложение.
Здравствуйте, IID, Вы писали:
IID>необязательно именно ее. Афинное текстурировние (а я его тоже упоминал) более общий случай той же самой задачи. И та же самая реализация — растеризатор заполняет построчно пиксели, шарясь по байтам текстуры.
Т.е. по сути нужно разобраться в видах растеризаторов. Мне не довелось с этим сталкиваться. Поигрался немного с 3D для чартов и отсечением невидимых граней (была идея получить векторную картинку для печати) и забросил. В 2004-2005г это было. Насколько оно у меня тормозило вручную на CPU, настолько летало в OpenGL.
Здравствуйте, Тёмчик, Вы писали:
BFE>>Ага. И всё это расписать прямо на доске.
Тё>>>Вот что делать с арифметической операцией над двумя числами в 1024 знака, это отдельная тема, к задаче не относящаяся. BFE>>Интересные новости про условия задачи! Тё>Так ты сам усложнил задачу!
Я? А вы предполагаете, что числа в выражении могут состоять только из одной цифры?
Тё>В исходном сообщении было 2+2 и 2+2*3. Для этого достаточно встроенных операций и памяти под стек.
В исходном сообщении было "2+2", "2*2", "2+3*2". Для этого вообще не нужно никаких операций кроме сравнения:
if ( expression == "2+2" ) printf("4");
if ( expression == "2*2" ) printf("4");
if ( expression == "2+3*2" ) printf("8");
Здравствуйте, CreatorCray, Вы писали:
Тё>>Очевидно, можно проецирующую координату оставить в double без округления, и копировать субпиксельно, т.е. раскидывать на "пятно" из покрытых координатой пикселов. Либо если reverse- брать значение пиксела с покрытого пятна из нескольких пикселов, в пропорциях покрытия. Либо почитать про билинейную фильтрацию.
CC>Ты уже "не сдал", ещё с матрицами, чего уж теперь суетиться?
Формула с синусами-косинусами- это продукт матрица вращения на вектор. Матрица вращения- частный случай аффинной матрицы.
Здравствуйте, Nuzhny, Вы писали:
I>>На такие вещи даёт ответ профайлер. Обсуждать "быстрее или нет" без внятных требований к производительность это по моему редкий зашквар.
N>Мне не нужен профайлер, чтобы понять что десятки миллионов лишних операций на картинку — это плохо.
То есть, если функция ни разу не является узким местом, ты всё равно начнешь оптимизации, просто из чувства прекрасного?
A>не считают нужным всех и вся сразу же допускать до system design interview,
И самое забавное, что сами же интервьюверы во время system design interview жидко обгаживаются, показывая полное непонимание особенностей system, которую они типа хотят design.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, a7d3, Вы писали:
I>>>Каким образом понять, какой должен быть подход в данном случае? Чего тебе не хватает это самый подход продемонстрировать?
A>>Бесполезно демонстрировать подобное когда у собеседника нет понимания базовых/элементарных вещей.
I>Подозреваю, если бы ты меньше хамил и строил из себя великого знатока, тебе было бы намного проще доносить свои идеи до адресата. Сильно думаю, что я проводил собеседования десятками в неделю когда ты еще программировать не умел
Дык и ты не паинька и гонору у тебя на целый бронепоезд.
Иди порассказывай про десятки собеседований в неделю кому-нибудь другому, кто в твоей весовой категории, там и найдёшь общий язык.
Куда мне тягаться с таким зубром, когда за последние 20 лет довелось провести не более четырех-пяти сотен собеседований.
I>До сих пор у тебя исключительно общие фразы, без какой либо конкретики
Так и ты херню несёшь, полную. Замерять квалификацию на собеседованиях — это надо сильно головой ушибиться.
Касаемо остального — не бывает такого, чтобы три человека из десяти одинаково хорошо подходили на одну и ту же роль в конкретную команду.
Если для тебя такая ситуация является нормой, то прекрати уже людей собеседовать. Потому принципу, раз не можешь какать, то и не мучай попу.
Люди все имеют разные системы ценностей, разные чаяния с желаниями развиваться. Кто-то уже выгоревший, кто-то не умеет держать work-live баланс, кому-то хочется лишь забиться под стол и чтобы его поменьше трогали. Кто-то самолюблён и полагает, что все остальные должны мириться с его недостатками, а он не обязан по этому поводу никаких усилий прикладывать.
Если тебе это всё не знакомо, непонятно и чуждо, то это говорит о твоей полной незрелости в вопросах работы с людьми.
Здравствуйте, a7d3, Вы писали:
A>Куда мне тягаться с таким зубром, когда за последние 20 лет довелось провести не более четырех-пяти сотен собеседований.
4-5 сотен это сравнительно немного. Про собеседовании 1 раз в неделю это примерно 50 собеседований в год, за двадцать лет должно быть около 1000.
4-5 сотен берется ориентировочно за несколько лет регулярных собеседований.
I>>До сих пор у тебя исключительно общие фразы, без какой либо конкретики
A>Так и ты херню несёшь, полную.
И снова хамишь. "гонору у тебя на целый бронепоезд" @
Подозреваю, ты примерно так же и на интервью ведешь себя. Бедные кандидаты
> Замерять квалификацию на собеседованиях — это надо сильно головой ушибиться.
Где ты видишь, что я предлагаю "замерять квалификацию"? Я вижу что задаю тебе вопросы и пока что не получил внятных ответов.
Чуть ниже ты сам, фактически, утверждаешь, что некто подходит лучше, некто хуже, то есть, надо бы сравнить, что бы понять эту лучшесть-хужесть.
Лучше-хуже — это и есть сравнение. На всякий случай, мало ли, вдруг ты не в курсе.
A>Касаемо остального — не бывает такого, чтобы три человека из десяти одинаково хорошо подходили на одну и ту же роль в конкретную команду.
Намекаешь, что надо сравнить, кто же подходит лучше? Это что же, бронепоезд дал задний ход ?
A>Если для тебя такая ситуация является нормой, то прекрати уже людей собеседовать. Потому принципу, раз не можешь какать, то и не мучай попу.
Как именно понять, кто лучше подходит? И почему тебе необходимо хамить в таком вот житейском вопросе? Что за потребность в хамстве?
A>Люди все имеют разные системы ценностей, разные чаяния с желаниями развиваться. Кто-то уже выгоревший, кто-то не умеет держать work-live баланс, кому-то хочется лишь забиться под стол и чтобы его поменьше трогали. Кто-то самолюблён и полагает, что все остальные должны мириться с его недостатками, а он не обязан по этому поводу никаких усилий прикладывать.
Снова общие слова. В сухом остатке — ты отказываешься от сравнения за счет сравнения. Внушает!
A>Если тебе это всё не знакомо, непонятно и чуждо, то это говорит о твоей полной незрелости в вопросах работы с людьми.
Здравствуйте, landerhigh, Вы писали:
I>>Это необоснованое обобщение. Куда ни вижу твой ник, у тебя нечто вида "все <категория> дураки"
L>Ты никак конспектируешь за мной? L>Право, не стоит. Меня смущает такое внимание к моей скромной персоне.
Ты сам себя старательно повторяешь, так что мне делать ничего не надо — всё уже отлито в граните еще до моего прихода
Здравствуйте, a7d3, Вы писали:
A>>>Куда мне тягаться с таким зубром, когда за последние 20 лет довелось провести не более четырех-пяти сотен собеседований.
I>>4-5 сотен это сравнительно немного. Про собеседовании 1 раз в неделю это примерно 50 собеседований в год, за двадцать лет должно быть около 1000. I>>4-5 сотен берется ориентировочно за несколько лет регулярных собеседований.
A>Для примера, сотня сотрудников и текучка пять процентов — каждый год надо нанимать пять новых человек. Это и выливается в 20-25 собеседований за год.
То есть, частный случай в мелкой конторе.
A>А на кой лад регулярные собеседования проводить? Заняться больше не чем?
У тебя только кейс "текучка". А с новыми проектами, ростом что делать?
Кроме того, в большой конторе есть собеседования при смене проекта, фактически, на новом проекте тебя никто не знает, и нужно решить, кто подойдет лучше, ты или парень с улицы.
Кроме того, в большой конторе как правило продвижение по лестнице сопровождается собеседованиями. Т.е. хочешь позицию повыше или просто другую — почему надо взять тебя, а не того парня?
Бывают и такие кейсы — у того парня выбор, или увольняться, чего он не хочет, или выяснять, чего не так с ним. Это тоже собеседование, понять, стоит ли продолжать с ним работу, дать другой проект, рекомендовать какие курсы и тд.
Есть и еще кейсы, которые так же решаются собеседованиями.
В целом у матёрых интервьюеров будет собеседований побольше чем 20-25 в год. Гораздо больше. Так что 400-500 сотен это никакой не военный результат для 20 лет опыта.
A>Или же собеседователь настолько «хороший» сотрудник, что его не допускают до реальной работы?
Техническое интервью — крайне важная задача, фейл стоит очень-очень дорого. Соответсвенно интервьюер как правило один из самых ценных сотрудников.
Это вобщем очевидно — кроме прочего контора демонстрирует кто же в ней работает, и абы кого на собес в своём уме мало кто ставит.
Поэтому интервью и есть та самая реальная работа, и, например, у руководителя это прямая обязанность проводить такие интервью.
A>Вытекало с той точки диалога, где было про задачки со сдвигами. Где было видно путаницу между ролью и квалификацией. Т.е. непонимание того, что сеньор-помидор является не квалификацией, а ролью.
Это у тебя какая то путаница. Как правило эту роль занимает человек, обладающий определенной квалификацией.
I>>Чуть ниже ты сам, фактически, утверждаешь, что некто подходит лучше, некто хуже, то есть, надо бы сравнить, что бы понять эту лучшесть-хужесть. I>>Лучше-хуже — это и есть сравнение. На всякий случай, мало ли, вдруг ты не в курсе.
A>Не означает. A>...решают эту задачу сравниванием меж собой имеющихся кусочков, потому как профанация будет...
И опять у тебя все к сравнению сводится. Как ни крути, а сравнивать приходится, что ты сам же и демонстрируешь уже в который раз.
Более того — ты уже с десяток раз ушел от ответа, как быть, если есть три годных кандидата на одну позицию, кого брать.
Вобщем, выступление твоё сильно так себе, хотя "гонору на целый бронепоезд" @
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, a7d3, Вы писали:
A>>Для примера, сотня сотрудников и текучка пять процентов — каждый год надо нанимать пять новых человек. Это и выливается в 20-25 собеседований за год.
I>То есть, частный случай в мелкой конторе.
Своеобразное утверждение, люди бывалые, люди опытные хорошо знают, что чуть ли не все большие конторы — это множество мелких под одним зонтиком. Например, под видом нескольких бизнес-юнитов подчинённых различным вице-презикам.
Да и не видать ответа на вопрос о том, с какого числа сотрудников компания перестаёт, в твоём понимании, являться мелкой конторой.
Три сотни персонала в R&D, поделённые на несколько бизнес-юнитов, могут обеспечить всю разработку софтовых продуктов компании размером в 1200-1300 человек.
A>>А на кой лад регулярные собеседования проводить? Заняться больше не чем?
I>У тебя только кейс "текучка". А с новыми проектами, ростом что делать? I>Кроме того, в большой конторе есть собеседования при смене проекта, фактически, на новом проекте тебя никто не знает, и нужно решить, кто подойдет лучше, ты или парень с улицы. I>Кроме того, в большой конторе как правило продвижение по лестнице сопровождается собеседованиями. Т.е. хочешь позицию повыше или просто другую — почему надо взять тебя, а не того парня? I>Бывают и такие кейсы — у того парня выбор, или увольняться, чего он не хочет, или выяснять, чего не так с ним. Это тоже собеседование, понять, стоит ли продолжать с ним работу, дать другой проект, рекомендовать какие курсы и тд. I>Есть и еще кейсы, которые так же решаются собеседованиями.
Это и не собеседование, это даже и не интервью.
Да и в ряде компаний сотрудника вольны менять проекты-продукты чуть ли не произвольно. Вспоминаем те самые столы с ножками на роликах.
I>Техническое интервью — крайне важная задача, фейл стоит очень-очень дорого. Соответсвенно интервьюер как правило один из самых ценных сотрудников. I>Это вобщем очевидно — кроме прочего контора демонстрирует кто же в ней работает, и абы кого на собес в своём уме мало кто ставит. I>Поэтому интервью и есть та самая реальная работа, и, например, у руководителя это прямая обязанность проводить такие интервью.
Это уже называется раздувание щёк, ради подчёркивания собственной важности со значимостью.
Если толковому инженеру вместо интервью устраивают решение задачек вроде разворачивания списка, то это очень неуважительное отношение к человеку. Такое запоминается надолго и рассказывается им пяти-шести знакомым, а те в свою очередь передают дальше. Поступив так с десятком кандидатов компания лишает себя притока в несколько сотен вменяемых людей. Если же эта информация утекает на глассдоры и т.п., то компания обречена на просеивание большого количества отбросов на рынке труда, в надежде найти хоть что-то приличное. Не трудно догадаться, какая деформация сознания и когнитивный диссонанс, после этого, развиваются у сотрудников ответственных за подбор и найм нового персонала такой компании.
A>>Вытекало с той точки диалога, где было про задачки со сдвигами. Где было видно путаницу между ролью и квалификацией. Т.е. непонимание того, что сеньор-помидор является не квалификацией, а ролью.
I>Это у тебя какая то путаница. Как правило эту роль занимает человек, обладающий определенной квалификацией.
И ты решил эту самую квалификацию обнаружить у кандидата во время интервью за счёт задачек, типа разворота списка или каких-то других, схожих? Смешно, инженер — это ни разу не сварщик и не фрезеровщик.
I>И опять у тебя все к сравнению сводится. Как ни крути, а сравнивать приходится, что ты сам же и демонстрируешь уже в который раз. I>Более того — ты уже с десяток раз ушел от ответа, как быть, если есть три годных кандидата на одну позицию, кого брать. I>Вобщем, выступление твоё сильно так себе, хотя "гонору на целый бронепоезд" @
Ещё раз, при найме людей нет смысла сравнивать кандидатов между собой. Таким образом не получится решить вопрос подбора подходящего в конкретную команду. Иным образом действуют, подбирая кусочек мозаичного панно или пазла. Если непонятно почему, то дискутировать дальше — бесполезная трата времени.
Здравствуйте, a7d3, Вы писали:
A>Своеобразное утверждение, люди бывалые, люди опытные хорошо знают, что чуть ли не все большие конторы — это множество мелких под одним зонтиком. Например, под видом нескольких бизнес-юнитов подчинённых различным вице-презикам.
Ога. Этот зонтик, в частности, обеспечивает обычно единые процессы. Например, рекрутинг общий для всех. От отдела к отделу могут меняться правила, непринципиально.
A>Да и не видать ответа на вопрос о том, с какого числа сотрудников компания перестаёт, в твоём понимании, являться мелкой конторой. A>Три сотни персонала в R&D, поделённые на несколько бизнес-юнитов, могут обеспечить всю разработку софтовых продуктов компании размером в 1200-1300 человек.
Вот и считай эти три сотни. В средней софтверной конторе одних разработчиков будет раза в два-три больше.
I>>Бывают и такие кейсы — у того парня выбор, или увольняться, чего он не хочет, или выяснять, чего не так с ним. Это тоже собеседование, понять, стоит ли продолжать с ним работу, дать другой проект, рекомендовать какие курсы и тд. I>>Есть и еще кейсы, которые так же решаются собеседованиями.
A>Это и не собеседование, это даже и не интервью.
Очевидно, что задача(кейс) и её решение(собеседование или интервью) это разные вещи. Выше приведены кейсы которые решаются при помощи собеседования или интервью. Разумеется, есть и другие способы, аудит например, но это сложновато применить в большинстве случаев.
A>Да и в ряде компаний сотрудника вольны менять проекты-продукты чуть ли не произвольно. Вспоминаем те самые столы с ножками на роликах.
И как это сюда относится?
I>>Поэтому интервью и есть та самая реальная работа, и, например, у руководителя это прямая обязанность проводить такие интервью.
A>Это уже называется раздувание щёк, ради подчёркивания собственной важности со значимостью.
Это должностные обязаности — руководитель занимается отбором людей в свою команду. И кстати говря, твои нападки мимо кассы.
A>Если толковому инженеру вместо интервью устраивают решение задачек вроде разворачивания списка, то это очень неуважительное отношение к человеку. Такое запоминается надолго и рассказывается им пяти-шести знакомым, а те в свою очередь передают дальше. Поступив так с десятком кандидатов компания лишает себя притока в несколько сотен вменяемых людей.
Гугл, Амазон, Микрософт и прочие гиганты давно уже должны были загнуться. Да и большинство мелких фирм.
Надеюсь ты не слился на этих списках? Там всё просто, кстати.
I>>Это у тебя какая то путаница. Как правило эту роль занимает человек, обладающий определенной квалификацией.
A>И ты решил эту самую квалификацию обнаружить у кандидата во время интервью за счёт задачек, типа разворота списка или каких-то других, схожих?
Кандидаты бывают разного уровня. Всем, с опытом до года-двух стоит задавать эти списки.
Такими задачами обнаруживается гарантированое отсутствие определенных компетенций. Если кандидат не умеет развернуть список, с ним сильно вряд ли стоит иметь дело. Ну разве что в L1, L2 суппорт пройдет, или ручного QA.
Объяснение простое — индустрия хавает неквалифицированый контингент огромным ковшом. Квалифицированые, подготовленые инженеры вобщем редкость.
Далеко не все задачи требуют именно инженерных скилов. Простой проверкой в виде списка можно отсеять процентов 95% залетных.
>Смешно, инженер — это ни разу не сварщик и не фрезеровщик.
Программист это еще не повод называться инженером. Как то так.
A>Ещё раз, при найме людей нет смысла сравнивать кандидатов между собой. Таким образом не получится решить вопрос подбора подходящего в конкретную команду. Иным образом действуют, подбирая кусочек мозаичного панно или пазла.
Снова общие слова и невалидные метафоры. В пазле ровно 1 кусочек встанет на место. В индустрии такое редкость. Всегда есть выбор — взять сейчас или подождать, проверить еще парочку и посмотреть, лучше подойдет — у кого опыта больше, или тот, у кого зп комфортнее.
> Если непонятно почему, то дискутировать дальше — бесполезная трата времени.
У тебя есть что нибудь кроме бронепоезда или даже он уехал?
Здравствуйте, Ikemefula, Вы писали:
I>Ога. Этот зонтик, в частности, обеспечивает обычно единые процессы. Например, рекрутинг общий для всех. От отдела к отделу могут меняться правила, непринципиально.
Нет, это не так, в том числе и в тех компаниях, которые на 3500-3700 сотрудников или 13-25 тысяч.
Странно, что у тебя такие заблуждения/проекции.
I>Вот и считай эти три сотни. В средней софтверной конторе одних разработчиков будет раза в два-три больше.
Софтверная компания делающая программные продукты исходит с того, что себестоимость продукта лишь на 15-25% состоит из затрат на разработчиков с тестерами и дизайнерами с техписами. Остальные 75-85% приходятся на другие подразделения компании.
(три сотни разрабов + две сотни тестеров) × 100/25 = компания две тысячи человек.
I>Очевидно, что задача(кейс) и её решение(собеседование или интервью) это разные вещи. Выше приведены кейсы которые решаются при помощи собеседования или интервью. Разумеется, есть и другие способы, аудит например, но это сложновато применить в большинстве случаев.
Сформулировано так, словно других вариантов нету и надо выбирать лишь из этих двух. Не годится.
A>>Да и в ряде компаний сотрудника вольны менять проекты-продукты чуть ли не произвольно. Вспоминаем те самые столы с ножками на роликах. I>И как это сюда относится?
Компании разные бывают, нет смысла всех под один горшок стричь. Реальная практика показывает, что принципы ротация кадров могут быть весьма различны от компании в компанию.
I>>>Поэтому интервью и есть та самая реальная работа, и, например, у руководителя это прямая обязанность проводить такие интервью.
A>>Это уже называется раздувание щёк, ради подчёркивания собственной важности со значимостью.
I>Это должностные обязаности — руководитель занимается отбором людей в свою команду. И кстати говря, твои нападки мимо кассы.
Забавное представление про характер обязанностей руководителя и вариантах исполнения таковых (проводить технические интервью с кандадитами задавая им разворот списка). Но и ты не мой сотрудник, за тебя не отвечаю, потому и мозги тебе вправлять — не моя задача.
A>>Если толковому инженеру вместо интервью устраивают решение задачек вроде разворачивания списка, то это очень неуважительное отношение к человеку. Такое запоминается надолго и рассказывается им пяти-шести знакомым, а те в свою очередь передают дальше. Поступив так с десятком кандидатов компания лишает себя притока в несколько сотен вменяемых людей.
I>Гугл, Амазон, Микрософт и прочие гиганты давно уже должны были загнуться. Да и большинство мелких фирм. I>Надеюсь ты не слился на этих списках? Там всё просто, кстати.
Уже обсуждалось, если человека рассматривают лишь в качестве «сырого таланта», то его собеседуют одним образом. Если же видят, что это состоявшийся инженер, то используется иной подход. Именно так поступали и поступают упомянутые тобой компании, потому они до сих пор не загнулись. Если ни тебя и твоих знакомых эти компании рассматривали лишь как «сырых талантов», то это не повод полагать, что иным образом они никого не собеседуют.
Крайне редко, бывает и другой сценарий. Когда кандидата намеренно унижают, чтобы посмотреть насколько покладистый, насколько ему нужна именно эта работа. В некоторые отделы/команды могут набирать спецом покладистых людей, согласных туалеты мыть, лишь бы в авиации работать. Некоторым менеджерам проще нанять покладистого и на всё согласного, чем решать проблему иным образом.
I>Кандидаты бывают разного уровня. Всем, с опытом до года-двух стоит задавать эти списки. I>Такими задачами обнаруживается гарантированое отсутствие определенных компетенций. Если кандидат не умеет развернуть список, с ним сильно вряд ли стоит иметь дело. Ну разве что в L1, L2 суппорт пройдет, или ручного QA.
Это именно то самое, что касается подбора «сырых талантов». Однако, в наш век все эти задачки уже опубликованы в книжках-сборниках или разобраны на веб-ресурсах. Твой любимый подход исчерпал себя, поскольку не защищён от жульничества — людей, спецом натаскивающихся на подобное.
I>Объяснение простое — индустрия хавает неквалифицированый контингент огромным ковшом. Квалифицированые, подготовленые инженеры вобщем редкость. I>Далеко не все задачи требуют именно инженерных скилов. Простой проверкой в виде списка можно отсеять процентов 95% залетных.
Есть такое правило — держаться как можно дальше от тех компаний, которые нанимают программеров (кодеров) вместо специалистов программной инженерии.
A>>Ещё раз, при найме людей нет смысла сравнивать кандидатов между собой. Таким образом не получится решить вопрос подбора подходящего в конкретную команду. Иным образом действуют, подбирая кусочек мозаичного панно или пазла.
I>Снова общие слова и невалидные метафоры. В пазле ровно 1 кусочек встанет на место. В индустрии такое редкость. Всегда есть выбор — взять сейчас или подождать, проверить еще парочку и посмотреть, лучше подойдет — у кого опыта больше, или тот, у кого зп комфортнее.
Мозаичное панно выкинул, а ухватился лишь за пазл? Хорошо, можно и через него.
Большая часть команд напоминают пазл собранный лишь на половину, а то и меньше. А потому и «кусочков» понапихать туда можно ощутимо больше одного-двух.
Здравствуйте, AleksandrN, Вы писали:
AN>Может быть HR у него не тех отсеивают
Вспоминается байка как компания не могла найти профессионального сварщика для варки какой то сложной хрени потому что хрюша выбрасывала в мусор всех кандидатов старше 40 как "слишком старые".
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, sergey2b, Вы писали:
S>убрать пробелы с переди сздаи
Строго говоря это не задача именно парсера.
S>обработка ошибок
if (...) return false?
S>знак
Элементарно.
S>ox
не ох а 0x
Это просто.
S>восмиричное число
как его предлагаешь отличать от десятичного с leading zeroes?
Мало чем отличается от 0x
S>экспонента
геморнее если хочется сделать эффективно, впрочем не особо сложнее чем просто дробное.
S>дробное число
элементарно.
S>класс
что класс?
S>большие числа скажем в 1024 разряда
а в чём тут сложность то, при наличии имплементации таких чисел?
Я когда свою имплементацию писал всё это делал, только не комбайном всемогутером а специализированными фукнциями с препарсером, на случай если хз что там за число подсунут. Всё одно формат определяется типом, в который читаем. Если дали uint то никаких отрицательных или дробных, если дали double то никаких 0x
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ikemefula, Вы писали:
I>Сдвиг обычно знают те, кто имеет опыт работы I>1. с битовыми операцими I>2. низкоуровневыми оптимизациями
3. читает RSDN
4. перед интервью посещает сайты с онлайн задачками типа codility или hackerrank
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, sergey2b, Вы писали:
S>несколько хороших задачь которымиможно заменить разоворот списка
Самое правильное в этой ситуации заменить интервьювера.
Такое ощущение, что когда нанимают конструктора (неважно чего), дают какой-то замысловатый паззл и говорят можешь сложить?
Ребята вы серьезно? Вы каждый день складываете такие паззлы?
Пора бы уже давно забыть про (2,71)6@#унтые задачи, которые показывают только один единственный навык — уметь решать задачи такого характера.
Людей берут на решение задач/проблем в определенной предметной области, с какими-то знаниями в определенных технологиях и так называемые soft skills.
И каждое собеседование должно строиться исходя из потребностей компании/проекта.
Если в вашей компании разворачивают списки, то безусловно задача на разворот №1 ))
На собеседованиях спрашивают за сколько тактов GC собирает кучу, выверты графов наизнанку, а потом смотришь в код и там такой звиздец, что просто берешь и переписываешь ибо саппортить невозможно. За все время видел много разных проектов и только у 1 из 10 код написано в первую очередь понятно, а во вторых в соотвествии с используемыми use cases.
Здравствуйте, Ikemefula, Вы писали:
I>Микросекунды на что именно? Нужно считать весь цикл вычисления туда-сюда включая шансы потершать по дороге кванты времени по любой причине.
Я толи что-то не понимаю, толи ты считаешь что идеальное с точки зрения производительности приложение — это приложение работающее в один поток. С такой фольмулировкой я не согласен.
I>Для примера — простая задержка Sleep(1) реально зависит от загрузки системы. Я тут много лет назад выкладывал замеры. В зависимости от загрузки системы этот Sleep(1) выполняется от 1 кванта до 15 секунд.
Если у тебя Sleep(1) занимает 15 секунд, то уже вообще без разницы где и как ты будешь считать — система и так не отзывается.
I>Та же проблема и при выталкивании вычислений в другой поток — пропускная способность растет при наличии ядер, но растет и латентность.
Нет такой проблемы. Есть закон Амдала и это единственное ограничение, которое у тебя возникает в общем случае. Дальше есть нюансы типа а какая у тебя модель памяти и прочее, но это уже небольшие уточнения, не более того. Ну а латентностью, возникающей при переключении контекста можно пренебречь как ничтожно маленькой величиной.
Здравствуйте, Ikemefula, Вы писали:
I>Это ничего не меняет. Список это одна из базовых вычислительных моделей, встречается по сотне раз на день.
Вы шаблонно мыслите. Человек не знает списков, допустим. Как они решал задачи которые связаны с ними? Не решал, значит надо посмотреть, решал — ок, знаит не вдумывается как рабоотает, одной стороны хорошо: работает — не трогай, с другой: знаит в случае чего придется потратить время на копание ибо незнает.
Все IT это применение стандартных решений или свое велосипедо строение, под конкретно свою узкую задачу.
Если человек не может придумать свой велосипед, на уже решенную задачу — какой он тогда программист? Построение велосипедов может потребоваться значительно раньше, чем будет изобретено коробочное решение.
Лично я писал свой react еще в 2007 году, а DI контейнер до меня велосипедисты написали еще на .NET 1.1.
т.е. сам факт не знания списков еще ни о чем не говрит, надо копать глубже.
1. Найти смещение знакоместа в видеопамяти (для текстового режима — так проще). Количество знакомест в строке — константа (скажем, 80). Одно знакоместо — один байт. Операцию умножения — не использовать.
странное дело, но мало кто может решить из тех, с кем я сталкивался
2. Повернуть прямоугольную картинку на произвольный угол (без сглаживания). Для простоты допустить, что 1 пиксель — 1 байт.
Здравствуйте, xarcass, Вы писали:
vsb>>Константа произвольно задаваемая, или 80?
X>Конечно любая — можно даже нечётную. Смысл не меняется.
vsb>>offset = row * 80 + col. row * 80 = row * 64 + row * 16 = row << 6 + row << 4. Такой алгоритм предполагается?
X>Конечно. Удивительно то, как много матёрых перцев на этом буксуют.
Просто они не желают вникать, что именно за херню у них попросили решить.
По-моему опыту более 90% кандидатов, увидев такие задачки на собеседовании, тут же выключают мозг.
Настолько, что даже не желают парсить чего конкретно за условия задачи и к чему это всё можно свести.
Оставшиеся 10% делятся на две группы, ни одну из которых на работу лучше никогда не нанимать.
Здравствуйте, a7d3, Вы писали:
A>Настолько, что даже не желают парсить чего конкретно за условия задачи и к чему это всё можно свести. A>Оставшиеся 10% делятся на две группы, ни одну из которых на работу лучше никогда не нанимать.
Что за группы? Получается, ты не возьмёшь человека за знание сдвига?
Сдвиг обычно знают те, кто имеет опыт работы
1. с битовыми операцими
2. низкоуровневыми оптимизациями
Здравствуйте, xarcass, Вы писали:
S>>несколько хороших задачь которымиможно заменить разоворот списка
X>1. Найти смещение знакоместа в видеопамяти (для текстового режима — так проще). Количество знакомест в строке — константа (скажем, 80). Одно знакоместо — один байт. Операцию умножения — не использовать. X> странное дело, но мало кто может решить из тех, с кем я сталкивался
X>2. Повернуть прямоугольную картинку на произвольный угол (без сглаживания). Для простоты допустить, что 1 пиксель — 1 байт.
Организация занимается написанием драйверов или микрокода для GPU?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, a7d3, Вы писали:
A>>Если же человек готов тратить время на эту мутоту, то значит он изрядно неуверен в себе и полагает, что слабо востребован на рынке труда, в силу тех или иных обстоятельств.
I>Битовые операции никакая не мутота. Оптимизации, протоколы, низкоуровневая работа с данными, системные функции — это неполный список того, где битовые операции не редкость.
И надо быть редкостным идиотом, чтобы проверять умение этим пользоваться во время интервью-собеседования
Подбор и найм людей не сводится к тому, чтобы взять и сравнить между собой кандидатов. Каждый год, последние 20 лет, подрастает очередное поколение, которое спотыкается на этом простом моменте.
Каждый год подрастает очередная волна имбецилов, которые не осознают, что интервью-собеседование это не то самое, когда даёшь человеку задачки и смотришь как он с ними справляется. Крики, вопли, брызганье слюной по этому вопросу всегда сводятся к простой вещи — эти имбецилы понятия не имеют, а как ещё можно проводить собеседование и как вообще людей подбирать-нанимать
Здравствуйте, Тёмчик, Вы писали:
Тё>Но вот к примеру, выпендриться: напишите на доске функцию, которая считает арифметическое выражение и печатает результат.
Это как раз именно что для выпендриться.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
G>С поворотами — тоже не все хорошо. Формулу поворота помнят не только лишь все. Ее придется выводить прямо на собеседовании.
G>В общем, задачи конечно интересные, но их нужно давать только в контексте поиска человека, который в работе должен жонглировать битовыми масками и выполнять другую акробатику. И при этом заранее озвучив, что вам нужно именно максимально эффективное по времени решение.
Какая там формула может быть? Школьная тригонометрия. Задача из реальной жизни. Люди писали карточную игру (довольно давно). Надо было сделать анимацию вращения спрайта карты. Промежуточные состояния генерировались прямо во время анимации — на лету. Причём на палме, у которого процессор дохлее тех, что сейчас в клавиатуры ставят (и без плавающей точки заодно). И ничего сделали. Но немного побуксовали — есть там одна тонкость, но её не понять, пока не попробуешь.
Здравствуйте, alzt, Вы писали:
A>Здравствуйте, a7d3, Вы писали:
A>>Хорошие специалисты относятся к тем 90%, у кого мозг выключается сразу же, как только на собеседовании начинают тратить их время на такие вот задачки. A>>Если же человек готов тратить время на эту мутоту, то значит он изрядно неуверен в себе и полагает, что слабо востребован на рынке труда, в силу тех или иных обстоятельств.
A>Мозг у людей вообще очень часто выключается. Это обычная эволюционная адаптация — глюкозу надо экономить. A>Но человек, который не напрягает свой мозг, мне на работе не нужен. Человек, который не может это сделать даже на собеседовании — биомусор. Можно нагрузить его какой-то несложной работой, чтобы не повышать преступность, но мне кажется, сразу в биореактор.
Это не работает. Потому что хороший специалист не станет тренироваться решать задачки на собеседованиях, а тот человек, который работать не умеет и ничего из себя не представляет — будет смотреться замечательно на фоне всех остальных. Поскольку у него выбора иного нету.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, a7d3, Вы писали:
A>>И надо быть редкостным идиотом, чтобы проверять умение этим пользоваться во время интервью-собеседования
I>Ну вот пришел к тебе товарищ, что заявляется экспертом по всякому низкоуровневому программированию, опыт в эмбеде и тд, и не может битовые операции. I>Как быть? Простить, поощрить, дать глянуть конспект?
Не важно в какой сфере человек себя специалистом позиционирует, а проверять задачками не самозванец ли — это сильно лишнее.
Один кандидат расскажет пяти-шести другим людям, а каждый из них, в свою очередь — тоже.
I>А как нужно интервью и что еще есть кроме как сравнить кандидатов?
В первую очередь стоит задуматься, а с чего вдруг эта идея возникла — сравнивать кандидатов между собой?
Какая цепочка рассуждений с доводами и аргументами привела к такому ложному выводу?
Здравствуйте, sergey2b, Вы писали:
S>Здравствуйте, Тёмчик, Вы писали: S>Это задачка из К и Р
S>И человек знающий про обратную польскую Наталию решит ее за недолго
Алгоритм Дейкстры для преобразования в польскую нотацию.
Здравствуйте, Тёмчик, Вы писали:
Тё>Здравствуйте, sergey2b, Вы писали:
S>>Здравствуйте, Тёмчик, Вы писали: S>>Это задачка из К и Р
S>>И человек знающий про обратную польскую Наталию решит ее за недолго
Тё>Алгоритм Дейкстры для преобразования в польскую нотацию.
У нас на первом курсе было домашнее задание написать на Паскале калькулятор
Здравствуйте, xarcass, Вы писали:
X>Если представить, что у нас есть просто массив байтов (условно двумерный), то для того, чтобы его попиксельно повернуть достаточно базовых знаний тригонометрии.
Если делать в лоб то будут глюки типа tearing.
X>Кто в своей повседневной работе использовал разворот односвязного списка — пусть первый бросит в меня камень.
От меня щас прилетит пару вёдер камней.
В системщине односвязные списки используются весьма часто, одна из причин — вставка "в голову" делается атомарно, не приходя в сознание.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Пять баллов! Тут и буксовали. А надо было просто заменить "в лоб" на "по лбу"
X>>Кто в своей повседневной работе использовал разворот односвязного списка — пусть первый бросит в меня камень. CC>От меня щас прилетит пару вёдер камней. CC>В системщине односвязные списки используются весьма часто, одна из причин — вставка "в голову" делается атомарно, не приходя в сознание.
Ну мне вот за более чем 30 лет стажа разворачивать список понадобилось ни разу. А те задачки, что я написал — вполне себе из жизни. Правда, половину стажа у меня — хардкорный эмбед, с отсутствием в большинстве случаев такой роскоши, как динамическое выделение памяти. А вторая часть — мобилки, где как-то тоже вот не попалось.
Здравствуйте, CreatorCray, Вы писали:
Тё>>Неужели ты в работе ни разу с задачей преобразовать выражение не сталкивался? CC>Дитятко, у меня уже давно есть свой калькулятор с формулами и функциями, считает в big number fractions
У меня были реально задачи разобрать выражение и построить дерево индикаторов (с зависимостями) и другая- разобрать regexp и потом отсортировать результаты по приоритету по количеству matched сегментов. Дедуля.
CC>И компилятор я писал ещё более давно, вместе с виртуальной машиной для пошаговой отладки для железки под которую это всё должно было работать.
Может, ты там только кирпичи подносил, а написал другой человек? Судя по твоему пригару на несложные задачки.
Тё>> Чем ты вообще занимаешься? CC>Системшиной.
Т.е. любую минимальную логику держат в usermode (и это правильно), а у тебя профессиональная деформация?
Здравствуйте, Тёмчик, Вы писали:
Тё>У меня были реально задачи разобрать выражение и построить дерево индикаторов (с зависимостями) и другая- разобрать regexp и потом отсортировать результаты по приоритету по количеству matched сегментов.
meh
CC>>И компилятор я писал ещё более давно, вместе с виртуальной машиной для пошаговой отладки для железки под которую это всё должно было работать. Тё>Может, ты там только кирпичи подносил, а написал другой человек?
Я это всё в одно рыло написал.
Тё>>> Чем ты вообще занимаешься? CC>>Системшиной. Тё>Т.е. любую минимальную логику держат в usermode
Сразу видно ыксперта.
Хотел напрыгнуть но промахнулся и плюхнулся в лужу? Обтекай молча.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, xarcass, Вы писали:
X>А надо было просто заменить "в лоб" на "по лбу"
И таки ведь да.
Я подобной графикой в до-аккселераторные времена занимался. Романтика пёрла просто атас. Особенно когда в итоге оно не тормозило. А теперь не интересно уже — всё есть готовое.
X>Ну мне вот за более чем 30 лет стажа разворачивать список понадобилось ни разу.
Да просто у меня задачи специфические, где такая азбука на каждом столбе.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Тёмчик, Вы писали:
Тё>Что за бред? С какого боку тут tearing? Нужно аффинное преобразование. А это умножение матриц. Быстро умножать матрицы- отдельная, большая (больная) тема.
А почему не перспективное? А почему матриц, а не матрицу на вектор? А нужна ли там вообще матрица?
Здравствуйте, Тёмчик, Вы писали:
Тё>Это всего лишь пример использования в работе.
И?
Тё>>>>>Неужели ты в работе ни разу с задачей преобразовать выражение не сталкивался? CC>>>>И компилятор я писал ещё более давно, вместе с виртуальной машиной для пошаговой отладки для железки под которую это всё должно было работать. Тё>>>Может, ты там только кирпичи подносил, а написал другой человек? CC>>Я это всё в одно рыло написал.
Тё>Ну если ты это делал "в одно рыло", в чём твоя претензия?
Где ты у меня тут увидел претензии?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ikemefula, Вы писали:
I>Задача это способ показать квалификацию. Как у женглёра — показать мастерство в действии, а не рассказать про него.
Это крайне печальное заявление, потому что собеседование не является испытанием и квалификацию на нём никто не проверяет.
I>>>А как нужно интервью и что еще есть кроме как сравнить кандидатов? A>>В первую очередь стоит задуматься, а с чего вдруг эта идея возникла — сравнивать кандидатов между собой? I>У кого эта идея возникла? И почему ты отвечаешь вопросом на вопрос?
Диалога не будет, ровно до тех, пока тебе не станет ясно, что интервью-собеседование не служит и для сравнивания кандидатов.
A>>Какая цепочка рассуждений с доводами и аргументами привела к такому ложному выводу? I>Обычно хамство и уход от ответа есть достаточно сильный признак некомпетентности. А у тебя как с этим?
Покажи на хамство пальцем.
Все люди находятся на разном уровне развития и осознания — отдельных компетенций. И до тех пор, пока тебе не станет ясно «А», то и бесполезно говорить с тобой про «Б». Однако, ты можешь и не подозревать о том, насколько некомпетентен и выяснять это лишь случайно, входе каких-то мимолётных контактов где-то с кем-то. Если такая картинка мира устраивает, то начни с самоконтроля:
— какая именно цепочка рассуждений с доводами/аргументами привела к посылу, что собеседование является способом сравнивания кандидатов.
На данный момент, выявлено две жуткие дурости, т.е. придётся осознать две вещи:
1. на собеседовании квалификацию не показывают, это не испытание кандидатов
2. собеседование проводят не для того, чтобы кандидатов между собой сравнивать
Здравствуйте, xarcass, Вы писали:
X>Кто в своей повседневной работе использовал разворот односвязного списка — пусть первый бросит в меня камень.
X>зы. если что — с реверса списка тема и началась
А часто спрашивают разворот списка на собеседовании? Меня, например — ни разу. Разговоры про списки, деревья и прочие контейнеры были, но спрашивали, как они устроены и какая сложность вставки и поиска значений.
А список развернёт любой первокурсник, который вчера лабу на эту тему делал.
G>Зачем спрашивать эту формулу на собесе? Ну то есть ты правда хочешь понять, помнит ли кандидат эту формулу?
Да нет там никаких формул вообще. Зато есть один весьма программистский нюанс. На который в реальной жизни реальные люди и наступили. И слегка побуксовали.
И вообще, чем критиковать чужие задачки накидал бы кто своих. А то кроме меня и тёмчика пока никто не сподобился.
Здравствуйте, xarcass, Вы писали:
G>>С поворотами — тоже не все хорошо. Формулу поворота помнят не только лишь все. Ее придется выводить прямо на собеседовании.
G>>В общем, задачи конечно интересные, но их нужно давать только в контексте поиска человека, который в работе должен жонглировать битовыми масками и выполнять другую акробатику. И при этом заранее озвучив, что вам нужно именно максимально эффективное по времени решение.
X>Какая там формула может быть? Школьная тригонометрия. Задача из реальной жизни.
Это сразу сужает перечень кандидатов до бывших школьников, студентов математических специальностей и тех, кто именно в этой теме и работает.
Скажем, если ты такую задачу будешь задавать бакенду или фронтенду, то велик шанс фейла. Вместо этого гораздо более результативно спрашивать по самому профилю кандидата.
В порядке убывания важности:
1. опыт, роли, обязанности — интересует прежде всего уровень коммуникации, масштаб работ, умение принимать решения и вникать в суть дела
2. интересы
3. технические скилы — желательно понимание основ, проектирования, а не сами баззворды
Обычно всё наоборот — спрашивают за баззворды, а всё остальное мало кто вообще берется спрашивать. На самом деле хороший сотрудник это далеко не всегда тот, кто уже на входе знает нужный баззворд. Более того, знатоки баззвордов слишком часто теряют интерес, например, на долгоиграющих проектах.
Здравствуйте, Gradiens, Вы писали:
G>Допустим, ответил. ЧТо это мне скажет? только то, что ты помнишь приблизительно те же вещи, что и я. О твоем профессионализме это не скажет ничего.
Кажется, что в программировании практически никогда не бывает так, что кандидат удовлетворяет всем необходимым требованиям. Разве что в 1С получить все сертификаты и можно на любой проект. Поэтому на собеседовниях смотрят:
1. Какой частью их необходимых знаний обладает кандидат.
2. Как быстро он учится.
3. Как умеет разбираться с незнакомыми проблемами.
В зависимости от результатов собеседования, можно взять кандидата со знаниями в предметной области и с низкой скоростью обучения или, наоборот, с высокой обучаемостью, но без знаний. В зависимости от проекта, укомплектованности команды и бюджета принимается решение. Или у тебя не так?
Возвращаясь к вопросу, например, о синусе можно понять насколько быстро кандидат разберётся с задачами, где будет немного математики.
Здравствуйте, xarcass, Вы писали:
X>И вообще, чем критиковать чужие задачки накидал бы кто своих. А то кроме меня и тёмчика пока никто не сподобился.
Лично я не фанат задач. Но две категории задач могут быть полезны.
1) любые на понимание алгоритмической сложности.
пример простой задачи: как максимально эффективно по времени отсортировать массив из 10^9 чисел, учитывая, что каждое из них не больше 10^6
2) любые на алгоритмическое мышление. Просто, чтобы посмотреть, как кандидат мыслит. И что делает, если у него не все получается.
пример простой задачи: есть массив с числами от 1 до N, все числа кроме одного не повторяются. Найти повторяющееся число.
пример задачи посложнее: есть указатель на однонаправленый связанный список. Как не выделяя динамической памяти узнать, закольцован список, или нет.
неплохо, если задача сразу принадлежит обеим категориям. Пример: найти все вхождения подстроки в строке.
Остальные типы задач — от лукавого. Лично я не вижу, как другие типы головоломок помогут понять, подходит кандидат, или нет.
Да и задачи на мышление — спорная тема. Можно потратить кучу времени, завалить хорошего кандидата, который хорошо программирует но плохо решает задачи "про гномиков"
Здравствуйте, Ikemefula, Вы писали:
I>Битовые операции никакая не мутота. Оптимизации, протоколы, низкоуровневая работа с данными, системные функции — это неполный список того, где битовые операции не редкость.
Замена умножения на сдвиг это разве оптимизация для стандартных CPU, компиляторов и С/С++? Я еще лет 10 назад пробовал разные варианты just for fun и выходило примерно шило на мыло
Здравствуйте, Gradiens, Вы писали:
G>Ну то есть кандидату совсем неочевидно, почему "Операцию умножения — не использовать".
Так это же прямая отсылка к сдвигу.
G>И сходу хочется объяснить постановку задачи "придурью интервьювера" G>А вот если сказать "операция критична по времени" — все сразу ясно.
Да не ясно. Еще большой вопрос будет ли сдвиг эффективнее. А вот запрет на умножение прямо говорит про сдвиг.
Все эти сдвиги на практике нужны в первую очередь не для скорости, а для адресации внутри байта, когда есть серьезные ограничения по памяти.
Здравствуйте, Skorodum, Вы писали:
G>>И сходу хочется объяснить постановку задачи "придурью интервьювера" G>>А вот если сказать "операция критична по времени" — все сразу ясно. S>Да не ясно. Еще большой вопрос будет ли сдвиг эффективнее. А вот запрет на умножение прямо говорит про сдвиг. S>Все эти сдвиги на практике нужны в первую очередь не для скорости, а для адресации внутри байта, когда есть серьезные ограничения по памяти.
Ну, конечно, сдвиг много эффективнее. Если не ошибаюсь, он вообще за один такт выполняется.
Запрет на умножение говорит... хз что он говорит, но любые запреты без объяснения причин — дорога в ад.
Что такое адресация внутри байта? чтобы выполнить сдвиг — навиг не нужно ничего адресовать внутри байта. Это атомарная операция. Одна инструкция процессора. Разве нет?
Сдвиги на практике нужны именно что из-за скорости.
А какая память расходуется при умножении? Лично я не вижу, где там перерасход по сравнению со сдвигом.
Здравствуйте, sergey2b, Вы писали:
S>Здравствуйте, Тёмчик, Вы писали: S>Это задачка из К и Р S>И человек знающий про обратную польскую Наталию решит ее за недолго
Сколько дней? С учётом входных данных, например таких: длина числа не более 1024 знака. Длина выражения не более 10 гигабайт. Ну, а что? В условиях про формат ничего не сказано.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Что такое "в повседневной работе"? По десять раз на дню? SVZ>У нас в программе использовались односвязные списки. На основе стандартного вектора, с хранением удаленных элементов, с поддержкой Undo/Redo. SVZ>Использовались для хранения полигонов, проводников на печатной плате. SVZ>При объединении пары списков один из них нужно развернуть.
Зачем?
Здравствуйте, Gradiens, Вы писали:
G>Ну, конечно, сдвиг много эффективнее. Если не ошибаюсь, он вообще за один такт выполняется.
Речь про то, что оптимизатор может превратить умножение/деление в сдвиг. Уже много лет как. И он это 100% сделает в вслучае x * 80.
Это тривиальнейшая оптимизация реализованная много лет назад. Если собеседующий этого не знает...
G>Запрет на умножение говорит... хз что он говорит, но любые запреты без объяснения причин — дорога в ад.
Да нет никаких веских причин. Собеседующий прочитал задачку в интернете вот и все причины.
G>Что такое адресация внутри байта?
Обращение к битам
G>Сдвиги на практике нужны именно что из-за скорости.
Нет. Компиляторы уже умеют это делать сами лет дцать как.
G>А какая память расходуется при умножении? Лично я не вижу, где там перерасход по сравнению со сдвигом.
Битовые операции используются, чтобы один байт памяти использовался для хранения 8 (*) бит информации, а не одного.
Здравствуйте, xarcass, Вы писали:
S>>несколько хороших задачь которымиможно заменить разоворот списка
X>1. Найти смещение знакоместа в видеопамяти (для текстового режима — так проще). Количество знакомест в строке — константа (скажем, 80). Одно знакоместо — один байт. Операцию умножения — не использовать. X> странное дело, но мало кто может решить из тех, с кем я сталкивался
Заполняем константный массив размером 80xRows числами от 0 до 79 и потом, по смещению в массиве получаем смещение знакоместа в видеопамяти. Но вы ведь не этого ждали, правда?
X>2. Повернуть прямоугольную картинку на произвольный угол (без сглаживания). Для простоты допустить, что 1 пиксель — 1 байт.
Здравствуйте, sergey2b, Вы писали:
S>>>Здравствуйте, Тёмчик, Вы писали: S>>>Это задачка из К и Р S>>>И человек знающий про обратную польскую Наталию решит ее за недолго
BFE>>Сколько дней? С учётом входных данных, например таких: длина числа не более 1024 знака. Длина выражения не более 10 гигабайт. Ну, а что? В условиях про формат ничего не сказано. S>А какие операции доступны и можно ли использовать скобки в выражениях
Числа только в десятичной системе исчисления?
Здравствуйте, Ikemefula, Вы писали:
I>"Современных процессоров" довольно большое количество и устроены сильно по разному, соответсвенно качество компиляторов далеко не всегда не высшем уровне.
Неплохо было бы подтвердить свои слова. Найдите компилятор и целевую архитектуру, когда x*80 не будут разложены на сдвиг и сложение.
I>Более того, не все ведь к С++ сводится. Часто это джыт, который, вобщем, сильно дохлый супротив обычного компилятора.
Джытами не пользуюсь, но вот что мне гугл дает:
There’s effectively zero difference between using division versus a shift with numbers this small. Those are nanoseconds, after all. Using a negative number shows no difference in the result.
With this we can now definitely say that replacing value / 2 with value >> 1 offers no benefit. Stop doing it for arithmetic operations and reserve it only for strictly bitwise things!
I>А умножение и сдвиг до сих пор отличаются по производительности, как то так.
Код и бенчмарк в студию.
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, sergey2b, Вы писали:
S>>>>Здравствуйте, Тёмчик, Вы писали: S>>>>Это задачка из К и Р S>>>>И человек знающий про обратную польскую Наталию решит ее за недолго
BFE>>>Сколько дней? С учётом входных данных, например таких: длина числа не более 1024 знака. Длина выражения не более 10 гигабайт. Ну, а что? В условиях про формат ничего не сказано. S>>А какие операции доступны и можно ли использовать скобки в выражениях BFE>Числа только в десятичной системе исчисления?
Здравствуйте, B0FEE664, Вы писали:
BFE>Сколько дней? С учётом входных данных, например таких: длина числа не более 1024 знака. Длина выражения не более 10 гигабайт. Ну, а что? В условиях про формат ничего не сказано.
Стек ведь необязательно держать в памяти. Можно завести в файле, и читать произвольный инпут. Сложность линейная. Вот что делать с арифметической операцией над двумя числами в 1024 знака, это отдельная тема, к задаче не относящаяся.
Здравствуйте, CreatorCray, Вы писали:
X>>Если представить, что у нас есть просто массив байтов (условно двумерный), то для того, чтобы его попиксельно повернуть достаточно базовых знаний тригонометрии. CC>Если делать в лоб то будут глюки типа tearing.
Здравствуйте, Тёмчик, Вы писали:
Тё>Не 3x3 на 3x1, а 2x2 на 2x1.
Тогда это не аффинное преобразование по определению.
Тё>А разве алгоритмическая сложность не C * O(N)? Умножаем матрицу на каждую координату (0..N-1), N раз.
Ну, да. Но константа для аффинного преобразования будет больше раз в... 10!
Здравствуйте, IID, Вы писали:
Тё>>Нужно аффинное преобразование. А это умножение матриц. Быстро умножать матрицы- отдельная, большая (больная) тема.
IID>не нужно там ничего умножать
Эээээ давай своё решение. Там в условии произвольный угол.
Здравствуйте, Тёмчик, Вы писали:
N>>Тогда это не аффинное преобразование по определению. Тё>Да что ты. Пространство ведь 2-мерное. Не хромает ли твоя математика?
Неа. Попробуй своей аффинной матрицей в 2D пространстве задать сдвиг, поворот и масштаб. Если получится — снимаю шляпу и всячески превозношу твой профессионализм.
Тё>Ты это, давай выкладывай свои катеты с гипотенузами, и посчитаем количество операций. Как там будут квадраты и корни квадратные считаться, да ещё и только в целых числах (!).
Здравствуйте, Ikemefula, Вы писали:
I>Для примера, в Атоме сдвиг это 1 такт, умножение 3..6 тактов, div — 9..41. https://software.intel.com/content/dam/develop/public/us/en/documents/intel-atom-tremont-microarchitecture-throughput-and-latency.pdf
Прекрасно, только это ровно ничего не доказывает, т.к. разговор не про то, что в процессоре умножение/деление более дорогая операция чем сдвиг, а про то, что в программе нет смысла заменять умножение на константу на сдвиг.
I>В микроконтроллерах всяких дело будет еще хуже.
Может, но к обсуждаемому случаю это вообще никак не относится.
I>То есть, выиграть есть где.
Конечно есть: если писать на ассемблере. А так нет.
Более того, это намного хуже читается.
I>На счет компилера трудновато будет, я как то давно отошел от таких дел.
Давно это когда? В 2010 это точно уже было в gcc.
Хорошая иллюстрация, что с вопросами на собеседовании надо быть аккуратнее (да, это не вы этот вопрос предложили).
Здравствуйте, Skorodum, Вы писали:
S>Прекрасно, только это ровно ничего не доказывает, т.к. разговор не про то, что в процессоре умножение/деление более дорогая операция чем сдвиг, а про то, что в программе нет смысла заменять умножение на константу на сдвиг.
I>>В микроконтроллерах всяких дело будет еще хуже. S>Может, но к обсуждаемому случаю это вообще никак не относится.
Не надо передёргивать — просто утверждение без конкретики.
I>>То есть, выиграть есть где. S>Конечно есть: если писать на ассемблере. А так нет.
Ты точно в курсе, что все джыты всех языков сделают лучше? А если микроконтроллер?
I>>На счет компилера трудновато будет, я как то давно отошел от таких дел. S>Давно это когда? В 2010 это точно уже было в gcc.
Здравствуйте, sergey2b, Вы писали:
S>несколько хороших задачь которымиможно заменить разоворот списка
Проще можно. На собеседовании предлагаешь кандидату поднять штангу. Поднимет больше 150 килограмм — это сильный программист, сеньер — берем. Поднимет 100 килограмм — это средний программист, много денег не дадим. Пожнимет килограмм 70 — это юниор, этого на стажера в лучшем случае и платить чтоб с голоду не умер. А кто меньше поднимет — это не программисты!
И главное, такое собеседование занимает несколько минут, и можно сравнивать кандидатов! Плохо что удаленно не получится собеседовать, а удаленно кандидат может надувные блины поставить. Ну удаленно можно заставить подтягиваться. Подтянется раз 30 на одной руке — сеньер. 30 раз просто — средний. Подтянулся раз 10 — это юниор, только на стажера потянет.
А то списки какие то, задачки. Совсем собеседовать не умеют, ужас!
S>Все эти сдвиги на практике нужны в первую очередь не для скорости, а для адресации внутри байта, когда есть серьезные ограничения по памяти.
лет 20 назад это было исключительно для скорости. Ибо даже целочисленное умножение было очень медленным. Не говоря уже о том, что на некоторых платформах (старые ARM-ы, например) количество тактов операции умножения зависело от значений операндов.
Здравствуйте, Тёмчик, Вы писали:
BFE>>Сколько дней? С учётом входных данных, например таких: длина числа не более 1024 знака. Длина выражения не более 10 гигабайт. Ну, а что? В условиях про формат ничего не сказано. Тё>Стек ведь необязательно держать в памяти. Можно завести в файле, и читать произвольный инпут. Сложность линейная.
Ага. И всё это расписать прямо на доске.
Тё>Вот что делать с арифметической операцией над двумя числами в 1024 знака, это отдельная тема, к задаче не относящаяся.
Интересные новости про условия задачи!
Здравствуйте, IID, Вы писали:
X>>>2. Повернуть прямоугольную картинку на произвольный угол (без сглаживания). Для простоты допустить, что 1 пиксель — 1 байт. BFE>>Без искажений эта задача не имеет решения.
IID>Картинка на пиксельном мониторе — это уже искажения
Если картинка пиксельная, то какие искажения?
IID>Хинт — у тебя вращение текстурированной херни протестов не вызывает ?
Вызывает.
Здравствуйте, Ikemefula, Вы писали:
I>А если микроконтроллер?
Тогда надо добавить в исходные условия: "есть микроконтроллеи и JIT где операция умножения дорогая и не оптимизируется...".
Иначе такие вопросы больше говорят о квалификации того, кто их задает.
S>>Давно это когда? В 2010 это точно уже было в gcc. I>Цитирую себя "не все ведь к С++ сводится"
Gnu Compiler Collection...
Здравствуйте, sergey2b, Вы писали:
S>>>>>Это задачка из К и Р S>>>>>И человек знающий про обратную польскую Наталию решит ее за недолго BFE>>>>Сколько дней? С учётом входных данных, например таких: длина числа не более 1024 знака. Длина выражения не более 10 гигабайт. Ну, а что? В условиях про формат ничего не сказано. S>>>А какие операции доступны и можно ли использовать скобки в выражениях BFE>>Числа только в десятичной системе исчисления? S>В восьмеричной шестначтиричной или двоичной
Двоичные числа записывать в прямом, обратном или дополнительном коде?
Почему нет поддержки троичной системы?
Здравствуйте, xarcass, Вы писали:
X>лет 20 назад это было исключительно для скорости.
Это никогда не было искючительно для скорости, т.к. доступ к битам требовался всегда.
BFE>>>Числа только в десятичной системе исчисления? S>>В восьмеричной шестначтиричной или двоичной BFE>Двоичные числа записывать в прямом, обратном или дополнительном коде?
наверное более универсально с дополнением до двух
BFE>Почему нет поддержки троичной системы?
Здравствуйте, Skorodum, Вы писали:
I>>А если микроконтроллер? S>Тогда надо добавить в исходные условия: "есть микроконтроллеи и JIT где операция умножения дорогая и не оптимизируется...". S>Иначе такие вопросы больше говорят о квалификации того, кто их задает.
Разумеется, про то уже говорилось, что просто так такие вопросы смысла не имеют.
I>>Цитирую себя "не все ведь к С++ сводится" S>Gnu Compiler Collection...
Здравствуйте, B0FEE664, Вы писали:
BFE>>>Сколько дней? С учётом входных данных, например таких: длина числа не более 1024 знака. Длина выражения не более 10 гигабайт. Ну, а что? В условиях про формат ничего не сказано. Тё>>Стек ведь необязательно держать в памяти. Можно завести в файле, и читать произвольный инпут. Сложность линейная.
BFE>Ага. И всё это расписать прямо на доске.
Тё>>Вот что делать с арифметической операцией над двумя числами в 1024 знака, это отдельная тема, к задаче не относящаяся. BFE>Интересные новости про условия задачи!
Так ты сам усложнил задачу! В исходном сообщении было 2+2 и 2+2*3. Для этого достаточно встроенных операций и памяти под стек.
Здравствуйте, sergey2b, Вы писали:
BFE>>>>Числа только в десятичной системе исчисления? S>>>В восьмеричной шестначтиричной или двоичной BFE>>Двоичные числа записывать в прямом, обратном или дополнительном коде? S>наверное более универсально с дополнением до двух
Без поддержки деления и чисел с плавающей точкой?
Нужна поддержка экспоненциальной формы для целых чисел?
BFE>>Почему нет поддержки троичной системы? S>потому что я ее не знаю
А чего там знать-то: 0,1,2,10,11,12,20,21,22,100,101,... ?
Здравствуйте, alzt, Вы писали:
A>Мозг у людей вообще очень часто выключается. Это обычная эволюционная адаптация — глюкозу надо экономить. A>Но человек, который не напрягает свой мозг, мне на работе не нужен. Человек, который не может это сделать даже на собеседовании — биомусор. Можно нагрузить его какой-то несложной работой, чтобы не повышать преступность, но мне кажется, сразу в биореактор.
Ну тогда, казалось бы, надо поставить перед ним вазочку с конфетами, и посмотреть, сколько сожрет. Сразу станет понятно, как он с глюкозой разбирается: путем отключения мозгофф, или путем пожирания конфет.
Только тут важно учитывать тот момент, что иные кандидаты иные конфеты ни за что жрать не станут.
Здравствуйте, a7d3, Вы писали:
A>Это не работает. Потому что хороший специалист не станет тренироваться решать задачки на собеседованиях, а тот человек, который работать не умеет и ничего из себя не представляет — будет смотреться замечательно на фоне всех остальных. Поскольку у него выбора иного нету.
Ну с другой стороны, я вот список, напремер, разверну и даже отсортирую. Потому, что я и в боевом коде так иногда делаю.
Здравствуйте, wraithik, Вы писали:
W>Интересно, почему мониторы были 80*25, а не 64*32 или 128*32.... Сдвиг вроде быстрее.
Потому, что в перфокарте было 80 символов, а 24 было разумным компромисом между удобством использование и ценой изделия. Почему на PC 24 превратилось в 25, я не знаю, но предполагаю потому, что 25 — это почти 24, и при этом хорошо согласуется с телевизионным стандартом по числу строк.
Здравствуйте, xarcass, Вы писали:
X>Кто в своей повседневной работе использовал разворот односвязного списка — пусть первый бросит в меня камень.
Я использовал. Подставляй голову.
P.S. Я даже умудрился в повседневной работе использовать функцию, которая переставляет местами две "половины" массива разного размера, используя O(1) дополнительной памяти и за время O(n):
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Gradiens, Вы писали:
G>>Ну, конечно, сдвиг много эффективнее. Если не ошибаюсь, он вообще за один такт выполняется.
Pzz>А за сколько тактов выполняется умножение на современном Пентиуме?
Адептам разворота списка пора переходить в следующее измерение — задавать повернуть квадратную матрицу на угол кратный 90° inplace, без использования дополнительной памяти.
Или оставаться в 1D, но двигаться дальше — циклический сдвиг массива на k N позиций влево или вправо, само собой, тоже inplace.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, a7d3, Вы писали:
A>>Это не работает. Потому что хороший специалист не станет тренироваться решать задачки на собеседованиях, а тот человек, который работать не умеет и ничего из себя не представляет — будет смотреться замечательно на фоне всех остальных. Поскольку у него выбора иного нету.
Pzz>Ну с другой стороны, я вот список, напремер, разверну и даже отсортирую. Потому, что я и в боевом коде так иногда делаю.
Вопрос же не в том можешь или нет. А тех обстоятельствах, в которых тебя вынуждают этим заниматься.
Мне жаловались разные люди, что обстановка на собеседованиях не располагает ни разу, к такого рода занятиям. Грубо говоря пыхтеть на листочке бумаги ручкой, когда рядом восседает откровенно зевающий собеседователь.
Т.е. задачка дерьмо, потому что есть лишь один годный вариант решения, но есть ряд вариантов облажаться при этом. Проверить мышление-рассуждение кандидата задачка не позволяет. Даётся задачка в таких обстоятельствах, что почти наверняка нетренированный человек в чём-нибудь да ошибётся. И в этом ожидании ошибки от кандидата и весь смысл, весь сок давания данной задачи. Чтобы у собеседующего появилась возможность ткнуть кандидата в некую ошибку в некой очень простетской задачке.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, a7d3, Вы писали:
A>>На данный момент, выявлено две жуткие дурости, т.е. придётся осознать две вещи: A>>1. на собеседовании квалификацию не показывают, это не испытание кандидатов A>>2. собеседование проводят не для того, чтобы кандидатов между собой сравнивать
I>Для чего проводят собеседование?
Для того чтобы людей подбирать?
Так и откуда же тогда взялась вся эта дурь, что двумя пунктами выше процитирована?
Ещё раз, через собеседование людей подбирают, а не отбирают.
Здравствуйте, a7d3, Вы писали:
A>Вопрос же не в том можешь или нет. А тех обстоятельствах, в которых тебя вынуждают этим заниматься. A>Мне жаловались разные люди, что обстановка на собеседованиях не располагает ни разу, к такого рода занятиям. Грубо говоря пыхтеть на листочке бумаги ручкой, когда рядом восседает откровенно зевающий собеседователь.
Ну вообще говоря, собеседующему лучше на некоторое время выйти, показав собеседуемому тропинку к сортиру и к источнику чая с крекерами, или чем там изба богата.
A>Т.е. задачка дерьмо, потому что есть лишь один годный вариант решения, но есть ряд вариантов облажаться при этом. Проверить мышление-рассуждение кандидата задачка не позволяет. Даётся задачка в таких обстоятельствах, что почти наверняка нетренированный человек в чём-нибудь да ошибётся. И в этом ожидании ошибки от кандидата и весь смысл, весь сок давания данной задачи. Чтобы у собеседующего появилась возможность ткнуть кандидата в некую ошибку в некой очень простетской задачке.
По таким задачкам видно, склонен ли соискатель проверять, например, корректность входных данных. Хотя эта, наверное, даже и для этой цели слишком проста.
Пришла идея ещё одной бессмысленной задачи на собеседовании — написать "универсальную" функцию, которая может использоваться для обхода двусвязного списка как в прямом, так и в обратном направлении.
Здравствуйте, Skorodum, Вы писали:
I>>Более того, не все ведь к С++ сводится. Часто это джыт, который, вобщем, сильно дохлый супротив обычного компилятора. S>Джытами не пользуюсь, но вот что мне гугл дает: S>
S>There’s effectively zero difference between using division versus a shift with numbers this small. Those are nanoseconds, after all. Using a negative number shows no difference in the result.
S>With this we can now definitely say that replacing value / 2 with value >> 1 offers no benefit. Stop doing it for arithmetic operations and reserve it only for strictly bitwise things!
Это написано чтобы люди перестали в С коде фигачить shifts везде где ни попадя. Компилятор же вполне может поменять div на shr.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Тёмчик, Вы писали:
N>>А почему не перспективное? А почему матриц, а не матрицу на вектор? А нужна ли там вообще матрица? Тё>Представить каждый пиксел как вектор координатами (x,y) и умножать на матрицу афинного преобразования, по аналогии с 3d.
Это ты щас ядрёной боНбой по таракану собрался бить.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, xarcass, Вы писали:
X>Тут то и нюанс. Многие начинают обходить source буфер. И всё — приплыли.
Ага, у таких появляются "дырки" в результате.
Знал людей которые упирались и ни в какую не хотели "перевернуть" логику и ходить таки по destination, ибо "так будет дольше!" и упорно изобретали велосипед по предотвращению tears.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, IID, Вы писали:
IID>tearing то откуда возьмётся ?
Не тот tearing который VSync, а когда результат получается с прорехами, когда итерацию делают не по dest а по src.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, PM, Вы писали:
PM>Дополнительный бонус за решение без if
Да банальный pointer arithmetic, использование bool параметра для выбора который из двух указателей в парах next/prev head/tail брать через "pointerPtr[param]"
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Pzz, Вы писали:
Pzz>P.S. Я даже умудрился в повседневной работе использовать функцию, которая переставляет местами две "половины" массива разного размера, используя O(1) дополнительной памяти и за время O(n):
Pzz>[AAAAA][BBBBBBBBBBBBBB] -> [BBBBBBBBBBBBBB][AAAAA]
CC> результат получается с прорехами, когда итерацию делают не по dest а по src.
Логичный результат. Если из src считать dst- будут "прорехи", но если из dst считать src- будут "складки". Очевидно, можно проецирующую координату оставить в double без округления, и копировать субпиксельно, т.е. раскидывать на "пятно" из покрытых координатой пикселов. Либо если reverse- брать значение пиксела с покрытого пятна из нескольких пикселов, в пропорциях покрытия. Либо почитать про билинейную фильтрацию.
Здравствуйте, Pzz, Вы писали:
Тё>>Так это разворот строки
Pzz>Нет.
Pzz>[0123456][ABCDEFGHIJKLMNOPQR] -> [ABCDEFGHIJKLMNOPQR][0123456]
Pzz>Так понятнее?
Pzz>И да, это эквиавалентно упомянутому здесь циклическому сдвигу массива in place.
Ты так и не понял? ел кашу->кашу ел. Разворот строки, как он есть.
Здравствуйте, Тёмчик, Вы писали:
Тё>Очевидно, можно проецирующую координату оставить в double без округления, и копировать субпиксельно, т.е. раскидывать на "пятно" из покрытых координатой пикселов. Либо если reverse- брать значение пиксела с покрытого пятна из нескольких пикселов, в пропорциях покрытия. Либо почитать про билинейную фильтрацию.
Ты уже "не сдал", ещё с матрицами, чего уж теперь суетиться?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Тёмчик, Вы писали:
CC>> результат получается с прорехами, когда итерацию делают не по dest а по src.
Тё>Логичный результат. Если из src считать dst- будут "прорехи", но если из dst считать src- будут "складки". Очевидно, можно проецирующую координату оставить в double без округления, и копировать субпиксельно, т.е. раскидывать на "пятно" из покрытых координатой пикселов. Либо если reverse- брать значение пиксела с покрытого пятна из нескольких пикселов, в пропорциях покрытия. Либо почитать про билинейную фильтрацию.
Для практического применения правильный подход это итерироваться по src, а в матрицу dst складывать не пиксели, а списки коржетей (цвет, процент заполнения пикселя). То бишь берём пиксель как квадратик из src, поворачиваем его на dst и смотрим на какие квадратики он ложится и процент того, сколько этого пикселя попало на какой пиксель. А после этого уже считаем конечный dst, смешивая цвета (и там формула сложней, чем просто сложить r g b).
А если делать ещё правильней, то, возможно, надо учитывать особенности матрицы у пользователя: монитор ведь не квадратики рисует, а каждый пиксель рисуется несколькими разноцветными прямоугольниками.
Здравствуйте, vsb, Вы писали:
vsb>Для практического применения правильный подход это итерироваться по src, а в матрицу dst складывать не пиксели, а списки коржетей (цвет, процент заполнения пикселя).
Идём по матрице dst, считаем проекцию на src, какие пикселы покрыла с какими пропорциями. Накрыла один 100%- копируем. Накрыла 3 с 20, 50, 30%- складываем по отдельности (r1 * 20 + r2 * 50 + r3 * 30) / 100 и записываем r в dst. Либо если прямая проекция- накидывать в dst на точки в пропорции от покрытия, (субпиксельно).
vsb> после этого уже считаем конечный dst, смешивая цвета (и там формула сложней, чем просто сложить r g b).
В смысле разбивать на яркость и цветность? Разве просто сложить цвета в пропорции не даст нужный результат?
vsb>А если делать ещё правильней, то, возможно, надо учитывать особенности матрицы у пользователя: монитор ведь не квадратики рисует, а каждый пиксель рисуется несколькими разноцветными прямоугольниками.
Да, но разве это не оверкил?
Здравствуйте, vsb, Вы писали:
Pzz>>Разворот, это ел кашу->ушак ле
vsb>ел кашу -> ле кашу -> ле ушак -> кашу ел
vsb>Получается два разворота, но сложность остаётся O(N).
Здравствуйте, Тёмчик, Вы писали:
Pzz>>Разворот, это ел кашу->ушак ле
Тё>А теперь ушак->кашу, ле-ел. Элегантно, коротко вместо извращения с сдвигами.
Но это не один разворот, а три. И в результате получается циклический сдвиг. Не в том смысле, что кто-то N раз сдвигает массив на один шаг, а в том, что результат эквиавалентен циклическому сдвигу.
Здравствуйте, Тёмчик, Вы писали:
vsb>>Для практического применения правильный подход это итерироваться по src, а в матрицу dst складывать не пиксели, а списки коржетей (цвет, процент заполнения пикселя). Тё>Идём по матрице dst, считаем проекцию на src, какие пикселы покрыла с какими пропорциями. Накрыла один 100%- копируем. Накрыла 3 с 20, 50, 30%- складываем по отдельности (r1 * 20 + r2 * 50 + r3 * 30) / 100 и записываем r в dst. Либо если прямая проекция- накидывать в dst на точки в пропорции от покрытия, (субпиксельно).
Ну да, так лучше.
vsb>> после этого уже считаем конечный dst, смешивая цвета (и там формула сложней, чем просто сложить r g b). Тё>В смысле разбивать на яркость и цветность? Разве просто сложить цвета в пропорции не даст нужный результат?
Насколько я знаю — с научной точки зрения нет.
vsb>>А если делать ещё правильней, то, возможно, надо учитывать особенности матрицы у пользователя: монитор ведь не квадратики рисует, а каждый пиксель рисуется несколькими разноцветными прямоугольниками. Тё>Да, но разве это не оверкил?
Не знаю (: У тех же шрифтов антиалиасинг это учитывает, значит для них не оверкил.
Здравствуйте, Тёмчик, Вы писали:
Тё>Формула с синусами-косинусами- это продукт матрица вращения на вектор. Матрица вращения- частный случай аффинной матрицы.
"Забъём гвоздь по шляпку, тем самым сведём задачу к предыдущей, которую мы знаем как решать" (С)
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, vsb, Вы писали:
vsb>Не знаю (: У тех же шрифтов антиалиасинг это учитывает, значит для них не оверкил.
Ты хоть раз видел как у нормального шрифтового движка оно внутри устроено? Там нефиговая такая неонка, чтоб и читаемо получалось и быстро работало.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Nuzhny, Вы писали:
N>С такими ответами, как "применить афинное преобразование" для поворота картинки ты пролетишь, как не умеющий размышлять, а лишь применять типовые решения.
Ровно наоборот. Матрица даст надёжный результат. Когда(если) хватит производительстности — можно углубиться в тему и оптимизировать, скажем, что бы были целочисленные операции.
Незачем струячить низкоуровневый код абы похвастаться знанием редкоиспользуемых вещей.
Здравствуйте, Nuzhny, Вы писали:
N>Я не готов изобретать велосипед, потому что никакого велосипеда тут нет. Никто в здравом уме не будет поворачивать картинку аффинным преобразованием. Если это надо делать быстро на CPU, то умножение матрицы (3х3) на вектор (3х1) будет слишком медленным, когда можно сделать в несколько раз быстрее (в целых числах в том числе). Если же на GPU, то float, но тоже не умножением матриц.
Слишком медленно это непонятно. Какие требования к производительсности и насколько критична эта разница в производительности и сколько там в процентах?
N>Призываю посчитать, сколько операций надо для поворота картинки, а сколько для аффинного преобразования: в аффинном случае у тебя для каждого пикселя будет 4 лишних умножения на 0, 3 лишних умножения на 1, 4 лишних операции сложения. Не оверкилл?
На такие вещи даёт ответ профайлер. Обсуждать "быстрее или нет" без внятных требований к производительность это по моему редкий зашквар.
Здравствуйте, Skorodum, Вы писали:
I>>А если микроконтроллер? S>Тогда надо добавить в исходные условия: "есть микроконтроллеи и JIT где операция умножения дорогая и не оптимизируется...". S>Иначе такие вопросы больше говорят о квалификации того, кто их задает.
Это ты почти что ответ сообщаешь. "есть микроконтроллер ХХХ, профайлер показывает, что педалит <вот этот код>. Как оформить максимально производительный вариант?"
Ответы могут быть самыми разными — от "подкрутить <этот компилер>", "взять <вот ну либу>" до "переписать <вот этот код> <вот таким способом>"
И если товарищ хотя бы идентифицировал проблему, это уже большой плюс. А если еще и решение нашел — вообще шикарно.
Собственно, я бы такое спрашивал если работа связана со вполне конкретными вещами да на горящую позицию. В других случах стоит переключиться на что другое.
Здравствуйте, IID, Вы писали:
Pzz>>А тебе как больше понравится, strstr в цикле, или алгоритм Морисса-Пратта на пальцах объяснить?
IID>мне больше скользящий (rolling) хеш нравится. Реализация тривиальная, а по скорости не особо уступает моррису-пратту.
Я хочу сказать, что и тому и другому не место, например, при чтении конфигурационного файла. Да, программа будет стартовать не три секунды, а аж на целых 5 миллисекунд больше. Но зато код будет понятным и чистым.
Здравствуйте, Ikemefula, Вы писали:
N>>С такими ответами, как "применить афинное преобразование" для поворота картинки ты пролетишь, как не умеющий размышлять, а лишь применять типовые решения.
I>Ровно наоборот. Матрица даст надёжный результат. Когда(если) хватит производительстности — можно углубиться в тему и оптимизировать, скажем, что бы были целочисленные операции.
Дак там формула с синусами-косинусами, это как раз продукт матрицы на вектор.
I>Незачем струячить низкоуровневый код абы похвастаться знанием редкоиспользуемых вещей.
Это не низкоуровневый код, а демонстрация недружбы с линейной алгеброй.
Здравствуйте, Тёмчик, Вы писали:
N>>>С такими ответами, как "применить афинное преобразование" для поворота картинки ты пролетишь, как не умеющий размышлять, а лишь применять типовые решения.
I>>Ровно наоборот. Матрица даст надёжный результат. Когда(если) хватит производительстности — можно углубиться в тему и оптимизировать, скажем, что бы были целочисленные операции.
Тё>Дак там формула с синусами-косинусами, это как раз продукт матрицы на вектор.
Именно что синусы да косинусы. Вопрос в цене оптимизации и спросе на неё. Раз в неделю — точно хватит матрицы, а если 100 раз в секунду конскую картинку поворачивать на фиксированый угол — это совсем другое.
I>>Незачем струячить низкоуровневый код абы похвастаться знанием редкоиспользуемых вещей. Тё>Это не низкоуровневый код, а демонстрация недружбы с линейной алгеброй.
Алгебра алгеброй, но если, для примера, 100% времени только и делаешь, что поворачиваешь картинки, то надо оптимизировать вусмерть. И тогда матричное умножение мягко говоря не лучший вариант.
Здравствуйте, Ikemefula, Вы писали:
Тё>>Это не низкоуровневый код, а демонстрация недружбы с линейной алгеброй.
I>Алгебра алгеброй, но если, для примера, 100% времени только и делаешь, что поворачиваешь картинки, то надо оптимизировать вусмерть. И тогда матричное умножение мягко говоря не лучший вариант.
Здравствуйте, Тёмчик, Вы писали:
I>>Алгебра алгеброй, но если, для примера, 100% времени только и делаешь, что поворачиваешь картинки, то надо оптимизировать вусмерть. И тогда матричное умножение мягко говоря не лучший вариант.
Тё>Да блин ну же! Формула синусов с косинусами и есть матричное произведение 2x2 матрицы вращения на координату! Тё>https://socratic.org/questions/if-you-multiply-a-2x2-matrix-and-a-2x1-matrix-the-product-is-a-2x1-matrix
Спасибо, капитан Очевидность! Ты реально не в курсе, что это можно примерно раз 5-10 сделать быстрее, если заменить целочисленными инплейс трансформациями?
Здравствуйте, Тёмчик, Вы писали:
Pzz>>Но это не один разворот, а три. И в результате получается циклический сдвиг. Не в том смысле, что кто-то N раз сдвигает массив на один шаг, а в том, что результат эквиавалентен циклическому сдвигу.
Тё>2*O(N), элегантное решение за 5 минут. Или исписанная доска и нерабочее решение через 30 минут. Или нечитабельная портянка в функции на экран. Константой в большинстве случаев можно пренебречь.
Я не понимаю, ты с чем споришь?
Я не оспариваю твое решение. Я делаю дополнительное утверждение, что твое решение подходит еще и для задачи о циклическом сдвиге. Потому, что это эквиавалентные задачи.
Ты правда этого не видишь даже после 2-х попыток объяснения?
Приведи пример "целочисленными инплейс трансформациями". Вот я думаю, что вызвать специализированную матричную функцию из библиотеки может оказаться быстрее, чем вручную формула синусов-косинусов.
Здравствуйте, Тёмчик, Вы писали:
I>>Спасибо, капитан Очевидность! Ты реально не в курсе, что это можно примерно раз 5-10 сделать быстрее, если заменить целочисленными инплейс трансформациями?
Тё>Приведи пример "целочисленными инплейс трансформациями". Вот я думаю, что вызвать специализированную матричную функцию из библиотеки может оказаться быстрее, чем вручную формула синусов-косинусов.
Специализированая библиотека — это ответ на все случаи жизни.
Вопрос в том, что там унутре — честное матричное умножение с оптимизациями, или же частные случаи подогнанные конкретно под твой вариант. Понятно, что основа будет из тех самых преобразований. Вопрос только в том, как именно ты будешь вычислять конкретную координату — матричным способом или частными случаями. И вот второй вариант поддаётся гораздо более глубоким оптимизациям, так как просто больше сведений о том, что нужно конкретно сейчас.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, a7d3, Вы писали:
I>>>Для чего проводят собеседование?
A>>Для того чтобы людей подбирать?
I>Подбирать по какому принципу?
Собеседование людей — это деятельность, с какой-то однозначной целью.
Вот от этой цели и зависит подход с принципами.
Зачем же всегда и всех одним и тем же образом подбирать?
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, a7d3, Вы писали:
A>>Вопрос же не в том можешь или нет. А тех обстоятельствах, в которых тебя вынуждают этим заниматься. A>>Мне жаловались разные люди, что обстановка на собеседованиях не располагает ни разу, к такого рода занятиям. Грубо говоря пыхтеть на листочке бумаги ручкой, когда рядом восседает откровенно зевающий собеседователь.
Pzz>Ну вообще говоря, собеседующему лучше на некоторое время выйти, показав собеседуемому тропинку к сортиру и к источнику чая с крекерами, или чем там изба богата.
Боятся, что кинется искать в инете решение с мобильного телефона, которые ныне почти планшеты
А глушилку мобильной связи ставить полагают бесполезным, потому как будут приходить со сборниками таких задачек с решениями.
A>>Т.е. задачка дерьмо, потому что есть лишь один годный вариант решения, но есть ряд вариантов облажаться при этом. Проверить мышление-рассуждение кандидата задачка не позволяет. Даётся задачка в таких обстоятельствах, что почти наверняка нетренированный человек в чём-нибудь да ошибётся. И в этом ожидании ошибки от кандидата и весь смысл, весь сок давания данной задачи. Чтобы у собеседующего появилась возможность ткнуть кандидата в некую ошибку в некой очень простетской задачке.
Pzz>По таким задачкам видно, склонен ли соискатель проверять, например, корректность входных данных. Хотя эта, наверное, даже и для этой цели слишком проста.
Именно, с какой стороны ни смотришь на такие задачки, а использование их на собеседование оказывается полным идиотизмом.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну вообще говоря, собеседующему лучше на некоторое время выйти, показав собеседуемому тропинку к сортиру и к источнику чая с крекерами, или чем там изба богата.
Это говно а не собеседование. Цель собеседования — увидеть может ли собеседуемый соображать. Готовое решение нафиг никому не надо, надо продемонстрировать способность это решение придумать.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, a7d3, Вы писали:
I>>Подбирать по какому принципу?
A>Собеседование людей — это деятельность, с какой-то однозначной целью. A>Вот от этой цели и зависит подход с принципами.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, a7d3, Вы писали:
I>>>Подбирать по какому принципу?
A>>Собеседование людей — это деятельность, с какой-то однозначной целью. A>>Вот от этой цели и зависит подход с принципами.
I>А можно на примере? Ничего ведь не понятно.
Ну тебе доверяют людей отбирать через собеседование, а кого именно и куда конкретно? На какую работу в какой проект, на какие задачи и сферу ответственности?
Вопрос риторический, не требует ответа здесь, а лишь наводит на мысль куда думать, чтобы понятно стало.
Здравствуйте, CreatorCray, Вы писали:
CC>Это говно а не собеседование. Цель собеседования — увидеть может ли собеседуемый соображать. Готовое решение нафиг никому не надо, надо продемонстрировать способность это решение придумать.
"Придумать" != "придумать, когда у тебя над душой стоят". Второе качество ценно для публичного человека или для продавца подержанных автомобилей, но совершенно не обязательно для инженера.
Здравствуйте, Ikemefula, Вы писали:
I>>>Спасибо, капитан Очевидность! Ты реально не в курсе, что это можно примерно раз 5-10 сделать быстрее, если заменить целочисленными инплейс трансформациями?
Тё>>Приведи пример "целочисленными инплейс трансформациями". Вот я думаю, что вызвать специализированную матричную функцию из библиотеки может оказаться быстрее, чем вручную формула синусов-косинусов.
I> Специализированая библиотека — это ответ на все случаи жизни.
Это ответ на быстрое умножение матриц.
I>Вопрос в том, что там унутре — честное матричное умножение с оптимизациями, или же частные случаи подогнанные конкретно под твой вариант.
Поворот на произвольный угол (не на n * PI/2)- там не частные случаи, а честное умножение. Которое вручную в лучшем случе не уступит специализированной функции, в худшем- уступит.
I> Понятно, что основа будет из тех самых преобразований. Вопрос только в том, как именно ты будешь вычислять конкретную координату — матричным способом или частными случаями.
А ты собрался сравнивать с Pi/2 и делать 2 реализации?
Здравствуйте, a7d3, Вы писали:
I>>А можно на примере? Ничего ведь не понятно.
A>Ну тебе доверяют людей отбирать через собеседование, а кого именно и куда конкретно? На какую работу в какой проект, на какие задачи и сферу ответственности? A>Вопрос риторический, не требует ответа здесь, а лишь наводит на мысль куда думать, чтобы понятно стало.
Вот у нас есть 10 потенциальных кандидатов на позицию сеньора, node.js, web application, позицию нужно закрыть где то месяца за два.
Каким образом понять, какой должен быть подход в данном случае? Чего тебе не хватает это самый подход продемонстрировать?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, a7d3, Вы писали:
I>>>А можно на примере? Ничего ведь не понятно.
A>>Ну тебе доверяют людей отбирать через собеседование, а кого именно и куда конкретно? На какую работу в какой проект, на какие задачи и сферу ответственности? A>>Вопрос риторический, не требует ответа здесь, а лишь наводит на мысль куда думать, чтобы понятно стало.
I>Вот у нас есть 10 потенциальных кандидатов на позицию сеньора, node.js, web application, позицию нужно закрыть где то месяца за два.
I>Каким образом понять, какой должен быть подход в данном случае? Чего тебе не хватает это самый подход продемонстрировать?
Бесполезно демонстрировать подобное когда у собеседника нет понимания базовых/элементарных вещей.
1) Рабочей единицей является не отдельно взятый сотрудник, а команда. Человек нанимается в качестве сотрудника на некую роль в конкретную команду.
2) Понятие роли в проекте/команде — это не тоже самое, что понятие квалификации у фрезеровщика или сварщика (пятый-шестой разряд).
3) Если среди кандидатов оставить лишь профессионалов с хорошей квалификацией, годных на роль синьора, то далеко не каждый из них подойдёт в конкретную команду.
Прописные истину тут в том, что люди в проектной работе не являются взаимозаменяемыми болтиками или одинаковыми кирпичами. Да, незаменимых у нас нету, но это и не означает, что все люди одинаковые болтики. Во-вторых, как в компании не бывает двух главбухов или двух техдиров, так и не все люди уживаются в рамках одной команды/проекта по этим же самым причинам, даже если их развести по различным направлениям в одном проекте.
Подбор строится на том, что нет понятия «незакрытая вакансия в компанию» — есть не полностью укомплектованный экипаж в конкретной команде. Только очень убогие компании не знают, что производительность отдельного сотрудника в разы меньше, чем у того же самого сотрудника, но работающего в подходящей команде.
Берём этих самых 10 кандидатов и смотрим, кто из них подходит на роль условного синьора вот в эту вот команду, а кого лучше туда не брать.
И общий вектор такой, что если кандидату по итогам собеседования не сделали оффера, то это ни в коем случае не про его профессионализм или квалификацию. Просто в данный момент нужны люди лишь вот в эту вот команду, на такую-то роль с задачами в таком-то проекте. И собеседование служит для того, чтобы подобрать человека исходя именно из этой вот всей специфики — конкретной команды и предстоящих обязанностей с ответственностью.
Здравствуйте, Тёмчик, Вы писали:
I>> Специализированая библиотека — это ответ на все случаи жизни. Тё>Это ответ на быстрое умножение матриц.
Быстрое умножение матриц не самоцель. Можно сэкономить если отказаться от матричного умножения и перейти к частным случаям под каждую задачу.
I>>Вопрос в том, что там унутре — честное матричное умножение с оптимизациями, или же частные случаи подогнанные конкретно под твой вариант. Тё>Поворот на произвольный угол (не на n * PI/2)- там не частные случаи, а честное умножение. Которое вручную в лучшем случе не уступит специализированной функции, в худшем- уступит.
А кто сказал, что всегда требуется этот произвольный угол? Ты точно уверен, что все задачи этого требуют?
I>> Понятно, что основа будет из тех самых преобразований. Вопрос только в том, как именно ты будешь вычислять конкретную координату — матричным способом или частными случаями. Тё>А ты собрался сравнивать с Pi/2 и делать 2 реализации?
Зачем сравнивать? И почему только Pi/2 ?
Вообще, целочисленные вычисления нынче актуальны в каких микроконтроллерах, где хилая поддержка плавающей запятой. Там до сих пор актуально все вычисления делать целочисленными, но обычно этим библиотека занимается. Целочисленная механика быстрее эмуляции плавающей запятой раз в десять. Тем не менее, разница между честным матричным умножением и оптимизированым частным случаем будет играть в любом процессоре.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, a7d3, Вы писали:
A>>не считают нужным всех и вся сразу же допускать до system design interview,
L>И самое забавное, что сами же интервьюверы во время system design interview жидко обгаживаются, показывая полное непонимание особенностей system, которую они типа хотят design.
Подавляющая масса компаний предпочитает использовать карго-культ, вместо того чтобы работать.
Раз известные компании стали использовать system design interview, то любители карго-культа и профанаций тут же начинают «соответствовать трендам». Типа хоть у них и рязанского розлива, но чтоб выглядело как в лучших домах Лондона с Парижем.
Здравствуйте, a7d3, Вы писали:
A>Подавляющая масса компаний предпочитает использовать карго-культ, вместо того чтобы работать. A>Раз известные компании стали использовать system design interview, то любители карго-культа и профанаций тут же начинают «соответствовать трендам». Типа хоть у них и рязанского розлива, но чтоб выглядело как в лучших домах Лондона с Парижем.
system design interview было в тренде последние лет двадцать как раз в мелких конторах.
В крупных да известных большей частью то гномиков, то реверс строки, то сто баззвордов, то еще что нибудь
Здравствуйте, Ikemefula, Вы писали:
L>>И самое забавное, что сами же интервьюверы во время system design interview жидко обгаживаются, показывая полное непонимание особенностей system, которую они типа хотят design. I>Это необоснованое обобщение. Куда ни вижу твой ник, у тебя нечто вида "все <категория> дураки"
Ты никак конспектируешь за мной?
Право, не стоит. Меня смущает такое внимание к моей скромной персоне.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, a7d3, Вы писали:
A>>Подавляющая масса компаний предпочитает использовать карго-культ, вместо того чтобы работать. A>>Раз известные компании стали использовать system design interview, то любители карго-культа и профанаций тут же начинают «соответствовать трендам». Типа хоть у них и рязанского розлива, но чтоб выглядело как в лучших домах Лондона с Парижем.
I>system design interview было в тренде последние лет двадцать как раз в мелких конторах.
А когда компания перестаёт быть мелкой конторой?
400-600 сотрудников — это какая? А если 1200-1300 или 3500-3700 персонала?
Вот эти калибры использовали и используют system design interview.
I>В крупных да известных большей частью то гномиков, то реверс строки, то сто баззвордов, то еще что нибудь
Некоторые крупные софтовые таким грешат, когда рассматривают кандидата как «сырой талант». Либо, это непонятно кто совсем уж «с улицы по объявлению» сам подавшийся и без референса.
Т.е. вопрос опять же упирается в классику — что личный/субъективный опыт не показатель, у всех по-разному бывает, а говорить за всех сразу — себе дороже.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, a7d3, Вы писали:
A>>Куда мне тягаться с таким зубром, когда за последние 20 лет довелось провести не более четырех-пяти сотен собеседований.
I>4-5 сотен это сравнительно немного. Про собеседовании 1 раз в неделю это примерно 50 собеседований в год, за двадцать лет должно быть около 1000. I>4-5 сотен берется ориентировочно за несколько лет регулярных собеседований.
Для примера, сотня сотрудников и текучка пять процентов — каждый год надо нанимать пять новых человек. Это и выливается в 20-25 собеседований за год.
А на кой лад регулярные собеседования проводить? Заняться больше не чем?
Или же собеседователь настолько «хороший» сотрудник, что его не допускают до реальной работы?
>> Замерять квалификацию на собеседованиях — это надо сильно головой ушибиться. I>Где ты видишь, что я предлагаю "замерять квалификацию"? Я вижу что задаю тебе вопросы и пока что не получил внятных ответов.
Вытекало с той точки диалога, где было про задачки со сдвигами. Где было видно путаницу между ролью и квалификацией. Т.е. непонимание того, что сеньор-помидор является не квалификацией, а ролью.
I>Чуть ниже ты сам, фактически, утверждаешь, что некто подходит лучше, некто хуже, то есть, надо бы сравнить, что бы понять эту лучшесть-хужесть. I>Лучше-хуже — это и есть сравнение. На всякий случай, мало ли, вдруг ты не в курсе.
Не означает.
Доводилось видеть мозаичное панно или пазлы всякие собирать? Результат достигается подбором тех кусочков, которые нужны в конкретном месте. Не решают эту задачу сравниванием меж собой имеющихся кусочков, потому как профанация будет.
Для меня вообще нет выгоды форматировать сознание кому-либо на эту тему. Конкуренция за кадры на рынке труда не располагает Чем хуже людей собеседуют в других местах, тем лучше для меня.
Здравствуйте, Gradiens, Вы писали:
vsb>>ел кашу -> ле кашу -> ле ушак -> кашу ел
vsb>>Получается два разворота, но сложность остаётся O(N).
G>Месье знает толк в извращениях ))
Ну это типа одна из стандартных задачек на собеседованиях, месье их проглядывал в своё время (:
I>И опять у тебя все к сравнению сводится. Как ни крути, а сравнивать приходится, что ты сам же и демонстрируешь уже в который раз.
Как я понял, a7d3 предлагает сравнивать людей с требованиями вакансии, а не между собой.
I>Более того — ты уже с десяток раз ушел от ответа, как быть, если есть три годных кандидата на одну позицию, кого брать.
Предположу, что после нахождения подходящего, перестают тратить время на собеседования. Но, да, было бы лучше, если бы a7d3 сам ответил.
Вообще, повсеместная практика — отсобеседовать сотню кандидатов на вакансию, найти 10 подходящих и из них выбирать лучшего, чревата кучей негатива в виде 99 человек, не прошедших собеседование. И для того, чтобы его сгладить придется постараться, а для этого собеседование проводить должны реально лучшие кадры, чтобы кандидат получил и кучу позитива и узнал много чего полезного для себя. Также после негативного отзыва дать обратную связь, что следует улучшить и почему (причем не "на отвяжись", т.к. это лишь усугубит ситуацию, а по делу и конструктивно, т.е. этим должен будет заниматься не рекрутер, а опять же толковый технарь с прокаченными софт скилами). Иначе 99 человек будут знать кто их отшил, но не понимать почему, а отсутствие информации — все что нужно для разных теорий заговоров (которыми охотно делятся на форумах)...
В этом плане стратегия взять первого подходящего сильно лучше.
Здравствуйте, Reset, Вы писали:
I>>И опять у тебя все к сравнению сводится. Как ни крути, а сравнивать приходится, что ты сам же и демонстрируешь уже в который раз.
R>Как я понял, a7d3 предлагает сравнивать людей с требованиями вакансии, а не между собой.
Разумеется, что сравнивают по результатам собеседования. При нормальном подходе эти результаты отражают и профиль работы, и уровень квалификации, хотя и приблизительно, и интересы, и соответствие резюме и много чего еще. То есть, результатов достаточно, что бы сделать определенные предположения, кто лучше подходит на позицию.
I>>Более того — ты уже с десяток раз ушел от ответа, как быть, если есть три годных кандидата на одну позицию, кого брать. R>Предположу, что после нахождения подходящего, перестают тратить время на собеседования. Но, да, было бы лучше, если бы a7d3 сам ответил.
Я бы не сказал, что первый подходящий это всегда хорошая тактика. Пока есть время, стоит проверить побольше.
R>Вообще, повсеместная практика — отсобеседовать сотню кандидатов на вакансию, найти 10 подходящих и из них выбирать лучшего, ... R>В этом плане стратегия взять первого подходящего сильно лучше.
Это зависит от того, куда берут людей. Если прямо к себе в команду, то, как правило, собеседований немного. А вот если в команду к заказчику которые попросит второй раунд, то цепочка удлинняется. Любого к заказчику не подсунешь, заказчик может и завернуть.
Если берут просто в контору, то обычно на вакансию меньше всего собеседований, просто минимальная планка, которая всем известна.
В любом случае приходится сравнивать и от этого никуда не уйти.
Здравствуйте, a7d3, Вы писали:
I>>Ога. Этот зонтик, в частности, обеспечивает обычно единые процессы. Например, рекрутинг общий для всех. От отдела к отделу могут меняться правила, непринципиально.
A>Нет, это не так, в том числе и в тех компаниях, которые на 3500-3700 сотрудников или 13-25 тысяч.
Прям так и вижу — по отделу рекрутинга на каждую команду, по процессу, лучше два, на каждый случай найма.
I>>Вот и считай эти три сотни. В средней софтверной конторе одних разработчиков будет раза в два-три больше.
A>Софтверная компания делающая программные продукты исходит с того, что себестоимость продукта лишь на 15-25% состоит из затрат на разработчиков с тестерами и дизайнерами с техписами. Остальные 75-85% приходятся на другие подразделения компании. A>(три сотни разрабов + две сотни тестеров) × 100/25 = компания две тысячи человек.
Ужос, тебя привлекают к собеседованиям уборщиков, специалистов по обслуживанию зданиях, вахтеров, охраны, бухгалтеров, офис-менеджеров, маркетологов?
Если три сотни разрабов, значит и считать нужно именно этих специалистов. Мы ведь про собеседования, а не про валовой продукт.
I>>Очевидно, что задача(кейс) и её решение(собеседование или интервью) это разные вещи. Выше приведены кейсы которые решаются при помощи собеседования или интервью. Разумеется, есть и другие способы, аудит например, но это сложновато применить в большинстве случаев.
A>Сформулировано так, словно других вариантов нету и надо выбирать лишь из этих двух. Не годится.
Собеседование и интервью это норма. Мы то про количестов интервью. В таких контора интервьюер проводит гораздо больше этих самых интервью
A>Компании разные бывают, нет смысла всех под один горшок стричь. Реальная практика показывает, что принципы ротация кадров могут быть весьма различны от компании в компанию.
Разумеется, потому в конторе, где все построено на интервью, матерый интервьюер в год проводит раза два три больше тех интервью, чем ты указал.
A>>>Это уже называется раздувание щёк, ради подчёркивания собственной важности со значимостью.
I>>Это должностные обязаности — руководитель занимается отбором людей в свою команду. И кстати говря, твои нападки мимо кассы.
A>Забавное представление про характер обязанностей руководителя и вариантах исполнения таковых (проводить технические интервью с кандадитами задавая им разворот списка).
Забавно — отбор людей в команду ты читаешь как "проводить технические интервью"
>Но и ты не мой сотрудник, за тебя не отвечаю, потому и мозги тебе вправлять — не моя задача.
Что ж тебя так на хамство то тянет? Никак не можешь без него? Какую проблему решаешь хамством, весу себе добавляешь, храбрости или как?
I>>Гугл, Амазон, Микрософт и прочие гиганты давно уже должны были загнуться. Да и большинство мелких фирм. I>>Надеюсь ты не слился на этих списках? Там всё просто, кстати.
A>Уже обсуждалось, если человека рассматривают лишь в качестве «сырого таланта», то его собеседуют одним образом. Если же видят, что это состоявшийся инженер, то используется иной подход.
Это снова общие слова.
A>Крайне редко, бывает и другой сценарий. Когда кандидата намеренно унижают, чтобы посмотреть насколько покладистый, насколько ему нужна именно эта работа.
Ну и опыт, похоже, тебе через многое пришлось пройти
A>Это именно то самое, что касается подбора «сырых талантов». Однако, в наш век все эти задачки уже опубликованы в книжках-сборниках или разобраны на веб-ресурсах. Твой любимый подход исчерпал себя, поскольку не защищён от жульничества — людей, спецом натаскивающихся на подобное.
Каким образом кандидат будет готов к рандомной задаче, ну, скажем, с leetcode, codewars, ну или к той, что я вчера у себя в проекте нашел?
Если он таки натаскался так, что ему любая такая задача нипочем — это реально круто!
I>>Далеко не все задачи требуют именно инженерных скилов. Простой проверкой в виде списка можно отсеять процентов 95% залетных.
A>Есть такое правило — держаться как можно дальше от тех компаний, которые нанимают программеров (кодеров) вместо специалистов программной инженерии.
Предпочитаешь лично заниматься черной работой? Давно уже придумали разделение труда, бери да пользуйся. Одни подчищают рутину, другие занимаются проектированием.
Если убрать тех, что попроще, то остальным придется тащить вообще всё.
I>>Снова общие слова и невалидные метафоры. В пазле ровно 1 кусочек встанет на место. В индустрии такое редкость. Всегда есть выбор — взять сейчас или подождать, проверить еще парочку и посмотреть, лучше подойдет — у кого опыта больше, или тот, у кого зп комфортнее.
A>Мозаичное панно выкинул, а ухватился лишь за пазл? Хорошо, можно и через него. A>Большая часть команд напоминают пазл собранный лишь на половину, а то и меньше. А потому и «кусочков» понапихать туда можно ощутимо больше одного-двух.
Из этого следует, что сравнивать придется гораздо больше, ширше, и глубже. Вот у тебя три инженера и два места из пяти. Кого взять? Три кандидата, значит реально возможна ситуация "камень-ножницы-бумага", когда первый выглядит предпочтительнее второго, второй — третьего, третий — первого.
Я тебе страшное скажу — эта ситуация возможна абсолютно везде, и в шахматах, и в боксе, и найме инженеров, и в найме дворников.
Кого брать?
Есть два регулировщика нагрузки. Настроены так, что при команде ЛЕВО всё идёт на первый, а при команде ПРАВО на второй.
Однако все ошибки падают только на первый.
На правах начинающего программиста предположу, что некоторым многим соискателям будет непросто решить эту с виду простую задачу: Alphametics Solver | Codewars
Здравствуйте, CreatorCray, Вы писали:
CC>Решение как таковое никого не интересует, интересует рассуждение в процессе решения, потому что это не вопрос — ответ а повод поговорить
Как раз потрепать языком — единственное, что хорошо умеют специалисты по прохождению собеседований.
Здравствуйте, sergey2b, Вы писали:
Тё>>Разворот списка — для суперменов. Синьёры на развороте строки сыпятся.
S>это когда надо слова поменять местами отночительно средины списка но порядок букв в слове оставить правильным
Нет, сыпятся на reverse(array) inplace.
Здравствуйте, Тёмчик, Вы писали:
Тё>Здравствуйте, sergey2b, Вы писали:
Тё>>>Разворот списка — для суперменов. Синьёры на развороте строки сыпятся.
S>>это когда надо слова поменять местами отночительно средины списка но порядок букв в слове оставить правильным Тё>Нет, сыпятся на reverse(array) inplace.
Даже не на UTF-8? А что ищется, знание стандартных функций или умение на выбранном языке реализовать
функция переворот(строка)
{
// На UTF-8 не работает
i = 0;
j = строка.длина() - 1;
пока (i < j)
поменять(строка[i++], строка[j--]);
}
Может в HR-фильтре что-нибудь подкрутить, если через него нужные кандидаты не проходят?
Здравствуйте, AleksandrN, Вы писали:
AN>Может в HR-фильтре что-нибудь подкрутить, если через него нужные кандидаты не проходят?
в США многие дают написать функцию преобразования строки в числа
первая версия в среднем 5-10 строк
в коцне собеседования у меня доходило до пару сотен на глаз
Здравствуйте, sergey2b, Вы писали:
AN>>Может в HR-фильтре что-нибудь подкрутить, если через него нужные кандидаты не проходят?
S>в США многие дают написать функцию преобразования строки в числа S>первая версия в среднем 5-10 строк S>в коцне собеседования у меня доходило до пару сотен на глаз
Лень напрягать мозк, но разве решение в лоб для целых не работает?
input='123456'
acc = 0;
for digit in input:
acc = acc * 10 + (code(digit)-code('0'))
print acc
Для float можно поставить состояние "точка пройдена" и набивать дробную часть с делением на 10, потом на 100, потом на 1000 и т.д. Сложность O(n) от длины строки (линейная).
Тё>Для float можно поставить состояние "точка пройдена" и набивать дробную часть с делением на 10, потом на 100, потом на 1000 и т.д. Сложность O(n) от длины строки (линейная).
во ты начал с 5 строк
а теперь
убрать пробелы с переди сздаи
обработка ошибок
знак
ox
восмиричное число
экспонента
дробное число
класс
большие числа скажем в 1024 разряда
меня один дедушка на этой задаче часа полтора упражнял
Здравствуйте, sergey2b, Вы писали:
S>меня один дедушка на этой задаче часа полтора упражнял
Ну если после простой версии добавлять юзкейсов, то можно и полтора часа трепаться. Хотя imho сложность не увеличивается, ничего нового о кандидате не узнаем. Такая простая задачка — на отсев нулячих по части алгоритмов, оюбые усложнения можно на словах "а если X" "тогда добавим Y". За 30 минут (максимум) алго части, хорошо если 3 задачки удастся спросить. А больше и не надо, не в гугл собеседуем.
Здравствуйте, Ikemefula, Вы писали:
I>Задача это способ показать квалификацию. Как у женглёра — показать мастерство в действии, а не рассказать про него.
А если жонглер вас пережонглирует, вы ему уступите свое место?
Здравствуйте, Gradiens, Вы писали:
G>Здравствуйте, xarcass, Вы писали:
X>>И вообще, чем критиковать чужие задачки накидал бы кто своих. А то кроме меня и тёмчика пока никто не сподобился.
G>Лично я не фанат задач. Но две категории задач могут быть полезны.
G>1) любые на понимание алгоритмической сложности. G>пример простой задачи: как максимально эффективно по времени отсортировать массив из 10^9 чисел, учитывая, что каждое из них не больше 10^6
G>2) любые на алгоритмическое мышление. Просто, чтобы посмотреть, как кандидат мыслит. И что делает, если у него не все получается. G>пример простой задачи: есть массив с числами от 1 до N, все числа кроме одного не повторяются. Найти повторяющееся число. G>пример задачи посложнее: есть указатель на однонаправленый связанный список. Как не выделяя динамической памяти узнать, закольцован список, или нет.
G>неплохо, если задача сразу принадлежит обеим категориям. Пример: найти все вхождения подстроки в строке.
G>Остальные типы задач — от лукавого. Лично я не вижу, как другие типы головоломок помогут понять, подходит кандидат, или нет. G>Да и задачи на мышление — спорная тема. Можно потратить кучу времени, завалить хорошего кандидата, который хорошо программирует но плохо решает задачи "про гномиков"
А потом вот эти люди пишут лютейшие интерфейсы c абсолютно не ортогональными методами, завязывают все компоненты в узел и перематывают это все скотчем. Вся алгоритмика задра..ся на раз. У меня знакомый чел, бывший UIщик, захотел писать под линукс на C++ и за 3 мес он алгоритмы выучил так, что сам порой мог интервьюверам вскипятить голову.
Я вот не алгоритмист ни разу, и сортировкой больих данных не занимался, и например для решения таких задач мне потребуется время. Зато любой другой проект, который я беру, почему-то начинает развиваться. Я выкидываю все старое или лишнее, непонятно почему на это у людей не хватает времени, умею выстроить развитие так, чтобы текущий проект и его внутренняя структура были как можно ближе к сценариям использования, выявляю слабые стороны и придумываю варианты компенсации.
За каждое принятое решение я могу аргументированно обосновать.
Если бы например я писал для себя поисковый движок ну или что-то около этого, на таких дешевых задачах разнес бы интервьювера.
Меня как-то спрашивали на UI, с какой частотой в винде таймер переключает потоки, я грю я хз, мне при моих проектах именно с таким сталкиваться не приходилось, но вы меня пугаете вопросами и у меня сразу несколько вопросов к вам: где вы это используете, а главное по какой причине вам это понадобилось, еще было бы оаправдано если бы это были JetBrains и решарпер для VS или Idea, ну или любой другой UI, который структурой тянет на целую ОС.
А так в массе свой это дешевые понты интервьювера.
Здравствуйте, diez_p, Вы писали:
I>>Задача это способ показать квалификацию. Как у женглёра — показать мастерство в действии, а не рассказать про него. _>А если жонглер вас пережонглирует, вы ему уступите свое место?
Я так и делал, когда искал человека себе на замену.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, diez_p, Вы писали:
I>>>Задача это способ показать квалификацию. Как у женглёра — показать мастерство в действии, а не рассказать про него. _>>А если жонглер вас пережонглирует, вы ему уступите свое место?
I>Я так и делал, когда искал человека себе на замену.
Здравствуйте, Ikemefula, Вы писали:
I>Например, 40мс ты считаешь чего, еще столько же уходит на всякие переключения и тд. В итоге, твой UI имеет лаг в 80мс что уже существенно для точной UI операции, тот же драг-н-дроп.
Ты в серьез утверждаешь, что переключение контекста в Windows настолько тяжелая операция? Я не спец в этих ваших вендах, но в нормальных ОС типа Linux речь идет о микросекундах
Здравствуйте, Тёмчик, Вы писали:
I>>Фактически, это непрямой вопрос на тему какой у тебя опыт в UI. Разумеется, если это единственный вопрос, то смысла в нём нет никакого. Многие считают, что выталкивание вычислений в другой тред это всегда хорошо. На самом деле в большинстве случаев плохо Жизнь так устроена. Вытакивать нужно только тяжелые вычисления. Тяжелые — зависит от задачи. Нет требований ко времени отклика, то и секундная задержка не является тяжелым вычислением. Есть всякие драг-н-дропы — 100мс это уже дико много.
Тё>Какая связь между плавной анимацией драг-дропа и вычислениями? Плавная анимация делается на GPU.
А если нет этого гпу? Кроме того, сложность решения никто не отменял.
>Вообще единственный рациональный способ держать UI плавным- это держать его в единственном потоке, а вычисления выкидывать в фон (фоновый пул потоков или обращение к бекенду).
Слишком высокая сложность решения и увеличивается латентность. Собтсвенно я говорю о том, как избежать латентности.
>Переключение контекста в любом случае в винде достаточно быстрое, если сделано всё по уму.
Дело не в переключении, а в распределении времени квантами.
Здравствуйте, kaa.python, Вы писали:
I>>Например, 40мс ты считаешь чего, еще столько же уходит на всякие переключения и тд. В итоге, твой UI имеет лаг в 80мс что уже существенно для точной UI операции, тот же драг-н-дроп.
KP>Ты в серьез утверждаешь, что переключение контекста в Windows настолько тяжелая операция? Я не спец в этих ваших вендах, но в нормальных ОС типа Linux речь идет о микросекундах
Микросекунды на что именно? Нужно считать весь цикл вычисления туда-сюда включая шансы потершать по дороге кванты времени по любой причине.
Одно простое переключение или системный вызов ничего не показывает, т.к. это малая часть происходящего.
Для примера — простая задержка Sleep(1) реально зависит от загрузки системы. Я тут много лет назад выкладывал замеры. В зависимости от загрузки системы этот Sleep(1) выполняется от 1 кванта до 15 секунд.
Та же проблема и при выталкивании вычислений в другой поток — пропускная способность растет при наличии ядер, но растет и латентность.
Если растет латентность, то смысл заниматься этой кунсткамерой с потоками?
Здравствуйте, kaa.python, Вы писали:
I>>Микросекунды на что именно? Нужно считать весь цикл вычисления туда-сюда включая шансы потершать по дороге кванты времени по любой причине.
KP>Я толи что-то не понимаю, толи ты считаешь что идеальное с точки зрения производительности приложение — это приложение работающее в один поток. С такой фольмулировкой я не согласен.
С тз. UI ты не получаешь бенефита, если выталкиваешь мелкие операции в воркер, т.к. в зависимости от загрузки системы у тебя растет латентность. Ты что, решил что все ядра свободны и только и ждут твоего воркера? Наоборот, потоки ставятся в очередь и время выделяется то одному, то другому. Потоки в очереди = латентность.
I>>Для примера — простая задержка Sleep(1) реально зависит от загрузки системы. Я тут много лет назад выкладывал замеры. В зависимости от загрузки системы этот Sleep(1) выполняется от 1 кванта до 15 секунд.
KP>Если у тебя Sleep(1) занимает 15 секунд, то уже вообще без разницы где и как ты будешь считать — система и так не отзывается.
Это важный факт — реальная задержка зависит от загрузки. Если в фоне работает GC, еще пару-тройку экземпляров этого же приложения, крайне странно думать, что воркеру ктото просто так даст квант времени. 15с это вырожденный случай. Но из 25 кадров сделать 5 вполне себе реально.
I>>Та же проблема и при выталкивании вычислений в другой поток — пропускная способность растет при наличии ядер, но растет и латентность.
KP>Нет такой проблемы. Есть закон Амдала и это единственное ограничение, которое у тебя возникает в общем случае. Дальше есть нюансы типа а какая у тебя модель памяти и прочее, но это уже небольшие уточнения, не более того. Ну а латентностью, возникающей при переключении контекста можно пренебречь как ничтожно маленькой величиной.
Ага, все ядра заняты, но для твоего воркера всенепременно найдется квант времени Если потоков больше, чем ядер, потоки в очереди на исполнение. Вот это и есть латентность.
Здравствуйте, Ikemefula, Вы писали:
I>Задра..ся только базовый набор алгоритмов, а вот дальше нужно владеть мат-методами — например, вычислить, доказать ассимптотику. И вот это уже не задра..ся, а изучается долго и упорно при наличии знаний матана. Без матана эту тему не осилить.
Матан тоже ни разу не рокет саенс. Просто надо понимать кого куда набирают, если берут алгоритмиста, который скорее математик, чем программист, то там совершенно будут другие вопросы.
_>>Меня как-то спрашивали на UI, с какой частотой в винде таймер переключает потоки, я грю я хз, I>Фактически, это непрямой вопрос на тему какой у тебя опыт в UI. Разумеется, если это единственный вопрос, то смысла в нём нет никакого. Многие считают, что выталкивание вычислений в другой тред это всегда хорошо.
Это отдельный вопрос, когда и что нужно выполнять в другом треде, а что в основном а главное как это делать.
I>Например, 40мс ты считаешь чего, еще столько же уходит на всякие переключения и тд. В итоге, твой UI имеет лаг в 80мс что уже существенно для точной UI операции, тот же драг-н-дроп.
Там все не так просто. Если 40мс что-то считается, можно смаршалить в другой тред и посчитать там — ни разу не проблема.
Основные проблемы начинаются с realtime апдейтами UI, когда прилетает куча данных, их представление все раскрашено, подлежащие компоненты работают только в UI потоке и не предназначены для друого, вот там и начинаются пляски.
В большинстве случаев enterprise UI, проблема в модели и в кривом использовании ООП.
И все эти задачи про гномиков разворотах списка и прочую мутотень особо смысла не имеют. Даже если человек примерно представляет что такое О(N) Ω(N) и Θ(N) этого будет вполне достаточно, вопрос в другом, за сколько он выучит алгоритмы, до нужного уровня, если он с ними до этого не работал.
Мне на собеседовании всегда интересно какие решенеия принимал человек, а не что он знает умеет, потому что именно решения, а не знания, определяют успешность проекта.
Все построение софта это борьба со сложностью и с проблемами, которые сам же и создал и вот тут интересна эволюция того куска, за который отвечает человек.
Нередко на собеседовании я пытаюсь погрузиться в проблемы которые решал кандидат и спрашиваю почему они не сделали вот так или так, иногда мне отвечали, что мы просто не додумались, а иногда поражаешься красотой решения.
Только принятые решения говорят об уровне человека, а не знание о том как развернуть список, или найти циклы в графе.
Здравствуйте, diez_p, Вы писали:
I>>Задра..ся только базовый набор алгоритмов, а вот дальше нужно владеть мат-методами — например, вычислить, доказать ассимптотику. И вот это уже не задра..ся, а изучается долго и упорно при наличии знаний матана. Без матана эту тему не осилить. _>Матан тоже ни разу не рокет саенс. Просто надо понимать кого куда набирают, если берут алгоритмиста, который скорее математик, чем программист, то там совершенно будут другие вопросы.
Матаном владеет довольно малочисленное меньшинство, потому чуть что сложнее базовых — упс.
I>>Фактически, это непрямой вопрос на тему какой у тебя опыт в UI. Разумеется, если это единственный вопрос, то смысла в нём нет никакого. Многие считают, что выталкивание вычислений в другой тред это всегда хорошо. _>Это отдельный вопрос, когда и что нужно выполнять в другом треде, а что в основном а главное как это делать.
Вопрос который ты привел, вобщем был в свое время довольно популярным. Как вытолкнуть вычисления в тред — в большинстве случаев нагуглить можно. Делать или не делать — вот эта граница всегда зависит от задачи.
I>>Например, 40мс ты считаешь чего, еще столько же уходит на всякие переключения и тд. В итоге, твой UI имеет лаг в 80мс что уже существенно для точной UI операции, тот же драг-н-дроп. _>Там все не так просто. Если 40мс что-то считается, можно смаршалить в другой тред и посчитать там — ни разу не проблема.
Можно. А сколько реально потребуется времени другому треду — тот еще вопрос, и далеко не факт что всё займет именно один квант времени. Это зависит от того, чем занята система. Нет свободного ядра — упс, латентность растет. И тут бывает так, что свой же GC мешает внятной работе UI.
_>Основные проблемы начинаются с realtime апдейтами UI, когда прилетает куча данных, их представление все раскрашено, подлежащие компоненты работают только в UI потоке и не предназначены для друого, вот там и начинаются пляски.
Вот-вот, я именно про этот случай. Передать то можно в другой поток, но хорошо бы представлять, когда это стоит или не стоит делать. И если люди выталкивают мелкие операции в другой поток, то при небольшой загрузке UI начинат лагать. Оно и ожидаемо — воркеры в очереди.
_>Нередко на собеседовании я пытаюсь погрузиться в проблемы которые решал кандидат и спрашиваю почему они не сделали вот так или так, иногда мне отвечали, что мы просто не додумались, а иногда поражаешься красотой решения.
Это очень трудный дзен Чем выше позиция, тем сложнее погрузиться в его проблемы.
_>Только принятые решения говорят об уровне человека, а не знание о том как развернуть список, или найти циклы в графе.
Это зависит от уровня позиции. Условно, если позиция примерно мидл, не сеньор, то стоит проверить именно списки, графы и тд. У них профиль — поглощение рутины, баги-фичи.
А вот у сеньора обязательно стоит искать принятые решения. У него профиль работы — дизайн среднего уровня, выработка решения для какой проблемы и тд. Алгоритмы здесь уже не самое главное. Если сеньор не умеет проектировать этот средний уровень, то на алгоритмах он просто будет уверенным мидлом.
Здравствуйте, Ikemefula, Вы писали:
I>Матаном владеет довольно малочисленное меньшинство, потому чуть что сложнее базовых — упс.
Да любой инженер плюс минус знает матан. Если конечно программист не инженер
I>Вот-вот, я именно про этот случай. Передать то можно в другой поток, но хорошо бы представлять, когда это стоит или не стоит делать. И если люди выталкивают мелкие операции в другой поток, то при небольшой загрузке UI начинат лагать. Оно и ожидаемо — воркеры в очереди.
Чтобы прям тормозил отклик, на мой практике такого не было, были задачи когда данные должны были отрисовываться менее чем за 10 мс. Но там была основная проблема что UI поток занят. Если прям нужно отклик, то скорее всего надо будет пилить что-то кастомное, поднимать приоритет потоков, вытаскивать в отдельный процесс.
Но это в общем случае какие-то конкретные технические решения, которые решаются чтением доков по конкретной ОС и то большинство таких проблем решаются как, а давайте попробуем простую оптимизацию, работает, ну и отлично, дальше не копаем.
_>>Нередко на собеседовании я пытаюсь погрузиться в проблемы которые решал кандидат и спрашиваю почему они не сделали вот так или так, иногда мне отвечали, что мы просто не додумались, а иногда поражаешься красотой решения. I>Это очень трудный дзен Чем выше позиция, тем сложнее погрузиться в его проблемы.
А вот попути погружения в проблемы начинаешь понимать каким образом погружался человек, что он изучил, может мне что-то расскажет.
_>>Только принятые решения говорят об уровне человека, а не знание о том как развернуть список, или найти циклы в графе. I>Это зависит от уровня позиции. Условно, если позиция примерно мидл, не сеньор, то стоит проверить именно списки, графы и тд. У них профиль — поглощение рутины, баги-фичи.
Если у меня задачи работы со списками, то я его вряд ли буду спрашивать, ибо нет смысла проверять умение, которое не всотребовано. С мидла нужен хороший код по отдельно взятой задаче: читаемый и поддерживаемый, понимание того как работают какие-то базовые вещи языка. И опять таки я буду спрашивать о его опыте и о том, какие например задачи он решал, что он сам сделал и так далее.
Здравствуйте, diez_p, Вы писали:
I>>Матаном владеет довольно малочисленное меньшинство, потому чуть что сложнее базовых — упс. _>Да любой инженер плюс минус знает матан. Если конечно программист не инженер
Далеко не любой и далеко не всегда на должном уровне. Такое нынче состояние дел в индустрии.
I>>Вот-вот, я именно про этот случай. Передать то можно в другой поток, но хорошо бы представлять, когда это стоит или не стоит делать. И если люди выталкивают мелкие операции в другой поток, то при небольшой загрузке UI начинат лагать. Оно и ожидаемо — воркеры в очереди. _>Чтобы прям тормозил отклик, на мой практике такого не было, были задачи когда данные должны были отрисовываться менее чем за 10 мс. Но там была основная проблема что UI поток занят. Если прям нужно отклик, то скорее всего надо будет пилить что-то кастомное, поднимать приоритет потоков, вытаскивать в отдельный процесс.
Я бы не стал сходу хвататься за приортеты. Первым делом стоит замерить и убрать все препятствия внутри UI потока. Быстрая отрисовка это прежде всего эффективная организация данных и адекватные операции над ними.
_>>>Нередко на собеседовании я пытаюсь погрузиться в проблемы которые решал кандидат и спрашиваю почему они не сделали вот так или так, иногда мне отвечали, что мы просто не додумались, а иногда поражаешься красотой решения. I>>Это очень трудный дзен Чем выше позиция, тем сложнее погрузиться в его проблемы. _>А вот попути погружения в проблемы начинаешь понимать каким образом погружался человек, что он изучил, может мне что-то расскажет.
Интерьвьюер и кандидат имеют всего лишь пересекающиеся области знаний, работы. Например, просто разный фокус у каждого. Соответсвенно, этот подход работает далеко не всегда.
I>>Это зависит от уровня позиции. Условно, если позиция примерно мидл, не сеньор, то стоит проверить именно списки, графы и тд. У них профиль — поглощение рутины, баги-фичи. _>Если у меня задачи работы со списками, то я его вряд ли буду спрашивать, ибо нет смысла проверять умение, которое не всотребовано.
Непонятно — вроде задачи со списками, но умение работы со списками почему то невострабовано. Как так?
>С мидла нужен хороший код по отдельно взятой задаче: читаемый и поддерживаемый, понимание того как работают какие-то базовые вещи языка.
Именно это и проверяется небольшими задачи — базовые вещи языка, умение писать понятный, читаемый, поддерживаемый код, знание каких либо особенностей, фич фремворка и тд и тд.
Десяток строчек кода говорят о кандидате гораздо больше, чем тысяча слов.
> И опять таки я буду спрашивать о его опыте и о том, какие например задачи он решал, что он сам сделал и так далее.
Тогда ты не узнаешь, насколько он хорош в базовых алгоритмах А для мидла эта способность является определяющей — показывает, как много глупых ошибок он будет делать. Например, придет ли ему в голову фиксануть группировку или он начнет писать наколеночную поделку. Те, у кого с базовыми алгоритмами хорошо, почти всегда знают, что наколеночные поделки это отстой. А если полезет фиксовать имеющийся вариант, то не обеспечит всю команду долгим багфиксом.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, diez_p, Вы писали:
I>Я бы не стал сходу хвататься за приортеты. Первым делом стоит замерить и убрать все препятствия внутри UI потока. Быстрая отрисовка это прежде всего эффективная организация данных и адекватные операции над ними.
Нет, быстрая быстрая отрисовка, это быстрая отрисовка, данные там все были готовы и хапать тормоза в обработке данных на UI, нууу так себе.
I>Интерьвьюер и кандидат имеют всего лишь пересекающиеся области знаний, работы. Например, просто разный фокус у каждого. Соответсвенно, этот подход работает далеко не всегда.
Обычно мне хватает то, что интервьювер рассказывает, дальше думаешь.
I>Непонятно — вроде задачи со списками, но умение работы со списками почему то невострабовано. Как так?
За все время написал нечеткое сравнение деревьев. Все остальное стандартные коллекции, где надо немного знать как оно внутри работает.
Для меня самый главный вопрос на собеседовании это понять что знает человек, а главное как он применяет эти знания, а теории навалом и она доступна, как правило вместе с кодом.
В общем выучить алгоритмы это не особо проблема.
Здравствуйте, diez_p, Вы писали:
I>>Я бы не стал сходу хвататься за приортеты. Первым делом стоит замерить и убрать все препятствия внутри UI потока. Быстрая отрисовка это прежде всего эффективная организация данных и адекватные операции над ними. _>Нет, быстрая быстрая отрисовка, это быстрая отрисовка, данные там все были готовы и хапать тормоза в обработке данных на UI, нууу так себе.
"данные там всегда готовы" — ага, сами организовались, сами себя оптимизировали... Здесь и нужно понять — в каком виде нужно данные хранить, чтобы добиться эффективной отрисовки. Эту часть всё равно нужно выполнить, даже если придется кое что считать в другом потоке.
I>>Непонятно — вроде задачи со списками, но умение работы со списками почему то невострабовано. Как так? _>За все время написал нечеткое сравнение деревьев. Все остальное стандартные коллекции, где надо немного знать как оно внутри работает.
"немного надо знать как оно внутри работает" — проверяется задачей на списки
_>Для меня самый главный вопрос на собеседовании это понять что знает человек, а главное как он применяет эти знания, а теории навалом и она доступна, как правило вместе с кодом.
Если некто не справился с обходом списка, дерева, крайне странно думать, что он понимает итерации, рекурсию и тд.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, diez_p, Вы писали:
I>Если некто не справился с обходом списка, дерева, крайне странно думать, что он понимает итерации, рекурсию и тд.
Тут тоже есть тонкие моменты. Человек не знает например список — ОК. Пусть не знает. Пусть придумает, как можно сохранить множество объектов, чтобы например удаление/вставка занимали констатное время. Плюс там однонаправленный, двунаправленный список и т.д.
А потом элементарная оптимизация , нужен список фрагментированность которого ограничена, чтобы зная расположение в памяти можно было вычислить произвольный адрес элемента: и иначинаются чанки, кастомные аллокаторы, АВЛ деревья для переиндексации Какие-то списки удаленных элементов, либо работа с чанком как массивом, либо длинна масива может быть переменной.
А потом делаем дерево многопоточным и спрашиваем про протоколы синхронизации памяти.
Как по мне, так лучше вообще заменять алгоритмические задачи на задачи по применению SOLID (если на проекте практикуется чистый ООП-шный код) и GRASP.
Пусть это будет алгоритмически простая задача, но например с вариациями (тогда применяем полиморфизм из GRASP), или дан код, который дублируется в нескольких методах частично, и нужно избавиться от дублирования, применив Template Method (выделив повторяющийся код в абстрактные методы, а отличающиеся детали в методы подклассов). Или дан код, нарушающий принцип подстановки Лисков, и нужно самостоятельно понять что именно этот принцип нарушен и предложить решение.
Здравствуйте, diez_p, Вы писали:
I>>Если некто не справился с обходом списка, дерева, крайне странно думать, что он понимает итерации, рекурсию и тд. _>Тут тоже есть тонкие моменты. Человек не знает например список — ОК. Пусть не знает.
Это говорит об отсутствии элементарной грамотности, отсутствии минимального опыта с базовыми структурами данных, отсутствии адекватного образования и много чего еще.
>Пусть придумает, как можно сохранить множество объектов, чтобы например удаление/вставка занимали констатное время.
Каким чудом он натренировал вычислительную сложность без базовых структур данных ?
Такие люди лично мне встречались — жосткие самоучки, дерево знаю — список не знаю, сложное знаю — простое не знаю. И всегда такие пробелы показывали просто чудовищные провалы почти в каждой из областей.
Фактически, натретировались ровно на конкретные кейсы, не вникая.
> Плюс там однонаправленный, двунаправленный список и т.д.
Если ты не знаешь списков — то даже заподозрить не сможешь типичные решения типичных задач. Эта область для тебя отсутствует.
_>А потом элементарная оптимизация , нужен список фрагментированность которого ограничена, чтобы зная расположение в памяти можно было вычислить произвольный адрес элемента: и иначинаются чанки, кастомные аллокаторы, АВЛ деревья для переиндексации Какие-то списки удаленных элементов, либо работа с чанком как массивом, либо длинна масива может быть переменной.
Ага — списки не знает, но чанки умеет Чудо то какое.
_>А потом делаем дерево многопоточным и спрашиваем про протоколы синхронизации памяти.
Если нет списков, то никаких деревьев не будет и в помине.
_>P.S я не С++ программист и не алгоритмист
Это ничего не меняет. Список это одна из базовых вычислительных моделей, встречается по сотне раз на день.
Здравствуйте, diez_p, Вы писали:
I>>Это ничего не меняет. Список это одна из базовых вычислительных моделей, встречается по сотне раз на день. _>Вы шаблонно мыслите. Человек не знает списков, допустим. Как они решал задачи которые связаны с ними? Не решал, значит надо посмотреть, решал — ок, знаит не вдумывается как рабоотает, одной стороны хорошо: работает — не трогай, с другой: знаит в случае чего придется потратить время на копание ибо незнает.
Не знает списков — значит не знает одну из самых часты вычислительных моделей. До свидания.
_>Все IT это применение стандартных решений или свое велосипедо строение, под конкретно свою узкую задачу. _>Если человек не может придумать свой велосипед, на уже решенную задачу — какой он тогда программист? Построение велосипедов может потребоваться значительно раньше, чем будет изобретено коробочное решение.
Если велосипедить простейшие вещи, как списки — далеко не уедешь. Студент 2го курса справится куда лучше такого кандидата.
_>Лично я писал свой react еще в 2007 году, а DI контейнер до меня велосипедисты написали еще на .NET 1.1.
Реакт это гораздо больше чем списки, а DI — тем более.
_>т.е. сам факт не знания списков еще ни о чем не говрит, надо копать глубже.
Наоборот — это отсутствие опыта. Списки это
1 простейшая ссылочная структура данных, все остальное гарантировано сложнее.
2 обработка данных порциями — дай следующую часть, дай следующую часть, и тд
То есть, кандидат как то ухитрился пройти мимо всего этого.
Если кандидат не умеет простые вещи на списках, это говорит о том, что его квалификация примерно 1...2 семестр первого курса профильной специальности. Списки обычно или на втором семестре 1го курса, или на 1 семестре 2го курса.
Здравствуйте, kaa.python, Вы писали:
KP>Ты в серьез утверждаешь, что переключение контекста в Windows настолько тяжелая операция? Я не спец в этих ваших вендах, но в нормальных ОС типа Linux речь идет о микросекундах