Последние лет 5 думал что послеобеденная сонливость связана, собственно, с обедом и инсулиновыми качелями - уровень инсулина медленно падает к обеду, затем резко возрастает после приема пищи, и затем также резко падает обратно И как-раз на этом резком падении у человека и наблюдается вялость и сонливость
По собственным ощущениям - похоже на правду, если я методично что-то жую перед обедом, и не наедаюсь на самом обеде, то спать не хочется
Это очень хороший индикатор того, что человек может и хочет делать. Трансляторы из английского в джаву ведь тоже востребованы, просто нужно иметь ввиду что человек планирует тупокодить
Для начала я обычно даю шаблон интерфейса, с оговоркой что его можно менять
class CurDownloadSpeed {
void addData();
void getCurrentSpeed();
}
Первым делом нужно определиться что такое вообще "текущая скорость скачивания". В целом скорость в данном случае - это объем деленный на время, так что кандидат может предложить более подходящий интерфейс
class CurDownloadSpeed {
public:
void addData(size_t bytes);
size_t getCurrentSpeed();
}
Далее мы обсуждаем контекст - сколько потоков скачивают данные, сколько отвечают за отображение, что для нас более критично - отображать правильные данные или скачивать быстрее В ходе этого я объясняю что у нас несколько воркеров, которые скачивают файл в несколько потоков (ну, нравится нам так) и один поток который дергается из условного UI для отображения
На этом этапе кандидаты могут накидать реализацию для отображения средней скорости, что-то вроде
Не судите строго, этот код написан "как я бы написал если бы меня спросили на собесе". В коде выше целый ряд спорных моментов, которые можно обсуждать:
реализация getCurTimeMs() - написана она ручками или мы решили "замокать" эту функцию?
branch prediction - насколько хорошо ставить в if условие, которое выполнится единожды?
переполнение size_t
деление на 0
неинициализированные переменные
приведение типов
размерность startTimeMs
После того как обо всем поговорили, можно переходить от "средней скорости" к "текущей". Худо-бедно соглашаемся о том, что "текущая скорость" - это скорость за последние, скажем, 10 секунд Как это сделать? Самый простой способ - при добавлении данных хранить их в паре (ts, value) Если данные добавляются часто (с частотой в микросекунду) мы получим огромный массив, который можно будет очищать при вызове getCurrentSpeed
Линейная сложность на вставку, линейная на чтение - еще и с блокированием вставки. Не очень приятненько.
Обновляем код, делая линию на вставке и константу на чтение - при каждом добавлении обновляем curSpeed (вычитаем старые из результата, добавляем новые. Сами данные храним в векторе). Тут уже пора вспоминать о потокобезопасности (на самом деле и раньше было "пора", но не так интересно)
Теперь у нас все хорошо со временем работы, но линейная память в зависимости от количества вставок (чтобы правильно очищать старое при добавлении нового). А нужно ли нам хранить все данные? С точки зрения UI пользователю побоку в какую микросекунду произошло обновление, так что в качестве единицы измерения времени можно взять секунду, и все байты в рамках одной секунды класть в 1 корзинку. Получается константа по памяти (60 корзинок по 1 секунде)
Ну и в конце просим перестать бесконечно аллоцировать память в векторе, реализовав циклический буффер, а заодно поговорив про модель памяти (почему постоянные аллокации - это плохо)
Как-то кандидат предложил хорошее решение и без циклического буфера (там не было лишних аллокаций, константа на вставку и чтение, константа по памяти). Не помню само решение, но мой вариант решения точно не единственно верный)
Мне вот нравится просить спроектировать виджет скорости скачивания файла. Как-то задали такую задачку в варгейминге лет 5 назад
Тут тебе и алгоритмы (временная сложность на вставку, временная сложность на чтение, сколько памяти будет кушать) и оптимизации (можно сделать агрегацию) и вопросы для обсуждения (что мы хотим показывать пользователю в самом начале? Как часто нужно отображать изменения? и вообще что такое скорость скачивания?) и многопоточка, если время останется (данные пушатся из разных потоков)
В мл все не очень с черно-белым восприятием, у факторов вообще нет "хорошо" и "плохо". Есть только корреляция из комбинации факторов в вероятность события
Т.е. при наличии фактора "тип данных" со значением "историческая энциклопедия" фактор "есть цифры в урле" - повышает ранг страницы А для фактора "тип данных": "поэзия" - понижает
И только на данной конкретной модели, обученный на данном конкретном наборе данных)
Чтобы этого избежать, можно в вызов подставлять название переменной: Sum(1,2,3,/*throwOnOverflow=*/ true) Плодить по сущности на каждый чих - и правда очень по-джавистски =)
в двух словах суммы по нидерландам: 1) аренда - от 1800 до 2400 евро (у нас 2000) 2) комунальные услуги - около 500 евро зимой (газ, электричество, вода), пока 200 из них возвращаются каждый месяц (но кажется эта лавочка работает только до конца 2022) 3) еда на двоих человек из местного ашана (лидл) - 25 евро в день, ~800 в месяц 4) страховка минимальная (обязательная) - 240 в месяц на двоих 5) интернет 50 евро, телефон около 20 евро (15гб, минуты даже не знаю какие там) 6) веб-сервисы (спотифай, нетфликс) - 20 евро 6) спорт зал 30 (а-ля кроссфит в минигруппах 60) - мы и там и тут, так что 90 евро в месяц 7) музеи 20-30 евро или музейная карта (вроде 60 евро, и ходи куда хочешь год по ней)
Итого, минимум 2000+500+800+240+70+20+90+60=3780 евро в месяц, что соответствует 70к\год без рулинга (скидка на налоги первые 5 лет), или 55к\год с рулингом.
8) поездка на автобусе по городу 2-3 евро, поездка на поезде в соседний город 6-15 евро) 9) поездка во францию на 10 дней вышла 1880, из них 450 чисто на поезда (амстер-париж-марсель-париж-амстер) и 550 за жилье. Остальное - еда и транспорт внутри городов) 10) поездка в бельгию на 3 дня - около 600 евро (200 на транспорт, 200 на отель) 11) страховка собаки ~250 евро в год, еда для собаки ~30 евро в месяц 12) поход в ресторан на двоих 40-60 евро (но рестораны тут в основном так себе, фастфуд вкуснее и дешевле)
В общем можно заложить еще 600 евро на "непредвиденные расходы" в течении месяца, и 1000 на "откладывать": получится 3780+1000+600 ~= 5380 Это 110к\год "без рулинга" или 82к\год "с рулингом"
Старые модели все еще остались, и часто пользуются популярностью - так называемая медийка (брендинг), которые работают на узнаваемость - им не нужно события, их нужно чтобы их узнавали на полках магазина (нестле, кола, все вот это вот что вы в том числе видите по телевизору)
И таких ребят еще довольно много на рынке интернет-рекламы
Оплата за конверсии - это конечно шаг вперед, но он не всем подходит - и не всегда выгоден. В конечном счете режим работы рекламного аукциона зависит от выгоды для рекламодателя. Может так, внезапно, оказаться, что заливать пользователей CPM-трафиком (показами) выйдет дешевле (меньше CPA), чем честная "цена за конверсию".
Но таки реклама искренне движется в сторону улучшения конверсионности, потому что это выгодно для рекламодателей - а значит и для рекламных площадок (позволяет привлечь больше клиентов). Движется как может =)
История по секретные вопросы не раскрыта. Это же еще один способ аутентификации, не более того. Спрашиваете столицу Калифорнии, отвечаете "творожок", в чем проблема...
Видимо, к счастью, нет. Я всего лишь пропустил трансляцию и надеялся на небольшое саммари, если повезет - с фокусом на технические аспекты.. А тут мешочек постов, в каждом из которых абсолютно нихрена =(
Последние лет 5 думал что послеобеденная сонливость связана, собственно, с обедом и инсулиновыми качелями - уровень инсулина медленно падает к обеду, затем резко возрастает после приема пищи, и затем также резко падает обратно
И как-раз на этом резком падении у человека и наблюдается вялость и сонливость
По собственным ощущениям - похоже на правду, если я методично что-то жую перед обедом, и не наедаюсь на самом обеде, то спать не хочется
Это очень хороший индикатор того, что человек может и хочет делать. Трансляторы из английского в джаву ведь тоже востребованы, просто нужно иметь ввиду что человек планирует тупокодить
Вполне возможно, по сложностям с ним получается то же самое - а реализовать куда проще
Но тогда нужно обсуждать + и - связанного списка относительно вектора
Для начала я обычно даю шаблон интерфейса, с оговоркой что его можно менять
Первым делом нужно определиться что такое вообще "текущая скорость скачивания". В целом скорость в данном случае - это объем деленный на время, так что кандидат может предложить более подходящий интерфейс
Далее мы обсуждаем контекст - сколько потоков скачивают данные, сколько отвечают за отображение, что для нас более критично - отображать правильные данные или скачивать быстрее
В ходе этого я объясняю что у нас несколько воркеров, которые скачивают файл в несколько потоков (ну, нравится нам так) и один поток который дергается из условного UI для отображения
На этом этапе кандидаты могут накидать реализацию для отображения средней скорости, что-то вроде
Не судите строго, этот код написан "как я бы написал если бы меня спросили на собесе". В коде выше целый ряд спорных моментов, которые можно обсуждать:
реализация getCurTimeMs() - написана она ручками или мы решили "замокать" эту функцию?
branch prediction - насколько хорошо ставить в if условие, которое выполнится единожды?
переполнение size_t
деление на 0
неинициализированные переменные
приведение типов
размерность startTimeMs
После того как обо всем поговорили, можно переходить от "средней скорости" к "текущей".
Худо-бедно соглашаемся о том, что "текущая скорость" - это скорость за последние, скажем, 10 секунд
Как это сделать?
Самый простой способ - при добавлении данных хранить их в паре (ts, value)
Если данные добавляются часто (с частотой в микросекунду) мы получим огромный массив, который можно будет очищать при вызове getCurrentSpeed
Линейная сложность на вставку, линейная на чтение - еще и с блокированием вставки. Не очень приятненько.
Обновляем код, делая линию на вставке и константу на чтение - при каждом добавлении обновляем curSpeed (вычитаем старые из результата, добавляем новые. Сами данные храним в векторе). Тут уже пора вспоминать о потокобезопасности (на самом деле и раньше было "пора", но не так интересно)
Теперь у нас все хорошо со временем работы, но линейная память в зависимости от количества вставок (чтобы правильно очищать старое при добавлении нового). А нужно ли нам хранить все данные? С точки зрения UI пользователю побоку в какую микросекунду произошло обновление, так что в качестве единицы измерения времени можно взять секунду, и все байты в рамках одной секунды класть в 1 корзинку. Получается константа по памяти (60 корзинок по 1 секунде)
Ну и в конце просим перестать бесконечно аллоцировать память в векторе, реализовав циклический буффер, а заодно поговорив про модель памяти (почему постоянные аллокации - это плохо)
Как-то кандидат предложил хорошее решение и без циклического буфера (там не было лишних аллокаций, константа на вставку и чтение, константа по памяти). Не помню само решение, но мой вариант решения точно не единственно верный)
Мне вот нравится просить спроектировать виджет скорости скачивания файла. Как-то задали такую задачку в варгейминге лет 5 назад
Тут тебе
и алгоритмы (временная сложность на вставку, временная сложность на чтение, сколько памяти будет кушать)
и оптимизации (можно сделать агрегацию)
и вопросы для обсуждения (что мы хотим показывать пользователю в самом начале? Как часто нужно отображать изменения? и вообще что такое скорость скачивания?)
и многопоточка, если время останется (данные пушатся из разных потоков)
еще и по сетям слегка пройтись можно
Эх, хорошо тогда пообщались
Почему работает 3ий вариант, если область видимости j должна бы быть ограничена вложенным циклом?
Обычная фраза, слышал сотни раз, равносильно "не так впечатляюще". Драма тут при том, в драматических жанрах принято взывать к эмоциям людей.
Нашли до чего докопаться
В мл все не очень с черно-белым восприятием, у факторов вообще нет "хорошо" и "плохо". Есть только корреляция из комбинации факторов в вероятность события
Т.е. при наличии фактора "тип данных" со значением "историческая энциклопедия" фактор "есть цифры в урле" - повышает ранг страницы
А для фактора "тип данных": "поэзия" - понижает
И только на данной конкретной модели, обученный на данном конкретном наборе данных)
Как и любой другой крупный сервис, Алиса наверняка обвешана трассировками и логами по самые помидорки. Специальной функции reportVovke там не будет
А как используются эти логи и трассировки - вообще не технический вопрос
Чтобы этого избежать, можно в вызов подставлять название переменной:
Sum(1,2,3,/*throwOnOverflow=*/ true)
Плодить по сущности на каждый чих - и правда очень по-джавистски =)Вы в МойОфис собеседоваться идете?
на целый 1% прорядили...
дорого?
в двух словах суммы по нидерландам:
1) аренда - от 1800 до 2400 евро (у нас 2000)
2) комунальные услуги - около 500 евро зимой (газ, электричество, вода), пока 200 из них возвращаются каждый месяц (но кажется эта лавочка работает только до конца 2022)
3) еда на двоих человек из местного ашана (лидл) - 25 евро в день, ~800 в месяц
4) страховка минимальная (обязательная) - 240 в месяц на двоих
5) интернет 50 евро, телефон около 20 евро (15гб, минуты даже не знаю какие там)
6) веб-сервисы (спотифай, нетфликс) - 20 евро
6) спорт зал 30 (а-ля кроссфит в минигруппах 60) - мы и там и тут, так что 90 евро в месяц
7) музеи 20-30 евро или музейная карта (вроде 60 евро, и ходи куда хочешь год по ней)
Итого, минимум 2000+500+800+240+70+20+90+60=3780 евро в месяц, что соответствует 70к\год без рулинга (скидка на налоги первые 5 лет), или 55к\год с рулингом.
8) поездка на автобусе по городу 2-3 евро, поездка на поезде в соседний город 6-15 евро)
9) поездка во францию на 10 дней вышла 1880, из них 450 чисто на поезда (амстер-париж-марсель-париж-амстер) и 550 за жилье. Остальное - еда и транспорт внутри городов)
10) поездка в бельгию на 3 дня - около 600 евро (200 на транспорт, 200 на отель)
11) страховка собаки ~250 евро в год, еда для собаки ~30 евро в месяц
12) поход в ресторан на двоих 40-60 евро (но рестораны тут в основном так себе, фастфуд вкуснее и дешевле)
В общем можно заложить еще 600 евро на "непредвиденные расходы" в течении месяца, и 1000 на "откладывать": получится 3780+1000+600 ~= 5380
Это 110к\год "без рулинга" или 82к\год "с рулингом"
Все расчеты округлялись вверх с небольшим запасом
И да, и нет, и по чуть-чуть...
Старые модели все еще остались, и часто пользуются популярностью - так называемая медийка (брендинг), которые работают на узнаваемость - им не нужно события, их нужно чтобы их узнавали на полках магазина (нестле, кола, все вот это вот что вы в том числе видите по телевизору)
И таких ребят еще довольно много на рынке интернет-рекламы
Оплата за конверсии - это конечно шаг вперед, но он не всем подходит - и не всегда выгоден. В конечном счете режим работы рекламного аукциона зависит от выгоды для рекламодателя. Может так, внезапно, оказаться, что заливать пользователей CPM-трафиком (показами) выйдет дешевле (меньше CPA), чем честная "цена за конверсию".
Но таки реклама искренне движется в сторону улучшения конверсионности, потому что это выгодно для рекламодателей - а значит и для рекламных площадок (позволяет привлечь больше клиентов). Движется как может =)
в фейсбуке в 2 раза больше, судя по новостям о сокращениях (10к ~ 10%)
История по секретные вопросы не раскрыта. Это же еще один способ аутентификации, не более того. Спрашиваете столицу Калифорнии, отвечаете "творожок", в чем проблема...
Видимо, к счастью, нет. Я всего лишь пропустил трансляцию и надеялся на небольшое саммари, если повезет - с фокусом на технические аспекты.. А тут мешочек постов, в каждом из которых абсолютно нихрена =(
делать по посту на каждый выпущенный продукт это какое-то очень редкостное мудачество и набивание kpi
делать по посту на каждый выпущенный продукт это какое-то редкостное мудачество и набивание kpi