Re[11]: чем заменить задачу по развороту списка - О работе

Здравствуйте, sergey2b, Вы писали:

S>несколько хороших задачь которымиможно заменить разоворот списка
Самое правильное в этой ситуации заменить интервьювера.

Такое ощущение, что когда нанимают конструктора (неважно чего), дают какой-то замысловатый паззл и говорят можешь сложить?
Ребята вы серьезно? Вы каждый день складываете такие паззлы?

Пора бы уже давно забыть про (2,71)6@#унтые задачи, которые показывают только один единственный навык — уметь решать задачи такого характера.

Людей берут на решение задач/проблем в определенной предметной области, с какими-то знаниями в определенных технологиях и так называемые soft skills.

И каждое собеседование должно строиться исходя из потребностей компании/проекта.
Если в вашей компании разворачивают списки, то безусловно задача на разворот №1 ))

На собеседованиях спрашивают за сколько тактов GC собирает кучу, выверты графов наизнанку, а потом смотришь в код и там такой звиздец, что просто берешь и переписываешь ибо саппортить невозможно. За все время видел много разных проектов и только у 1 из 10 код написано в первую очередь понятно, а во вторых в соотвествии с используемыми use cases.

Здравствуйте, 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>>Задача это способ показать квалификацию. Как у женглёра — показать мастерство в действии, а не рассказать про него.
_>А если жонглер вас пережонглирует, вы ему уступите свое место?

Я так и делал, когда искал человека себе на замену.

Здравствуйте, 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ке поменялся шедулинг и теперь все немного не так.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, diez_p, Вы писали:

I>>>Задача это способ показать квалификацию. Как у женглёра — показать мастерство в действии, а не рассказать про него.
_>>А если жонглер вас пережонглирует, вы ему уступите свое место?

I>Я так и делал, когда искал человека себе на замену.

Тогда вопросов нет.

Здравствуйте, Ikemefula, Вы писали:

I>Например, 40мс ты считаешь чего, еще столько же уходит на всякие переключения и тд. В итоге, твой UI имеет лаг в 80мс что уже существенно для точной UI операции, тот же драг-н-дроп.

Ты в серьез утверждаешь, что переключение контекста в Windows настолько тяжелая операция? Я не спец в этих ваших вендах, но в нормальных ОС типа Linux речь идет о микросекундах

Здравствуйте, Ikemefula, Вы писали:

I>Фактически, это непрямой вопрос на тему какой у тебя опыт в UI. Разумеется, если это единственный вопрос, то смысла в нём нет никакого. Многие считают, что выталкивание вычислений в другой тред это всегда хорошо. На самом деле в большинстве случаев плохо

Жизнь так устроена. Вытакивать нужно только тяжелые вычисления. Тяжелые — зависит от задачи. Нет требований ко времени отклика, то и секундная задержка не является тяжелым вычислением. Есть всякие драг-н-дропы — 100мс это уже дико много.

Какая связь между плавной анимацией драг-дропа и вычислениями? Плавная анимация делается на GPU. Вообще единственный рациональный способ держать UI плавным- это держать его в единственном потоке, а вычисления выкидывать в фон (фоновый пул потоков или обращение к бекенду). Переключение контекста в любом случае в винде достаточно быстрое, если сделано всё по уму. А если у тебя пачка потоков конкурируют за один-единственный мутекс- так это рукожопый дизайн, не более того.

Здравствуйте, Тёмчик, Вы писали:

I>>Фактически, это непрямой вопрос на тему какой у тебя опыт в UI. Разумеется, если это единственный вопрос, то смысла в нём нет никакого. Многие считают, что выталкивание вычислений в другой тред это всегда хорошо. На самом деле в большинстве случаев плохо

Жизнь так устроена. Вытакивать нужно только тяжелые вычисления. Тяжелые — зависит от задачи. Нет требований ко времени отклика, то и секундная задержка не является тяжелым вычислением. Есть всякие драг-н-дропы — 100мс это уже дико много.

Тё>Какая связь между плавной анимацией драг-дропа и вычислениями? Плавная анимация делается на GPU.

А если нет этого гпу? Кроме того, сложность решения никто не отменял.

>Вообще единственный рациональный способ держать UI плавным- это держать его в единственном потоке, а вычисления выкидывать в фон (фоновый пул потоков или обращение к бекенду).

Слишком высокая сложность решения и увеличивается латентность. Собтсвенно я говорю о том, как избежать латентности.

>Переключение контекста в любом случае в винде достаточно быстрое, если сделано всё по уму.

Дело не в переключении, а в распределении времени квантами.

Здравствуйте, kaa.python, Вы писали:

I>>Например, 40мс ты считаешь чего, еще столько же уходит на всякие переключения и тд. В итоге, твой UI имеет лаг в 80мс что уже существенно для точной UI операции, тот же драг-н-дроп.

KP>Ты в серьез утверждаешь, что переключение контекста в Windows настолько тяжелая операция? Я не спец в этих ваших вендах, но в нормальных ОС типа Linux речь идет о микросекундах

Микросекунды на что именно? Нужно считать весь цикл вычисления туда-сюда включая шансы потершать по дороге кванты времени по любой причине.
Одно простое переключение или системный вызов ничего не показывает, т.к. это малая часть происходящего.
Для примера — простая задержка Sleep(1) реально зависит от загрузки системы. Я тут много лет назад выкладывал замеры. В зависимости от загрузки системы этот Sleep(1) выполняется от 1 кванта до 15 секунд.
Та же проблема и при выталкивании вычислений в другой поток — пропускная способность растет при наличии ядер, но растет и латентность.
Если растет латентность, то смысл заниматься этой кунсткамерой с потоками?

Собственно ради UI я и делал все подобные замеры.

Здравствуйте, Ikemefula, Вы писали:

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

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

I>Для примера — простая задержка Sleep(1) реально зависит от загрузки системы. Я тут много лет назад выкладывал замеры. В зависимости от загрузки системы этот Sleep(1) выполняется от 1 кванта до 15 секунд.

Если у тебя Sleep(1) занимает 15 секунд, то уже вообще без разницы где и как ты будешь считать — система и так не отзывается.

I>Та же проблема и при выталкивании вычислений в другой поток — пропускная способность растет при наличии ядер, но растет и латентность.

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

Здравствуйте, 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>>Непонятно — вроде задачи со списками, но умение работы со списками почему то невострабовано. Как так?
_>За все время написал нечеткое сравнение деревьев. Все остальное стандартные коллекции, где надо немного знать как оно внутри работает.

"немного надо знать как оно внутри работает" — проверяется задачей на списки

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

Если некто не справился с обходом списка, дерева, крайне странно думать, что он понимает итерации, рекурсию и тд.

От:	Тёмчик	жж
Дата:	16.10.20 22:31
Оценка:

От:	IT	linq2db.com
Дата:	19.10.20 15:20
Оценка:	+1

	От:	diez_p
	Дата:	20.10.20 14:46
	Оценка:	+1

	От:	diez_p
	Дата:	20.10.20 14:55
	Оценка:

	От:	diez_p
	Дата:	20.10.20 15:12
	Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	21.10.20 07:54
Оценка:

От:	kaa.python	РСДН профессионально мёртв и завален ватой.
Дата:	24.10.20 11:44
Оценка: