Хэш функция деленное на количество бакетов

Нормальный ответ: — не углублялся, знаю что гц пробегается несколько раз по памяти и отмечает данные на удаление и на дополнительную проверку — не знаю термина write barrier, разверните немного — stw? не помню, кажется больше одного раза После таких ответов никто вам не скажет что вы профнепригодны, это нормально на таком уровне знать тему

А как именно механизм равного распределения работает ?

Так в случае коллизии идет связный список

Так вроде связный список идет уже после увеличения мапы, а чтоб мапа увеличилась нам нужно 6,5 коллизий в каждом бакете в среднем

Теор вер советую глянуть

Интервьюер ваш прав на все 146%. А вам стоит подучить чем отличается передача параметров по указателю и по значению и где применять то и другое. А уж заявление в стиле «потом отпрофайлим» это уж совсем красная лампочка, я б лично на этом месте с вами сразу попрощался. Так что это действительно кринж.

Чтобы перестроилась нужно 6.5 в среднем коллизий

Пример высосан из пальца, но мы будем собирать 6.5 коллизий в среднем)

Если у нас 2 бакета, 1 забит полностью, а другой пуст, то у нас в среднем 4. Хеш функция опять определила что кладем в 1, че делаем ?

Чейним первый дальше, внутри забитого бакета будет ссылка на новый бакет

Чейним первый дальше, внутри забитого бакета будет ссылка на новый бакет

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

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

Ладно, если там используется чейнинг, что будет если один из бакетов переполнен, а хеш функция сгенерирует хеш для этого переполненого бакета, опять будет генерироваться новый хеш? А если он опять будет попадать в тот же бакет

Вот еще кстати вопрос, как в случае коллизии мы определяем потом нужный элемент? Есть же что-то типа условной таблички, которая за линейное время помогает нам найти нужный элемент

тем, что у тебя мапа в слайс превратится со скоростью поиска O(n)

Так он и так и так "превращается", чейнинг бакетов тоже дает O(n) в худшем случае

ключи хранятся в бакетах

А в каком виде и где именно? В условной ноде списка, где лежит элемент?

Рост числа оверфлоу бакетов ограничен. Когда лоад фактор станет 6.5 выделится память под большее число бакетов

Нет, не ограничен) Ну и кто мешает ограничить лоад фактор без бакетов, просто ограничив длинну связанного списка элементов

что значит не ограничен? Он не будет бесконечным, а прекратится, когда лоад фактор станет 6.5. Что значит, что он ограничен

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

Ого, вот это заносчивость. Так по делу есть что сказать? Чего конкретно я не знаю? Или может быть у вас есть чудные примеры когда вы начали передавать все по значению и снизили нагрузку на CPU? У меня вот есть, потому что я писал ещё на go1.5 но это очень узкий кейс, который вслыл лишь однажды и там простой заменой все не решилось.

Какая ещё заносчивость, б-же упаси. О вас забочусь же, а то вам интервьюеры всё время не те попадаются. :)

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

Но вопрос про способ передачи параметров неплох. Начиная с него можно обсудить весь memory management в го и узнать глубину глубин кандидата. А можно пойти в сторону код дизайна, поболтать за семантику такой передачи, value object'ы, ddd и так далее. Или можно увидеть, что кандидат не знает базовых вещей. Или вообще не заинтересован в собесе.

Вопрос имхо плох) Вообще не понимаю зачем обсуждать работу с памятью (не припомню ни одной таски прямо об этом😁), тем более что большинство интервьюеров сами её не понимают (они как правило понимают модель Си и говорят: лучше по указателю, память и аллокации сэкономим, быстрее будет (ну кто код профилировал и видел как GC ставит CPU на колени в такие моменты тут гомерически хохочет))😁 Лучше спросить "как сделать чтобы БЛ и HTTP не были прибиты гвозядми друг к другу без лишнего кода и всякой ерунды в духе пустых интерфейсов"?

Вы профилируете только если есть такая таска? Не интересно на что под копотом время уходит?) А мне интересно. Я даже по выходным профилировал, и всегда без таски. Так что противоречие надуманное.

Вы профилируете только если есть такая таска? Не интересно на что под копотом время уходит?) А мне интересно. Я даже по выходным профилировал, и всегда без таски. Так что противоречие надуманное.

В мире вообще интересного очень много, но почему-то на собесах забывают о факте ограниченности времени, может себя Маклаудами считают? :) А раз время ограничено, то может соискатель лучше знает то что встретит непосредственно в задачах от бизнеса?

Время действительно очень ограничено, не стоит его тратить на споры в интернете

:) В дискуссии формируется точка зрения, происходит развитие логики и т.п. И да, последнее для многих вредно, это видно на собесах. :) Не в коем случае ни секунды в развитие, лучше выучить наизусть имена файлов Go. :)

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

Все сложнее, на собесе и потом в работе нужно применять прокачанную логику, если на ее прокачку хватило время в паузах, между зубрением имен файлов Go. Но тут есть опасность, вдруг некоторые интервьюеры поймут что соискатель умнее, будет взрыв жопы, а потом куча ереси в попытке доказать соискателю, что он говно. Иногда подобное заметно прям здесь. :))

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

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

Скажу что для такого можно делать, подойдет учить имена файлов Go.

Да нет, это вашей логике так выходит

Это какой то мем, который я пропустил, видимо

Это откуда имеенно? :)

Или такие вопросы))

Ладно, шучу, вопрос и правда мега идиотский

Вот если бы он был один такой, не было бы этих всех диалогов. :)

Или такие вопросы))

Почему они не спросили строчку в файле? Видно поверхностные вопросы🤡

По сути вопрос не плох, по подробностям из примера, где попросили каких то абстрактных но при этом конкретных цифр, вопрос плох максимально возможно. Опять же все хотят максимальной глубины знания кандидата, но готовы ли они платить за такую глубину? Нужна ли такая глубина на рабочем месте, где неспешно кидаются jsonами? Опять же про архитектуру было правильно отвечено, что внешние операции по сети (а при микросервисной архитектуре так всегда), занимают намного больше времени. И как известно на фоне 1 секунды искать миллисекунды, типичная преждевременная оптимизация.

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

Скажу что для такого можно делать, подойдет учить имена файлов Go.

По поводу цифр хотели услышать какой размер структуры можно скопировать через стек и при этом счастливо жить и не заметить этого. Ответ был в духе: килобайт спокойно можно копировать. И да, там ещё был вопрос почему стек работает быстрее потому что он в кэше процессора а куча нет. Такой же абстрактный вопрос, на который я сходу придумал контр аргумент который не понравился интервьюеру) Лучше бы про ast оптимизации спросили бы, чесслово

По поводу цифр хотели услышать какой размер структуры можно скопировать через стек и при этом счастливо жить и не заметить этого. Ответ был в духе: килобайт спокойно можно копировать. И да, там ещё был вопрос почему стек работает быстрее потому что он в кэше процессора а куча нет. Такой же абстрактный вопрос, на который я сходу придумал контр аргумент который не понравился интервьюеру) Лучше бы про ast оптимизации спросили бы, чесслово

Стэк тоже в оперативке лежит, не в кэше процессора.

Вроде куча в оперативке, а стэк в кэше

оба в оперативке

Стек попроще устроен, чем хип. А в кэше он может быть, а может и не быть. Если горутина миллионная, её стек будет в кеше или нет?)

Не спорьте. ;) И то, и то располагается в оперативной памяти. Область стека может быть подтянута в кеш при определённых условиях. Да и от платформы тоже зависит.

Не спорьте. ;) И то, и то располагается в оперативной памяти. Область стека может быть подтянута в кеш при определённых условиях. Да и от платформы тоже зависит.

Вот опять же. Вам задают вопрос - а вы вместо ответа контраргумент. Зачем? В первую очередь должен быть ответ, а уже потом всякие контраргументы и собственное мнение.

Стэк тоже в оперативке лежит, не в кэше процессора.

Требовать знаний имён файлов в го это действительно дно. Однако знать как работает рантайм вполне правильно. Да и неужели вам не интересно? На Хабре как-то пробегала статья про устройство горутин - с удовольствием прочитал. С именований структур поржал, не запомнил, правда.