Нет, не хорошо. Очень плохо. Да, меня покусал с++ и я хочу this, который некоторыми санитайзерами запрещен. Ну да ладно. Но почему односимвольные переменные не запрещены?
Хорошие советы, вспомнил свои первые пол года - столкнулся ровно с тем же
Я бы поспорил с названиями. Что значит не занимайтесь планированием? Планированием то заниматься как-раз теперь надо. Но планированием, а не разбором поддержки и техдолга. И желательно даже не приоритезацией.
А четвертый пункт лучше было бы обозначить "научитесь делегировать". "Не быть узким горлышком" можно и работая по 20 часов в сутки, но через пол года бизнесу придется искать нового тимлида - это не очень выгодный обмен
Последние лет 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) Плодить по сущности на каждый чих - и правда очень по-джавистски =)
Скорее чтобы в налоговой декларации указать что было пожертвовано 100500 фунтов на африканских детей, поэтому верните мне х% уплаченных налогов
О как. Ну я уточка, мне сложно в двойные отрицания =)
В таком случае четвертый пункт надо назвать "не учись делегировать"
Почему в го так модно использовать односимвольные имена переменных?
Нет, не хорошо. Очень плохо.
Да, меня покусал с++ и я хочу this, который некоторыми санитайзерами запрещен. Ну да ладно. Но почему односимвольные переменные не запрещены?
Хорошие советы, вспомнил свои первые пол года - столкнулся ровно с тем же
Я бы поспорил с названиями. Что значит не занимайтесь планированием? Планированием то заниматься как-раз теперь надо. Но планированием, а не разбором поддержки и техдолга. И желательно даже не приоритезацией.
А четвертый пункт лучше было бы обозначить "научитесь делегировать".
"Не быть узким горлышком" можно и работая по 20 часов в сутки, но через пол года бизнесу придется искать нового тимлида - это не очень выгодный обмен
Не состоят они только если успели сняться. В последний год уехавшим, возможно, было не до таких формальностей
Странные какие-то квантили. При выборке 200 200 300 300 1000 p99==p95==1000 же?
хорошая попытка, но нет
Работать 10 лет беря таски из джиры и все - в джуны. Если инструментарий совпадает, то можно попробовать в мидлы, но есть риски.
Последние лет 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% прорядили...