В теории можно написать простой SQL-запрос и, конечно, крупные компании имеют огромные хранилища, в которых вы можете запросто подобное реализовать.
У меня первая ассоциация была Splunk.
Но в рамках собеседования нам это не нужно. Поскольку эта задача не относится к распределённым системам, и обрабатываемые данные умещаются в память, зачем вносить излишнюю сложность и зависимости от базы данных для того, что можно решить с помощью всего 20 строк простого кода?
Можно просто уточнить, что интересует алгоритм, а не приложение. Это сразу отсекет массу вопросов про архитектуру, https://en.m.wikipedia.org/wiki/Non-functional_requirement и варианты написать программу с использованием высокоуровневых библиотек.
Вы на самом деле подняли интересную тему, но как-то сходу принялись ему возражать.
сложность любого алгоритма оцениваю с точки зрения его теоретической сложности на машине тюринга
Здесь, насколько я помню, есть лента с входными данными для чтения и лента для записи результа. А все что между ними это и есть сам алгоритм - разные аспекты сложности которого мы хотим оценить.
В отношении оценки по памяти нас интересует не объем данных, который мы прочитали-обработали-записали, а сколько памяти нужно компьютеру, чтобы выполнить наш алгоритм. Поэтому то, что находится на лентах мы не считаем.
Автор пишет:
only uses O(1) of memory
Memory это неформальный сленг. В CS обычно говорят про Space Complexity и Auxiliary Space Complexity. Первая характеризует общий объем, который требуется алгоритму, включая и входные переменные. Вторая - только объем дополнительных переменных (которые алгоритм аллоцирует сам). Короче Space = Input + Auxiliary.
we want to generate a list of ‘loyal customers’
Здесь все упирается в то, что он имеет ввиду говоря 'a list' - какой-то абстрактный список или же некую конкретную структуру данных из хаскеля?
Судя по тому, что он дальше пишет про O(1), его интересует лишь дополнительный объем - без учёта входных и выходных данных. В самом деле, они заданы условиями задачи и будут всегда одинаковыми, поэтому при сравнении алгоритмов ими можно пренебречь.
В общем если зачем-то очень хочется, то дядьку можно упрекнуть в некоторой нестрогости изложения. Но с другой стороны, это публицистика, а не научная статья, чтобы устраивать ему за это вендетту.
Так как ничего не сказано про дни, ничего не сказано про погоду, ничего не сказано про день рождения директора, ничего не сказано про любовницу, то и спрашивать про это здесь выглядит лишним.
В этом, мне кажется, и стоит основная разница между мышлением олимпиадников и, назовем их, - коммерческих разработчиков.
Первые всецело доверяют постановщику задачи, понимают условие буквально и на этом сильно экономят своё время.
Вторые знают, что бизнес не умеет в буквальные формулировки, и поэтому сомневаются в каждом слове. Но в итоге это экономит деньги.
Оба подхода имеют право на существование, адекватный результат получается только в своем контексте.
Вы правда думаете, что можете посоветовать что-то автору поста в вопросах "выживания"?
Мне показалось, что автор уже пережила этот этап.
На самом деле я например не чувствую особенного отношения, в рабочих вопросах по-крайней мере.
Это комплексный вопрос. Любые простые ответы вместе с долей негатива исключают и позитивные моменты. Поэтому тема является постоянным источником для жарких споров. Просто пара примеров.
В офисе есть довольно много моментов, которые напрямую не касаются функциональных обязанностей: что будем дарить на день рождения или 8 марта, кому менять бутыль с водой в кулере, и т.п. Все это добавляет эмоциональных красок в повседневную рутину, делая работу больше похожей на нормальную жизнь, чем долбаную матрицу.
На удалёнке, в распределенных командах, такие уголки сглаживаются, и сотрудник здесь просто безликий ресурс с аватаркой. С одного стороны - мечта интроверта. С другой - глобально индустрия стремится к унификации. Чем меньше выделяешься, тем легче расстаться и проще заменить. Win-Win.
Но при смене работы каждый раз приходится доказывать коллегам, что взяли меня на должность на основе честного собеседования и тестового задания, как и всех остальных.
С этим сталкивается каждый, независимо от пола и должности - будь то стажёр или директор. Примерно первые полгода. Команда проверяет новичка на "прочность", стараясь нащупать рамки доверия и границы дозволенного. Потом становится проще. В ход могут идти различные приемы, в том числе и то, что давит на самооценку. Тут не важно женщина вы или мужчина, чёрный или белый, верующий или атеист - если вас это цепляет. Но это уже тема harassment. В здоровом коллективе будет просто повышенное внимание к новичку, от которого не понятно чего ожидать. Здесь главное не путать.
Мы с женой тоже мало пересекаемся по хард скиллам и в этом плане отлично дополняем друг друга в семейной жизни, а не сравниваем.
На работе же люди чаще преследуют свои собственные интересы и делают это кто как умеет. Некоторые в погоне за признанием прибегают к грубым приемам. Например, выделяют лишь недостатки других в сфере своих собственных интересов и принижают чужие заслуги, где не разбираются сами. Реально командные отношения встречаются не так часто, как про это пишут Scrum-апологеты.
На моей родине, комплименты прямым текстом традиционно расцениваются скорее как лесть, подхалимство или проявление в поведении "чуждой нам европейской гей-культуры". Суровые уральские мужики так не говорят. Использование черного юмора на грани токсичности наоборот считается допустимой формой выражения приязни. Утрируя, сказать "какая ты умничка" - нельзя. "Я думал ты дура накрашенная, а ты вообще ничего - соображаешь" - можно. Короче, стиль "шоу уральских пельменей", изрядно вплетеный в нормы бытового этикета. Когда долго не живёшь в среде, то возвращаясь приходится держать в уме, что люди в общем-то хотят друг другу добра и общаясь таким образом проявляют исключительно свою доброжелательность и позитивный настрой.
представитель заказчика, крайне неприятный товарищ
Здесь немножко другой уровень. Работа BA во многом связана с людьми и доставать требования порой приходится из разного хлама. Поэтому им нужно уметь налаживать контакты и работать с совершенно разными персонажами, без вреда для самооценки. Подпускать таких "представителей" напрямую к разработчикам конечно не стоит.
У моей коллеги был коронный аргумент: "я же блондинка - мне можно".
К девчонкам в преимущественно мужском коллективе действительно особенное отношение (кстати как и к парням в женском). Как эти особенности будут проявляться сильно зависит от традиций и культуры.
Но в любом случае, пытаться быть как все и требовать такого же отношения, от других это практически невыполнимая миссия - ни для себя, ни для коллег. Стратегия выживальщика - стать для них кем-то особенным. Я как то несколько месяцев подряд работал на территории колцентра, где вокруг были одни девушки. Без чувства юмора и отрефлексированной самооценки думаю там реально было съехать с катушек, особенно по началу в период взаимной адаптации.
Армия как вариант, где мат это не грубость, а профессиональный сленг. Девчонки стараются не отставать и часто обгоняют парней, аж уши заворачиваются.
Мне кажется в период юношеского самоутверждения все получают свою долю синяков, независимо от рода занятий. Многое конечно зависит от среды: если вокруг культура преимущественно токсична, то вряд-ли работа (детсад, школа, вуз) даст что-то принципиально иное. Хотя бывают и исключения.
Через 15 и дальше лет все это воспринимается иначе, и если там не случалось непоправимых травм, то это просто взросление.
Через несколько лет нынешние преимиумы будут продаваться как б/у, по цене "Москвича". Да и технологии из премиумов сейчас довольно быстро спускаются в сегменты ниже.
Например, для него запрос «создать массив случайных чисел в Python» означает «импортировать случайные числа», а затем «random_numbers = [random.randint(1, 100) for _ in range(5)]»
Здесь тоже получается, что переводчики не всегда улавливают контекст.
For example, “create an array of random numbers in Python” does “import random”, then “random_numbers = [random.randint(1, 100) for _ in range(5)]”.
чемпион — это кто угодно, кроме сотрудника с четко определенными обязанностями и выделенной должностью
Champion это ответственный исполнитель, роль. Как ответственный за технику безопасности, ответственный за пожарную безопасность и т.п. в каждом отдельном кабинете.
Соответственно Security Champion в команде разработки это точка входа для различных вопросов, касающихся собственно security, в рамках зоны ответственности этой команды. Через него департамент безопасности внедряет в команду свои практики и тактики. В него маршрутизируются баги. К нему приходят в случае проверок и делают козлом отпущения всех грехов.
упоминание security champion идет вкупе с четким указанием того, что позиция это скорее волонтерская
В Project Manager'а наличие такой роли в команде спускается как требование. Дальше он может либо оставить ее на себе, либо делегировать вниз. Чаще всего таким персонажем становится Team Lead, естественно по доброте душевной.
этот человек участвует практически во всех процессах внутри компании – как ни крути, а ИБ важна везде. Маркетинг, поддержка, кадры, фронт- и бекофис, инфраструктура – всё это нуждается в персональном консультанте, который готов прийти на помощь в любой момент
Здесь скорее задачи Security Architect, Security Advisor, SecOps и ещё пары ролей. Эти ребята являются штатными сотрудниками департамента безопасности, они формируют стратегии и тактики, разрабатывают нормативную базу, обучают, внедряют, анализируют, и в том числе сеют свое добро в команды через местных чемпионов.
То есть вы считаете, что фальсифицируемость субъективна, а не объективна?
Фальсифицируемость это не закон природы, а логический критерий оценки. Применение логики к физике и что мы считаем объективным это два философские вопроса, ответы на которые в итоге сводятся к текущему научному консенсусу.
выигравшая сторона может получить вполне весомые выгоды
Практика французской и октябрьской показала, что бенефициароми становятся совсем другие люди. "Революция, как бог Сатурн, пожирает своих детей".
Революции устраивают силами протесно настроенных граждан, и это в большинстве своём отнюдь не романтически настроенная интеллигенция, а те, кто реально может и готов все крушить. Пока они нужны, их восхваляют. Но рано или поздно революции заканчиваются, а люди не меняются. В мирной жизни такие герои неудобны любой власти, которая хочет для себя какой-никакой стабильности, и победители от них всегда избавляются.
Привычные, величественно-романтические картинки общества в состоянии революции из учебников истории, литературы и советского кино, показывают нам сцены, где мифологизированные герои сражаются со злодеями ради общего блага. Мне раньше казалось, что Булгаков в "Мастер и Маргарите" от лица проф. Преображенского все это довольно сильно извратил. Но сейчас оценки поменялись местами. Революция это сила разрушения, а не созидания. Смысла в этом не больше, чем в любой другой войне людей с людьми.
У меня первая ассоциация была Splunk.
Можно просто уточнить, что интересует алгоритм, а не приложение. Это сразу отсекет массу вопросов про архитектуру, https://en.m.wikipedia.org/wiki/Non-functional_requirement и варианты написать программу с использованием высокоуровневых библиотек.
Вы на самом деле подняли интересную тему, но как-то сходу принялись ему возражать.
Здесь, насколько я помню, есть лента с входными данными для чтения и лента для записи результа. А все что между ними это и есть сам алгоритм - разные аспекты сложности которого мы хотим оценить.
В отношении оценки по памяти нас интересует не объем данных, который мы прочитали-обработали-записали, а сколько памяти нужно компьютеру, чтобы выполнить наш алгоритм. Поэтому то, что находится на лентах мы не считаем.
Автор пишет:
Memory это неформальный сленг. В CS обычно говорят про Space Complexity и Auxiliary Space Complexity. Первая характеризует общий объем, который требуется алгоритму, включая и входные переменные. Вторая - только объем дополнительных переменных (которые алгоритм аллоцирует сам). Короче Space = Input + Auxiliary.
Здесь все упирается в то, что он имеет ввиду говоря 'a list' - какой-то абстрактный список или же некую конкретную структуру данных из хаскеля?
Судя по тому, что он дальше пишет про O(1), его интересует лишь дополнительный объем - без учёта входных и выходных данных. В самом деле, они заданы условиями задачи и будут всегда одинаковыми, поэтому при сравнении алгоритмов ими можно пренебречь.
В общем если зачем-то очень хочется, то дядьку можно упрекнуть в некоторой нестрогости изложения. Но с другой стороны, это публицистика, а не научная статья, чтобы устраивать ему за это вендетту.
В этом, мне кажется, и стоит основная разница между мышлением олимпиадников и, назовем их, - коммерческих разработчиков.
Первые всецело доверяют постановщику задачи, понимают условие буквально и на этом сильно экономят своё время.
Вторые знают, что бизнес не умеет в буквальные формулировки, и поэтому сомневаются в каждом слове. Но в итоге это экономит деньги.
Оба подхода имеют право на существование, адекватный результат получается только в своем контексте.
Без относительно самой гостьи, статья является примером нормальной журналистики. Жаль, что получила не так много плюсиков.
Мне показалось, что автор уже пережила этот этап.
Это комплексный вопрос. Любые простые ответы вместе с долей негатива исключают и позитивные моменты. Поэтому тема является постоянным источником для жарких споров. Просто пара примеров.
В офисе есть довольно много моментов, которые напрямую не касаются функциональных обязанностей: что будем дарить на день рождения или 8 марта, кому менять бутыль с водой в кулере, и т.п. Все это добавляет эмоциональных красок в повседневную рутину, делая работу больше похожей на нормальную жизнь, чем долбаную матрицу.
На удалёнке, в распределенных командах, такие уголки сглаживаются, и сотрудник здесь просто безликий ресурс с аватаркой. С одного стороны - мечта интроверта. С другой - глобально индустрия стремится к унификации. Чем меньше выделяешься, тем легче расстаться и проще заменить. Win-Win.
С этим сталкивается каждый, независимо от пола и должности - будь то стажёр или директор. Примерно первые полгода. Команда проверяет новичка на "прочность", стараясь нащупать рамки доверия и границы дозволенного. Потом становится проще. В ход могут идти различные приемы, в том числе и то, что давит на самооценку. Тут не важно женщина вы или мужчина, чёрный или белый, верующий или атеист - если вас это цепляет. Но это уже тема harassment. В здоровом коллективе будет просто повышенное внимание к новичку, от которого не понятно чего ожидать. Здесь главное не путать.
Мы с женой тоже мало пересекаемся по хард скиллам и в этом плане отлично дополняем друг друга в семейной жизни, а не сравниваем.
На работе же люди чаще преследуют свои собственные интересы и делают это кто как умеет. Некоторые в погоне за признанием прибегают к грубым приемам. Например, выделяют лишь недостатки других в сфере своих собственных интересов и принижают чужие заслуги, где не разбираются сами. Реально командные отношения встречаются не так часто, как про это пишут Scrum-апологеты.
На моей родине, комплименты прямым текстом традиционно расцениваются скорее как лесть, подхалимство или проявление в поведении "чуждой нам европейской гей-культуры". Суровые уральские мужики так не говорят. Использование черного юмора на грани токсичности наоборот считается допустимой формой выражения приязни. Утрируя, сказать "какая ты умничка" - нельзя. "Я думал ты дура накрашенная, а ты вообще ничего - соображаешь" - можно. Короче, стиль "шоу уральских пельменей", изрядно вплетеный в нормы бытового этикета. Когда долго не живёшь в среде, то возвращаясь приходится держать в уме, что люди в общем-то хотят друг другу добра и общаясь таким образом проявляют исключительно свою доброжелательность и позитивный настрой.
Здесь немножко другой уровень. Работа BA во многом связана с людьми и доставать требования порой приходится из разного хлама. Поэтому им нужно уметь налаживать контакты и работать с совершенно разными персонажами, без вреда для самооценки. Подпускать таких "представителей" напрямую к разработчикам конечно не стоит.
У моей коллеги был коронный аргумент: "я же блондинка - мне можно".
К девчонкам в преимущественно мужском коллективе действительно особенное отношение (кстати как и к парням в женском). Как эти особенности будут проявляться сильно зависит от традиций и культуры.
Но в любом случае, пытаться быть как все и требовать такого же отношения, от других это практически невыполнимая миссия - ни для себя, ни для коллег. Стратегия выживальщика - стать для них кем-то особенным. Я как то несколько месяцев подряд работал на территории колцентра, где вокруг были одни девушки. Без чувства юмора и отрефлексированной самооценки думаю там реально было съехать с катушек, особенно по началу в период взаимной адаптации.
Армия как вариант, где мат это не грубость, а профессиональный сленг. Девчонки стараются не отставать и часто обгоняют парней, аж уши заворачиваются.
Мне кажется в период юношеского самоутверждения все получают свою долю синяков, независимо от рода занятий. Многое конечно зависит от среды: если вокруг культура преимущественно токсична, то вряд-ли работа (детсад, школа, вуз) даст что-то принципиально иное. Хотя бывают и исключения.
Через 15 и дальше лет все это воспринимается иначе, и если там не случалось непоправимых травм, то это просто взросление.
Через несколько лет нынешние преимиумы будут продаваться как б/у, по цене "Москвича". Да и технологии из премиумов сейчас довольно быстро спускаются в сегменты ниже.
Здесь тоже получается, что переводчики не всегда улавливают контекст.
Может нарисовать пляж когда все нудисты только разошлись.
Champion это ответственный исполнитель, роль. Как ответственный за технику безопасности, ответственный за пожарную безопасность и т.п. в каждом отдельном кабинете.
Соответственно Security Champion в команде разработки это точка входа для различных вопросов, касающихся собственно security, в рамках зоны ответственности этой команды. Через него департамент безопасности внедряет в команду свои практики и тактики. В него маршрутизируются баги. К нему приходят в случае проверок
и делают козлом отпущения всех грехов.В Project Manager'а наличие такой роли в команде спускается как требование. Дальше он может либо оставить ее на себе, либо делегировать вниз. Чаще всего таким персонажем становится Team Lead, естественно по доброте душевной.
Здесь скорее задачи Security Architect, Security Advisor, SecOps и ещё пары ролей. Эти ребята являются штатными сотрудниками департамента безопасности, они формируют стратегии и тактики, разрабатывают нормативную базу, обучают, внедряют, анализируют, и в том числе сеют свое добро в команды через местных чемпионов.
Фальсифицируемость это не закон природы, а логический критерий оценки. Применение логики к физике и что мы считаем объективным это два философские вопроса, ответы на которые в итоге сводятся к текущему научному консенсусу.
Ключевые моменты увольнения и компенсации обычно прописываются в контракте. Ты знаешь все условия заранее, кроме даты.
"Собачье сердце", спасибо, я дурилка.
Практика французской и октябрьской показала, что бенефициароми становятся совсем другие люди. "Революция, как бог Сатурн, пожирает своих детей".
Революции устраивают силами протесно настроенных граждан, и это в большинстве своём отнюдь не романтически настроенная интеллигенция, а те, кто реально может и готов все крушить. Пока они нужны, их восхваляют. Но рано или поздно революции заканчиваются, а люди не меняются. В мирной жизни такие герои неудобны любой власти, которая хочет для себя какой-никакой стабильности, и победители от них всегда избавляются.
Привычные, величественно-романтические картинки общества в состоянии революции из учебников истории, литературы и советского кино, показывают нам сцены, где мифологизированные герои сражаются со злодеями ради общего блага. Мне раньше казалось, что Булгаков в "Мастер и Маргарите" от лица проф. Преображенского все это довольно сильно извратил. Но сейчас оценки поменялись местами. Революция это сила разрушения, а не созидания. Смысла в этом не больше, чем в любой другой войне людей с людьми.
Одни начали использовать ИИ для написания фейковых отзывов, другие - для поиска. Населению не понять, они здесь - товар. Битва роботов уже началась.