Мы в Palta активно ищем сотрудников, поэтому я собеседую людей уровня senior & lead. А до этого в Melsoft доводилось мидлов и выше собеседовать. Накопился ряд наблюдений, которыми хочется поделиться.
Сначала хотел написать на глобальную тему, вроде разницы между junior, middle, senior & lead, но дело шло туго, поэтому сделаю проще.
Расскажу о косяках, которые с большой вероятностью помешают пройти собеседование конкретно у меня.
По отдельности каждая проблема — не приговор, но точно снижает шансы на положительное впечатление.
Для каждой проблемы я написал упрощённый пример диалога. Надеюсь получилось наглядно. Главное помните, что вопросы и ответы там придуманы специально для иллюстрации проблемы, а не взяты из реальных собесов. По большей части :-)
Если вы хотите от жизни большего, не можете сжульничать и родились в СНГ.
Давно хотел написать пару соображений на тему, а раз сейчас идёт вступительная кампания, то и напишу.
Написанное я считаю справедливым для людей, которые хотят расти над собой: стать хорошим специалистом, создать что-то заметное, принести пользу обществу.
Этот текст мало полезен для тех, кому родители уже подготовили тёплое место, кто косит от армии, кто идёт учится «потому что надо» и так далее.
Строго субъективно, конечно.
Чёрт дёрнул вспоминать вышку. Я планирую немного забатанить машинное обучение, но сперва решил вспомнить, чему меня в университетах учили. Тем более, что математического анализа мне иногда не хватает.
Поэтому я нагуглил на Stepik курс с пятью звёздами сразу в двух частях (1, 2) за авторством Александра Храброва.
Первую часть я прошёл за 6 полных дней на 100%. Вторую, с перерывами, дней за 10 на 87%: стало жалко времени и сил. График в заголовке намекает на причину :-)
Попутно накопил заметок о курсе, о том как «правильно» учить математике. И как ей учить не надо.
Само собой, всё с моей колокольни.
Буду говорить в контексте программирования, но соображения можно распространить шире.
Когда мы описываем алгоритм: программу, доказательство теоремы или решение математической задачи — мы строим его описание в рамках некоторой формальной модели. В рамках соглашений и ограничений, которые мы явно или неявно принимаем.
Описать алгоритм вне формальной модели невозможно. Хотя бы потому, что любой язык — уже формализация.
Отсюда вытекает интересная проблема.
Спросили, использовал ли я системное мышление в реальной жизни и как оно мне помогло. А вот и не знаю, использовал ли :-)
Конечно знаю: использовал, помогло. Но чтобы ответить подробнее надо больше строк.
Есть несколько нюансов, которые усложняют ответ.
Во-первых, термины «система», «системное» перегружены значениями. Особенно в русском языке. В непрофессиональном контексте они имеют очень широкую трактовку, а профессионалы не горят желанием формализировать понятия. Особенно в рунете. В англоязычной среде дела идут лучше, но я бы не сказал, что на много.
Во-вторых, «системное мышление», «системная инженерия» — это мемплексы — наборы мемов-практик. Если я использую 2 практики из 10 — я использую мемплекс? А если 51 из 100? Кто вообще определяет входит практика в мемплекс или нет?
Использовать системную инженерию то же самое, как использовать гибкие методологии разработки. В том или ином виде их все используют, но в разных вариантах и с разным успехом. Эталонный agile вы вряд ли встретите, как и эталонную системную инженерию.
Поэтому отвечу сразу для нескольких контекстов.