Comments 158
Какой то оверпауэр для джуниора, Имхо. Как задача с монетами решается?
Положить в оба носка по 50 монет, а затем один носок положить во второй
Спасибо, действительно оригинально. Но, Имхо, слабо отражает реальность. Это скорее ребус, а не задача. Вот про кольцо вагонов мне понравилась.
Классно.
Можно передавать в Парижскую палату мер и весов как эталон задачи, которая не подойдет для собеседования.
Можно передавать в Парижскую палату мер и весов как эталон задачи, которая не подойдет для собеседования.
Зато тут можно проверить не способность к решению ребусов, а поведение человека при общении с заказчиком.
Вот говоришь ты такой: «Нам для БД нужно два сервера, master и hot standby».
А тебе в ответ: «У нас будет только один сервер».
А ты: «Ok, давайте развернем standby в виртуалке на том же сервере. Так еще и количество ядер удвоится».
Все довольны. Занавес =)
Вот говоришь ты такой: «Нам для БД нужно два сервера, master и hot standby».
А тебе в ответ: «У нас будет только один сервер».
А ты: «Ok, давайте развернем standby в виртуалке на том же сервере. Так еще и количество ядер удвоится».
Все довольны. Занавес =)
Это же всё не с одного собеседования: в каждой компании по одному-два вопроса по SQL вот, наверное, и накопилось. Скорее всего это не решающие вопросы, а проверка кругозора, насколько известны-понятны кандидату смежные темы/технологии.
UFO just landed and posted this here
Я конечно не шибко в теме знаний конкретно .Net девелопера, но проведя аналогию, меня такими вопросами заваливали на тех. лида/директора.
Как то страшно и радостно, что уровень джуниоров так вырос (или это частный случай?)
Как то страшно и радостно, что уровень джуниоров так вырос (или это частный случай?)
Смотрят не сколько ты сделаешь/знаешь, а где сломаешься.
И в чем смысл (для работодателя)? Он кого ищет? Того кого можно сломать или человека, который выполнит задачу?
«Сломать» не следует понимать буквально, а следует понимать в контексте возможностей претендента.
Людей обычно «ломают» не вопросами, рабочей обстановкой.
Людей обычно «ломают» не вопросами, рабочей обстановкой.
Тут правильнее сказать «нащупать горизонт эрудиции и опыта». Просто посмотреть, насколько этот Junior разбирается в теме и как работают мозги. Других вариантов я не вижу, разве что опять понатырили вопросов из топ.собеседований гугла.
Но тут в вопросах по .Net явный перекос в теоретику. В отличие от SQL, например. Некоторые пункты могут вообще ни разу не встретиться за годы разработки.
И если человек ответил на все вопросы, то тут два варианта:
- У него есть 10 лет опыта в разноплановых проектах на C#.
- Он заучил справочник перед собеседованием.
И в случае собеседования на джуна / мидла ответ очевиден :)
Я ответил на многие вопросы, но с C# слабо знаком.
Ну вообще там были вопросы про LINQ, что чисто C#-фича. Абстрактные классы и интерфейсы на уровне синтаксиса — тоже фича C# и Java, а в том же C++ нету интерфейсов и это уже вопрос, что называть платоновским человеком — вроде две ноги, нет перьев, а [ощипанная] курица.
MVVM — это тоже MVC--костыль к WPF и Силверлайт (или WPF это костыль к MVVM — это дискуссионный вопрос).
Event и delegate — опять таки чисто .NET мозгокрутка. В Жабе делгатов нет, а в С/C++ вместо этого дотнетовского зоопарка хватает обычного теплого и лампового указателя. Да и вообще вопрос холиварный ИМХО
MVVM — это тоже MVC--костыль к WPF и Силверлайт (или WPF это костыль к MVVM — это дискуссионный вопрос).
Event и delegate — опять таки чисто .NET мозгокрутка. В Жабе делгатов нет, а в С/C++ вместо этого дотнетовского зоопарка хватает обычного теплого и лампового указателя. Да и вообще вопрос холиварный ИМХО
В том-то и дело, что шкала оценки нелинейна. 80% ответов без подготовки лучше, чем 100% с подготовкой.
Ну может спрашивают то же самое, но ожидания ниже.
Я на половину вопросов про паттерны и ООП вообще в интернет лазил, потому что раньше помнил, но забыл за ненадобностью. Лично для меня вызывает удивление, почему такие очевидные вещи, как использование интерфейсов и абстрактных классов теперь называется паттернами проектирования, и требуется их знание на уровне определений.
Паттерны настолько холиварная тема, что спрашивать ее в прямую на собеседовании на уровне испытания ядерной бомбы )))
Я обычно спрашивал в ответ. А вы уверены, что вам надо, чтобы я это знал?
Ну использую я синглтон, обсервер, адаптер. Так я их использовал и до того как они стали паттернами. Но чтобы объяснить чем фасад отличается от адаптера, мне надо в вики слазать. Мне можно уйти?
Хотя сеньоров больше по практике гоняют. Что сделал, что не сделал. А вот такой проблемы у вас не было. Была? И как решали? Что правда так? А мы-то почти без извращений обошлись…
Ну использую я синглтон, обсервер, адаптер. Так я их использовал и до того как они стали паттернами. Но чтобы объяснить чем фасад отличается от адаптера, мне надо в вики слазать. Мне можно уйти?
Хотя сеньоров больше по практике гоняют. Что сделал, что не сделал. А вот такой проблемы у вас не было. Была? И как решали? Что правда так? А мы-то почти без извращений обошлись…
Паттерны вводились в разработческий обиход для упрощения общения. А сотрудники которые «всё понимают, а сказать не могут» явно востребованы меньше.
Скорее они уж вводились для того, чтобы если где-то что-то можно абстрагировать, то люди не выдумывали велосипеды. Есть много направлений кодинга, где нельзя просто взять и использовать паттерны как есть и рассчитывать на успех. И не знание их названий, для таких программистов, вовсе не значит, что они востребованы меньше.
Проблема паттернов в том, что их настолько раздули до состояние «божественности», что многие их пихают куда-то только можно, что порой приводит не к решению проблем, а к их росту в кратном размере.
Всему свое место.
Проблема паттернов в том, что их настолько раздули до состояние «божественности», что многие их пихают куда-то только можно, что порой приводит не к решению проблем, а к их росту в кратном размере.
Всему свое место.
> Паттерны вводились в разработческий обиход для упрощения общения
Да, для упрощения общения и оформления кусков кода, похожих на паттерн, соответствующим образом, чтобы при чтении чужого кода возникало меньше вопросов.
> А сотрудники которые «всё понимают, а сказать не могут» явно востребованы меньше.
То есть сотрудник, которые использует термины «прокладка»/«прокси», «враппер» вместо «фасад», «адаптер» востребован меньше? А термин «шаблонный класс» для программиста на С++ вообще означает совсем другое, а не паттерн.
Да, для упрощения общения и оформления кусков кода, похожих на паттерн, соответствующим образом, чтобы при чтении чужого кода возникало меньше вопросов.
> А сотрудники которые «всё понимают, а сказать не могут» явно востребованы меньше.
То есть сотрудник, которые использует термины «прокладка»/«прокси», «враппер» вместо «фасад», «адаптер» востребован меньше? А термин «шаблонный класс» для программиста на С++ вообще означает совсем другое, а не паттерн.
> А термин «шаблонный класс» для программиста на С++ вообще означает совсем другое, а не паттерн.
Вы путаете с «шаблонным методом». Паттерна «шаблонный класс» не сущестует.
Вы путаете с «шаблонным методом». Паттерна «шаблонный класс» не сущестует.
> Вы путаете с «шаблонным методом». Паттерна «шаблонный класс» не сущестует.
От этого суть моего комментария не меняется. Вот шаблонный метод:
А называть паттерн «шаблонным методом», а не классом, у меня язык не поворачивается, потому что он представляет собой класс, а не отдельный метод.
От этого суть моего комментария не меняется. Вот шаблонный метод:
template <class T>
void DoSomething(const std::vector<T> &data);А называть паттерн «шаблонным методом», а не классом, у меня язык не поворачивается, потому что он представляет собой класс, а не отдельный метод.
> А называть паттерн «шаблонным методом», а не классом, у меня язык не поворачивается, потому что он представляет собой класс
Сама суть паттернов в том, чтобы иметь общепринятые названия. А общепринятое название — шаблонный метод.
> потому что он представляет собой класс, а не отдельный метод
Больше половины паттернов представляют собой класс, но от этого они не называются «класс». Потому что их название отражает не их реализацию в коде, а их суть. И суть паттерна «шаблонный метод» в том, чтобы иметь шаблон метода, где под шаблоном понимается заготовленная реализация с переопределяемыми шагами.
Сама суть паттернов в том, чтобы иметь общепринятые названия. А общепринятое название — шаблонный метод.
> потому что он представляет собой класс, а не отдельный метод
Больше половины паттернов представляют собой класс, но от этого они не называются «класс». Потому что их название отражает не их реализацию в коде, а их суть. И суть паттерна «шаблонный метод» в том, чтобы иметь шаблон метода, где под шаблоном понимается заготовленная реализация с переопределяемыми шагами.
Может смысл в том что на junior-а и изучить насколько хорошая память и знает теорию?
К примеру в вопросах по sql попался кластеризированный индекс, это же не про sql как таковой а про mssql(в oracle это будет ibdex organazed table), причём же тут .net платформа?
И в принципе проработав много лет с .net можно с половиной тем не встретится :)
причём же тут .net платформа?Юольшинство вакансий на .NET это Asp.NET, по крайней мере, субъективно выглядит так. Автор, похоже, тоже на эти выкансии пробовался. Ну а там где asp.net там почти всегда mssql. Вот и вся история.
Видимо, таки да. По опыту работы спрашивать большого смысле нет. Если что и сделал, то вряд ли этим стоит гордится (по себе студенту сужу).
Если на теорию отвечает — значит читал, разбирался, помнит. По хорошему можно ещё допвопросы задавать на предмет догадается ли как это применить. Но доп вопросы ещё придумать надо ))))
Если на теорию отвечает — значит читал, разбирался, помнит. По хорошему можно ещё допвопросы задавать на предмет догадается ли как это применить. Но доп вопросы ещё придумать надо ))))
Среди джуниоров конкуренция за рабочие места выше, чем среди миддлов/сеньоров, к сожалению, не так давно сам с этим столкнулся. Поэтому компании могут себе позволить фильтровать кандидатов, как им вздумается. Ну и пресловутый совет, который везде можно услышать — «лучше хоть как-то подтянуть знания, хоть где-то набраться практики и пробоваться сразу на вакансию мидла».
Компания ищет себе молодых специалистов и для их привлечения указывает в вакансии зарплату в N денег, которая выше среднерыночной и будет привлекать к себе много внимания. Но компания не хочет действительно платить джуну N денег. Он приходит на собеседование, где ему дают такие задачки. Задачки ему с трудом даются. И потом ему говорят: «Знаете, Вы нам подходите, но всё-таки у вас есть недостаток знаний-сами видите, поэтому мы готовы взять вас за N-40%».
Трижды проходил собеседования на позицию Sr.Firmware Engineer в компаниях Tesla, Apple и в каком-то стартапе. Нигде не было задач на логику типа вагонов и монет с носками. В стартапе только были задания на знание школьной математики и физики. Их задают, когда нормальных вопросов для интервью придумать не могут?
Если не секрет, какого рода вопросы были на собеседованиях в Tesla и Apple?
Не проходил собеседования в Tesla / Apple, но проходил в других больших компаниях, и советую книжку "Cracking the Coding Interview by Gayle Laakmann McDowell". Автор работала в Google, Microsoft, и Apple, и вопросы в больших компаниях в основном очень похожи.
У меня походу одна из коллег (девушка, как и автор) походу тайно фанатеет от этой книги. Где-то к 10-ой минуте собеседования с ней мне стало грустно и уныло, захотелось пойти домой и попить кофе с зефирками.
Если что, то собеседовали человека ко мне и под мою задачу, а она за компанию пошла…
С другой стороны может и правильный подход
Если что, то собеседовали человека ко мне и под мою задачу, а она за компанию пошла…
С другой стороны может и правильный подход
Неправильный. Крупные компании, в основном, задают такие вопросы на этапе phone screen / skype interview, потому что они не могут позволить себе возить к себе в офис всех за свой счет, и им нужно отсеять 90%. Они отсеивают тех ребят, которые умеют быстро за ограниченное время решать сложные логические задачи.
В небольшой компании в таких вопросах смысла нет, гораздо лучше спросить то, с чем необходимо иметь дело в работе (особенности языка, паттерны, boxing / unboxing, итд).
Лучший способ отсеять удаленно — попросить написать програмку или попросить дать ссылку на свой код (и то и то хорошо, но не все могут выложить свой код).
Это вот как раз может отсеять 90% кандидатов, если требования на позицию высокие (если нет, то можно брать всех подряд).
Конкретно в моем случае, еще 90% отсеивалось после моего увлекательного рассказа что здесь надо делать и через какой мир боли придется пройти. Но тут правда действительно задача для супер-героев.
Но это все если позиция действительно сложная. Если что-то простое, то можно всех подряд брать, а про boxing и unboxing человек может потом и в MSDN прочитать для общего образования. Потом все равно по какой-то магической причине у человека который рассказывал на собеседовании про boxing/unboxing но все равно пишет:
Что в принципе нифига не смертельно.
Или
Хотя ArrayList наверное никто не использует уже… на самом деле .NET в этом плане несколько более дружелюбный. Это вот в Жабе можно испытать батхерт от Long и long например.
Это вот как раз может отсеять 90% кандидатов, если требования на позицию высокие (если нет, то можно брать всех подряд).
Конкретно в моем случае, еще 90% отсеивалось после моего увлекательного рассказа что здесь надо делать и через какой мир боли придется пройти. Но тут правда действительно задача для супер-героев.
Но это все если позиция действительно сложная. Если что-то простое, то можно всех подряд брать, а про boxing и unboxing человек может потом и в MSDN прочитать для общего образования. Потом все равно по какой-то магической причине у человека который рассказывал на собеседовании про boxing/unboxing но все равно пишет:
Point pt = new Point();
Console.WriteLine(pt);
Что в принципе нифига не смертельно.
Или
int i = 10;
ArrayList arrlst = new ArrayList();
arrlst.Add(i);
int j = (int)arrlst[0];
Хотя ArrayList наверное никто не использует уже… на самом деле .NET в этом плане несколько более дружелюбный. Это вот в Жабе можно испытать батхерт от Long и long например.
> Потом все равно по какой-то магической причине у человека который рассказывал на собеседовании про boxing/unboxing но все равно пишет:
А что не так с первым кодом? Да, там есть боксинг, но накладные расходы на него пренебрежимо малы по сравнению со стоимостью вызова `Console.WriteLine`, а усложнять читаемость кода явным вызовом `pt.ToString()` не хочется.
А что не так с первым кодом? Да, там есть боксинг, но накладные расходы на него пренебрежимо малы по сравнению со стоимостью вызова `Console.WriteLine`, а усложнять читаемость кода явным вызовом `pt.ToString()` не хочется.
`Console.WriteLine` сам вызывает метод ToString() передаваемого в него параметра (MSDN). Так что не совсем даже понимаю где здесь boxing/unboxing
Спасибо. Про книгу слышал, но хочется узнать именно про личный опыт.
Во всех местах просили реализовать какой-нибудь вариант очереди либо стэка. Часто спрашивают про static, const, volatile в С. Почему-то популярный вопрос, как определить, что число — степерь двойки. Разные задачки на простые манипуляции с битами, проверяют знания, как работают сдвиги и логические операции. Простые имплементации связанных списков. Спрашивают как работает RTOS, как происходит переключение контекста, семафоры, мьютексы, зачем это все нужно и чем одно отличается от другого. По алгоритмам самыми сложными были вопросы реализовать binary heap и определить, что связанный список имеет кольцо и разорвать его. Никогда не спрашивали ничего про деревья и графы.
Много вопросов по железу т.к. позиция Firmware Engineer то проверяют есть ли хоть базовые понятия о том, как работает электроника.
Много вопросов по железу т.к. позиция Firmware Engineer то проверяют есть ли хоть базовые понятия о том, как работает электроника.
> Почему-то популярный вопрос, как определить, что число — степерь двойки
Вызвать инструкцию POPCNT через интринсик компилятора. Такой ответ принимается?
Вызвать инструкцию POPCNT через интринсик компилятора. Такой ответ принимается?
Интересные вопросы. Спасибо за подробный ответ.
Потратили бы десяток минут за чашечкой чая, поправили бы пунктуацию и прочее, ничего бы страшного не случилось, невозможно же читать.
А ведь это даже не песочница, — приветствую тебя, Хабрахабр образца 2017 года! O tempora, o mores!
А ведь это даже не песочница, — приветствую тебя, Хабрахабр образца 2017 года! O tempora, o mores!
JosefDzeranov, спасибо. Вы и сами, наверное, cогласитесь с тем, что стало гораздо лучше.
sql-ex.ru — для начинающих самое оно
Удивлен, что вам, автор, не предложили middle позицию.
Middle всё же подразумевает опыт и навык в первую очередь, а не пару хорошо проштудированных справочников.
Открытый вопрос. Работник с малым опытом, но крепкими знаниями, которого уже не надо учить — это мидл или нет? Полгода на проекте и будет у него опыт.
Разделение условное. И, думаю, вполне толкового новичка можно ставить на мидл позицию, если он умеет обраться с людьми.
На middle нужен опыт работы.
Недавно искал работу на должность Middle JS разроботчка. Разместил резюме на сайте поиска работы и мне, однажды, позвонили из одной американской компании (украинский отдел). Дали ссылку на вакансию, там было написано, что требуемый опыт работы 3 года, в то время как у меня всего 2. Думаю ладно, может число с неба взяли. Выполнил задание, прошел тех. собеседование. Через пару дней ответили, что я понравился украинскому отделу, но конечное решение принимает американский, и там думают, что 2 года это мало, поэтому отказ.
Сам я по этому поводу не сильно расстроился, т.к. уже был оффер, плюс в тестовом задании ножно было использовать, для меня, стэк, что хорошо для развития.
Но вообще, лучше переспрашивать в подобных случаях.
Недавно искал работу на должность Middle JS разроботчка. Разместил резюме на сайте поиска работы и мне, однажды, позвонили из одной американской компании (украинский отдел). Дали ссылку на вакансию, там было написано, что требуемый опыт работы 3 года, в то время как у меня всего 2. Думаю ладно, может число с неба взяли. Выполнил задание, прошел тех. собеседование. Через пару дней ответили, что я понравился украинскому отделу, но конечное решение принимает американский, и там думают, что 2 года это мало, поэтому отказ.
Сам я по этому поводу не сильно расстроился, т.к. уже был оффер, плюс в тестовом задании ножно было использовать, для меня, стэк, что хорошо для развития.
Но вообще, лучше переспрашивать в подобных случаях.
Про 80% не удивительно, удивительно, что не 100. Такие вопросы и джуниорская зп.
Зарплата вовсе не способностями определяется, а скорее стажем. Часто видел откровенно посредственных сеньоров и даже принципалов как и выдающихся джуниоров.
Я не понимаю зачем джуну задавать столько таких вопросов. Если ты с этим всем работаешь несколько лет, то ты все это хочешь-не хочешь, а запомнил. Но тогда речь пойдет не о джуне. А джун это может только выучить как стишок. Компаниям нужен человек, который хорошо учит стихи и прозу? По-моему лучше послушать как человек рассуждает и понять нормально ли он впишется. А остальное приложится.
С решением же логических задачек вообще непонятно. Уже давно известный факт, что умение их решать говорит лишь о умении решать логические задачи. Не более того. Сильно сомневаюсь, что это хоть как-то относится к профилю хоть одной компании.
Может быть кто-то знает ответы на эти вопросы. Зачем это все?
С решением же логических задачек вообще непонятно. Уже давно известный факт, что умение их решать говорит лишь о умении решать логические задачи. Не более того. Сильно сомневаюсь, что это хоть как-то относится к профилю хоть одной компании.
Может быть кто-то знает ответы на эти вопросы. Зачем это все?
А что у него еще спрашивать? Джун на то и джун, что у него еще нет опыта, но должно быть максимум зазубренной теории, которую он через практику, превратит в опыт, и тогда он не будет уже джуном. Смысл слушать как он рассуждает? Опыта нет, рассуждать будет по книгам, которые написали люди, которые хорошо пишут книги, не более. Конечно, пообщаться с ним на предмет его адекватности необходимо, ну а дальше только логические задачки и пр.
Ага) меня вот так в институте обучали, вместо практики теория или теория без практики. В итоге я работаю совершенно в другой области. Особенно весело было на первой практике на 4 курсе, когда ты понимаешь, что совершенно не понимаешь куда эту теорию прикладывать и как.
А зачем этот зазубренный максимум? Лично вам как работодателю или коллеге? У вас это «все-все-все» применяется? Вот сильно сомневаюсь. К тому-же по моему опыту обычно так: есть те, кто может запомнить только если понял до мелочей и те, кто может выучить как стишок. Первые могут рассказать куда меньше, чем вторые, но при этом с практической точки зрения первые безмерно полезнее, чем вторые. Вы все еще думаете, что вам нужен максимум? ;)
По поводу логических задачек. Они славятся тем, что нужно «догадаться». Если ты не догадался, то однозначно не решил. К тому-же такие задачки как с носками и монетками вообще неоднозначны. Скажем решил человек задачку положив половину монеток в каждый из носков, а потом запихнул носок в носок. Решил? Да. Но если мы говорим о программисте, то лучше будет если он ее не решит. Потому, что на практике массив и массив с вложенным массивом не одно и то же. Вот и думай теперь хорошо, что он решил или нет.
Хотите задачку? Дайте математическую. Для примера. Найти наименьшее натуральное число сумма цифр которого равна 40. Вроде бы ничего сложного. Правда? Но при этом вы проверите как хорошо соискатель знает основы математики, исчисления, как хорошо ориентируется за что отвечает каждый разряд. Начнет-ли он хаотично метаться или пойдет равномерно. Будет использовать прямой перебор или будет, к примеру, использовать максимальное число в каждой разрядности. Решил? Молодец! А 42? И тут могут быть несколько сценариев от мгновенного ответа до повторения части вычислений. Хотите устроить стресс-тест? Не вопрос. Предложите решить эту же задачу с помощью программы. На любом другом языке. Сейчас мало кто требует только один язык. Наверняка в резюме будет Python, а может быть что-то из модного типа Lisp или Haskell. Предложите ему ноут с Linux. Логинитесь в консоль и отдаете. Безусловно нужного языка быть не должно. Мало того, что вы мгновенно узнаете правду ли он написал по поводу администрирования, так еще и узнаете как он себя поведет в экстренной ситуации. Даже если соискатель действительно не первый раз видит Linux он как минимум должен попросить пароль. И даже если первый- не беда. Пусть признается, что нужна помощь и ее стоит оказать и посмотреть как себя поведет дальше и как он решит задачу. Как минимум можно использовать традиционный путь или функциональный подход. Не знаю как вам, а лично мне так нравится куда больше. Во всяком случае намертво заклинить не должно. А потерять перспективного кандидата только потому, что он не умеет монетки по носкам раскладывать — глупо.
По поводу логических задачек. Они славятся тем, что нужно «догадаться». Если ты не догадался, то однозначно не решил. К тому-же такие задачки как с носками и монетками вообще неоднозначны. Скажем решил человек задачку положив половину монеток в каждый из носков, а потом запихнул носок в носок. Решил? Да. Но если мы говорим о программисте, то лучше будет если он ее не решит. Потому, что на практике массив и массив с вложенным массивом не одно и то же. Вот и думай теперь хорошо, что он решил или нет.
Хотите задачку? Дайте математическую. Для примера. Найти наименьшее натуральное число сумма цифр которого равна 40. Вроде бы ничего сложного. Правда? Но при этом вы проверите как хорошо соискатель знает основы математики, исчисления, как хорошо ориентируется за что отвечает каждый разряд. Начнет-ли он хаотично метаться или пойдет равномерно. Будет использовать прямой перебор или будет, к примеру, использовать максимальное число в каждой разрядности. Решил? Молодец! А 42? И тут могут быть несколько сценариев от мгновенного ответа до повторения части вычислений. Хотите устроить стресс-тест? Не вопрос. Предложите решить эту же задачу с помощью программы. На любом другом языке. Сейчас мало кто требует только один язык. Наверняка в резюме будет Python, а может быть что-то из модного типа Lisp или Haskell. Предложите ему ноут с Linux. Логинитесь в консоль и отдаете. Безусловно нужного языка быть не должно. Мало того, что вы мгновенно узнаете правду ли он написал по поводу администрирования, так еще и узнаете как он себя поведет в экстренной ситуации. Даже если соискатель действительно не первый раз видит Linux он как минимум должен попросить пароль. И даже если первый- не беда. Пусть признается, что нужна помощь и ее стоит оказать и посмотреть как себя поведет дальше и как он решит задачу. Как минимум можно использовать традиционный путь или функциональный подход. Не знаю как вам, а лично мне так нравится куда больше. Во всяком случае намертво заклинить не должно. А потерять перспективного кандидата только потому, что он не умеет монетки по носкам раскладывать — глупо.
Найти наименьшее натуральное число сумма цифр которого равна 40
Так как система счисления не указана, ответ 4041. ("40" это одна цифра)
Если приведет запись суммы цифр числа 40 в 41-ричной системе так что бы в результате получилось 40 — великолепно. А если потом еще и программу напишет, то вообще великолепно ;)
Кстати, если не подойдёт 41-ричная, всегда есть палочная. В ней сумма цифр натурального числа всегда равна самому числу. ;)
Я ж не против того, что бы от собеседования или теста получали удовольствие все. У меня как-то был случай когда меня отправили по работе на курсы Linux. А так как уровень был продвинутый, то прислали анкету что бы убедится, что не совсем нулевые приедут. А вопросы как всегда какая команда используется для просмотра файлов в директории? И три варианта на выбор. И так мне скучно стало, что я решил, что отнесусь к заданию серьезно. И на каждый вопрос я отвечал, что все команды подходят с примером использования. И так на все вопросы. С курсов позвонили на работу и сказали, что я могу на курсы не ехать и сертификат мне дадут просто так. И что это была самая ржачная анкета за все время проведения всех курсов.
А что не так с 41-ричной? знак для числа означающего 40 придумать? ну пусть будет
Где такие джуниоры ходят? Когда собеседовал людей для интегратора средней руки, мне в основном попадались кандидаты, которые не могли рассказать, что такое односвязный список, притом от слова «совсем».
Возможно потому, что знание теории computer science и типов данных (вроде всяких односвязных-двусвязных списков, двоичных деревьев итд) не имеет отношения к прикладному программированию, только если вы не разрабатываете свой ЯП или свою базу данных.
И человек может это знать, только если у него в университете был CS101 (чего в российских реалиях ожидать глупо), либо если он готовился к собеседованиям по книгам.
А вот что такое Boxing/Unboxing при разработке на C# знать надо, но джуниорам не знать это простительно.
Разве структуры данных и алгоритмы не являются типовым предметом на Ит-факультетах? У меня был такой предмет, хотя назвать свой ВУЗ хоть как-то выдающимся я явно не могу.
Ну вы со списками и деревьями тут перегнули конечно. Это основы, без понимания которых, даже к написанию к первому «hello world» приступать нельзя. Я тут тоже перегнул, но это так, для баланса
Для баланса нужно было перегибать куда меньше, чем сделали вы. Когда вы в последний раз в боевом проекте реализовывали хоть что-то из основных алгоритмов? Уверен, что в подавляющем большинстве проектов прожект если увидит такой код просто скажет заменить вызовом из библиотеки и попросит больше так никогда не делать. И ведь будет более чем прав. Во-первых вы можете налажать. От этого вообще никто не застрахован. А во вторых вы потратили время на то, что уже сделано и отлично работает. Я уже не говорю про то, что сопровождать ваш код будет сложнее.
Я не считаю, что не нужно знать основных алгоритмов. Хотя-бы иметь о них представление — очень хорошо. Но что бы прям жить без них было нельзя- большое преувеличение.
Я не считаю, что не нужно знать основных алгоритмов. Хотя-бы иметь о них представление — очень хорошо. Но что бы прям жить без них было нельзя- большое преувеличение.
А никто и не говорит, что нужно каждый день релизовывать односвязные списки. Их нужно знать и понимать, чтобы сделать правильный «вызов из библиотеки». Нужно понимать, когда использовать массив, когда словарь, а когда списки. Понимать в каких частях системы это критично, а в каких нет. Вот зачем всё это надо хорошему программисту, которым хочет стать джуниор.
Если джун не знает списков, это, конечно, не приговор, но как минимум это заставляет задуматься, а чем же он занимался в техникуме/колледже/институте и даёт повод задать дополнительные вопросы.
Если джун не знает списков, это, конечно, не приговор, но как минимум это заставляет задуматься, а чем же он занимался в техникуме/колледже/институте и даёт повод задать дополнительные вопросы.
Допустим я не знаю как устроен связанный список. Я только знаю его «свойства». Скажем просто узнал что на каком случае лучше работает. Не могли бы вы привести пример как я мог бы его «неправильно» вызвать? Где там вообще можно ошибиться?
Допустим я не знаю как устроен связанный список. Я только знаю его «свойства».
За свою многолетнюю практику такого не встречал. Ещё сложнее представить джуниора, которые узнал свойства, умеет их анализировать и применять, но не знает откуда они взялись. Тем нем менее, знаете свойства — хорошо, значит уже что-то значете об списках и, возможно, сможете правильно их использовать по назначению.
Я никак не могу взять в толк, толи у меня ВУЗ действительно такой офигенный, толи болшая часть хабровчан учили программирование в пирожковых техникумах (Я как-то был на олимпиаде ссузов и ИТшных техникумов там было представлено 3, ещё пяток технических, остальные какие угодно).
Связанные списки мы проходили на первом курсе колледжа. Это обязательная программа на специальность программиста. В госстандарте это первый год обучения специальности, неважно среднетехническое это образование или высшее. Если их в программе нет, то и госдиплом вряд ли в таком учебном заведении можно получить. Разве что «оператор ЭВМ».
Связанные списки мы проходили на первом курсе колледжа. Это обязательная программа на специальность программиста. В госстандарте это первый год обучения специальности, неважно среднетехническое это образование или высшее. Если их в программе нет, то и госдиплом вряд ли в таком учебном заведении можно получить. Разве что «оператор ЭВМ».
Жесть, в моем ССУЗе такого и близко не было. Правда и ССУЗ не в РФ. Еще раз убеждаюсь, что даже средне-специальное образование в РФ лучше, чем в Казахстане.
Такое не в каждом российском ВУЗе есть.
Давайте так, в каком вузе и на какой специальности этого нет?
вот ФГОС по фундаментальной информатике например, см. учебный цикл «Б.3». это обязательная часть, без нее невозможно получить диплом.
Ну так и интегратор средней руки это не работа мечты для крутого студента.
Вы точно проходили собеседование на .NET Junior?
Когда меня заставляли собеседовать народ, то на джуниора я обычно спрашивал в какие игры играет, какой сорт виски предпочитает, ну можно было спросить опционально про какие-нибудь общие понятие ООП, чтоб совсем несерьезно не выглядеть.
А вот решение тестовых задачи и/или ссылки на свой какой-нибудь код — по-моему единственная эффективная по которой можно хоть как-то оценить человека.
Угу и задают вопросы:
Внезапно это как раз олимпиадная задачка…
Чойт меня не покидает ощущение, что люди совсем не знают кого хотят набрать, может я постарел и засиделся?
Когда меня заставляли собеседовать народ, то на джуниора я обычно спрашивал в какие игры играет, какой сорт виски предпочитает, ну можно было спросить опционально про какие-нибудь общие понятие ООП, чтоб совсем несерьезно не выглядеть.
А вот решение тестовых задачи и/или ссылки на свой какой-нибудь код — по-моему единственная эффективная по которой можно хоть как-то оценить человека.
Так же хочется отметить тот факт, что в своем резюме я указал, что занимаюсь олимпиадным программированием и это очень положительно повлияло на ход многих собеседований. Меня просили рассказать, что это такое. Меня удивило, что большинство интервьюверов не знали про такое движение в программировании.
Угу и задают вопросы:
Вы находитесь в пустом поезде...
Внезапно это как раз олимпиадная задачка…
Чойт меня не покидает ощущение, что люди совсем не знают кого хотят набрать, может я постарел и засиделся?
Подскажите, а как с поездом правильно решать? Пока одна идея метаться туда обратно. В первом вагоне включаем свет и идем до след освещенного вагона, выключаем там свет и идем обратно в первый вагон, если горит, повторяем
Ну да: придется ходить туда-сюда зажигая/отключая свет, увеличивая дальность.
Но это вообще олимпиадная задачка: олимпиадники обычно знают решение, прочие — как повезет, но сходу догадается не каждый, тем более за ограниченное время собеседования, можно еще и яркой лампой в лицо в упор светить и проводить собеседование в комнате без окон для создания более дружелюбной атмосферы…
Но с другой стороны эта задачка не из воздуха — есть такая штука как «кольцевой(циклический) список» — вот и ходи по нему бесконечно, т.к. хрен его знает где начало, а где конец :-)
С монетками — делим по полам, и один носок вставляем в другой…
Но это вообще олимпиадная задачка: олимпиадники обычно знают решение, прочие — как повезет, но сходу догадается не каждый, тем более за ограниченное время собеседования, можно еще и яркой лампой в лицо в упор светить и проводить собеседование в комнате без окон для создания более дружелюбной атмосферы…
Но с другой стороны эта задачка не из воздуха — есть такая штука как «кольцевой(циклический) список» — вот и ходи по нему бесконечно, т.к. хрен его знает где начало, а где конец :-)
С монетками — делим по полам, и один носок вставляем в другой…
Присваиваем n=0. Включаем свет, идем вперед на 2^n шагов, выключаем везде свет по пути, идем 2^n шагов назад, если свет в вагоне выключен, значит 2^n больше или равен числу вагонов (и значит, что больше нет вагонов со светом), включаем, считаем, пока не упремся в вагон со светом, возвращаем посчитанное, иначе увеличиваем n и goto 2. Решение честно вычитано где-то в параллельном потоке трепа.
тоже задумался… пока родил такое:
нужно создать упорядоченную последовательность «включенных» и «выключенных» вагонов при этом откатываться назад и проверять не достигли ли мы конца стека вагонов. И желательно поменьше бегать.
1) включаем свет в первом. ****1****
2) двигаем направо выключая свет в двух справа. Затем заходим в следующий и включаем там.*****100*****
3) возвращаемся по изученным вагонам следим чтоб не произошло изменений 2 темных 1 светлый ***000100***
4) идем налево и оставляем 3 вагона темными и в следующем за ним включаем свет *111110001001111**
5) в итоге мы с каждой итерацией увеличиваем последовательность упорядоченных светлых или темных вагонов и при этом проверяем на ошибки прежние «записи» и при обнаружении ошибки понимаем что кольцо замкнулось. Там уже проще вычислить через сумму чисел до числа равного количеству итераций до ошибки плюс число вагонов в «участке с ошибкой».
нужно создать упорядоченную последовательность «включенных» и «выключенных» вагонов при этом откатываться назад и проверять не достигли ли мы конца стека вагонов. И желательно поменьше бегать.
1) включаем свет в первом. ****1****
2) двигаем направо выключая свет в двух справа. Затем заходим в следующий и включаем там.*****100*****
3) возвращаемся по изученным вагонам следим чтоб не произошло изменений 2 темных 1 светлый ***000100***
4) идем налево и оставляем 3 вагона темными и в следующем за ним включаем свет *111110001001111**
5) в итоге мы с каждой итерацией увеличиваем последовательность упорядоченных светлых или темных вагонов и при этом проверяем на ошибки прежние «записи» и при обнаружении ошибки понимаем что кольцо замкнулось. Там уже проще вычислить через сумму чисел до числа равного количеству итераций до ошибки плюс число вагонов в «участке с ошибкой».
С поездом же совсем просто, проходишь по кругу, всё включаешь потом выключаешь и считаешь. Или я чего-то не понимаю? Единственная видимая засада — надо знать, что вагоны ограничены определённым количеством, теоретически их же м.б. миллиард/триллион, без ограничения сверху задача не имеет решения.
Ну это естественно)
А как определить, что ты уже все включил? Вот идешь ты по вагонам, включаешь свет. А потом 500 вагонов подряд свет включен. И какой вывод из этого делать? Во всех вагонах свет включен? Или же в 501 выключен? Пройти еще 500? А если и там включен, а в 1001 выключен? Когда остановиться и начать выключать?
А это задачка на знание алгоритмов или на хитрость? Например, приходит в голову такой вариант — включаем свет в своем вагоне, ждем, например, полчаса, потом выключаем свет и быстро идем считать вагоны, трогая лампочки. Вагон, в котором выключенная лампочка будет теплой — тот вагон, откуда мы вышли. И всего прошли круг один раз.
Вот без интернирования строк джун ну никак не проживет. Живо себе представляю, как младший разработчик начинает заниматься оптимизацией memory traffic и первым делом приступает к написанию unsafe-кода. Тут ему как раз и помогают эти знания.
Будто только для написания unsafe-кода нужно это знание. Это отличный вопрос для входа в тему работы строк в c#. Все же есть много новичков пишущих s1+s2+s3+s4+s5 в цикле. Есть и много людей требующих любую конкатенацию из двух строк заменять стрингбилдером или string.Format.
Все же есть много новичков пишущих s1+s2+s3+s4+s5 в цикле. Есть и много людей требующих любую конкатенацию из двух строк заменять стрингбилдером или string.Format.Без сомнения. Я имел в виду, что лучше задать вопрос «строки — это ref или value type». Чаще всего говорят ref. Потом спрашиваешь, «а почему же они не изменяемые»? И кто такой StringBuilder? Если уже в этом контексте кандидат упомянет интернирование — честь ему и хвала, но на практике моих собеседований такого не происходило :) Может не те джниоры приходят? А «те» только в Москве?
Мне одному показалось, что автор кокетничает, говоря о своем удивлении, что его взяли в 80% случаев и о своей низкой самооценке? Мне показалось что он наоборот несколько самоуверен.
Пройдя 5 собеседований, я выяснил такую вещь: чем позитивнее и свободнее ведешь себя на собеседовании, тем легче и быстрее онао проходит.
— Привет, чувак. Ты что-ли тут самый крутой техдиректор-всех-эректор?
— Спасибо. До свидания.
14 секунд. Весело. Быстро. Рекорд.
PS. А по фразе действительно так. Ищут/ищем же людей, которые не будут меньжеваться на работе. А если товарищ уже на собеседовании зажат и вопроса про промис стремается… Нужен такой, даже если потея ответит правильно? )
Хорошо, что я не стал шарпистом. Си шарп джуниоры на собседованиях поднимают системы на паттернах проектирования, пишут нереальные зубодробительные ассинхронные методы и покрывают код юнит тестами, а после этого сидят над суровыми задачами на матан и логику.
Реально, хреново видимо джниорам, кто шарп выбрал. Если там такие джуниоры, то миддлы там наверно вообще какие-то полумифические нереальные типы, чьё прикосновение может исцелять безнадёжных больных.
Реально, хреново видимо джниорам, кто шарп выбрал. Если там такие джуниоры, то миддлы там наверно вообще какие-то полумифические нереальные типы, чьё прикосновение может исцелять безнадёжных больных.
Вполне себе адекватный список вопросов на джуна на самом деле, если отбросить логические задачи. Во-первых какая-никакая но гарантия что вы будете разговаривать на одном языке во время работы, во-вторых ну а что еще спрашивать у него? К тому же вряд ли автора успевали опросить об этом всем за одно собеседование это компиляция вопросов с 5 разных компаний.
благодарю за интересный материал!
Количество задач — сильно много, на позицию junior — однозначно overhead. Как правило дают 1-3 задачи, иногда, как Вы заметили, задачи дают из трекера компании. Честно говоря, мало тут профильных задач на .Net, скорее они все применимы практически к эдакому универсальному пулу программистов языка/платформы X.
Уважаемый, не прибедняйтесь. Самооценка у Вас в порядке, если Вы написали статью, уж поверьте
Вопросы про SOLID — это точно не джуниоровский уровень. Конечно, их можно просто зазубрить, но толку от этого…
А с поездом решение может кто-то точно сказать? Я вижу так: проходим по всем вагонам, отключаем везде свет, дальше включаем в одном и идем по кругу до него, включая свет в остальных. Получается круг пройти 2 раза.
Решение было выше в комментариях, а в вашем случае, как вы определите, что уже во всех отключили? Ведь количество вагонов не известно, может там просто много подряд отключенных уже до ваших манипуляций было…
Ссылка на комментарий
Ссылка на комментарий
Бывает, что работодатель спрашивает — есть ли к нему какие-нибудь вопросы. У вас такое было? Поделитесь тем о чём спрашивали?
Хм… интересно, есть топ вопросов работодателю на собеседовании? )
Да, и действительно, а почему бы не проверить уровень работодателя встречными задачами? )) А то может придётся работать на тугодума)
Хм… интересно, есть топ вопросов работодателю на собеседовании? )
Да, и действительно, а почему бы не проверить уровень работодателя встречными задачами? )) А то может придётся работать на тугодума)
Мне скоро тоже предстоят собеседования на позицию junior .net developer. Прочитал статью, и выпал в осадок, осознав, что ещё не готов, особенно касаемо паттернов и sql. Потом почитал комменты и как то отлягло)))
SQL точно обязательно, паттерны еще можно не знать.
на позицию ASP.NET разраба, ну или .NET Core бекендера. Давайте не уподобляться плохим HR и уточнять область работы.
Вы правы, asp.net developer. Просто мыслью комментария было не это.
Вы так говорите, будто базы данных — привилегия веб-проектов. Давайте не будем уподобляться ситхам.
ЗЫ Звучит, будто желание узнать область работы — это признак плохого HR'а (=
ЗЫ Звучит, будто желание узнать область работы — это признак плохого HR'а (=
Объективно, в современных реалиях проектов, которые работают на клиенте с локальной бд так, чтоб джойны приходилось писать (особенно на регулярной основе) можно по пальцам пересчитать.
Чаще же всего, что на десктопах, что на мобилках в базу просто кешируется ответ от сервера.
ЗЫ. либо вы там лишнюю частицу «не» увидели, либо я не знаю. «не уподобляться» и «уточнять» — однородные сказуемые.
«Давайте не уподобляться и уточнять» == «Давайте уточнять, а не уподобляться»
Чаще же всего, что на десктопах, что на мобилках в базу просто кешируется ответ от сервера.
ЗЫ. либо вы там лишнюю частицу «не» увидели, либо я не знаю. «не уподобляться» и «уточнять» — однородные сказуемые.
«Давайте не уподобляться и уточнять» == «Давайте уточнять, а не уподобляться»
Бывает, конечно, всякое, но типичное десктопное приложение на .NET будет работать в энтерпрайзном окружении с выделеным БД-сервером и часть бизнес-логики на хранимках и жирные джойны на больших объемах данных — это то, с чем реально можно столкнуться.
И конечно же в этом ынтырпрайзном окружении клиент напрямую с базой на сервере работает?
Вы так говорите, будто это что-то плохое) Суть дела не изменится, даже если нагородить прослоек.
Слыхал, что в некоторых компаниях бывают специальные БД-разработчики, абстрагирующие всю работу с DAL через хранимки, но на практике такого не встречал.
Слыхал, что в некоторых компаниях бывают специальные БД-разработчики, абстрагирующие всю работу с DAL через хранимки, но на практике такого не встречал.
Я слыхал, в других компаниях бекенд пишут, а клиент с API работает. Иногда даже с Rest.
Суть дела не изменится, даже если нагородить прослоек.
Действительно. Клиенту как не надо было знать SQL так и не надо. О чем я и писал.
Я же вам уже оппонировал примером, что полно проектов, где пишут разного плана морды на C# в фулл-стек и SQL — маст ноу (= Сказать, что SQL совсем не нужен джуниору — это сильно сузить круг возможных вакансий для него.
Вот еще раз, нахрена «жирные джойны» на клиентах? Все жирные джойны должны быть на серверной стороне. Не важно, на хранимках это будет делаться, на вьюхах, или будет полноценный клиент с Rest-api.
Гнать SQL по сети, а уж тем более делать «жирный джойн» на клиенте идея очень плохая.
Вот и остается, что SQL нужен бекендерам и ASP.Net-чикам.
Гнать SQL по сети, а уж тем более делать «жирный джойн» на клиенте идея очень плохая.
Вот и остается, что SQL нужен бекендерам и ASP.Net-чикам.
Прежде всего, этот холивар на тему идеальной архитектуры не имеет отношения к объективной реальности — джуниор не будет ее строить) Проекты есть и SQL там требуют.
Вот и я думаю, откуда вы взяли это?) Джойны на сервере, в хранимках. А хранимки должен кто-то писать. Этот «кто-то» должен получать зарплату. Почему бы не писать их самому разработчику, что клиент пишет?) И дешевле выйдет, и лишнее звено коммуникации уйдет.
Почему не фигачить дополнительный REST-сервис? А зачем это делать, если для своих внутренних нужд можно обойтись шаренной сборкой?) Больше кода — больше багов, больше систем — больше интеграции, больше API-тестов и прочих сложностей с поддержкой. Не нужно множить сущности и втыкать веб-стек там, где в нем нет нужды.
Вот еще раз, нахрена «жирные джойны» на клиентах?
Вот и я думаю, откуда вы взяли это?) Джойны на сервере, в хранимках. А хранимки должен кто-то писать. Этот «кто-то» должен получать зарплату. Почему бы не писать их самому разработчику, что клиент пишет?) И дешевле выйдет, и лишнее звено коммуникации уйдет.
Почему не фигачить дополнительный REST-сервис? А зачем это делать, если для своих внутренних нужд можно обойтись шаренной сборкой?) Больше кода — больше багов, больше систем — больше интеграции, больше API-тестов и прочих сложностей с поддержкой. Не нужно множить сущности и втыкать веб-стек там, где в нем нет нужды.
Ну пробелов по sql не так много, можно покрыть, с паттернами наверное поможет только практика
Какое решение у задачи про поезд? Из того что написано в комментах я не увидел критерия остановки работающего для любой длины состава.
Решение в лоб:
Включаем в исходном вагоне свет. Идем в одну из сторон до тех пор, пока не встретим вагон со светом, попутно считая количество пройденных вагонов. Примем число пройденных вагонов за c. Выключаем в этом вагоне свет. Возвращаемся в обратную сторону на c шагов, чтобы оказаться в изначальном вагоне. Если свет в вагоне выключен, то число вагонов в поезде c, алгоритм завершен. Если свет в вагоне включен, то опять идем в произвольную сторону до первого вагона с включенным светом, считая вагоны.
Частный случай — 1 вагон. Включаем свет. Выходим из вагона в соседний и оказываемся в изначальном вагоне. c = 1. Выключаем свет. Возвращаемся на 1 вагон назад. Оказывамся в вагоне с выключенным светом => кол-во вагонов равно 1.
Асимптотическая сложность алгоритма:
O(n²) — везде свет включен;
Ω(n) — свет включен только в изначальном вагоне.
Для улучшения вычислительной сложности (не асимптотической) можно использовать не один вагон с включенным светом, а паттерн, например, из трех вагонов (включен, выключен. включен) и при нахождении такого же паттерна возвращаться назад на c вагонов и проверять.
Включаем в исходном вагоне свет. Идем в одну из сторон до тех пор, пока не встретим вагон со светом, попутно считая количество пройденных вагонов. Примем число пройденных вагонов за c. Выключаем в этом вагоне свет. Возвращаемся в обратную сторону на c шагов, чтобы оказаться в изначальном вагоне. Если свет в вагоне выключен, то число вагонов в поезде c, алгоритм завершен. Если свет в вагоне включен, то опять идем в произвольную сторону до первого вагона с включенным светом, считая вагоны.
Частный случай — 1 вагон. Включаем свет. Выходим из вагона в соседний и оказываемся в изначальном вагоне. c = 1. Выключаем свет. Возвращаемся на 1 вагон назад. Оказывамся в вагоне с выключенным светом => кол-во вагонов равно 1.
Асимптотическая сложность алгоритма:
O(n²) — везде свет включен;
Ω(n) — свет включен только в изначальном вагоне.
Для улучшения вычислительной сложности (не асимптотической) можно использовать не один вагон с включенным светом, а паттерн, например, из трех вагонов (включен, выключен. включен) и при нахождении такого же паттерна возвращаться назад на c вагонов и проверять.
Спасибо. Я на этапе определения цикличности застрял, надо было еще подумать прежде чем сдаваться.
В треде есть и более оптимальное решение с верхним пределом асимптотической сложности O(n*lg(n)) habrahabr.ru/post/338102/#comment_10421568
Там даже O(n).
Не могу согласиться.
Возьмем n = 2²⁰, тогда в худшем (и лучшем тоже) случае надо будет пройти (1+2+4+8...+2²⁰)*2 вагонов, чтобы убедиться, что мы выключили свет везде. Умножение на 2 — это проход туда и обратно. После чего надо сделать один полный проход с подсчетом. Количество слагаемых в скобках — lg(n). Каждое из слагаемых можно грубо принять за n (асимпотика же ¯\_(ツ)_/¯). Т.е. мы 2*lg(n) раз прошли n вагонов, чтобы убедиться в том, что обошли весь поезд + 1 раз прошли n вагонов для подсчета. Получается O(n*(1+2*lg(n))) или O(n*lg(n)).
Справедливости ради нижний асимптотический предел сложности такой же как и верхний с точностью до константы Ω(n*lg(n)) ⇒ Θ(n*lg(n)). А это может значить, что на больших и очень разреженных составах (почти везде свет выключен) алгоритм «в лоб» может работать лучше.
Возьмем n = 2²⁰, тогда в худшем (и лучшем тоже) случае надо будет пройти (1+2+4+8...+2²⁰)*2 вагонов, чтобы убедиться, что мы выключили свет везде. Умножение на 2 — это проход туда и обратно. После чего надо сделать один полный проход с подсчетом. Количество слагаемых в скобках — lg(n). Каждое из слагаемых можно грубо принять за n (асимпотика же ¯\_(ツ)_/¯). Т.е. мы 2*lg(n) раз прошли n вагонов, чтобы убедиться в том, что обошли весь поезд + 1 раз прошли n вагонов для подсчета. Получается O(n*(1+2*lg(n))) или O(n*lg(n)).
Справедливости ради нижний асимптотический предел сложности такой же как и верхний с точностью до константы Ω(n*lg(n)) ⇒ Θ(n*lg(n)). А это может значить, что на больших и очень разреженных составах (почти везде свет выключен) алгоритм «в лоб» может работать лучше.
Критерий такой: свет в вагоне с индексом x-n переключается при переключении света в вагоне с индексом x+n, где x — индекс текущего вагона, а n — предположительная длина состава.
Для меня было неожиданностью, что меня пригласили работать практически все компании (80%), в которых я проходил собеседование.
То есть из-за некомпетентности собеседующих большинство компаний остались с… носом!
Спрашивается - что не так так эти компании делали, что упустили нужного им программиста?
Очень интересно, спасибо большое за данный материал
А я вот все никак не соберусь на собеседование на Junior .Net Developer, в голове куча теории, а практики мало (пишу всякую мелочь для себя).
По вопросам прошелся, вроде ничего страшно нету. Более-менее понимаю (а что нет немного подтяну), только с sql пока не стыкался совсем.
Для себя (в Киеве), хотелось бы найти что-то что где можно применить знания со своей основной на данный час специальности (сертификованый инженер-землеустроитель, CAD/GIS, геодезия).
По вопросам прошелся, вроде ничего страшно нету. Более-менее понимаю (а что нет немного подтяну), только с sql пока не стыкался совсем.
Для себя (в Киеве), хотелось бы найти что-то что где можно применить знания со своей основной на данный час специальности (сертификованый инженер-землеустроитель, CAD/GIS, геодезия).
Всем привет. Создал курс по Основам программирования с видео лекциями. Советую всем пройти. Буду благодарен за отзыв. stepik.org/course/5482/syllabus
Sign up to leave a comment.
Как я проходил собеседования на позицию Junior .Net Developer