четверг, 1 ноября 2012 г.

Что нужно знать Java разработчику для прохождения собеседования

Мы как-то резко разогнались с женой и сразу начали накидывать информацию. Настала пора притормозить и начать с начала.

А начало у нас будет простое. Для чего мы работаем? Если кто-то скажет "для удовольствия", "для того, чтобы узнать что-то новое" или не приведи Господи "чтобы работать в  команде", киньте, пожалуйста в него чем-нибудь тяжелым. Зачем этот HR к нам пришел? Самое главное и не надо этого стесняться, мы работаем ради денег. Так вот, цель определили. Теперь как к ней идти.

Денег нам не дадут, если мы не устроились на работу, где эти деньги платят. Ну и денег будет мало, если мы не смогли попасть на ту работу, где их много (то есть пришлось удовольствоваться малым... это не наш путь, правда?). Поэтому самым важным умением любого программиста надо признать умение проходить собеседование. Вот этим вопросом мы сейчас и займемся.



Сразу оговорюсь, я пищу о собеседовании в компании, занимающиеся аутсорсинг-разработкой enterprise приложений. Ни про игровые компании, ни про автоматизаторов всех мастей ничего не скажу, хотя подозреваю, что там все примерно так же.

Как правило, во вменяемых компаниях вас сначала собеседует некий HR, а только потом - технарь. Так вот, вы сразу должны понимать, что HR ничего не решает. Его (её, как правило) бонус напрямую зависит от того, сколько людей она наймет. Поэтому ей экономически выгодно нанимать кого угодно, лишь бы техническое собеседование прошел. Так что прохождению первого собеседования радоваться не будем. ну и готовиться к нему не будем. Почти. Что нужно подготовить к первому собеседованию, так это вспомнить названия последних мест работы (лет за пять, не больше) и быть готовым к вопросам "почему вы оттуда ушли, что не устраивало?". Опять же, HR-ка ничего не решает, но все-таки... Опробуйте сначала на ней свои варианты ответов. С большой долей вероятности, после прохождения технического собеседования вас вызовет начальник и будет задавать все те же вопросы. И вот он уже будет решать - брать вас или нет. И если за последние пять лет вы поменяли 10 работ, причем с каждой вы уходили потому, что не сошлись характерами, будьте готовы - вряд ли вас возьмут. Скандалисты и склочники никому не нужны.

Итак, группы вопросов, которые вам зададут почти в любой компании:

1. (опциональная) По устройству JVM, байт-кода, garbage collector и всякое такое. На самом деле эти темы уже отходят в прошлое, однако надо все это знать. Потому как пригодится и в работе.
2. ООП: три принципа, области видимости и т.п. Знать обязательно. Я лично, любого "программиста", который не знает ответ на вопрос про классы А и В, не возьму. Нефиг позорить гордое имя программера.
3. Collection Framework. Основные интерфейсы, их основные реализации, преимущества и недостатки. Мы же блин работаем с entrprise решениями. То есть - у нас много цифорок и очень  много буковок. И все это надо где-то хранить и как-то обрабатывать. Знание этого пункта ультимативно, хотя бы в основном.
4. (опционально) Многопоточность: треды, семафоры, блокировки. Зависит от специфики работы, может быть важным пунктом, а  может и не быть вовсе.
5. SQL. Знания на базовом уровне, опыт работы (как программиста) с чем-то из распространенных СУБД: DB2, Oracle, MS SQL или на худой конец MySQL. Умение написать просто запрос, выбирающий данные из двух таблиц. Конечно, мы давно все пользуемся ORMами, однако, когда все идет не так, как надо (а оно ВСЕГДА так делает), приходится включать режим show sql и читать-читать-читать глазками.
6. Spring. Знание, практически, ультимативно. Имеется в виду, конечно только dependency injection. Всякие так Spring MVC - не обязательно.
7. Какой-то из фреймворков для построения морды: JSF, Struts, может быть что-нибудь для AJAX или даже FLEX. Не важно. Главное чем-то одним владеть на уровне "профессионально работал на...".

В общем-то и все. Человек, который сумел пройти эти семь пунктов заслужит у меня, например, положительную оценку.

12 комментариев:

  1. Как же много всего надо знать и уметь 6)

    ОтветитьУдалить
    Ответы
    1. Да ладно, прямо много.... на самом-то деле знать надо существенно больше, это только для собеседования список ;)

      Удалить
  2. А чем знания устройства JVM может пригодится в работе? Честно, чем? Всегда было это интересно.

    Знание типов и принципов работы garbage collector-ов - это еще ладно, при тюнинге app сервера пригодиться может. раз в 5 лет. (набор, кстати, разнится от версии и "производителя" т.е. всё- равно в доки и гуглы лезть придётся глубоко и плотно каждый раз )

    Но например тот же байт код?

    Это знания того же уровня что и устройство компилятора C++ : нужны крайне редко и узким спецам.

    ОтветитьУдалить
    Ответы
    1. И тебе привет, Гму, рад тебя видеть.

      Я сам, лично, вопросов этой группы никогда не задаю на собеседовании. Но мне регулярно задают. Естественно не о том, какова структура байт кода, а о том - что это такое и зачем он вообще нужен. Так же я отношу к этой группе вопросы о том, что такое JIT и зачем он нужен, можно ли и с помощью каких инструментов получается исходный код из байт-кода и с помощью каких инструментов (обфускаторов) можно частично этому помешать. Ну и так далее. И знание ответов на эти (вполне примитивные для опытного разработчика) вопросы часто используется в работе. По крайней мере мной.

      Удалить
  3. Привет привет :)

    Честно - ответы про эти JVM & so on - знаю. На уровне общего грубого представления, но знаю. В работе не использую, вообще никогда. (Я, если что, большой и толстый технический лидер в свой не маленькой конторе, опыт Java - под 15 лет. :) )

    Я понимаю что собеседования имеют мало общего с реальностью, но всё же...

    Ну вот обфускаторы или интерпретаторы с других языков на Java машине - это там где нужно понимать байт код, да. Но это настолько редко встречающаяся работа, реально. И если вдруг в такие дела попадешь - там научат. И похлеще любой доки.

    Сама тема мне для меня очень интересна и актуальна (почему и влез), но с другой стороны. Со стороны нанимателя :) Мы ищем людей и имеем большие трудности с их нахождением. Многие годы, причем. Так что мне крайне любопытно об этом обо всем почитать. Глядишь чего нового почерпну.

    P.S. Вообще интересно сравнить. Если по предложенному тобой списку вопросов идти - я лузер :) Spring не знаю.. JVM и т.п. - выше. чего за три принципа ООП имеются ввиду даже не нагуглил слёту :)

    ОтветитьУдалить
    Ответы
    1. Ну раз интересно, то я с радостью отвечу, поскольку как раз знаю ситуацию с обоих сторон баррикад - часто занимаюсь наймом и часто ищу работу. Ты задавай вопросы, я же не знаю, что тебе интересно ;).

      Насчет того, что ты не знаешь - как раз знаешь. Ты же сказал - имеешь примерное представление. Что и зачем. навыков работы с этими инструментами тебя никто и не спросит.

      А вот спринг не знать - в современном аутсорсе - это очень жирный минус. Строго говоря за последние 5 лет участвовал чуть ли не в полусотне проектов и только один был не на спринге. А насчет трех принципов ООП - ты меня повеселил :) Да знаешь ты их отлично - инкапсуляция, полиморфизм, наследование. :) Вспомнил? да и гугл сразу же подсказывает ;)

      Удалить
  4. Ах вот что за принципы... :) как то не связывал :)

    Я на самом деле этих фреймворков столько пережил... ну кто сейчас вспомнит что такое torque например? И Spring тоже переживу :) не люблю я их. Костыли. Для быстрой разработки непритязательных приложений - да подходит. наверное. Я от аутсорсинга ушел лет 12 назад. Хотя наверное в пост совецком пространстве это самая распространенная работа, да.

    А вообще у меня отношение такое - опытный человек любую библиотеку освоит за считанные недели. Дай ему доки и примеры. А балбеса и навороченный фреймфорк не спасет. Видал я такие реализации систем ну в оооочень больших и всемирно известных конторах что тошнило неделю потом. На Spring в то числе.

    Мне всё интересно :) Наверное самому стоило такой блог завести но ты успел раньше :)

    ОтветитьУдалить
    Ответы
    1. > Ах вот что за принципы... :) как то не связывал :)
      хе-хе :) Старый стал, ленивый ;)

      Насчет спринга - вряд ли переживешь. Скорее что-то типа него в JVM встроят - все к этому и идет. Dependency Injection штука а) нужная и б) настолько уже привычная разработчикам, что деваться некуда. В общем-то все новые разработки которые я видел на нем базируются. А вот как обращаться к Hibernate без Spring - я даже и не помню.Хотя да. балбеса ничего не спасет. но нормальному разработчику удобные фреймворки - очень помогают.

      >Наверное самому стоило такой блог завести но ты успел раньше :)
      Хочешь поучаствовать в написании статей? :)

      Удалить
  5. Вот написал бы о Spring, чего в нем ценного-полезного. Мне интересно :) А самому читать - да, Старый и ленивый :)

    Встроят - изучим. Прецеденты уже бывали не раз, да.

    ОтветитьУдалить
  6. Спасибо, полезная статья, но думаю в большей степени для тех кто уже обладает какими-то навыками.
    У меня делема я никогда не программировал, но есть большое желание знать Java. Не знаю с какой стороны к ней подойти. Просто читать книжки впрок, нет никакого смысла. Все быстро выветривается, а по работе она мне не нужна.

    С чего бы Вы посоветовали начать и что знать на начальном этапе, что бы можно было дальше двигаться уверенно?

    ОтветитьУдалить
    Ответы
    1. Я сделал цикл лекций по Джаве для начинающих. Советую ознакомиться https://www.youtube.com/watch?v=-gGLSxmw3jo&list=PLmqFxxywkatRQsM9u0p-6-vvzlJgnVwKE

      Удалить
    2. Спасибо за ответ) Обязательно посмотрю)

      Удалить