Программирование для не-прикладных задач — это академические исследования.
Всё остальное программирование — так или иначе предназначено для решения прикладных задач.
Построить базу данных — это очень узкая специфическая область. Правильно пользоваться базой данных — другая, но менее специфическая. Современный фронт-энд это вообще отдельная песня, с кучей нюансов.
Но во всех этих задачах применимы паттерны, лучшие практики, идиоматические подходы языка/платформы и т.д. Фундаментальные вещи не меняются уже десятки лет, и если человек из знает и умеет применять, велика вероятность что он сможет (условно) быстро и качественно осваивать новые технологии и производить качественные решения. Именно такую «базу», я считаю, есть смысл проверять на собеседованиях/ассесментах, я не специфические знания фреймворка/библиотеки.
> кто сейчас метит в Джуны, и имеет большой опыт в индустрии
это как вообще?
Странная логика, получается чем опытнее инженер тем сложнее/медленнее он будет решать простые задачи? Мозг не может быть «заточен», мозг либо решает задачу либо нет.
Не могу представить себе инженера который быстро и легко решит, скажем, задачу распределённого консенсуса («изобретёт» PAXOS-like протокол, например), но который при этом не сможет инвертировать бинарное дерево :)
Именно это я и хотел донести, что работать синьором не всегда поможет прохождению интервью, как ни парадоксально.
Но я остаюсь при своём мнении, не навязывая его: если простая алгоритмическая задача ставит в тупик, то титул синьора как бы обязывает поправить ситуацию, не обязательно в контексте подготовки к собеседованиям.
Если надо пройти собеседование — надо учиться проходить собеседования. Это отдельный скилл, который достаточно условно коррелирует с успехом на будущей работе. Это все знают, но не меняют подхода.
Но с другой стороны, Senior Developer который не может инвертировать бинарное дерево (рекурсивное решение занимает 3 строчки кода) или написать за час BFS по графу, должен провести очень серьёзную «инвентаризацию» своих скиллов и сделать выводы.
Довольно плоское изложение инженерной работы, как по мне. Часто бывает что время на гибкое или универсальное решение на порядок (!) отличается от времени на добавление нужного функционала «здесь и сейчас». Плюс практически в каждой нетривиальной системе имеется в наличии определенный объем технических долгов, которые точно не ускоряют разработку гибких универсальных фич. Поэтому и получается что «работа на будущего работодателя» может сильно снизить КПД работы для текущего работодателя, особенно при доминировании операционных задач (когда надо просто вклеить новый график в мониторинг, а не изобретать велосипед для мониторинга)
Достойный ответ, конструктивная критика вместо пассивно-агрессивного тона и кворум для принятия решений позволяют быстро и безболезненно решать много производственных вопросов.
Поможет еще явное формулирование ценностей команды (манифест), который принимают все члены команды и который регулярно поддерживается в актуальном состоянии.
Автора по человечески жаль, выглядит будто человек застрял в тупике и не развивается. Из собственного опыта, профессионалам высочайшего класса не нужно никому ничего доказывать или кого-то «наказывать». Здоровые конкуренция и дух соперничества это полезно и важно, ударение на слове «здоровые».
Автору искренне желаю найти новые пути развития и перестать быть «чемпионом зала».
Наверное, будет не лишним упомянуть про еще один курс, доступный на coursera: «Algorithms: Design and Analysis, Part 2» который будет вести Tim Roughgarden из Стэнфорда (тыц). Курс начинается через 12 дней.
Если сравнивать курсы от Роберта Сэджвика и Тима Рафгардена, то мне кажется они дополняют друг друга, несмотря на то, что темы практически совпадают. Еще у Тима больше математических доказательств — меня, например, больше всего впечатлило доказательство работы «Find K-th largest element of unsorted array» (megresort based) за линейное время. Архив первой части курса Тима здесь
Думаю, книга Java Concurrency in Practice (легко гуглится) поможет разобраться в ситуации. Целая глава там отведена описанию подходов для прекращения работы потока по требованию. Лично мое мнение — запуская сторонний код, нет вообще никаких гарантий его работоспособности в много-поточной среде.
Если честно, не знаю как Double Shake определяется в iOS, поэтому тут не могу что-либо подсказать.
Но первое что приходит в голову если немного задуматься — это отслеживание изменения вектора, прочитанного с акселерометра. Момент, когда предыдущее и текущее значение этого изменения отличаются на какую-то величину калибровки, можно считать событием Double Shake.
Всё остальное программирование — так или иначе предназначено для решения прикладных задач.
Построить базу данных — это очень узкая специфическая область. Правильно пользоваться базой данных — другая, но менее специфическая. Современный фронт-энд это вообще отдельная песня, с кучей нюансов.
Но во всех этих задачах применимы паттерны, лучшие практики, идиоматические подходы языка/платформы и т.д. Фундаментальные вещи не меняются уже десятки лет, и если человек из знает и умеет применять, велика вероятность что он сможет (условно) быстро и качественно осваивать новые технологии и производить качественные решения. Именно такую «базу», я считаю, есть смысл проверять на собеседованиях/ассесментах, я не специфические знания фреймворка/библиотеки.
> кто сейчас метит в Джуны, и имеет большой опыт в индустрии
это как вообще?
Не могу представить себе инженера который быстро и легко решит, скажем, задачу распределённого консенсуса («изобретёт» PAXOS-like протокол, например), но который при этом не сможет инвертировать бинарное дерево :)
Но я остаюсь при своём мнении, не навязывая его: если простая алгоритмическая задача ставит в тупик, то титул синьора как бы обязывает поправить ситуацию, не обязательно в контексте подготовки к собеседованиям.
Но с другой стороны, Senior Developer который не может инвертировать бинарное дерево (рекурсивное решение занимает 3 строчки кода) или написать за час BFS по графу, должен провести очень серьёзную «инвентаризацию» своих скиллов и сделать выводы.
Поможет еще явное формулирование ценностей команды (манифест), который принимают все члены команды и который регулярно поддерживается в актуальном состоянии.
Автору искренне желаю найти новые пути развития и перестать быть «чемпионом зала».
Если сравнивать курсы от Роберта Сэджвика и Тима Рафгардена, то мне кажется они дополняют друг друга, несмотря на то, что темы практически совпадают. Еще у Тима больше математических доказательств — меня, например, больше всего впечатлило доказательство работы «Find K-th largest element of unsorted array» (megresort based) за линейное время. Архив первой части курса Тима здесь
Но первое что приходит в голову если немного задуматься — это отслеживание изменения вектора, прочитанного с акселерометра. Момент, когда предыдущее и текущее значение этого изменения отличаются на какую-то величину калибровки, можно считать событием Double Shake.