Ну если наследование прямоугольника от квадрата — не вызывает вопросов, то вопрос с пингвином стоять не будет (птица — пингвин, который может летать =) )
мне не нужно «самый важны» — мне нужно «достаточно хороший». Но если дадите жменьку «более лучших» (можно без обоснования) — то с удовольствием ознакомлюсь.
Вполне возможно, и да, про это можно поговорить. Про big O, а не «а какая там сложность в b-tree».
На мой взгляд слишком широкий вопрос сначла дает ухже результат чем частный случай и потом поднятие выше по абстракциям.
+ опять таки экономит время, нет смысла слушать главу из учебника если ее приложение вызывает вопросы.
Не знаю, какие у вас «стартапики», но как раз небольшие конторы сейчас в среднем более адекватны больших.
— у нас «стартапиком» называют что-то хотябы с претензией на технологичность.
Остальным (без бабла и/или инетресного проекта) — приходится брать все что осталось.
Не факт что именно деревья будут нужны, но Big O — точно пригодится. И если речь про собеседование мидл+ специалиста в «стартапики» — то там куда больше вероятности увидеть вопросы про деревья и на «найти решение которого нет готового» — на своем месте.
А если на конвеер — то там по-моему вообще выбирать не приходится, одна рука есть? по ФТП файлик залить можешь? — вы приняты.
в этом то и прелесть этого примера, не нужно спец. знаний чтобы решить (приблизительно) эту задачу.
Пусть даже не точно.
Отсутствие «книжного» ответа — это отличный повод посмотреть как кандидат ищет решение незнакомой задачи, а не достает из памяти/гугла как в анекдоте (https://lol-sus.livejournal.com/1308476.html)
не, если на вопрос «что там в индексе» ответ есть — B-tree — мы предполагаем что человек не просто слово выучил.
Если ответа нет — это несколько другая ситуация. Незнание тут — не приговор, и мы обычно продолжаем вопросом — а чтобы там могло быть и смотрим варианты с плюсами и минусами. Иногда это даже полезнее.
конечно, если вы знаете как устроена структура данных, то дальше идут вопросы которые вы задаете сами себе:
1. сколько и каких операций нужно чтобы найти элемент в дереве на 100 000 элементов
2. как изменится эта оценка если элементов станет в 2 раза больше? А в 10?
=
и если человек знает что там может быть (константа, экспонента, корень, логарифм...) — то ответ готов.
Метод универсален для любых структур данных.
Если это нужно в работе на ту позицию, на которую вы собеседуете — это замечательно. Если нет — это «опять очередной интервьюер, считающий, что он и его контора тут сами себе гугл».
— нужно ли оценивать трудоемкость вставки в b-tree index в pgSQL на CentOS по пятницам? — нет не нужно.
Уметь быстро оценивать трудоемкость решения — постоянно.
А еще куда полезнее — говорить в таком же ключе о реальных задачах, а не о бинарных деревьях просто потому, что вам нравится о них поговорить.
Решение реальной задачи — до которого мы добираемся если есть смысл, занимает 30-60 минут. Я не готов тратить столько времени человека если особых надежд на то что все пройдет хорошо нет.
а) b-tree — это не бинарное дерево (но к делу это не относится)
б) т.е. не может из достаточных данных вывести ответ (а это звоночек) т.к. тут «вывод» занимает 1-2 минуты максимум (вместе с поговорить) — если есть понимание как это в принципе делается. Так что именно «недостаточно тренирован делать выводы и моделировать ситуацию даже не очень сложную, но в голове».
куда важнее знать что эти формулы есть и что там в «аргументах», в той области где работаешь — очень полезно помнить характер зависимостей, а сама формула куда менее ценна (ее вполне можно и посмотреть если есть понимание что она «нужна»)
другой вопрос что если он не знал что там внутри b-tree — то тут понятно что без гугла дальше не уедем, но я, например, предлагаю придумать варианты и обсудить их плюсы и минусы.
Это куда полезнее чем «знаю-не знаю», ибо как раз вот это дает очень мало представления о том что будет дальше.
Ну и немного цифр, у тех кого мы берем на работу с таким «подходом» % прохождения испытательного срока больше 80% (скорее ближе к 90). Как минимум корреляция — очень хорошая.
Меньше размышлений неправильных дьяволу деталей огульных.
Если у вас наверное есть какое-то объяснение почему кандидат хорошего уровня не может провести оценку сложности операции с довольно простой структурой данных — было бы интересно послушать.
У меня только такие: не может оценить сложность в принципе/не знает что это такое; не способен размышлять (сейчас, или в принципе — вопрос). По одному вопросу конечно однозначный вывод делать нельзя, может просто локально «затупил», но если это система — то нам не по пути.
Вся информация которая нужна для оценки «на столе», загуглить тут можно только ответ, а он без понимания особо не нужен.
если кандидат не может «без гугла» оценить сложность поиска по b-tree — («знать» чтобы ответить за 1.5 секунды не обязательно) то наверняка у него будут проблемы с тем чтобы в гугле отсеивать «левые» ответы/советы от нормальных.
Это не порядок аргументов функции в PHP 4.2 — это фундаментально.
А то, что поиск по B-tree индексам в PostgreSQL имеет логарифмическую сложность? Я вчера узнал, вот теперь и вы.
а не в PostgreSQL? =)
А если серьезно — ну ладно не помнить (хотя такое забывать — странно), но быстро прикинуть зная что такое B-tree и как принципиально работает индекс еще и озвучив процесс прикидывания интервьюеру — добавит очков.
Собеседование это не квиз (ну по крайней мере не должно быть), и там куда менее полезны мгновенные ответы «потому что я готовился», чем демонстрация того как эти ответы ищутся.
+ опять таки экономит время, нет смысла слушать главу из учебника если ее приложение вызывает вопросы.
— у нас «стартапиком» называют что-то хотябы с претензией на технологичность.
Остальным (без бабла и/или инетресного проекта) — приходится брать все что осталось.
А если на конвеер — то там по-моему вообще выбирать не приходится, одна рука есть? по ФТП файлик залить можешь? — вы приняты.
Пусть даже не точно.
Отсутствие «книжного» ответа — это отличный повод посмотреть как кандидат ищет решение незнакомой задачи, а не достает из памяти/гугла как в анекдоте (https://lol-sus.livejournal.com/1308476.html)
ничего другого этим вопросом не узнать. Вашу идею я понял.
Если ответа нет — это несколько другая ситуация. Незнание тут — не приговор, и мы обычно продолжаем вопросом — а чтобы там могло быть и смотрим варианты с плюсами и минусами. Иногда это даже полезнее.
1. сколько и каких операций нужно чтобы найти элемент в дереве на 100 000 элементов
2. как изменится эта оценка если элементов станет в 2 раза больше? А в 10?
=
и если человек знает что там может быть (константа, экспонента, корень, логарифм...) — то ответ готов.
Метод универсален для любых структур данных.
ЗЫ. не стоит путать неспособность придумать, с отсутствием решения в памяти. Это принципиальное отличие.
Уметь быстро оценивать трудоемкость решения — постоянно.
Решение реальной задачи — до которого мы добираемся если есть смысл, занимает 30-60 минут. Я не готов тратить столько времени человека если особых надежд на то что все пройдет хорошо нет.
б) т.е. не может из достаточных данных вывести ответ (а это звоночек) т.к. тут «вывод» занимает 1-2 минуты максимум (вместе с поговорить) — если есть понимание как это в принципе делается. Так что именно «недостаточно тренирован делать выводы и моделировать ситуацию даже не очень сложную, но в голове».
Это куда полезнее чем «знаю-не знаю», ибо как раз вот это дает очень мало представления о том что будет дальше.
Ну и немного цифр, у тех кого мы берем на работу с таким «подходом» % прохождения испытательного срока больше 80% (скорее ближе к 90). Как минимум корреляция — очень хорошая.
(достаточно одного чтобы доказать что есть, сейчас все сообщение можно свести к «не верю!»)
Если у вас наверное есть какое-то объяснение почему кандидат хорошего уровня не может провести оценку сложности операции с довольно простой структурой данных — было бы интересно послушать.
У меня только такие: не может оценить сложность в принципе/не знает что это такое; не способен размышлять (сейчас, или в принципе — вопрос). По одному вопросу конечно однозначный вывод делать нельзя, может просто локально «затупил», но если это система — то нам не по пути.
Вся информация которая нужна для оценки «на столе», загуглить тут можно только ответ, а он без понимания особо не нужен.
Это не порядок аргументов функции в PHP 4.2 — это фундаментально.
А если серьезно — ну ладно не помнить (хотя такое забывать — странно), но быстро прикинуть зная что такое B-tree и как принципиально работает индекс еще и озвучив процесс прикидывания интервьюеру — добавит очков.
Собеседование это не квиз (ну по крайней мере не должно быть), и там куда менее полезны мгновенные ответы «потому что я готовился», чем демонстрация того как эти ответы ищутся.
что до физ лиц: то там скорее всего возникает НДФЛ не резидента который вы должны уплатить как налоговый агент.