Какая нужна теоретическая база на собеседовании джуна?
Какую вакансию на джуна не открой(за очень редким исключением), везде в требованиях найдешь пункт "понимание ооп/солид/грасп/ягни/и т.д.и т.п.". На фоне этого у меня возникает вопрос, а в каком виде происходит проверка вот таких теоретических познаний джуна? Нет, я понимаю, что на это можно ответить "ну ты приходишь и тебя спрашивают", но я просто не могу понять: почти все джуны (включая меня, конечно же), у которых нет крутого технического (а еще лучше - практического) бекграунда, описывая, например, принципы SOLID или ООП, просто озвучат заученный текст и в лучшем случае смогут подкрепить его пет-проектом в котором будет разделение на классы (и даже больше чем на 2) и, скорее всего, минимальное разделение логики между классами (чем больше методов в одном классе, тем лучше и красивее). Что именно работодатель хочет увидеть на интервью у джуна в этом плане? Просто с кем бы я не общался из новичков (даже с теми, кто уже ищет работу и даже ее находит), большинство говорят, что знают все эти принципы и правила, но даже мне видно, что это далеко не так, потому что в их работах они не используются от слова совсем.
Сейчас у меня просто небольшое перепутье, я 9 месяцев изучаю php (особенно сосредоточившись на чистом, осознанно строя кучу велосипедов, чтобы потом было проще разбираться с фреймворками и легаси) по принципу "пишу проект и походу дела изучаю новые технологии, чтобы их туда привинтить", и сейчас я действительно ощущаю в себе силы в техническом плане, чтобы пойти попробоваться на джуна, но понимаю, что мое понимание ООП с его принципами и т.д. мягко скажем, не самое лучшее, из-за этого я стараюсь погрузиться в теорию и не могу закончить даже один пет-проект, потому что я несколько раз переписывал его архитектуру, постепенно улучшая ее. А всё потому, что мне кажется, что когда я попаду в реальный проект, я буду только мешать своим говностроением, постоянно его переписывая по требованию старших, если не вникну в это самостоятельно.
P.S.Понимаю, вопрос получился несколько размытым, проще говоря: я хочу узнать, как именно проверяются и какие на самом деле должны быть знания в этой области у джуна?
P.P.S. Да, знаю, что очень часто описание вакансии делается HR, которому толком не объяснили, какого именно разработчика ищет компания, и он просто по кусочкам собирает среднюю температуру вакансий по hh, вот и пихает туда под копирку.
Одиночка Айс, в случае с РНР это нормально.
Если хочется понимать в архитектуру, то с этим очень помогает офис и работа над сложными проектами, которые в одно лицо не потянешь.
Роман Юрьевич Ипатьев, в офисе и так сижу, а сложные... что считается сложными проектами? Хайлоады не делал, так, магазины, да формирование всяких подписей/файлов и прочие интеграции, но в теории я 0, по факту.
Реальное понимание ООП и паттернов - это не уровень джуна.
И да - как вы верно заметили - те кто говорят, на самом деле просто заучили пару расхожих заклинаний.
Как метко сказано в последней книжке Пелевина,
Маня была счастлива. Вот что значит быть дочкой банкира - папа не объяснял, папа инструктировал, как объяснять другим".
Вот людей, которые могут объяснить, но сами не понимают, в последнее время как-то очень много появилось.
В реальности от джуна требуется чисто механическая часть ООП:
- уметь использовать готовые классы, уверенно обращаться к свойствам и методам
- знать что делают основные магические методы
- понимать неймспейсы и автолоад
- в целом уверенно читать исходный код классов - то есть не пугаться слов implements и use (которое трейты а не неймспейсы)
- уметь использовать контрол-клик в Шторме
И да - как вы верно заметили - те кто говорят, на самом деле просто заучили пару расхожих заклинаний.
То есть получается, интервью - обоюдное лукавство: собеседующие лукавят, говоря, что от вас требуется понимание ООП и т.д., а вы, говоря, что всё это понимаете?
Спасибо за ответ:)
gigisarri98, погодите, а при чем здесь собеседующие?
Вас уже кто-то собеседовал?
Если вы судите по тексту вакансии, то вы же сами пишете, что он составляется "от балды".
Если на собеседовании от вас действительно потребуют понимания принципов, то это будет да - лукавство.
Но как я выше писал, от джуна оно не требуется, и на собеседовании не должен подниматься этот вопрос, разве только факультативно.
Роман Юрьевич Ипатьев, как по мне, пусть лучше джун из магических методов знает только конструктор/деструктор, про автолоад, что composer все сам делает, если соблюсти PSR (хотя может и имелось ввиду), а implements и use вообще не использует. Но знает SOLID, GRASP теоретически, и хотя бы нарушение Single Responsibility может определить по коду. Т.к. большинство магических методов нужны для специфических задач, и чем их меньше, тем лучше. Интерфейсы невозможно нормально применять не зная того же SOLID, а треды вообще не нужны. А про "контрол-клик" отличное замечание.
1) Не бояться получить отказ. Каждый отказ это опыт.
2) В большинстве случаев они сами не знают и не соблюдают того что написали в вакансии.
3) Самое главное зайти в это дело. Не важно в какую дыру ты попадешь на первую работу. Как только тебе начнут присылать задачи в которых ты плаваешь скилы полетят вверх тк придется с этим разбираться.
4) Популярные аббревиатуры просто заучить, никто не будет требовать написать диссертацию про их использование. Потому что читай пункт 2.
Ну в общем алгоритм действия такой:
1. Находишь компанию, которая ищет джунов.
2. Приходишь туда на собес.
3. Возможно выполняешь тестовое задание.
4. При неудаче повторить начиная с первого пункта.
9 месяцев самообучения и какие-то пет проекты достаточная база, чтобы начинать ходить по собеседованиям.
Основная проблема в ответах на вопросы типа твоего: у разных кампаний разные требования к уровню джуна в софт/хард скилах. Поэтому только через собесы ты сможешь познать уровень своей подготовки и подтянуть западающие области.
Дружище, на практике дела у некоторых программистов обстоять еще хуже.
Я лично знаю людей, которые разрабатывают серьезные проекты на крутых фреймворках, делают сложные приложения. Но если спросить про идиомы ооп, максимум две расскажет. А про solid вообще впервые слышит ....
А работают уже больше 6-7 лет программистами, претендуют на хорошую ЗП.
Так вот к чему я это все?
Знать нужно все, по максимуму.
А вообще в средних компаниях обычно делят джун/мидл/сеньер по уровню ответственность за какую-то часть работы.
Да, нужно именно теоретическое понимание. Чтобы когда на ревью джуну скажут, что он нарушил Single Responsibility, он не просил объяснений о чем вообще идет речь и тем более на стал доказывать, что его решение лучше. Нормально, если джун несколько "плавает" в понимании этих принципов (четкое понимание придет с опытом), ненормально, если считает, что с него требуют что-то лишнее.
когда я попаду в реальный проект, я буду только мешать своим говностроением, постоянно его переписывая по требованию старших,
Не совсем так. Джуна не допустят к говностроению.
Для начала будут простые задачки - поправить баги, добавить/убрать параметр из апи, поменять цвет какого-нибудь элемента, заменить одну картинку другой и т.д.
К архитектуре допустят когда вырастешь до миддла
просить больше это в нашем менталитете попытка пробить на шару)
какой потрясающий будет джун, который всё это знает, уровня по сути миддла, и платишь ему при этом как джуну.
И эта фича с лихвой нивелируется как раз тем, что каждый вчерашний "выучу С++ за 21 день" дальше четырех принципов ООП в понимании (не опыте, а лишь понимании) не двинулся, а говорить - горазд.
Приходит к тебе джун и говорит
"у меня вот задача, сделать такой простенький сервис который будет делать вот это и вот это, а я не очень понимаю как начать"
И ты ему начинаешь полтора часа пояснять что к чему.
Или второй вариант - приходит к тебе джун с таким же вопросом,
А ты ему отвечаешь
"Тут юзай синглтон, тут фабричный метод, тут подойдешь потом посмотрим что выйдет, тут пока сделай декоратор с заглушкой."
И можно идти начинать работать.
Конкретная реализация различных паттернов - это огромный опыт.
Но в первую очередь это просто обычная терминология.
Да, конечно паттерн как термин и понятие отличается от термина типа "интерпретатор и компилятор" тем, что сложно его объяснить в двух словах - надо потратить время на изучение, а желательно еще и попытаться написать парочку объектов для набивки руки.
Но собственно это от джуниора и требуется - владеть терминологией на достаточном уровне, чтобы экономить много времени.
Простой
Простой
Простой
