Немного дополню пост, сам в этот же период искал работу на middle/senior java developer, зп от 100к~110к на руки, предложений много, весь треш в основном проходит на первой неделе, на второй попадаются уже фирмы поинтересней.
Собеседования самые разные, от «назовите все методы класса Object» до задач про горящие веревочки(каюсь, не решил), было собеседование где попросили ссылку на Github репозиторий, считаю это неплохим подходом. Было собеседование где просили сделать задание примерно на день работы а затем на самом собеседовании сказали что им нужен программист попроще и что у них ограничен бюджет, только время потратил.
Если кто собирается искать работу, советую хорошо подготовить JavaSE, в остальном сами собеседующие мало чего знают за гранями их повседневной работы, поэтому если вас будут собеседовать на должность JavaEE(EJB, CDI, JPA, JSF), либо Spring разработчика, то это не значит что собеседующий отлично все это знает.
Опять же модель памяти и многопоточность тоже следует почитать, сюда же и GC приплюсую. Народ который любит самоутверждаться за ваш счет скорее всего будет спрашивать именно это.
Алгоритмы знать нужно на базовом уровне — это основные сортировки, поиск по дереву, знать что такое бинарное дерево(и поиска тоже), кратко знать виды деревьев поиска, АВЛ, Красно черное, Хеш таблицы, не нужно уметь писать их реализацию, мало кто это может сделать с ходу(за исключением самых простых реализаций).
Важное знание — умение оценивать сложность алгоритмов, если вы будете это уметь делать, то остальное будет значительно легче для вас.
Сам я на работу устроился, зарплата превысила указанную в резюме сумму, с интересностью работы пока разбираюсь.
Я думаю, любой согласится, что чем абстрактнее требования, тем проще работать.
Прям ОЧЕНЬ не согласен, как по мне, чем конкретнее задача, тем быстрее я ее сделаю и заказчика дергать не буду и сам не буду вертеться в сомнениях. А когда заказчик предоставляет готовые части, так это совсем круто, да у меня могут возникнуть вопросы и замечания, но уладить их можно в любой момент если заказчик на связи. Вплоть до редакции кода и присланных файлов.
Почему не нужно грузить бизнес техническими проблемами? Вот в западных компаниях часто написание тестов отдают на аутсорс например нам. При этом там бизнес учитывает эти проблемы.
Мы закладываем время написания тестов во время решения задачи, но это позволяет лишь частично покрыть код юнит тестами, а вот модульное и интеграционное тестирование мы пишем нелегально с угрозой получить по шапке.
Не понравилось обобщение о западных и восточных разработчиках в конце статьи, правила разработки часто диктуются условиями бизнеса и менеджерами. Подстроиться под них не всегда удается. В моей компании например написание тестов это инициатива прежде всего разработчиков, на это не выделяется время и это никак не поощряется.
Да ладно бы просто страшно, больше мой рациональный разум разработчика возмущает такой глупый и странный способ решения проблем.
Это как у вас в доме преступник — в кутузку весь дом.
Собеседования самые разные, от «назовите все методы класса Object» до задач про горящие веревочки(каюсь, не решил), было собеседование где попросили ссылку на Github репозиторий, считаю это неплохим подходом. Было собеседование где просили сделать задание примерно на день работы а затем на самом собеседовании сказали что им нужен программист попроще и что у них ограничен бюджет, только время потратил.
Если кто собирается искать работу, советую хорошо подготовить JavaSE, в остальном сами собеседующие мало чего знают за гранями их повседневной работы, поэтому если вас будут собеседовать на должность JavaEE(EJB, CDI, JPA, JSF), либо Spring разработчика, то это не значит что собеседующий отлично все это знает.
Опять же модель памяти и многопоточность тоже следует почитать, сюда же и GC приплюсую. Народ который любит самоутверждаться за ваш счет скорее всего будет спрашивать именно это.
Алгоритмы знать нужно на базовом уровне — это основные сортировки, поиск по дереву, знать что такое бинарное дерево(и поиска тоже), кратко знать виды деревьев поиска, АВЛ, Красно черное, Хеш таблицы, не нужно уметь писать их реализацию, мало кто это может сделать с ходу(за исключением самых простых реализаций).
Важное знание — умение оценивать сложность алгоритмов, если вы будете это уметь делать, то остальное будет значительно легче для вас.
Сам я на работу устроился, зарплата превысила указанную в резюме сумму, с интересностью работы пока разбираюсь.
Прям ОЧЕНЬ не согласен, как по мне, чем конкретнее задача, тем быстрее я ее сделаю и заказчика дергать не буду и сам не буду вертеться в сомнениях. А когда заказчик предоставляет готовые части, так это совсем круто, да у меня могут возникнуть вопросы и замечания, но уладить их можно в любой момент если заказчик на связи. Вплоть до редакции кода и присланных файлов.
Мы закладываем время написания тестов во время решения задачи, но это позволяет лишь частично покрыть код юнит тестами, а вот модульное и интеграционное тестирование мы пишем нелегально с угрозой получить по шапке.
Это как у вас в доме преступник — в кутузку весь дом.