Не знаю, как у вас, но у меня любимая часть интервью — логические задачи.
Довелось пройти немало собеседований на вакансию разработчика, поэтому набралась небольшая коллекция.
Спешу поделиться с вами!

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

А вот задачка на выходные! Она плохо подходит, чтобы спрашивать на собеседовании, потому что слишком уж на инсайт (пожалуйста, никогда не задавайте такие на собеседованиях), и слишком простая для соревнований. Как раз чтобы доставить тот самый satisfying click в мозгу, за который мы любим программирование. Итак:

Есть большой массив из N 32-битных чисел. Каждое число встречается два раза, а два числа -- по одному. Найти эти два числа за один проход по массиву с константными затратами памяти (то есть не зависящими от размера массива).

Не забывайте использовать тег <spoiler> для решений в комментариях!

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


Видите пару схожих вопросов рядом? Вот и мой разум приоткрыл один глаз и сказал – «Хм… Знакомая тема, бро». Стараясь не думать, как выглядят глаза разума, я прочитал эти вопросы, комментарии к ним, и у меня появилось непреодолимое желание поделиться с сообществом своей историей. История под катом.

«Я экспериментировал с задачами кубического представления в стиле предыдущей работы Эндрю и Ричарда Гая. Численные результаты были потрясающими…» (комментарий на MathOverflow)

Вот так ушедший на покой математик Аллан Маклауд наткнулся на это уравнение несколько лет назад. И оно действительно очень интересно. Честно говоря, это одно из лучших диофантовых уравнений, которое я когда-либо видел, но видел я их не очень много.

Я нашёл его, когда оно начало распространяться как выцепляющая в сети нердов картинка-псевдомем, придуманная чьим-то безжалостным умом (Сридхар, это был ты?). Я не понял сразу, что это такое. Картинка выглядела так:


«95% людей не решат эту загадку. Сможете найти положительные целочисленные значения?»

Вы наверно уже видели похожие картинки-мемы. Это всегда чистейший мусор, кликбэйты: «95% выпускников МТИ не решат её!». «Она» — это какая-нибудь глупая или плохо сформулированная задачка, или же тривиальная разминка для мозга.

Но эта картинка совсем другая. Этот мем — умная или злобная шутка. Примерно у 99,999995% людей нет ни малейших шансов её решить, в том числе и у доброй части математиков из ведущих университетов, не занимающихся теорией чисел. Да, она решаема, но при этом по-настоящему сложна. (Кстати, её не придумал Сридхар, точнее, не он полностью. См. историю в этом комментарии).

Вы можете подумать, что если ничего другое не помогает, то можно просто заставить компьютер решать её. Очень просто написать компьютерную программу для поиска решений этого кажущегося простым уравнения. Разумеется, компьютер рано или поздно найдёт их, если они существуют. Большая ошибка. Здесь метод простого перебора компьютером будет бесполезен.

Введение

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

Платформа Android, да и наверное многие другие платформы не позволяют выполнять долговременные операции в UI потоке. Выполняя долговременную операцию в UI потоке вы просто напросто повесите программу.

Android предлагает для решения такого рода задач AsyncTask. AsyncTask позволяет выполнять долговременную операцию и взаимодействовать с UI потоком.

Проблема

Казалось бы ничего сложного, создаем AsyncTask передаем созданному AsyncTask указатель на текущую Activity и все готово, фоновый процесс работает, обновляет UI, все счастливы.

Все прекрасно работает до тех пор, пока не сменится ориентация экрана (Книжная → Альбомная, Албомная → Книжная) или приложение не будет отправлено в фон. Обычно при таком подходе после смены ориентации экрана происходит краш приложения.

На одном из проектов столкнулась с утечками памяти. Воспользовалась первым правилом разработчиков — загуглила. К моему глубокому разочарованию нашла много статей для программистов и совсем чуточку для тестировщиков. Большинство публикаций датированы 2011-2014 годом.

Ниже информация об утечках памяти, которая пригодится в 2017 году. Расскажу, чем их наличие грозит приложению, и перечислю несколько подходов к локализации.

С недавнего времени у меня появилась настойчивая мысль, что профессиональное развитие сильно замедлилось и это хочется как-то исправить. Да, читаю книги, слушаю курсы, но в то же время приходит и понимание того, что возможно пришло время сменить работу, здесь вроде как все изучено, плавно уходим в рутину. Данная мысль сподвигла меня на рассылку своего резюме в несколько компаний — лидеров рынка. После прохождения собеседования в 3 из них, я решил, как водится внести свои 5 копеек в освещение обширной темы собеседования, а именно технических вопросов по Java коллекциям, с которыми приходится сталкиваться. Да, знаю, читатель скажет: «коллекции — избитая тема, сколько можно», но часть из приведенных ниже вопросов, я задавал своим знакомым разработчикам, которые занимают именно позиции разработчиков («крепких середнячков», по меркам недалекой от Москвы глубинки, которые уверенно справляются со своей работой на практике, а вот в теории скажем так есть пробелы, потому, что работа не требует решения каких-то нетривиальных задач, да и потому что не всем это интересно — изучать как внутри работает структура данных), вызывало растерянность. Думаю, что рассмотренный материал будет не очень интересен разработчикам выше уровня Junior (я попрошу их комментировать, дополнять и критиковать изложенный здесь материал), а вот Junior`ы уверен, найдут в этой статье интересное для себя.