Pull to refresh
23
0
Александр Пак @alekspak

User

Send message
Задачи на собеседованиях на самом деле достаточно простые. И на собеседованиях не требуют идеального кода. Задача, которую я спрашиваю, требует пару циклов и хэш таблицу. Её даже можно решить в одну строчку на некоторых языках. И примерно так большинство задач, которые я знаю что люди спрашивают. Я даже иногда могу очень сильно подсказывать алгоритм, чтобы мне просто написали корректный код, потому что может быть человек волнуется и у него ступор случился. Мне даже норм почти псевдокод и я игнорирую, когда вызывают неправильные методы, которых нет в классе. Но не справляются.

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

Я бы хоть FizzBuzz спрашивал, если бы его не все знали. Проблема в том, что вопросы часто утекают и их запрещают спрашивать. Поэтому интервьюерам приходится придумывать новые задачи, которые не популярны и не такие сложные. Несложные задачи, которые не сводятся тривиально к известным всем, не так просто придумать, поэтому некоторым попадаются замудренные.
Это новая штука. Там есть подсветка синтаксиса. Правда большинство готовится писать на доске и выбирают доску. Также с языками. Готовят джаву, говоришь, у вас тут питон как главный язык в резюме, может питон, а они всё равно на джаве.
Когда приходишь в Гугл учишь много нового, потому что все системы и «библиотеки» свои. То есть общие знания о том, как что устроено помогает, но в целом никто не ждет, что ты с первого дня начнешь писать кучу кода. Поэтому интервью так устроены, потому что в основном фундаментальные знания снаружи полезны внутри. И в целом ожидается, что ты сможешь взять любую технологию/язык и сделать что-то с этим. Я уже успел написать код на 6 языках и даже сделать кое-какие изменения в приложении для Андроида, хотя никогда в жизни не прикасался к Андроиду.

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

Я бы попробовал опять, но просто на SWE, а потом, уже поняв что и как устроено внутри, решить куда хочется дальше идти.
1) Тут как раз и работает lifetime. Он у них одинаковый и поэтому данные внутри не могут жить дольше чем MutexGuard
2) Send это немного другое. Потокобезопасный это trait Sync, а Send просто позволяет отправлять объект в другой поток
Пожалуйста, не рассказывайте ему, какое напряжение на кинескопах!
Какая может быть совместимость для абсолютного нового класса? До сих пор во всех коллекциях enumerator делается структурой и сам Липперт пишет:
Yes, mutable structs are a bad programming practice, but in this case it’s not so bad because the foreach loop is never going to expose the raw enumerator to possible misuse by user code. Sometimes you really do want to avoid collection pressure, so making the enumerator a struct can be a small but measurable win.
А свежее обсуждение немного притянуто за уши, как мне кажется. Я придерживаюсь мнения, что если ты решил делать что-то нестандартное, то будь добр — изучи матчасть. Так что я не вижу проблем в том, чтобы делать mutable structure.

Насчет советов: нужно же немного подключать голову. Например в случае нового кода я всё-таки настаиваю, что нужно делать перечислитель для коллекции значимым типом. А для других советов там в начале есть предостережения:
Если есть возможность без вреда для внешнего кода иметь в качестве параметра конкретную коллекцию, а не интерфейс, то используйте ее, это сможет улучшить производительность foreach
Если возможности иметь в качестве параметра конкретную коллекцию нет, можно, например, использовать IList и for вместо foreach
В библиотечных классах перечислитель сделан в виде типа-значения в давние времена, до появления обобщённых (дженерик) типов, чтобы избегать оборачивания (боксинга) в каждой итерации цикла. В наше время это неактуально.

Что? Я привел вам List<T>, который появился вместе с generic и которой как раз имеет enumerator структуру. Мне кажется вы невнимательно прочитали в чем проблема. А в целом, насчет того, что применять, а что не применять — мне кажется вы не читали кучу моих предостережений насчет того, когда стоит прибегать к этим советам.
Да, туплю с утра. Хотелось надеяться на лучшее.
Почему? Если не LegacyMode, то с ним тоже всё в порядке же:
public int IndexOf(String value) {
        return IndexOf(value, (LegacyMode ? StringComparison.Ordinal : StringComparison.CurrentCulture));
}
Отсюда: referencesource.microsoft.com/#mscorlib/system/string.cs

Contains
public bool Contains( string value ) {
        return ( IndexOf(value, StringComparison.Ordinal) >=0 );
}



StartsWith (EndsWith такой же)
public Boolean StartsWith(String value) {
        if ((Object)value == null) {
                throw new ArgumentNullException("value");
        }
        Contract.EndContractBlock();
        return StartsWith(value, (LegacyMode ? StringComparison.Ordinal : StringComparison.CurrentCulture));
}



IndexOf
public int IndexOf(String value) {
        return IndexOf(value, (LegacyMode ? StringComparison.Ordinal : StringComparison.CurrentCulture));
}

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


Я же вначале написал, не надо кидаться в такие крайности, если у вас нет с этим проблем. Просто, если код писали не совсем криво, то мало будет мест, которые можно исправить и сразу +200% к производительности. Наступает момент, когда тут немного, там немного и получили +10%. Мелочь, а приятно.
Да, интересная тема. Скорей всего займусь, тем более, что при обнаружении очевидных проблем, можно будет самому исправить в коде моно и попробовать влить в основной репозиторий.
То, что оптимизатор многие вещи убирает я уже понял, но так как я пишу под моно, то я предпочитаю некоторые вещи писать явно и не зависеть от реализации. А насчет nullable, так это вообще одно большое исключение из правил.
Позволяет в одной коллекции хранить объекты различного типа без боксинга. В WPF значения хранятся в EffectiveValueEntry, которые структуры, но значения внутри себя хранят в Object поле. Если количество различных типов заранее известно, то можно использовать union, чтобы не боксить, но при этом хранить их в одном месте.
Да, знаю. У нас тоже есть в некоторых местах такие штуки. А еще вот так извращаемся.
Скажем так: в конкретно нашем случае, мы лучше сделаем несколько лишних операций, чем выделим лишнюю память, которая влияет на GC и тем самым может вызвать блокировку потока. То есть мы пока еще не грузим процессор в 100% всё время, потому что есть блокировки, немалая часть из которых вызваны из-за GC.
Вообще, я имею в виду все блокировки, то есть когда мы сваливаемся в kernel lock и поток спит. Но в данном случае — да, проблема была в GC.
Да, всё так. Но как всегда теория выглядит хорошо, а в реальности не всё так безоблачно. Исходники открытые, можете почитать. Интересное чтиво :)
1

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity