Comments 520
О-нотация, это даже не базовые знания. Это базовый язык, на котором я могу объяснить, что этот кусок будет дико тормозить на больших данных, потому что N-квадрат, а надо лог N. Если что, я не в VK работаю.
я не помню, чем бинарный поиск отличается от линейного
Вот этим и отличается. У бинарного поиска O=log(N), у линейного O=N
Странно с такими пробелами претендовать на миддла.
Впрочем, не стоит расстраиваться. По собеседованиям полезно ходить, чтобы узнать про свои пробелы и эти пробелы закрывать. К десятому собеседованию уже будет представление, чего ожидают от вас.
Про BigO вынужден согласиться, за последние годы это стало мастхев даже на джуна.
А вот про сравнение алгоритмов поиска или сортировки... Не уверен, что помнить наизусть все реализации и их сложность это адекватная метрика. Я бы сказал, в таком случае стоит дать человеку два алгоритма и сказать - оцени сложность и сравни какой лучше. Все же, собственная реализация таких алгоритмов поиска или сортировки это не ежедневная задача для... да не для кого в общем то, неужели вы хоть раз в проект тянули не готовое решение этих вопросов из публичных репозиториев или средств языка, а сами реализовывали?
Про DNS сам не могу понять свое отношение. С одной стороны, у разработика необходимость с этим сталкиваться может годами не возникать, с дургой стороны, как сказал классик "Это база, Это знать надо". У меня понятие DNS навечно запечено горячим клеймом прямо на мозге со времен настройки ADSL интернетов во времена беззаботной юности и младших классов школы
Никто его не просил сравнивать, никто не спрашивал про реализации и сложности, никто не просил реализовывать... но, странно, не знать отличие линейного поиска от бинарного. И да, чтобы знать,что тянуть из публичных репозитариев, неплохо знать ключевое различие этого, а по хорошему еще и краевых случаев.
Чел мог просто растеряться и забыть, или пользоваться в посведневке иными терминами. Так, году в 2009-м меня не взяли по причине того, что не смог ответить на вопрос: "Что такое EAV?" .. оказывается это банальное продольное хранение данных, которым пользовался с 2001года "вдоль и поперек", а мой коллега так аж 1997года. Ктож знал, что какой-то Тенцер в 2004-м наклепал статью про этот подход и обозвал его Entity-Attribute-Value? :)
Это действительно странно выглядит, что человек настрадался с различными типами индексов в БД, редисом, но не знает как работает хэш таблица.
Про DNS сам не могу понять свое отношение. С одной стороны, у разработика необходимость с этим сталкиваться может годами не возникать
Мне, как системному адиминистратору, вообще непонятно, как может у программистов "годами не возникать необходимость сталкиваться с DNS". А мы потом сталкиваемся с захардкоженными IP-адресами в ПО, вот счастье-то какое.
У этой монеты есть две стороны. Админы приносят не меньше счастья разработчикам когда, спустя часов 5 диагностики и уверений что никто ничего не трогал, вскрывается что все таки в DNS своими шаловливыми руками кто-то залез или изначально криво настроил.
Ну, ваш пример про хардкод - это из другой оперы, которая называется "а нафиг нужно выносить параметры, если можно быстренько накидать вот так". А про DNS - лично я встречал разрабов, которые не в курсе что это такое, как и в принципе модель OSI. Будучи по образованию безопасником и по текущей профессии абапером когда-то собеседовался на бэкэндера с нулевыми знаниями веб разработки. Интервьюер сказал, что даже с моими малыми знаниями у меня их больше, чем у выпускников программной инженерии. Также из личного опыта работы сложилось мнение, что в некоторых местах уровень знаний разрабов сильно ограничивается их текущими задачами (не всегда по их вине), из-за чего даже когда-то имея знания о каких-либо технологиях человек эти знания утрачивает со временем. Поэтому вроде как с одной стороны он не знает базу, которую должен знать любой джун, а с другой стороны он и правда на текущем месте может быть отличным спецом. Я вот как абапер комплексную по поводу отсутствия знаний по многим темам (тот же гит и системы контроля версий), потому что это все берет на себя сап, из-за чего нет даже потребности в каком-либо контроле версий (это один из примеров, есть ещё куча других вещей, которые на себя берет платформа).
Мне, как системному адиминистратору, вообще непонятно, как может у программистов "годами не возникать необходимость сталкиваться с DNS"
Александр, а мне вот, как программисту, хоть и ненастоящему, совершенно понятно, как у программистов годами не возникает необходимость сталкиваться с DNS (особенно - именно с DNS). Программисту ведь достаточно того, что есть некая служба, которая преобразует имя сервера в сети в его сетевой адрес, с которым сетевые службы устанавливают соединение. А настройкой этой службы (а то и вообще вопросом, что там за служба используется) занимаются уже специально обученные люди.
Программисту даже необязательно знать, как там сетевой адрес протокола внутри выглядит. Я, к примеру, так и не удосужился узнать, как там внутри выглядит адрес протокола NetBIOS Frames, при том, что в своих программах, работавших c БД на сервере Interbase, я этот протокол некоторое время активно использовал. Правда, имя сервера (не говоря об адресе) указывалось не прямо в моей программе а в псевдониме IDAPI (она же BDE), но это мало что меняло: ответственность на создании образца псевдонима IDAPI была на программистах, а эникейщики просто настраивали ПК пользователей по этому образцу (обычно - копированием файла конфигурации, но бывали нюансы).
А вот за жестко прописанное в прграмме (а не вконфигурации) даже имя сервера, не говоря уж о его адресе, программистам таки надо действительно давать по башкеставить на вид.
PS Ну да, я тоже много работал системным администратором (и, возможно вы меня помните в этом качестве по Зеленому), и как бороться с DNS знаю хорошо. Но это - потому что я работал администратором сетевой инфрасруктуры предприятия (AD, Exchange и пр.) - там да, без знания DNS (причем, с весьма глубоким погружения в ее специфику) работать просто невозможно. Но это - совсем другая профессия IMHO (впрочем, изначально мне пришлось совмещать ее с программированием).
Плюсую и докину аргументов. Сейчас информации так много что специалист в одной сфере может шарить очень хорошо, а в другой - поверхностно, и вот это "поверхностно" может придать излишней уверенности в своих силах и человек напортачит, а ошибка всплывёт в самый неожиданный момент.
Вот вчера было. Я админ одной широко известной системы уже 15 лет, осертифицировался, знаю подноготную от и до. У нас есть юзеры с админскими правами в подсистеме, такие часто выдаются продакт менеджерам. Попросили меня настроить их проект. Я всё сделал по фен шую. Полез продакт и переделал так как он видит. В итоге подсистема не работает. Он жалуется своему начальнику что всё сломалось. Тот идёт к моему начальнику. Полчаса времени четырёх высокооплачиваемых специалистов на выяснения отношений. А если бы он сразу признал что ничего не понимает в подсистеме и сказал мне что ему надо - заняло бы 5 минут одного человека. То есть в 24 раза эффективнее.
Когда меня на собеседовании спрашивают про что-то не относящееся к вакансии я сразу отвечаю что кое-что могу но не стану, потому что есть более грамотные специалисты чем я. О-нотация понятно, это в школе проходят. Но все тонкости настройки ДНС это тонкий лёд где легко огрести проблем - пусть этим занимаются сетевики, а не программисты. А если нет сетевика - тем более не нужно ничего выдумывать, лучше загуглить ответ на профильном сайте.
Господа, ну вы же немного передёргиваете. В статье ни слова не написано про тонкости настройки или детали реализации.
Если я правильно прочитал, вопрос был конкретно "что такое DNS". Не оправдываю интервьюера, который мог бы и по другому сформулировать вопрос. Но всё-таки знание концепции, как именно мой компьютер находит в сети условный гугл, это важное умение для любого технического специалиста.
О-нотация понятно, это в школе проходят
Вы учились в СССР или в 2000-х? Потому что в девяностых точно не проходили. Если первое, то понятно, почему ругают нынешнее образование, а если второе, то не понятно, почему ругают, если там даже такое проходят. А вообще говоря, вдалбливать школьникам про сложность алгоритмов — это как всем школьникам насаживать умение программировать. Зачем всем, если кто-то из них будет работать мясником, водителем автобуса или точить садовый инвентарь? С той же аргументацией можно всех обучать работать на фрезерном станке и различать номиналы резисторов по полоскам.
Независимо от того, что это может быть полезно и перенастраивает мозги, оно всё равно неминуемо забудется. Я на PHP писал в течение 10 лет, но прошло лет 6, а я уже сомневаюсь, как там в классах переменные создавать, нужно ли писать запятые, точки с запятой, нужен ли знак доллара, писать ли значения через двоеточие или знак равенства, как статические "переменные" задавать (даже не помню, как это называется, свойства что ли?), какие у классов есть магические методы.
С такими рассуждениями придем к тому, что в штатах практикуется - "мне это не надо, я это учить не буду". Наше образование дает большой кругозор. Когда человек учит только то, чем дальше собирается заниматься и абсолютно забивает на всё остальное - это очень плохо сказывается на способностях видеть "картину в целом". Кому-то география никогда в жизни не пригодится, а кому-то физика или химия, но это же не повод их не учить в школе, потому что иначе высшие чины заявляют на пресс конференциях что отправляют эсминцы к берегам Белоруссии и распространяются видео о том, что снежки от огня не таят потому что снег на планете поменили рептилойды. Ну вы поняли.
Я не против того, чтобы школьников учить тому, что одни алгоритмы эффективнее других, и что эффективность измеряется только в конкретном контексте применения. Но учить математически это оценивать — для чего? Профдеформация какая-то, "если я это знаю, то все обязаны это знать".
Пример со мной: я смотрю научпоп про астрономию, астрофизику и квантовую механику, но мне это нужно для общего образования, поэтому я не знаю ни одной формулы (кроме формулы для тяготения, ещё из школы). Вот так на словах школьникам можно рассказывать про разное. Но уж точно не стоит заставлять их запоминать, какая страна каким морем омывается, и какой там часовой пояс.
Сейчас слушаю, как Панчин рассказывает, что на древнем астероиде нашли 5 оснований, из которых строятся ДНК и РНК (но я это уже слышал от Масленникова), из этого делаю вывод, что ДНК-основа жизни — это более фундаментальная вещь, чем "так случайно получилось", что согласуется с докладом в рамках SETI, который я смотрел раньше, из чего следует, что внеземная жизнь, видимо, будет основана на ДНК, так как у химии не особо много вариантов выбора. Я вроде бы могу перечислить эти основания (пятое — это ж урацил, да?), но даже не представляю, из чего они состоят, и не отличу одно от другого, потому что я не погружался до уровня формул.
Да его же не спрашивали про устройство DNS и протокола TCP/IP. Можно было хотя бы базовыми словами ответить: "Система доменных имён, которая позволяет преобразовать домен в айпишник".
Это просто проверка на то, что человек хоть чуть-чуть вылезает за пределы ide и интересуется тем, как магические коробочки, называемые компьютером, таки работают.
И да, если он ни разу не загуглил ради интереса что такое DNS_PROBE_FINISHED_NXDOMAIN в хроме или не настраивал свой роутер/впн, где всегда есть опция по DNS, то какой он вообще программист?)
И да, если он ни разу не загуглил ради интереса что такое DNS_PROBE_FINISHED_NXDOMAIN в хроме
Ни разу не загугливал, потому что хром ни разу ему такую ошибку не выдавал?)
Ага, а если и выдавал, то он не вчитывался и просто говорил "давай работай интернет грёбаный", перезагружал роутер и всё чинилось.)
Ну в крайнем случае звонил в техподдержку провайдера, когда уже три раза ребутнулся, перезагрузил ОС, а хром всё равно не открывает чатжпт, которого можно было бы спросить что же с этим делать.
Я оттого оставил свой комментарий, что реально в своей недолгой жизни ровно 0 раз жизни видел такую ошибку) Да и для настройки VPN'а какие-то настройки связанные с DNS руками нынче вводить не нужно. Настройка роутера... ну да, давным-давно - было необходимостью, в инструкции от провайдера провайдера обычно был такой момент, но нынче часто и этого не нужно.
И я не оправдываю отсутствие любопытства, но в реальной жизни действительно можно ни разу не столкнуться с проблемами с DNS и прекрасно себя чувствовать.
"есть некая служба, которая преобразует имя сервера в сети в его сетевой адрес, с которым сетевые службы устанавливают соединение."
Как я понимаю, примерно такой ответ и ожидался.
как может у программистов "годами не возникать необходимость сталкиваться с DNS"
У меня вопрос строго противоположный, а что там делать с DNS? Есть служба которая имя в адрес преобразует, а как оно там работает, да черт его знает. Разработчик вполне возможно ни разу в жизни это не настраивал ни на работе, ни дома. Я, к примеру, ни разу в жизни не обжимал витую пару, что теперь)
А мы потом сталкиваемся с захардкоженными IP-адресами в ПО, вот счастье-то какое.
А это вообще причем?
У меня вопрос строго противоположный, а что там делать с DNS?
Если нужен пример из практики то например натыкались на проблемы резолвинга в образе myalpine(mysl). Он резолвит через udp, и не полностью поддерживает стандарт. По итогу если ответ от сервера >512b то можно сказать "потрачено". Если про DNS не знать то можно долго хвататься за голову с мыслью "а че здесь собственно происходит?".
Да и вообще между "а что такое DNS?" и "могу написать аналог Bind 9 на ассемблере с закрытыми глазами" очень много промежуточных вариантов. Крайности всегда плохо.
Если про DNS не знать
Тут конечно неплохо бы расшифровывать термин "сталкиваться с DNS", одно дело не знать в смысле "первый раз слышу такой набор букв", другое дело не знать в смысле "не знаю как настраивать на древней версии линуха".
Да и вообще между "а что такое DNS?" и "могу написать аналог Bind 9 на ассемблере с закрытыми глазами" очень много промежуточных вариантов. Крайности всегда плохо
Согласен. Меня как-то сильно удивила категоричность в смысле "вообще непонятно". Ну пишет кто-то бэк, десктоп, базовщину, кады какие-нить, ну какой там DNS?
Ну так автор задал тему этому разговору: "не знал что ответить на вопрос: что такое DNS". Отсюда и пошло обсуждение.
Никто вроде в ветке не писал что нужно знать RFC от корки до корки, скорее наоборот.
В принципе, если речь про хайлоад, то про DNS как раз лучше бы вообще не знать, ЕВПОЧЯ. )
Всё что связано с DNS может (должно) быть вынесено в отдельный модуль который будет делать человек который не только RFC от корки до корки знает, но и знает все известные угрозы и наиболее известные костыли от крупных провайдеров которые на RFC клали с прибором.
раз образы и альпайн взяли, в докере и прочих куберах, вполне себе внутренние dns имена используются и надо хоть базово понимать почему и как мы обращаемся к сервисам внутри них
это конечно больше уже в сторону девопсов, но сейчас базовое понимание ci/cd и основы знаний как собрать локально стенд, уже требуется на миддл должностях
Программисту достаточно знать, что все сетевые сервисы должны иметь hostname, а чтобы эти hostname появились и были доступны только там, где нужно, как раз и есть админы.
Откуда-то у этих хардкодеров эти ip же появились изначально. Едва ли они сами сервер настраивали, если это, конечно, не микробизнес.
Программисту достаточно знать, что все сетевые сервисы должны иметь hostname, а чтобы эти hostname появились и были доступны только там, где нужно, как раз и есть админы.
если человеку прям совсем не интересно как оно там под капотом работает, то imho это фиговый специалист, который настраивая например локальное окружение будет по каждому вопросу к девопсу бегать?
Если по каждому вопросу интересоваться, то это будешь днями документацию читать вместо работы, а запомнить всё невозможно.
Главный навык разработчика - уметь искать и понимать информацию, с появлением llm это стало как никогда просто. Так что при необходимости со всем можно разобраться.
Но вот специально всё подряд изучать может быть и полезно, но далеко не все хотят всё свободное время на это тратить. А в рабочее, как правило, есть чем заняться и так.
Если по каждому вопросу интересоваться, то это будешь днями документацию читать вместо работы, а запомнить всё невозможно.
удивительно, почемуто я знаю и как DNS/ARP/TCPIP..и прочие страшные слова из OSI работают, при этом программист...недавно вот читал что такое FiberChannel и почему оно не через оптику может работать и всёравно оставаться fiber...крайне познавательно...когда я был админом меня очень интересовало в чем разница между FC/SAS/SATA дисками например и как работает iSCSI...и вообще копание в эту сторону очень облегчает понимание инкапсуляции на реальных кейсах..вне классов и объектов в программинге
не нужно знать досканально, надо знать образно и куда заглянуть для подробностей... мне не совсем понятно почему другим ИТшникам это не интересно, это же блин основы
Я узнал как называются алгоритмы поиска и сортировки лет через 15 после их фактического использования. Узнал кажется тут на хабре в комментариях к постам про собеседования.
Конечно терминологию хорошо бы знать, но что-то я сомневаюсь что к ним такая очередь, что незнание пары терминов достаточный повод для выкидывания кандидатов.
В принципе, это тысяче первое подтверждение того, что навык работы и навык прохождения собеса слабо пересекаются. Особенно в "бигтехе".
same story, про знания терминов, да …
только в моем случае по юности я некоторым алгоритмам вообще придумал свои названия (порой даже забавные)
Думаю, из тех кто не может ответить на вопросы из статьи - именно что очередь.
Да, можно некоторых терминов не знать или забыть, волноваться, все дела. Обычно в таких ситуациях интервьюер начинает подходить к вопросу с другой стороны, например определяет понимание темы через какие-то практические примеры.
Косвенно можно предположить, что в статье это и произошло:
Интервьюер: что такое О-нотация знаете?
Кандидат: первый раз слышу
И: ну давайте попробуем понять какой алгоритм поиска будет "сложнее в исполнении" линейного поиска или бинарного
К: я не знаю таких алгоритмов, что за чушь вы ваще спрашиваете?
И: я подскажу. При линейном поиске мы в общем случае должны в цикле пройти по всем элементам массива, а в как будет осуществляться поиск, если данные у нас не в массиве а в отсортированном дереве?
К: видел деревья в лесу, перестаньте давить на меня и морочить голову. Давайте перейдем уже к нормальным вопросам
К слову о деревьях. Я понимаю, что это односвязный граф, где от каждого элемента, идя по "предкам", можно дойти до единственного общего предка. Но что считать отсортированностью в такой структуре, это можно узнать только читая соответствующую литературу. Я, например, не представляю. Односвязные списки, кроме литкода, использовал раз в жизни, ради прикола. Так бы обычным массивом обошёлся, но в него сложно добавлять что-то в середину, а мне нужно было сделать драг-н-дроп внутри списка элементов на странице.
Но я и не претендую на работу в корпорациях.
// Если мне показать пример отсортированного дерева, то я пойму и смогу придумать что-то с поиском.
Двоичное/бинарное дерево можно описать как "есть начальная вершина-корень, в каждой вершине записано значение, и у каждой вершины могут быть левый и правый потомок"
Отсортированное дерево - то, в котором у каждой вершины - все элементы левого потомка и его потомков меньше элемента в вершине, а все элементы правого потомка и его потомков - больше элемента в вершине.
Или [на Википедии](https://ru.m.wikipedia.org/wiki/Двоичное_дерево_поиска) прочитать
Понял. А поиск начинаем с вершины, судя по логике? Дерево ведь задано только ссылкой на вершину, если я правильно понимаю ситуацию.
А поиск начинаем с вершины, судя по логике
Да. И у отсортированного дерева так как все элементы слева меньше ноды, все справа больше, идем по логике. "Я ищу элемент с ключом 10, у ноды (изначально корень), значение например 5, 10 > 5, значит надо правую ветку взять, там у ноды какое значение? 15? 10 < 15, идем влево значит" повторяем пока не найдем что ищем (или ничего не найдем)
Ну, это уже тривиально. Получается аналогия двоичного поиска по массиву.
Достаточно много алгоритмов и структур данных очень логичных и простых (в красно-черных деревьях тоже ничего такого, по сути пара несложных правил которые позволяют дереву быть всегда сбалансированным, а красно-черные они всего лишь потому что надо было ноды классифицировать как то, а издательство которое печатало статью могло печатать только черными и красными чернилами), стоит только реально открыть книжку/сайт, прочитать и подумать немного над тем что читаешь, во многом остальное уже специфично, на интервью врятли встретится, в обычных книгах по алгоритмам тоже скорее всего не будет и уже разбирается по мере надобности.
По этому меня и удивляет количество программистов (как минимум на хабре) которых только упоминание алгоритмов/структур данных/литкода вводит в ступор.
Дык никто и не говорил, что это сложно. Наоборот, про топикстартера удивляются, ведь это довольно простые вещи.
Помните байку про "разработчика brew не взяли на работу в гугл, потому что там на собесе требуют неадекватных теоретических вещей вроде разворота бинарного дерева"?
Поздравляю, прямо сейчас вам хватает знаний о деревьях, чтобы сделать именно то, о чём этого разработчика просили.
Вот у вас было дерево у которого все элементы в левом поддереве меньше значения в корне, все элементы в правом поддереве больше значения в корне и то же самое выполнено для всех потомков.
Нетрудно догадаться, как написать код, который сделает наоборот (все элементы в левом - больше, все элементы в правом - меньше, и так для всех потомков вниз). Тут прямо вообще нет подвоха.
Ура, вы научились решать ту самую страшную задачу тех самых неадекватных собеседующих. Не так страшен черт, как его малюют.
(Нет, про повороты деревьев как в красно-черном в той истории речи не шло, это популярное народное развитие этой байки, возникшее потому что - ну не могли же в той истории про страшные вопросы спрашивать такие тривиальные вещи)
прямо сейчас вам хватает знаний о деревьях, чтобы сделать именно то, о чём этого разработчика просили
Нет, не хватает. Что такое разворот применительно к дереву? Когда я давно читал про разворачивание списков, я думал, что эти списки там как-то свёрнуты, а их нужно развернуть, это как распаковать. В какой-то момент я понял, что нужно всего лишь поменять порядок связей в списке на обратный. Но в дереве?
А, так дальше есть объяснение.
С точки зрения математики, нужно всего лишь переопределить термины "лево" и "право" :)
А вообще, я не могу сходу предложить качественный алгоритм такой замены, кроме как собрать всё в массив и разбить заново.
А вообще, я не могу сходу предложить качественный алгоритм такой замены, кроме как собрать всё в массив и разбить заново.
Ну, вы в некотором роде половину решения уже озвучили - надо просто поменять местами лево и право.
Что-то в таком роде.
f(узел):
поменять местами левого и правого потомка
Если левый потомок не пуст - вызвать f(левый потомок)
Если правый потомок не пуст - вызвать f(правый потомок)
Мой поинт в том, что по какой-то причине довольно простые вещи в сообществе часто почему-то воспринимаются (и разносятся байками) как какие-то задачи-гробы нерешаемые ("деревья вращать!11") или как что-то требующее зубрения ("сложность операций в коллекциях языка требуют заучить!1").
Конечно, бывает, что это действительно нечто неадекватное - в соседней ветке комментариев вот человек говорит, что у него на собесе спрашивали красно-чёрное дерево. Я такого не встречал, но неадекваты-собеседующе - бывают.
Но гораздо чаще - когда копаешь эти страшные истории чуть глубже, оказывается, что спрашивали довольно простые вещи на понимание, к которым к тому же можно довольно быстро подготовиться.
В отсортированном дереве, в каждом узле значение левого потомка меньше, чем в зафиксированном, а в правом больше
Вообще-то это не "программерское", а больше чисто математическое и даже "матановское" понятие О-малое, О-большое.. Отсутствие знаний говорит только лишь про отсутствие базовой математики у претендента, которая нужна далеко не всем и не всегда, даже сеньорам.
У меня нет "базовой математики", но я читал книги, а в любой книге про алгоритмы и во многих по языкам программирования есть про О-нотацию.
Так в книгах про алгоритмы, алгоритмическая сложность есть основа. Не удивительно, что там это есть. Но .. Вы точно уверены, что автор в курсе наличия книг по алгоритмам? (Кнута на вас нет!) если он не различает бинарный поиск от пузырька?
Интересно, в какой книге по алгоритмам нет бинарного поиска?
Видимо, я слишком стар и не поспеваю за новыми веяниями, но меня очень удивляет, что человек может стать программистом, не прочитав ни одной книжки, а тем более добраться до мидла в хайлоад проекте.
Ну, понятие "хайлоад" сейчас довольно расплывчатое. 50k rps - может быть и очень мало и очень много, смотря какие запросы.
Сейчас понятие хайлоад немного не про бирарный поиск или про сортировку пузырьком, а про балансер или шардирование через оркестратор. Ну или failover накрайняк (но я не фанат).
Я php не знаю, но думаю там уже есть open source решение которое содержит разнообразные реализованные методы сортировки, которые протестированы, опробованы и с подробными инструкциями при каком сценарии что лучше использовать.
Вы точно уверены, что автор в курсе наличия книг по алгоритмам?
Вот собеседующий и выяснил это одним простым вопросом.
В любой статье на хабре про собеседования есть про о-нотацию :).
Слушайте, когда я только начал изучать программирование, я буквально в первых же книгах и статьях столкнулся с асимптотической сложностью алгоритмов. При том что я самоучка. Как программист может этого не знать, я не очень понимаю.
Ну, я сталкивался, но так и не запомнил, как там что считается. Я просто понимаю, что цикл в цикле — это дольше, чем один цикл. Могу даже сходу сказать, что зависимость квадратичная. А вот если второй цикл прерывается один раз на первом элементе, второй раз на втором, третий — на третьем, то я даже с листочком и ручкой не смогу сказать, какая это зависимость. <N умноженное на арифметическую прогрессию>, что-то такое.
Это незнание не мешает избегать вложенных циклов там, где можно их избежать. А так как мой код работает в браузере, то я могу хоть лишних 100 мс потратить или задействовать на мегабайт больше оперативки. Оперативки на то и нужна, чтобы её использовать, а вряд ли будет какое-то устройство, где не найдётся 1 МБ. Дело не в том, что я нарочно буду это делать, просто, мне приятнее написать [].forEach() или [].some(), чем гонять for(;;). За последние лет 5 я for использовал только на литкоде.
Мне для общего развития, чем [].forEach() и for(;;) отличаются?
ФорИч не позволяет выйти раньше.
Грубо говоря, там нет break
Из forEach можно выйти по return
получается "... я for использовал только на литкоде" так себе предмет для гордости )
Он мне кажется слишком многословным. Если я буду вместо каждого .filter, .map, .every, .some, .forEach писать for(), то, во-первых, не смогу делать цепочки, а во-вторых, придётся вчитываться в этот for, чтобы понять, что внутри творится, тогда как .every заранее говорит о том, что будет происходить.
Не говоря о том, что для map нужно будет подготовить пустой массив, заполнить его, потом всё переприсвоить.
Там же внутри ещё одна функция создаётся
Это если нет условий выхода или условий отсечения. На leetcode метод отсечений ветвей в задачах реализуют именно через двойной цикл (цикл в цикле). И получают либо O(n) либо логарифм. (Обычно, такая сложность возникает при работе с двоичными данными, aka строка битов).
"А вот если второй цикл прерывается один раз на первом элементе, второй раз на втором, третий — на третьем..." - то в итоге всё равно будет сложность O(n^2) квадратная. Потому что по формуле арифметической прогрессии получаем сумму элементов как
S = n * (n + 1) / 2
В итоге будут два переменных множителя с константой (const = 1/2)
n * (n + 1) * 1/2 => n * (n + 1) * const. => n * n => O(n ^ 2).
Тут всё просто, внутри О лежит именно функция, а не число.
Я просто понимаю, что цикл в цикле — это дольше, чем один цикл
Не всегда. Вот алгоритм решета Эратосфена, работающий за линейную сложность, хоть там и 2 вложенных цикла.
если второй цикл прерывается один раз на первом элементе, второй раз на втором
И там сложность будет такая же квадратичная. На самом деле будет N^2/2 итераций, если арифметическую прогрессию.
[].forEach()
И еще какой-нибудь find/contains там внутри навернуть, или что там у вас есть, которое внутри по всему массиву бегает. В результате на ровном месте получаются квадратичные алгоритмы и без вложенных циклов.
Надо все-таки уметь оценивать сложность.
Если нужно делать .find для каждого элемента в цикле, то этого всё равно не избежать, даже если сверху будет for().
У меня массивы на единицы, иногда на сотни элементов. Не десятки тысяч, в браузере мне на моей работе (тут делаю акцент) не приходится такие огромные данные перебирать. Запрос данных с сервера всё равно займёт больше времени, чем я буду их перерабатывать, хоть бы даже четырьмя вложенными циклами.
Если нужно делать .find для каждого элемента в цикле, то этого всё равно не избежать,
Можно отдельным проходом все элементы запихать в какую-нибудь хеш-таблицу, и уже там вместо find в массиве за O(1) проверять в основном цикле. Его тоже можно сделать как forEach.
У меня массивы на единицы, иногда на сотни элементов.
Ну вот уже кусок кода можно ускорить в несколько, иногда в сотни раз.
Запрос данных с сервера всё равно займёт больше времени, чем я буду их перерабатывать
Так на бакенде же тоже самое.
Сходил по ссылке
Я хлебушек. Если бы я и смог продраться через подобные выкрутасы, то те времена прошли 20 лет назад. Я даже не уверен, что там понимают под фигурными скобками, массив, множество, или ещё что похлеще. Просто поверю, что такой алгоритм есть, но я крайне сомневаюсь, что сам буду такое писать, и что мне придётся выбирать между разными вариантами. И уж точно я не смогу определить сложность чего-либо, чтобы сравнить их между собой. Я осознаю свой уровень и уровень решаемых мной задач. Внутри того, что я делаю, я могу интуитивно определить, что будет работать быстрее, без явного выведения формул для N.
Матан - это же не базовая математика. Вот школьная алгебра - да, базовая 😅
Я кандидатскую защитил по матану, и мне бы в голову не пришло, что "О-нотация" это про это.
Я ни разу, нигде, никогда не встречал термин "О-нотация", в моей литературе либо употреблялся термин "big O", либо не употреблялся никакой, сразу писали, там, O(n log n), без слов понятно. Нотаций вида O=log(N) и O=N, кстати, тоже что-то не припомню. Увидав это "О-нотация" в тексте, думаю, догадался бы, о чём речь, а вот услышав в устной речи, да ещё с маасковским аааканьем, думаю, запросто можно не вдуплить. Спросили бы, там, как оценивается асимптотическая сложность алгоритма, посмотрели бы, напишет фигурант им это O или нет.
Отдалённо похожий случай, ещё как-то спросили что-то вроде: "А какой самый худший способ синхронизировать процессы?" Сама постанова несколько безумная: "Давайте, скажите, какой по-вашему, я за минуту придумаю хуже." Выяснилось, что имели ввиду busy waiting, с каковым термином я на тот момент тоже не сталкивался - пару раз в статьях для обозначения этого явления встречалось слово "polling", а обычно ничего не встречалось, и так понятно, что не надо так делать, если есть альтернативы.
А какой самый худший способ синхронизировать процессы?
Ответ был используя time.Sleep()?
Можно сделать ещё хуже - например, вообще их не синхронизировать. Можно и ещё хуже - вместо синхронизации майнить биткойны, воровать пароли и рассылать трояны. Нету дна.
Мне кажется, это уже демагогия. Вопрос был про "худший из способов синхронизации". Есть проблема. Есть решения проблемы. Решения могут быть разные. Вопрос к выбору худшего решения. Отсутствие решения (не синхронизировать) и усугубление ситуации (майнить битки) не является решением. Понятное дело что намеренное вредительство будет хуже любого решения, но вопрос про решения, а не про вообще что может быть хуже в данной ситуации.
[active pooling] ... и так понятно, что не надо так делать, если есть альтернативы.
Ну да - расскажите это людям занимающимся синхронизацией. Ну например писателям ядра линукса.
Теперь уже практически любой лок работает так:
1. Некоторое время T ждём на спинлоке (это фактически active pooling)
2. Потом снимаемся с процесса и ждём на примитиве ядра.
Для спин-лока просто время T большие чем для мьютекса.
Ну например писателям ядра линукса.
А им там просто ничего не остается, кроме спинлоков: прочие примитивы синхронизации - они в другой реальности, на другом слое, в который нельзя просто так взять и обратиться. Не скажу за Linux, а для писателей драйверов Windows, в части обработчиков прерываний, это - обычная беда: если они будут лезть в вышележщий слой, то быстро STOP 0x0A (IRQL not less or equal) словят. Но в Windows, хотя бы, полная асинхронщина есть (и была изначально в ядре), и можно такие штуки, где нужна синхронизация, запускать асинхронно - DPC в очередь поставить (там примитивов синхронизации, вроде как, доступно больше), а то и в APC вынести (там вообще полная свобода использовать примитивы ОС - они в слое ниже реализованы). А за Linux современный не скажу, куда и сколько там асинхронщины завезли (изначально там был вообще Big Kernel Lock, т.е. один спинлок на все ядро, но это было совсем давно). И да: pooling у вас следует по смыслу читать как polling (т.е. - опрос).
Теперь уже практически любой лок работает так:
Это если вы используете какой-нибудь язык с навороченной средой выполнения, типа C#, или библиотеку. На голом C(++) надо или самому делать такие вещи, или пользоваться тем, что в ОС есть.
А им там просто ничего не остается,
Остаётся, и я это явно описал в своём ответе.
Спин лок через какое-то время просто кладёт просит кладёт воркер в очередь фьюекса.
Мьютек тоже сначала крутится на спин-локе, а потом кладёт pid в очередь фьютекса.
В том-то и дело, что из-за существования временной локальности (ровно то, благодаря чему кэши приносят пользу) - идея "покрутиться на спин-локе" / "чуть-чуть поделать active pooling" - достаточно разумная.
Ну, значит, то, что в Linux называют spinlock - это не то, что всегда было принято называть этим словом.
Традиционный spinlock, вообще работает без помощи планировщика - просто опрашивает в цикле содержимое ячейки памяти. А у вас он что-то кладет в каую-то очередь. Кстати, в многопроцессорной системе нельзя просто взять и что-нибудь положить в совместно используемую структуру данных. Допустим, для работы конкретно с очередью (простой) алгоритм на атомарных операциях есть, но наверняка ведь имеются и такие струткуры ядра, для согласованного доступа к которым атомарными операциями не обойдешься - вот для них как раз и используется тот самый традионный spinlock, и вот там альтернатив нет.
Короче, я выяснил, что мы тут говорим о разных вещах, называемых одним и тем же словом.
PS Посмотрел я статью в Википедии про futex.Там почему-то пишут что это - примитив для прользовательского пространства. Поясните тогда, что-ли, причем тут ядро, которое вы упомянули.
Ещё раз про главное: моя мысль, с конкретным примером, что говорить "active loop" отстой - это крайне поверхностное суждение.
0.
смотреть лучше не futex, а: https://en.wikipedia.org/wiki/PREEMPT_RT - теперь этот режим основной в linux Kernel.
1.
Про futex есть два понятия: "Computer Science примитив futex" и "linux/futex.h :: futex". Вот первый я имел в виду когда говорил во что spin_lock развернётся - забыв что вы из мира Win и по контексту не поймёте.
2.
Сейчас spin_lock (примитив ядра), разворачивается через 10 слоёв абстракций в очередь ждущих воркеров и снимается с CPU (в режиме PREEMT_RT который сейчас включен по-умолчанию, разумеется там ещё 100500 действий типа повышения приоритета и т.п.).
3.
Т.е. по-сути сейчас:
- spin_lock (примитив ядра) - покрутится на active loop и уйдёт в preemption (*)
- mutex (примитив pthread) - покрутится на active loop и уйдёт в preemption
*) В реализации по-умолчанию, если вы не заблокировали irq && preemption......
Ещё раз про главное: моя мысль, с конкретным примером, что говорить "active loop" отстой - это крайне поверхностное суждение.
А я с этим согласен. Потому что обращение к ядру, да ещё и с последующим переключением контекста на какой-то другой поток (а то и процесс) - операция весьма дорогая, на коротких промежутках времени выгоднее на ней сэкономить, даже за счет того, что некоторое время процессор ничего полезного делать не будет. Но дьявол, как всегда - в деталях.
смотреть лучше не futex, а: https://en.wikipedia.org/wiki/PREEMPT_RT - теперь этот режим основной в linux Kernel.
В Linux лучше всего вообще без особой на то нужды ничего не смотреть: там вокруг любого нововведения всегда поднимается шумиха (потому что open source - он не про деньги, а про авторитет, который нарабатывается как раз шумихой), за которой рассмотреть чисто техническую сторону сразу сложно. А нужды у меня сейчас нет.
забыв что вы из мира Win и по контексту не поймёте.
Ну, я из мира не только Windows, много чего в жизни было. В частности, межпроцессное взаимодействие(и синхронизацию в частности) я изучал по теоретической книже (не Танненбауму, который, кажется написал свою книгу позже, а некому Шоу - переводили такую книгу в СССР). И на Unix'овский ipc того тамошнее изложение не совсем ложилось, так что не знаю, было ли там описание на примере чего-то реального, но не Unix, или же - чисто теоретическое. Так что к терминологии я привык к тамошней. И линуксовскую терминологию без контекста не понимаю, да.
spin_lock (примитив ядра) - покрутится на active loop и уйдёт в preemption (*)
В той исходной версии примитивов синхронизации, которой я учился, термин spinlock понимался однозначно: зацикливание процессора на опросе, пока другой процессор не освободит ресурс. И в Windows NT изначально был только такой spinlock. Потом появился spinlock с очередью, похожий на то, что вы ту про Linux написали, но про него я мало что знаю, а кроме того, в описанном мной случае - в процедуре обработке прерывания (IRQL>DISPATCH_LEVEL), где обращаться к планировщику запрещено, его использовать всё равно нельзя, ну а ещё сечас есть (когда появился - не отследил) системный вызов, который , по описанию, совмещает с захваотом spinlock постановку в очередь для продолжения обработки DPC (это отложенная процедура, которая работает как раз на IRQL=DISPATCH_LEVEL, т.е. на том же уровне, что и планировщик).
Короче, мы говорили о разных spinlock и спорить тут дальше не о чем. А изучением ядра - хоть Linux, хоть современной Windows (там за прошедшие три с лишним десятка лет после выпуска NT много чего дополнительно появилось) мне заниматься неинтересно: работе c интересующим меня в текущий момент ASP.NET Core оно вряд ли поспособствует.
Теперь уже практически любой лок работает так:1. Некоторое время T ждём на спинлоке (это фактически active pooling)2. Потом снимаемся с процесса и ждём на примитиве ядра.
> Это если вы используете какой-нибудь язык с навороченной средой выполнения, типа C#, или библиотеку. На голом C(++) надо или самому делать такие вещи, или пользоваться тем, что в ОС есть.
Слушайте вы даже не поняли, что это описание работы spin lock (из linux kernel) и mutex (из pthred).
Рассказываете "как на самом деле" работают блокировки.
О-нотация, это даже не базовые знания. Это базовый язык, на котором я могу объяснить, что этот кусок будет дико тормозить на больших данных, потому что N-квадрат, а надо лог N.
Это вообще никак не связано. Классический N+1 может быть на порядки быстрее, чем O(1), тупо потому что выбирает из UoW/кеша по индексам, а не улетает на реплика сет в Тайвань в виде SQL запроса на полтора мегабайта.
Все эти О-нотации нужны исключительно олимпиадникам на собеседованиях и на микрооптимизациях в крайне редких и частных случаях. Так как даже на микрооптимизациях скорее лишняя аллокация будет тормозить...
P.S. Конечно же это имхо. За всю практику ни разу не воскликнул: "О боже, да тут же log N! А можно до 1 сократить". SQL N+1 не считается, это классика)
ну такие вещи стоит знать хотя бы для общего развития, чтобы при выборе наиболее оптимального алгоритма можно было как-то сравнить. Ну грубо говоря, чтобы чел, знающий про О-нотацию, но не знающий алгоритмов сортировки мог быстрым гуглежом найти более оптимальный не вдаваясь в реализацию
Для общего развития - конечно. Как и про устройство CPU, про вентили, про сумматоры и прочее. Но одно дело общее развитие, а другое практика. И вот на практике - доскональное знание xhprof/memprof/xdebug/etc, очевидно (по-моему), на порядки профитнее.
Сколько раз вы на практике пользовались профилировкой, чтоб отловить что-то и оптимизнуть и сколько раз пытались переписать алгоритм с N на Log N?
На практике все эти термины всё же сводятся к: "нафига тут 10 запросов, когда это можно сделать за 1?". На этом всё. Ни про какие "алгоритмические сложности" и речи не идёт.
Более того, вместо этой хрени с алгоритмической сложностью PHP-шнику на порядки важнее знать интринсики VM, почему x === null разворачивается в 5-6 инструкций проца, а is_null(x) в 200+, знать про устройство выделения и освобождения памяти, знать про страницы и фрагментацию, знать про шаги оптимизации (сколько их там, 12 или 15, скажете?) и проч. Если уж мы касаемся темы микрооптимизаций.
Для общего развития - конечно
Ну и зачем нам программист, у которого с общим развитием пробелы? Как минимум книг по своей специальности он не читает.
Это вопрос цены. Если у компании есть деньги платить за академические знания, в принципе, можно и про реализацию L1 кеша спрашивать. Обычно же требуют невменяемое за очень даже не рыночную зарплату. Я вот на недавнем собесе общался о внутренней реализации виртуальных функций в С++. За время работы ни одной виртуальной функции я в итоге не написал.
За время работы ни одной виртуальной функции я в итоге не написал.
Жалуетесь или хвастаетесь? ;)
Действительно, зачем писателю читать какого-то Толстого. Он же писатель, а не читатель.
Хвастаюсь конечно, я однажды работал с такой наследовательной лапшой, что недавняя статья про ООП головного мозга показалась мне вполне разумной.
Насчет Толстого- специалист должен соответствовать задаче. Нет смысла нанимать оверквалифицированного инженера красить заборы.
однажды работал с такой наследовательной лапшой
Любой gui toolkit построен на этом самом наследовании. Шаг в сторону от формошлепания, и придется столкнуться.
специалист должен соответствовать задаче
Даже слесаря на СТО с единственным умением - откручивать гайки - скорее всего не возьмут. Шаг в сторону - и чел поплыл Веб-разработчик, который ничего не знает про DNS, это очень узкий специалист.
Любой gui toolkit построен на этом самом наследовании. Шаг в сторону от формошлепания, и придется столкнуться.
Вопрос скорее в том, как устройство виртуальности поможет мне написать нормальную иерархию, а не класс брат сына отец дяди и внук отца? Все, что нужно знать, это class A : public Parent и что то помнить про diamond problem.
В целом для меня странно, что веб разработчик не знает основ веба, но я могу себе представить то, что этот днс даже рядом не стоял с его стеком. У бизнеса есть потребность в таких простых инженерах, кто быстренько сляпает решение.
Я, к примеру, знаю достаточно много прикладных инженеров, которые понятия не имеют какое физическое явление стоит за их формулой y = kx^a. Это не мешает им проектировать безопасные и рабочие механизмы. Бэкендеру днс тоже в целом не сильно то и нужен. Но отсутствие любопытства я не одобряю.
Любой gui toolkit построен на этом самом наследовании. Шаг в сторону от формошлепания, и придется столкнуться.
Есть "Анти-ООП" паттерны, вроде ECS, которые не требуют наследования вообще. Ну или в единичном варианте, вида: class Button extends Entity. Конечно, в основном оно используется в описании игровых миров, а не в GUI, но думаю что на счёт "любой gui" -- вы погорячились. Например для того же Bevy.
Шаг в сторону - и чел поплыл Веб-разработчик, который ничего не знает про DNS, это очень узкий специалист.
Вы же понимаете, что хоть вы и отчасти правы, однако "должен знать" - это всё субъективщина. Для начала стоит понять накой хрен ему это знать? Ну вот представим ситуацию, я, допустим, не знаю. У меня какая такая задача может возникнуть, что эти знания резко потребуются?
Шаг в сторону от формошлепания, и придется столкнуться.
Самые сложные и интересные кодовые базы в моей C++-практике не имели ни единой виртуальной функции.
А если писатель не читал Толстого, но читал Чехова и Фолкнера, потому что он, вообще-то, американский писатель, а не российский, то он тоже профнепригоден? А собеседуют его вообще на должность учителя младших классов.
Оно "микро" только до поры, пока программист CRUD пишет. Вот прекрасный пример, как даже в написанном сотнями контрибьюторов тулинге все еще полно мест, которые дают реальный буст, если понимать, как переписать https://marvinh.dev/blog/speeding-up-javascript-ecosystem/ (серия статей большая и про node, но, в целом, понимание дает)
Статья может и хорошая, но думаю удивляться даже не имеет смысла, что эта процедурная лапша на JS ещё тормозит. Просто сам влезал в исходники postcss (что у вас по ссылке) на позапрошлой неделе, у самого кровь из глаз потекла. Там в принципе надо всё переписывать по-хорошему. И регулярки вместо обычного слайса - не самое худшее что там есть)))
P.S. Да и не только postcss, в целом вся экосистема JS актуальная из подобной лапши состоит. Я, кроме TypeORM не могу припомнить проектов где бы была заложена адекватная архитектурная база.
Более того, вместо этой хрени с алгоритмической сложностью PHP-шнику на порядки важнее знать интринсики VM, почему
x === nullразворачивается в 5-6 инструкций проца, аis_null(x)в 200+,
Не могу не пошутить - в случае оригинального поста это будет особо полезно - ведь работать-то он должен был не на php, а на php-подобном языке, который траслируется в C++, который потом наверняка и через оптимизирующий компилятор гонится.
Не заглядывал в эту машинерию, но вангую, что половина встроенных функций php там не реализована в принципе (потому что не нужно), а другая половина реализована по-другому и скорее всего может вполне себе заинлайниться и соптимизироваться компилятором)
И вот на практике - доскональное знание xhprof/memprof/xdebug/etc, очевидно (по-моему), на порядки профитнее.
Опыт профилирования и оптимизаций на его основе - довольно универсальный и полезный - даже если придётся пересесть на другие инструменты, тут сложно не согласиться
Видите ли, какая штука... Алгоритмы и теория информация - это вечные знания, а вот ваши is_null и === - и есть херня мелкие подробности имплементации. Завтра сделают пхпшники is_null не функцией, а лексической конструкцией и можете выкинуть ваши эзотерические знания на помойку.
Впрочем, похоже, уже сделали:
===: 6852473.9742279 us
is_null: 6840348.9589691 usСкрытый текст
ini_set('memory_limit', '-1');
const SZ = 100_000_000;
$a = [];
for($i = 0; $i < SZ; $i++)
$a[$i] = rand() < 0.3 ? $i : null;
$t = microtime(true);
for($i = 0; $i < SZ; $i++)
if ($a[$i] === null) { }
print("===: " . (microtime(true) - $t) * 1_000_000 . " us\n");
$t = microtime(true);
for($i = 0; $i < SZ; $i++)
if (is_null($a[$i])) { }
print("is_null: " . (microtime(true) - $t) * 1_000_000 . " us\n");
Если ты сам пишешь алгоритм, то в этом есть смысл. Но вряд ли тебе когда-либо понадобится писать его самостоятельно. Если выбираешь библиотечную реализацию, то сравнивать их имеет смысл только с помощью тестирования на реальных примерах, из-за проблемы, которую указал предыдущий комментатор.
Классический N+1 может быть на порядки быстрее, чем O(1)
О-нотация - это не про скорость. Это про зависимость времени выполнения алгоритма от объёма входных данных.
Это значит, что при увеличении данных в 1000 раз выбор из кэша затормозит тоже примерно в 1000 раз. А запрос из Тайваня будет выполняться примерно столько же, сколько и выполнялся.
Все эти О-нотации нужны исключительно олимпиадникам
Нет. Это было бы так в идеальном мире, где джуны не вставляют цикл в цикл и потом ещё и защищают конструкцию: "ну ведь работает же". А оно работает на тестовых 10 записях.
Очень странная история с О-Нотациями. Я знаю что они существуют и что показывают, но их вычислять не умею(да и не надо особо было)
Для меня вместо О-Нотаций я смотрю в код и если виду большую вложенность - пытаюсь ее разобрать(так и работает стабильно, да и выглядит лучше)
А с джунами вопрос интересный. Почему они так делают - бог их знает.
Поскольку в свободное время занимаюсь репетированием, то предполагаю, почему джуны хреначат везде большую вложенность и прочие нечистивые вещи -- на курсах от всяких фабрик и тд им не говорят, что это есть плохо, а в самостоятельном плавании они останавливаются на первом удачном или не очень решении. Бывали и есть у меня ученики, которым я прививаю обратное... Однако из-за лени и не желания видеть альтернативный вариант при уже имеющемся рабочем (пусть не оптимальном) они продолжают городить эти конструкции.
Я и сам это подходил когда-то, но как-то быстро начинал делать нормально... На программной инженерии, первый курс ещё, у нас была система автоматической проверки задачек. Внутренний продукт школы (скажем, факультета), где решения со вложенными циклами и не только не проходили некоторое количество задач. Чуть более оптимизированные задачи выдавали time limit реже, пока мы не доходили до ± приемлемого решения, проходившего все тесты по времени и ответами. Так что очень многое решает этап образования, а именно получения базовых знаний.
Я лично не знаю как оценить свои знания(работаю на фрилансе, пока что думаю о трудоустройстве), самоучка, но понимания того, что вложенные списки сильно нагружают систему(ещё и переодически любят ломаться) у меня есть.
Я просто смотрю на код с точки зрения его поддержки (пока был сильно зелёным кучу ошибок допускал в проектировании, теперь лезть туда больно физически)
Так стоп, стоп. Ребята. Причем тут олимпиадники. Ведь кто то же пишет все эти замечательные библиотеки, которые вы используете в бизнес проектах. Программисты внезапно это не только клиентский коммерческий софт. Но и библиотечный. Вот им это и надо. Притом очень надо. Внезапно есть программисты которым надо знать все уровни абстракции снизу вверх, так как им приходится писать реализации.
Классический N+1 может быть на порядки быстрее, чем O(1), тупо потому что выбирает из UoW/кеша по индексам, а не улетает на реплика сет в Тайвань в виде SQL запроса на полтора мегабайта.
Ну так дьявол носит кеды кроется в деталях. Даже без учета технических нюансов, при расчете O-нотации есть два базовых правила: откидываются константы и оставляется только самое быстрорастущее слагаемое. Поэтому на самом деле может легко оказаться, что O(N) = O(1000000N + 1000logN). Это даже без того, что идеальной оптимизации не существует и любое практическое решение всегда сводится к разумному компромиссу между скоростью и потреблением памяти.
Поэтому куркуляторы и прочие блокноты весят по 300 мегабайт и потребляют гигабайт памяти. Забыли, как оптимизировать. Разбаловали вас Интелы с Амд, ох разбаловали :)
Человека, который не понимает концепции вычислительной сложности и написания "алгоритмического" кода в целом - я бы не взял знание конкретных терминов не так важно (автора статьи, по некоторым звоночкам, скорее всего тоже).
Разумеется при любой работе (скажем у меня в бытность написания компилятора) разные алгоритмы занимали не более 10% времени. Но горе тому, кто их не знает - ваш уровень определяется не "медианной" решаемой задачей, а самой сложной задачей, которую вы можете решить самостоятельно.
Опять же человек плохо понимающий программирование - не только n^2 vs n*log(n) походя путает, а спокойно и не задумываясь выдаёт код с экспоненциальной сложностью если задача становится минимально сложнее и хоть чуть-чуть нестандартной (особенно остро это у людей, любящих заучивать паттерны проявляется).
Ну и про сравнение "алгоритма" с прерыванием потока исполнения - вы же понимаете, что этим примером побеждаете соломенное чучело и прерывание потока исполнения на условный SQL-запрос / execve / whatsoever - точки о которых безусловно надо помнить.
Напоследок (к комментарию ниже): паттернам уровня "x === null" можно же научиться за 1 день, а вот если выяснилось, что "программист" не умеет писать алгоритмы - ваш уровень проблем сразу превращается "мы наняли писать код человека, программистом не являющегося".
ну так в алгоритмах зачастую и аллоцируется память, например, когда вы заранее не знаете сколько элементов будет в ответе, фильтр например
Нормально мне так карму слили за комментарий
Скрытый текст
Господам сливающим напоминаю: если вы будете бороться с критикой таким способом, то всё, что изменится - вы не увидите критики. Значит, не будете видеть, что можно исправить.
Я вот например хорошо знаю про оптимизации алгоритмов, более того работал с этим - например в один момент оптимизировал фильтр калмана под конкретную задачу. И про о от н могу сказать, и даже пользуюсь во время работы при написании алгоритмов.
Однако слова "о-нотация" для меня что то новое. Точнее, я немного припоминаю, что слышал это на каком то одном собеседовании, но не более. И услышав на собеседовании "расскажите про О-нотацию", я бы растерялся и вряд ли бы понял, о чем речь. При этом на вопрос в чем разница между пятью видами сортировок ответил бы на раз два.
Так что, конечно к автору поста вопросы есть, но то что "угадай-что-значит-аббревиатура" это плохойтспособ проводить собеседования - я полностью согласен.
О-нотация, это даже не базовые знания. Это базовый язык, на котором я могу объяснить, что этот кусок будет дико тормозить на больших данных, потому что N-квадрат, а надо лог N. Если что, я не в VK работаю.
Никакая это не база, а всего-лишь требование одной из ниш разработки ПО. Если вы не разработчик кодеков или не обрабатываете изображения на C++, а на серьёзных щщах в бизнес-приложении на Жаве ваш код сам лопатит миллионы записей, то вашего архитектора гнать надо ссаными тряпками за профнепригодность.
Вот вам очень простой контрпример из моей девопсячьей жизни:
Жил-был ansible-плейбук, который, помимо прочего, настраивал кластеры PostgreSQL. Работал очень быстро, никаких проблем с ним никогда не было. В какой-то момент не самый прошаренный коллега получил задачу дописать в него функциональность накидывания и удаления ролей. Решил он её очень незамысловато - сначала получает из СУБД список ролей, для каждой циклом собирает список пользователей. Потом берёт каждого пользователя из Ансибла, составляет список ролей, которые у него должны быть. Потом для каждого списка пользователей, полученного из СУБД... ну вы поняли, да?
Или не пишите движки СУБД или не пишите компиляторы \ бинарные трансляторы или не пишите библиотеки примитивов или .... то вам не надо.
Именно. Только 1% рынка разработки ПО типа приведённого реально нужны и алгоритмы и прочие О. Остальные же 99% с умным видом играют в карго-культ и ваят свой самолёт из говна из палок. Например, иммитируют работу СУБД. Или играют в хайлоад. В котором оверхед на 99% и генерит хайлоад. Ведь так хочется быть похожими на Белых Людей!
Мы проводили шуточный эксперимент, задавая вопросы с собесов мидлам и выше, которые уже не один год работают. Из полусотни опрошеных более-менее ответил один, и то потому, что подрабатывает курсами жавы в свободное время...
Плюс, как показывает практика, люди с крутым умением зубрить развитым логическим мышлением и инициативностью сильно не отличаются. Так что набирая "отличников"-теоретиков, рискуете набрать инфантильную орду, а не тех, кто двигает бизнес вперед. Теорию можно спрашивать со студента или стажера, это показатель, как он учился, так как он ее еще не забыл. Спрашивать с мидла с 5+ лет опыта про сортировки наизусть - ну тогда стоит погонять еще по истории Монголии, географии Кыргызстана, сольфеджио, фармакологии - "вдруг надо будет, а он не знает".
У нас в гугле по другому. Когда придумал новую задачку для интервью, сначала прогнал ее на коллегах. Все справились на отлично.
Отличная демонстрация ошибки выжившего - в компании где, чтобы пройти собесы, надо задолбаться решением алгоритмов на доске, внезапно все способны решить очередную новую задачу для собеса.
Но и вы задаете вопросы тем, кто, судя по всему, такое же интервью проходил в вашу же компанию N лет назад.
Суть в том, что алгоритмические интервью так не забываются, как ваши вопросы. Т.е. либо эти навыки используются в работе или это как кататься на велосипеде - один раз научились и уже никогда не забудете. В любом случае делает эти интервью в гуглах не такими страшными.
У вас в гугле четыре из пяти интервьюировавших меня человека поплыли, как только я попытался пообщаться про данные ими же задачи вглубь. Ну там, поговорить про kd-деревья с чувихой, давшей задачу про назначение ближайших велосипедов ездокам по двумерному городу (и ожидавшей решение с очередями), или про особенности трединга и локфри с чуваком, который сам начал обсуждать тему многопоточности при решении его задач, или про более продвинутые, чем блумфильтры, вероятностные структуры.
Пятый не поплыл только потому, что это был culture fit-раунд и разговор ни о чём.
"в свободное", конечно... 8 часов честно отпахал и пошел преподавать джаву
Мне, скажем, не говорят «сделай, чтобы O(LogN)» — мне говорят «сделай, чтобы быстро работало». Да я собственно и не помню, как это в нотации записывается — я по задаче вижу, что тут лучше сделать вот так, а там — вот эдак.
На какой черт это поменять? Нужно применить взял выбрал. Хотя пхп должно умереть любительскя подделка зачем-то стали применять на больших проектах
что такое DNS?
Бывает. С позиции адвоката дьявола: такие вопросы помогают выяснить, может ли человек объяснить сложные вещи простыми словами и, как следствие, насколько хорошо понимает о чём говорит. Выучить определения несложно, другое дело — в двух словах, как ребёнку, рассказать, что такое DNS или O-нотация.
В остальном сочувствую. Ваш подход к проведению собеседований, очевидно, рациональнее.
Я тоже только на собесе узнал, что паттерн CQRS использую уже 2 года. Зачем любой фигне давать отдельное название? Давайте использование ложки при поедании супа назовем "спун-юзингом" и будем в резюме писать "опыт применения паттерна спун-юзинг 25 лет".
Проблема в том, что когда обсуждается какое-то решение, то проще сказать: "Предлагаю использовать CQRS". Знание общей терминологии позволяет быстрее излагать свои мысли и не приходить к недопониманиям.
Не-а. Это способ выпендриться перед коллегами и только. Коллегам, будет понятно краткое смысловое описание на русском или английском, смотря с чем у них проще..
Ага, ведь на работе же выпендрёжем будет фраза "прога сделана через MVA паттерн на синглтонах", а не краткое и ёмкое объяснение архитектуры проги для человека, которому нужно в ней разобраться. Некоторые вещи проще объяснить через терминологию и это не будет выпендрёжем. Но местами и правда ее используют ради понтов, чтобы простое обозвать как можно сложнее
Проблема в том, что эта общая терминология общая только внутри вашего информационного пузыря. В других пузырях могут быть другие термины. Вот как-то приехал я в другой город и спрашивают меня какой версией силенга собирал проект. А я стою и туплю. Не собирал я проект силенгом, только клангом....
Затем что по CQRS (и любой другой фигне) пишут книги, статьи и комментарии. В которых скорее всего описаны подходы и решены проблемы, которые в вашей домашней реализации не предусмотрены. Это как "Я уже 10 лет пишу button1.onclick, и оказывается использую ООП. Ну и дебильное название". ООП гораздо шире чем вызов метода у объекта.
Даже написание программы через классы всё ещё не делает прогу оопешной. Очень часто видел код, в котором ООП было только ради ООП, но не использовался ни один из его принципов
В книгах много чего пишут. Я однажды читал книгу по TypeScript, в которой постоянно упоминались какие-то формы. Конечно, я думал про <form> и никак не мог понять, при чём там они. В какой-то момент оказалось, это объекты в JS.
Помнить все аббревиатуры, чтобы поддержать любой разговор, — это невыполнимо. Собеседующий согласился бы подождать, пока человек погуглит и прочтёт описание, чтобы узнать, что это что-то, что он хорошо знает?
Понимаю, что хочется называть вещи правильно и по-академичному, но я также за подход, что речь должна учитывать то, кому она адресована. Например, при общении с автомеханиками я скорее всего скажу "брелки", а не "брелоки", и уж точно не скажу "ржа́веть". Или другой пример. Нашему гитаристу я скажу зажать струну на три лада выше, а не скажу играть малую терцию, потому что я и сам-то не разберу, где она там малая, и в какой тональности песня, чтобы ещё терции считать.
Я однажды читал книгу по TypeScript, в которой постоянно упоминались какие-то формы. Конечно, я думал про <form> и никак не мог понять, при чём там они. В какой-то момент оказалось, это объекты в JS.
Выглядит просто как ошибка перевода
Но ведь написано же в бумажной книге!
Вообще, в русскоязычных книгах, я заметил, такое бывает. Прочитал про обобщённые типы, а на хабре все пишут про какие-то дженерики. Думаю, да когда ж я узнаю, что такое эти дженерики?
Или, вот, читал про сегменты в Go, а во всех статьях пишут про слайсы. Лишь посмотрев код, я понял, что за слайсы такие. Но и то, у меня оставались сомнения, что вдруг слайсы — это особый вид сегментов с собственным поведением.
Выше человек пишет: "Кладёт воркер в очередь фьюекса". Странно, что в очередь, а не "в кьюшку". И то ли это сленг из какой-то очень узкой области, то ли действительно общепринятая в англоязычной литературе терминология. Хотя "кладёт" — это точно сленг, потому что в очередь всё же добавляют.
Конечно, я не хочу людей, которые читали книги на английском, заставить перечитывать русскоязычные переводы, чтобы общаться на одном языке, но по факту имеем ситуацию как с поворотниками на кольце — в автошколе учат всегда сначала включать правый поворотник; но на дороге все, кто не едет направо, сперва включают левый, и даже были случаи, что если при въезде показать правый, а потом ехать дальше по внешнему краю кольца, то люди перестают пропускать и ломятся вперёд, думая, что машина будет съезжать с кольца. Так и приходится перенимать в речь всякие дженерики с локерами.
Обычно английские кальки все же приживаются не по чьей-то блажи, а потому что так действительно понятнее - перевод или неудобен, или уже чем-то занят.
Например, были попытки переводить CSS Grid как "сетки" - но слово "сетка" в контексте верстки уже используется в более общем смысле.
Или вот слово view - бывает пишут "представление", но во-первых не выговоришь, а во-вторых звучит дико. Что за представление, цирковое что ли? А скажешь вьюха и все понимают.
Понимают те, кто в контексте :) Для меня это до сих пор что-то абстрактное, вроде шаблона страницы, но вроде и не совсем, это может быть и целый компонент. Я с MVC так и не познакомился, как и с MVVM. Аббревиатуры-то написать могу, расшифровку знаю, но осознания не имею.
Так разговор и свёлся к тому, что учебники нужно читать на английском. Но лично у меня, например, скорость чтения английского текста раза в полтора ниже, в нём не могу пробегать абзац глазами, выцепляя слова и достраивая из них общий смысл абзаца. Аналогично не могу искать нужный кусок текста, беря по паре слов из предложения. А вот на русском могу.
вы бы со "спун-юзингом" потише себя вели, а то "утром в газете - вечером в куплете")))
Тем не менее, прямо здесь в этом комментарии вы использовали слово "паттерн", нафига вы используете эти ненужные термины?
Почему бы не говорить просто об устойчивых решениях дизайна програмного обеспечения? Просто и понятно. Придумали термин "паттерн", блин, зачем-то.
Можно же своими словами нормально обсуждать. Вот вы так и говорите - "я уже два года использовал устойчивое решение дизайна програмного обеспечения так же известное как CQRS, не зная, что для него придумали отдельное название" - и вас сразу все поймут.
Потом вас спросят, чем это устойчивое решение дизайна програмного обеспечения, заключающееся в <пять слов пропущено> отличается от другого устойчивого решения програмного обеспечения, введённого <имя рек>, и по словам его сторонников, заключающегося в <пять слов пропущено>.
А кто-то из коллег скажет, что многие то путаются между этими устойчивыми решениями дизайна програмного обеспечения, но есть принципиальная и критическая разница, которая не имеет значения в большинстве случаев, но в в вашем проекте - принципиальная.
Ему не поверят - а он в ответ пошлёт на хабр на статью с разбором разных устойивых решений дизайна програмных обеспечений, в которой словосочетание "устойчивое решение дизайна програмного обеспечения будет встречаться" 18 раз, а краткое описание конкретного устойчивого дизайна програмного обеспечения, которое заинтересовало ваших колег будет в встречаться 8 раз, так как название мы решили приницпиально этому устойчивому решению дизайна програмного обеспечения не давать.
Поздравляю с выходом в большой мир! Отлично понимаю твои переживания — сам проходил через это лет 10 назад, но тогда всё было совсем иначе.
Просто поясню: компания VK ≠ социальная сеть VK и уж точно не то, что про неё писали на Хабре десять лет назад. По сути, VK — это mail.ru, а внутри него миллион команд, многие из которых вообще не связаны с оригинальным VK.
Что касается KPHP — учить его не было необходимости. Внутренние языки компаний редко спрашивают на собеседованиях, потому что внешние кандидаты априори их не знают и не обязаны знать.
А вопросы про DNS и O-нотацию — это классика собеседований в крупные (и уже не только крупные) компании. В этот же список входят вопросы про массивы, хеш-мапы, указатели, сборщик мусора и всякие тонкости языка программирования, с которым ты работаешь. Это просто стандартный фильтр на входе.
То, что ты успешно решаешь бизнес-задачи в своей компании — без сомнений. Но если есть планы попасть в бигтех, стоит уделить больше времени подготовке к собеседованиям и лучше разобраться в том, как устроен рынок труда.
То, что ты успешно решаешь бизнес-задачи в своей компании — без сомнений. Но если есть планы попасть в бигтех, стоит уделить больше времени подготовке к собеседованиям и лучше разобраться в том, как устроен рынок труда.
Это практика "собеседование как культ", когда оно перестаёт иметь хоть что либо общее с реальными решаемыми задачами.
А вопросы про DNS и O-нотацию — это классика собеседований в крупные (и уже не только крупные) компании. В этот же список входят вопросы про массивы, хеш-мапы, указатели, сборщик мусора и всякие тонкости языка программирования, с которым ты работаешь. Это просто стандартный фильтр на входе.
На джуна? Возможно. Было время, когда на вопросы по структурам и алгоритмам данных я отвечал. На мидла таких вопросов быть не должно.
Вопросы на собеседованиях могут не нравиться, но пенять можно только на глубину погружения в предмет, и уж точно не на то, что вопросы "не для мидла, а для джуна".
Предполагается, что множество знаний джуна полностью помещается внутрь множества знаний мидла. Если это не так - имеет смысл более реалистично оценивать свой грейд.
Маленькая ремарочка: лет 5 назад я проходил собес в Яндекс, и там внезапно мне попалось на одном из бесконечных этапов задание в виде объяснения/оценки сложности в О-нотации/реализации в примитивном варианте класса, который бы работал с красно-черными деревьями.
При всем уважении к команде с бывшим красно-черным логотипом, такое логично спрашивать у джуна, у которого нет еще практических знаний, но универская база свежа, нежели у человека, который писал бэкенды на Ruby on Rails уже в течении 5 лет, и помнит о красно-черных деревьях вскользь, и применял их в работе ровно 0 раз за 5 лет.
но вот они были - и вы на них не ответили) получается, вы и не мидл, вы и не джун, вы - просто разработчик, который работал, получил какой-то опыт и экспертизу, своё видение и предпочитаете заточенность на решение задач какому-то общему кругозору (который, как правило, хотят видеть большие компании, ведь, как правило, туда всегда ищут больше, чем надо - вдруг куда-то вырастет. Исполнителей по факту наличия задач в таск-трекере обычно ищут фриланс-конторы, которым абсолютно всё равно на вообще любые ваши знания и опыт, пока вы можете реализовывать задачи)
Странные выводы Вы сделали.
В реальной жизни так не бывает, чтобы из таск трекера сразу готовая фича. Продуктовая команда приносит часто весьма сырое описание задачи. Моё предназначение, как разработчика - оценить задачу, её влияние на продукт в целом, предложить лучшее решение, иногда оно может не совпадать с видением продактов. После дискуссии начать цикл разработки, сначала проектирование, затем разработка, тестирование (юнит, интеграционное, нагрузочное), затем ввод в эксплуатацию. Потом наблюдение, оптимизация при необходимости.
А есть ещё баги и инциденты, которые ещё отловить надо. Есть ревью кода и менторство над младшими разработчиками.
Бывают ещё сложные архитектурные задачи. Как пример: мигрировать все сервисы с elasticsearch v6 на elastcisearch v8. Приходится переопределять архитектурные подходы, реализовывать паттерн стратегии, писать скрипты для безболезненной миграции данных, править спеки сервисов для деплоя.
В бигтехе задача от продактов идёт бизнес-аналитикам, архитекторам, системным аналитикам, проджектам и только потом уже к вам. А вас никто не будет спрашивать, надо ли им это, раз задача у вас, значит надо, а решение уже в задаче от архитекора или системного аналитика, вам и предлагать нечего, вам надо ТОЛЬКО сделать. Тестированием будут заниматься QA-инженеры, развёрткой - ваш тимлид или девопс, инфрой - админы и девопсы. Такова ужасная жизнь корпоратов, где у каждого своя роль, и как у программиста у вас роль именно программировать, а не всё прочее. Если хотите более широких полномочий, то работайте в компаниях меньше - чем меньше компания, тем шире ответственность.
Скучно же так, не? Вообще не обсудить алгоритмы и развитие на будущее, свое решение не предложить, "зачем так жить?".
Ну на заре карьеры можно еще чтобы все разжевали и делаешь как скажут, а уже с опытом хочется большее участие принимать.
У нас в компании 4 разработчика, но если мне менеджер поставил задачу, значит это надо, тестирует обычно отдельный человек или сам менеджер (ну, я тоже не сдаю то, что откровенно не работает, и иногда в процессе нахожу косяки), после моего merge request'а оно попадает на прод не знаю какими путями, это не моя сфера, а где там какие серверы, это тоже не моя забота.
Ну, допустим, в гугле на принципала у тебя тоже будут спрашивать алгоритмы и структуры
На мидла таких вопросов быть не должно.
Из-за обилия курсов и вкатунов с околонулевыми знаниями приходится отсеивать кандидатов на всех уровнях, такие дела.
Если мидл не может ответить на вопросы для джуна, значит он стажер.
Ну Вы можете "надувать щёки" и говорить о том, что Вас такое спрашивать не нужно, однако по факту Вы всегда проиграете кандидатам, которые уделили время подготовки именно к этим темам, пусть и "ради собеса".
Вы можете попробовать изменить эту практику, но для этого надо попасть в бигтех и подняться там по карьерной лестнице. Возможно, в процессе к Вам придёт осознание того, зачем же на самом деле задаются все эти вопросы.
А можно просто не стремиться в бигтех и делать свою работу там, где хочется - тоже вариант.
Внутренние языки компаний редко спрашивают на собеседованиях, потому что внешние кандидаты априори их не знают и не обязаны знать.
Работающему с PHP человеку должно быть просто любопытно, зачем VK и Facebook запилили свои реализации, тем более что весь код на гитхабе - и да, на мой взгляд странно не спросить. Но возможно, интервьюер был из той части mail.ru, в которой не знают или не любят kphp.
TL;DR: "Почему меня не спросили то, что я знаю".
Даже уважение какое-то к VK появилось.
Очень удивило незнание термина "О-нотация". Это не "вариант терминологии", это общепринятая терминология. Впрочем, вряд ли к автору бы придрались про термин, если он действительно рассказал про сложность.
я не помню, чем бинарный поиск отличается от линейного
...
Не было вопросов про оптимизацию
А чего про нее спрашивать, если даже низкоуровневые оптимизационные вопросы мимо?
Не было упоминания стратегического планирования развития продукта
Собеседование не на архитектора вроде бы.
Не было вопросов про системы контроля версий
И не на джуна.
У автора очень специфическое понимание навыков мидла. Это, конечно, проблема индустрии, что мы общие нормативы родить не можем, но вот результат - джуны без теоретической базы после 4х лет работы радостно рвутся на мидл. А мелким компаниям не жалко звания на погоны раздавать, если человек им пользу приносит.
Очень удивило незнание термина "О-нотация". Это не "вариант терминологии", это общепринятая терминология.
Общепринятая терминология - это "сложность алгоритмов". Термин "О-нотация" я слышал впервые.
А чего про нее спрашивать, если даже низкоуровневые оптимизационные вопросы мимо?
Потому что низкоуровневой оптимизацией на практике никто не занимается. Под все основные структуры и алгоритмы есть обёртки и обёртки над обёртками. А тем, кто на продакшене хочет заниматься вилосипедостроением, надо по рукам давать.
Реальная оптимизация выглядит так:
П1. Правдами и неправдами, через логгирование, профилирование и дебаггинг запросов находим тормозящий кусок кода
П2. Анализируем кусок кода. Чаще всего проблема в инфраструктуре - некорректно пользуемся БД (шлём запросы в цикле, отсутствует индекс, либо недостаточно узкая выборка). Решаем либо быстро, либо чуть дольше (партицирование, шардирование, масштабирование ресурсов).
П3. Если проблема всё же в коде, кидаем этот кусок в GPT, просим оптимизировать, клепаем тест-кейсы на изначальный вариант, смотрим, чтобы проходили на конечном, оцениваем время выполнения. Профит!
Не было упоминания стратегического планирования развития продукта
> Собеседование не на архитектора вроде бы.
Возможно, мои полномочия миддла чуть пошире стандартных, но для меня нормально, имея на руках продуктовое описание фичи, оценить её влияние на систему, ресурсозатраты на разработку и эксплуатацию и затем, провести полный цикл разработки сервиса, и, потенциальное внедрение взаимодействия с другими сервисами системы.
Не было вопросов про системы контроля версий
> И не на джуна.
Спорный вопрос. Здесь можно придумать задачи более усложнённые, по типу конфликтов, юз-кейсов ребейза, черри-пиков и сквошей. Но тут ладно, может и соглашусь, что джун тоже может всё это знать.
Если проблема всё же в коде, кидаем этот кусок в GPT, просим оптимизировать
До чего дошёл прогресс, вкалывают роботы, а не человек... Но это объясняет причину отсутствия начальных знаний. Если решаешь только типовые задачи, то копипаста со SO и chatGPT позволяют решать большинство вопросов, надо только немного синтаксис языка знать, английский для составления запросов и в целом достаточно. Как же приятно быть программистом, оказывается. Даже завидно немного :)
кидаем этот кусок в GPT,
...и идём собирать вещички) В крупных компаниях за такие телодвижения ИБ-шники очень быстро прибегут)
В наиболее крупных компаниях есть свои корпоративные аналоги GPT))
При этом в некоторых проектах этой компании всё равно может быть запрещено использовать даже внутренний аналог GPT. True story.
У крупных компаний просто есть контракты с опен аи на выделенные сервера и гарантии приватности данных.
Думаю, как минимум ФСТЭК немного напрягутся, если банки и операторы связи РФ умудрятся заключить контракты с OpenAI.
российские компании это свой мир, я про это ничего не знаю, но могу предположить что должен быть свой аналог, контракт с яндексом или другим российским бигтехом на выделенные ресурсы LLM.
Как я выше в ветке писал, у Сбера например есть собственные GigaChat и GigaCode, но некоторым сберовским же проектам запрещено их использовать в работе.
Наверно есть какие-то причины, мне рассказывали знакомые(не знаю насколько правда), что "сбер" это только зонтичный бренд, объединящий внутри группу довольно независимых структур и под-компаний и тогда вполне вероятно что один продукт не может гарантировать выполнение требований по compliance(не знаю как это в РФ называют), которые выставляет другой проект, а значит его нельзя использовать.
Даже если проект настолько НДАшное НДА и нельзя гигачат, у нас все равно есть развёрнутые на своей инфре ЛЛМки. Для небольшого количества людей сейчас доступное железо, даже на одной карте можно запустить. Модели в опенсорсе.
Проблем ноль, главное чтобы девопсы были
Сложность алгоритмов можно выразить в wtf/min. А можно в О-нотации. Про Ω и Θ видимо можно даже не спрашивать.
Потому что низкоуровневой оптимизацией на практике никто не занимается
Во-первых полагаю, что именно в ВК ей занимаются очень даже. Во-вторых "мне никогда не попадалось" - вообще не метрика. Именно поэтому вредно на старте карьеры 4 года сидеть на одном месте. Обертки над обертками заканчиваются leftpad'ом, а код из GPT, если уж такая идея в голову пришла (хотя тут должен быть другой вопрос), может закончится замедлением другой части приложения, просто потому что GPT не в контексте всей системы. TTM и ориентирование на бизнес - хорошо, но желательно чтобы код при этом все-таки работал
для меня нормально, имея на руках продуктовое описание фичи, оценить её влияние на систему, ресурсозатраты на разработку и эксплуатацию и затем, провести полный цикл разработки сервиса, и, потенциальное внедрение взаимодействия с другими сервисами системы
На соседние элементы - да, уровень мидла. На систему в целом - архитектора.
Я стараюсь не быть токсиком, просто желаю выбраться из инкубатора, и понять, что мир сложнее, чем он кажется из средней компании с highload-микросервисами на php.
Я бы вас не нанял, и не только по причине недостаточности технической компетенции. Вы не воспринимаете фидбек.
Если проблема всё же в коде, кидаем этот кусок в GPT, просим оптимизировать
Понаберут по объявлению.
кидаем этот кусок в GPT, просим оптимизировать
это фиаско
Общепринятая терминология - это "сложность алгоритмов"
Нет. "Сложность алгоритмов" или "вычислительная сложность" не ограничевается "O" большим, туда входят еще много других асимптотических обозначений. Строго говоря, "О" большое и "сложность алгоритма" - два разных термина
Но так исторически сложилось, что говоря про сложность алгоритма подразумевают О-нотацию
Реальная оптимизация выглядит так:
Судя по тому, что вы написали, вы мало занимались реальной оптимизацией.
Правдами и неправдами, через логгирование, профилирование и дебаггинг запросов находим тормозящий кусок кода
Да ладно? А я, наивный, думал для начала надо хотя бы настроить инфраструктуру для измерения перфоманса.
Чаще всего проблема в инфраструктуре - некорректно пользуемся БД (шлём запросы в цикле, отсутствует индекс, либо недостаточно узкая выборка)
Это бывает, но далеко не так часто как вы пытаетесь это представить. Бывает что отсутствует индекс, который должен быть, но это всё равно никак не влияет на перформанс.
По моему опыту, обычно проблема там, где её не ждёшь.
Либо чуть дольше (партицирование, шардирование, масштабирование ресурсов).
За ненужное масштабирование надо по рукам бить (либо вычитать из зарплаты стоимость ресурсов)
Если проблема всё же в коде
А как вы узнаете, что проблема в коде, если не можете отличить линейный поиск от бинарного?
Если проблема всё же в коде, кидаем этот кусок в GPT, просим оптимизировать, клепаем тест-кейсы
Дык зачем вы нужны, может проще ChatGPT нанять? А вы никогда не подписывали соглашение о неразглашении исходного кода при трудоустройстве?
Давайте продолжу вашу мысль: если проблема в базе данных, то кидаем базу в ChatGPT, если проблема в сторонней библиотеке, то кидаем стороннюю библиотеку. Если проблемы в конфигурации кубернетиса, то кидаем все наши настройки, не так ли?
оцениваем время выполнения
Время выполнения надо не оценивать, а измерять
Нанимать тогда надо чатжэпэтэ, а не тебя
Очень странно, что вы ругаете собеседование за то, что оно имеет формат викторины, хотя вопросы, которые вам не нравятся, всё-таки были не на "знаю правильное слово в ответе", а на какое-никакое понимание - что про сложность, что про dns, что про указатели.
Но как пример хороших ожидаемых вопросов мидлу - вы предлагаете именно что викторину.
Спорный вопрос. Здесь можно придумать задачи более усложнённые, по типу конфликтов, юз-кейсов ребейза, черри-пиков и сквошей. Но тут ладно, может и соглашусь, что джун тоже может всё это знать.
В чём сложность черри-пика? Берётся комит, применятеся к HEAD'у, плюётся в пользователя конфликтом.
В чём сложность сквоша? Что концептуально сложного в объединении коммитов?
Почему это пример "чего-то", что не может осознать джун?
Я прямо сейчас подойду к своей бабушке и скажу - представь, что я дал тебе три бумажки:
- вот на первой бумажке большим красным маркером написано "изменение 1", а в тексте написано "добавь строчку X"
- вот на второй бумажке большим красным маркером написано "изменение 2", а в тексте написано "добавь строчку Y"
- вот на третьуей бумажке большим красным маркером написано "изменение 3", а в тексте написано "удали строчку X"
Я вас уверяю, моя бабушка и без опыта работы с этими вашими компухтерами сможет осознать глубокую концепцию того, что эти три карточки можно объединить в одну.
В итоге, вопрос концептуально сводится к тому, что человек знает конкретное слово в одной конкретно взятой системе контроля версий. Это ли не викторина?
Потому что низкоуровневой оптимизацией на практике никто не занимается. Под все основные структуры и алгоритмы есть обёртки и обёртки над обёртками. А тем, кто на продакшене хочет заниматься вилосипедостроением, надо по рукам давать.
Для бигтеха характерно огромное количество самописного говна, в том числе самописные бд и системы хранения. А к этим самописным бд и системам хранения пишутся обёртки под используемые языки.
Откуда по вашему взялся таранул и кликхаус?) Их писали точно такие же как вы разработчики mail.ru (сейчас - VK) и яндекса - в том числе джуны и миддлы.
Вот только на один тарантул и кликхаус, вышедшие наружу в каждой из этих компаний найдётся 5-ок / 10-ок внутренних решений той или иной степени упоротости - к каждому из которых надо "на местах" писать и поддерживать обёртки)
Очень удивило незнание термина "О-нотация". Это не "вариант терминологии", это общепринятая терминология.
Я вспоминаю очень-очень давнее собеседование на временного сотрудника техподдержки в один временный развесистый проект. Меня спросили, что такое "лоад эмерджи" (цитирую русскими буквами, как услышал, это важно). Я честно ответил, что не знаю и вообще впервые слышу. Дома потом честно гуглил "load emergy", с предсказуемо нулевым результатом. На следующем собеседовании (все тот же персонаж) меня еще и пожурил, что я так и не узнал. Нелюбопытный, дескать.
То, что речь шла о load average, я выяснил только, когда приступил к работе. Ну да, не хватило мне исправляющей способности. Опыта на пингвинах у меня тогда особо большого не было, но там и работа была, прямо скажем, не высочайшей квалификации.
Я думаю, собеседовавший меня товарищ тоже мысленно хватался за голову, кого мы набираем, божеж мой...
Даже уважение какое-то к VK появилось.
Очень зря. Это вы видимо не слышали как они стажеров на фронтенд отбирают через ТЗ на фулл стек с деплоем с выполнением этой радости за неделю.
Я, возможно, чего-то не понимаю, но даже я, ни разу не разработчик, знаю, что такое указатели и О-нотация, хотя для меня эти знания были актуальны ...дцать лет назад в студенческой практике и в качестве хобби, причем программирование у меня было отнюдь не основным интересом. Точно так же я не понимаю, какую проблему может у профессионального разработчика, идущего работать в связанный с интернетом проект, вызвать вопрос "что такое DNS".
Мне сложно судить, зачем такие вопросы задают на собеседованиях конкретно в ВК, но с моей колокольни неумение ответить на такие вопросы - красный флаг, могущий говорить о серьезных пробелах в фундаментальных знаниях у человека. И, какой бы у него ни был практический опыт, при прочих равных я однозначно предпочел бы кандидата, у которого таких пробелов нет. Потому что отсутствие базовых знаний - плохой знак, и в своей профессиональной области я не раз в этом убеждался.
Указатели в Пыхе это отдельная песня. Как таковых их там нет на самом деле, но .. применять можно и вполне успешно. Вот такая вот загогулина.. :)
Я, возможно, чего-то не понимаю, но даже я, ни разу не разработчик, знаю, что такое указатели и О-нотация, хотя для меня эти знания были актуальны ...дцать лет назад в студенческой практике и в качестве хобби, причем программирование у меня было отнюдь не основным интересом. Точно так же я не понимаю, какую проблему может у профессионального разработчика, идущего работать в связанный с интернетом проект, вызвать вопрос "что такое DNS".
Я уверен, мои бывшие одногруппники также назовут ответ на эти вопросы. Потому что теорию зубрили. Я теорию не зубрил, а проекты сложные делал и автоматы получал за них.
Точно так же я не понимаю, какую проблему может у профессионального разработчика, идущего работать в связанный с интернетом проект, вызвать вопрос "что такое DNS".
Ну не знал я значения термина ДНС до собеседования. Ну узнал я его значение сейчас, что изменилось?
Незнание не мешало мне в своё время basic auth делать на апаче, рейт-лимиты с редиректами на порты в nginx прописывать, или certbot-ом SSL подписывать. Точно так же, как и знания этого термина абсолютно ничего не дают на практике.
или certbot-ом SSL подписывать.
А вы серьезно считаете это поводом для гордости, что уже второй раз пишете про это как о большом достижении в разработке? Цертбот, если что, это обертка вокруг летсенкрипта, которая делает в нем кнопку "сделать хорошо" которую просто надо нажать. Попробовали бы без него - сразу бы поняли что такое DNS и для чего он нужен и какие типы записей бывают
Кстати, про DNS менеджмент написано прямо на главной странице цертбота, он нужен если вдруг ваш kkrps проект захочет, например, масштабироваться и wildcard сертификат.
Незнание не мешало мне в своё время basic auth делать на апаче, рейт-лимиты с редиректами на порты в nginx прописывать
А какой-то негодяй на стековерфлоу взял ваш ник и сыплется на вопросах про работу апача на 80 порту
Точно так же, как и знания этого термина абсолютно ничего не дают на практике.
Знание расшифровки этого термина действительно ничего не дает. Понимание его работы бы дало, но что уж теперь.
А какой-то негодяй на стековерфлоу взял ваш ник и сыплется на вопросах про работу апача на 80 порту
Этот же негодяй успел подчистить вопрос про работу апача, видимо после комментария про вопрос. Что-то тут не чисто :)
Я уверен, мои бывшие одногруппники также назовут ответ на эти вопросы. Потому что теорию зубрили. Я теорию не зубрил, а проекты сложные делал и автоматы получал за них.
Приведу простую аналогию вашеих действий. В играх жанра RTS есть такая стратегия игры, которая называется раш (rush).
В наше время можно, наверное, не объяснять, что это такое
...но на всякий случай объясню: это стратегия, когда игрок вместо того, чтобы развиваться полноценно, с прицелом на победу в длительной игре за счет лучшего развития, обрывает развитие как только становится способен нанести фатальный урон противнику, производит нужное для этого количество войск и идет уничтожать противника, занятого дальнейшим развитием. Если получается - то это победа. Если нет - чаще всего, поражение из-за отставания в развитии, впрочем, это зависит от баланса конкретной игры.
Так вот, вы по жизни выбрали раш - и теперь из-за этого страдаете. Но, поскольку баланс игры в жизнь в наше время довольно благосклонен к игроку, то у вас есть возможность уйти в развитие ("в технологии") и скомпенсировать отставание в нем. Если хотите, конечно. Но без развития вы рискуете не продвинуться по жизни дальше, так и остаться таким же, типа, миддлом, и, во вполне обозримой перспективе - вылететь из профессии из-за развития AI или просто по достижении предельного возраста (но это всё не точно).
Выбор - за вами. Причем, какой именно выбор оптимальный - это вам никто не скажет.
Можно еще изменить ветку прокачки. Двинуться в менеджеров, там софтскилы даже важнее, а поверхностное понимание технологий и какой никакой практический опыт будут только плюсом.
поверхностное понимание технологий и какой никакой практический опыт будут только плюсом
Это сарказм? По моему опыту менеджеры со знаниями гораздо лучше они хоть понимаю сложность и трудозатраты.
- У нас есть плохой программист, к тому же неуживчивый (ошибается и отказывается признавать свою неправоту), что с ним делать?
- Давайте сделаем менеджером
- Давайте, но чур в другом отделе
Причем, какой именно выбор оптимальный - это вам никто не скажет.
О да, вполне возможно, что за "операторами GPT", не знающих ничего в глубину, а всё по верхам - будущее.
Незнание не мешало мне в своё время basic auth делать на апаче
Это сделано другими людьми, вам осталось без ошибок переписать пример из howto.
Это не теория, а самая что ни на есть практика. Возможно, прямо сейчас на вашей работе вы с ней не сталкиваетесь, но разве отсутствие у вас каких-то знаний и опыта - это повод советовать другим людям, как им поступать и на что обращать внимание? Советы на основании наличия опыта понять можно, на основании отсутствия - уже не очень.
Ну не знал я значения термина ДНС до собеседования. Ну узнал я его значение сейчас, что изменилось?
Что изменилось для вас - решать вам, это ведь ваше образование и эрудиция. А собеседующий, например, мог сделать вывод, что вы не понимаете основ функционирования IP-сетей и, следовательно, вас можно исключить как кандидата как минимум на часть вакантных позиций.
Незнание не мешало ... certbot-ом SSL подписывать.
Значит субдомены не настраивали.
"Не помнить" О-нотацию, отличие линейного и бинарного поиска или принцип работы хеш-таблицы можно только в одном случае - если ты этого никогда и не понимал. Если один раз разобрался и понял базовую идею, забыть это уже невозможно, настолько нам всё просто и естественно.
Это НЕ викторина на знание редких терминов, это проверка понимания самых-самых базовых концепций кампутер-сайнс. Интервьюер простейшими вопросами успешно отсеял кандидата с неподходящим им майндсетом. Кому-то это неважно, а им важно. Нормальный собес.
Только одно объясните мне, может я тогда пойму и приму эту религию собеседований. Что вы там все время сортируете? Кто-то пишет свой 100500 вариант сервера реляционной или key-value базы данных? Или создаётся ещё один Java фреймворк? Или ни одна реализация очереди или брокера сообщений вам не подошла и нужно писать свою? 95% разработчиков в бигтехе пишут бизнес код, и для этого почти никогда не нужны эти знания. Но очень нужны знания, как используя готовые инструменты из стека, паттерны и многие другие знания предметной области в короткие сроки выполнить задачу от бизнеса. Этим занимаются подавляющая часть мидлов и сеньоров. И кандидатов набирают именно на такую работу. Так зачем им выносят мозг вопросами по тем знаниям, которые им никогда не понадобятся при разработке бизнес кода и никогда не спрашивают о том, чем им предстоит реально заниматься?
Это частый аргумент, но ложный.
Если бы от автора ждали написания собственного key-value хранилища, то ему задали бы другие вопросы - про глубокие детали реализации и всякие нюансы (а их там много). Но нет, его всего лишь спросили, а для что вообще нужна хеш-таблица и по какому принципу она работает. Это вопрос на базовое понимание происходящего, которое нужно для правильного использования уже готовых решений. Самого общего ответа "на пальцах" скорее всего было бы достаточно.
Если бы спрашивали так, то вопросов нет. Разумеется, кандидат должен понимать, что такое хешмап, чем отличается сортированный список от несортированного и т.п. Вот лично у меня пару лет назад был собес, который я сам прекратил. Чел 40 минут меня пытал красно-черным деревом, до атомов просто разбирал. При этом вакансия была чисто бизнесовая, они там пилят систему какую-то по документообороту. Были указаны требования на знание спринг, спринг секьюрити, камунда, брокер сообщений, посгри, редиса и что-то ещё плюс понимание архитектурных паттернов, вообщем, стандартный суповой набор в энтерпрайзе. Но он ни одного вопроса по этим навыкам не задал! В начале бегло за пять минут спросил по ним, я ответил, и потом начался вынос мозга. Знакомые рассказывают, что примерно так же собесились в Я, Сбер, МТС. Т е это какая-то общая повальная тенденция. И потом когда их берут, сидят и пилят условные круды. Вот это вот что такое? Кто там у них пишет своё красно-черное дерево? Да, я до деталей, до математических формул не знаю как оно там под капотом написано. Потому что мне это настолько глубоко не надо. 90 процентов алгоритмов по отбору, сортировке, фильтрации данных в Java решаются с помощью stream api. Я уверен, что он написан правильно теми разработчиками, которые досконально знают тему. Они это и написали именно для того, чтобы все остальные этим пользовались и не изобретали каждый раз велосипед. Но почему это не спрашивают, почему нет вопросов по тем компетенциям, которые они сами указали в вакансии?
Приведу аналогию с футболом.
Когда в профессиональную (да даже и любительскую) команду на просмотр приходит новый игрок, ему (если только он конечно не Месси и не Криштиану Роналду )) ) дают мяч и говорят "чекань" (или "набивай").
В реальной игре чеканить-набивать естественно не нужно, там другие навыки и умения надо проявлять. Тем не менее все пришедшие на просмотр не спрашиваю "а зачем?", а берут мяч и набивают 10-20-50-100 и более раз, кто сколько сможет.
Пересекался в свое время с людьми, имевшими опыт игры в профессиональном футболе, в том числе и премьер-лиге РФ (или как она 20 лет назад называлась), никто не жаловался, напротив говорили и соглашались что без этого никуда. Потому что это базовый навык, только и всего.
Я ни разу не защитник алгоритмических собеседований, сам их не люблю проходить и никогда не провожу, но хотя бы базовое понимание сложности алгоритмов и знание основных структур данных могут понадобиться и прикладному программисту тоже. Мне, к сожалению, не раз приходилось видеть, как люди бездумно фигачат что-нибудь типа вложенных циклов там, где они не нужны, и неправильно используют "готовые инструменты" из стандартной библиотеки.
На собеседованиях не просят писать красно-черные деревья и хеш-таблицы. Вас просят их применить и показать хотя бы поверхностное понимание как и что там работает, чтобы показать, что вы сможете применить когда и как оно понадобится. И применять вот это вот все в работе в больших компаниях приходится очень часто. Если и просят что-то техническое такое сделать, то там элементарные вещи вроде разворота дерева для проверки, что кандидат способен удержать в голове аж целых два указателя одновременно.
Есть два стула: HashMap и TreeMap. На какой кого посадишь и почему?
Битва двух якодзун - с одной стороны не всегда релевантные вопросы, с другой человек, считающий себя мидлом, не знающий про О-нотацию и DNS.
Выше уже писал: О-нотация не программерское, а математическое понятие. Чел без математики может и не знать термина, но вполне внятно описывать сложности тех или иных алгоритмов своими словами.
Кстати, О-нотация весьма приближенная оценка. Так алгоритм О(N^2) может оказаться шустрее чем алгоритм O(N) при малых N и большой подготовительной работы у второго, которая тем не менее const. Но, с кочки зрения О-большого, второй алгоритм .. выгоднее. Вот такая вот загогулина..
Я не настоящий сварщик, и большую часть времени, как девопс-инженер, ничего сложнее лайтового перекладывания данных в Питоне не пишу - но почему-то в курсе про О.
И да, если бы мне кто-то на собесе ответил ровно как вы - что это обобщённая оценка зависимости времени выполнения от размера данных, я бы засчитал это как исчерпывающий ответ. Так же, как засчитываю ответ про OSI - что это древняя, выдуманная учёными и имеющая весьма опосредованное отношение к реальности штука. Так же, как засчитываю ответ про CAP-теорему в виде анекдота "быстро, качественно и недорого - выберите любые два".
Это вопросы кругозора и отсутствия пробелов в фундаментальном понимании. Важно знать принцип, а не вызубрить определение.
Очень многословный способ сказать "я тоже понятия не имею что такое О нотация, и отказываюсь учиться"
Выше уже писал: О-нотация не программерское, а математическое понятие
Вполне себе программерское - про оценку работы программы.
ровно в том же вк в 2017-м переписывал O(N^2) решение на O(LogN) (как по цпу, так и по памяти) в формировании персональной пагинации одного рекомендательного раздела. Было приятно удивлять коллег, что "нерешаемая задача", роняющая воркер по памяти, вполне себе решается на изи.
Йокодзун (ёкодзун)!
И эти люди пишут о знании терминологии…
Миддл, незнающий разницы между бинарным и линейным поиском? Это в Y2K25 такие миддлы теперь?
Ни в коем случае не хочу вас как-то унизить или обидеть, просто это базовые знания любого программиста, который программирует дольше одного дня. Каким чудодейственным образом вы подробно ответили про О-сложность, если не знаете разницу между бинарным и линейным поиском? Ничего не утверждаю, но недовольство интервьювера вполне могло быть обоснованным.
Я не знаю PHP, возможно, для бэкэнда все эти знания и не нужны, лепите сайтики по готовым фреймворкам и в ус не дуете :)
Миддл, незнающий разницы между бинарным и линейным поиском? Это в Y2K25 такие миддлы теперь?
Закон хабра: если человек напишет статью или комментарий в которой укажет, что какую-то вещь не знает, то обязательно найдется человек, который эту вещь знает и думает, что это прям обязательное для всех программистов знание. Обязательно в стиле "фу, не сеньор". Для контекста добавлю, что когда читал статью, то не смог вспомнить, алгоритм бинарного поиска. Помню по названию, что изучал для алгоритмов и собесов, но поскольку в работе не требовался, то и забыл вообще про что он.
Ответить на это хочется как в анекдоте про мартышку: "дура не дура, а свои 100 рублей имею". Причем не в том смысле, что паразит, а в том смысле, что приношу пользу бизнесу, несмотря на незнание.
Так никто и не просил вспоминать алгритм бинарного поиска. А по памяти его ни один нормальный человек не напишет, если предварительно специально код не заучивал (это утверждение основано на том, что баги в алгоритме его изобретатель много лет отыскивал, прежде чем он безсбойно заработал). Его спросили про разницу между этими поисками и вопрос следовал после вопроса про О-сложность. Как бы очевидно, какой ответ хотели услышать.
Ээ, в чем проблема в алгоритме бинарного поиска, какие там баги изобретатель отыскивал? Может, простую идею поиска в отсортированном массиве спутали с чем-то еще?
Возможно, это отсылка к какому-то слуху, что где-то была реализация с целочисленным переполнением: m = (l+r)/2; вместо m = l + (r-l)/2;
Но это не ошибка в алгоритме бинарного поиска, а неаккуратность с арифметикой.
Но вообще, новички часто допускают ошибку off by one, в результате бинпоиск может зациклиться. Когда осталось 2 элемента, средний окажется равен одной из границ и можно так неудачно расставить строгие знаки сравнения и +-1, что именно эта равная среднему граница и заменится им, так что после итерации интервал не поменяется.
Так что я частично согласен с комментатором выше: бинпоиск не абсолютно тривиален и там можно накосячить. Совсем новичка стажора его лучше не спрашивать. Но мидл-то должен уметь это заметить, хотя бы с подсказками.
Не в алгоритме, а в реализации - тык.
Я не знаю PHP, возможно, для бэкэнда все эти знания и не нужны, лепите сайтики по готовым фреймворкам и в ус не дуете :)
Нет. Мы не "сайтики лепим", а высоконагруженные микросервисы готовим, с сотнями тысяч RPM и сотнями терабайт данных. И нет, знания линейного и бинарного поиска здесь не нужны.
Потому что данные хранятся в БД. И вы знаете, что к записям надо обращаться по индексированному ключу. А если индексной таблицы нет, то её приходится создавать. Без этих знаний вы никак не смогли бы работать с БД (поэтмоу вы и имеете представление про О-сложность). Это всё те же знания линейного и бинарного поиска, но абстрагированные за интерфейсом СУБД.
" Без этих знаний вы никак не смогли бы работать с БД" Почему? Имея опыт собеседований базистов могу сказать, что далеко не всякий пришедший собеседоваться на сеньора может внятно объяснить как ложится на О-нотацию те или иные опрерации работы с БД.
То есть сеньор(!!!) пишет работу с БД, не понимая базовых принципов работы СУБД? А вы точно собеседовали сеньоров, а не джунов?
Уточню, что я говорю не о конкретных реализация конкретных БД - эти данные почти никто в три часа ночи сказать не сможет. Я говорю о примитивной информации, типа "поиск по индексированной БД это O(logN), а поиск по не индексированной O(N^2)". Тут можно поспорить про реализацию, что где-то не бинарный поиск, а хэш-таблица и O(N), вместо (logN), но в качестве первого приближения и без конкретики это адекватный ответ. А вот если сеньор скажет "я не понимаю, о какой О-сложности вы говорите, я с высоконагруженными БД работаю через чатГПТ", то как бы HR плохой, да.
HR притаскивали их резюме как сеньорские (100500 лет опыта в наличии, стек подходящий...), запросы были на сеньорские бабки. :)
"А вы точно собеседовали сеньоров, а не джунов" Случалось и обратное: крупная компания (не буду показывать пальцем). Собеседуют сеньора два лида и сеньору приходится деликатно "срывать покровы" над этой темой, чтобы не припозорить обоих лидов перед девочкой-hr-ом.
А про это уже в комментариях тут писали. Компании налево и направо раздают титулы. Этот программист у нас работает дольше всех, уже целых джва года, поэтому ему табличка сеньор тим лид. В принципе, ничего плохого в этом не вижу. Программисту приятно, директор ему звание присовоил, а з/п не поднимает, типа разменялись и все довольны :) А по факту работает как мидл или джун вообще. И вот приходит настоящий сеньор и ему приходится скромничать. Или этот недосеньор меняет работу, пробуется на сеньора главного лидера отрасли и не может ответить, надо ли в конце строчки ставить точку с запятой.
Поиск по неиндексированной это О(N), где N - кол-во элементов(пессимистический сценарий), а по хэшу это O(1) - константный, нам плевать на кол-во элементов. Вот тебе и «примитивная информация». Выходит, даже на джуна не тянете, по вашей же логике?
"Константный" до поры до времени. Если данных там больше, чем влезает в машинное слово, вылезает либо тот самый логарифм для длинного хеша, либо вообще O(N) из-за вынужденного увеличения бакетов. Другое дело, что на практике так не бывает.
Если данных там больше, чем влезает в машинное слово
Что это значит?
вылезает либо тот самый логарифм для длинного хеша
Сложность вычисления хэша не зависит от числа элементов. От числа элементов потенциально зависит количество сравнений при коллизиях хэша, но именно поэтому в случае хэш-таблиц говорят O(1) amortized.
либо вообще O(N) из-за вынужденного увеличения бакетов
Аналогично (даже если вы найдёте реализацию, пересоздающую бакеты при поиске, а не вставке, на что я бы с интересом посмотрел).
Вы, конечно, можете сказать, что получить O(n) таки можно, и на этом даже основаны dos-атаки, на что я скажу, что это решается, например, рандомным сидом ценой потери воспроизводимости, поэтому это уже совсем дебри.
Что это значит?
Количество элементов значительно больше чем usize::MAX
То есть я подразумевал что количество бакетов должно расти туда где их можно перечислить разве что длинной арифметикой.
Но вы правы - сам хеш-то подразумевается фиксированной длины, поэтому по достижению максимально перечислимого количества бакетов, расти остается только размеру самих бакетов. И вот тут уже сложность поиска начинает расти вместе с ними. Но понятно что на практике так не будет, кроме как в случае атаки на коллизии.
Количество элементов значительно больше чем usize::MAX
В таком случае будут проблемы не с хэшмапой, а с тем, чтобы все эти элементы разместить хотя бы в виртуальной памяти (предполагая, что вы не на какой-нибудь экзотической архитектуре, где usize меньше указателей).
искать в бакете можно повторным хешированием другой функцией, тогда время поиска останется константным, а допустимое количество элементов увеличится экспоненциально.
либо вообще O(N) из-за вынужденного увеличения бакетов.
Но все рассчитано так, что в среднем все-равно за O(1) выполняется.
Когда пишешь комментарий не думая, а читают - думая. Красиво по фактам уделали :D
Уверяю, до фига разработчиков 1с (примерно 90%) которые из вашего поста поймут только что речь идет о БД... но они не уверены какая именно у них под капотом.. то ли MS SQL, то ли какой-то portage, а может sportage )))
Мои знания об 1С ограничены анекдотами и байками. Как я понял, это отдельный дивный Мир. Если там "всё из коробки", а чег онет - запрашивается у службы поддержки 1С на дополнения. Тогда, действительно, для продуктивной раоты нужны только знания имеющегося функционала 1С, без побочных знаний. Но и отойти ни на шаг технически невозможно и из-за отсутствия занний и из-за технической невозможности. Но это пальцем в небо, я только мемчики читал.
А если серьёзно, то проходить "первичную фильтрацию" у HR, который даже не знает, на какую должность вы претендуете и который не способен адекватные вопросы задать - это трагедия всей IT-индустрии. Вот вы опытный разработчик хайлоад сервисов и устраиваетесь на аналогичную позицию, а вам задают вопросы не только из другой области, но ещё и на другом языке программирования... Я считаю большим везением, если удаётся собеседоваться сразу со специалистом или с будущим руководителем, в обход первичной фильтрации. Хотя бы не спросили, кем вы видите себя через 5 лет и не попросили нарисовать дом :)
Я считаю большим везением, если удаётся собеседоваться сразу со специалистом или с будущим руководителем, в обход первичной фильтрации.
Для этого нужна роль "нанимающий сеньор", который целыми днями будет только и делать, что проводить собесы даже с теми, для кого контейнер это "я в нем еду на работу ношу" - очень нерациональное расходование бюджета.
Скрытый текст
Написав 'контейнер это "я в нем еду на работу ношу"' вспомнил как собесился на свою самую первую работу (2016й, искал вакансии c# или php, устроился в итоге php-шником), сразу после универа: не ответил на вопрос про интерфейсы, потому как думал, что речь про UI.
Мне аж до сих пор стыдно насколько тупым я был.
Честно говоря по вашим комментариям складывается впечатление что у вас ситуация когда "мы" делаем "высоконагруженные микросервисы готовим, с сотнями тысяч RPM и сотнями терабайт данных ", но конкретно "я" перекладывает json между этими сервисами с нагрузкой в сотню RPM. Формально все правильно, но как говориться есть один нюанс.
Чуть выше Вы писали про 50к RPM. Прокол.
Чем дольше дискуссия, тем больше сотен тысяч RPM
RPM это опечатка или штука придуманная специально чтобы вместо 3к rps можно было написать "сотни тысяч"?)
Поздравляю! Вы в начале пути! Найм в биг.тех, это тоже своего рода "навык".
Вы столкнулись с процессом найма в крупной технологической компании. В таких организациях процесс собеседований, как правило, "систематизирован", что обусловлено большим количеством проводимых интервью.
Поймите, что для компании крайне сложно оценить ваши уникальные навыки, таланты и ваш "брильянт способностей".
Поэтому процесс собеседований строится на основе заранее подготовленного списка вопросов, на которые кандидат должен ответить. Интервьюер, в свою очередь, делает пометки о качестве и полноте ваших ответов.
Более того, технологический прогресс шагнул ещё дальше. Существуют прецеденты (в других компаниях) использования ИИ в процессе собеседования, когда ИИ анализирует ваши ответы, суммаризирует их и выявляет критические паттерны и несоответствия в навыках. И стоит Вам применить слово паразит "честно говоря, я не уверен", он с лихвой пометит вас "красным флажком вруна".
А вообще, верно говорили выше. Высококлассный специалист в биг техе, должен не только быть хорошим техническим специалистом, но он должен знать как правильно "кукарекать" в кофейне за "ванильным латте", так что учите "определения и аббревиатуры", чтобы быть в этой банде )))
P.s. ИМХО вся суть всех этих "собеседований" в "Миллион за старания, а не за результат."
Странно для Web-developer, конечно, что вы не смогли объяснить, чем бинарный поиск отличается от линейного и что такое DNS. Ну зато теперь, надеюсь, знаете) Пора уже вам от практики переходить к теории для систематизации опыта.
"ищут кандидата с более углублёнными знаниями (знаниями чего?)"
Я так думаю, что они теперь в hr-ской базе проставили, что соискатель и по софтскилам "не торт", если он на демонстрацию очевидных косяков по базовым знаниям, начал с пеной у рта что-то громко доказывать.
а вот интересно есть 2 сущности массив односвязный[1024] и двоичное дерево[1024] вот надо найти 1024 еллемент в линейном массиве мы тривиально будем идти вроде до 1024, а вот с бинарным 32 чтоли?
ну получается в одном случае 1024 прыжка а в двоичном без перестраивания поидее 640 или я ошибся или 512 прыжков вот тут выйгрыш наверно
Скрытый текст
0
1 2
3 4
5 6
7 8
------
В классическом бинарном дереве поиск будет зависеть от элементов. Если это будут числа 1...1024, то поиск тоже будет линейным.
Для сбалансированного дерева будет log2 (1024) = 10
простите это прыжков до 1024?
в дерево введены последовательно числа от 0 до 1024 - 1024 последний елемент и так же последовательно от 0 до 1024 введены значения в односвязный список
если там отсортированный массив 1024 найдется прямо на первом шаге. А вот сложность будет О(10)
но ведь от нулевого индекса до 1024 в поиск это в Next 1024 прыжка, если простое дерево соорудить где 1 проверка и слева минимум то ровно по прямой на половину меньше, отсортированный массив это сначала отсортировали потом прыгнули да?
суть интереса в том сколько затратиться времени чтобы по факту дойти до последнего введенного элемента от 0 по односвязному списку в сравнении с деревом если в оба вводили последовательно с шагом 1 1024 елемента
ладно буду смотреть
што? О(10) означает, что в дереве из 1024 элементов вы найдете любой заданный элемент не более чем за 10 "шагов". Если входная последовательность будет заведомо отсортированной, то имеет смысл перед поиском проверить первый и последний элементы, а только потом уже искать из середины
ок вот есть
//c
struct NodeOL//singlelist
{
NodeOL *next;
};
///////////////////////////
struct NodeBTL
{
NodeBTL *left;
NodeBTL *right;
};
//и типо в оба последовательно вводили с шагом 1 от 0 до 1024О(10) означает, что в дереве из 1024 элементов вы найдете любой заданный элемент не более чем за 10 "шагов".
Нет, конечно.
O(10) = O(1024) = O(π)
Понятно, что я придираюсь, но просто иначе это уже рекурсивная метаирония.
а почему у вас дерево настолько несбалансировано?
балансировка обязана проиходить при вставке, и за счёт фиксированного числа операций не увеличивает сложность вставки в O-нотации.
без балансировки можно это же дерево выродить в односвязный список. И тогда сравнивать односвязный список с односвязным списком не имеет смысла.
потомучто подумал о задаче ввода принципиально от 0 до 1024 и стало интересно сколько времени без перестройки деревьев и прочего
и без начала и конца вот есть только некст и у дерева допустим лево и право
ну в реальности такого нету, я уже понял, в С++ есть начало и конец уже, но чото прям стало интересно, ладно потом гляну
Если уж использовать по какой то причине деревья без самобалансировки, то входной массив данных перемешать нужно в случайном порядке перед вставкой
Еще есть целый класс деревьев, которые балансируются за счет рандома. Например, декартово дерево.
входной массив данных перемешать нужно в случайном порядке
Не стоит вскрывать эту тему. ИМХО проще балансировать деревья, чем правильно (в вероятностном смысле, с обоснованием хотя бы самому себе) перемешивать массивы.
Не очень понимаю, причём тут "начало и конец"
Поиск по дереву - O от глубины.
Если дерево у вас строится так, что имеет глубину O(N) (как вы сделали) - то поиск по дереву будет иметь ту же самую сложность - O(N)
Причём тут начало, конец и какие-то конкретные языки программирования (C++)?
UPD: при повторном заходе в комменты заметил, что оно не только не сбалансировано, но и не отсортировано. При этом добавляет сложности в работе. А оно такое зачем вообще придумано?
массив односвязный
Эмм, односвязный список, массив это "немножко другое"
выйгрыш
Понял, ок, пусть будет односвязный список, не вопрос
|| Совершенно не было вопросов про их диалект KPHP
А с чего бы они были? Вас могли собеседовать на самые разные проекты с самым разным пхп - от обычного легаси php5.6 (но надеюсь, там уже нету такого кода), так и на php7.1, на 8.2. KPHP, насколько понимаю - какой-то внутренний диалект, который вообще не факт, что до сих пор используется. А если и используется, то в каких-то нишевых разработках и пилят такой код сениоры либо мидлы, которых получили опыт/экспертизу. Было бы странно у вас спрашивать что-либо по каким-то внутренним наработкам, диалектам языков или особенностям настроек чего-либо.
Здесь были вопросы интервьюеру с моей стороны, про то, как он взаимодействует с последними версиями PHP и режимом use-strict, а также пару вопросов про подкапотное преобразование в C++
такое довольно странно спрашивать у интервьюера, если это не разработчик с проекта или тим-лид - и даже если это так, взаимодействие с use-strict - оно или есть, или нету, что до подкапотного преобразвания в C++ - такое не особо есть смысл спрашивать, так как если php код какой-то движок и переваривает в C++, то на это дело есть отдельный транспайлер/конвертор, делать обзорную лекцию по которому - достаточно странно, с этим просто столкнёшься или нет, а столкнувшись или изучив внутренню документацию, станет понятно, какой код переварит успешно, а какие места лучше писать по-другому. Все эти знания опять же спрашивать странно, так как они общего характера для большинства транспайлируемых/конвертируемых языков вроде того же HaXe. А какую-то конкретику/специфику вряд ли можно так выделить, чтобы на интервью рассказать.
Это похоже на то, чтобы на собеседовании спрашивать, "а как у вас на проекте Ts в Js переваривает, есть ли свой диалект и какие особенности". Ну переваривает и переваривает, за это отвечает какой-то софт или библиотека или самописная вещь, но если вас не собеседуют прям туда - зачем вообще копать в такие узконаправленные вещи, неплохо бы сосредоточиться на общем уровне, а в специфику вас и так введут или покажут.
полное отсутствие вопросов про паттерны разработки
а чего про них спрашивать-то? как правило, типовые задачи сами по себе складываются в эти самые шаблоны, не стоИт задачи, чтобы писать код который бы именно вот по шаблонам по канонам был выполнен, задача диктует исполнение и иногда это - фабрика, иногда - декоратор, иногда адаптер, а бывает и такое, что это класс-одиночка-божественный объект-шестирукий Шива, нафаршированный методами как следует.
Получается, базовые вещи по такому вроде бы и спрашивать нечего, а специфику незачем, типа там "как бы вы реализовали шаблон "Мост" на php"? Что и кому дадут такие вопросы и ответы, зачем это?Просто показать, что "я учил"?
архитектурные подходы и методологии проектирования
выше справедливо замечали, что это не мидлового уровня задачи, сейчас бы доверить мидлу тасовать архитектуру или тащить DDD на микросервисы или там свой фреймворк запилить или "давайте перейдём на Лару - все переходят на Лару". Этим другие люди заниматься должны, другого опыта, квалификации и экспертизы
Не было вопросов про оптимизацию и решения около-бизнесовых кейсов
оптимизацией опять же другим бы людям заниматься, то, что вы с этим сталкивались и разобрались - здорово, было ли это правильно? Нужно ли будет это на текущем проекте? Неясно. Это и выглядит не совсем правильно, если на проекте мидлы роют в оптимизацию - это показатель проблем и чудовищного техдолга проекта, ошибок проектирования. И опять же не мидлу заниматься таким, обычно на такое тратят время специально обученный разумный человечек, который наоборот не делает никаких мидловых задач, а занимается вот как раз узкими местами и методами их преодоления.
Решение около-бизнесовых кейсов - да с чего вообще спрашивать про такое? Опять же на больших проектах и в серьёзных компаниях этим отдельные отделы и люди занимаются, то, что вы как мидл с чем-то таким сталкивались - здорово. А про что ещё у вас спросить, с чем вы сталкивались, хотя не должны были? Может, с клиентами спецификации составляли? Может, финансовое планирование место имело? Может, обучали отдел техподдержки? Ну так этого всего на новом проекте не будет, как правило, если нанимают нового человека - значит, или много или будет много и прямых задач по разработке на пхп
Не было вопросов про системы контроля версий
Что спрашивать? Везде git. Ну merge, как и везде. Какие-то свои процедуры создания и вливания веток. Cherry-pick, кстати - это здорово, но не совсем здраво и опять же указывает на определённые проблемы в ведении веток проекта. Это вроде совсем базовые вещи, которые должен знать любой, кто вообще работал с git. Про контроль версий обычно интернов спрашивают или совcем новичков, чей пет-проект просто сохранялся в IDE по факту как файлы.
Не было упоминания методологий процесса разработки и стратегического планирования развития продукта
вот уж что не мидла ума дело - так эти две вещи. Сейчас бы привлекать разработчиков на стратетическое планирование продукта или там SDLC обсуждать. Что ещё, может, финансы распределим, бизнес-план построим?) Людей там спланируем в ИТ-отдел нанять? И чем вы, как новопришедший разработчик, собрались помочь при разработке стратегии продукта, не зная ни продукта, ни домена, не имея экспертизы хотя бы в несколько лет по этому самому продукту, либо сходных знаний.
Методологии процесса разработки - даже комментировать странно. Не нашего уровня вообще задачи, да и задачи ли - как правило, в компании на проектах эти самые процессы уже устоявшиеся, а на новых проектах применяются накатанные же схемы взаимодействий, чтобы все процессы и потоки были сходные с теми, что уже есть. Это не с полного 0 в RnD отдел на новый язык-технологию наниматься и что-то там пробовать, чтобы нужно было какие-то вырабатывать методологии. Опять же туда нанимают сильно других людей - начинать такие проекты и разрабатывать такие методологии.
Даже unix системы не упомянули.
Опять же - что там упоминать и зачем? Как правило, в вашем резюме уже написано, с какими системами вы работали - windows, linux, соответственно, какие-то навыки есть, которые вам позволяют на текущем месте выполнять задачи - то что толку про это спрашивать? Основы знания терминала или что спросить? Как работает ядро линукса? Как пропатчить кде
И вообще - возможно, у них проект под windows и там linux/unix нету необходимости применять.
= = = =
резюмируя, не очень понятно, зачем автор написал статью - это достаточно амбициозно, имея такие опыт и экспертизу, давать такой компании как VK советы и рекомендации, как собеседовать "мидлов". По автору такое ощущение, что он попробовал проект-два, 2 года выполнял какие-то задачи, допустим, что успешно, попутно занимался кучей побочных задач, чем обычно грешат проекты с текучкой кадров, или недоукомплектованные, или с техдолгом, или стартапы ("решения около-бизнесовых кейсов", господи).
То что знал - не спросили. Зато спросили, что не знал. Уже успели получить какое-то своё видение - "какой должен быть мидл", которое в ВК почему-то не разделили. Налицо нехватка опыта работы в крупных компаниях на хорошо спланированных и делегированных проектах - где бекенд занимается бекендом, фронт-енд - фронт-ендом, есть архитекторы, CTO, аналитики, отдел поддержки.
п.с: VK, напишите мне в личку, пожалуйста, если всё ещё ищете мидла на язык слона - обещаю сосредоточиться на php и не лезть в стратегическое планирование продукта)))
п.п.с: автор, без обид, но такие статьи лучше бы писать, проработав в индустрии хотя бы лет 10, вашего опыта пока хватает только на успешную работу на вашем проекте/компании
Как интересно у Вас выходит. Всё мимо. Видимо по Вашему мнению middle php разработчик должен целыми днями велосипеды самописные для бинарного поиска строить и сложность алгоритмов высчитывать. Зато руками и в пределах своей зоны ответственности!
Возможно у нас разные понятия о грейдах, но по моему мнению, middle - это не просто боевая единица, а сотрудник, способный и менторством заниматься, и оптимизацией и проектированием архитектуры, и другим спектром более сложных задач. Ему в конце концов как-то надо же сеньором становиться.
Исходя из Вашего описания уже сейчас всех мидлов можно выбросить и передать все задачи копилоту. (Про джунов я вообще молчу)
п.п.с: автор, без обид, но такие статьи лучше бы писать, проработав в индустрии хотя бы лет 10, вашего опыта пока хватает только на успешную работу на вашем проекте/компании
Таких претензий никогда не понимал. Я получил какой-то опыт, поделился им и своим видением ситуации, предложил альтернативный сценарий проведения собеседования. Разве не для этого "мы тут все и собрались"? Так что без обид не выйдет.
давать такой компании как VK советы и рекомендации, как собеседовать "мидлов"
А там что не люди работают? Или совершенные программисты? По работе продукта этого не заметно.
И судя по вашему сообщению, миддлу в принципе вообще ничего знать не надо. Ну кроме отличия бинарного и линейного поиска.
так ведь не говорилось вообще всем варежки захлопнуть и молчать)
это естественно, что много какие процессы в вк можно улучшить - в том числе найм. Но просто хотелось ответить автору статьи, что при всём уважении к его опыту, но вк - большая компания, давно на рынке и они, скорее, если и прислушиваются к каким-либо замечаниям конкретно по собеседованиям для разработчиков, то, думается, эти люди имеют намного больше опыта и, возможно, гораздо лучше понимают внутреннюю специфику компании и её проектов
А вот был бы автор условно аксакалом, ещё помнил пхп5.4, поучаствовал в жизни 5 или больше компаний, стартапов, проектов, вот от такого человека было бы интересно услышать какую-то критику, так как базироваться она будет на большом опыте, на внутряках и на понимании - какие могут быть приблизительные хотелки у подобного работодателя.
что до знаний мидла - мидлу вполне себе нужно знать достаточную базу языка, своего стека, протоколов, инструментария, версионности, редакторов, терминалы, деплои, докеры, всего понемногу, чтобы на более-менее самых разных задачах в своём проекте не теряться, чтобы можно было работать с таск-трекером, планировать, писать код, проводить дебаг как через дебаггер, так и через vdd ('var dump die'), версионность, участвовать в тестированиях и деплоях, взаимодействие с фронт-ендом, с девопсами. Чем меньше тебе нужно объяснять, что как куда делать со стороны сениора или тим-лида - тем больше ты мидл и наоборот)
Естественно, что расширенные кругозор, более глубокие знания, софтскилы, навыки общения и умение передавать свои знания, объяснять материал коллегам или там джунам - приветствуются и формируют хорошие задатки на дальнейшее развитие, но вот развитие архитектуры, какие-то методологии, подходы, а тем более около-сфера, финансы, управление продуктом - как правило, заниматься этим нанимают отдельных специалистов, а зачастую какое-либо внимание со стороны разработчиков и вообще не приветствуется (например, финансы или NDA моменты) либо остаётся непонятым - "на вашем уровне есть задачи от тим-лида в таск-трекере".
А чего по личкам то ходить? У них все публично: https://team.vk.company/vacancy/?tags=2231
п.п.с: автор, без обид, но такие статьи лучше бы писать, проработав в индустрии хотя бы лет 10, вашего опыта пока хватает только на успешную работу на вашем проекте/компании
Что то все забыли, что сам VK так не считает. Сам нашел, сам связался, сам пригласил... т.е. компанию полностью устроил опыт автора на момент собеседования и никаких "10 лет". И что это вообще за мидл с 10 летним опытом? VK же мидла искала, правильно?
@Davidaa_WoW Количество "экспертов" в камментах просто зашкаливает, я же в свою очередь хочу сказать, что любой собес - это преимущественно лотерея. Ты можешь ответить на все вопросы и в целом "не понравиться", а можешь мычать, бекать-мекать и тебя заберут с руками и ногами. Все зависит от настоения собеседующего.
Тоже когда собесился, вопросы были оторваные от реальности. Типо чем тсп от юдп отличается.
Т.е человек должен перед собесом заучить никому не нужные определения, чтобы никогда их не использовать.
Ну и по стабильности работы вк - видно, к чему такие србесы их привели.
Про себя - я лид и провел кучу собесов. И чаще всего по опыту, люди которые помнят всю эту мишуру, потом хуже работают.
Если человек пишет код для микроконтроллеров, то может и не знать "чем тсп от юдп отличается ", если же его работа хоть как то связана с сетью, то должен. Не каждый водитель должен знать цикл Карно, но отличать бензин от дизеля и не пытаться залить их в электрокар обязан.
Как это знание поможет написать хороший код?
Сравнение не подходит. Нужно ли знать отличие инжектора от карбюратора, чтобы хорошо водить?
Кроме написания хорошего кода (полагаю имелась ввиду бизнес логика) у инженеров еще много задач есть, например понимать что вообще происходит с той системой, которую им доверили (в больших компаниях это часто 15-летнее легаси). Вот тут самые разные знания и пригождаются (на самом деле тут они зачастую и получаются, поэтому их неимение это зачастую результат того что любые более менее серьезные проблемы чинили старшие товарищи). Конечно с этим важно не упарываться, если человек сам сказал что он эксперт в другой области, по этой области его и нужно гонять, если он действительно эксперт то всему научится.
Нужно ли знать отличие инжектора от карбюратора, чтобы хорошо водить?
Что бы водить машину вам нужно ее обслуживать и вообще выбрать исходя из своих условий. Вряд ли вы в таежную деревню возьмете машину по принципу "красненькая".
И точно так же затащив в проект либу для видеостриминга по webrtc через TCP можно долго удивляться жалобам на тормоза. Зато код хороший.
Сравнение некорректное. "Чтобы хорошо водить" == "пользоваться". Должен ли клиент вашего сервиса писать на языке, на котором сервис написан? Пожалуй, нет. Должен ли программист это делать? Скорее да.
Вы здесь не водитель, а механик.
Вы здесь не водитель, а механик.
На самом деле это интересный философский вопрос, насколько программист и в какой степени инженер, способный сделать модификации, в какой - водитель, а в какой - механик) Я бы сказал, что для разработчиков любого профиля, даже "просто водителя/пользователя" хватает проектов, НО при наличии более сильных кандидатов его скорее всего отсеют.
В том и дело. Чтобы участвовать в гонках, не нужно быть механиком. Но все чемпионы в гонках — механики.
Любой компании удобней иметь чемпиона.
Учитывая текущее препечальное падение среднего уровня на рынке, может оказаться так, что в компании вообще нет механиком, одни водители, которые пишут чуть хуже и сильно медленнее чатгпт.
Реальные чемпионы как правило знают себе цену и дорого обходятся, так что нет, не любой компании и в любой ситуации есть бюджеты на чемпионов ;-) А профессиональные таксисты или водители служб доставки часто знают свой девайс именно на уровне "пользователя", что не мешает им приносить пользу компании деньги.
"отличие инжектора от карбюратора" знать не обязательно, но залив бензин вместо дизеля можно убить мотор.
Как знание базы помогает писать хороший код я не могу сказать. Я вообще поражаюсь как без этого знания можно писать что-либо связанное с сетью, тем более если речь идет про highload. Отсутствие handshake запросто может сильно уменьшить latency и дать несколько лишних kRPS для микросервиса.
Более подробно хорошо рассказано здесь https://youtu.be/aXYJlizk3CQ
Нужно, потому что потом приходят с вопросом а почему телнет не работает? Да потому что там UDP и телнет его не умеет.
Нужно ли знать отличие инжектора от карбюратора, чтобы хорошо водить?
Если вы устраиваетесь на работу за деньги, то и спрос с вас как с профессионального водителя, а не как с автолюбителя. И да, профессиональный водитель обязан знать, чем карбюратор отличается от инжектора.
С программированием то же самое - любитель, который кодит для себя или для друзей, нк обязан знать вообще ничего. А профессионал, который работает за деньги, базу знать обязан.
Если вы устраиваетесь на работу за деньги, то и спрос с вас как с профессионального водителя, а не как с автолюбителя. И да, профессиональный водитель обязан знать, чем карбюратор отличается от инжектора.
Где?
Описание вакансии amazon flex delivery driver
Посмотрел пяток разных вакансий водителя-доставщика почты USPS — нет требований знать устройство авто, есть только требования уметь водить.
Посмотрел требования на commercial driver license в Техасе — нет требований разбираться в устройстве авто, есть требования знать, что перед приступанием к работе нужно убедиться, что нет лужи масла, что лампочки не сгорели, и максимум от устройства авто — проверить натяжение разных ремней-цепей, если они у вас есть. Получающему CDL для развоза почты на полуличном легковом авто даже это не нужно.
Карбюратор от инжектора отличать точно не нужно.
там кмк более актуально знание где у тебя в машине огнетушители, как проверить их пригодность и как их применять правильным образом. а карбюратор у тебя, инжектор или вообще турбодизель с механическим тнвд - только в контексте "чо из этого экономичней и дешевле/реже обслуживать приходится"
Если уж тянуть автомобильные аналогии, то водитель== user, а программист == конструктор. Юзеру допустимо не знать что там под капотом. Но если конструктор не понимает, как оно там внутри, он вам наконструирует, ага.
ЗЫ подходит на парковке дед, спрашивает - а сколько в твоей машине клапанов? а я такой, в растерянности: да хз.. (зачем оно мне? я даже не уверен, есть ли эта информация в мануале.).
с конструкторами бывают приколы,когда авиаторов пустили сделать мафынку - ну, получили преждевременную оптимизацию во все поля (до них там трудно доходило, что машине лишняя пара центнеров веса в общем-то роли не играет)
что машине лишняя пара центнеров веса в общем-то роли не играет
Это +200 кг массы-то роли не играет? Если речь про легковушку, то это так-то +20%, и вполне может повлиять на экономичность и динамические характеристики.
до них там трудно доходило, что машине лишняя пара центнеров веса в общем-то роли не играет
очень сильно играет, два пассажира весом 90-100 кг уже заметно влияет на динамические характеристики любого авто слабее 100л.с. а полностью груженое авто уже прям откровенно не едет
Посмотрел пяток разных вакансий водителя-доставщика почты USPS — нет требований знать устройство авто, есть только требования уметь водить.
ой кстати, а это вообще наши российские (советские) реалии
например на ЖД тоже самое, наши ЖД машинисты например зубрят электросхемы и устройство двигателя и его обслуживание, чтобы в пути починить чутьли не что угодно...а в США машинист только управляет поездом и всё... от этого очень сильно бомбит наших ЖД фанов что у них сплошные наездники и никто не разбирается в технике
разные подходы, где у нас тянет 1-2 секции - у них будет 3-5, и поломка одной ничего особо не решит, если ее можно условно в балласт перевести. ну, при условии, что оно успеет сломаться до того, как под ними очередной мост провалится или рельсы кончатся :)
ну это не основная причина в плане секционирования, там сам принцип ответственности иной, сломался локомотив - за это отвечает сервисная компания, которая сама туда бригаду отправляет для ремонта и отвечает за опоздания по этой причине
там проще поезд застраховать и опоздание оплатит страховая компания
Ну там же сказано: you use your own vehicle. Запорол свою машину, залив дизель вместо бензина — сам себе и виноват будешь.
Как это знание поможет написать хороший код?
Вы что, издеваетесь? Знание того, как работают сетевые протоколы поможет разработать механизм обмена между устройствами (или между устройством и системой верхнего уровня) в зависимости от характера взаимодействия и требований. А для уже существуюшего кода выяснить причины мистических багов типа "мы тут льем поток данных с датчиков, и в какой-то момент оно хаотично встает колом" или "через локалку все работало отлично, но как только заказчик развернул систему через 3G-модемы все стало работать как говно, хотя скорости более чем хватает".
Просто на будущее
SQL инъекции - просто не нужно класть сырой ввод пользователя в SQL запрос.
Ошибка номер раз: во-первых, понятие "пользовательский ввод" не имеет чёткого определения, что не позволяет построить на его основе гарантированную защиту. Во-вторых, даже если ввод "не пользовательский", ошибки синтаксиса от спецсимволов SQL никто не отменял. Поэтому данное правило звучит гораздо проще: "никогда не класть данные прямо в запрос".
Валидацию никто не отменял.
Ошибка номер два: валидация относится к бизнес-логике. А к безопасности - наоборот, никакого отношения не имеет, за исключением очень редких специальных случаев.
Добавить туда prepared statements и инъекции не страшны
Непонятно, что имеется в виду под "добавить", если это и есть тот самый способ, при котором "данные не попадают прямо в запрос". При этом важно помнить, что сам по себе подготовленный запрос - не панацея, и лучше использовать формулировку "заменять актуальные данные в запросе на знаки подстановки".
Ошибка номер три: помимо данных, есть ещё идентификаторы и ключевые слова. Для них замена подстановками не сработает и их надо фильтровать через белые списки.
XSS атаки - снова валидация пользовательского ввода, html escape
Ошибка номер четыре, которую мы уже разбирали на примере инъекций. Во-первых, валидация пользовательского ввода сама по себе, а обеспечение безопасности - само по себе, они почти не пересекаются. Во-вторых, для защиты от XSS экранируют не "пользовательский ввод", а "любой вывод в зависимости от его контекста": если выводим в HTML, то применяем HTML экранирование, если выводим в JS, то применяем JS-экранирование - и так далее. И пользователь тут ну совершенно вообще не при чём.
Насчёт интервью согласен с вашими оценками, но тут надо понимать, куда идёшь. В FAANG, которого косплеит ВК, идеальным кандидатом является конформист-зубрила, прокачанный винтик. И система найма заточена на отсеивание всего остального.
Не было вопросов про системы контроля версий
А про них-то чего спрашивать? Это даже не джуновские вопросы, это даже у стажеров как-то странно спрашивать. Мб еще нужно проверять скиллы "уверенного пользователя ПК"?
У претендующих даже на миддлов спрашивал и спрашиваю. Уже понял по прошлым, что люди тупят.
Половина не расскажет дальше 3 базовых операций: конфликты (когда возникают, могут ли быть проблемы в отсутствие конфликта), ребейзы и далее.
Если человек не разобрался с этим, то то и дело его будут преследовать "странности" Гита
Эти знания передаются за 20 минутный инструктаж. Спросить можно, конечно, но я бы не стал кандидата из-за ошибки в таком вопросе отклонять. А раз так, то и вопрос задавать нет смысла. Но вот в первый день провести инструктаж нужно. Если всякие коммиты и конфликты встречались абсолютно всем, кто более чем в одиночку разрабатывал, а вот "ребейзы и прочее" уже могли и не встречаться. И это скорее исключение, чем нормальная работа. Да, это оправдание с моей стороны, без справки я не смогу через консоль сделать что-т сложнее коммита или апдейта :)
Если б за 20 минут всё решалось, не было бы кейсов.
Я даже согласен на эксперимент, вы (или кто угодно) инструктирует человека которой из гита знает 3 команды 20 минут, я проверяю 10 минут
Ментор на то и ментор. Для того, чтобы человек мог начать работать с любой системой контроля версий достаточно вводной на 20 минут. А вот когда если вдруг возникнет ситуация, требующая каких-то особых знаний, вот тогда уже это тпрограммист обращается к своему ментору или читает документацию.
Я просто в принципе не понимаю, зачем нужно по памяти помнить команды git или чего-то ещё. Я вообще не понимаю, зачем нужено работать через консоль и что-то помнить, если все простые и частые операции выполняются через GUI (или программа, или контекстное меню - не важно)? Важно просто знать возможности системы, а как конкретно что-то сделать, всегда можно глянуть в мануал. Зачем помнить команду с кучей переменных аргументов, если её надо вызывать раз в пару лет, если случилась неприятная беда?
fetch, pull, push и всё, чтобы начать работать бользих знаний не требуется. Что вы ещё собрались спрашивать? Как откатить изменение в середине файла к ревизии трёхкоммитной давности, при этом переключить ветки и сделать мерж? За такой вопрос на собеседовании можно получить по лицу.
Большинство разработчиков знают только базовые вещи вроде add, commit, merge, push, pull. Что-то сложнее просто вводит их в ступор.
Мб еще нужно проверять скиллы "уверенного пользователя ПК"?
ужé не повредит... и заодно на базовые навыки онлайн-гигиены.
Как можно не знать базовые вещи в виде хеш-таблиц/деревьев и знать про индексы в БД ?
Такое ощущение что статья это байт на комментарии. Миддл удивляется обычным несложным вопросам.
эти знания за суммарные 4 года решения задач для бизнеса и 2 года работы мидлом.
Проблема в том, что не имея базовых представлений об этих вещах, вы даже не можете никак понять, что они вам, оказывается, были нужны. Имея эти знания, вы почти навреняка могли бы снизить нагрузку в некоторых местах на порядки, ускорить загрузки страниц и расходы на сервера.
Вот эти самые задачки на литкоде, которые куча программистов ненавидит и ругает, как ненужные - они почти все сформулированы как "дано вот это, сделать вот это". И почти все из них можно реализовать "наивно": дословно переводя с человеческого на язык программирования. И это медленное решение там не подходит, потому что есть на порядки более быстрые решения, если применить какую-нибудь штуку вроде хеш-таблицы или очереди с приоритетом. Если вы про них не знаете, то вы даже не заметите, что вот тот простой кусок кода, который вы писали, чтобы запилить какую-то фичу - это на самом деле задачка с литкода и там нужны эти самые, "не нужные вам за 2 года работы мидлом" алгоритмы.
Как не надо, знают все. А вот как надо, не знает никто). Даже те, кто думает, что знает
Я сейчас в поиске работы, последние 7 лет работаю проджектом в IT (до этого еще 3 года драйвила бизнесовые проекты). Общий стаж работы - 14 лет. Последние 5 лет работала с eCommerce системой (текущая поддержка системы, ее доработка, все проекты связанные с ней). Впервые за пять лет вышла на рынок и тихо афигиваю от вопросов на собеседованиях.
Разброс на собесах огромный и почти не касается процесса управлением проектами, командой, бюджетом и с какими трудностями сталкивались и как их решали. Так, 2-3 вопроса общих типа основные этапы жизненного цикла проекта/разработки ПО и как вы подходите к управлению задачами, какой самый сложный проект у вас был. Зато остальные вопросы - расскажите про Git, клиент-серверную архитектуру, API и какие еще основные типы интеграций существуют, сервис брокер, микросервисы, хранилища данных, на последнем собеседовании вообще была серия блиц-вопросов по направлению DevOps. И конечно же - "опишите все своими словами". Самое мое любимое - на основании каких показателей и параметров вы будете выбирать архитектурное решение будущей серверной инфраструктуры для компании нашего масштаба (к слову - одна из крупнейших телекоммуникационных компаний России). Еще раз - вакансия по описанию - уровень мидл проджект (даже без бюджетирования). И ладно б если такие вопросы задавали на собеседовании с руководителем, а его озвучивает HR, которому просто выдали список вопросов с ответами.
У меня уже были дискуссии со знакомыми из IT (причем как системные аналитики, так и разрабы, архитекторы и тестеры) на тему - должен ли проджект быть технически хорошо подкован или же все-таки главное - сильные управленческие навыки. Я считаю, что он должен уметь оперативно погружаться в вопрос, что бы понимать о чем речь, но что смешно - большая часть знакомых считает, что управленческие навыки сильно важнее, а типы интеграции должны знать соответствующие специалисты.
Не оправдываю.
Но эти цитаты в совокупности выглядят очень же странно, и не логично:
Я являюсь действующим PHP middle разработчиком в одной средней компании
За свою карьеру провёл пару десятков таких собеседований
Клиентами являются крупные интернет-магазины
Суммарно обрабатываем около 50к запросов в секунду, храним миллиарды записей и отвечаем за качество и жизнеспособность около тысячи интернет-магазинов.
Вопрос: что такое "О-нотация". Я отвечаю, что не знаю, прошу подсказать о чём вообще идёт речь.
Это не похоже на "среднюю" компанию, хотя, я не знаю вашего понятия "среднего". Но такая компания, судя, по цитатам, выглядит больше. Про собеседования от "мидла" (верится слабо), это отдельно, особенно, если не было более старших. Помню, собеседовал меня джун, это было весело, и собеседовал меня на позицию старшего разработчика, разумеется, я к ним не пошёл.
Совершенно не было вопросов про их диалект KPHP.
По причине, что это никто, кроме разработчиков компании, не знает (ну, почти) и тем более, никто не готовится, и какой смысл это спрашивать.
Что больше всего удивило - полное отсутствие вопросов про паттерны разработки, про архитектурные подходы и методологии проектирования. Не было вопросов про оптимизацию и решения около-бизнесовых кейсов.
Это вопросы для разработчиков старших, этим "мидлы" не занимаются в крупных компаниях.
Не было вопросов про системы контроля версий.
Это вопросы для джунов.
Не было упоминания методологий процесса разработки и стратегического планирования развития продукта.
Это продактов или, даже, директоров, тимлидов.
И, вообще, идти сейчас в эту "компанию", вопрос отдельный (риторический).
Все коменты не читал.
В общем - пару лет назад я проходил это собеседование и прошел (к моему удивлению).
Самое угарное, что я стал задавать вопросы интервьюеру о практическом применении того, о чем он меня спрашивал. (О-нотации, протоколе protobuf, BGP и т.д.) и вразумительного ответа не получил. Типа просто это нужно знать - показатель вашего кругозора. Потом приятные новости с оффером, рабочий ноут и т.д.
Но дальше - я увидел код ВК. И охуехал... Потому что ничего, озвученного на собесе там и близко не было - монолит из говнокода.
В итоге я сейчас фрилансю на ту же сумму и не сильно парюсь.
Но дальше - я увидел код ВК. И охуехал... Потому что ничего, озвученного на собесе там и близко не было - монолит из говнокода.
Так это классика. Увы, но мы живем во времена когда, на большинстве вакансий в России, собес это какой-то набор абстрактных вопросов не особо сильно связанных с тем что реально в компании происходит.
И вот мы на выходе получаем два-три этапа собесов озона где одни и те же люди задают одни и те же вопросы, пять этапов яндекса где на каждом насилуют мозги алгоритмами и компании поменьше где вообще сами не знают кого ищут.
Помню пытался устроиться в такие компание (правда компании небольшие, по 10-15 ч). Тоже дрючили по алгоритмам, в итоге не взяли потому что интервьюер посчитал что алгоритм O(n), хотя он был O(log n) - долго пытался объяснить.
В другую не взяли потому что не написал SQL запрос (завалился с подзапросом) - хотя разложил по полочкам каждый шаг и объяснил где можно оптимизировать. В итоге не прошел, хотя просто был невыспавшийся.
Но дальше - я увидел код ВК. И охуехал... Потому что ничего, озвученного на собесе там и близко не было - монолит из говнокода.
Во многих крупных компаниях такая ситуация. Сам сталкивался и знакомые программисты рассказывали. То же самое, что на собеседовании задают вопросы про деревья, сортировки, но в реальности это на текущей работе никогда не пригодится.
Зачем вам в вк? Сейчас мало кто говорит о них как о привлекательном работодателе.
А хотите лайф-хак? - Как мгновенно на одну ступень повысить свой уровень как специалиста?
Слушайте: на примере О-нотации. Вы ведь встречали запись О(n) и знаете, что это сложность алгоритма. У вас же сразу в голове возникли вопросы - "а почему это так записывается? Что это О вообще значит?", но вы пренебрегли поиском ответа.
В следующий раз в любой подобной ситуации не пожалейте времени, выясните очень тщательно, учитывая все подробности, что все эти циферки и буковки значат.
Вообще со стороны после прочтения сложилось впечатление, что автор засиделся на прошлом месте и его действительно "все устраивало", возможно он развивался в вещах узко специализированных на его работе, но не расширял кругозор. А именно при этом и вспоминаются (запоминаются) все эти джуно-мидловые вопросы.
Привет, ниггер. Добро пожаловать в 2025-ый год. Да, вот такие собеседования сейчас. И ты или принимаешь эти абсурдные правила, или идёшь в жопу
Единственное что я не понимаю, как можно не знать про DNS. Потому что об этом знают даже те, кто в IT не работал никогда (Team Viewer крайне настойчиво требует прописать в системе DNS от Google)
Ребята, откроую вам страшную тайну. На самом деле, в бигтех очень легко попасть, когда ты еще в универе проходишь там стажировки, на которых как раз учат алгоритмике и литкоду, когда ты еще прогрет матаном и прочими околонаучными задачками. После нескольких лет работы, ты начинаешь менять работу, понятное дело, переходя в другой бигтех. Вот таких мидлов как раз таки и ищут. Даже если вы прошли интревью, вас могут зарубить на этапе выбора команды, за которой последнее слово (потому что ребятам из команды некогда проводить собесы, но они с удовольствием пообщаются с вами о действительно нужных навыках, чтобы чтобы не взять себе обузу). Подумайте сами, каково вам будет работать со вчерашними студентами, из которых некоторые уже получили ученую степень.
Почему в бигтехе спрашивают такие задачки? Да потому что там решения не итерпрайзные и архитектура там особо и не нужна, а нужны навыки написания высокопоизводительного кода. Солид, ддд, слоистая архитектура - это всё можно освоить за месяц, а вот навыки написания парсеров, компиляторов, субд, маиематмческих программ - это да, требуются специальные знания, области научных интересов, которые обычно отрабатываются во время учебы в универе.
Отдельным пунктом можно выделить алгоритмический этап. На самом деле его лучше назвать "тестом на алкаша" - именно тут видно, как за десятки лет опыта работы и количесива потребленного алкоголя и никотина, мозг потерял в объеме. Это как раз тот этап, на котором можно без обид отказать бедному скуфу, до конца не разрушив его мечту войти в большой мир айти. А вы что, реально думали, что вас не взяли из-за того, что пузырьком не умеете сортировать? Ну ну.
Вы спросите: а как так, почему же меня позвали на собес? Да потому что рекрутеры - это 22 летние девочки, которые шерстят резюме по ключевым навыкам и опыту. Они наверняка уверены, что вы обязательно знаете, что такое фильтр Блума, после 14 лет программирования на пхп. Ах да, собеседования кандидатов - это тоже их kpi, без которых никак нельзя. Да, бывают самородки, но это скорее исключение.
Короче, не расстраивайтесь. Успокоить я вас могу лишь одним: в бигтехе из вас выжмут все соки. Вас хватит лет на 5 10 (до 30 35 лет), а дальше вы уйдете туда, откуда сейчас пыиаетесь попасть в бигтех.
Всем удачи и добра! Меньше круда, больше графов!
Отдельным пунктом можно выделить алгоритмический этап. На самом деле его лучше назвать "тестом на алкаша" - именно тут видно, как за десятки лет опыта работы и количесива потребленного алкоголя и никотина, мозг потерял в объеме. Это как раз тот этап, на котором можно без обид отказать бедному скуфу, до конца не разрушив его мечту войти в большой мир айти. А вы что, реально думали, что вас не взяли из-за того, что пузырьком не умеете сортировать? Ну ну.
Какой снобский абзац однако.
Сопляки не заглядывают дальше своего 30-летия)
Полагаю, это какой-то природный защитный механизм психики.
Да ладно. Вы за последние пару лет что то узнали (при условии что у вас опыт 7+ лет)? Изучение всяких фрейворков и бд не в счет, так как это не прокачивает ваши фундаментальные знания. Такие вот дела
А какие, простите, новые фундаментальные знания появились в computer science за последние пару лет?
Да в тех же LLM полно, исследования одни за другим идут. Вот хотя бы альтернативу для CoT предложили
https://arxiv.org/abs/2412.06769
Да что там пару лет, куча народу до сих пор не знает что такое SSI алгоритм в базах или стейтлесс корутина в языке, про тимсорт никогда не слышали, застыв в знаниях на уровне 2000 года.
изучение БД в основном и прокачивает фундаментальные знания, 95% фундаментальных знаний в айтишке в них и сконцентрированы)
Много раз приходилось рефачить код после олимпиадников... Пару раз было из-за постоянно приходящего OOM киллера. Грустно это все.
а вот навыки написания парсеров, компиляторов, субд, маиематмческих программ - это да, требуются специальные знания
Я бы, конечно, с большим интересом посмотрел, где в бигтехе более-менее гарантированно чем-то из этого заниматься, особенно парсерами и компиляторами, и чтобы нужны были спецзнания, а не «латаем дыры в clang под гугловскую специфику» или «перепечатываем хайповый папир с NIPS из закорючечной нотации в тензорфлоушную», для чего спецзнаний нужно на уровне чуть выше хорошей школы.
Но пока даже «латаем дыры в clang» — очень высококонкурентная среда с кучей желающих там поработать, поэтому большинство даже со спецзнаниями идёт и перекрашивает кнопочки. Ну или, пользуясь эргодической теоремой (хоть мне эти спецзнания пригодятся выпендриться в комментариях), вы почти наверное будете большую часть своей жизни перекрашивать эти кнопочки, даже если иногда удастся прикоснуться к великому.
Я видел как минимум команду, которая пилила бэкэнд к LLVM под свой DSP (Не эльбрус, б-же упаси. Международная компания с R&D в России). С соответствующей необходимостью векторных оптимизаций и распараллеливания. И не было там никакой очень высококонкурентной среды. Найти кого-то со способностями чуть больше чем у дуба было довольно-таки нетривиальной задачей.
Найти кого-то со способностями чуть больше чем у дуба было довольно-таки нетривиальной задачей.
Что там по ЗП было? Может просто мало предлагали, такое бывает сплошь и рядом
У меня наблюдаемые данные по американским (и паре европейских) офисам двух с половиной из пяти букв фаанга (все две с половиной делают своё нетривиальное железо), и чьи потребности по компиляторщикам этак на 90-95% закрываются внутренним трансфером. Желающих пилить компиляторы внутри этих компаний сильно больше, чем позиций, где этим можно заниматься.
Куча желающих - это 500 откликов на одну вакансию бекендера за один день? :)
Нет, это написал рядом.
Но пока даже «латаем дыры в clang» — очень высококонкурентная среда с кучей желающих там поработать
+1
Кмк, уже то, что шланг написан на С++ означает, что желающих писать компилятор для С++ слишком много.
вы почти наверное будете большую часть своей жизни перекрашивать эти кнопочки, даже если иногда удастся прикоснуться к великому
Не перекрашивать кнопочки, а бороться с С++, записывая код предназначенный либо для Даталога, либо для Камла в плохооформленном eDSL.
Все по делу и вас ожидаемо заминусили.
Не было вопросов про системы контроля версий
Даже unix системы не упомянули.
мы же вроде на PHP разработчика подавались, нет?
За мой опыт с 2008 года, начиная с Яндекса и кучи различный остальных мест, включая всякие Фейсбуки, Майкрасофты, гуглы и тд у меня ни разу в жизни такого не спрашивали на любой уровень.
Более того из 6 смен мест работы я только 1 раз писал на языке не в первый раз. Я каждый раз менял язык при смене работы. Особенности/синтаксис/опыт языка тоже никто никогда не спрашивал, включая даже низкоуровневые С и С++.
Факт в том, что интервью не всегда похоже на обычную работу и там могут спросить совершенно другие аспекты. Можно пытаться отрицать неудобные факты, но не уверен, что это поможет в том, чтобы попасть на работу.
Более того из 6 смен мест работы я только 1 раз писал на языке не в первый раз. Я каждый раз менял язык при смене работы. Особенности/синтаксис/опыт языка тоже никто никогда не спрашивал, включая даже низкоуровневые С и С++.
Это почти не работает в России. В 9.5 из 10 случаев компании не нужен специалист не знающий стэка на котором ведется разработка потому что это более длительный период до момента пока сотрудник не начнет работать на 100% и возможные косяки с его стороны из-за незнания каких-то специфик стэка.
Я за все время что работаю видел наверное 3 вакансии где прямо говорилось что берут не зависимо от текущего языка. Это были яндекс, авито и ситимобил.
Вы забыли добавить еще один важный момент, что при таких условиях после смены ЯП все HR считают вас джуном.
более длительный период до момента пока сотрудник не начнет работать на 100%
Это сколько, 1-2 дня обучения новому языку? Я помню, когда работал в Яндексе 2008-2014 - там вообще едва кто в принципе работал. Там по месяцу никто ничего не делал, 1-2 дня обучения новуму языку вообще ни на что не повлияют. Что за сроки/проекты такие, что 1-2 дня могут сделать прям большую разницу?
Если будут 2 абсолютно одинаковых кандидата, один со знанием стека, другой без - то да, лучше взять с опытом. Но в жизни такого не будет. Будет кандидат со знанием стека, но не знающий, например, что такое split-brain и paxos и остальные фундаментальные вещи в distributed systems и будет, который знает фундаментальные вещи, но до этого писал на другом языке, скажем python вместо ruby.
Это сколько, 1-2 дня обучения новому языку
Хехе я уже сильно больше декады на С++ пишу и не скажу что я ему до сих пор обучился (xkcd c++ 21 days).
xkcd
abstruse goose! (который, к сожалению, всё)
Зависит от проекта и насколько там прям нужно все нюансы знать языка и конкретного стандарта. Кажется, что чтоб писать даже на С++ его не нужно знать в совершенстве. Я в 2008 шел в Яндекс писать на С и С++ ни раз не писав до этого. Как-то не было особо проблем с этим.
Из недавного года 2 назад - у меня один друг примерно 15 лет писал на Перле в разных местах и пошел в Фейсбук работать, писать на С++ кодеки для кодирования/декодирования видео. Вроде как-то быстро освоился, с языком сложностей не было - его только их система сборки напрягала как-то. Еще другой совсем недавний пример, другой друг последние лет 10 писал на C# и немного джавы. На С++ писал только в универе лет 20 назад. Пошел в MS, писать их MsSQL с 20М строками на С++ различных стандартов, написанных за последние лет 30. Тоже нет сложностей с языком.
Если бы ФБ или MS на эти проекты ограничивали бы поск только кандидатами с опытом на С++ они бы вообще едва кого нашли бы.
Чтобы как-то писать чтоб заработало, да, чтобы писать на любом языке околооптимальный код, надо с ним очень много времени провести (для примера мне надо на С++ писать, который я знаю нормально, и на обжективе, который я не прям знаю, мой плюсовый код гораздо производительнее, так как всех уголков обжектива "надо использовать то, а не это чтоб в этой ситуации было быстрее" я просто не знаю), я не раз видел как даже на шарпе писали такой код, что пройдясь по нему можно было легко несколько миллисикунд снять с кадра, что уж там говорить про С++ (я уж молчу про то, что на плюсах такие веселые сегфолты можно наделать, что дебажить неделями). Но конечно это мое личное что мне хочется максимально оптимально использовать инструмент, отсюда я и выбрал себе область где производительность важна и платят мне отчасти за то, насколько я могу писать производительный код/оптимизировать.
теперь чуть понятнее почему у МС раз в год кривое обновление, которое всё ломает
Это вопросы для джуна все :) Я всё это еще в школе уже знал, хотя было 0 лет опыта коммерческого программирования…
не знал что ответить на вопрос: что такое DNS
я не помню как работает хеш-таблица
Я бы вас тоже не нанял на мидла
А как работает хеш-таблица? Она же или есть в языке (я читал, что в Perl есть), или её нет. Кто её знает, как она там работает? Исходники компилятора/интерпретатора читать? Или речь о чём-то другом?
Понятно, что если в компиляторе смогли сделать, то можно просто руками это сделать. Наверное, про такой случай речь, да?
Общий принцип описан в любом учебнике по алгоритмам. Детали реализации в конкретном языке могут быть в учебнике по самому языку или в документации стандартной библиотеки.
А как работает хеш-таблица
Обычно в документации контейнеров языка написана структура данных которая использована в реализации. Знать это надо чтобы понимать какую структуру данных и почему надо выбрать для вашего юзкейса.
То есть, настолько глубоко нужно изучать языки? Типа, пока штук 10 учебников не прочитаешь, можно даже не искать работу? А ведь ещё нужно что-то писать, чтобы закреплять знания. А пока их читаешь, уже выйдет новая версия языка, и не одна.
Я с января прошлого года взялся изучать Go, до марта поизучал, в январе этого года решил начать заново, но пропуская большие куски, которые уже прочитал и примерно помню. Так, учебник, который я читаю, уже даёт некоторые устаревшие примеры. Например, vs code мне показывает, что генератор случайных чисел уже не нужно инициализировать. А на хабре видел, что там что-то с замыканиями изменили где-то в версии 1.23 или около того. Чувствую, я так могу никогда не догнать актуальное состояние языка, а ведь я читаю только про поверхностные вещи, там пока что дают по паре функций из каждой библиотеки. Был бы я безработным, насколько всё было бы проще и быстрее…
То есть, настолько глубоко нужно изучать языки?
Знать контейнеры это не "глубоко изучать языки", это где то на уровне как написать цикл или условие в языке. Прочитать документацию по контейнерам это 20 минут делов от силы. Новая версия вышла, прочитать по диагонали что там новое, посмотреть на чем новые контейнеры если они есть (что врятли). Это то что нужно постоянно и количество контейнеров обычно по пальцам можно пересчитать.
Нет, я про то, что знать, как оно устроено внутри, ведь вопросы был о том, как работают хеш-таблицы, а не как ими пользоваться в работе.
Вы слишком тревожитесь по мелочам. Вы представляете себе этот вопрос как будто вам на экзамене дали билет и вы должны написать максимально подробно и строго.
Например если у вас спросят что такое интеграл то большинство людей удовлетворится быстром ответом что это площадь между кривой графика и осью Y, а не будете мучительно вспоминать что это предел сумм и имеет в виду ли автор вопроса интеграл Римана или какой-то другой. Учитель по матану в универе не удовлетворится но это особый случай, он и про устройство хеш-таблицы спрашивать не будет.
Касательно хеш-таблицы в Go, большинству хватит ответа что это структура данных которая раскидывает данные по бакетам, на основании остатка от деления результата хеш-функции на количество бакетов, а не будет ожидать что вы зачитаете код по памяти.
Дальше про коллизии хеша, O(1) в теории, на практике линейный доступ внутри бакета, возможный DoS из-за этого, каким образом это решено, допустимые ключи, потокобезопасность. На этом практически все, это не так уж и много и достаточно практически обоснованно.
Особо упоротые будут спрашивать "сколько байт берется от хеша перед взятием остатка ?"и "как делается рандомизация?" но таких считанный процент и даже у них это вопросы со звездочкой.
Дальше про коллизии хеша, O(1) в теории, на практике линейный доступ внутри бакета
Или open addressing, или cuckoo hashing (это на самом деле спрашивали на интервью, кстати).
структура данных которая раскидывает данные по бакетам, на основании остатка от деления результата хеш-функции на количество бакетов
O_o Не знаю, что понимается под бакетом (некое ведро?), но я думал, речь про что-нибудь типа ассоативного массива с ключами из каких-то идентификаторов.
Разве интеграл — это площадь не между графиком и осью X? Конечно, смотря как назвать оси, можно и E назвать, но я имею в виду ось абсцисс.
Разве интеграл — это площадь не между графиком и осью X?
Да, все верно, тут мой косяк.
речь про что-нибудь типа ассоативного массива с ключами из каких-то идентификаторов
Так одно другому не мешает. Хеш-таблица это уже конкретная реализация ассоциативного массива. А сам ассоциативный массив можно запилить хоть на самом массиве с полным перебором хоть на деревьях.
Бакеты это структуры данных внутри самого hashtable для хранения данных, можно сказать что в Go это массивы если не углубляться в совсем уж нюансы. В Java HashMap если я правильно помню это был LinkedList потом что-то поменяли, сделали деревья.
но я думал, речь про что-нибудь типа ассоативного массива с ключами из каких-то идентификаторов.
Так в том-то и вопрос - а откуда берётся "ассоциативный массив"?
Благословением и проклятьем нашей области является то, что в программировании нет магии - вообще нет магии - только фокусы. Нету в машинном коде никаких ассоциативных массивов - только байтики, адреса памяти и операции над ними.
Значит возможность "по ключу" достать какое-то значение - кто-то взял и написал.
А как он это сделал?
И эти общие принципы - они в общем-то довольно общие для всех языков. Во всех языках вы так или иначе найдёте какой-то аналог мапы.
И эти стандартные вещи (вроде мапы / асоциативного массива или очереди с приоритетом) пишутся примерно одинаково (если не углубляться в какие-то совсем дикие тонкости) - вне зависимости от того, сидите ли вы в 80ых читая книгу Кнута с псевдоассемблером, пишете ли в 90-ых на QBasic'е или изучаете в 2025-ом Go.
Вчера смотрел лекцию по физике, там дядька тоже приводил пример с "почему N не пришла на работу". Потому что она подскользнулась, потому что вода замерзает при низких температурах, потому что такое поведение молекул, потому что электромагнитное взаимодействие между подошвой и льдом приводит к скольжению. Короче, человек не пришёл на работу из-за строения нашей вселенной.
Нужно ли погружаться в ассоциативные массивы, если они просто даны языком, как в PHP? Ну конечно, кто-то это написал. Но если он уже написал, и это работает, зачем мне в этом ковыряться? Он писал не для того, чтобы это разбирали, а чтобы пользовались без необходимости копаться в кишках. Я шевелю пальцами, но даже не знаю, сколько там мышц. А до 2021-го даже не знал, что такое сухожилия, пока не растянул лодыжку. Да и сейчас не знаю, растут ли они, и что из себя представляют. Но пользуюсь с детства.
Нужно ли погружаться в ассоциативные массивы, если они просто даны языком, как в PHP? Ну конечно, кто-то это написал. Но если он уже написал, и это работает, зачем мне в этом ковыряться? Он писал не для того, чтобы это разбирали, а чтобы пользовались без необходимости копаться в кишках.
Ну, это зависит от того, чем вы хотите заниматься и где.
---
Давайте я сделаю небольшой лирическое отступление - мой брат играет на гитаре. Играет хорошо (хотя не мне судить) - но работает на обычной работе - играет он для души и иногда в качестве подработок - разные ситуации, в которых можно поиграть каверы.
И вот среди музыкальной тусовки в нашем захолустье встречаются разные люди. Среди них есть молодёжь, которая не может взять и подобрать песню и заметить ошибку в скаченных аккордах из интернета.
Играют просто ну вообще не так, как в песне - но просто хлопают глазами и говорят "а я скачал, ну там вот так вот".
А зачем им в этом ковыряться? Большинство пьяных слушателей не заметит и кто-то, кто в интернеты аккорды загрузил - он же их зачем-то разобрал (пусть и плохо), написал и выложил, чтобы им думать не надо было. В крайнем случае иногда может найти один или два энтузиаста, которые их поправят, им наверное больше всех надо. А не найдутся - да и чёрт с ним?
(О способностях этих людей делать свою интересную музыку стоит умолчать, но это в общем-то им и не надо).
Получают ли такие люди на "подработках" меньшую долю с выступления? Да нет, как-то поровну пилится всё.
С другой стороны и работать с этими людьми не так интересно и приятно. Да и проекты с погружёнными в творчество/ремесло людьми получаются интереснее (да вот только не так уж их и много в узкой своеобразной тусовочке).
---
В случае профессии программиста - глубокие знания не обязательно вам принесут бОльше денег - работал автор поста мидлом не думая об этих ваших указателях - и прекрасно найдёт позицию мидла или сениора на те же деньги, что предложил бы ему в корпорации, а то и больше, да ещё и в рамках комфортного для себя набора компетений. Не пропадёт он.
Но надо понимать две вещи, как мне кажется:
Проводящий собеседование мог вполне себе иметь обоснованное представление о том, нафига нанимаемому нужно понимать что такое указатель.
Речь даже идёт не о том, что ему надо писать какие-то особенные фундаментальные вещи - скорее напротив, из-за бардака.
Ну вот транслируют они свой код из php самописным транслятором в C++, и знает собеседующий, что раз в пару месяцев на дежурстве какой-то сервис - да коркается. И это нужно разгребать. Может ли такое быть? Да легко.
Нафига ему тогда нанимать человека, который не может ответить, что такое указатель и планирует развести руками и сказать "да я вообще-то php-программист, не буду я даже голову тут включать"? Ну он же не совсем дурак ведь.Проводящий собеседование мог видеть некоторую ненулевую ценность в "культуре" (понимать фундаментальные основы и всё такое). Ценность этой культуры может существовать, а может и не существовать - с моей колокольни тут сложно судить.
Я в группе играю несколько лет, несколько лет придумываю себе соляки просто на слух, лишь недавно поверхностно коснулся теории музыки, посмотрел, что определяют тональности, какие ноты куда подходят, но гаммы не заучивал, сочиняю по-прежнему, полагаясь на свой слух. Правда, я этим не зарабатываю, но мне хватает и такого.
Если нужно будет разобраться, как устроено что-то там, то я буду разбираться. А заранее пытаться предугадать, что именно мне понадобится, я не могу, поэтому пока что изучаю то, что мне интересно. Скажем, уже год пытаюсь как-нибудь освоить Go, но на работе он мне точно не пригодится, я же фронтендер, а бэкенд на битриксе. Просто захотелось. Правда, в ущерб учебнику по TS, который я начал читать в 2022, когда ещё был безработным, но как нашёл работу, так его и не брал. Работа мешает мне учиться.
до 2021-го даже не знал, что такое сухожилия, пока не растянул лодыжку.
От вас этого никто и не ждет. А вот если этого вдруг не знает врач первой категории - это крайне странно. А если этот же врач еще и не знает, что такое ЦНС и вакцины - ну тут вообще ой.
Нужно ли погружаться в ассоциативные массивы, если они просто даны языком, как в PHP?
Зависит целиком от ваших интересов и амбиций. Если не интересно и хочется продолжать делать что вы делаете где это не надо? Ну проживете и так и найдете и такую работу, заодно будет времени больше свободного. Хочется делать что-то где надо более углубленные знания? Тогда нужно. Будут ли за это платить больше? Может быть, может быть и нет, насколько это для вас решающий фактор вам решать.
Единственное что обладая глубокими знаниями даунскейлиться проще (если вы умеете писать условный хайлоад, то сайт визитку тоже как-нибудь осилите), но в обратную сторону оно не очень работает.
Вам в жизни то не надо знать как прям конкретно и досконально работает, про открытый/закрытый тип и т.д. (конечно если вы не в перформансе специализируетесь). Вы просто знаете что чтоб положить туда элемент вам надо посчитать хэш и по нему выбрать бакет (то есть тут сложность основная в "посчитать хэш", у всяких строк может быть с этим плохо) и положить элемент. Достать - по хэшу найти бакет и поиском найти там. Отсюда логика подсказывает что если хэш считается плохо и много коллизий (одинаковый хэш для множества разных ключей), то это плохо, так как бакет будет заполнен и процесс поиска в нем скорее всего не быстрый по сравнению с хэшированием (ну и на эти бакеты память нужна). Иииии на этом все. И это еще один из самых сложных контейнеров которые есть обычно в стандартной библиотеке.
Но этим вы покрыли вообще все языки, теперь когда вы открыли документацию и там написано "контейнер super_map реализован через хэш-таблицу", вы знаете как оно работает и зачем его использовать в работе и почему именно этот контейнер, а не какой другой.
В JS мне достаточно знать, что Map сохраняет значение по ключу, где ключ может быть чуть ли не чем угодно, даже функцией. Это же тот же самый способ хранения данных? Как оно устроено внутри, я даже не интересовался.
Кто его знает что там в JS точно если честно, но чет мне подсказывает что функция там тоже по сути своей указатель от которого вполне себе легко берется хэш. Хэш вы в принципе от чего угодно можете посчитать, хоть от рэндомного куска памяти.
> Как оно устроено внутри, я даже не интересовался.
А почему бы и не поинтересоваться? :) Достаточная часть того что я знаю о программировании после всех лет что я им занимаюсь (и продолжаю узнавать) не от учебников, а от "хм, а как это устроено внутри? а как оно вообще работает? а почему оно работает именно так? а как оно еще может работать?"
Ну, оно просто работает, лезть в дебри браузерного движка — это уж перебор. Тем более, что движок скорее всего написан на C или C++, я там ничего не пойму. Если хочется что-то поизучать, то есть много чего из моей области, чего я никак не соизволю освоить.
Ну не спорю что каждому свое и у каждого свои приоритеты (я в свое время добирался до того как конкретно процессоры и память работают физически и логически).
Я к тому что "хм в JS есть мапа.. а что такое мапа? ага, а как вообще мапы работают, что они умеют и какие бывают и почему использована именно хэшмапа тут?", вот вы и на практике разобрали структуру данных, поняли что она умеет, когда в вашем конкретном языке надо выбрать именно ее и почему, и заодно узнали как хэшмапы работают во всех языках, теперь даже в С++ вы пошли посмотрели что unordered_map реализован хэшмапой и сразу знаете как и когда этот контейнер использовать, что сделало, на мой взгляд, вас немного лучшим программистом в широком смысле, чем вы были до того, как задались этим вопросом.
как конкретно процессоры и память работают физически и логически
Что-то на самом базовом уровне нам в универе рассказывали, это-то я в какой-то части понимаю :)
Map работает так, как описано в MDN, а что оно умеет, там же расписано в методах. Всё равно, что браузером ерализовано, то оно и умеет делать. Пожалуй, можно через что-то типа Map.prototype добавить своих функций, но я надеюсь, мне никогда не поставят задачу, которая требует таких извращений. Это означало бы, что мне недостаточно возможностей, которые даёт реализация языка, и что никто другой этого ещё не решил.
У меня в очереди лежат книги по алгоритмам, но я предпочитаю читать художественные книги вперемешку с научпопом, а до учебников добираюсь очень редко — нет ментального ресурса.
Это означало бы, что мне недостаточно возможностей, которые даёт реализация языка, и что никто другой этого ещё не решил.
А теперь представьте, что нанимающему вас челу нужно, чтобы вы решали задачи, которые за вас никто не решил реализовав библиотеку.
И если библиотека взорвётся на проде, то у вас не будет опции "развести руками и сказать, что какие-то другие более умные разработчики накосячили" - в лучшем случае за неё отвечает либо точно такой же коллега, как вы, но сидящий в соседней команде, либо вы сами. И у чатгпт спросить не выйдет - эту библиотеку десять лет назад написал ваш бывший коллега, который был на этой позиции и нанимался примерно с таким же багажом знаний, как и вы, наружу его никто не выкладывал из пределами вашей корпорации - да что уж тут, за пределами вашего продукта, одного из полусотни в пределах корпорации - никто эту библиотеку никогда в глаза не видел.
Собеседующий чел может вполне себе знать, что вам придётся поддерживать внутреннее дерьмо - и совершенно справедливо решить, что мидл, который получив задачу скажет "ну для этого библиотеки нет, не мне же их писать" - ему в команду не очень подойдёт.
Ну или нанимающий чел думает, что ему это нужно, возможно в этом ошибается (Например, потому что сам пришёл из другого отдела, где разработчики на этой позиции такие задачи решают, тут конкретно оно может и не пригодится, но что поделать).
---
В любом случае, собседующий чел не решает задачу "провалидировать, что вы, будучи мидлом, можете гордо носить имя мидла", как этого ждёт автор исходной статьи.
А теперь представьте, что нанимающему вас челу нужно, чтобы вы решали задачи, которые за вас никто не решил реализовав библиотеку.
Дадут задачу — тогда и буду разбираться, лишь бы время дали. Но вообще, я перед трудоустройством смотрю список рабочих обязанностей. Если там есть "вам нужно будет разрабатывать библиотеки и фреймворки", то я и пробовать не буду к ним устраиваться, потому что это не мой уровень. Я же понимаю, что я что-то умею, а что-то не умею.
Я, вообще, программированием занялся из интереса, а всякие умные книжки интересу мешали, поэтому я изучал всё, хоть и с помощью учебников, но во многом на практике, и не лез в те области, с которыми мне было не весело разбираться. Мне весело было сделать сайт с каталогом своих фильмов, чтобы он сам парсил описания с рутрекера, — я сделал. Мне скучно было делать поиск по этому сайту — я не сделал, поэтому уже 15 лет вывожу полный список фильмов и жму ctrl+f.
А потом так жизнь сложилась, что я стал зарабатывать своими умениями. Ну, не обучился я, прикладную математику не заканчивал. До сих пор есть вещи, которые мне не интересны.
Общие принципы работы хеш-таблиц не менялись уже больше 70 лет, а знания деталей реализации в конкретном языке от новичка обычно не ждут. Кстати, в учебниках по Go описывается устройство map'ы.
Может ли человек учить, что не надо делать, если он сам пытался устроиться во vk?..
У меня вызывало удивление php и highload в одном предложении.
И это вовсе не претензия к кому-либо, я просто думал что php для мелких проектов и вообще давно умерло. А оно вон как!
Периодически практикую хождение по собесам чтоб поддерживать знания в актуальном состоянии. Весьма полезно.
Вы исходите из того, что собеседующие держат руку на пульсе технологий и задают актуальные вопросы?
в большинстве случаев да. Так как вакансии появляются из-за потребностей бизнеса, которые на прямую зависят от реалий.
Например: магазин разрабатывает приложение, так как клиенты пользуются приложениями конкурентов.
Продуктовая сеть внедряет доставку, так как клиенты предпочитают заказывать продукты на дом.
Нагрузки и данные растут, нужны БД с поддержкой репликаций и шардированием. От сюда растет потребность в аналитических БД - привет кликхаус. Меняется архитектура от монолитов к микросервисам с шинами (Kafka, RabbitMQ).
Админы не справляются, появляется devops.
И т.д.
Лет через 20 придумают что-то еще. С нетерпением жду.
Ну, не знаю. Когда я уволюсь со своего нынешнего места, они опять будут искать человека на Vue2, потому что проект никуда не денется.
Для легаси да, к сожалению, но иногда их тоже распиливают и переписывают, когда накладные расходы на сопровождение превышают создание заново.
Создание чего-то с нуля, да ещё на передовых технологиях, это для меня отдельная вселенная, я там никогда не бывал.
Когда на прошлой работе только внедряли Vue, я написал один сайт за несколько месяцев, до сих пор стыдно за компоненты по 500 строк html-шаблонов с кучей v-if. Но я тогда ещё не понимал, как с этим работать. Поэтому сейчас стараюсь как можно лучше изучить то, что собрался использовать, а то проект сразу после написания превращается в легаси.
Вопрос: что такое "О-нотация".
Неужели вы за всю карьеру ни разу не обсуждали с коллегами сложность и оптимальность вашего кода? Я когда джунам ревью проводил, то там в каждом втором ПРе писал что-то типа "тут линейная, хотя вот так можно сделать константу". Потому что джуны любят в базу ходить в цикле. И все понимали, о чем речь. Это не какая-то яйцеголовая БАЗА из недр мехмата, а просто термин ежедневного использования. Когда мне вот настолько резко глаза открывают на собесах, то я обычно говорю "спасибо за науку", а не жалуюсь.
Автор выше уже писал - он обсуждал алгоритмическую сложность, просто именно О-нотацией её ни разу не называл.
Да, бывает такое, что не обсуждали. Я за ~10 лет работы, пожалуй, никогда ни с кем не обсуждал свой код. Не потому, что я не хочу, а потому что в рабочее время никому такую задачу не ставят, а в нерабочее кому это надо?
Один только раз после игры в теннис напарник помог мне понять, как разбивать компоненты в vue на более мелкие части. Я тогда только-только постигал это всё. Возможно, что и сейчас не совсем правильно постиг, но кто бы оценил?
Я за ~10 лет работы, пожалуй, никогда ни с кем не обсуждал свой код.
в смысле, у вас в команде code review вообще нет?
У нас нет команды как таковой. На прошлой работе мы начинали маленькой компанией в три человека, одним из которых был директор, потом выросли до ~40-50 человек, я то делал какие-то интернет-магазины наполовину самописные, то потом перешёл во фронтенд, но всегда работал один, потому что у каждого фронтендера в компании были свои проекты. Крайне редко со мной в пару ставили кого-то ещё, с кем можно было разделить задачи. А бэкендеры работали сами по себе. API в сваггере описали — мне и достаточно. Если есть баги или вопросы — пишу в рабочий чат. В среднем как-то так я работал около 8 лет.
На нынешнем месте я единственный фронтендер, остальные 3 человека пишут на PHP. Недавно их было больше, но сейчас столько. Некому смотреть за моим кодом. Да и у них, если конфликтов нет, то всё идёт на тестовый сервер и там тестируется. Я иногда смотрю в PHP, потому что у нас на самом крупном из проектов — битрикс, всё переплетено, и могу дать обратную связь бэкендеру, который со мной его пишет. Всё же, я знаком с синтаксисом PHP и могу понимать некоторые вещи, которые не связаны с функциями битрикса. Иногда, если сервер выдаёт ошибки, а уже ночь, то я сам могу заняться дебагом и найти причину (то за null не уследили, то в массив ключ не добавили, потому что if не сработал).
Из моих последних достижений — уменьшение размера js+css (два больших файла) с 16 МБ до 3.9 МБ, ещё и с разбивкой на модули, которые загружаются только если нужны. Это всё висело годами, но я наконец решил заняться вопросом и оптимизировать. Настолько всех всё устраивало. Поэтому какой-то неоптимальный код или плохие имена переменных — это вообще не проблема.
Я хотел бы, чтобы кто-то посмотрел мой код и что-нибудь подсказал. Я несколько лет не знал, что в vue есть provide/inject, и занимался просовыванием пропсов и событий туда-обратно через цепочку компонентов. В какие-то моменты даже стал слать события через window.dispatchEvent(). Может, есть что-то ещё, что хорошо было бы узнать.
Извините, поскольку PHP и highload упомянуты в разных предложениях, что абсолютно верно, я всё-таки не понял на чём вы пишите highload сервисы?
И тут я понял почему ВК такая помойка!
Нанять 5 разработчиков по итогу 20 техинтервью - это, конечно, эффективность, вызывающая лютую зависть. Вашим HR, осуществляющим предварительный отбор, надо поставить памятник.)
Вторичный скрининг резюме я проводил самостоятельно. Грубо говоря, давал первичные инструкции HR по требуемым навыкам. Если отклик удовлетворял, резюме направлялось мне. Много отсеивал из-за отсутствия инфы в «обо мне», и подробного описания выполняемых задач на предыдущих проектах. На собеседования приглашали только с моего одобрения. Вероятно оттуда и эффективность, так как я уже на этапе чтения резюме мог сказать, кто мне как коллега однозначно не подойдет
Хотел сначала прокомментировать конкретику описанную в статье, но позже понял что в этом нет смысла, автор считает что он один "Д'артаньян" и мир должен быть устроен так как считает автор, все остальные же не правы по его мнению, эти настроения видны как из стиля самой статьи, так и из желания ответить/доказать что-то каждому комментатору.
Этот характеризует автора в первую очередь как не зрелую личность в плане возраста и жизненного опыта, это не хорошо и не плохо, это просто факт.
Добро пожаловать в реальный мир, он разный, с разными требованиями, людьми, сложившимся контекстом и в конце концов задачами которые потребуется решать. Как правило очень редко есть что-то плохое или что-то хорошее, злодеи или "Д'артаньяны", есть контекст результатом которого является многое. В одном случае важно одно, в другом случае другое. И если где-то, что-то не так как тебе нравится с великой долей вероятности, это не значит, что кто-то плохой, просто у них не так как у тебя и все.
А тебе уже решать что с этим делать, дальше "вариться в своем соку" или тратить усилия, адаптировать себя (навыки, характер, знания) по требования других, все просто.
По хорошему автору задуматься о саморефлексии, подумать о том, что он хочет в будущем, бороться с ветряными мельницами в пустую или работать над собой.
Не стоит забывать о том что софты важны не менее чем харды, я бы сказал что они являются важной составляющей дальнейшего роста разработчика необходимость для следующих ступеней/ветвей (синьер, тим/тех лид, архитектор, продакт и тд).
Он окончил в прошлом году образование с квалификацией бакалавра РТУ МИРЭА и сейчас учится на квалификацию магистра (судя по его vk), думаю, предположить возраст не составляет труда.
Ба, ещё и красный диплом...
Яркий пример того, на сколько бесполезно требование высшего образования в вакансиях.
Ну в высшем образовании есть здравое начало, как минимум потому что самому ты вряд ли сможешь самостоятельно собрать весь спектр знаний, который тебе дают в вузе, юуквально по крупицам. Я к тому, что большинство "вошедших" узнают о чём-то только в процессе решения проблемы, в то время как нормальный специалист с нормальным высшим уже понимает как решать. Хотя это не отменяет того, что есть хоршие спецы и без высшего профильного.
Проблема скорее в том, что либо вуз не оставил после себя даже минимальных знаний, и тут либо вопрос к вузу, почему не дал ровным счётом ни-че-го, либо сам человек мошенник, который читерил за красный диплом. Что в целом ставит под сомнение качество высшего образования и необходимость наличия корочки.
Сталкерить людей нехорошо :)
С каких пор узнать общедоступную (да и не только) информацию об авторе статьи, считается "сталкингом", в вашем понимании.
В профиле у меня этой информации нет. Значит надо гуглить ФИО, либо никнейм. У меня такого желания никогда при прочтении статей не возникало, а Вы вон даже до ВК успели дойти
У меня такого желания никогда при прочтении статей не возникало
И снова вы пытаетесь выставить себя эталоном. "Я этого не знаю" = "это на позиции миддла не нужно", "У меня не возникало желания это делать" = "это нехорошо". Не очень хорошая тенденция. :)
Значит надо гуглить ФИО, либо никнейм.
Это то, что сделает практически любой ответственный HR на позицию выше джуна. И если в резюме и публичных данных видны явные противоречия - готовьтесь к тому, что вас или не позовут на собеседование вообще, или зададут логичный вопрос о расхождениях.
А комментаторы выше видимо все как на подбор, HR-ы и IT рекрутеры, раз решили меня загуглить?
При скрининге кандидата - это норма. В кейсе выше - нет.
Странно, конечно, не знать, чем отличается бинарный поиск от линейного, даже я на собесе смог объяснить это, хотя я всего лишь QA, даже не джуниор разработчик. А тут человек - миддл
Уверен, в комментах это уже написали, но кратко что я понял из поста:
Автор на собесах задает вопросы, в которых он хорошо шарит, интервьюер действовал так же, однако скоуп вопросов не совпал. Вот незадача )
Про терминологию, согласен, вполне можно иметь опыт и применять на практике ходовые алгоритмы и подходы (паттерны), оценивать сложность (О-нотация) алгоритмов и т.п., при этом не зная что у них у всех есть названия. Но справедливости ради, определения и термины как раз не сложно освоить при подготовке, да и удобнее будет говорить на одном языке.
Автор когда сам ведет собес, больше упирает на "софт-скилы", "сработаемся ли мы с человеком по характеру" и знание непосредственно предметной области автора. Это конечно классно, когда ты находишь человека сразу "в контексте", но шансы найти такого сильно ниже, чем просто хорошего профессионала. Отмечу еще, что собесился он не на конкретный проект, а просто в контору, и конкретная предметная область таки еще не известна.
Одним словом автор собеседует правильно, остальные неправильно.
Автор, ну сплошной же вин-вин, что для вас, что для ВК ))
Если серьезно, что означает ваше незнание O-нотации с точки зрения интервьюера: человек не читает про алгоритмы, а если читает, то у него в голове не откладывается. Незнание же про DNS от человека с несколькими годами в веб-разработке у меня бы вызвало подозрение, что опыт просто липовый. Не умение настроить что-то там, я сам во всяких сетевых вещах чайник и обращаюсь к специально обученным коллегам, но не знать сам термин??
Мне интересно, а какого уровня ответ про DNS был бы удовлетворительный?
"Ну есть такие сервисы, ты им домен, они тебе ip адрес. По домену компьюеьры не связываются, а по адресам связываются" или нужно прям подробно рассказать, как они устроены внутри, какие существуют, как и где настраивается, как происходит таинство синхронизации серверов, какие виды записей существуют?
если бы я спрашивал то ""Ну есть такие сервисы, ты им домен, они тебе ip адрес. По домену компьюеьры не связываются, а по адресам связываются" - такого было бы более чем достаточно, разве что если бы человек ответил я бы еще попробовал про ARP спросить, потому что сталкивался с тем что люди путают ARP и DNS (MAC и IP соответствено) но это был бы опциональный вопрос на прощупывание глубины знаний если они есть
Не знаю, в ВК были самые интересные собеседования, что у меня были в России.
Однажды я просто пришел посреди бела дня не подав резюме и не давая кантактов, пообщался на Невском с командой "по зарабатыванию бабла", узнав море интересных подковерных секретиков и ушел как ни в чем не бывало, недовольный озвученой инфой, молодой и идеалистичный.
Другой раз, я без малейших проблем организовал собеседование на главного архитектора на задачу по переводу всего VK с монолита, собеседовать меня отправили пхпшников, насколько я понимаю, даже не являвшихся лидами и качество собеседования было конечно не очень, но мы общались по телефону без всяких зумов, бродя по улице, поэтому не удивительно, что не смогли друг друга понять. Но не испытал никаких негативных эмоций и опять же много узнал о внутренностях VK, а вопросы были нестандартные и сильно глубокие(на уровне железа), сразу видно, что ребята готовились, резюме читали, а не пришли по шаблону опрашивать.
Везде бы так собеседоваться, - быстро, эффективно, без головотрепки, без зума и тп.
Боже, как я настрадался даже пытаясь общаться с HRами других компаний, столько времени слито HRами и копипастерами вопросов из интернета вникуда, столько абсолютно некомпетентных людей задающих абсолютно позорные для себя вопросы и готовые стоять на своих заблуждениях до конца.
Сравнение.
Собес в Европе недавно - задачка с протоструктурами van Emde Boas tree на 30 минут.
Собес в России в VK, что такое О нотация. - Жесть вообще валят сволочи, кошмар и ужас.
Никогда не слышал термина. Зачем оно надо вообще.
Видимо каждая первая книга по алгоритмам и википедия с большими черными буквами - Big O notation это редкость сейчас.
Что сказать мне бы такие собесы.
В остальном
Лет 5-8 назад вас с таким уровнем даже на стажера бы не взяли не говоря уже про Middle.
Я, собственно, написал чуть выше, как это выглядело с точки зрения собеседующего: про алгоритмы ничего не читает, а если и читает, то в голове не откладывается. Проблемы же с DNS у человека с заявленным опытом в веб-разработке у меня бы вызвали подозрение, что опыт липовый )
Так вы посмотрите с какой скоростью эту статью лайкают и как летит репутация автора вверх.
Вот такой текущий уровень большинства разработчиков в России.
Я помню я в 2017 жаловался на уровень разрабов.
А они то просто гуру программирования были по сравнению с вот этим.
От фразы - Я - тот кто настраивал на сервере ssl шифрование через certbot-а )))
Я до сих пор не могу остановиться ржать.
Прикол в том, что такие деревья работают с ключами определённого типа. Там хитрость в том, что в качестве ключей берётся домен битов чисел от 0 до 2 ^ m.
Соответственно, манипуляции с битами дают ещё один логарифм, в итоге получаем, что log(log(m)) вместо log(n) для очереди с приоритетами.
А вообще, некоторые алгоритмы быстры только потому, что Мы сужаем окно поиска, добавляя ограничения (Constraint Programming).
Вот только что посмотрел в вики метод (ну в принципе основная идея ясна, хоть и мельчить ближе к листам не всегда полезно) и... мне трудно придумать реальную задачку на van Emde Boas tree кроме как "реализуйте van Emde Boas tree".
Когда долго работаешь в одной теме, мозги замыливаются. А уж знания в "академической" формулировке выветриваются начисто!
Меня на собесе спросили "что такое позднее связывание", я сижу и хлопаю глазами как баран.
При том, что динамической перегрузкой пользуюсь постоянно :))))))))))))))))))))))))))
Простите, но какими вы будете заниматься оптимизациями, если не знаете, как и что оптимизировать и как это измерить/оценить?
Вы "можете рассказать и про типы индексов", но "не помню по какому принципу там эти деревья строятся", "я не помню как работает хеш-таблица" и "я не помню, чем бинарный поиск отличается от линейного". Так где правда? Вы не сможете рассказать ни про индексы, ни про типы индексов, если вы не понимаете, как они устроены. Рассказ "ну индекс он это самое... поиск ускоряет" — это не рассказ. Как вы поймёте, выгодней построить индекс по (datetime, user_id) или по (user_id, datetime)?
Да никак.
Ну ничего необычного, у нас теория и статистика дороже практики🤣
Шоб такое?
https://aliexpress.ru/item/1005006896923674.html
Дико извиняюсь! Пушнул не в то окно!
Можно удалить?
Я блин сам в бэке на пыхе (джун правда), я просто не могу представить, чтобы мидл не знал что такое ДНС, уровни ОСИ, О-нотацию. Это еще только то, о чем автор написал, представляю, что там всплывет, если глубже капнуть. Кроме того, реакция на критику - это поведение типичного подростка, когда все неправы, один он мушкетер. Тяжело быть подростком, не знаешь как с гормонами справиться.
Полностью согласен!!
И поздравляю вас вы по нынешним меркам Senior уже!!
Со сложностью и ДНС да, а Вот с уровнями ОСИ не согласен при этом, где вот они реально нужны чтобы их все наизусть знать?
Они реально не нужны, но этот вопрос просто ооочень любят задавать.
С другой стороны, если собеседующего не удовлетворил ответ "это старая, часто имеющая мало общего с реальностью концепция" и он настаивает прям на перечислении "Каждый Охотник Желает Знать Где Сидит Фазан" - это звоночек.
Да, мне кажется нужно отделять что в современном мире используется а что уже не используется в работе от слова совсем. Местами тонкие грани конечно но в случае ОСИ даже если сетями работаешь уже крайне редко надо, ну разве что драйвера и прошивки сетевых устройств.
Реально знать, какой из них какой, в принципе и не надо, но понимать, что есть Ethernet, над ним ARP, над ним IP, над ним TCP и т.д. как бы хорошо.
Автор прекрасно знает структуры данных и множество чего и разницу между сортировками. Фишка в том, что посыл в этой теме изначально другой. Собеседующие в край ахуели требовать и спрашивать с кандидата тупые базовые вопросы. Я не часто хожу по собесам, т. к. не люблю свияиться с места на место. Но иногда посмотришь собес программиста на какой-то блять стартап в шарашкину контору и ловишь кринжа. Чел спрашивает про сортировки программиста, который 15 лет в этом деле крутиться...
. Чел спрашивает про сортировки программиста, который 15 лет в этом деле крутиться...
представляете какой кринж когда приходит чел с опытом 15 лет, и не знает базовых вещей, просто вообще не знает..он с ними не сталкивался, все 15 лет xml руками перекладывал
Не обязательно XML. Сын - у них там на работе плюсовика ищут - рассказывал, что как-то пришел к ним кандидат, лет за сорок с соответствующим реальным стажем в программировании, который не знал, как с итераторами работать: а они ему были не нужны - он сидел где-то в полугосе типа Росатого и какие-то там численные рассчеты делал, так что ему массивов с циклами по жизни хватало.
Чел спрашивает про сортировки программиста, который 15 лет в этом деле крутиться...
Кручусь в этом лет 20, могу написать сходу несколько сортировок/поисков потому что когда-то их видел и они просто банально логичные (бинари серч - дай рэндомному человеку телефонный справочник и попроси найти по имени, этот человек будет плюс-минус бинарным поиском искать). Сортировки стоит пару раз увидеть и понять и уже не забыть как они работают. Структуры данных - в каждом языке есть контейнеры, чтобы понимать какой юзать все равно стоит пойти в документацию и посмотреть какие структуры данных внутри и почитать про них если не знаешь. Никогда не готовился к литкод задачкам и никогда у меня не было проблем их решать на интервью, потому что в 99% случаях там просто стоит 5 минут подумать и здравым смыслом решить задачу.
Сортировки стоит пару раз увидеть и понять и уже не забыть как они работают
А как на счёт их названий? Слиянием/вставками/выбором, как это всё запомнить? Я помню, что сортировка слиянием вроде бы делит всё "пополам" на "меньше" N и "больше" N, потом рекурсивно ещё пополам, пока не останется 1-2 элемента, потом всё склеивает. А может, это и не она.
Как-то раз хотел написать сортировку пузырьком и не смог o_O Получилась тоже с двумя циклами, но которая меняла не соседние два элемента, а i-й элемент от начала, находя для него наиболее подходящееся значение из оставшихся N-i.
Ну лично мне кажется названия логично вытекают из реализации (или наоборот). Пузырьком - максимальный/минимальный всплывает наверх. Вставкой - вставляешь элемент как карты в руке сортируешь. Слиянием - разбиваешь и мержишь пока идешь назад (вы просто по названию прикинули логику как оно работает и угадали, я про это и говорю). Квик сорт - да, тут уже не о чем не говорит. Но в общем и целом никогда не встречал чтоб спрашивали - напиши сортировку пузырьком. Что-то пишешь пока задачку решаешь, если надо написать, и не важно как оно называется.
Во, недавно смотрел, как работает квиксорт, всё понял, но сейчас уже не помню, что там было. Вроде бы, что-то рекурсивное.
Мало кто помнит все от и до.
Ключевая идея - выбрать опорный элемент и сделать так, чтобы все элементы меньше опорного были слева, больше справа.
Больше ничего помнить не надо. Все остальное можно додумать по ходу дела. Приблизительно также и по другим алгоритмам, никто на память код не учит
Хм, это же то, что я описал в merge sort. Тогда я не помню, что такое merge sort.
Merge рекурсивно делит массив на подмассивы из 1-2 элементов, сортирует их, затем рекурсивно поднимаясь вверх происходит слияние подмассивов.
В быстрой сортировке мы сначала сортируем относительно опорного, а потом рекурсивно повторяем для левой и правой части. Фаза слияния остутствует - сортировка происходит на месте.
Интересно, что у этих алгоритмов разная сложность по памяти и времени, что дает почву для разговора на собеседовании.
Ага, общий принцип всё же схож, поэтому я их перепутал.
Насколько помню, для слияния массивов A и B нужно создавать временный массив размером AB и как-то хитро с помощью двух указателей ходить по A и по B, выискивая, где меньше.
Как то хитро это буквально: смотрим на первый элемент A и B, оба A и B отсортированы, какой элемент меньше? Если элемент А меньше, то он и есть самый маленький, так как все элементы в А дальше больше, первый элемент В тоже больше и значит вообще все элементы В больше (так как оба А и В отсортированы, то есть этот элемент А меньше самого маленького в В, а значит меньше всех). Забираем этот элемент в новый массив.
С этим элементом разобрались, надо разбираться с остальными, теперь смотрим на второй элемент А (с первым только что закончили) и на первый В. Если первый элемент В меньше, то он меньше всех элементов в А и сейчас он самый маленький. Забираем его в конец финального массива, теперь смотрим на второй элемент А и второй В. Продолжаем пока все не скопируем в новый массив.
Вот и вся хитрость.
Я могу это написать, я же решаю задачи на литкоде. Просто, это то место, где можно ошибиться, случайно забыв, где конец массива. Или продолжая сравнивать элементы, когда один из указателей уже дошёл до конца и дальше можно уже не сравнивать.
А вы квиксорт себе в голове в pivot sort какой переименуйте и станет легче :)
Выбираете рандомно элемент в массиве (Pivot) все что меньше бросаете слева, все что больше - справа. Что станет с этим пивотом если слева будут элементы только меньше него, а справа только больше? Он будет стоять на том же месте, на котором он стоял бы в отсортированном массиве, условно мы отсортировали этот элемент. Но справа все как попало и слева как попало, так значит надо сделать то же самое для всех элементов справа (ну до элемента который уже был поставлен правильно на предыдущем шаге очевидно) и слева, пока мы не поставим так все элементы на свои места (то есть все элементы не побывают пивотом). Всё, массив отсортирован. Сможете по этому уже написать код? Да скорее всего, может не оптимально напишете шаг с переброской элементов, но какая разница, тут уже можно загуглить, главное что поняли что происходит. Согласитесь в этом есть своя простота и элегантность.
Ну всё, перед вами большой, страшный и сложный квиксорт которым на хабре в комментах сеньоры и мидлы любят пугать друг друга.
А, сложность. Ну в общем случае массивов где вы не можете делать предположения о данных вам обычно надо либо сравнить каждый элемент с каждым (n^2), либо у вас вылезет "разделяем массив на сколько-то там частей и что-то там делаем с каждой частью" что по сути дает вам дерево с количеством уровней - если условно делите на две части более-менее сбалансированно, на первом уровне будет 1 кусок (весь массив), на втором 2 (две половины), на третьем 4 (по две половины двух половин) и т. д. то есть логарифм с основанием 2 (не важно на самом деле) от n таких уровней (нарисуйте дерево если не понятно почему), ну и на каждом уровне вы обычно трогаете все n элементов, то n шагов log(n) раз. Ну и всё. В случае с квиксортом там просто надо запомнить что в среднем будет n log(n), но есть и случай когда вы выбираете каждый раз левый элемент в уже отсортированном массиве. Есть формальное доказательство что в среднем квиксорт nlogn даст, но вам оно не особо надо.
Вроде все просто и логично. Автор говорит что его одногруппники зазубрили по этому скорее всего скажут сложности как написать сортировки те же, но на самом деле наоборот, если зазубрить, то оно сразу же и вылетит, если реально понять один раз, то останется навсегда.
Опуская момент с уровнем вопросов, на собесе важно посмотреть как кандидат будет себя вести когда не знает ответа, раздражается, отстраняется, или рассуждает и задает наводящие вопросы, эта реакция важнее чем знание техники. Так что "тупые" вопросы всегда будут, и хорошо там где их задают, значит попадешь в нормальный коллектив.
Обсуждение алгоритмов поиска и сложности напомнило мне про один собес, лет 15 назад... Обсуждали собственно поиск и сложность.
Я там предлагал всякие варианты за исключением пузырьковой. Чел говорит - ну я ожидал услышать бинарный поиск. А я такой - стоп, это же надо массив сначала отсортировать поэтому сложность будет "сложность сортировки" + "сложность поиска" и не факт, что быстрее, надо считать. Он такой - ну мы из БД возьмем, там же есть order by. Я - хлоп хлоп глазами - "а что order by это разве не алгоритм сортировки со своей сложностью?". Меня не взяли.
А автору - не расстраивайтесь - вк, яндексы и прочие фаанги - в какой-то мере задроты (помнится тут была статья, как у человека было 7 собесов по алгоритмам в яндекс - "ну наверное хотят проверить базовые вещи" и так 7 раз). Невелика потеря. Зарплаты там не космические, и легаси там тоже присутствует (см на днях статью от яндекса про БД, там у них пхп и mysql 5.7).
Пожалуй самое обидное - это узнать, что ты чего-то не знаешь, и отсюда негодование "да че они такие тупые вопросы задают". Ну у всех наверное так было (у меня было) - но я пошел развиваться (про DNS до сих пор толком не знаю xD, недавно наш dev ops мне рассказывал, что wildcard не будет работать так, как я хотел). С возрастом опытом приходит понимание - чего ты не знаешь и это нормально. И уже на очередном собесе в Ozon - я сразу сказал, что структуры не использовал, на заковыристые вопросы не отвечу, как перформить перфоманс с их помощью - не знаю. Давайте следующий вопрос. Но это не помешало им сделать оффер (от которого я отказался).
Можно любить или не любить такого формата собеседования, но они показывают, насколько часто вы заглядываете "под капот" и как глубоко стараетесь изучить инструменты, с которыми работаете. Также есть база, которую никто не отменял в виде алгоритмов и структур данных, SOLID, шаблоны проектирование и прочее. Эта база помогает писать структурированный и легко поддерживаемый код.
Просто для информации, указатели есть в PHP неявно. Они используются при работе с объектом, если вы присвоите объект другой переменной или передадите его в качестве аргумента функции, то тут как раз будет указатель, а не ссылка, как многие думают)
И как выше видел, вы писали, что люди это зубрят. Я это все не зубрил, а просто изучал, ковырял и старался понять, как это все работает, применяя на практике. И не потому что это спрашивают на собеседованиях, мне это интересно) Я даже больше скажу, мне даже было интересно опустить уровнем ниже, до Assembler, поковырять его, понять как работать с регистрами процессора. Потом пошёл ещё ниже, уже на изучение проектирование процессоров (пока FPGA / ПЛИС). Про такое уже на собеседованиях не спрашивают, но для меня это приятное хобби и зарядка для мозгов)
На самом-то деле все выглядит по-другому.
В программировании 100500 вещей, которые можно раскопать. На раскопки каждой может уйти и час, и день, и неделя.
Далеко не каждый работодатель будет ждать неделю, пока программист раскопает условные указатели или сетевой протокол или какую-нибудь там ошибку в недрах фреймворка.
Поэтому и появился стековерфлоу и народ им активно пользуется.
Раскапывать во внерабочее время в принципе можно, но у людей могут быть и другие жизненные интересы и хобби.
И как результат функции оптимизации - народ раскапывает / зубрит то, что спрашивают на собесах (указатели, сборщики мусора, хеш таблицы, асинк-авайты и тп). Или то, с чем он реально работал и у него было время на это.
Касаемо указателей, то вроде есть и явно же, но урезано. Я про алиасы &$var. По идее, когда мы, передаём скалярные типы данных или массивы, то передаётся копия переменной. Если переменная является объектом, то алиас не нужен и по умолчанию передаётся ссылка на объект.
Это как с вещественными и ссылочными типами в C#)
Ссылка и указатели это немного разные вещи. Но в интернетах нет простого объяснения на пальцах. Аналогично - чем отличается интерфейс от абстрактного класса. Вроде бы одно и тоже, но есть ньюанс.
C# по умолчанию работает со ссылками, а вот если использовать unsafe блоки кода - то там можно использовать указатели.
Не хочу быть очередным капитаном, но раз хочется что-то написать в комменты, то напишу что рад за кого-то кому так легко удается нормальный небольшой продакшн поддерживать силами одного PHP-разработчика, и если бы он знал чуток базу то свалил бы в какой-нибудь ВК, так что правильно что наняли кого-то кто не знает :-).
Серьезно, сложно же найти такого человека адекватного? (статья то вроде неплохо написана)
>на основе какого ЯП мне удобнее всего будет проводить интервью (мы же вроде на PHP разработчика подавались, нет?).
Вполне могут прийти разработчики, имеющие богатый опыт на PHP, но в данных момент пишущие на другом ЯП.
>Указываю интервьюеру, что указателей в PHP не завезли, рассказываю про ссылки и принципы работы с ними
Эмм мне периодически приходится их использовать или видеть например в функциях, изменяющих объекты. Хоть так делать всякие клин коды запрещают, но иногда так удобнее. Максимально простой пример:
function addItemToList(array &$list, mixed $value): void
{
$list[] = $value;
}Так что указатели есть и вполне себе иногда используются. Хотя это и не указатель, как в С++ том же. Указателей из С++ так, то нет в PHP именно с тем функционалом. Забавно, что походу интервьювер принял алиасы за указатели.
> Вопрос: что такое "О-нотация".
В комментариях на эту тему развели холивары, но многие программисты реально могут не знать этого. Биг О, массово захайпилась относительно недавно благодаря блогерам, ШП и т.д.. Конечно в книгах по алгоритмам Биг О описана очень давно, но отрицать, что лет 15 назад о ней знали только "олимпиадники" будет сложно. Имхо ответить на него хоть как-то, в теории возможно, учитывая что о Биг О сейчас трындят из каждого утюга (причём не каждый утюг ещё понимает о чём говорит). Так что, почему холивары на эту тему появились вполне понятно.
> Можете закидать меня тапками, но нет, я не помню, чем бинарный поиск отличается от линейного, не помню по какому принципу там эти деревья строятся, я не помню как работает хеш-таблица
Тут автора могу понять но в бигтехах всегда задают вопросы по компьютер сайнс. Сам знаю тему алгоритмов на минимальном для работы уровне, однако периодически мне требуются и хэш таблицы, и очереди и даже понимание бинарных деревьев с базовыми операциями (всякие вертикальные, горизонтальные поиски) для работы с ними. Банально недавно пытался написать риадер сэйвов для одной игры, а там все данные хранятся в бинарных деревьях, думаю понятно почему. Опять же на пхп с деревьями не сталкивался, нл с хэш таблицами и стэками редко, но бывало. Самого бесят "стажорские" задачки, но как писал ранее их спрашивают в бигтехах всегда и у всех.
>не знал что ответить на вопрос: что такое DNS
Это ещё пожалели и не спросили про все уровни OSI, какие бывают алгоритмы расчета Load Average и как определить MTU (в мэил ру это обожали у всех спрашивать, даже у фронтендероа). :) Ну бывают затупы. Опять же вопрос понятно ради чего задавался. Бэкендеры по идее должны знать, минимальную базу по сетям.
> Что больше всего удивило - полное отсутствие вопросов про паттерны разработки, про архитектурные подходы и методологии проектирования.
Потому что видимо ВК попыталась перенять систему западных бигтехов, где нет узких специалистов, а есть инжинер-разработчики, которые от проекта к проекту работают с разными стеками и ЯП. Поэтому в западных бигтехах гоняют по компьютер сайнсу (алгоритмы, структуры данных, сети, БД, ООП, программная инженерия и т.д.). Почему интервьюверы не спросили про ООП, правда странно. Может в ВК его не используют и PHP код там не менялся со временем 5-ой версии или интервьюеры сами за него плохо шарят. Однако, касаемо бизнес специфики, то в зпападных бигтехах её спрашивают редко. Считается, что ты, как инжинер должен смочь в короткие сроки быстро разобраться со спецификой любой технологии или ЯП. Однако, почему ВК ищет узкого специалиста, но не задаёт вопросы по специфике фиг знает.
Если честно, такие собесы-экзамены, мне не особо нравятся, но в бигтехах это норма. Сам бы я кстати 100% посыпался на вопросах о БД, а точнее о транзакциях и всё, что с ними связано, т.к. использую MySQL, разрабы которой сами рекомендуют не использовать транзакции... Но этот пробел в ближайшее время восполню, т.к. перелезаю на постгрес, а там вроде с ними всё ок.
но отрицать, что лет 15 назад о ней знали только "олимпиадники" будет сложно.
Первое издание Cracking the Coding Interview вышло в 2008-ом году) Я бы сказал, это значит, что в бигтехе (особенно, западном) литкод-стайл задачки + рассуждения про сложность уже тогда были не новостями, а "старостями".
Если посмотреть про русский бигтех... Ну вот прямо тут вопрос от 2011-го года - https://qna.habr.com/q/5783
Далее уже ближе к телу: какие контейнеры из СТЛ знаю, какая сложность работы при вставке элементов в list, set,… ну и прочее.
Не знаю, откуда вы это берёте про "раньше этого не спрашивали", но нытьё про "зачем в яндексе алгоритмы спрашивают" было на хабре и пять лет назад и 10 лет назад, за 15 разве что сказать не могу, маленький я тогда был для алгсобесов - но готов поспорить, что где-то кто-то ныл про них и тогда.
Если у вас всё замечательно с индексами субд, то какие тогда могут быть проблемы с хэш таблицей? Если же у вас есть проблемы с хэш таблицей, то я не уверен, что вы до конца понимаете индексы субд.
Наверное в предыдущих комментариях уже сказали, но размер типов переменных в байтах не имеет никакого отношения к О-нотации, и упоминание их в одном абзаце показывает возможное непонимание что такое О-нотация.
Если вы говорите, что за 4 года никогда не столкнулись с необходимостью знать разницу между линейным и бинарным поиском- вам может просто казаться, что не столкнулись. Я вспоминаю пару джунов которые все данные искали вложенными циклами с линейным поиском, и при небольшом увеличении массива все начинало дико тормозить, и им даже не приходило в голову это реорганизовать. Это может быть с использованием любого языка программирования. Эти штуки на собеседовании у них не просто так, а вот из такого опыта с джунами, и вам нужно просто ликвидировать этот пробел на будущее.
ВК уже не тот, что при Дурове, сейчас там подвезли эффективных менеджеров и таких же умных собеседователей. Бабки казённые, куда и как тратить вообще не важно, главное всем говорить, что к 2030 будет 100% поисковых запросов, 100% аудио и видео связи, мессенджеров, ну и пять Ютубов будет загружено. А проект настолько будет прибыльный, что ещё и за просмотры платить начнут. Вот только пока когда я с поисковика нахожу видео по своему запросу и меня просят авторизоваться тупо чтобы посмотреть, матеря интернет по паспорту закрываю и ищу на нормальных площадках
Вот читаю комментарии и офигеваю. Все вдруг резко накинулись с "грешно не знать про Х".
Я вот как мидл пэхэпэшник с несколькими годами стажа, включая сферу финансов, сферу образования и сферу е-комерса, ответственно заявляю:
Ноль раз в жизни мне потребовалось писать руками алгоритм сортировки (за исключением случаев, когда это делается ночером дома по фану или в образовательных целях). Умные старички со степенью математики уже давно изобрели прекрасные эффективные алгоритмы, а не менее одарённые программисты добавили их в нативную логику самого языка, и поэтому простейшая инструкция
sort()отработает быстрее, чем рукописный алгоритм в 99.99% случаев.Ноль раз в жизни мне потребовались структуры данных сложнее, чем массив или объект. Ясно-понятно, коллекции, композиции, все дела. Но деревья? Я до сих пор не встречался ни с одной задачей и ни с одним набором данных, которые потребовали бы подобную структуру. Возможно, если уходить в какой-то глубокий код, типа если вы пишете свой пхпстан или свой Doctrine\DBAL, но без этого - ни разу. И вообще: не важно, знает ли человек конкретную структуру: если он хороший разрпб, вы просто берёте его, он сталкивается с задачей, где ему надо работать с этой структурой, ...[прошло 30-60 минут] ..., ВУАЛЯ - он знает про такую структуру и умеет с ней работать. До нынешней работы я чот слышал про редис и кликхаус. Но исключительно "что это, и для чего это можно юзать". И меня взяли! А теперь я умею с ними работать.
Big O нотация: хватает одного/двух раз прочитать, чтобы понять что по чем, как делать льзя и нельзя, и это в целом полезно и крайне прельстиво для здоровья вас и вашего продукта. НО. Есть одно маленькое НО. Людей, которые называют это и знают об этом как "Big O Notation" горааааздо меньше, чем людей, которые называют это или знают об этом как "оценка сложности алгоритмов". И тут действительно вопрос больше смахивает на "мы хотим отсеять самоучек, и работать только с теми сливками сообщества, кто учился в MIT-е и шарит за высокое".
Прочие викторины: у меня было много собесов, и на одном из них меня так же задушили терминологией. В половине случаев с этого собеседования это оказывались механизмы языка, которые я знал и умеючи использовал по необходимости, но тупо не знал, как это называется. Потому что о большинстве вещей, открою вам тайну, мы узнаём либо в ответах стаковерфлоу, либо в чужом коде или коде коллег. Ну, сейчас еще всякие чаты гопоты добавились (на основе того же стака и открытых репо гита). Потом просто разбираемся, что это, и почему было сделано именно так. А как оно называется - никого не волнует.
Чем отличается алгоритм А от алгоритма Б: окей, я знаю разницу и принцип работы пузырька, бинарного поиска и может ещё пары. И хоть раньше я стеснялся в силу своей на тот момент джуновости, но в будущем я буду просто спрашивать: "а у вас была необходимость реализовывать руками и применять в проекте хоть один из них?". Более чем уверен, что ответ будет "Нет".
Вообще, как показала лично моя практика - чем больше на собесе вопросов аля "а знаешь ли ты Х" - тем херовее кодовая база у них на проекте.
В одной из компаний, где я работал, у меня на собесе спрашивали, что такое днс (при том, что я как джун-мидл не имел доступа к инфраструктуре и тем более её настройке или разворачиванию, да и днс они не юзали. На нынешней работе хотя бы ингрес-записи в кубике создаются...), а так же, вы будете смеяться, дефолтные порты mysql, ftp, ssh, http и https. Господи, меня даже попросили перечислить ВСЕ МАГИЧЕСКИЕ КОНСТАНТЫ ПЫХИ... (Моя личная позиция: если вам хоть одна из них понадобилась хоть где-то, кроме кастомных эксепшенов или Kernel-класса в методах `get(Root|Var|Whatever)Path()` для получения абсолютного пути - у меня вопросы к вашему коду). В результате - у них в коде методы по 300 строк, строки кода по 300+ символов без переноса, классы по 11к строк, год-обжекты, нарушение вообще всех принципов и паттернов, ноль тестов, а 60% команды даже не знали и/или не юзали xdebug, а дебажили dump-and-die... Самый мрак, который я там видел - `shell_exec('java -jar {300 символов аргументов}');`
Лично я на собесе может уделил бы какое-то время прощупыванию широты познаний собеседуемого, но в основном собес бы строился по сценарию:
Расскажи о самых, как ты считаешь, эксклюзивных своих познаниях в языке/фреймворке (так я бы узнал, до чего он дочитал/додебажился), и где и почему тебе это понадобилось.
У нас такая-то инфраструктура. Есть задача сделать вот это. Сейчас оно работает так и так. Как бы ты решал такую задачу
Интервьюируемый предлагает решение
Мы спрашиваем ещё одно, возможно усложняем задачу (правки, хых)
Он предлагает снова
В какой-то момент мы пользуемся ролью старшего и говорим, что нет, так мы делать не будем, а будем делать иначе (заведомо предлагая плохое решение). И здесь доп. баллы получит тот, кто возразит и аргументированно отстоит своё решение.
Ну а дальше смотрим, какое решение предложит чел, предусмотрел ли он возможные ошибки или эдж-кейсы и т.д. если это тестовое задание - написал ли он тесты на своё поделие, качество кода и т.д.
В какой-то момент мы пользуемся ролью старшего и говорим, что нет, так мы делать не будем, а будем делать иначе (заведомо предлагая плохое решение). И здесь доп. баллы получит тот, кто возразит и аргументированно отстоит своё решение.
Тут главное претенденту угадать знает ли интервьюер, что это решение заведомо плохое.
С другой стороны, если не знает и не готов узнать, то может и ну его нафиг такую вакансию.
Чертовски хочу согласиться с автором по ключевым пунктам статьи (и дело не в ВК)
Биг. тех, очевидно что большие компании ищут разработчика middle уровня который будет писать код (отсюда и дроч по алгосам) и перетаскивать карточки в таск-менеджере (которые ему туда поставят любимые лиды или архитекторы).
АБСОЛЮТНО НАСРАТЬ, как ты проектируешь (тот же DDD) или как выстраиваешь архитектуру БД, не тебе об этом заботиться и очевидно не тебе этим заниматься.
Такое ощущение что происходит "подмена" понятий ценности для работодателя и для кандидата.
Как будто middle разраб хочет сказать, вот смотрите, я научился и умею + практикую, у меня есть ценность за то что я знаю достаточно сложные вещи (от этого и идёт как будто рост зп).
Но по сути биг. теху это и не нужно (складывается такое ощущение)
Они формируют "шаблон" на должность и ты под неё должен подходить (ты должен закрывать потребности бизнеса), а всё остальное, ну молодец, ты знаешь, красавчик, вот тебе 150к в чуть меньше рынка, тяни толкай)))))) Возможно потом (через 0.5 - 1 год) у тебя будет performance review, и тебе дадут конфетку на 20-40к, но ты по прежнему будешь перетаскивать карточки которые тебе ставят (архитекторы или лиды)
Если рассматривать компании среднего уровня, то автор 100% прав. Тот мидл разраб нужен с умением проектировать, чтобы дать задачу, а он её СПРОЕКТИРОВАЛ и потом СДЕЛАЛ, и тут когда тебе реально пришлось столкнуться со многим, твоё businessValue повышается.
Почитал статью, посмеялся, конечно. Есть подозрение, что это всё толстота для сбора каментов. Ну невозможно всерьёз воспринимать опусы про настройку ssl через certbot или размеры в байтах в контексте О-нотаций, да ещё помноженные на гротескный пафос местами)
Но отвечу как будто всерьёз. Опыт проведения тех.интервью почти достоверно мне рисует автора: до 22-25yo, 1-1.5 места работы, где он варился в чём-то самом себе. При этом есть люди, которые нормально воспринимают всё и понимают что им ещё развиваться надо, активно учатся, внимают, читают. А есть которые фыркают и делают вид что не понимают зачем это всё вообще. Однажды чел не смог пояснить что такое проценты даже (доходит до таких вопросов при прощупывании дна базы). А потом один чел на это спросил "ну а что у вас там всё время проценты на работе чтоль считать надо".
Ни автор ни многие комментаторы как будто не вполне понимают в чём (по крайней мере "в том числе") суть и собеседований и "тупых вопросов". Это просто прощупывание что вообще есть в голове у человека. Знание стека это не такое прям важное. Это задача довольно прикладная, главное, чтобы было на что ложиться этому. Просто никто не хочет в здравом уме нанимать себе мидлов которые не знают что такое проценты. Это, конечно, утрируя (хоть и из личной практики). Подставьте вместо процентов сюда "общие принципы работы хеш таблиц" или ещё какие-то совершенно базовые знания даже для джуниора.
Как говорится, дурак это не тот, кто чего-то не знает, а тот кто упорствует в своём невежестве. 10 лет назад в моде были срачи нужно ли ВО в профессии, теперь дошло нужно ли мидлу знать что такое хеши и днс. Вот тебе и очередь за забором.
Может быть, а может быть и нет. Я бы мог согласиться, если бы своими глазами не видел как на работу брали абсолютно профнепригодных, которые даже как аникейщики слабые, не то что сисадмины. На прежнем месте работы они валяли дурака, а пользователи страдали, был полный бардак и неработающая техника, сеть, программы. А вот люди более умные, добросовестные, которые наводили порядок не могли получить офферы.
Реальная жизнь весьма непредсказуема.
Согласен. На собесах сами не понимают что спрашивают. Не понятно что им нужно академические знания, зазубренные определения или реальные навыки, способность развиваться и добросовестность. Ну а комментарии превратились в хвастовство и выпячивание эго друг друга.
А вы точно хотите лечиться у врача, который на вопросы "чем лекарство отличается от БАДа" и "Что такое анамнез?" психует, не отвечает, говорит что это вопросы для студента и бежит плакать на med habr, если таковой имеется у медиков, как его завалил страшный предвзятый медцентр?
Бывает конечно что интервьюеры перегибают палочку и начинают спрашивать то, что вчера прочитали в узкопрофильном блоге, но у вас спросили основу основ, handshake, вопросы просто удостовериться, что вы программист а не курьер Яндекс-доставки, и вы завалили каждый - так еще и позориться на весь хабр прибежали.
Хотя судя по количеству плюсов, за последние годы уровень хабра опустился столь низко, а в голосовании разрешили участвовать столь многим школьникам, что любая такая статья обречена на успех
VK, как НЕ НАДО собеседовать middle разработчиков