Усі статті, обговорення, новини для початківців — в одному місці. Підписуйтеся на телеграм-канал!
Что junior должен знать по Java, помимо core. Нужно ли знание каких то фреймворков? Если да, то какие? Что должен знать из web-разработки?
Спасибо!
любой будущий программист должен уметь нагуглить FAQ вопросы. Я уже приводил на этом форуме раза 4, это серьезно последний раз:
Java core сильно громко сказано, я уверен что вы его не знаете.
1) типы в Java, inboxing, outboxing, как примитивы друг в друга преобразуются.
2) Коллекции, иерархия интерфейсов и реализаций, чем ArrayList «лучше» LinkedList. Обязательный вопрос по HashMap-ам, что такое хеш-функция, внутреннее устройство.
2.5) Строки очень часто спрашивают, циклы, управляющие структуры, что появилось в JDK 7 по сравнению с
3) Интерфейс, Абстрактный класс, 3 принципа ООП, несколько шаблонов проектирования.
4) Servlet, JSP, JSTL, Tomcat или другой Servlet container, никуда не девается жизненный цикл и как это все работает.
5) Advanced топики для джуна: системы контроля версий Git, Svn, системы сборок Maven, Gradle, Spring, Hibernate, Web-Service-ы (обычно REST), не зверствуют, но жирный плюс.
6) Иногда чтобы завалить спрашивают про устройство памяти, что такое стек или куча, куда создаются объекты, зачем нужен garbage collection, параметры запуска JVM так что почитайте JVMS docs.oracle.com/.../jvms/se7/html, Почему завалить? Потому что этого как ни странно не знают многие middle/senior не говоря о джунах.
7) базовый SQL, подзапросы, что такое сущность->связь, спроектировать 2 таблички и выполнить по ним запросы. noSQL также могут спросить.
8) из веб разработки иногда попросят базовый JS и CSS. HTML и так все должны знать. Хорошо если знаете основные типы HTTP запросов, в чем их предназначение и отличие.
9) JDBC, куда ж без него, раз в
10) Многопоточность обязательно спросят, как работает wait, notify, notify all, почему нельзя использовать sleep, как создать dead-lock, вокруг чего бывает синхронизация. Эта тема очень важна, т.к. спрашивают на каждом собеседовании, но чаще всего на проекте либо нормальная реализация из пакета concurrent, либо вообще не сталкиваетесь.
11) Что такое static-методы и переменные. Простейший пример из фильма
12) Потоки ввода вывода, базовые вещи, прочитать строку из консоли, какие бывают фильтры.
13) Английский крайне важен для аутсорса.
P.S. желательно что-то слышать про TDD, JUnit. Джуны как правило моки не знают, но быстро учат.
5 месяцев назад джуном я не смог устроится... Оказалось что проще устроится мидлом.
читаю комменты, все супер синьоры, а как читаешь чужой синьорный код — так не понимаешь, где же все эти синьоры ))
За рубежом есть такая практика: больше обращать внимание на следующие моменты — обучаемость, способность решать конфликты, и другие софтскилные моменты. Никто вас не будет дрочить до самой глубины, т.к. все понимают что документация и гугл в помощь. Очень интересно услышать мнение тех лидов.
я видел синьйорный код — ты его с первого раза не прочитаешь.
согласен. Но плохочитаемый код — это очень плохо. Можно выебнуться и наворотить сорок миллионов уровней абстракции.
A vy, pane, bachyly Ukrainskyh senioriv? Ce zh hlopchyky
Видел, в основном им под 40. И эти люди иногда не знают некторых вещей, которые спрашивают на собеседованиях даже на мидла, но зато эти люди очень качественно подходят в разработке и их проекты работают и живут. Реалии таковы, как я уже ранее написал, что очень важна обучаемость и этот процесс у девелоперов перманентый. Читаю про реалии разработкив разных «топ компаниях Украины, а также Европы», так все сводится к саппорту старого кривого кода и никто особо не парится , но если проходить собеседование в эти компании, то на интервью тебя выдрочать по всему стеку и по всей его глубине.
Коментар порушує правила спільноти і видалений модераторами.
Нужно очень много знать, на самом деле, вот не полный список 327 вопроса на собеседование Java Developer
В вообще в этом курсе будет покрыта большая часть тем. Включая задачки на логику, знание алгоритмов Все о Java и JavaEE на русском от украинских разработчиков (email-курс на 21 дней)
Крою козирним Головачем!
www.youtube.com/user/KharkovITCourses
Это несомненно козырь) Но Иван ушел в Scala на сколько мне известно и подготовкой java junior теперь не занимается. Так что место вакантно)
Ну відоси будуть ще довго актуальними
// якщо маєшь відношення до курсу, то краще буде прибрати
(email-курс на 21 дней)— звучить якось брудно маркетингово
В точку, чисто маркетинговый ход. Насчет чистоты можно долго спорить.
Принято, уважаю Ивана. Многим рекомендую его видео.
5 месяцев назад джуном я не смог устроится... Оказалось что проще устроится мидлом.
Собеседования это просто продажи, а все продажники врут :) Я лично считаю, что из Delphi senior (к примеру) получиться senior Java ± за год. А вот из джуна-нет, потому человек с опытом коммерческой разработки предпочтительнее человеку без опыта.
Cia fraza “komercijna rozrobka” jakas’ debilna.
Вот именно!!!! Если человек нужен на работу — его берут на работу, если нет — проводят собеседования!!! Крассава
Same tak. Jaksho druzhbany klychut’ - to berut’ navit’ kasyriv z ATB
советую этот ресурс, на котором разбирается много вопросов и ответов по собеседованиям Джава и веб разработчиков
www.journaldev.com
любой будущий программист должен уметь нагуглить FAQ вопросы. Я уже приводил на этом форуме раза 4, это серьезно последний раз:
Java core сильно громко сказано, я уверен что вы его не знаете.
1) типы в Java, inboxing, outboxing, как примитивы друг в друга преобразуются.
2) Коллекции, иерархия интерфейсов и реализаций, чем ArrayList «лучше» LinkedList. Обязательный вопрос по HashMap-ам, что такое хеш-функция, внутреннее устройство.
2.5) Строки очень часто спрашивают, циклы, управляющие структуры, что появилось в JDK 7 по сравнению с
3) Интерфейс, Абстрактный класс, 3 принципа ООП, несколько шаблонов проектирования.
4) Servlet, JSP, JSTL, Tomcat или другой Servlet container, никуда не девается жизненный цикл и как это все работает.
5) Advanced топики для джуна: системы контроля версий Git, Svn, системы сборок Maven, Gradle, Spring, Hibernate, Web-Service-ы (обычно REST), не зверствуют, но жирный плюс.
6) Иногда чтобы завалить спрашивают про устройство памяти, что такое стек или куча, куда создаются объекты, зачем нужен garbage collection, параметры запуска JVM так что почитайте JVMS docs.oracle.com/.../jvms/se7/html, Почему завалить? Потому что этого как ни странно не знают многие middle/senior не говоря о джунах.
7) базовый SQL, подзапросы, что такое сущность->связь, спроектировать 2 таблички и выполнить по ним запросы. noSQL также могут спросить.
8) из веб разработки иногда попросят базовый JS и CSS. HTML и так все должны знать. Хорошо если знаете основные типы HTTP запросов, в чем их предназначение и отличие.
9) JDBC, куда ж без него, раз в
10) Многопоточность обязательно спросят, как работает wait, notify, notify all, почему нельзя использовать sleep, как создать dead-lock, вокруг чего бывает синхронизация. Эта тема очень важна, т.к. спрашивают на каждом собеседовании, но чаще всего на проекте либо нормальная реализация из пакета concurrent, либо вообще не сталкиваетесь.
11) Что такое static-методы и переменные. Простейший пример из фильма
12) Потоки ввода вывода, базовые вещи, прочитать строку из консоли, какие бывают фильтры.
13) Английский крайне важен для аутсорса.
P.S. желательно что-то слышать про TDD, JUnit. Джуны как правило моки не знают, но быстро учат.
Мне интересно, что же вы при этом будет спрашивать у Senior.
Всё то же самое, + Spring, Hibernate и так далее.
Как по мне, то приведенные 13 пунктов с таким же успехом подойдут чтоб проверить мидла. Разве что не будут спрашивать про ООП.
Почему не будут спрашивать про ООП? А вдруг не знает. Spring и Hibernate там уже есть.
p.s. Мне что то подсказывает, что спрашивать джунов конечно все это можно, но искать работника будете очень долго :)))))))))))))
Джуна ООП спрашивать скорее всего будут. А вот мидла или сеньора о таком спрашивать — проявлять неуважение))
Процентов 80 спрашивают. «Не наши» тоже это спрашивают. У любых позиций. И еще про класс и интерфейс все всегда спрашивают.
Я был бы только рад, если бы у меня на собеседованиях спрашивали ООП.
Нет, ну это не единственный вопрос,конечно же. Но ведь спрашивают?! Главное всегда когда спросят я непроизвольно делаю круглые глаза и впадаю в ступор на пол минуты с мыслью " они бы еще аксиомы стереометрии спросили«. Потом все таки вспоминаю и идем дальше.
Еще меня «очень радует» вопрос на сколько баллов из Х вызнаете свой язык? Я его вообще не знаю, я просто на нем пишу лет 10. И еще на 5ти языках ±. И часто как в анекдоте «Прочитал две книжки: Му-му и Анна Каренина. Но не помню в какой из них Му-му под поезд бросилась».
p.s. Лично я предпочитаю задание на написание программы или алгоритмические, чем эти вечные размусоливания на тему типов джоинов и где хранится стек приложения.
p.p.s. Прошу прощения, наболело за время жизни в индустрии.
Та всё норм)
Все-таки, со временем у нас будет более толковый найм и тем меньше будет вопросов «в молоко».
Я думаю толкового найма не будет по макроэкономическим причинам: высокий спрос, низкое предложение -> снижение стандартов.
Видите в титуле слово «senior»?
В таком случае вопрос некорректен, в EPAM нет грейда "
каста наивысшего стандарта сотрудников", да и в других компаниях насколько я знаю тоже. Вы пытаетесь как-то пошутить?
Так про касту шутка была? Есть level-ы D1-D5, M1-M5.
Это лет где-то 7 назад было: «ты — Хеллоу Ворлд на собеседовании, а тебе — 1К долларов» как я где-то читал о том времени.Вас обманули, меня например в 2007 при гораздо больших знаниях не брали и на вдвое меньшую сумму, пока все нормально не выучил.
Для такой простенькой модели не обязательно быть кем-то высочайшего класса.
Сегодня хотят купить 900 яблок, продают 200,
Завтра хотят купить 1100 яблок, продают 250,
Послезавтра хотят купить 1300 яблок, продают 300.
.......
Это я к чему, рано или поздно ушлые продавцы в такой модели будут подсовывать прелые или зеленые яблоки в уже расфасованные пакеты с обычными. Цена естественно будет расти, но и среднее качество яблок будет падать.
Сравнивая вопросы на собеседованиях шесть лет назад и год назад, определенно вижу, что планка требований выросла. Раньше все хлопали в ладоши, когда ты рассказывал про ООП, а сейчас даже средне-глубоких познаний в Spring и Hibernate не всегда достаточно, чтоб вызвать одобрительный кивок интервьюера.
Шесть лет назад можно было зная «по верхам» попасть даже куда-нибудь в Люксофт. В Сиклум было проще попасть — не то что сейчас — три раунда собеседований (или сколько там). Короче, сегодня требования к девелоперам всех мастей выросли.
Это было несколько раньше, да и не во всех компаниях
кое-где грейды есть, но они никак не влияют на перечень исполняемых обязанностей. только на вилку зарплаты :-)
хотя в некоторых компаниях синьоров чаще нагружают задачами относящимися больше к бизнес-аналитикам (особенно при отсутствии аналитика). например интерпретация бизнес требований в документы технического дизайна , по которым другие девелоперы уже будут кодить
Напомнило анекдот про шарпея: дырочку видишь? Это попа! :-)
Вопрос не в стандартах, а в том что то о чем спрашивают не совсем имеет отношение к тому, как человек будет программировать. 80% вопросов — одни запрос к гуглу, а оставшиеся 20% — тараканы в голове собеседующего
просто вопросы должны составляться по другому
джуна можно спрашивать очевидные вещи (например для чего нужно наследование)
а мидла и сениора — окольными путями — например — наследование это хорошо или плохо ? почему плохо и почему хорошо? те ответ должен предполагать развернутую дискуссию о слабых и сильных связях в дизайне классов
я считаю чем выше уровень разработчика, тем более «абстрактными» должны быть вопросы на собеседовании — не из серии знаю/не знаю, да/нет, а предполагающие расширенное толкование. достаточно хороши вопросы на problem solving — например дается какая-то вводная (утечка памяти, рейс кондишн) и какими средствами его можно локализовать или избежать
но искать работника будете очень долго :)))))))))))))если задача — не просто определить абстрактный уровень в виде суммы баллов, то каждый ответ в отдельности по шкале «не знает совершенно/что-то слышал/примерно в курсе/норм ориентируется» примеряется к ожиданиям по проекту: «ну, да, JDBC явно не используем — только ORM, так что пофиг; а вот что на вопрос про интерфейсы начал про UI лопотать — жирный минус, у нас довольно сложная система классов, напортачит сразу ж»
Вопрос на самом деле стоит больше в плоскости менеджмента в вопросах найма людей. Если человек нужен на вчера,то критерии и процесс будут совершенно другими чем в случае «нам возможно потребуется еще один разработчик которого у нас нет через два месяца». Правда джунов это меньше касается, их много. А вот с уровнями по выше — степень маразма на собеседовании обратно пропорционален «срочности» поиска сотрудника. Плавали,знаем.
Все вышеизложенное впрочем не касается реальных гигантов рынка типа Oracle/Google/Ms, там процесс более плановый и стандартизированный.
Как техническому специалисту не в моих правилах занижать планку, я не принимаю решение о найме, я сообщаю менеджеру и HR-у о том, что знает кандидат, чего не знает, способный или нет и мое общее впечатление в письменном виде. Если нужен «на вчера» и примут некомпетентного, то я не причем, т.к. я свой развернутый feedback уже отдал, а они его не приняли в расчет.
То есть по-вашему Junior’a от Senior’a отличает «+ Spring, + Hibernate»))? Как-то это не справедливо, мне кажется, причём для них обоих)))
уровень понимания идет по шкале «слышал название» к «да я сам это написал!»
если джун плавает в вопросах синхронизации потоков, то это допустимо.
если синьор плавает, а в проекте применяется — лучше уж поискать дольше человека.
Я еще не senior, поэтому собеседовать senior-а мне как-то не с руки. Я бы спрашивал у senior-а 50% глубокое знание по технологиям проекта, а также базовым технологиям типа рефлексии, JNDI, OSGI, устройство JVM, профайлеры, тюнинг производительности, интеграционные шаблоны, TDD, BDD, прочие продвинутые тестовые типа Cactus и Selenium, применимости всего этого и узких местах.
Еще 50% — senior-ные навыки проектирования и видения проекта, а также планирования тасков, приоретизация задач, багов и soft-skills может ли ассистировать/заменить лида, взяв на себя часть нагрузки по джунам, миддлам. Soft-skills важен чтобы не постесняться и уточнить у заказчика что ему реально требуется, чем городить полгода одноколесный велосипед и выбросить.
Также интересный вопрос по выводу на чистую воду: в сложной ситуации пишет ли кандидат по flow принятому на проекте, делает coverage или если сроки горят — костылит? Так вот если костылит, то он всегда будет так поступать и нужно определить для себя нужно ли такого брать.
Еще важно если senior гений, но ведет себя отвратительно, заносчиво или высокомерно, твердолоб в своих решениях «переписать с нуля любой ценой» или «строить по старинки из кирпича не по-ламерски», то я бы его не взял. Потому что любой продукт делается командой, а брать бомбу замедленного действия смысла нет.
простите за борзость, а у вас нет методички или что то типа того по изложенным выше вопросам? заранее благодарен...
К сожалению, методички нет, сам осваиваю по крупицам, чтобы ответить на эти вопросы когда придет время.
JNDI, OSGI,Не так уж и много людей с OSGI работали. Да и с JNDI кроме базовых лукапов тоже мало кто имел дело кроме тех кто в начале 2000х начинали. Так что это бессмысленно. Тем более у вас в Ипаме принимают в компанию, а не на проект и уровень нужно оценить общий, а не подходит/не подходит на проект.
интеграционные шаблоныОпять таки, их 65, и кандидат даже имевший дело с Spring Integration или Apache Camel может и не помнить чего-то.
Короче видно что вы особо не собеседовали. Но вот с этим я на 300% согласен
Еще 50% — senior-ные навыки проектирования и видения проекта, а также планирования тасков, приоретизация задач, багов и soft-skills может ли ассистировать/заменить лида, взяв на себя часть нагрузки по джунам, миддлам. Soft-skills важен чтобы не постесняться и уточнить у заказчика что ему реально требуется, чем городить полгода одноколесный велосипед и выбросить.
Также интересный вопрос по выводу на чистую воду: в сложной ситуации пишет ли кандидат по flow принятому на проекте, делает coverage или если сроки горят — костылит? Так вот если костылит, то он всегда будет так поступать и нужно определить для себя нужно ли такого брать.
Ну я еще «в пути» к совершенству и senior-ов пока не собеседовал. Считаю что по крайней мере OSGI надо знать, а в интеграционных шаблонах не обязательно все 65, но любой может привести к интересному диалогу. Рад что по другим вопросам замечаний нет, значит в целом я на верном пути:-)
Самое важное как человек думает, просто что-то заученное не имеет смысла.
«Путь к совершенству» в ИТ ? А почему бы не спросить про JNI на С-шные библиотеки?Сmake компилятор не ставил ли кандидат на мавен? Можно так же поинтеросоватьтя что делал кандидат с map-reduc-ом..Да мало что можно спросить что никогда не придется делать.
>Почему завалить? Потому что этого как ни странно не знают многие middle/senior не говоря >о джунах.
бесит такое. вы хотите человека нанять или поиздеваться?
(это не к вам вопрос а вообще к подобной практике)
а практика говорит о том что несмотря на кучу умных вопросов на собеседовании, девелопер на позиции Java разработчика -потом часто большую часть времени правит HTML шаблоны и XML конфиги
Ага, поговорим о канкаренси и о том как космические объекты бороздят просторы хипа, о всех шаблонах, включая интеграционные. Чтобы в итоге попасть на проект с говнищем чуть менее чем полностью написанным индийскими братьями, которые, к сожалению, не читали требований Олега Карякина, и отношением к проекту типа — «Ну его нахер трогать, рефакторинг займет 100 лет, клиент на это денег не даст, поэтому вот тут мы подставим костылик, вкоммитим в наш любимый svn, перекрестимся и будем ждать результатов ночной сборки». Как-то так.
Уже джуно-миддлов есть смысл спрашивать про устройство JVM
вы хотите человека нанять или поиздеваться?я его не нанимаю, мое дело оценить его технический уровень и нормально ли с ним работать в команде, если человек выходит из себя когда его спрашивают базовые вещи, то это тревожный звоночек. Глупо на проекте где нет Struts про него спрашивать, это да, но про general Java никогда не глупо. Потому что знать по верхам Spring, Hibernate, но не знать коллекций, строк и рефлексии или писать аннотации и не знать интерфейсов == не знать ничего.
Сейчас по-проектная тенденция постепенно уходит и от человека требуется все больше overall knowledge, которая применяется везде, тот же JVM и способность быстро разобраться с новой технологией, потому что на одном рабочем месте может быть много разных проектов.
По цьому списку можна скласти туторіал для підготовки джуна, або ж список питаннь для співбесід джуна :)
6) Иногда чтобы завалить спрашивают про устройство памяти, что такое стек или куча,
Хехе, кто с С начинал,тому известно.
все так. На первом сбс в епаме было почти все из вышеперечисленного
Смотря в каком направлении планируешь развиваться — modile или enterprise/web. В любом случае Java Core нужно знать отменно.
Думаю всё необходимое можно найти здесь
docs.google.com/...0wTEpCbrRE/edit
Я бы спросил про
Что такое ACID?
Контракт между Equals/Hashcode?
Какие есть основные коллекции?
Устройство хэштаблицы?
Виды джойнов, ссылочная целостность, каскады?
Что такое юнит тесты, зачем они нужны, как, когда и для чего их применять?
Что такое SOLID?
Что такое рефакторинг?
По js спросил бы что такое замыкания, hoisting, реализации наследования.
Плюс еще задал бы парочку глупых примеров из ООП, вроде у кота 4 ножки и у стула 4 ножки, можем ли мы отнаследовать кота от стула.
Еще желательно какой-нибудь ассайнмент вроде написать утилиту которая распечатала бы директорию в виде дерева и в зависимости от параметров отсортировала бы output. Чисто чтобы проверить как человек пишет код.
Обязательно спросил бы какие книги читал.
Имхо от джуниора нужно уметь писать код, быть технически грамотным, хорошо владеть ООП, писать чистый протестированный код с минимумом дублирования. И это кстати не все синьоры умеют к сожалению.
А Вы бы взяли на работу джуна, если бы Вам джун сказал, что можно отнаследовать кота от стула и обяснил почему? :)
Понимание того, как можно отнаследовать кота от стула маловато будет, чтоб прям брать на работу джуном.
Наверное именно поэтому полно говнокодеров, которые не понимают суть наследования, зато отлично знают что кошку от табуретки нельзя наследовать, даже не поинтересовавшись условием задачи. Да и пиво открываю на работе зажигалкой если нет открывашки, нарушая все принципы ООП и здравого смысла:-)
Я бы не взял, потому что с вероятность 80% он будет творить такое на проекте. Пихать наследование куда не надо. Это прямо таки бич всех джунов. Вместо того, чтобы разобраться с основными 23 шаблонами и их применять по очереди ни к месту, тулят одно наследование, также не интересно.
Подождите... вы ж таких на работу не берете:-) Творят на проекте именно те кто на собеседованиях и отвечал социально желаемые ответы, не понимая сути. Еще один прекрасный вопрос: по ссылке или по значению передаются объекты. Поделитесь авторитетным мнением?
В Java все передается по значению, а когда передается объект, то передается значение ссылки, а не прямой адрес в памяти (как в других языках)
Согласен. Но согласитесь, что не все кто проводит интервью это знают?:-)
Для джуна это тоже важно знать, чтобы потом избегать досадных ошибок когда передают что-то примитивное в void метод, надеясь что оно там как-то изменится. По поводу знает или не знает интервьер, обычно считается хорошим тоном не спрашивать того, чего сам не знаешь или плаваешь. Но если на проекте применяется к примеру мощный JS, а на собеседовании присутствует Java dev из другого проекта, то он тоже может спросить, хоть на таком уровне и не разбирается.
Передаётся копия ссылки или копия значения примитива, если быть точным.
как обратную сторону медали смею предложить мидлов которые помешаны на паттернах. тулят их к месту и нет. особенно когда доходит до обсурда — фабрика фабрик
«Вы и Дженифер Лопес. Руки есть, ноги есть, голова есть. Близнецы-братья» © Мой препод в универе
ИМХО, нужно уметь разделять trainee-junior и junior-middle. То, что ты описал должен уметь/реально прочувствовать strong junior/недомидл.
еще забыл он сверху написать про уровни изолированности транзакций что бы добить окончательно :))
Почему «добить» это блин первая пара по базам в любом универе.
не знаю, что это за универ, но для меня такой универ из раздела фантастики, было
ACID.. SOLID.. вы там джуниор составителя словаря аббревиатур собеседуете?
приходит такой джун и говорит... ACID, дедуля? не, не слышал, а ты дедуля про MongoDB слышал? И что дальше — в отбраковку?
а ты дедуля про MongoDB слышалДедуля про все слышал. Тем более что есть NoSQL базы с ACID.
так как, джун без знания ACID — не джун или чо?
Тем более что есть NoSQL базы с ACID.ну, вестимо и женщины бородатые бывают
До чего джуны ленивый пошли, в гугле полно статей, что нужен знать, а что необязательно.
Неужели лень искать, но не лень создавать тему?
Теперь по теме, все зависит от компании и проекта. Где-то терпят отсутствие знаний фрейворков(в частности Hibernate, Spring и т.д), но бывают места где от джуна это требуют(говноконторки ищущие юных гениев, чтобы продавать их аки синьеров).
Но, в любом случае от джуна ожидают хороших знаний по core, servlet api и jdbc. помимо этого не стоит забывать про SQL и JS.
Я нашел эту статью через гугл
Есть простой способ: открывайте вакансии и смотрите что сейчас в тренде.
Но я бы сказал так: помимо core, джун должен максимально хорошо знать core.
На месте джуниора, я бы, все-таки, не распылялся на фреймворки, но таки уделил 80% внимания основам. Для этого очень хорошо подойдет методичка по SCJP (около
Хорошо бы ещё по этой книге вести конспект и записывать самые интересные и ключевые моменты. Потом хватит одного лишь беглого просмотра этого конспекта, чтобы подготовиться к вопросам по core на собеседовании.
я бы в знание фреймворков особо не упирался. по крайней мере для джуниоров. оно часто меняется и быстро устаревает.
а вот коре и алгоритмы это навсегда.
в крупных софтверных западных компаниях типа того же Google, Microsoft, Amazon, предпочитают брать хорошо соображающих в алгоритмах, тк все задачи на собеседованиях в таких компаниях это достаточно абстрактный кодинг не привязанный к каким-то фреймворкам или технологиям
Все что у вас захотят спросить в конкретной компании © Собеседования и тараканы в голове его проводящего бывают крайне разные.
Капитан Очевидность подсказывает — спрашивают обычно то, что написано в описании требований к конкретной вакансии. если чего-то из заявленного списка не знаешь — не беда, но следует почитать про, хотя бы чтоб общее понимание было, перед собеседованием
Поспорил бы с этим.
с какой частью именно?
Капитан Очевидность подсказывает — спрашивают обычно то, что написано в описании требований к конкретной вакансии.
Oleg Kariakin
Dmytro Lynnyk
Андрей Донской
anonymous
Mobile
Emma Hansson
Vasyl Hukalyuk
Dmytro Sokolov
Dmytro Sokolov
idOne Арбузный
Viktor Syrovets
Anton Kovalev
Oleg Kotok
Victor Mikhaylov
Юрий Паламарчук
Oleg Kariakin
Victor Mikhaylov
Taras Voloshenko
Євген Козлов
Stanislav Sergienko
Ivanov Ivan
Alexandr Semeshchenko
Ievgen Safronenko
Yurii Drozd
Дмитро Дем'яненко
Oksana Chuiko
Anatolii Papenko
Maksim Babenko
Artem Kunyk
Студент
Vasiliy Poupkine
Maksim Babenko
Юрий Паламарчук
Artem Kunyk
Andrey Pilipenko
Найкращі коментарі пропустити