Интервью ужасны, лайв кодинг зло, теоретические вопросы бесполезны
HTML-код
- Опубликовано: 2 окт 2024
- Я не первый, кто говорит о том, что у тенических интервью много недостатков, кто-то считает, что теоретические вопросы зло, кто-то не любит лайв кодинг. Я решил рассказать свое мнение о интервью.
Ссылки из видео:
/ %d0%9f%d1%80%d0%be%d0%...
/ %d0%98%d1%80%d0%b0%d0%...
Поддержать меня: boosty.to/mflenov
Обо мне: www.flenov.ru
Мой ИТ блог www.flenov.info
Мой просто блог blo.moe
Twitter: / flenov
Инстаграм: / mflenov
Телеграм: t.me/mflenov
Кстати, рекомендую посмотреть два моих видео про лучшее интервью ruclips.net/video/QsMNL7KTYKo/видео.html и худшие интервью ruclips.net/video/eV7SdXJxU6g/видео.html
for int i = 0 to 11 {
sum = sum + array[i] - i
}
по моему в вашем решении лишняя проверка (i>0) плюсовать 0 н страшно а ниже 0 I не будет.
еще можно сразу в процессе минусовать I От array(i) используя только 1 переменную.
Чем меньше опыта у собеседующего и чем Уже его кругозор, тем более странные интервью с узкими техническими вопросами и очень далекими от жизни теориями.
Самыесилные интерьюеры на моей памяти спрашивали очень конкретные практические вещи и моделировали ситуацию вместе с интервьюируемым. Зато если на одном проекте за три года дорос до "синьера", вот у такого интервьюера держись, там вопросы - прям из оглавления учебников и справочников слизаны.
И еще меня улыбает что на интервью все такие специалисты и компании такие прям на острие прогресса, а в код смотришь - там такое унылое, кривое, неподдерживаемое дерьмо, которое можно только в приступе шизофрении написать :)
Не обязательно надо быть крупным руководителем чтобы считаться успешным и просиживать штаны в офисе. Не обязательно гнаться за повышением в должности, только для того чтобы тебя не считали неудачником. Сейчас надо проявлять творческие фантазии, что-то полезное изобретать. Например чтобы изобрести говностокий или говноизоляционный костюм, надо поработать в говне. Чтобы усовершенствовать мотоплуг или трактор, надо поработать в поле. Врят ли ты сможешь это все изобрести просиживая штаны в офисе. Если ты будешь делать вертикальную карьеру, то все твои силы будут уходить на борьбу с конкурентами которые тоже хотят занять высокие должности. А там уже не до творческих идей, там надо думать как обороняться правильно, а в семьдесят лет (если ещё доживешь) ты возможно поймешь что вся твоя жизнь уходила не на реализацию творческого потенциала, не на реализацию своих талантов, не на то что у тебя лучше всего получается, а на оборону и войну с конкурентами за высокие посты и возможно ты поймешь что за это время ты мог бы что-нибудь полезное изобрести. Так что не надо стесняться работать за станком, не надо стесняться работать в поле, не обязательно становиться бизнесменом, не обязательно просиживать штаны в кабинете.
Шанс стать руководителем мелкого звена-это шанс один из десяти.
Шанс стать директором филиала-это шанс один из ста.
Шанс стать генеральным директором- это шанс один из тысяча.
Шанс стать призедентом крупной корпорации в которой работают десять тысяч работников- это шанс один из десяти тысяч.
А вот время потраченное на бесмысленную борьбу за кресло руководителя- шансы очень большие. Не нужны вам эти мнимые шансы, не нужна вам эта политическая борьба в компании. Работайте слесарями, работайте в полях. Изобретейте что-то. Проявляйте изобретательность, проявляйте инженерные смекалки, проявляйте творчество. Не тратьте свою жизнь на бесмысленную борьбу за кресло-руководителеля.
Мой девиз в жизни такой:
Терпеливо
Активно
Учитесь
Хорошим
Искреним
Делам
Запомните эту аббревиатуру и пусть этот девиз сопровождает вас везде.
Наши соотечественники на собеседованиях в роли собеседователя особо не смотрят на знания. Они выбирают себе удобного человека-коллегу.
В Канаде тоже это часто бывает причиной найма
@@programisli мне кажется что между неприятным и приятным человеком выбор очевиден, даже если приятный чуть слабее по знаниям, один фиг они будут писать +- одинаковый код.
@@redeyes256 Просто говори всегда да, на этом построены все мировые корпорации. Кто с чем не согласен свободен.
это в любой области так) Если человек обаятелен, то без работы не останется. Главное, чтобы не совсем дебил был.
У нас (как и в Канаде, и в США, и в Германии, и в Англии) подавляющее большинство проектов - это реализация маловажных приложений, чтобы потратить ИТ-бюджет. Конечно, в этом скиллы не нужны, собрать кое-как работающее приложение из готовых кубиков может любой формошлёп. Поэтому ищут по софт скилам и чтоб был психологически комфортен. Полноценных разработчиков собеседуют по-другому, но из здесь присутствующих вряд ли кто-то с этим сталкивался.
RUclips, знай, это годный контент )
15:00 Проблема в том, что то, как программист тиранит начальника на собеседовании вопросами никак не соотносится с реальным кодированием. Я никогда на собеседовании уточняющих вопросов на такие задачи не задаю. Но, при этом, часто находил ошибки в ТЗ, в том числе в экономических формулах.
Кому нужен вшивый гугл? Ну, предложат вдвое больше, чем компашке второго эшелона, но во-первых, деньгами там будет меньше половины. Остальное - опционы и прочая хрень, которую 10% сотрудникам не дадут, т.к. они попадут в боттом тир, а остальные будут сидеть 3 года на амфетаминах, чтобы это получить. А после 3-х лет - ап ор аут, в надсмотрщики-тимлиды или на улицу, выжатым как лимон. Вы учитесь, чтобы за три года себя сжечь ради процветания гуглосекты? Ну-ну...
Наверное хороший программист не определяется возможностью писать код под стрессом)
Ну компаниям нужны те, кто может это делать. И плохими таким программистов точно не назвать. Хотя и те, кто не может писать не обязательно плохие.
За последний месяц, прошел около 15 интервью на Джава разработчика в Москве. 90% вопросов одинаковые. Только 1 компания гоняла по алгоритмам, бинарный поиск, сортировки, оценка сложности O(n),O(1) И так далее. Но конкретно по джава вопросов почти не было. Для себя отметил около 40 вопросов которые задают почти все. Это джава кор, коллекции, немного многопоточность, как устроена та или иная коллекция и какая в чем превосходит другую. Многопоточность 9 из 10 не используют, но все же спрашивают. Далее идут вопросы по фреймворку, как он работает под капотом, зачем он нужен. Далее идут вопросы по БД, транзакции, подробности про ACID, уровни изоляций, денормализация, партиции, индексы. После этого уже вопросы архитектурные. Как разбивать на микросервисы, какие паттерны использовать в определенных случаях и тд. Не знаю раскроет ли все это кандидата полностью, но даже когда я отвечал на все вопросы, иногда тупо не проходил софт скиллс, там уже сложно понять что им не понравилось, твоя борода или твои вопросы про внутренние процессы
Они поняли что ты отвечаешь на их книжные вопросы сам, а они так не могут. Следовательно ты умнее их и такого им не надо
Да где ты столько нашёл- то в Москве? Я рыл по 2-3 месяца подряд, находил сотню вакансий, из них 95 - формошлёпы (какие там алгоритмы, синтаксис Джавы и пару модных фреймворков спросят, и всё), 3 - продвинутые формошлёпы, 1 - жулики (хотят, чтобы кандидат им кусок системы реализовал как "тестовое задание") и 1 - реальная работа. Залез как-то в Яндекс, прошёл все пять техскринингов, мне прислали 110+ вакансий, из них только 5 - с алгоритмами, и в 4 из этих пяти собеседуют по софт скилам, т.е. им тоже нужны формошлёпы, а не мозги.
А стримы с женой это вообще жесть
Ну не знаю, если в компании требуется постоянно работать под стрессом, и там все горит - то нафиг такую компанию, пусть ищут пожарных лучше)) Я нормально работаю лишь в тишине и одиночестве) Нормальная жизнь и сон дороже)
Работать в тишине и спокойстве - это мечта, но не всегда так получается
Пожарные это тех Лиды 😂
Ситуация, когда срочно просят что то посмотреть, на собеседовании и на работе очень сильно отличается, на собеседовании совершенно чужие люди и ты не в контексте задачи или проекта, на работе, вы уже в одной лодке с знакомыми тебе людьми и в контексте проекта или задачи.
Я не прошёл собес в Альфу. Сделал задачи sql с минимальными подсказками. Но уверенно сделал код ревью и указал на все проблемы. Нашёл sql иньекцию. Оптимизировал async - выявил sync over async. Завернул data access логику в транзакцию. Итого не взяли так как не ответил подробно про yield оператор и как внутри работает task.
Ну что сказать, в альфе дебилы, раз так придираются. Хотя, могли это начать делать из-за Волков, которые рисуют опыт
Теоретические вопросы плохи потому что их набор сильно ограничен и любой дурак может выучить ответы на них. Ответы на теоретические вопросы зависят больше от опыта собеседований чем от опыта работы.
Лайвкодинг работает хорошо для программистов, которые психологически к нему готовы. Под стрессом даже очень опытный и умный человек может очень убедительно изображать дилетанта под стрессом, потому что логика на собесе работает в короткую и глубокие размышления не катят.
Про стрессо-устойчивость тоже неправда. Потому что быть умным в стрессовом режиме когда за спиной менеджер абслолютно не сложно и такой опыт есть у всех, сложно быть умным когда на тебя смотрят люди, которые ПРОВЕРЯЮТ умный ли ты с высокими ставками. Человек подвержен гипнозу, когда на него смотрят люди которые сомневаются умный ли он, ему становится очень сложно быть умным. Напротив, менеждер за спиной хочет чтобы вы решили задачу и поэтому это не вредит.
Полностью согласен, недавно проходит собес, дали несложную задачку (что-то похожее решал на leetcode), и я очень сильно осыпался, даже стыдно как-то. В итоге всё завалил, так и не смог её решить. Зато после завершения собеса очень быстро вырубился и сделал.
6:00
1) Массив
2) Cвязный список
3) Динамический массив или список
4) Стэк
5) Очередь
6) Хэш-таблица или словарь
7) Множество
Больше структур данных которые есть в C# я не знаю.
Ну и хватит для большинства задач
Теоретический вопрос на уровне "Что такое линия кеша". "Что такое CSRF" и т.п.
Ну вот и здравствуйте. По себе скажу, что я в первую и последнюю очередь смотрю на стремление человека искать решения. Если человек что-то не знает, то он узнает в процессе работы и так. Главное - это ум человека для меня, а это никакими тестами и алгоритмами не проверить.
Можно к вам на работу?
про решение чуваком задачи про повторяющееся число - если вдруг заменить числа объектами, то его решение всё равно будет работать, а решение Михаила - нет. Если бы того чувака спросили про это, он мог бы в качестве достоинства своего решения про это рассказать. Но если не думать о распространении решения на другие типы данных, то решение Михаила, конечно, в 100 раз, что называется, умнее. Вариант с битами - прикольный))) Я, когда решаю задачу, невольно думаю о том, что условия могут немного(/много) измениться, поэтому тянет делать более универсальные решения. Это, наверное, не совсем правильно..(( Вместо чисел могут появиться объекты, повторений может быть не 2, а хз сколько (и тогда решение с битами не прокатит), чисел может быть не 11, а овердохрена и т.д. Самое правильное, наверное - прям сразу обговорить эти моменты, когда тебе дали задачу. Кстати, тяга к универсализму может и работе вредить - нужно решить конкретную задачу в текущих данных и фсьо, а вместо этого "заново изобретается спринг"... :-/ В общем, YAGNI - это, наверное, про это.
В том то и дело, что слишком специфическое задание - есть все числа от 1 до 10 и одно из них повторяющееся. Не думаю, что в реальной жизни потом придется решать подобное, поэтому хеш приняли. Но интервьюеру интересно в данный момент размышление
Хороший программист может не знать что такое инкапсуляция, но он обязан понимать/ощущать что это такое. Такое у меня мнение. Вопрос только как вытащить из него понимает он это или нет. А ответ на прямой вопрос "что такое инкапсуляция" не стоит вообще ничего. Только время тратить)
Da v c++ net raznizi mezdu class/struct, iskluchaya oblast' vidimosti po umolchaniy. A vot v C# est' raznica, class - reference type, struct - value type, vot etogo mnogie ne znayut, vidimo daze avtor rolika.
Купи наклейки с русскими буквами на англ. клаву и не заставляй людей страдать
@@fj8017 Ne straday, teba nikto ne zastavlaet.
@@dmitrii1703 Чел, хватит...
2:33 "Братан давай возьмём у тебя интервью, что ты думаешь про интервью на программиста"))))
Структуры в основном использую для проброса данных в Native
Я убедился, что подстрессом соверенно не могу писать код, когда продакшен у нас упал и мне нужно было написать исправление, прямо в MS Teams митинге, где присутствовала толпа народу.. Я минут 5 не мог сосредоточиться и даже не мог понять с чего начать, после чего сказал, что давайте я напишу исправление и созвоонимся через пол часа. Как только положил трубку сразу все пошло ... Стресс это ужасно
Бесспорно, это ужасно, но это проблема нашей работы и этот навык нужно отрабатывать. Ходить по интервью, пробовать решать задачи, когда на тебя смотрят...
@@programisli Когда смотрят то еще пол беды, а когда еще и впятером говорят и обсуждают на неродном для тебя языке. Не скажешь же им "Заткнитесь вы все, Чапай думать будет!"
@@programisli нет надо просто отказываться работать с мудаками и всё) Искать приятных себе людей нормальные нетоксичные компании и всё будет хорошо) Никто никому ничего не должен.
насчет задачки. Сложить все 11 чисел, потом сложить от 1 до 10. Первое отнять от второго. Гугл держи чемодан с бабками поставь стол из кокоболлы, я иду XD
Не потом, а одновременно
for int i = 0 to 11 {
if (i > 0)
Sum1 += i;
Sum2 += array[i]
}
profit = Sum2 - Sum1
@@programisli Ну теперь уж точно примут. Ладн еще учится и учится
@@programisli а можно узнать зачем проверка i>0 ? можно же просто так суммировать без проверки.
@@programisli еще можно просто взять одну переменную и плюсовать array[i] и отнимать i сразу.
for int i = 0 to 11 {
sum = sum + array[i] - i
}
@@smbatadamyan220там должно быть if (i
Какое-то время "заставили" писать по взор SQL код, задача простая, но блин, когда на тебя смотрят, когда у тебя тайм-лимит, руки опускаются. Ненавижу такие интервью.
На счет терминологии типа "инкапсюляция", полиморфизм и пр. Задали как-то мне такой вопрос, про что я в книже читал лет 20 назад) Я затушился. При том, что у меня за плечами 3 крупных продакшн проектов за 10+ лет, а определение "не знаю" ;-)))
Я так прямо и спросил интервьера "Ну не знаю книжного определения, но как-то же пишу код"... На что ответа не получил. Видимо вопросы на интервью сами где-то из инета достали....
Ну учиться писать с человеком за плечами полезно. Тут нужно просто походить по собеседованиям и этот опыт появится.
На счет определения инастыляции, три крупных проекта за плечами и ни разу тебе не понадобилось определение, оно просто на фиг не нужно. Определение ничего не говорит о программисте
Решение может и неэффективное, зато потом его гораздо проще прочитать и поменять, чем разбираться какие биты меняются в числе и что вообще происходит)
Ну с битами решение такое же по своей идее, тут просто данные хранятся не в хеше, а в битах
Второй!!!)
Первый!!!
Расчет окончен)
for int i = 0 to 11 {
sum = sum + array[i] - i
}
А мне только предстоит искать работу программистом. Два года к этому шел, а наверно и всю жизнь. Без опыта работы походу тяжело найти будет, может Хом проекты как то поспособствуют.
Попробуй, можно что-то открытое сделать на гитхабе
Интересно на интервью спрашивать, как бы человек спроектировал приложение. Тема широкая и позволяет определить уровень человека по качеству и глубине вопросов, которые он задаст.
Это отличный вопрос, но он ближе к синьеру. Джуниора спрашивать такое наверно не очень хорошо, только в ступор загонешь его
Пожары на работе говорят о плохом менеджменте.
Нахер такую работу с пожарами, я не пожарник.
В галерах это регулярно, клиент пришел и сказал, что нужно сегодня и менеджеры не могут отказать.
Значит менеджеры профнепригодны.
я бы тоже не ответил что такое managed язык, первый раз такой вопрос слышу
А вот в этом и прикол, что никто не спрашивает и я не требую определения, просто что это для тебя дает и тут хорошим ответом может быть - управляемый код дает плюс с управлением и безопасностью памятью и на эту тему потом можно порассуждать
@@programisli а какой код не управляемый? весь код управляемый и управляется он разработчиком. ну разве что на php с памятью не поработать
Обычнов любой книжке по C# это прямо первая страница первой главы :) Просто синиоры уже подзабыли когда книжки читали
Только сейчас понялчто хэш это имелся в виду HashTable, блин для меня хэш это всегда было число - контрольная сумма. Опять таки вопрос в точности терминологии - немножко не точно сказанное слово и получается кофуз вместо подсказки на решение.
Согласен, нужно быть точнее, обычно мои видео долгие как раз потому что подбираю слова
Как выглядит решение с HashTable?
Если бы менеджер стоял за спиной во время лайвкодинга, то я бы сгорел от стыда во время гугления или, не дай Бог, во время перехода на StackOverflow в результатах выдачи.
Я помню в Канаде лет 10 назад у меня была проблема и я подошел к менеджеру с вопросом, что делать и он начал гуглить при мне. Так что ничего страшного в этом нет
@@programisli гыгыгы)) Я еще смотрю видос, оставил коммент пока не забыл. Спасибо за выпуск.
Когда я замахался объяснять, что такое инкапсуляция, наследование и шо никто не понимал - полиморфизм, и писать реверс строки на Си, мне повезло. Я с английским пролетал. Ну,... Мы занимаемся вот этим. Нам надо вот это и это. Вы можете? Могу. Вам это интересно? Приходите завтра на работу. А я думала, что вы не придете. Самое лучшее интервью :-)
Не обязательно надо быть крупным руководителем чтобы считаться успешным и просиживать штаны в офисе. Не обязательно гнаться за повышением в должности, только для того чтобы тебя не считали неудачником. Сейчас надо проявлять творческие фантазии, что-то полезное изобретать. Например чтобы изобрести говностокий или говноизоляционный костюм, надо поработать в говне. Чтобы усовершенствовать мотоплуг или трактор, надо поработать в поле. Врят ли ты сможешь это все изобрести просиживая штаны в офисе. Если ты будешь делать вертикальную карьеру, то все твои силы будут уходить на борьбу с конкурентами которые тоже хотят занять высокие должности. А там уже не до творческих идей, там надо думать как обороняться правильно, а в семьдесят лет (если ещё доживешь) ты возможно поймешь что вся твоя жизнь уходила не на реализацию творческого потенциала, не на реализацию своих талантов, не на то что у тебя лучше всего получается, а на оборону и войну с конкурентами за высокие посты и возможно ты поймешь что за это время ты мог бы что-нибудь полезное изобрести. Так что не надо стесняться работать за станком, не надо стесняться работать в поле, не обязательно становиться бизнесменом, не обязательно просиживать штаны в кабинете.
Шанс стать руководителем мелкого звена-это шанс один из десяти.
Шанс стать директором филиала-это шанс один из ста.
Шанс стать генеральным директором- это шанс один из тысяча.
Шанс стать призедентом крупной корпорации в которой работают десять тысяч работников- это шанс один из десяти тысяч.
А вот время потраченное на бесмысленную борьбу за кресло руководителя- шансы очень большие. Не нужны вам эти мнимые шансы, не нужна вам эта политическая борьба в компании. Работайте слесарями, работайте в полях. Изобретейте что-то. Проявляйте изобретательность, проявляйте инженерные смекалки, проявляйте творчество. Не тратьте свою жизнь на бесмысленную борьбу за кресло-руководителеля.
Мой девиз в жизни такой:
Терпеливо
Активно
Учитесь
Хорошим
Искреним
Делам
Запомните эту аббревиатуру и пусть этот девиз сопровождает вас везде.
Более безобразной задачи для собеседования на программиста, чем задача с поиском повтора в вырожденном и специально заточенном на примитивный математический трюк случае, сложно себе представить, сразу возникает вопрос, а вам точно программист нужен или математик-фокусник? Оценка правильности решения задачи поиска повтора с массивом из 11 чисел в дапазоне 1-10, также вызывает сомнения. Давайте немного усложним, не отсортированный список из 12 элементов, диапазон 1-10, два повтора, нужно найти повторяющиеся числа, какой алгоритм для этого вы считаете правильным и в чем его преимущество перед простым перебором?
Так ведь массив итак в задании был не отсортирован. Вопрос не в математики, а в том, чтобы увидеть мышление кандидата
@@programisli хотелось бы увидеть решение без "бекдоров", можно схематично, без кода и действительно ли оно для листа в 10-12 элементов оптимально?
Давно смотрю но не знал про программысли видиоуроки
Я ТОЖЕ ОБ ЭТОМ ГОВОРЮ !!!!!!!!!!!!!! Я выделил 3 типа лайвкодинга......
Сразу лайк и оставлю еще комментарий, потому что #крутьконтент
норм. про лайф кодинг начал думать по другому.
Было бы круто узнать про решение с зажиганиями битов. Никак не могу догадаться
Идешь по циклу, увидел число 1, проверил, если не горит первый бит зажег первый бит в числа, увидел число 5, проверил, если не горит пятый бит, зажег его, и так далее. В принципе тот же хеш, просто за счет того, что в задании указано, что чисел мало, достаточно использовать двубайтовое число и использовать битовые операции
Выбирать нужно самое простое решение из возможных. С битами обычный энтерпрайз разработчик не часто работает. В основном битовые операции могут пригодится в алгоритмах шифрования, там да.
А эти утки совсем распоясались 😠
3:15 оч правильный подход с оглаской еще одного канала и просьбой подписаться
После последнего поста я понял, что много людей смотрят этот канал и не знают про второй и третий
@@programisli я вообще не сразу понял, что канал другой, даже после того как ссылку кидали, подумал плейлист на этом канале
Ребята вы че? ООП, и в частности полиморфизм, как его главная часть - ключевой момент в разработке, без этого не будет Dry код, за который не стыдно. Если ты не шаришь в ООП - в дотнете точно делать нечего
Знание определения не гарантирует умение применять, это разные вещи, поэтому лично я считаю, что спрашивать в теории полиморфизм смысла нет, а вот можно задать практический вопрос, это будет намного нагляднее
Был пару раз кодинг онлайн, в блокноте, вполне норм. А кодинг на SQL написать запрос с парой джоинов - да изи
Спасибо большое за видеоуроки.
Спустился в комменты и хорошо посмеялся. Люди сравнивают программистов с поварами, юристами, врачами.
Вам не кажется, что это не одно и то же? Если задумаетесь об этом, то придёте к выводу, что в нашем мире мало аналогий, и таким способом почти нечего сравнивать.
Каждая профессия уникальна и конечно же собеседование библиотекаря и программиста будут разными. Но мы же можем искать аналогии в других профессиях и брать что-то на вооружение? Откуда пришел Скрам? Его родоночальником является автопроизводитель - Тойота. А сейчас уже редко можно встретить ИТ компанию без скрама. Так же и в поиске персонала можно искать какие-то вещи в других направлениях.
Спасибо, если по питонячи то как то так)) решение junior😉
А как хешем сделать не подскажите? Ваш вариант просумировать тоже крут, но это если мы знаем кол элементов в списке
import collections
list_num = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 3]
print([item for item, count in collections.Counter(list_num).items() if count > 1])
То же самое можно с помощью LINQ сделать в C# и с точки зрения красоты кода это выглядит красиво, но с точки зрения решения не уверен, что кто-то на собеседовании его примет.
Вы совсем не упомянули Россию, где тяга к алгоритмам просто дошла до безумия, когда в том же Яндексе людей гоняют несколько дней на собесах по алгоритмам и структурам данных, а насмотревшиеся на это безумие эффективные тим лиды из других компаний начинают на собесах спрашивать алгоритмы и паттерны у джуниоров фронтендеров, что совсем уже безумие. И могут себе позволить, потому что на одну вакансию по 36 человек, много с высшим образованием.
Я не знаю, как в России, я говорил о том, что в Канаде и несколько раз у меня были интервью в США. Так что про Яндекс не могу ничего сказать
я бы давал кусок кода чтоб кандидат его отрефакторил и починил
Писать код под стрессом это плюс, конечно, да вот только писать код на интервью в незнакомой обстановке с незнакомыми людьми, не зная, что они думают и как на это смотрят, и писать код даже и под взглядом продакта - это все-таки очень разные вещи.
Согласен, поэтому и сказал, что тут еще и задача менеджеров и интервьюеров создать обстановку
Что-то, я не понял решения с суммами 1+2+3+4+3+5=18; 1+2+3+4+3=13; 18-13=5. 1+2+2+3+4+5=17; 1+2+2+3+4=12; 17-12=5. Ведь, то что мы не прибавили в первый раз, то и будет результатом разницы.
Нужно две суммы - сумма чисел от 1 до 10 и сумма массива:
for int i = 0 to 11 {
if (i > 0)
Sum1 += i;
Sum2 += array[i]
}
profit = Sum2 - Sum1
@@programisli прикольно, а если у нас есть такой массив
int sum1=0;
int sum2=0;
Int itog=0;
Int [] n={1024,8,5,777,7,101,3,25,0,7}
for(int i=0;i
@@seka1309 в задаче четко сказали что 11чисел в массиве от 1 до 10 и повтояряется только 1 из них.
Лично я не мог работать когда начальник у меня за спиной.
Сразу падает скорость, вот не знаю как такое тренировать.
Уверенность и опыт ну и плевать должно быть, кто там смотрит за спиной
@@programisli Не могу так, даже дома раздражает когда я сижу за компьютером и в метре от меня стоит.
Как будто над душой стоят.
Лебедь понял, что он не будет работать
Не прошел собеседование
@@programisli и стал демонстративно показывать, что он думает о собеседованиях)))
Не совсем уловил мысль, в превью указано "лайвкодинг зло", в конце видео "учитесь решать задачи под стрессом". Не касаясь интервью был в реальной ситуации, когда ПМ попросил поправить модуль (мелкий фикс) и я сходу затупил в async вызов, но я думаю он все понял, поэтому сказал что отвлекать не будет и отошел, причем потом смотришь - задача на 2 минуты, а под взглядом со стороны начинаешь тормозить
Я взял высказывание, которое достаточно часто вижу - "Лайв кодинг зло" и высказал свое мнение. Я не считаю его злом, потому что кодинг прямо на интервью говорит многое, какой программист перед нами.
Кстати, а почему с вашим богатым опытом в разработке, вы Михаил, сами до сих пор не в каком нибудь FAANGe/бигтехе? Судя по вакансиям можно ж и удаленно работать, да и ваша локация позволяет, в Торонто офисы многих компаний есть
У меня никогда не было целью большая компания, потому что мне больше нравятся небольшие компании. Удаленно - на сколько я знаю, даже сейчас FAANG-и начинают выгонять своих сотрудников в офис, а у меня 100% удаленная работа.
А как быть когда через ЛинкедИн поступает множество предложений прособеседоваться, я соглашаюсь, но не прохожу собеседования? Может лучше сразу отказываться от таких интервью? Пишу на С# всего 3 года...
А зачем отказываться? Если тебя все устраивает и ты 100% дашь отказ, то отказывайся. Если есть шанс, что перейдешь, то соглашайся. Я часто отказываю сразу, если знаю, что не соглашусь в любом случае, потому что на нынешней работе все устраивает
насчет пожара надо пройти курс когнитивно.поведенчиской.терапии чтобы быть спокойным и не парится по мелочам. Если кто за спиной стоит, то автоматический думаешь что сейчас будет негативная критика или оценка. Этот бред вообще всем надо убирать на работе. Жить будет легче и злится, потеть ненадо.
А не должно быть критики, и тогда и мыслей не будет. А даже если и есть критика, нужно к ней относится спокойно. Если бы я резко реагировал на критику в комментариях, уже давно удалил бы канал.
13:10 - что за бредовый алгоритм? он не будет работать.
1
2
2
3
4
5
6
7
8
9
10
сумма всех 57, сумма без одного последнего 47, и того разница 10 (а должна быть 2 по логике алгоритма)
может имелось ввиду просуммировать все числа от 1 до 10 = 55. И вычисть это число из суммы других чисел.
Сумма всех чисел - сумма индексов (не чисел) от 1 до n-1
я делал попытки использовать структуры в свифте) долго ждал момента, когда они были бы уместны. и что вы думаете? чуть позже оказалось, что нифига они в данном случае не подходят. реально не могу представить, когда бы они были полезны.
Да, классы чаще нужны, просто тема была в том, что смысл на собеседованиях спрашивают про структуры, если в работе их потом не будут использовать
Работаю в бюджетной гос организации, получаю 1000 долларов в переводе на нац валюту, на работе пол дня шлангуеш но зарплату свою берешь, плюс соцпакет отпуск выходные, праздники, стаж пенсия, хочу стать программистом но не получается пока, подскажите стоит ли менять комфортные условия, на работу по полной, программистом всегда хотел стать, и это желание не оставляет, стоит ли идти в прграммисты.
Последнее было вопросом или утверждением на счет стоит идти в программисты? Это решать каждому самому, ноя рекомендую всем, что стоит попробовать
Зачем халяву менять на каторгу? Любишь программировать - программируй что-то своё пока "шлангуешь" на основной работе
кілька структур - 5-10
Нет, он хотел дать совет поплюйте на все, никого не слушайте - делайте как считаете нужным🤣🤣🤣 это я про птицу
Так она же целую минуту показывала прям, что думает по этому поводу.
Перед менеджером можно загуглить, на интервью этого не сделаешь
Интервьюеров надо использовать как гугл. Не знаю как в России, а в Канаде у нас без проблем если кто-то не знает, как пишеться функция, то мы подскажем синтаксис и все с ней связанное, но меня часто интересует какой вопрос спросит кандидат, когда не знает.
Подплывший братан был loonie?
Ты меня в тупик поставил, loonie - это канадское название 1-го доллара.Да, там утка нарисована. Сейчас проверил в переводчике и другого значения у loonie нет, только доллар
Но структура это же и есть класс, только не содержащий методов. Я не программист c#, просто немного знаю про структуры.
в c#: класс - ссылочный тип (хранится в куче), а структура нет (хранится в стеке). и структура содержит методы))
В C# структура может содержать методы и даже конструкторы. Павел правильно сказал, вопрос в расположении, а значит в том, как выделяется и освобождается память, как происходит вызов методов со ссылкой
Включу зануду, способ с разницей переменных точно не сработает, так как не факт что последнее число будет повторкой. Но в любом случае спасибо за видео, всегда рад новым видосам от вас.
Не совсем четко объяснил алгоритм, я уже после залива заметил. Одна переменная собирает числа от 1 до 10, а вторая переменная реальные числа в массиве
for int i = 0 to 11 {
if (i > 0)
Sum1 += i;
Sum2 += array[i]
}
profit = Sum2 - Sum1
@@programisli сижу ломаю голову как этот код повторить на PYTHON)))
@@GFU472
На питоне можно так
Sp.sort()
For a in range(len(sp)):
If sp[a]==sp[a-1]:
Print(sp[a])
@@zaser11 этот вариант тоже рабочий! но автор видео его упоминал как самый тупой вариант решения 15 25 мин
@@GFU472 может и тупой, но он рабочий и для начинающего я думаю этот вариант более понятный, а так конечно есть и другие варианты решения этой задачи, более красивые
Спасибо
И снова фильтр мой комментарий удалил
Ненавижу Ютуб за это
Может я какой-то неправильный, но я вообще ни разу не ходил ни на интервью, ни на собеседования. Если надо тест - пожалуйста, тестовый проджект - пожалуйста. А с некоторых времен, если не вижу картину будущего проекта и четкое понимание работодателем картины происходящего, даже и мыслей откликаться нет, все равно время потраченное впустую.
После теста все равно ведь интервью проводят.
19:17 что за красотка!!! В идеальном состоянии!
Про принципы ООП это как мантра по идее, все должны знать, а вот вопросы про виды сортировок и тд бывают лишними.
Вопросы ООП не говорят о том, как потом человек будет писать код. Ну знает человек про наследованное, но но на много важнее, умеет ли он правильно его применять или строит деревья, как было в VCL
@@programisli ну это по крайней мере даёт понять что у человека есть понятие что такое ООП и возможность писать хороший качественный код, я не говорю уже о принципах SOLID. Про ООП обычно у джунов спрашивают. Если перед вами сидит Синьор то сразу можно начинать с GoF паттернов.
Добрый день , такой вопрос: система обозначений О() при моделировании расхода памяти встречаться в вопросах ? Если не корректный вопрос ,извините!
Бывают, спрашивают про O, обычно не заморачиваются и просто смотрят - эффективное решение или нет
@@programisliСпасибо ,тема нууу очень интересная!
Интересно, спасибо
А теперь представим, как проводились бы практические интервью у юриста или повара. Нужно смоделировать ситуацию в суде, а собеседующего считать судьёй или сварить борщ в реальном времени.
На счет повора не вижу проблем, приготовить что-то прямо на месте. Вот юриста практическое интервью это наверно невозможно
@@programisli да и у повара тоже нереально. У всех людей же разные вкусы. Кто - то вообще борщ не любит. Как это будут оценивать? Может собеседующий - вегетарианец.
Перед задачкой на 13 минуте специально поставил на паузу и 2 минуты сам решил подумать.
Очень приятно удивился, когда наши решения с разностью сумм совпали))
Я Python Junior+
А можешь, пожалуйста, детальнее обьяснить?
Я не могу понять как это работает
@@VolodymyrTymkiv
num_list = [1, 2, 3, 4, 5, 6, 6, 7, 8, 9, 10]
sum_of_10 = sum(range(1, 11))
total_sum = sum(num_list)
print(total_sum - sum_of_10)
>>> 6
@@FRA1T так как числа от 1 до n, то вместо первой суммы можно посчитать сумму арифметической прогрессии по формуле: n(n+1)//2
@@Vadimzor да)
@@Vadimzor возможно вы имели ввиду n(n-1)/2 ?
что за привичка с животными разговаривать. Кто с уткой, собакой, кошкой .. Еще с цветками не хватало
То ли дело с чайниками разговаривать, когда он свестит кричать на весь дом - иду, иду!
Ну на комп матерится это совсем другое
@@programisli XD
Сейчас специально глянул солюшн сервера, над которым иногда ведется работа - ни одной структуры на 100 проектов.
Зато на интервью скорей всего спрашивают - а что это такое?
@@programisli Не знаю, я ни одного интервью на шарписта не проходил. Но при этом семь лет разрабатывал и на плюсах и на C#, сейчас разрабатываю фронт на ангуляре, а готовлюсь к собесам на джависта(тоже есть опыт, но просто так без теории не возьмут). По структурам помню только то, что назначенная двум переменным одинаковая структура копируется при присваивании и может изменяться без влияния на другую переменную. Над особенностями хранения в памяти даже не задумывался. Мне кажется, если бы предложили пройти собеседование на текущее место работы, я бы его не прошел.
@@programisli кстати, насчет managed и работой с памятью, на практике всего лишь раз понадобилось основательно читать про сборку мусора, профилирование и т.д. У меня была библиотека, написанная на плюсах, которая встраивалась в дотнетовский сервис через C++/CLI. В итоге оказалось, что всё мое чтение не имело смысла, т.к. в плюсах на обьекте не вызывался деструктор, а дотнетовская часть протаскивалась в плюсовый обьект в виде делегата и жила там бесконечно.
12:00 Если вы ждёте от программиста дополнительных по задаче - то это очень плохо. В реальной работе ты никогда не спрашиваешь ничего. Тебе дали задачу, что надо тебе сказали. Что не надо - не сказали. То есть проверка идёт не на реальное программирование, а не то, что человек умеет задавать вопросы на собеседовании.
Как раз в реальной работе ты задаешь вопросы и ищешь более оптимальное решение, а не тупо делаешь ересь, которую пишут, зачастую, аналитики, которые ничего не понимают в техническом устройстве проекта.
@@techbuterbrod 1. Я лично сам согласовывал ТЗ. А когда не согласовывал, посылали ТЗ назад, если я с ним что-то не так. Не надо мне рассказывать, как это делается.
2. Вопросы, которые приводит автор, да и вообще вопросы, ты не задаёшь. Ты делаешь свою работу, а не фигнёй страдаешь по типу "а не мало ли у меня оперативки?" и т.д. Когда будет мало оперативки, начальник тебе скажет или ты сам это поймёшь.
Твоя задача - запрограммировать, а не вопросы задавать. А у автора видео получается, что он наберёт человека, который вопросы задаёт, а не который задачу решит.
@@vinfdsc ТЗ? 😂 Да ты походу в какой-то госконторке сидишь, где про agile не слышали.
@@techbuterbrod А-ха-ха. Вам аналитики, о которых вы сами упомянули, что пишут? Вы сами-то про agile что, только слышали? Про судебные моменты потом о спорах, что кому принадлежит, включая выбивание дверей спецназом, тоже никогда не читали?
ТЗ - это юридический документ. Причём даже если мы пишем программы только для себя, он будет.
Что касается agile, ни в одном нормальном agile-процессе нет никаких аналитиков. Ибо мы сами себе аналитики, именно поэтому это и agile. Это вы работаете в какой-то чумной конторке, где вместо программирования бумажки аналитик пишет.
-------
И, ещё раз, мы сейчас говорим не о процессах разработки, а о вполне конкретном примере: вопрос, хватает ли у меня памяти. Если у меня не хватает памяти, мне начальник об этом скажет. Если не сказал, то:
1. Либо с памятью всё норм.
2. Либо памяти не хватает, но начальник сам об этом не знает.
Начальник - профессионал. Если что важно, он об это мне скажет. Если же я сам начальник, то уж точно не у аналитика я буду спрашивать, сколько у меня свободной памяти. Аналитики - придурки, которые мешают работе.
Вот и возникает вопрос, а у кого я тогда на работе должен спрашивать такие вопросы?
Ответ на него однозначный: вопрос про нехватку памяти никогда не стоит. Он либо сразу ставится руководителем и решается, либо изучается программистом непосредственно.
Послушал историю с задачей на массив от 1 до 10 и сразу захотелось стать программистом!
Что делать?
Становится программистом
@@programisli что-то не припомню, чтобы мне вообще приходилось работать с массивами чисел. Мапы, джейсонины, листы строк - да. Массивы чисел - нет. (джавист)
Михаил, привет! 🤝 Какие вопросы чаще всего задают junior разработчикам? В какие темы стоит углубиться?
Если честно, то вопросы одинаковые задают и тем и другим в Канаде, просто результат потом найма будет зависит от того, как кандидат отвечает на вопросы.
В России у меня спрашивали когда на Джуна шёл, ооп рассказать все, стек и куча разница reference type и value type, string и stringbuilder в чем отличие, конструкция using, как работает garbage collector, разница между class и struct, что такое интерфейс, разница между наследованием класса и интерфейса, что такое метаданные, clr, il, разница между task и thread, return и yield return, и вопросы по sql. Это для .Net Junior, проходил примерно в феврале. Мб что-то упустил.
Про структуры. Все используют стандартные структуры типа DateTime или TimeSpan. А они ведут себя по-другому, чем классы. Поэтому важно знать отличия классов от структур. Я обычно задаю такие вопросы на интервью.
В принципе Int32 тоже структура и стандартные типы много используют и с точки зрения менеджмента памяти я как раз люблю спрашивать про эти типы
Видимо, не все вопросы в этой теме одинаково полезны для стандартного разработчика. Boxing / unboxing скорее всего нужно хорошо знать, а почему у структуры нельзя определить конструктор по-умолчанию вряд ли. Хотя и то, и это про память.
Боксинг - это как раз самый важный вопрос, который должын понимать со значимыми типами, потому что из-а этого могут быть баги.
Решение через битовую маску не подойдет потому что числа 1 до 10 не флаги, и биты совпадают... Но если число возвести в куб то сработает:
static void Main(string[] args)
{
var arr = new []{ 1,2,3,4,5,6,7,7,8,9,10 };
var mask = 0;
foreach (var item in arr)
{
var num = item * item * item;
if ((num & mask) == num)
{
Console.WriteLine($"Number is {item}");
break;
}
mask |= num;
}
if (Console.GetCursorPosition().Top == 0)
{
Console.WriteLine($"No repetitions");
}
Console.ReadLine();
}
Именно биты. Читаешь число из массива, если число 5, то проверяешь пятый бит. Свободен? Зажигаешь его. Не свободен? Ты нашёл профит. То есть тебе нужно 10 бит для хранения 10 чисел. Ты сжимаешь массив из чисел в массив из бита
@@programisli Да не плохое решение оно не сильно отличается от того что я привел выше т.к. там придется 2 возводить в степень N, что бы установить нужный бит )
Очень интересно было послушать, но возникает вопрос, как прокачаться в этом "понимании", если ты не работаешь даже джуном? Сам на стадии обучения, поэтому и интересуюсь :)
Ходить по собеседованиям
@@programisli А разве давать фидбек по поводу ответов собеседуемого это такая частая практика? Сколько читал/слышал, многим не объясняют, где человек ошибается в своих рассуждениях/ответах. Понимаю, что многое зависит от самой компании и людей, которые в ней работают
проходить собеседования это отдельный навык и качается он именно походами на эти собеседования)
@@user-zk2gg6nw4t это понятно, но я изначально говорил о "понимании", в контексте того, что какой-то код/решение плохой, а какой-то хороший и если ты не работаешь над реальным проектом, то этого опыта просто не набрать
@@maximo7561 да пофигу хороший он или плохой(конечно хороший лучше), на сугубо потребительский пролетариарско бизнесовый взгляд имеет значение работает код или нет(решает ли задачу, для которой он нужен), это первостипено на моё усмотрение, а потом можно гнаться за всем остальным, если тебе не дадут новую задачу.
Я думал структуры данных это словарь, например
Не понял, почему такой комментарий под этим видео, я же структуры данных не упоминал, может где-то что-то оговорился?
А, я понял о каких структурах. Есть "структуры данных" а я говорил о структурах как о типе данных. Есть такой тип данных "структуры" в C#. Я здесь рассказывал про них www.flenov.info/story/show/Znachimye-tipy-v-C-na-primere-struktur
вот по архитектуре приложений, какие источники можно посоветовать? помимо паттернов проектирования
Я в основном видео смотрю и читал несколько книг от MS, например вот это docs.microsoft.com/en-us/dotnet/architecture/microservices/
@@programisli спасибо
интересная задумка кодревью, интересно у нас в России так практикуется? Попадалось кому-нибудь?
Я не знаю, как в России, но судя по тому, что мне часто говорят в комментариях, что там спрашивают, что такое инкапсуляция, наследование и полеморфизм, то не удивлюсь, если им необходимо именно решение алгоритма
Меня так на предыдущем месте работы нанимали, потом я так же собеседовал кандидатов. Я тоже считаю, что кодревью - хороший способ оценки кандидатов.
Мне сперва дали тестовое задание, а потом устроили его код ревью с просьбой обосновать мои решения.
@@AndreiVvedenskii У меня тоже было такое. И я там честно признался, что в этом месте надо было сделать вот это, но у меня не получилось, поэтому здесь этот адский костыль прописался.
да ладно вам...
если уж спросили про наследование, скажите что не знаете... выждите паузу... потому что используете агрегацию-ассоциацию и композицию, которые перекрывают всю необходимость в наследовании.
скорее всего дальнейшие вопросы по ооп отпадут.
Тогда будут думать, что я не знаю, но вопрос не знания или не знания, проблема в том, что даже правильный ответ ничего не говорит о кандидате, как о программисте.
14:54, прям мою жизнь описал😂😂😂
Задачу с числами от 1 до 10 и одним повторяющимся можно также решить через two pointers, если я все правильно понял.
Для этого нужен отсортированный массив, если массив отсортирован, можно и двоичным поиском воспользоваться.
Не уверен, что код ревью лучший способ собеседования. Это как в литературе - есть хорошие критики, которые разложат по полочкам любое произведение, но почему-то писателями они стать не могут.
И тут мы тоже можем сделать хороший вывод - а критикует ли кандидат по делу или просто придирается. Были у нас и такие кандидаты.
@@programisli всегда улыбался, когда читал в учебнике - такой-то был выдающимя критиком. А потом случайно наткнулся на ролики с участием Дмитрия Быкова и понял, что и такое бывает. Мне кажется, основная проблема, что для этих уникумов, что написание кода или книги (роли не играет) - это ремесло, которым им в некотором смысле даже стыдно заниматься, потому что зачастую и то и то представляет из себя уже изученное, а им надо только новое, о чем еще никто не знает.
Хорошие размышления! Особенно мне понравился вариант с код ревю. Один только вопрос про способ поиска повторяющегося числа, там где вы говорили про суммирование всего масива и всех чисел кроме последнего. Не уверен что все получится, ну или я что-то не допонял)
Нам нужна сумма массива и сумма чисел i от 1 до 10 , чтобы увидеть разницу
for int i = 0 to 11 {
if (i > 0)
Sum1 += i;
Sum2 += array[i]
}
profit = Sum2 - Sum1
@@programisli Спасибо
@@programisli А спомощью хэша как ? Мой вариант (C#)
int[] arr = { 1, 2, 3, 3, 4, 5, 6, 7, 8, 9, 0 };
var result = arr.GroupBy(i => i).Where(grp => grp.Count() > 1).Select(grp => grp.Key).FirstOrDefault();
@@JohnDoe-tm1rv если это оптимальное по производительности с твоей точки зрения, то садись, два))
@@denisn6408Спасибо. Я уже давно оценки не получаю, я их ставлю :)
Да, это ужасные вопросы для автора библии C#, задавать Вам такие вопросы действительно неприлично.
А чтобы отсеять неподготовленных кандидатов на джуна - норм.
В конце концов, есть списки вопросов, легко гуглятся. Почитай, изучи, подготовься к интервью. Очень печально когда не могут хоть что-то ответить на элементарные вопросы
Ну вот ответит человек на вопрос, что такое полиморфизм, наследование и инкапсуляция, что это скажет о программисте, как о человеке, которому нужно писать код, а не давать хорошие определения? Эти вопросы плохие, потому что они ничего не говорят о программисте.
@@programisli мне не требуется идеальное определение, важно чтобы было понимание, хотя бы объяснение своими словами. Если у кандидата нет понимания базы, то нет смысла переходить на следующие этапы интервью, давать тестовое задание и т.п.
@@programisli Потому что вопрос в каком бы случае вы приминили наследование а в каком делегирование ставит в тупик 99% респондентов :)
А еще в С# есть три вида полиморфизма - больше половины спрашивающих про полиморфизм сами не знают что их бывает много разных :)
Это вопросы для интерна с нулевым опытом.
Да ладно вам энкапсуляция ))) Полиморфизм ))) Я с 3го интервью понял что невозможно обьяснить принципы солид предварительно не подготовившись это как курс на 40 минут времени )) Вопрос что такое солид это 40 минут времени ответ а на словах это невозможно объяснить нужно показывать . А вообще что такое полиморфизм вопрос не корректный полиморфизм бывает двух типов интерфейсами и наследованиями надо уточнять какой . Еслибы меня про инкапсуляцию только спрашивали это вообще халява ))
Да нет, проблема в том, что инкапсуляцию каждый понимает как хочет. На прошлой неделе видел видео в котором автор утверждает, чтобы Википедии написано фуфло и рассказал все по своему. Попадётся такой интервьюер и ты завален только потому, что ты не знаешь его определения, а общепринятые из Вики это фуфло
@@programisli Мдаа за 20 интервью раза 2 спросили про инкапсу как то мне везло . Но всетаки солид принципы по голосовому интервью это топ ну лучше не чего придумать нельзя ) только если не искусственный интелект в вотсапе обсуждать )) Я вообще как делаю всегда на интервью я беру и говорю вы собираетесь меня 30-40 минут интервьюировать давайте я задам вам 3 вопроса по минуте чтобы понимать вообще кто меня интервьюирует и тогда я готов 40 минут своего времени потратить . Только так теперь общаюсь и как только синьйоры начинают валится на 3х вопросах на стронг мидла дальше уже ставлю вопрос как вы собираетесь отвечать и оценивать если вы даже на стронг мидла вопросы не можете ответить .
Про то, что теория не нужна категорически не согласен. Потому что в команде нужно общаться и понимать друг друга. И человеку во фразе "тут нужно отрефакторить: это вместо фабрики класса вынести в депенденс, а это спустить в анцестора и там сделать маппиг" нужно объяснять все слова начиная с первого, то это отнимает слишком много времени.
Хорошая теория нужна, в не инкапсуляция и полиморфизм. Ты часто говоришь на работе отполиморфь эти методы или инкапсулируй этот класс?
Вместо "полиморфизм" я часто говорю "перегрузи этот метод с другими аргументами". Насчет инкапсуляции я конечно напрямую не говорю, но говорю что - то типа "Слишком много хелперов ты наделел, не стоит все методы всех классов делать public static"
Вот мне всегда было интересно, а что если все кто берет программистов по принципу "какие вопросы он задает, как соображает" придут к такому же врачу? Приходишь к такому врачу, а он тебя очень круто опрашивает, очень красивым почерком заполняет карточку, задает множество уточняющих вопросов, а потом .... открывает лаптоп и начинает гуглить :D
А че, алгоритм ведь можно нагуглить :))) И диагноз тоже можно нагуглить :)))) И автомеханик вам может машину починить по туториалам из ютуба :)))))))))))))))))))))))))))
А ты думаешь автомеханики не гуглят и не смотрят схемы? Сколько раз было в официальный сервис дилера форда захожу с фордом и мне на технические вопросы говорят- сейчас в компьютере посмотрю.... Врач, слесарь и программист будет знать и помнить те вещи, с чем он работает каждый день, но если он столкнется с задачей, болезнью, которую никогда не видел до этого, откроет специализированную литературу и будет изучать.
@@programisli Я думаю, что специалист должен обладать профессиональными знаниями необходиыми для своей позиции и знать инструменты с которыми работает. А когда врач отлично задает вопросы, но не уверен сколько у человека позвонков, наверно это не очень хороший врач.
А если в компании основное требование - чтобы человек мог "понять задачу", то у меня серьезные вопросы к такой компании. Например, почему в компании задачи ставят люди, которые не способны формулировать мысли в письменном виде?
Увы, это болезнь отрасли, да, в курсе. Белый человек сказал "хочу", и пусть code-monkeys делают, пока ему не понравится. Ну а чтобы Белый человек себя совсем уж идиотом не посчитал, надо таких monkeys найти, которые с полуслова мысли угадывают и сами еще активность проявляют, додумывают в нужном направлении.
Но сейчас, на сколько я вижу, все это привело к тому, что отрасль верно идет к какой-то реформации. Думаю, что в обозримом будущем будет интересно и будет сложнопреодолимый раздел между основной частью monkeys и инженерами. Как в банках - есть банкиры и есть операционисты в окошке, а вроде и те и другие в банке работают, но разница колоссальная. У сисадминов это уже произошло, когда зарплата серьезных специалистов в десять раз выше зарплат основной массы админов, и вырасти из рядового админа в такого спеца очень сложно - нужно чтобы многое совпало.
у тебя очень наивное представление о врачах))
@@Antonio-mne-jarko У меня жена врач.
@@slippers5477 и? Ты реально думаешь, что врачи сами что-то знают? Хахаха
Правильные теоретические вопросы показывают насколько глубоко человек разобрался в теме. Можно спросить как устроен планировщик в языке, как работает аллокатор, чем стек от кучи отличается и какие плюсы у того и другого. Чем ТСР от UDP и тут целый набор теоретических тем по сетям. Есть много теоретических вопрос понимания которых позволяет писать эффективный и производительный код ну или хотя бы понимать что происходит в написанном.
Есть хорошие вопросы на понимание, но очень часто спрашивают же фигню
Человек мог просто заучить теорию, но не понять. Это вообще не показатель.
web-программисты - хоть фронты, хоть бэки - вообще рехнулись с хэшами. Они их суют везде и всюду, а всё потому, что не задумываются даже о том, насколько это хреновое (и по времени, и по памяти) в большинстве случаев решение.. А потом мы имеем сраную страничку, жрущую сотни мегабайт или даже гигабайты памяти.
Решение через хэши озвученной задачи с поиском повторяющегося числа в массиве, содержащем очевидную прогрессию - свидетельство того, что базовая арифметика из этой головы давно выветрилась, если вообще там была. Условная хорошесть этого решения исчерпывается тем, что оно таки работает. Все остальные характеристики этого решения - по времени, по памяти - отрицательные.
Где-то на Хабре сегодня видел то ли пост, то ли комментарий на эту же тему😂
Тут же вопрос сравнения, это лучше тупого перебора, но является ли это идеальным решением - нет. Если мы будем смотреть только на идеальные решения, то возникнет серьезная проблема, программистов просто не найдем на рынке
@@dimka59ru То был не я, про хабр я уже и забыл почти :)
@@programisli Тут просто необходимо обозначить вопрос “Чем конкретно лучше?” Даже тупой перебор по памяти будет однозначно лучше, а по времени - как повезёт, оно же O(n²).
Конечно же я не ратую за идеальные решения, тем более, что нередко кажущиеся идеальными в общем случае, оказываются неработоспособными в частном, взять хотя бы этот же пример с массивом: конкретный массив содержит числа в диапазоне INT_MAX-10 .. INT_MAX - и вот кажущееся идеальным решение нуждается в доработке напильником. И тут выходит чувак с повсеместным хэшем на знамени и яростно им размахивает под собственные крики “А я говорил!” :)
В первом грубом приближении решения будем считать хорошими или плохими. Тогда решения перебором и через хэш - плохие.
Впрочем, я ж вообще о другом подумал :) Михаил, меня по сути триггернуло то, что ты сказал “Это норм для сеньора”. Кажется, мои представления о сеньоре отличаются от твоих . Просто я не склонен считать/называть программистом того, кто выучил язык программирования, даже если у него и должность называется “программист”. Ему до программиста (в моей табели о рангах) ещё дорасти надо. При этом я довольно много работал с офигенными программистами, которые вообще не знали языков программирования. Никаких. Вот :)
@@alexandernaumochkin иногда бывает так, что человек может быть посредственным математиком, но хорошим программистом, и наоборот. Я за коллегой, (он физик), постоянно переписывал его код.
А фразы "дорасти, табель о рангах" - оставьте этот снобизм молодежи. Задача программиста - писать код. Никакой магии, никакого волшебства в этом нет. Не важно что: перекладывание json'ов или разработка научного ПО.
Полиморфизм не знает! Хахаххаа. Зато в ролик рекламы вставил мама негорюй
Рекламу вставляет гугл, а про полиморфизм я не говорил, что не знаю. Я сказал, что считаю это плохим повросом. Полиморфизм, инкапсуляция - это ужасные вопросы для интервью