Получил слишком хороший 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-м классе мы именно на господине по имени Блез решали безумные задачки по сортировке, поиску элементов в массиве. С получением же аттестата зрелости закончились и эти тренировки на кошках.
В любом случае у Вас вполне достойный оффер. Понимаю сомнения - сам в свое время метался, когда меня просто "умножили на три" по сравнению с текущей работой, предложили страховку, оплату спортзала и бесплатные языковые курсы.
Ни один язык не мешает. Точнее - перестает мешать после определенного рубежа.
Хоть ПАСКАЛЬ, хоть БЕЙСИК.
Правда при наличии в резюме только бейсика Я бы спросил что-нибудь об организации объектов, а при паскале - об математике указателей. Просто чтобы видеть было ли развитие после изучения этих языков.
Зарплата хорошая, но точно не завышенная.
разрабатывает демки по интеграции или add-ons для имеющейся громадной платформы. Так что надеюсь репозиторий будет не очень ветвистым
Скорее всего будет куча релизов и бранчей, но может Вам придётся работать только на одном (чекаут, чекин).
Я показал им интерфейс своего первого проекта, потыкал в кнопки, объяснил архитектуру. Они сказали, что им нравится мое резюме
Typisch deutsch - бумажки важнее, но хорошо, что хоть что-то по проекту спрашивали.
Не совсем понятно, требуют ли тут знания столь специфичных вещей на интервью?
Эта не специфическая вещь -- утечки памяти программируются очень часто, и хорошо если разработчик понимает причины их возникновения (а также зачем надо отписывать события, избегать сверхглубоких рекурсий...).
Я бы стал изучать больше практических вещей, вроде популярных библиотек и фреймворков, чем лезть в дебри их реализации и нюансы использования.
Можно не угадать с изучаемым (например, Angular vs. React). A вот приципиальным пониманием разработки на JavaScript могут похвастаться немногие.
собеседования будто бы исключительно злобные тролли проводят, которые всю ночь учат такие нюансы наизусть и валят ими претендентов.
Нетривиальный или очень сложный вопрос могут задавать с другой целью. Посмотреть реакцию кандидата: затупит или будет конструктивно рассуждать, задавать доп. вопросы.
А что, Ворд является единственным инструментом для создания резюме?
У меня, например, резюме в двух форматах - ПДФ и РТФ. РТФ могу и в Нотепаде поправить...
А Офиса в системах - вообще нет. Да и не люблю Я его - слишком много информации
об владельце сообщает...
Об Ворде разок на интервью беседовали довольно плотно - там думали об красивых
отчетах.
Думаете, это впечатлит работодателя? Сильно?
------
В зависимости от требований - навыки использования Ворда в аутоматион вполне идут в зачет
для прогера.
У меня сейчас часть отчетов делается в Ехселе. То, что сбрасывается в файл, рассчитано на
одну специфическую версию Ехсела - именно ее надо ставить на клиентские системы.
Как по твоему - впечатлит ли работодателя замена текущей версии отчетника на версию
в которой он не будет привязан к определенному Ехселу?
На всякий случай поясню - на уровне автоматизации версии Ехсела весьма сильно
отличаются.
Верстка в pdf - это реально огонь
------
Пых... РТФ-документик печатается на ПДФ-принтере и ПДФка шлется рекрутерам.
По моему - нормально. Не нормально когда рекрутер канючит именно вордовский
документик и не может ни извлечь данные из ПДФки, ни открыть Вордом пересланнаю РТФку...
верстка в постскрипте
-----
Постскрип - мечта... используются специфические принтеры для печати лейблочек...
там даже не постскрип, а специфический для принтера язык ... ну и зоопарк с версиями...
все слеплено в стиле ВБ6 - где-то в коде формы идет рулежка принтером... 
Но самый-самый приятный момент - это все еще делается через полуоткрытое ИПсоединение...
Все никак руки не доходят починить...
А если человек укажет навыки там чтения, знания таблицы умножения и как доказать теорему Пифагора, это впечатлит?
Просто считаю, что умение решать квадратные уравнения, например, озвученное в 30+ лет может быть только во вред.
Рисовать черточки на BASIC в школе и несколько лет успешно участвовать в олимпиадах по спортивному программированию в школе и университете, где решаются серьезные задачи из теории графов, с использованием динамического программирования итд итп, пусть даже на старом никому не нужном языке программирования - это две совершенно разные вещи. О том, нужны ли навыки из спортивного программирования в работе, можно поспорить, но как минимум вчерашние олимпиадники хотя бы понимают, что такое пространственная и вычислительная сложность, умеют быстро писать производительные алгоритмы, умеют тестировать свой код и имеют чутьё на баги - тесты на олимпиадах очень изощренные. Так что если успехи есть - почему бы их не упомянуть? Тем более это вырисовывает логическую цепочку в автобиографии, показывает внутреннюю мотивацию, любовь к професии, что тоже важно.
Если бы мои интервьюеры этого не понимали - не уверен, что я хотел бы работать с ними :-)
При поступлении во второй университет мне на вступительных экзаменах выпало что-то посчитать... и доказать Теорему Пифагора.
Расчетная часть базировалась на теореме синусов, но требовалось догадаться что нужно использовать одно из следствий. Контрольным вопросом на понимание материала был - чем можно заменить теорему синусов в данном расчете? - Ответ - Теоремой косинусов. - второй вопрос не помню, но что-то по совместимости, ответил на него так - Какая разница - будет синус или будет косинус ака синус плюс пи-пополам? Уравнение то трансцендентное - от этого не уйти...
После этого была Теорема Пифагора. Мой вопрос - Каким способом доказывать? - вызвал полное недоумение, пришлось пояснить - Теорему Пифагора Я могу доказать 18-ю способами - (перечисление названий). Какой именно вы хотите услышать?... Доказывал тем, который назывался "стул невесты".
Как по твоему - Если меня приняли на учебу, то впечатлило ли доказательство Теоремы Пифагора приемную комиссию (ака работодателя)? Или оно было совершенно не нужно и можно было обойтись решением трасциндетных уровнений?
если человек укажет навыки там чтения, знания таблицы умножения
-----
В Штатах - да, впечатлит - там много тех, кто закончил школу без указанных навыков. В той с(т)ране откуда Я - теперь уже тоже. Как ни странно - и в Ирландии имеет место быть - тут есть сотрудники, которые владеют только устным общением - ни читать, ни писать не могут.
Мало того, в той с(т)ране откуда Я надо не только указать навыки говорения/чтения/письма, но и предъявить документ (отдельный от школьного аттестата полученного там же) подтверждающий их наличие. А без документа - на работу не возьмут - запрещено законом - даже если диффуры третьего порядка в голове считаешь...
Осознал? Или будешь понижать требования до уровня складывания кубиков и пазлов? По кубикам - Я сдамся, а по пазлам... на райончике где Я сейчас живу есть девочка... лет 15... любит пазлы... но с ними - не справляется - уровень развития не позволяет... Я таки думаю что как раз неспособность сложить пазл будет причиной отказа работодателя от использования данного сотрудника... вот если бы справлялась - взяли бы куда-нибудь...
Так-то оно так. Я все вел к тому, что указание таких инструментариев зачастую только во вред. Как если бы Вы указали в резюме работу грузчиком или в McDonalds. Должна быть четкая и удовлетворительная картина, не разрывающая шаблон. Архаические же инструментарии зачастую вызывают не удивление в плане wow, а удивление в плане what's the fuck 
Я это говорю не ради чего-то негативного или чтобы скрестить мечи - наоборот, хорошо, что у Вас получилось все и с такими условиями.
меньше лирики, больше конкретики
-----
При поступлении в армию США заполняется куча анкет.
Один из вопросов в одной из анкет - Умеете ли вы читать? - или надо ЕЩЕ конкретнее?
люди читают до 7-й или 8-й строки максимум
-----
Это проблема того кто пишет или все же проблема того кто читает?
Я регулярно пропускаю что-то при чтении. За эту неделю, помимо новостей, германки и работы, прочитано четыре книги общим объемом под 3500 страниц. Разумеется часть прочитана по-диагонали и что-то упущено. Но это - моя проблема - будет надо - вернусь у буду перечитывать.
Именно так Я и буду относится к читателям моих текстов - если текст нормальный, а сделать его читаемым это моя проблема, то понять его - проблема читающего. Ни помочь при чтении, ни исправить пропуски Я все одно не могу...
Что до того что читают первую половину первой страницы - Я знаю. Где надо - пользуюсь. К несчастью во многих случаях в эту половину страницы надо втиснуть информацию для нескольких людей с различными интересами.
потоки чужого сознания осиливать просто никто никто не хочет и вряд ли будет
-----
delivery of software solutions using C++ in an embedded software development environment (Linux/Windows). Wider technology environment stack includes Python, C, Java & .NET.
-----
Осиливай. Это - верхняя четверть объявления.
В нижней - там еще много всего... ну всякие лидершип, работа в индивидуальной группе и т.п.
Контракт - 6 месяцев.
> Ни разу не видел, чтобы кто-то напрямую в PS писал. Может, LaTeX?
не спорю, что в ЛаТеХе если через Tikz, можно классные графики строить, но для этого надо иметь латех съинсталлированный на компе, и иногда ждать несколько секунд, пока оно все откомпилится. Если же нужна простая, но векторная, двухмерная графика (это все-таки не OpenGL), то можно забацать заголовок на несколько строк, и потом сливать команды отрисовки, что получится постскрипт, который, при необходимости, конвертится в что угодно. Примерчик приложил - если открыть его редактором, то можно более-менее быстро понять как это все нарисовано. То есть реально генерится из голого сишника в 3-4 принта без единого вызова внешних библиотек.
Прикреплённые файлы
