кусок задачки

[juan_gandhi]

Вот вы, скажем, имплементируете фесбук месенджер. Как вы ключ зададите для чатов? Я предложил (на интервью было) просто пару ключей юзеров. Ну там штука, что симметрично ж должно быть. Интервьюер сказал, что правильно будет брать hash(Set(userid1, userid2)). Меня это как-то удивило; смысл-то понятен, но глупость же.

На самом деле, для симметрии надо просто брать пару ключей да сортировать, например. List(userid1,useri2).sort. И вообще этого мало, нужно еще хранить priority queue из собеседников.

Впрочем, фигня. Обидно другое - это за неделю уже второй облом в смысле контактов. Я, как иной mentally challenged, чуть не каждого первого попавшегося считаю за доброжелательного приятеля - а блин, присмотришься - он тебя ненавидит за каким-то хреном. Как они между собой-то вообще? Не понимаю.

Comments

[snowps.livejournal.com]

Раньше термин не попадался, посмотрел - выглядит местами похоже по концепции на алгоритм поиска подстроки, с которым я экспериментировал 15 лет назад. :) Там нужно было быстро определять вхождение повреждённого серийного номера (оторвано начало, конец или доступна толька часть из середины) в гарантийную базу. Поиск в Оракле по %...% был очень долгим, я предложил экспортировать все имеющиеся серийники в несколько файлов, потом грузить их в комп с большим количеством памяти в сплошной массив, состоящий из суммы строк с терминальными символами и делать в нём поиск по четырём байтам ASCII с инкрементом в один байт ассемблерной подпрограммой, в результате чего на выходе в первый заход ставился флаг хотя бы одного вхождения подстроки в отдельных блок данных и далее делалось вычисление индекса искомой записи в файле и только тогда дёргалась БД на предмет подробной информации. Сто тысяч серийников на PIII просматривались за десятки миллисекунд, это было на несколько порядков бысрее работы БД, но так же, как и во многих других случаях, нестандартное решение испугало и народ продолжил мучиться с фуллсканом. :)

[juan-gandhi.livejournal.com]

Да, вот хороший пример.