Comments 58
рейтинг = 100 * log(x) * y / x
1) По какому основанию логарифм?
2) А если рейтинг отрицательный, то всё очень плохо?
Если я ни разу не был на собеседовании, то при делении на 0 получим inf, логарифм от 0 тоже в принципе в принципе даст -inf. Бесконечно отрицательный рейтинг. Надежды нет)
Да, подтверждаю, формула не идеальна. Даже в случае если человек уже работает (x == 1), но предложений от компаний не получал (сам нашел работу и устроился (y == 0)) — получается 0 / 1. Но вроде же и так понятно, что она написана «от балды».
Жаль нет идеальной формулы для приема на работу. Хотя может и наоборот — хорошо :)
Жаль нет идеальной формулы для приема на работу. Хотя может и наоборот — хорошо :)
но предложений от компаний не получал (сам нашел работу и устроился )
Т.е. вы нашли компанию, компания не сделала вам предложение, но вы в ней работаете? Магия…
Я думаю, в посте имелось ввиду предложения от компаний, которые сами нашли тебя и предложили работу (возможно даже без собеседования).
А мне показалось что это соотношение прошел/не прошел собеседование…
UPD точне взяли/взяли на работу, если вдруг собеседования не было
UPD точне взяли/взяли на работу, если вдруг собеседования не было
Хм. Теперь я запутался.
Давайте ещё раз:
x — количество собеседований, x >= y. При приёме на работу всегда есть хотя бы одно, хотя бы формальное собеседование (даже если работодатель очень хочет этого работника),
y — количество job offer-ов. Т.е. предложениий о работе. Трудоустройство == принятие job-оффера работником.
Так понятней?
x — количество собеседований, x >= y. При приёме на работу всегда есть хотя бы одно, хотя бы формальное собеседование (даже если работодатель очень хочет этого работника),
y — количество job offer-ов. Т.е. предложениий о работе. Трудоустройство == принятие job-оффера работником.
Так понятней?
Есть:
if(Вы_подходите && Хватает_денег)
{
Вы_приняты!
}
if(Вы_подходите && Хватает_денег)
{
Вы_приняты!
}
1) По какому основанию логарифм?Ну это видно, что перевод. log «по-ихнему» — это lg по-нашему.
Зависит от области. В математике, например, log обычно обозначает натуральный логарифм, т.е. ln. А вообще, утверждается такое:
x = log y often means x = loge y in mathematics texts.
x = log y often means x = log10 y in science and engineering texts.
x = log y often means x = log2 y in computer science texts.
Я на втором собеседовании устроился, так что у меня все зависит от основания логарифма.
Тоже первым делом обратил на это внимание. Либо натуральный, либо десятичный (скорее натуральный). Но уточнить стоило бы. Жаль статья переводная, у автора уже не спросишь.
Перевод хороший.
Тоже первым делом обратил на это внимание. Либо натуральный, либо десятичный (скорее натуральный). Но уточнить стоило бы. Жаль статья переводная, у автора уже не спросишь.
Перевод хороший.
Почему же не спросишь?
Нет ничего невозможного.
Если у кого-то есть реальный интерес в этом — я постараюсь связаться с автором и выяснить это.
Нет ничего невозможного.
Если у кого-то есть реальный интерес в этом — я постараюсь связаться с автором и выяснить это.
Было бы неплохо. Потому что основание логарифма меняет формулу в разы, получается либо у всех будет
Написал автору. Если ответит — обязательно отпишусь.
Там в комментарии к формуле на этот вопрос ответил автор. Десятичное основание)
Всё верно. Натуральный логарифм принято обозначать ln, а log без указания основания — десятичный.
Десятичный — lg
У нас — да. На Западе — log.
На каком западе? Кто вам это сказал?
Это зависит. См. комментарий выше.
а log без указания основания — десятичный
Всю жизнь считал, что десятичный алгоритм — это lg
Натуральный логарифм тоже порою обозначают как log(x)
пруф даже в википедии:
Натуральный логарифм обычно обозначают как ln(x), loge(x) или иногда просто log(x), если основание e подразумевается.
Там десятичное основание.
И что это, получается при моих показателях «4 собеседования, 5 предложений работы» — я получаюсь лох полный с рейтингом 75? А должно быть как — 1 собеседование и 10 предложений?
В идеале каждая компания, где проходили собеседования, если будет предлагать работу, то рейтинг выше 100 будет только при 10+ собеседованиях. Но такое маловероятно.
Если мыслить логически: человек идёт на собеседование в компанию, в которой хочет работать. И если они предлагают ему работу, то он скорей всего согласится. Так что, большое количество собеседований при большом количестве предложений маловероятно. Мы, конечно же, отбросим тех, кто по фану ходит на собеседование и остальные случаи, а будем говорить в целом.
Скажем, что каждое второе собеседование заканчивается предложением о работе, тогда чтобы рейтинг был >100, нам необходимо сходить на >100 собеседований. Фантастичные цифры )
Если мыслить логически: человек идёт на собеседование в компанию, в которой хочет работать. И если они предлагают ему работу, то он скорей всего согласится. Так что, большое количество собеседований при большом количестве предложений маловероятно. Мы, конечно же, отбросим тех, кто по фану ходит на собеседование и остальные случаи, а будем говорить в целом.
Скажем, что каждое второе собеседование заканчивается предложением о работе, тогда чтобы рейтинг был >100, нам необходимо сходить на >100 собеседований. Фантастичные цифры )
Уровень опытности инженера обратно пропорционален его зависимости от внешних оценок и формул :)
Искать работу, на самом деле, интересно. Думаю многим знакомо несколько гнетущее чувство когда по какой то причине остаёшься без работы. Но когда начинаешь искать и тебе уже на первых собеседованиях говорят что берут, причем сразу в нескольких местах, надо признать (чего уж там греха таить), что тебе нравится и хочется испытать это чувство ещё раз. Но надо останавливаться и начинать работать, доказывая что в тебе не ошиблись. Безусловно, базовые знания важны но важно и иметь возможность показать что ты до сих пор делал и как. Причем, именно то что я уже сделал, снимало все вопросы и меня готовы были сразу брать. За всю историю меня никто никогда не пытал вопросами на знание алгоритмов или сообразительность. Возможно это немецкая специфика, но было именно так. Если у человека есть базовое образование и опыт то что то освежить не составит труда, в Германии это понимают. Не раз уже писал что надух не понимаю всех этих тестов и вопросов с подковырками. Зачем? Открой код написанный человеком и поговори о том что там написано, довольно быстро все станет понятно. Поговори о семье увлечениях, это гораздо важнее, т.к. позволит оценить уживчивость человека в коллективе. Опять же, если у человека есть хоть какой то опыт в конкретном языке (на котором предстоит писать) то гораздо большее значение имеет знание предметной области где предстоит кодировать, Согласитесь, глупо мучать вопросами из области распознавания образов человека которому предстоит программировать бухгалтерию. Мне кажется это болезнь, присущая некоторым крупным компаниям, не является какой то общей тенденцией в отрасли и говорит скорее о несовершенстве системы набора персонала в таких компаниях. Небольшие или средние фирмы могут себе позволить более предметный разговор с соискателем нежели прогон его по тестам и каверзным вопросам зачастую предвзято настроенными сотрудниками (дескать меня мучали я тебя тоже помучаю).
п.с. извиняюсь что тут немного поякал, просто нужно было как то веско обосновать сказанное, а что может быть более веским нежели личный опыт.
п.с. извиняюсь что тут немного поякал, просто нужно было как то веско обосновать сказанное, а что может быть более веским нежели личный опыт.
Алгоритмы еще ладно, вот теорему Коши о вычетах спрашивать при устройстве на позицию Android разработчика это по-моему ненормально. А случай был.
Наблюдал ситуацию когда ребята которые хорошо шарят в алгоритмах на деле больше ничего и не умеют, т.е. даже не могут банально соблюдать code conventions, не говоря уж о какой-то базовой архитектуре и разбиении на модули.
И как мне показалось даже не пытаются все это постигнуть, т.к. считают себя крутыми программерами только потому что они знают стопицот алгоритмов на красночерных деревьях и графах, которые, как ни странно, используются крайне редко…
И как мне показалось даже не пытаются все это постигнуть, т.к. считают себя крутыми программерами только потому что они знают стопицот алгоритмов на красночерных деревьях и графах, которые, как ни странно, используются крайне редко…
Они-то используются каждый день, только слава богу все это скрыто за удобным API stdlib, или любой другой стандартной библиотеки, которая покрывает потребность в алгоритмах на 99%.
Я имел ввиду повседневные задачи, безусловно мы все это используем, но никто ж не пишет для прода свой вектор/список/дерево :)
Никто не пишет, но обязан знать как на самом деле его программа работает… так ведь?
Знаю, что это прозвучит очень неканонично, но я в данную секунду наверное и базовых алгоритмов в точности написать не смогу. Каких-то из них я не знал никогда, какие-то знал, но за ненадобностью и неиспользуемостью они подзабылись.
И за мои почти 10 лет опыта работы разработчиком на С++ я если и страдал от этого незнания, то лишь в начале карьерного пути, когда не обладал иными достоинствами. Такими как знание/умение разбираться в стандартных (и не очень) библиотеках, умение в непонятных ситуациях формулировать и задавать вопросы, а также самостоятельно искать на них ответы, и, главное, ответственный подход к делу и стремление не делать говна. И все мои работодатели, кроме самого первого, были мной довольны и счастливы иметь со мной дело.
В тот единственный раз, когда я сам выступал в роли работодателя, я пытался подобрать исполнителя исходя из его знаний и умений. Подобрал, как мне показалось. И через несколько месяцев мне пришлось разорвать с ним сотрудничество, потому как он имел ужасную привычку тупо класть болт на поставленные задачи, не вчитывался в их формулировки и в конечном счёте делал не то, что от него требовалось, а то, что ему самому приходило в голову. Я долго пытался найти к нему подход, от почти полного делегирования всех деталей реализации на его усмотрение до почти полной формализации задач до каждой мелочи, но всё оказалось без толку.
Так что знание алгоритмов — это не панацея и даже, мне кажется, не самое главное. Наверное, в разных коллективах лучше всего работают разные стратегии подбора кадров, но лично я скорее возьму человека, который не знает вообще ничего, но имеет голову на плечах, способен логически мыслить и умеет слушать других и говорить сам, нежели того, кто всё знает, но при этом при коммуникации с ним ощущение, что говоришь с каким-то инопланетянином.
И за мои почти 10 лет опыта работы разработчиком на С++ я если и страдал от этого незнания, то лишь в начале карьерного пути, когда не обладал иными достоинствами. Такими как знание/умение разбираться в стандартных (и не очень) библиотеках, умение в непонятных ситуациях формулировать и задавать вопросы, а также самостоятельно искать на них ответы, и, главное, ответственный подход к делу и стремление не делать говна. И все мои работодатели, кроме самого первого, были мной довольны и счастливы иметь со мной дело.
В тот единственный раз, когда я сам выступал в роли работодателя, я пытался подобрать исполнителя исходя из его знаний и умений. Подобрал, как мне показалось. И через несколько месяцев мне пришлось разорвать с ним сотрудничество, потому как он имел ужасную привычку тупо класть болт на поставленные задачи, не вчитывался в их формулировки и в конечном счёте делал не то, что от него требовалось, а то, что ему самому приходило в голову. Я долго пытался найти к нему подход, от почти полного делегирования всех деталей реализации на его усмотрение до почти полной формализации задач до каждой мелочи, но всё оказалось без толку.
Так что знание алгоритмов — это не панацея и даже, мне кажется, не самое главное. Наверное, в разных коллективах лучше всего работают разные стратегии подбора кадров, но лично я скорее возьму человека, который не знает вообще ничего, но имеет голову на плечах, способен логически мыслить и умеет слушать других и говорить сам, нежели того, кто всё знает, но при этом при коммуникации с ним ощущение, что говоришь с каким-то инопланетянином.
Ну понятно, что этого знания «про дело» нужно вагон и маленькая тележка. Но я просто к тому, что что-бы правильно проектировать программы из тех компонентов, которые предоставляет ОС и стандартные\не стандартные библиотеки нужно иметь представление как и что компонуется и какие имеет характеристики. Моя точка зрения чисто с такой архитектурной стороны, что если не иметь какого-то базового представления о том какие принципы заложены в них, то можно налажать с там, к примеру, int hashCode() { return 5; } и потом городить кеши, да всякие подпорки. Ну а когда требования к производительности возрастают, то и структуры данных должны быть лучше подобраны, что в результате, например, может означать для программиста, что просто нужно под определенный запрос создать индекс в БД.
я вот, например, знаю что такое индекс, зачем и как влияет. Но понятия не имею как его реализацию написать на доске на собеседовании.
Алгоритмы важны, безусловно. Для определённого круга задач, в первую очередь. Если в твоём проекте идёт стадия тотальной оптимизации и борьбы за вычислительные ресурсы — или если она хотя бы прогнозируется в будущем — то руководителям проекта будет целесообразно подбирать команду с учётом наличия подобных знаний, либо же провести ликбез по этой тематике. С учётом того, что специалисты в целом должны быть подготовленные и сообразительные, подобную акцию можно не растягивать на несколько месяцев, которые длится обычный вузовский курс по алгоритмам, а дать в виде небольшой брошюры, в которой были бы срезюмированы абсолютно необходимые и обязательные к написанию «с закрытыми глазами одной рукой за спиной» вещи, плюс что-то ещё для расширения кругозора, плюс ссылки на годные источники информации по теме — для собственного интереса и самообразования. Ну и пару коллективных Q&A после этого провести — для закрепления пройденного материала.
Но, как показывает лично мой опыт, в подобном подходе нуждаются не просто не все проекты, а их абсолютный минимум. Бо́льшая часть проектов — это либо что-то небольшое и короткоживущее, где превыше всего — скорость изготовления, либо что-то очень большое и монструозное, где жизненный цикл сводится к добавлению новых функций плюс модификации и исправлению ошибок в старых. В таких проектах главное — опять же, выкатывание новых версий в срок и с должным уровнем качества.
Понятно, что есть системные архитекторы, которые создают скелет проектов с чистого листа. И вот от их способности построить этот скелет грамотно, в том числе с использованием правильных алгоритмов, зависит то, получится ли в результате полноценный продукт или же какой-нибудь уродец. Таким людям, понятное дело, алгоритмы знать положено по статусу. Но далеко не каждый программист, даже в Google, может похвастаться полномочиями уровня архитектора. По большей части, работа программиста сводится к рутинному кодированию вещей, незатейливых с точки зрения алгоритмов, но требующих хорошего понимания в структуре проекта. И тут усидчивость, хорошая память и добросовестность становятся куда ценнее, чем знание алгоритма Дейкстры =).
Но, как показывает лично мой опыт, в подобном подходе нуждаются не просто не все проекты, а их абсолютный минимум. Бо́льшая часть проектов — это либо что-то небольшое и короткоживущее, где превыше всего — скорость изготовления, либо что-то очень большое и монструозное, где жизненный цикл сводится к добавлению новых функций плюс модификации и исправлению ошибок в старых. В таких проектах главное — опять же, выкатывание новых версий в срок и с должным уровнем качества.
Понятно, что есть системные архитекторы, которые создают скелет проектов с чистого листа. И вот от их способности построить этот скелет грамотно, в том числе с использованием правильных алгоритмов, зависит то, получится ли в результате полноценный продукт или же какой-нибудь уродец. Таким людям, понятное дело, алгоритмы знать положено по статусу. Но далеко не каждый программист, даже в Google, может похвастаться полномочиями уровня архитектора. По большей части, работа программиста сводится к рутинному кодированию вещей, незатейливых с точки зрения алгоритмов, но требующих хорошего понимания в структуре проекта. И тут усидчивость, хорошая память и добросовестность становятся куда ценнее, чем знание алгоритма Дейкстры =).
В точку, все верно, люто плюсую. Насчет алгоритмов — я слабо представляю, как умение написать алгоритм Дейкстры во сне (подразумевается, тупо заучив его) поможет в написании UI для gmail. Чем, обычно, и грешит Гугл (Яндекс, Epam) на собеседованиях — набирают лучших инженеров, задают вопросы по выученным алгоритмам, и садят за адаптивную верстку продукта 100500-й важности
Круто написано! Получился хороший толчок для джуниоров =)
У меня разорвался шаблон, когда в первой формуле я начал делить на ноль
А что там про олимпиадников на позиции «промышленных» программистов писали, кто помнит? :)
Смешная статья.
Если автор программирует, что бы зарабатывать, мне его искренне жалко.
Я программирую и от этого я просто в нирване, а деньги, как доп. бонус.
И стартовая формула, как сейчас модно называть «для неудачников».
Считать нужно компании которые ТЕБЯ устраивают. Нужно быть хозяином положения, даже когда ты наемный работник, а не пресмыкающимся. «Ой, меня не взяли, я наверно плохой» :)))
Правельная формула: «Я выбрал из ХХХ компаний только Х, потому что только они меня устраивают».
Нужно автору из точки зрения раба, перейти в позицию хозяина. Не ведитесь, не примеряйте его маску, она негативная :)))
Если автор программирует, что бы зарабатывать, мне его искренне жалко.
Я программирую и от этого я просто в нирване, а деньги, как доп. бонус.
И стартовая формула, как сейчас модно называть «для неудачников».
Считать нужно компании которые ТЕБЯ устраивают. Нужно быть хозяином положения, даже когда ты наемный работник, а не пресмыкающимся. «Ой, меня не взяли, я наверно плохой» :)))
Правельная формула: «Я выбрал из ХХХ компаний только Х, потому что только они меня устраивают».
Нужно автору из точки зрения раба, перейти в позицию хозяина. Не ведитесь, не примеряйте его маску, она негативная :)))
Если автор программирует, что бы зарабатывать, мне его искренне жалко.
Вы, как я понимаю, на попечительстве родителей? Потому что иначе ваш комментарий выглядит весьма странным.
Что мешает наслаждаться программированием на работе? Вот я люблю программировать: и на работе программирую, и когда есть время свободное программирую.
Да, Вы правы, на попечении родителей :))))
За одной маленькой неточностью, я сам родитель уже не один десяток лет и многодетный папа. Программирую тоже несколько десятков лет.
Я фанат программирования.
А эта статья навязывает рабское мировозрение и ничего более.
Я читаю тех. литературу по выходным, в свободное время что то изучаю не потому что я «прокачиваю скилы, что бы меня взяли на работу», а потому что мне это интересно.
Я на работу устраивался ВЫБИРАЯ работу, а не делал подсчеты, на сколько я плох/хорош по собеседований от разосланых резюме.
Ей богу смешно.
То что минусили меня, это явно студенты или начинающие программеры. Те у кого программирование — призвание, а не работа, кто выбирает работодателя ставя свои условия, те меня понимают. :))
За одной маленькой неточностью, я сам родитель уже не один десяток лет и многодетный папа. Программирую тоже несколько десятков лет.
Я фанат программирования.
А эта статья навязывает рабское мировозрение и ничего более.
Я читаю тех. литературу по выходным, в свободное время что то изучаю не потому что я «прокачиваю скилы, что бы меня взяли на работу», а потому что мне это интересно.
Я на работу устраивался ВЫБИРАЯ работу, а не делал подсчеты, на сколько я плох/хорош по собеседований от разосланых резюме.
Ей богу смешно.
То что минусили меня, это явно студенты или начинающие программеры. Те у кого программирование — призвание, а не работа, кто выбирает работодателя ставя свои условия, те меня понимают. :))
Если бы мне не платили, я бы программировал своё и для себя. Но мне платят. И там не всегда такая уж нирвана. Бывает и откровенный шлак.
UFO just landed and posted this here
в 99-м году проходил интервью в достаточно большой фирме. Искали человека который знает java. Показали листинги и спросили, «что делает код?».
Знаете, какое в вакансиях часто встречающееся требование к соискателю? «Умение разбираться в чужом коде».
В этом плане показать кусок кода собственного написания и попросить в нём с ходу разобраться — неплохой тест для соискателя. Потому как, в отличие от теоретизирований на тему алгоритмов, структур данных и особенностей языка, а также попыток сходу без привычных инструментов накреативить какой-нибудь работающий код на заданную, умение разбираться в коде у хорошего программиста развивается до уровня рефлексов и регулярно эксплуатируется в обычном рабочем процессе при стрессовых условиях («надо срочно пофиксить»), так что волнение будет вносить не столь сильные искажения в демонстрируемый результат.
Понятное дело, что многое зависит от того, насколько хорошо структурирован и оформлен код, а также от того, смотришь ли ты его на экране компьютера в знакомой IDE, или же в распечатанном виде. Но, тем не менее, по ходу рассуждения и по задаваемым соискателем вопросам можно составить неплохое впечатление о его адекватности и способностях. А не это ли главная цель собеседования?
«что делает код?». где они правильные ответы брали я не знаю. но это так — элюстрация.
Так может им не особо важен ответ, а важен именно процесс рассуждений? Вы можете и ответить неверно о работе куска кода, но ход ваших рассуждений может интервьюирующему сказать о том, что вы способны мыслить вне стандартных шаблонов/алгоритмов, что означает, что вы сможете в будущем сами разрабатывать алгоритмы для решения поставленных задач.
Sign up to leave a comment.
ABC: Always Be Coding (не переставай программировать)