Нет, тестовые не даем.
Я стараюсь больше уделять внимание тому, КАК кандидат мыслит, а не ЧТО он знает.
Конкретные знания конечно же важны, но в каком-то пределе, а вот умение мыслить — бесценно.
А тестовые не даем по нескольким причинам одна из которых — хорошие спецы в них не нуждаются и более того с высокой вероятностью сразу Вас пошлют при первом же намеке на тестовое (я и сам не люблю тестовые)
боюсь проверить компетенции в мире ИТ практически невозможно. можно только построить гипотезу тк правильные ответы не дают гарантий, что человек умеет это применить, ровно как и не знание теории не говорит о непригодности. тут все очень сложно и строится на чистой субъективности
Я бы чуть-чуть поправил пункт про «кто должен собеседовать». Все таки перекрестный опрос хоть и стресс, но моя практика показывает, что это наиболее эффективный способ задать правильные вопросы и правильно интерпретировать ответы на них. По мимо лида на собеседовании должен присутствовать hr (или грамотный манагер с пониманием психологии) и ещё кто нибудь из команды разработки. Что это даёт в сумме: у компании и команды есть возможность презентовать себя не одним лицом, что позволит собеседоемому чуть лучше понимать во что он хочет ввязаться. У команды же появляется возможность спросить самые многогранные вопросы в контексте и правильно понять ответы, принять коллективное решение. Если идти по пути я начальник — я все знаю (один в поле воин) можно что-то упустить, не так понять и пр человеческие факторы.
Есть только одно требование к подобным собеседованиям: все представители команды должны работать как единый организм, а не тянуть одеяло на себя.
Меня лично собеседовали и 5 технарей (вся дев команда) и солянка из представителей каждого организационного уровня. Что мне, как собеседуемому, позволяло понимать куда я попал и что будет дальше если принять оффер. В роли собеседующего (лида) за последние 2 года мы выработали практику, что в собеседовании участвуют минимум 2 технаря и всегда заранее обсуждаем некую стратегию чтобы не устраивать хаос. Не всегда, но частенько так же участвует hr дабы спрашивать другие правильные вопросы. После чего принимаем коллективное решение.
предлагаю закрыть тему тк дело не в том как я или Вы смотрите на эти 2 сильно разные вещи, а в том, о чем в статье не сказано при проведении сравнений и замеров: чем они отличаются и какие плюсы и минусы у них есть. а самое главное не сказано: выбирайте инструмент исходя из задачи )
с этим я спорить не собираюсь, в условиях что мы хотим сделать что-то простое как x+1. однако это не отменяет сказанного мной: генератор иниализируется быстрее полного построения готового списка, памяти требует примерно ноль, асимтоматика перебора значений линейная в обоих случаях. однако, если проводить честные замеры, то в list comprehension мы обязаны вызывать какую-нибудь функцию, не потому, что так надо, а банально для чистоты эксперимента тк вызов функции одна из самых дорогих операций и просто взять ее, выкинуть и сказать что генераторы отстой — это как сказать что запорожец с реактивным двигателем быстрее болида формулы 1.
если учитывать, что map в 3м питоне превратился в генератор, то разница между ними все таки ощутимая. асимтоматика перебора значений так и останется линейной в обоих случаях, а вот по памяти и скорости инициализации любой генератор утрет нос list comprehension'y.
как вообще можно сравнивать list comprehension и около генераторное выражение обернутое в лист? или сравнивайте корректно строго на 2.7 или вместо list comprehension используйте генератор обернутый в лист. а то получается попытка сравнить несравнимое и впихнуть невпихуемое.
тут есть некоторые нюансы на эту тему.
когда твой работодатель закрывает контракт и регистрирует ПО в каком-то там реестре российского ПО (речь про гос. заказы), то по букве закона с него требуют чтобы была отдельно заполненная бумажка с твоим отказом от авторских прав и за это тебе причитается разовое авторское отчисление. И букву закона тут совершенно не волнует сколько и каких именно бумажек ты подписал для своего работодателя.
как-то я совсем не согласен с автором в контексте mvp + microservises. да даже далеко ща пределами mvp микросервисы в большинстве своем излишество. если смотреть через призму хайпа и неограниченных ресурсов — да, отличное решение, но если смотреть правде в глаза — первые несколько лет не стоит даже вспоминать про из существование. а ещё лучше последовать примеру гигантов, например Амазон, который о микросервисах задумался когда у него штат был овер 3к сотрудников и выручка что-то около полу лярда в год. (точных цифр и источник не скажу).
так ответ же очевиден: нет! это надо вот только сейчас, ровно на 1 раз и ни кто этим пользоваться не будет. Проблема не в том, что программисты не умеют говорить ртом с манагерами (хоть эта проблема тоже имеет место быть), проблема в том, что сами манагеры зачастую не знают ответов тк хотелки прилетают откуда-то сверху.
у меня к автору подобный вопрос, только с некоторым изменением. копия полученная за счёт знаний и опыта реализована другими словами (взяли только идею, но сделали иначе, но ядро в целом идентичное если не смотреть на код). и ниже про патенты зашла речь, как они могут помочь по отношению к алгоритмам, если результирующий алгоритм — это всего лишь наслоение алгоритмов из книг, например, того же Д.Кнута. патентовать достояние человечества или фундаментальные основы пока что не начали (или я не в курсе). в итоге получается хоть тресни, а работодатель беззащитен от копипасты/плагиата. и любой сотрудник подписавший все что ему подсунули может тупо твооить все что вздумается. или я совсем дурак ?)
в очень немногих компаниях есть подобные строки в контракте или где-то около того. в большинстве своем мы сами придумываем себе эти правила и живём с ними. крупные зарубежные компании на сколько я знаю это практикуют на регулярной основе, российские же компании часто этим пренебрегают, даже вполне себе крупные
не скажу точный названий и в целом деталей, но в буква закона, как минимум в направлении госсектора обязует твоего работодателя вознаграждать тебя за подписание отказа от авторских при передаче результатов контракта заказчику. даже если в трудовом четко и ясно написано, что ты ни чего имеешь и хочешь иметь с данного кода — все равно тебе должны заплатить.
Как точка отсчета explain очень даже хорош. Да, можно нагрузочные придумать и посмотреть на систему в динамике, а еще никадать не 10 параметров, а 100500 с неравномерным заполнением дабы было максимально близко с реальности (интернет-магазин всего и вся например).
Вот только есть одно НО: факт в том, что 99.9% проектов ни когда в жизни не достигнут таких объемов данных как в выборке у автора (смешные 10млн) и им куда важнее не скорость выолнения запроса, а скорость разработки этого самого проекта. И по классике жанра, все что тормозит — кладется в кэш и спят спокойно)
За статью спасибо.
Правда мне всегда было интересно зачем все это извращение с бинарными деревьями(кроме фана для души), когда существует более эффективное семейство B-деревьев.
а чем автора не устраивает pxd? обёртка над libnoise пишется минут за 20 копипастой из хедеров. да, есть момент для автоматизации в виде преобразования с/с++ хедеров в pxd, но там не такие объемы чтобы тратить на это столько времени. Вы же не собираетесь запилить комбайн покрывающий вообще все что есть в линуксах и немного сверху.
Я стараюсь больше уделять внимание тому, КАК кандидат мыслит, а не ЧТО он знает.
Конкретные знания конечно же важны, но в каком-то пределе, а вот умение мыслить — бесценно.
А тестовые не даем по нескольким причинам одна из которых — хорошие спецы в них не нуждаются и более того с высокой вероятностью сразу Вас пошлют при первом же намеке на тестовое (я и сам не люблю тестовые)
Есть только одно требование к подобным собеседованиям: все представители команды должны работать как единый организм, а не тянуть одеяло на себя.
Меня лично собеседовали и 5 технарей (вся дев команда) и солянка из представителей каждого организационного уровня. Что мне, как собеседуемому, позволяло понимать куда я попал и что будет дальше если принять оффер. В роли собеседующего (лида) за последние 2 года мы выработали практику, что в собеседовании участвуют минимум 2 технаря и всегда заранее обсуждаем некую стратегию чтобы не устраивать хаос. Не всегда, но частенько так же участвует hr дабы спрашивать другие правильные вопросы. После чего принимаем коллективное решение.
когда твой работодатель закрывает контракт и регистрирует ПО в каком-то там реестре российского ПО (речь про гос. заказы), то по букве закона с него требуют чтобы была отдельно заполненная бумажка с твоим отказом от авторских прав и за это тебе причитается разовое авторское отчисление. И букву закона тут совершенно не волнует сколько и каких именно бумажек ты подписал для своего работодателя.
Вот только есть одно НО: факт в том, что 99.9% проектов ни когда в жизни не достигнут таких объемов данных как в выборке у автора (смешные 10млн) и им куда важнее не скорость выолнения запроса, а скорость разработки этого самого проекта. И по классике жанра, все что тормозит — кладется в кэш и спят спокойно)
Правда мне всегда было интересно зачем все это извращение с бинарными деревьями(кроме фана для души), когда существует более эффективное семейство B-деревьев.