Заблуждения программистов о трудоустройстве

https://shubhamjain.co/2018/06/07/falsehoods-programmers-believe-about-hiring/
  • Перевод
Это перевод. Статья опубликована в июне 2018 года

Я не сразу устроился на достойную работу. Мне вполне хватало технических навыков, но я просто сдерживал себя. На это не было никаких причин, кроме глупых предположений о том, что хочет работодатель. Я пошёл на дерьмовую работу и тратил всё свободное время на коммиты Github ради улучшения профиля. Я тогда не знал, что принимающим решение людям практически не интересен этот код.

Прошло четыре года. Теперь я лучше понимаю процедуру трудоустройства и то, как увеличить свои шансы, используя логику нанимателя.

В стиле известной статьи Патрика Маккензи об именах, вот список главных заблуждений, которые могут быть у программистов (особенно начинающих).

1. Обязателен вклад в проекты Github с открытым исходным кодом


По моей оценке, менее чем у 3−4% соискателей есть значительный вклад на Github. В последние полтора года я практически ничего не коммитил и всё же получаю больше предложений о работе, чем во времена прежней активности на Github. Значительно важнее связи на LinkedIn и опыт работы.

2. Компания, использующая определённый фреймворк (скажем, Angular.JS), не станет рассматривать никого, кто им не владеет


Большинство компаний понимают, что хорошие программисты могут быстро развиваться. Технологии в любом случае меняются каждые несколько месяцев, так зачем жёстко требовать знаний конкретного фреймворка?

3. Технические навыки важнее всего


Умение чётко общаться, хорошо работать в команде и понимать бизнес-цели на самом деле ценится выше, чем умение программировать.

4. Просить коллег о рекомендации неудобно


Если вы действительно компетентны в своей области, люди с радостью дадут вам рекомендацию.

5. У вас нет шансов, потому что вы конкурируете с монстрами, у которых тысячи звёзд Github и сверхклассные проекты


Преувеличение конкуренции — разновидность ошибки выжившего. Если бы вы конкурировали со звёздными программистами, компании бы не тратили месяцы, как это часто бывает, чтобы закрыть одну позицию.

6. Если попросить большую зарплату, то такого жадного, неблагодарного мудака отвергнут почти сразу


Больше о переговорах. Если вкратце: всегда есть большое поле для манёвра, а работодатели больше вас уважают, если вы начинаете переговоры.

7. Отсутствие ответа на заявку означает, что резюме выбросили в корзину и последующие действия бесполезны


Обязательно, обязательно отправьте ещё одно письмо. У людей много дел, а ваше резюме, возможно, просто не заметили. Никто не считает дерзостью повторные попытки, если вы вежливы и уважительны. Не однажды случалось, что я останавливался после одного или двух писем, а позже узнавал, что HR-менеджер просто забыл ответить. Все мои опасения показаться надоедливым были необоснованными.

8. Если компания нанимает 1−3% кандидатов, то вы конкурируете с сотнями талантов


Прочитайте статью «Поиск отличных разработчиков». Пул кандидатов обычно кишит резюме от некомпетентных специалистов, которые рассылают резюме во все фирмы.

9. Череда отказов означает, что вы ужасный программист. Как этот


Трудоустройство — неорганизованный и нечёткий процесс. Иногда даже компании не знают точно, что они ищут. Иногда у интервьюеров чрезмерные ожидания без веской причины. Даже кандидаты, которые идеально подходят, могут попасть в чёрную полосу, которая не имеет ничего общего с их способностями. Так, продолжайте попытки!

10. Отличное резюме — длинное с множеством ключевых слов


Хорошие кандидаты умеют резюмировать работу без объяснения подробностей. По моему опыту длинное резюме с множеством ключевых слов скорее коррелирует с некомпетентностью.

11. Рассылка резюме по всем компаниям увеличивает ваши шансы


Массовая рассылка редко помогает. Прежде чем подать заявку, поймите компанию, их продукт и используйте эти знания в сопроводительном письме. Это само по себе поставит вас выше остальных, кто не сделал простую домашнюю работу.

Но это лишь верхушка айсберга. Главный хак для трудоустройства — связи. Если у вас обширные связи, а ваши способности всем известны, то вы можете узнать о вакансии ещё до того, как она попадёт на официальную страницу. На собеседовании к вам сразу отнесутся как к надёжному кандидату, а интервьюеры гарантированно увидят вас в более позитивном свете. Наращивание сети связей требует времени и не всем нравится (точно не мне). Однако со временем оно окупается сторицей.

Знаете другие заблуждения? Дайте знать, я добавлю в список.
Поделиться публикацией
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 423
  • +4
    Согласен со статьей. Да, совсем новичку может быть сложно найти работу, но сейчас есть реальный дефицит хороших кадров
    • +8
      Это создает ложное впечатление, что если ты не считаешь себя хорошим, крутым спецом, то никому не нужен. В мире разработки и средние спецы требуются или нет?
      • 0
        Из многих средних спецов со временем зачастую получаются хорошие. Опытные работодатели это учитывают.
        • 0
          себя хорошим, крутым спецом
          Я специально сказал «хороших», а не «крутых». Это ведь разные вещи.
          • –9

            Берем Даля и ищем… Крутой — сильный.

            • +4
              Окей. А «хороший» там тоже «сильный»? «Крутой»/«сильный» — это для меня уровень синиора, а «хороший» может быть даже джун, если необходимо закрыть позицию джуна и он хороший.
              • +4
                1) Куда берём, кого, что? Не могли бы вы ссылочку привести? А то если вы про того Даля, что я думаю, то я у него такого не вижу.
                2) «закопайте стюардессу», живой великорусский за 150 лет несколько изменился
            • +6

              В мире разработки, насколько я могу судить, и среднего-то спеца найти не очень просто — рынок забит откровенно слабыми кандидатами (люди, способные для получения максимального элемента массива полностью отсортировать его).

              • +2
                Вот я понимаю, что для этого не нужно полностью сортировать массив (только не знаю, как это отобразить в резюме), но при этом даром никому не нужен.
                • –1
                  Отсекают еще совершенно «чистых незамутненных» кандидатов такими грязными приемчиками: «какова сложность вставки в вектор целых чисел v?» и пока кандидат не опомнился говорят: рассмотрим такой пример:
                  for (int i = 0; i < 10000000000; ++i)
                      v.push_back(i);
                  

                  не ожидающий подвоха честный кандидат ответит «линейная» и его мгновенно отсекут как «юниора».
                  • +4
                    Интервьюёры иногда напоминают наперсточников, которые разводят «лохов». Причем чем именитее компания, тем более эта аналогия прослеживается.
                    • 0
                      Почитал про push_back, время вставки — константа, в общем случае, ну и на выделение памяти ещё время может потребоваться. Сложность вставки в вектор зависит от того, куда вставляем, если я правильно понял подвох) Или вы про то, что время отработки цикла не имеет ничего общего с единичной вставкой в вектор?
                      • 0
                        Вы тоже попались, хотя было время подумать. :) Не злорадствую, высмеиваю типичных интервьюёров. Сложность вставки в конец конечно константа, сложность вставки в таком цикле линейна, если бы вообще этот цикл работал, но он, к сожалению, зацикливается и будет почти гарантированно bad_alloc. Если же цикл не зациклится, потому что MAX_INT > 10000000000, то будет все равно bad_alloc, потому что не хватит памяти. Если же памяти хватит, то интервьюируемый молодец, а интервьюер остался в дураках, но этого не произойдет.
                        • +2
                          Сложность вставки в конец конечно константа

                          Амортизированно, но даже не в случае реаллокаций.

                          Но вообще, конечно, с учётом такого сценария разговора, очень хочется посчитать плотность UB/LOC в реальном коде таких интервьюверов.
                      • 0
                        Отсекают еще совершенно «чистых незамутненных» кандидатов такими грязными приемчиками
                        Вы представляете интервьюера, как какого-то мудака, который только спит и видит, как вас завалить? Вы сами хоть раз с той стороны сидели?
                        • +2
                          Да, сидел и прекратил эту лживую вакханалию еще в 2013 году. Представляю одной из первейших задач интервьюёра сбить цену интервьюруемого. Не знаете RVO? Вы что, батенька, с ума сошли? Да вы просто юниор!
                          • +2
                            Ну вот вы сбивали цену, а я просто ищу хороших специалистов. Не судите всех по тому, как лично вы проводили интервью
                            • 0
                              Я так не проводил никогда интервью. Мы-то искали юниоров в основном. И смотрели главным образом на то, что человек проходит минимальный ценз, и ориентируется в технологии и проблематике в общем, никогда не подлавливая его на каверзных вопросах. Никогда. Никакого чувства, что кандидата «облапошили» нет. И второе непременное условие — чтобы человек как личность был вменяемый и хороший.
                              В основном все, что я видел в отношении себя — это «наперсточничество». Сбивка цены на подлове. Честнее просто дать задачи, как в Яндексе, и все. Не с подвохом, а просто задачи. Ведь человек должен уметь решать задачи, так? Но устное интервью, где нужно найти «лучшего среди тех, кто знает все примерно одинаково» — превращается в вакханалию с ударами ниже пояса. У нас типо одно простое интервью, и все. И оффер. Никаких задач. А на деле это вакханалия.
                              Как вам удается в формате интервью искать хороших специалистов? Это вообще возможно? Все будут отвечать на ваши общеизвестные вопросы, ловить вафлю на вопросах с подвохом, и просто не отвечать на «сложные» вопросы о незнакомых тонкостях в технологиях.
                              • +2
                                На самом деле абсолютное большинство приходящих на собеседования кандидатов не может ответить и на базовые вопросы без подвоха.
                                Если это конечно не вопросы уровня хелловорлдов
                            • 0
                              Вы и без всяких таких задачек можете ставить цену какую хотите — рынок же.
                              • 0
                                Я ставлю какую хочу, а мне открытым текстом говорят, что наши удивительные программеры обладают замечательной способностью оценивать релевантность финансовых ожиданий путем проведения волшебных собеседований. Система оценки запускается — и — бац — магическим образом оказывается, что я не соответствую своим же ожиданиям.
                          • 0
                            О, обожаю эти вопросы про «какова сложность алгоритма»…
                            К реальной работе имеет отношение чуть больше чем никак. Т.е. кандидат должен знать что вариант А будет работать быстрее варианта Б (и желательно почему), но вот знать что тут именно «линейная» сложность, а не «квадратическая» ему знать совсем не обязательно. Дело в том, что в реальных проектах не пишут своих сортировок массивов, а используют готовые решения и библиотеки, а значит скорее всего они используют один из самых быстрых алгоритмов (если конечно у вас не специфические данные). А позвольте спросить зачем вы добавляете миллионы записей в вектор?! В реальной жизни такого не будет и если я увижу такой код, то я попытаюсь оптимизировать его ещё до прихода в этот цикл.
                            • +4
                              В реальной жизни люди пишут запросы к базе в цикле в цикле. Ну типа:

                              for (foo => first.count) {
                                for (bar => second.count) {
                                  insert_unique(foo_objs, db.query('select * from foo where id=$foo'))
                                  insert_unique(bar_objs, db.query('select * from bar where id=$bar'))
                                }
                              }


                              Пример, конечно, утрированный, но основы понимания сложности алгоритма нужны не только для сортировки массивов
                              • 0
                                В реальной жизни относительная «стоимость» каждой микро-операции может сильно различаться на x86 и ARM, например. А на ре-аллокацию вектора по ходу вставки может вообще не найтись подходящего куска свободной памяти.
                                • –1
                                  Основы понимания сложности алгоритмов нужны, но они нужны уровня «лучше-хуже», «быстрее-медленнее», «можно-нельзя». Но никак не «линейная», «квадратическая», «логарифимическая» и т.д. Большим плюсом будет умение работать с профайлером, находить «горячие» функции и анализировать планы SQL запросов. К сожалению вопрос о сложности алгоритма при вставке в вектор в цикле не сможет помочь отличить хорошего кандидата от плохого…
                                  • +1
                                    И «линейная», «квадратическая», «логарифимическая» тоже нужны. Даже при работе с SQL если вам предложат сортировать результат выборки по неиндексированному полю, а то и по случайному числу. На 100 записях условно без разницы какая там сложность, а вот на 100 000 очень влияет.
                                    • 0
                                      Ага, а потом фигачат квадратичные алгоритмы вместо линейных или логарифмических, потому что на маленьких объёмах данных те быстрее. А потом удивляются: как же так, ведь было всё быстро?! А при увеличении данных в 10-100-1000 раз ВНЕЗАПНО стало медленно, и вон тот ранее тормозной алгоритм вдруг всех уделал.
                                      • 0
                                        Дело в том, что чаще всего фигачить алгоритмы не нужно. Для массивов есть Sort(). Для SQL есть ORDER BY. Умение избежать лишних циклов и выносить весь ненужный код за циклы — вот основа алгоритмов для программиста. Для SQL — умение читать планы запросов и знать как работают индексы. Пользуясь этими правилами можно избежать основных косяков, а дальше в дело вступает профайлер и в случае если код работает медленно — можно подумать как оптимизировать…
                                        • 0
                                          Умение избежать лишних циклов и выносить весь ненужный код за циклы — вот основа алгоритмов для программиста.

                                          К сожалению понимание зачем это нужно есть далеко не у всех. Хотя бы интуитивное представление о сложности алгоритмов нужно.
                                          • +3
                                            Для SQL есть ORDER BY
                                            ORDER BY RAND()?
                                            • 0
                                              Вы про вот такой (валидный) SQL-запрос?
                                              SELECT *
                                                FROM table1
                                                ORDER BY RAND()
                                              В чём именно состоит ваш вопрос?
                                              • 0
                                                Считаете, что с ним всё равно какая сложность у сортировки, линейная или квадратичная?
                                                • 0
                                                  А что значит «с ним всё равно»? «Всё равно» для написания такого запроса или «всё равно» в том смысле, что время его исполнения не будет зависеть от сложности сортировки?
                                                  Для написания всё равно — и так очевидно, что если сортировка у SQL-сервера будет «честная», а не оптимизированная под случайное перемешивание, то время будет больше оптимального.
                                                  А для оценки времени выполнения (если сортировка «честная») — очевидно, что не всё равно, если время выполнения этого запроса критично.
                                                • 0
                                                  Вы про вот такой (валидный) SQL-запрос?
                                                  Я про такой валидный запрос:
                                                  SELECT *
                                                    FROM table1
                                                    ORDER BY RAND()
                                                    LIMIT 1

                                                  Вопрос сами найдёте?
                                                  • 0
                                                    Это решение какой-то олимпиадной задачи вида «как в одну строку на SQL получить случайную строку из базы»?
                                                    Вопрос не найду, у меня самого вопрос — зачем такое вообще через ORDER BY делать, и какое это имеет отношение к порядку сложности сортировки?
                                                    • +1
                                                      Это решение какой-то олимпиадной задачи вида «как в одну строку на SQL получить случайную строку из базы»?
                                                      Нет, это довольно популярное у новичков решение для получения случайной строки.

                                                      отношение к порядку сложности сортировки?
                                                      Вы даже слегка не представляете, какое это имеет отношение к сортировке и её сложности?
                                                      • 0
                                                        Да, не понимаю. Очевидно, что сортировка больших данных — ДОЛГАЯ.
                                                        Знать, кубично, квадратично или линейно она долгая — не обязательно. Нужно знать только, что сортировка применяется после выборки, а LIMIT — после сортировки, поэтому сначала прочитается вся таблица (долго и много данных), а потом к ней применится долгая операция.
                                                        • +1
                                                          Я знаю, что вы понимаете. Вы и O-нотацию понимаете. А люди такое пишут и не понимают. Честно признаюсь, я такое писал и даже не задумывался. У меня образование не прогерское и в первый год даже мысля не было, что тут сортировка, что сортировка — n*logn, что с ростом данных оно работает слишком медленно. Просто я даже не предполагал, что такие вопросы задавать нужно.
                                                      • 0
                                                        Вопрос не найду, у меня самого вопрос — зачем такое вообще через ORDER BY делать, и какое это имеет отношение к порядку сложности сортировки?
                                                        А как правильно? Не холивара ради, а образования для. Просто я SQL не знаю, и однажды, когда мне нужно было выбрать случайную строчку из базы, написал именно такое решение. Не потому, что не знаю, что долго, а потому, что база все равно небольшая, а по-другому я не умею.
                                                        • 0
                                                          Легко гуглится на самом деле.
                                                          • +2

                                                            На самом деле, это хоть и быстрое решение, но весьма неточное. Простейший контр-пример: [1, 2, 3, 4, 5, 100000]. При неравномерном распределении ID, такой подход, конечно, не годится. А неравномерное распределение ID совершенно рядовая ситуация. Неужели в недрах SQL нет чего-то более подходящего?

                                                            • +1
                                                              Да, не спорю) Я давно уже SQL не писал, но реально вменяемых решений оттуда не помню.
                                                              • 0
                                                                Можно попробовать через RowNumber решить — но не уверен что будет достаточно быстро

                                                                Вот для SQL Server:

                                                                DECLARE NUM AS INTEGER
                                                                SELECT NUM = count(*)*RAND() from tbl
                                                                select * from (select ROW_NUMBER() OVER(ORDER BY (SELECT NULL)) as ROWNUM, t.* from tbl t) t2 WHERE ROWNUM=@NUM

                                                                SELECT TOP 1 * FROM tbl
                                                                ORDER BY NEWID()

                                                                Для 300 000 строк первый запрос у меня отработал в 2 раза быстрее второго…
                                                                • 0
                                                                  То же, вроде бы, можно написать и для MySQL, но вместо row_number() использовать LIMIT с двумя параметрами.
                                                                  Примерно так (за синтаксис не ручаюсь):
                                                                  SELECT * FROM tbl LIMIT @num, 1
                                                                  • 0
                                                                    Лимит переберет первые num записей, а потом отберет одну.
                                                                    • 0
                                                                      Переборка по индексу должна быстро работать:
                                                                      SELECT t.*
                                                                      FROM (
                                                                        SELECT id
                                                                        FROM tbl
                                                                        LIMIT @num, 1
                                                                      ) q
                                                                      JOIN tbl t
                                                                      ON t.id = q.id
                                                                      Но вообще, мне кажется, SQL для таких операций не очень-то приспособлен, это уже бизнес-логика.
                                                        • 0
                                                          Не вижу в этом ничего плохого, особенно если табличка на 10 строк, а ORDER BY RAND() даст стабильную сортировку (в чём я, правда, не уверен).
                                                          • +2
                                                            Конечно ничего плохого, если вы понимаете, когда можно применять, а когда нет. Т.Е. понимаете, по сути, сложность алгоритма
                                                            • 0
                                                              С этого-то и началось обсуждение (а именно мой комментарий по поводу «нужно понимать», а не «знать» что тут «квадратичная, а не линейная сложность». Чрезмерное зацикливание на сложности алгоритмов ведёт к частой проблеме хороших программистов, а именно к преждевременной оптимизации. Поэтому ORDER BY RAND() имеет смысл, пока не обнаружится, что этот код является бутылочным горлышком в производительности. Да и представить необходимость делать выборку случайной записи из миллионов я с трудом могу представить — чаще всего будет какое-нибудь ограничение, которое уменьшит выборку до десятков-сотен записей…
                                                              • 0
                                                                Чрезмерное зацикливание на сложности алгоритмов ведёт к частой проблеме хороших программистов, а именно к преждевременной оптимизации
                                                                Мы ведь всё еще о собеседованиях говорим? Лучше взять того, кто вообще сложности алгоритмов не знает, лишь бы преждевременной оптимизацией не дай бог не занимался? А как узнать, понимает ли человек, если у него не спросить?
                                                            • 0
                                                              А где грань, 10, 11, 100, 1000, 1000000? Сможете дать оценку, не запуская реально запрос, когда время исполнения превысит 50 мс, если при 10 даёт 1 мс?
                                                              • 0
                                                                А где грань, 10, 11, 100, 1000, 1000000?

                                                                Если производительность приемлема, то более читабельное решение приоритетнее. Я выше написал, что меня беспокоит стабильность сортировки. Если он один раз для каждой строки посчитает свой рандом и будет его использовать — тогда это нормальный способ получить случайную строку.

                                                                Сможете дать оценку, не запуская реально запрос, когда время исполнения превысит 50 мс, если при 10 даёт 1 мс?

                                                                Тут квадрат, только у нас нет константы, от которой плясать. Так что оценку дать нельзя, потому что у нас есть одно уравнение с двумя неизвестными — y2 и C.
                                                                • 0
                                                                  Оценку константы можно получить по данным «при 10 даёт 1 мс». Если принять ваше допущение, что «тут квадрат», то константа в формуле C*N^2 порядка 0.01 мс, то есть где-то на 70 записях уже время выборки превысит 50 мс. Понятно, что формула грубая и скорее всего запас побольше, потому что реальная формула скорее ближе к C1+C2*N^2, но понимание того, что тут не линейная зависимость, а более крутая, даёт нам право предпологать, что крайне маловероятно, что выборка из 500 записей уложится в 50 мс.
                                                                  • +2
                                                                    Оценку константы можно получить по данным «при 10 даёт 1 мс»

                                                                    Каким образом? Мы знаем, что сложность квадртичная. Окей, значит она описывается формулой y = c*x^2 + b. Дальше у нас есть только одно уравнение 1 = c*10^2 + b. Как мы отсюда можем c и b получить?

                                                                    • –1
                                                                      Каким образом?
                                                                      Из личного опыта. Например, более или менее любой, занимавшийся олимпиадным программированием, знает, что в 2 секунды можно сделать около 100 млн операций (тех самых, что в формуле асимптотической оценки), с редкими исключениями алгоритмов или структур данных с большой константой, вроде фибоначчиевой пирамиды или алгоритма Штрассена. Думаю, в работе с базами данных так же.
                                                                      • 0
                                                                        что в 2 секунды можно сделать около 100 млн операций


                                                                        Это разве не зависит от железа?
                                                                        • 0
                                                                          Железо на олимпиадах все примерно одинаково производительное. Да, если взять задачи десятилетней давности, придется изменять ограничения на размер входных данных или на время работы.
                                                                        • +1
                                                                          При чем личный опыт? При чем тут олимпиады? Мы про решение задачи, которое должно быть единственным. Ответ в стиле «ну я когда в 12 году был на олимпиаде от нашего универа, там были четвертые пни которые делали столько-то операций, так что ответ такой-то».

                                                                          С двумя свободными параметрами одной точке на плоскости (10,1) соответствует бесконечное множество парабол с разными c и b.

                                                                          Плюс

                                                                          Думаю, в работе с базами данных так же.


                                                                          А я вот так не думаю. И без формальной разрешающей процедуры у нас нет шанса установить, кто прав. Т.к. в аналитической задаче всегда есть один ответ, а тут зависит от того, чей олимпиадный опыт больше видимо.
                                                                          • 0
                                                                            В комментарии, с которого началась ветка, сказано
                                                                            Оценку константы,
                                                                            а не «точное значение константы». Личный опыт, в том числе в смежной сфере — вполне приемлемый вариант для того, чтобы получить грубую оценку производительности.
                                                                            • +1
                                                                              Для оценки производительности на личном опыте недостаточно данных. А что за движок СУБД? А сколько ядер/процессоров? А является ли таблица inmemory? Если нет, то какие там индексы? Нет ли оптимизатора, который развернет ORDER BY RAND() во что-то иное? Все это влияет на ответ, причем сильно. А если оценка может скакать на порядки в ту или иную сторону, то не очень-то это оценка хороша.
                                                                              • 0
                                                                                Ну так человек, работающий в конкретной компании с конкретной базой, скорее всего, имеет личный опыт, который покрывает как раз все эти данные. А применительно к тому, что я выше писал — в олимпиадном программировании у вас одно ядро и все операции в памяти.
                                                                                А вот вид используемого индекса и написанный код как раз заключены в асимптотическую оценку.
                                                        • 0
                                                          Не у всех программирование ограничивается вбиванием запросов к БД, знаете ли.
                                                          • 0
                                                            В ваших «чаще всего» примерах крайне желательно перед использованием Sort() или ORDER BY понимать, что на больших объёмах относительно случайных данных скорее всего и там, и там средняя сложность скорее всего будет N*log(N), а никак не N или 1.
                                                        • 0
                                                          Да даже без разницы нужны или нет, по моему даже те кто на непрофильной специальности учился могут сложность оценивать. Так или иначе если программирование интересно натыкаешься рано или поздно.
                                                        • 0
                                                          Имеет смысл иногда, кстати. Например, если очень быстрое кэширование и медленная реальная выборка. Единственное, конечно строку с foo вынести из внутреннего цикла, если побочных эффектов нет. С другой стороны, сложности это не изменит :)
                                                          • 0
                                                            Не утрировано, я подобное видел в продакшен коде, те самые настоящие индусы писали.
                                                          • +1
                                                            В реальной жизни, более того, найти одну из строк во входе прямым сравнением с memchr при теоретической сложности O(mn) может быть эффективнее, чем городить Ахо-Корасиков и потом по ним бегать, ломая все кеши и branch predictor'ы.
                                                            • +2
                                                              О, обожаю эти вопросы про «какова сложность алгоритма»…
                                                              К реальной работе имеет отношение чуть больше чем никак

                                                              В который раз могу привести реальный пример из продуктового кода:


                                                              List<SomeType> list = GetSomeList();
                                                              foreach (var item in list)
                                                              {
                                                                  int i = list.IndexOf(item);
                                                                  // do something with item and i
                                                              }

                                                              Таки вы по-прежнему считаете, что сложность алгоритма не имеет отношения к реальности?


                                                              Понятно, что в реальной работе каждый день не программируется реализация графовых алгоритмов, но понимание таких вещей необходимо и при работе с базовыми типами данных, с которыми работа каждый день идет.


                                                              Так же, как понятно, и то, что достаточно вопросов на общее понимание этих вещей, и на то, чтобы понять, готов ли разработчик осознанно выбирать то, что ему подсказывает автозаполнение в IDE (в идеале — знакомиться с доками).

                                                              • 0

                                                                Я ещё видел реальный код с LINQ головного мозга.
                                                                Это когда простой код с for (int i = 0; i < list.Count; i++) заменялся чем-то непонятным и монструозным.

                                                                • 0
                                                                  Таки вы по-прежнему считаете, что сложность алгоритма не имеет отношения к реальности?

                                                                  Я бы сказал, что не надо вызывать IndexOf внутри цикла, даже когда не знал про оценку сложности и какая она у пузырьковой сортировки. Потому что для поиска там скорее всего еще один цикл.
                                                                  Я считаю, что чтобы понять, что такой код писать не надо, знание сложности необязательно.

                                                                  • 0
                                                                    Я считаю, что чтобы понять, что такой код писать не надо, знание сложности необязательно.

                                                                    Согласен с вами, есть куча таких моментов, которые проистекают из здравого смысла.


                                                                    Что касается вопросов на "сложность", насколько понимаю, тому две причины:


                                                                    • Во-первых, можно усмотреть, что в разные периоды возникала разная мода на то, что спрашивать (зачастую такая мода необоснована с точки зрения сути предстоящей работы).
                                                                    • Во-вторых, применительно к .NET-сфере, насколько помню, такие вопросы стали возникать, когда появились дженерики и реализации типизированных Dictionary/SortedDictionary/SortedList (то того был только нетипизированный Hashtable и DictionaryBase, от которого наследовались узкоспециализированные коллекции), и когда затем появился LINQ.
                                                                      Т.е., когда появились стандартные средства, предполагающие понимание сложности, тогда и появились вопросы.
                                                                • +6
                                                                  Не совсем согласен, потому что такая разница между линейной и квадратичной сложностью может очень сильно роялить на больших объемах данных.
                                                                  • 0
                                                                    Я бы даже сказал между линейной и константной, когда список можно заменить хэшсетом. Мы сталкивались с такой проблемой при обработки больших исходных файлов на несколько мегабайт.
                                                                    • 0
                                                                      Это вы для хэшсета сложность добавления в него считаете константной? А как же неравномерность распределения хэш-функции, разрешение коллизий, переполнение вёдер и перестройка хэша? Раз уж мы о больших объёмах данных говорим.
                                                                      • 0
                                                                        Так амортизированно все равно константа получится, разве нет? А что в худшем случае линия, для большого числа запросов не особенно важно.
                                                                        • 0
                                                                          Зависит от того, есть ли у вас достаточно места, чтобы изначально выделить под него, и все данные влезли туда без большого процента коллизий.
                                                                          Впрочем, я ненастоящий сварщик, спорить не решусь.
                                                                          • +3
                                                                            Понятно, что «в худшем случае» у нас могут все элементы попасть в одну корзину, и нас ничего не спасет, хеш-таблица хороша именно в среднем случае, когда все хеши более или менее разные.
                                                                            Тогда у нас среднее число элементов в одной корзине получается n/k, где n — число элементов, а k — число корзин. И до тех пор, пока эта величина порядка O(1), добавление, удаление и поиск элементов будут работать за O(1). Поэтому если n/k превышает некий константный порог, мы увеличиваем k, перестраивая всю таблицу. Очевидно, что эта операция (проитерироваться по всем элементам и добавить все по одному в новую таблицу) работает за O(n), ведь новая таблица побольше и все добавления в нее константны. Поэтому операцию перестроения мы будем делать редко, каждый раз экспоненциально увеличивая размер таблицы.
                                                                            Если, например, стоимость перестроения таблицы размера x равна a*x, и мы увеличиваем размер вдвое каждый раз, то при добавлении n элементов в изначально пустую таблицу мы потратим O(n) времени на добавления, и дополнительно a*n + a*n/2 + a*n/4 +… + a*1 = 2*a*n = O(n) времени на все перестроения в сумме. То есть, на добавление O(n) элементов мы потратили O(n) времени, или, амортизированно, по O(1) на элемент.
                                                                            Это на пальцах, нестрого, в реальности используются другие соотношения, а еще нам желательно оценивать частоту коллизий, ведь может не повезти, там нужно везде считать мат ожидания и вероятности, а это с асимптотическими оценками сложнее. Но суть не меняется — с хеш-таблицей мы имеем в среднем амортизированно константное время работы.
                                                                            PS: «В среднем» означает, что нам может не повезти и данные подберутся так, что асимптотика будет больше. Именно в случае хеш-таблицы такие шансы в случае случайных данных экспоненциально уменьшаются с размером входных данных, но иногда может попасться задача (по крайней мере, на олимпиадах, хотя, может, и в реальном мире), в которой данные будут специально подобраны наихудшим способом.
                                                                            «Амортизированно» означает, что одна операция может занять гораздо дольше, чем O(1) — в нашем случае, вплоть до O(n). То есть, если нам нужна стабильность времени ответа, то операция добавления элемента в хеш-таблицу не подойдет. А вот если мы делаем пакетную обработку запросов, то это не важно.
                                                                            PPS: Если интересно, могу статью на эту тему написать, с подробным объяснением и строгой математикой.
                                                                            • 0
                                                                              если n/k превышает некий константный порог, мы увеличиваем k, перестраивая всю таблицу.

                                                                              В перле, ЕМНИП, перестройка идёт тогда, когда количество элементов в хэше становится равным размеру самой таблицы. Независимо от состояния корзин.
                                                                              • 0
                                                                                Если под размером таблицы понимается число корзин, то это как раз n/k=1. Просто, насколько мне известно, в других языках и библиотеках бывают и другие соотношения.
                                                                                • 0
                                                                                  Да, но при этом состояник корзин не учитывается: некоторые могут быть и пустыми.
                                                                        • 0
                                                                          В нашем случае эти тонкости были не важны, с такими проблемами не сталкивались. Так же как и не важна динамическая природа динамического массива, в котором иногда происходит перевыделение памяти. Был важен переход со списка к хешсету — получили значительный прирост.
                                                                    • +2
                                                                      Даже если не пишут свои алгоритмы, то нужно знать сложность, хотя бы оценочную, алгоритма используемого под капотом. Например, чтобы сказать на предложение остортировать массив из миллиона элементов, и пускай десять секунд ждут, ведь сто тысяч за секунду сортируется, что ждать придётся заметно больше десяти секунд, минимум в разы, потому что сортировки на никак не упорядоченных данных линейной не бывает.
                                                                    • 0
                                                                      Но ведь амортизационная стоимость и вправду будет О(n)
                                                                  • 0
                                                                    Насктолько редко сейчас встречается адекватный человек, который просто готов работать и ответственно относиться к задачам, что я уже лет 5-10 считаю, что технические навыки — второстепенны и приобретаются на порядок проще, чем человеческие и организационные.

                                                                    P.S. И при этом практически в каждом резюме можно увидеть self-organized.
                                                                    • 0
                                                                      P.S. И при этом практически в каждом резюме можно увидеть self-organized.

                                                                      Хорошо, что я такое не пишу. Хоть что-то в моем резюме честное! /s
                                                                      • +3
                                                                        Ну. Медленнообучающийся, некоммуникабельный, непроактивный и проч. и проч. не-. Зато честно. Работодатели должны оценить честность:)
                                                                      • 0
                                                                        Неистово плюсую. Не надо быть семи пядей во лбу, рокстар, аджайлгуру, разработчиком собственного фреймворка(велосипеда), чтобы просто ответственно делать свою работу, просто решить задачку. Причём неважно какая задача. Если человек делает на от**ись, то он всё так делает.
                                                                        • 0

                                                                          Подпишусь, Это разумеется не только с айти так.

                                                                      • 0
                                                                        попробуйте проверить свои силы на тестовых задачках. Возможно, вы недооцениваете себя. Если же нет, то хоть поймете куда стремиться
                                                                        • 0
                                                                          Спасибо за совет. Не забыть бы его, когда он понадобится. Только нашел работу на джуниора.
                                                                      • +1
                                                                        Да, совсем новичку может быть сложно найти работу, но сейчас есть реальный дефицит хороших кадров


                                                                        Ага, ага.
                                                                        Только сейчас дефицит высококвалифицированных кадров.
                                                                        А новичок — кадр низкоквалифицированных.
                                                                        • 0
                                                                          Да, потому новичку будет сложно, но зато потом он окунется в мир дефицита и отыграется за все.
                                                                          • +1
                                                                            Только сейчас дефицит высококвалифицированных кадров.

                                                                            Этот дефицит присутствует и будет присутствовать всегда.


                                                                            Причина простая: с ростом квалификации сотрудники приобретают различные навыки, но каждый из сотрудников развивается по-своему. И чем выше уровень квалификации, тем сложнее найти специалиста, множество навыков которого совпадает с требованиями работодателя.


                                                                            Тут остаётся 3 варианта: годами искать идеального сотрудника, платить завышенную зарплату overqualified сотруднику, либо тратить время на обучение underqualified сотрудника.

                                                                            • +3

                                                                              Как-то опыт показывает, что квалифицированные сотрудники и новые области осваивают легко и быстро, связывая их цепочками ассоциаций со старым опытом.
                                                                              (да, и квалификация != стаж. Выпускник вуза, если был заинтересован, может уже иметь за плечами достаточно опыта, чтобы легко и быстро скакать по языкам, фреймворкам и технологиям)

                                                                          • +1
                                                                            Очень часто нужен хоть кто угодно, кто готов делать работу.
                                                                            • –1
                                                                              Конечно, но, к сожалению/к счастью, рынок таких вакансий переполнен кандидатами
                                                                              • +1
                                                                                Это вы из какой-то параллельной вселенной пишите :)
                                                                            • +27

                                                                              Ещё добавлю для русскоязычных: не следует так уж бояться своего рунглиша. Достаточно intermediate, и не так уж важно произношение. На собеседовании будут стараться понять, а дальше при погружение выправится. Диалектов английского столько, что рунглиш один из не самых сложных :)

                                                                              • +5
                                                                                Верно. Еще добавлю, что к своим оговоркам надо относиться с юмором: если вас не поняли и переспросили — улыбнитесь и спокойно объясните другими словами. Вы ничего не теряете, но если будете хмуриться, напрягаться, психовать, что вас не понимают — это сильно уменьшит ваши шансы на успех.
                                                                                • +6

                                                                                  Тоже нет. Главное — продолжить. Совсем не нервничать на собеседовании, наверное, невозможно.

                                                                                  • +1
                                                                                    ИМХО возможно и нужно не нервничать. Это должно быть, как отчет по успешной работе или хорошо подготовленный доклад на конференции. Конечно, будет избыток адреналина, эмоциональный всплеск, но это не называется «нервничать». Хороший лектор на лекции, которую читает очередным студентам уже 20 лет, испытывает сходные ощущения. Если не будет испытывать, его не будут слушать, заснут.
                                                                                    • +12
                                                                                      PS К собеседованию нужно относиться как к переговорам двух равных сторон, даже если вам очень необходима работа. Нельзя показывать, что вам позарез нужны деньги, нельзя заискивать.
                                                                                      • +2

                                                                                        Иначе говоря — качайте скил переговоров.

                                                                                      • +1

                                                                                        Мы тут говорим про новичков-середнячков, для которых собеседование — вынужденное занятие, кто может жаловаться на софтскилы, и кому нужен совет "отказывают? Не сдавайтесь!", да? Ну и как, могут они не нервничать? Или это совет из серии "мышки, станьте ёжиками"? ;)

                                                                                        • 0
                                                                                          Может и отказывают как раз потому что нервничают. Ну там пометка «не уверен в своих силах» или ещё похуже. Ну или просто из-за нервов на простой технический вопрос не может ответить.

                                                                                          Ладно если первое-второе собеседование в жизни или за длительный срок, или если вот прям вакансия мечты, мелькнувшая раз в пятилетку. Но если ходишь на собеседования регулярно и постоянно нервничаешь (независимо от результата), то стоит пересмотреть своё отношение к ним на уровне своей психики, возможно даже к специалисту за помощью обратиться.
                                                                                          • +5
                                                                                            Из тех, кого знаю, да — снеснение и нервы проходят к 3-5 разу, мозг привыкает. Но это когда серийные посещения. Там как раз вместо начинает прижимать негативным восприятием, вплоть до «опять спросили это, пойду я».

                                                                                            Пойти к специалисту деньги нужны, а он(а) как раз работу ищет ;)

                                                                                            Но как минимум в тех местах где я собеседовал — нервы никого не отталкивали, и моя задача как собесника — успокоить и выковырять из скорлупаники.
                                                                                            • +6
                                                                                              скорлупаника — шикарное словцо!
                                                                                              • 0
                                                                                                Но как минимум в тех местах где я собеседовал — нервы никого не отталкивали, и моя задача как собесника — успокоить и выковырять из скорлупаники.

                                                                                                Да. Но когда видишь, что человек готов на любую работу, возникают серьезные сомнения.
                                                                                                • 0
                                                                                                  Что значит «готов на любую работу»? Она никогда не бывает «любая» если он ищет не работу разнорабочего, а программиста.
                                                                                                  Развернуть бы мысль.

                                                                                                  А то «любой язык»? Ну, это не редкость.
                                                                                                  «Любой фреймворк»? Да они ж все на одно лицо, какая разница на чем лабать.
                                                                                                  «Готов даже тесты писать для существующего кода»? Дак таких надо вообще печеньками подманивать!
                                                                                                  • 0
                                                                                                    Развернуть бы мысль.
                                                                                                    Нпр., знаю случаи, когда в целях экономии ремонт помещения делался силами сотрудников.
                                                                                                    какая разница на чем лабать
                                                                                                    Далеко не всех работодателей устраивает предельно формальное отношение. Когда совсем без разницы, то «и так сойдет». В результате нередко получается очень кривой код.

                                                                                                    Вспоминаю рассказ одного археолога. Приехали в далекую деревню на раскопки две группы по 10 человек. Одна остановилась в доме у одной тетки, а другая у другой. Обе получили одинаковые (хорошие для деревни) деньги за постой и стол. Одна подходила предельно формально — все было свежее со своего огорода, но что-то недокипело, а что-то перекипело и было невкусно. Но обоснованных претензий предъявить было невозможно и приходилось терпеть. Когда ей говорили, что невкусно, она не расстраивалась, а просто отмахивалась.

                                                                                                    Другая очень старалась, чтобы ее постояльцы были довольны. Очень расстраивалась, если кому-то не понравились щи или каша. Пекла пирожки к чаю и т.д. Постояльцы были очень довольны, как и хозяйка, хотя ей никаких дополнительных денег это не приносило. ИМХО при прочих равных большинству работодателей хочется, чтобы работник старался сделать работу как можно лучше, чтобы сознание хорошо сделанной работы приносило ему радость.
                                                                                                    • 0
                                                                                                      С другой стороны ряд работодателей грустит, когда я говорю, что не использую и не хочу использовать питон, например.
                                                                                                      • 0
                                                                                                        Ваше право. Я знаю очень крутых специалистов, пишущих только на Коболе или АБАП. Но при каких-то катаклизмах типа сокращений или закрытия конторы — они ищут работу по пол-года.
                                                                                                        • 0
                                                                                                          Да не, я не на Коболе и не на АБАП. В тот же Idris я начал тыкать ещё до его релиза, сейчас пробую всякие фичи, которые войдут в C++20, скорее всего. Просто, ну, не хочу использовать питон.
                                                                                                          • 0
                                                                                                            Я тоже PHP не люблю — но у компании одна из систем на нем, стоила приличные деньги в разработке и довольно неплохо работает. Поэтому кандидат, не желающий писать на PHP в принципе — нам не подойдет, хотя мы что-то новое туда добавляем довольно редко.
                                                                                                            • 0
                                                                                                              Так речь таки о том, есть разница, на чём лабать, или нет.
                                                                                                          • 0
                                                                                                            И кстати на западе Кобол до сих пор востребован (т.к. много успели написать на нём). Постоянно вижу 1-2 вакансии «Кобол для мейнфреймов», а специалисты по нему очень хорошо оплачиваемые именно потому что редкие, а новички туда идти не хотят…
                                                                                                            • 0
                                                                                                              У медали как правило две стороны — те же «1-2 вакансии» могут быть в неудобных местах, требовать допуска и т.п. С другой стороны — человек не ставящий себя в жесткие рамки скорее найдет себе приличную работу. Мой личный рекорд — 8 языков за одну неделю (C, C++, SQL, ABAP, R, Java, JavaScript и Lua), но это уже хакатон-извращения ;)
                                                                                                        • 0
                                                                                                          Вспоминаю рассказ одного археолога.

                                                                                                          Вывод: можно не напрягаться и получать такие же деньги, как напрягающийся.
                                                                                                          • 0
                                                                                                            Или по другому:
                                                                                                            И за деньги можно работать с удовольствием.
                                                                                                            • 0
                                                                                                              И за деньги можно работать с удовольствием.
                                                                                                              Да. Кто-то за работу получает только деньги, а кто-то и деньги, и удовольствие ;)
                                                                                                      • 0
                                                                                                        Может человек готов на любую работу, потому что ипотека, жена, дети и хочется кушать, а заначка кончилась или около того eewz0z.pen.io?
                                                                                                        • +1
                                                                                                          Среди работодателей много добрых и отзывчивых людей. Но, к сожалению, большинство не может позволить себе взять человека только из жалости. Мир устроен очень жестоко, и если кандидат не вызвал ничего кроме жалости, то ему м.б. очень вежливо, но откажут.
                                                                                                          • 0
                                                                                                            Речь не о том, что у кандидата нет ничего, кроме сложной ситуации за плечами, а о том, что если заначка кончилась, а с офферами не особо, то пойдешь на любую работу. Ну и собеседоваться становится сложнее: одно дело, когда у тебя есть работа, и от отказа ты ничего не теряешь, другое дело, когда каждый отказ бьёт по остатку денег… Тут есть повод волноваться — а волнующийся соискатель выглядит как слабый соискатель, которого надо дожать.
                                                                                                            Я в 2015 попал в такую ситуацию как у человека выше, никому не пожелаю.
                                                                                                            • 0
                                                                                                              Дожали?
                                                                                                              • 0
                                                                                                                Мне, видимо, повезло. В определенный момент звезды удачно сложились и я нашел свой путь. Но с тех пор зарекся уходить с работы, не найдя новую. Позволяет экономить здоровье (нервы) и деньги.
                                                                                                                • 0
                                                                                                                  зарекся уходить с работы, не найдя новую
                                                                                                                  Не считаете ли Вы такой подход предательством по отношению к текущему работодателю? Вам бы понравилось, если Ваша жена искала себе нового мужа, не подав сначала на развод?
                                                                                                                  • +1
                                                                                                                    1) Я — не считаю. Во всяком случае для иного подхода нужна как минимум очень мягкая «подушка», что бывает далеко не всегда. Да и вообще, при чём тут предательство? Это банальный прагматизм.

                                                                                                                    2) Так и было. Развод у нас случился только тогда, когда у обоих сторон наметились хоть какие-то перспективы. До того — понимали, что разводиться «в никуда» как минимум опрометчиво.
                                                                                                                    • 0
                                                                                                                      Не считаете ли Вы такой подход предательством по отношению к текущему работодателю?
                                                                                                                      А вы думаете, что работодатель при желании уволить вас не найдет сперва замену?
                                                                                                                      • –2
                                                                                                                        Я думаю, что практика «глаз за глаз» порочна, а практика «начни с себя» достойна.
                                                                                                                        • +2
                                                                                                                          Ага, «подставь другую щеку», и всякий другой христианский бред.

                                                                                                                          При чём тут месть? Это современные традиции бизнеса. Ваше дело после того, как нашли работу — отработать положенный срок, передав дела. Все.
                                                                                                                          • –2
                                                                                                                            Очевидно, у нас с Вами разные понятия о том, что такое хорошо, и что такое плохо. Продолжать бессмысленно.
                                                                                                                      • –1
                                                                                                                        Это не предательство — это рынок. В законе прописано уведомить работодателя за 2-4 недели (в зависимости от страны). Если вы выполнили это, то всё честно. Конечно, если за 2 недели перед сдачей проекта ушли «в отпуск с последующим увольнением», то это некрасиво и так делать не нужно… А в остальных случаях — всё ОК…
                                                                                                                        • 0
                                                                                                                          Мой вопрос относится к ПОИСКУ работы, а не к уведомлению после того как она найдена.
                                                                                                                          • 0
                                                                                                                            Так в чем проблема с поиском работы? Может я хочу найти офис, в котором ковры лежат по фен-шую и это у меня год займет
                                                                                                                            • –1
                                                                                                                              Ваше право. Только делать это следует, на мой взгляд, не за спиной у текущего работодателя. Fair play.
                                                                                                                              • +1
                                                                                                                                Я не против fair play, но почему-то если ты честно скажешь работодателю, что намерен искать другую работу, то тебя либо начнут гнобить, либо сразу уволят (а ипотеку платить всё ещё нужно и семью кормить тоже). Не может тут быть fair play…
                                                                                                                                • +1
                                                                                                                                  Что значит «за спиной»? В рабочее время втайне от работодателя делать этого не следует, конечно, а чем я занимаюсь в личное время моё, как ни странно, личное дело. Сознательно посвящать в это работодателя я даже моральных обязательств не имею, не говоря об юридических
                                                                                                                              • 0
                                                                                                                                Работодатель должен исходить из того, что он лишь работодатель в быстро меняющемся мире, а не рабовладелец в стабильном. Условно можно считать, что работники всегда ищут более подходящую им работу, пускай и с разной активностью.
                                                                                                                            • 0
                                                                                                                              Нормальная практика.
                                                                                                                              В мире ИТ предложение работы и выход на работу могут между собой растянуться и на 2 недели по закону и на месяц и на два. Вполне можно успеть передать дела.
                                                                                                                              • 0

                                                                                                                                А разве в договоре было что-то о "верности пока смерть не разулучит нас"? Трудовой договор — не брак. Или вы срочные трудовые договоры тоже считаете аморальными? И испытательные сроки...

                                                                                                                                • –1
                                                                                                                                  Я не говорю о верности одному работодателю до гроба. Я говорю о неэтичности смены работодателя без предварительного его уведомления об этом (сам работодателем не являюсь).
                                                                                                                                  Срочные договоры и испытательные сроки не считаю аморальными, потому что и то и другое делается открыто, а не за спиной.
                                                                                                                                  • 0
                                                                                                                                    Вопрос в том что некоторые работодатели действительно ведут себя неадекватно. Допустим запланировал ты поискать места получше в городе своем, постепенно, в течении года, никуда не торопясь, собирая информацию, сообщаешь об этом работодателю, а он возьмет и сразу попросит по собственному написать, или даже по соглашению, не очень важно. А ведь еще далеко не факт что вообще нашел бы место лучше, может быть поискал, нашел пару мест получше, заодно решил уточнить насчет повышения на текущем — и получил. А это было единственное преимущество найденных мест.
                                                                                                                                    • –1
                                                                                                                                      Смена работодателя без предварительного уведомления неэтична и даже незаконна в какой-то мере. Поиск нового работодателя разной степени активности вполне этичен. А если вы считаете, что нет, то расскажите, пожалуйста, с какого момента для вас начинается поиск нового работодателя и с какого заканчивается интерес к ситуации на рынке труда и своих перспекти на нём?
                                                                                                                                      • +1
                                                                                                                                        Поиск потенциального нового работодателя это не смена работодтеля. И если вы считаете что я морально обязан в такой ситуации оповещать своего работодателя, тогда пусть и он оповещает меня каждый раз когда просматривает варианты потенциальных новых работников, которые могут претендовать на моё место. Тогда это будет честно и морально.

                                                                                                                                        А пока я всего лишь обязан(как морально, так и юридически) сообщать моему работодателю о уже принятом решении сменить работу. И сделать я это должен в установленный законом срок.