Получил слишком хороший job offer
Добрый день, уважаемые коллеги!
Недавно я прошел собеседование на должность Java-разработчика в крупной местной софтверной компании и неожиданно получил слишком хороший оффер. Я планировал получить что-то среднее между джуниором и мидлом, а мне после часового поверхностного абсолютно не технического интервью дали почти сеньора, коим я себя совершенно не ощущаю :-D Теперь у меня опасения: а могут ли они меня уволить после испытательного срока, если не потяну? Или скорее понизят уровень и зарплату? Как это обычно тут делается? Может лучше сразу высказать сомнения еще до заключения контракта? Но это как-то глупо будет звучать: "понизьте мне зарплату на 10-20%, пожалуйста, мне так спокойнее будет".
Или может быть я зря температурю? Мой опыт: три года олимпиад по информатике на Pascal, красный диплом после пяти лет учебы на АСУ в провинциальном вузе и почти десят лет работы мастером на все руки в небольших компаниях: эникейщиком-админом-виндузятником и программистом 1С по совместительству. Сейчас заканчиваю магистратуру в немецком университете с очень хорошим средним баллом. Собеседовался я на Java разработчика, и должен признать, на Java я стал писать только во время учебы на магистратуре.
Если есть среди вас опытный Java программист, буду крайне благодарен, если подскажете, куда двигаться. Дальше будет много букв описания моих навыков. У меня было два учебных Java-проекта и один полностью написанный мною реальный, который показывает всё, что я умею. Back-end - это облачное JavaEE-приложение с использованием:
- EJB для бизнес-логики: stateless и singleton startup beans (чтобы делать lifecycle callbacks), местами асинхронные методы, потому что container-managed среде в JavaEE (до 8 точно) нельзя создавать потоки.
- JPA очень поверхностно: несколько entities, пара связей 1:n, пара простых запросов JPQL, немного constraints, lifecycle callbacks. В основном сущности запрашивает клиент через OData протокол и библиотека Apache Olingo сама преобразовывает клиентские зарпосы в JPQL-запросы, а бизнес-логика работает с сущностями через DAO-слой. Никакой оптимизации запросов не делалось, кэширования нет (и я никогда с ним не работал), тут очень мало данных в приложении.
- JTA - аннотации на методах и session beans чтобы правильно выстроить transactional scopes + немного повозился, чтобы Apache Olingo работал с Container-Managed транзакциями.
- CDI - decoupling, простота создания и удобство управления жизненным циклом зависимых объектов, написал несколько аннотаций, создал несколько продюсеров.
- BeanValidation - использовал все стандартные constraints + написал пару своих.
- ODATA интерфейс для фронтенда реализован при помощи Apache Olingo. Автоматически строится на основании JPA-модели + добавлено пара своих функций, переопределено поведение местами, повозился, чтобы заставить его нормально работать с container-managed транзакциями и их текущей реализации (JOTM) на этом сервере.
- Приложение так же выступает, как REST-сервер, так как пользовательские функции в OData принимают данные только из HTTP path параметров и передавать там конфиденциальную информацию, чтобы она закэшировалась всем Интернетом, нехорошо). Реализация Apache CXF, так как она уже используется Olingo и не хотелось перегружать приложение зависимостиями. Соответственно немного JAX-RS аннотаций, перехватчиков-обработчиков исключений, JNDI-lookup для session beans из Servlet и вперёд.
- REST-клиент я набросал свой в виде обертки над Apache CXF для удобства работы с несколькими сторонними API, сейчас бы уже использовал Feign. Умею пользоваться Gson и Jackson для сериализации/десериализации в JSON/XML, писал аннотации в прежних проектах, здесь просто использовал DTO. Немного работал с JQuery/XQuery/XPath.
- Security - declarative на базе ролей прописанных в deployment descriptor, программно через Servlet Filter дополнительная фильтрация. Аутентификация через сторонний SAML2 Identity Provider, который используется в этой компании, есть опыт работы с ним, его интерфейсами, особеностями итд.
- Timer Service для cron-подобного планирования задач.
- JavaMail API для рассылки уведомлений.
- Log4J для логов, облачная платформа позволяет выставлять logging level и читать логи.
- JUnit для тестов, которые больше смесь unit и интеграционных, зачастую без изоляции компонентов/моков. OpenEJB как контейнер для выполнения этих самых тестов.
- Maven для управления зависимостями, было несколько конфликтов, далее того сильно не вдавался в подробности его устройства и плагины.
- GIt использую постоянно, но в команде я не работал и даже никогда назад откатываться не приходилось, так что особого опыта с ним нет.
- Конфигурация приложения через properties-файл + через само приложение + облачная платформа позволяет инджектить ресурсы.
- Всё задокументировано javadoc. Сам код старался писать, чтобы он был "self-documented" и комментарии были бы не нужны: короткие методы, небольшие классы, нормальные названия переменных/методов.
Фронтенд писал впервые, быстро, на JavaScript с использованием проприетарной библиотеки, но я не хочу о нем говорить, потому что он симпатичный снаружи и ужасный внутри - это мое первое фронтенд приложение, оно для внутреннего пользования, это больше automation-проект и всем пофигу. Можно сказать, что во Front-end у меня вообще нет опыта.
Ну и если говорить о базовых вещах, то я имею представление о временной и пространственной сложности алгроитмов и операций над основными коллекциями, знаю основные ООП-паттерны, читал Clean Code, GoF, читал пару книг по Java, включая Java 8, знаю основные базовые Java библиотеки и интерфейсы, есть внутренняя мотивация поработать с облачными платформами и микросервисами (собственно, этим мой новый отдел и занимается). До этого был опыт написания всяких хитрых SQL-запросов и представление о том, как их оптимизировать.
Основными своими минусами вижу то, что все мои знания поверхностны, так как я всегда работал в одиночку, на небольших проектах, где "и так сойдет" и желательно подешевле и побыстрее. Не работал с многопоточностью. Валюсь на каверзных вопросах по Java вроде "как создать memory leak" или что-нибудь про GC, аргументы JVM итд. Не писал тесты серьезно: с автоматизацией, с полной изоляцией, интеграционые, Selenium, ничего такого. Не занимался maintenance серьезных проектов. Не работал с CI/CD, Jenkins, JIRA, Docker и даже Linux. И никогда не работал в команде, так что я по сути даже не знаю, насколько неправильно всё, что я делал, как быстро я должен был это делать итд итп) Шеф был очень доволен первым проектом, но он не разработчик, у моего кода не было review, а еще я пахал, как негр, чтобы побольше чему-то научиться в сжатые сроки.
Не знаю, на чем лучше сконцентрироваться: углубляться в какие-то базовые фундаментальные вещи или изучать больше то, чем отдел конкретно занимается: их облачную платформу, архитектуру микросервисов, контейнеры, всякие новомодные Netflix-библиотеки (API management, circuit breaker, сервера конфигураций итд итп).
Большое спасибо всем, кто откликнется и подскажет, что делать в данной ситуации и на что сделать упор в дальнейшем самообразовании.
В соответствии с немецким законодательством, в течение испытательного срока Вас имеют право уволить с Kündigungsfrist (сроком уведомления) в 2 недели без
особого объяснения причин. У Вас, правда, есть право с таким же коротким сроком уведомления уволиться самому (если, например, Вы нашли лучшее место).
Зарплата и уровень -- все зависит от того, как это прописано в контракте. Т.е., фиксированную часть з/п (Grundgehalt) уменьшить не могут, но если
часть зарплаты -- бонусы, зависящие от Ваших результатов, их могут сократить.
Телепаты в летних отпусках, а без них непонятно, что такое хороший job offer.
Сколько фиксированное брутто и сколько бонус? В Heidelberg или другом городе ? Что за контора: IT-фирма с внутренними проектами или постоянными заказчиками, отдел разработки, старт-ап?
после часового поверхностного, абсолютно нетехнического интервью дали почти сеньора
Хоть горшком назовут - деньги важнее, как и реноме фирмы, проект. O чём хоть говорили на интервью?
Git использую постоянно, но в команде я не работал
Не проблема для небольших проектов или более менее самостоятельной работы. Но можно попасть, как кур во щи, в большую команду с ветвистыми бранчами и мозговыедающими формальностями по итерациям.
Сказали, какой системой управления кодом пользуются, какими IDE ?
Сам код старался писать, чтобы он был "self-documented" и комментарии были бы не нужны
Похвально, но здесь редко ценится.
Валюсь на каверзных вопросах по Java вроде "как создать memory leak"
stackoverflow.com/questions/6470651/creating-a-memory-leak-with-java
Выходит, они не могут по результатам испытательного срока пересмотреть контракт и уменьшить мою зарплату и карьерный уровень? Только уволить?
Можно под угрозой увольнения предложить переподписать другой договор, например, на должность юниора. Или, как заметили выше, выставить на мороз во время испытательного срока.
С другой стороны, можно и самому во время сего срока ходить на другие собеседования и свалить, если работа не подойдёт. Поищите оценку фирмы на том же kununu (выбирайте достоверные отзывы, а не клише от HR).
Из внешниx источников можно узнать о текучкe кадров. Лучше всего, если отыщите через знакомых инсайдера в фирме.
Если есть сомнения, можно попросить о техническом интервью с теми,
с кем будете работать. Отказ от него я бы трактовал как плохой знак.
на что сделать упор в дальнейшем самообразовании.
Майнить Упор можно cделать на получение ценного для резюме опыта работы.
Выходит, они не могут по результатам испытательного срока пересмотреть контракт и уменьшить мою зарплату и карьерный уровень? Только уволить?
одно другому не мешает.
1. на основе вашей работы решают, что на должность по заключенному договору вы не подходите.
2. увольняют
3. предлагают другой договор на другую должность с другими обязанностями (и естественно с другой зарплатой).
Хммм... на п.3 далеко не все уволенные согласятся.
Основание - неправильная начальная оценка кандидата, т.е. отсутствие необходимой квалификации у управленцев и соответствующие последствия...
По теме - если реальный уровень юниор-мид, то пробовать на сениора - можно, но очень велика вероятность срыва.
Если по простому - там в фокусе не проблемы с синтаксисом, а вопросы организации взаимодействия команды.
На моей памяти не случалось успешных проектов в которых сениором был юниор.
С мидом - был более менее успешный - реализовали под 80% функциональности второго из трех стайджей, в основном за счет квалификации исполнителей. И это - один из нескольких - остальные проваливалiсь...
Спасибо за развернутый ответ!
Сколько фиксированное брутто и сколько бонус? В Heidelberg или другом городе ? Что за контора: IT-фирма с внутренними проектами или постоянными заказчиками, отдел разработки, старт-ап?
65 000 из которых 10% бонусом. Гайдельберг. Одна из крупнейших международных софтверных компаний, на всех площадках в топе топов. Отдел разработки, работает с внутренними заказчиками, а то и сам себе придумывает работу: по большей части разрабатывает демки по интеграции или add-ons для имеющейся громадной платформы. Так что надеюсь репозиторий будет не очень ветвистым, команды маленькими и проекты достаточно короткими - не люблю долго засиживаться над какой-нибудь давно уже legacy фигнёй.
Хоть горшком назовут - деньги важнее, как и реноме фирмы, проект.
В рамках данной фирмы это не просто название должности: у них жесткая иерархия должностей и ступеней, и сразу оказаться в ее середине довольно волнительно :-D
O чём хоть говорили на интервью?
Они рассказали о своей работе, я о себе. Предупредил, что в основном работал с 1С, много про нее расспрашивали, гуглили, удивлялись :-) Я показал им интерфейс своего первого проекта, потыкал в кнопки, объяснил архитектуру. Они сказали, что им нравится мое резюме и что по стечению обстоятельств все, что я использовал в своем первом проекте, они собираются или уже используют в своих, так что я вроде как кстати.
Упор можно cделать на получение ценного для резюме опыта работы.
stackoverflow.com/questions/6470651/creating-a-memory-leak-with-java
Я бы стал изучать больше практических вещей, вроде популярных библиотек и фреймворков, чем лезть в дебри их реализации и нюансы использования. Как по мне, пока сам на грабли не наступишь, причем на реальном проекте, такие вещи не запомнишь. Тем более в той же статье на stackoverflow довольно специфичные примеры и сочетания, которые я вообще на практике ни разу не применял в JavaEE. Не совсем понятно, требуют ли тут знания столь специфичных вещей на интервью? Потому что если почитать тот же Habrahabr, так собеседования будто бы исключительно злобные тролли проводят, которые всю ночь учат такие нюансы наизусть и валят ими претендентов.
А сколько я проходил собеседований, хоть бы один технический вопрос задали когда-нибудь. В основном все видят: олимпиады, конкурсы, оценки, стипендии, 10 лет опыта - берём! Здесь только один раз спросили, каковы основные шаги в Test Driven Development, и лет десять назад попросили наисать SQL запрос, который из одной таблицы с 10 записями выдаст 100 результатов. В основном какие-то ребусы детские дают.
По теме - если реальный уровень юниор-мид, то пробовать на сениора - можно, но очень велика вероятность срыва.
Ну меня не совсем сениором берут, скорее - старшим мидом :-) В команде есть свой архитектор, более опытные товарищи.
Другое дело, что я до сих пор не знаю, какая тут принята продуктивность в проектах и будет ли моя гораздо ниже. В команде никогда не работал, в Германии тоже. В единственной студенческой подработке описанный выше проект был целиком мой.
три года олимпиад по информатике на Pascal
Я бы нигде и никогда, ни под какими пытками не упоминал бы последнее слово ни в резюме, ни во время общения. Совсем.
По поводу Junior/Middle/Senior - это лычки ровным счетом ничего не значат, играют на человеческой страсти к получению медалей. То бишь признания и ублажения самолюбия. Не более. Смотреть нужно на доход. Судя по упомянутой Вами сумме, то не то, чтобы wow, но довольно неплохо, чуть выше среднего, что имеет очень далеко не каждый, приезжающий по той же BK.
Я бы нигде и никогда, ни под какими пытками не упоминал бы последнее слово ни в резюме, ни во время общения. Совсем.
Pascal
Ну почему, пара интервьюеров даже его и Delphi учили во время аусбильдунга. К тому же в 90-е не так много было ЯП и конкретно Pascal был у нас по регламенту.
Какая такая и кого именно дискриминация? Не понял.
Просто считаю, что умение решать квадратные уравнения, например, озвученное в 30+ лет может быть только во вред. И не только я так считаю, кстати, имя нам - легион. А какой главный постулат эскулапа? Правильно, постулат сей таков: "Не навреди!"
Да знаю я это, я тоже в школе учился. В 8-м и 9-м классе начинали с Бейсика, а в 10-м и 11-м классе мы именно на господине по имени Блез решали безумные задачки по сортировке, поиску элементов в массиве. С получением же аттестата зрелости закончились и эти тренировки на кошках.
В любом случае у Вас вполне достойный оффер. Понимаю сомнения - сам в свое время метался, когда меня просто "умножили на три" по сравнению с текущей работой, предложили страховку, оплату спортзала и бесплатные языковые курсы.
Ни один язык не мешает. Точнее - перестает мешать после определенного рубежа.
Хоть ПАСКАЛЬ, хоть БЕЙСИК.
Правда при наличии в резюме только бейсика Я бы спросил что-нибудь об организации объектов, а при паскале - об математике указателей. Просто чтобы видеть было ли развитие после изучения этих языков.