да и 400 и 500 NET вполне реальные суммы. Работодатели ушли, но и специалистов много уехало. Но интересно посмотреть как через год изменится статистика.
Все шаги которые я написал как правило проходятся быстро, если ты натренирован. Поэтому они сами советуют решать leetcode до интервью, как и FAANG и около них. Например facebook дает 40 минут на 2 задачи, уровня easy первая и medium/hard вторая. (Проходил собес, но не получилось)
При этом, я сам не очень люблю алго-интервью, но есть 2 стула, либо фейлить собесы, злиться и грустить или принять правила игры и строить карьеру.
Если прочесть cracking coding interview и how Google works, то станет понятно чего ждут на собеседовании:
Убедился что точно и верно понял задание и необходимую сложность решения
Сам подумал над разными решениями до кодинга
Сам выяснил недостающие в задании нюансы
Сам написал что то типо тестов, что бы проверить себя потом, что алгоритм все пройдет (если инпут Х то ответ У)
Написал код
Обязательно проверил свой же код до сдачи
Если есть трудности, посоветовался с интревьером, это твой коллега и вы решаете рабочую задачу
Убедившись, что задача прошла тесты, скомпилируется и будет работать правильно сдаешь задачу
Яндекс смотрит как думает человек и нравится ли интервьеру то как думает человек. Решить алгоритм важно, но это 50% того, что хочет интераьер. Этого не достаточно для оффера. Покажите ему, что с более сложной задачей вы тоже справитесь, как минимум правильно поймете задание, напишите тесты и сходите к коллегам за помощью.
Однако все мы люди и интерьер смотрит через свою призму опыта, как бы не хотела компания унифицировать процесс найма. С этим нужно смириться и не грустить.
К сожалению, такую статью написать пока не могу. Так как чтобы написать статью про популярную библиотеку, нужно ее заиметь. Иначе, как по мне, получится как у инфоциган: "У меня бизнеса нет, но вас я научу быть на шаг впереди конкурентов"
Вы действительно правы! Использование native сейчас, кажется оправданным, если код действительно сложный, а человек/команда его пишущий действительно хорошо понимает тонкости языка.
Однако существовало мнение, что можно оптимизировать небольшие алгоритмы вынося часть кода в натив, именно небольшие алгоритмы которые что-то считают. Особенно выгодно это казалось для android. Но Проведя эти тесты я понял, что как android разработчик без углубленного знания C/C++ я вряд ли смогу написать код который будет быстрее чем на Java, а использование native для простых алгоритмов и вовсе с большой вероятностью не даст ожидаемого результата.
Смыслом статьи хотелось показать, что нет смысла использовать инструмент для микрооптимизаций несложных алгоритмов.
Здравствуйте! Нет, выполнять консольные команды из Android Studio не нужно, все работает из коробки. Т.е. в AS все намного проще. Советую прочитать эту статью которая рассказывает именно про AS.
Здравствуйте, простите меня за мой непрофессионализм в c/c++, но вопрос я не понял. Насколько я знаю, wstring в плюсах используется для unicode строк, а string для ASCII строк. Но какое это отношение имеет к моей серии статей? :) Попробуйте переформулировать вопрос, больше деталей. Возможно я, или кто-то из сообщества даст ответ.
Лично я в ходе изучения не видел никаких ограничений на минимальную версию API. Точно работает на версиях >= API 18. На более ранних версиях поддержка то же есть, но с некоторыми особенностями описанными на это странице developer.android.com
Привет! Да, я в начале статьи приложил ссылку на NDK. В андроиде использовать native удобнее, все автоматизировано из коробки и нет необходимости выполнять какие либо команды в консоли. В третей статье, которая выйдет 15 февраля и будет про perfomance я приведу пример использования NDK и ссылку на репозиторий.
Спасибо за комментарий, в idea по умолчанию используется Lint. Очень мощный инструмент, однако он медленнее Detekt. Именно в этом его главный проигрыш. Так же Detekt написан специально для kotlin, а значит можно рассчитывать на более качественный анализ, в теории.
Цель статьи познакомить с Detekt, возможно, в будущем я напишу статью именно конкурентных отличий статических анализаторов на Kotlin.
Починил, большое спасибо!
да и 400 и 500 NET вполне реальные суммы.
Работодатели ушли, но и специалистов много уехало.
Но интересно посмотреть как через год изменится статистика.
Все шаги которые я написал как правило проходятся быстро, если ты натренирован. Поэтому они сами советуют решать leetcode до интервью, как и FAANG и около них.
Например facebook дает 40 минут на 2 задачи, уровня easy первая и medium/hard вторая. (Проходил собес, но не получилось)
При этом, я сам не очень люблю алго-интервью, но есть 2 стула, либо фейлить собесы, злиться и грустить или принять правила игры и строить карьеру.
Если прочесть cracking coding interview и how Google works, то станет понятно чего ждут на собеседовании:
Убедился что точно и верно понял задание и необходимую сложность решения
Сам подумал над разными решениями до кодинга
Сам выяснил недостающие в задании нюансы
Сам написал что то типо тестов, что бы проверить себя потом, что алгоритм все пройдет (если инпут Х то ответ У)
Написал код
Обязательно проверил свой же код до сдачи
Если есть трудности, посоветовался с интревьером, это твой коллега и вы решаете рабочую задачу
Убедившись, что задача прошла тесты, скомпилируется и будет работать правильно сдаешь задачу
Яндекс смотрит как думает человек и нравится ли интервьеру то как думает человек. Решить алгоритм важно, но это 50% того, что хочет интераьер. Этого не достаточно для оффера. Покажите ему, что с более сложной задачей вы тоже справитесь, как минимум правильно поймете задание, напишите тесты и сходите к коллегам за помощью.
Однако все мы люди и интерьер смотрит через свою призму опыта, как бы не хотела компания унифицировать процесс найма. С этим нужно смириться и не грустить.
К сожалению, такую статью написать пока не могу. Так как чтобы написать статью про популярную библиотеку, нужно ее заиметь. Иначе, как по мне, получится как у инфоциган: "У меня бизнеса нет, но вас я научу быть на шаг впереди конкурентов"
Большое спасибо за комментарий!
Вы действительно правы! Использование native сейчас, кажется оправданным, если код действительно сложный, а человек/команда его пишущий действительно хорошо понимает тонкости языка.
Однако существовало мнение, что можно оптимизировать небольшие алгоритмы вынося часть кода в натив, именно небольшие алгоритмы которые что-то считают. Особенно выгодно это казалось для android. Но Проведя эти тесты я понял, что как android разработчик без углубленного знания C/C++ я вряд ли смогу написать код который будет быстрее чем на Java, а использование native для простых алгоритмов и вовсе с большой вероятностью не даст ожидаемого результата.
Смыслом статьи хотелось показать, что нет смысла использовать инструмент для микрооптимизаций несложных алгоритмов.
Здравствуйте! Нет, выполнять консольные команды из Android Studio не нужно, все работает из коробки. Т.е. в AS все намного проще. Советую прочитать эту статью которая рассказывает именно про AS.
Здравствуйте, простите меня за мой непрофессионализм в c/c++, но вопрос я не понял.
Насколько я знаю, wstring в плюсах используется для unicode строк, а string для ASCII строк. Но какое это отношение имеет к моей серии статей? :)
Попробуйте переформулировать вопрос, больше деталей. Возможно я, или кто-то из сообщества даст ответ.
Спасибо за внимательность :) был не прав, исправлюсь.
По поводу шагов, не знаю что ответить, посчитал, что так прозрачнее последовательность действий.
Лично я в ходе изучения не видел никаких ограничений на минимальную версию API. Точно работает на версиях >= API 18. На более ранних версиях поддержка то же есть, но с некоторыми особенностями описанными на это странице developer.android.com
Привет! Да, я в начале статьи приложил ссылку на NDK.
В андроиде использовать native удобнее, все автоматизировано из коробки и нет необходимости выполнять какие либо команды в консоли. В третей статье, которая выйдет 15 февраля и будет про perfomance я приведу пример использования NDK и ссылку на репозиторий.
Цель статьи познакомить с Detekt, возможно, в будущем я напишу статью именно конкурентных отличий статических анализаторов на Kotlin.