This media is not supported in your browser
VIEW IN TELEGRAM
Уже завтра он встретит вас на работе
😁6
Попробовал я значит эти разрекламированные сегодня тесты на форуме ЦИПР (это же надо додуматься, чтобы на такой уровень вынести 10-20 - минутные тесты для разрабов как вау-технология).
Краткий итог - шлак полнейший - теоретические вопросы еще более-менее, но практика с ужасным редактором кода, который даже не умеет в автокомплит - это фиаско (на самом деле то ли тормозит, то ли частично умеет). Кроме того - задачи элементарные, но с кучей условий, что ты можешь не успеть вспомнить все нужные статические методы, которые на практике не часто используешь, вроде parseDouble, Math.pow. Вообще эта часть похожа на алгоритмическую секцию в одной известной компании на "Я" - сидишь как дурак и пытаешься доказать, что ты - не верблюд.
Кто пытался - кидайте в комменты свои впечатления!
Краткий итог - шлак полнейший - теоретические вопросы еще более-менее, но практика с ужасным редактором кода, который даже не умеет в автокомплит - это фиаско (на самом деле то ли тормозит, то ли частично умеет). Кроме того - задачи элементарные, но с кучей условий, что ты можешь не успеть вспомнить все нужные статические методы, которые на практике не часто используешь, вроде parseDouble, Math.pow. Вообще эта часть похожа на алгоритмическую секцию в одной известной компании на "Я" - сидишь как дурак и пытаешься доказать, что ты - не верблюд.
Кто пытался - кидайте в комменты свои впечатления!
👍1😁1
Включил ненадолго сообщения в канале - проверим насколько это целесообразно и не будет ли спама.
Немного про практику. 💻 Технический дневник.📒
Впервые о нем я прочёл в книге 'Программист-прагматик'. Я и до этого делал некоторые заметки, но после стал намного чаще. О чем вообще эта идея - всякий раз, когда вы решаете какую-то задачу и сталкиваетесь с нестандартным кейсом, фиксируете это. Я последнее время использую телефон, несмотря на то, что бумага иногда даже лучший вариант. Просто блокнот в моменте не всегда под рукой.
У меня в заметках телефона накопилось уже очень много таких знаний, буду пробовать с вами делиться в том или ином виде. А пока вы можете эту технику взять и себе на вооружение - это полезно не только на работе, но и в учёбе - ведь она для разработчика никогда не заканчивается.
Впервые о нем я прочёл в книге 'Программист-прагматик'. Я и до этого делал некоторые заметки, но после стал намного чаще. О чем вообще эта идея - всякий раз, когда вы решаете какую-то задачу и сталкиваетесь с нестандартным кейсом, фиксируете это. Я последнее время использую телефон, несмотря на то, что бумага иногда даже лучший вариант. Просто блокнот в моменте не всегда под рукой.
У меня в заметках телефона накопилось уже очень много таких знаний, буду пробовать с вами делиться в том или ином виде. А пока вы можете эту технику взять и себе на вооружение - это полезно не только на работе, но и в учёбе - ведь она для разработчика никогда не заканчивается.
👍5🔥1
В пользу поста выше. 👆
Я как-то с другим сеньором решал проблему того, что созданный мок в тестах не отрабатывал, те не отрабатывал verify на вызове его метода (если не поняли, то ничего страшного) 🤔. Проблему мы как-то решили и забыли. А буквально вчера в общем чате джавистов про похожую кто-то спросил, а я не запомнил и не записал, что в итоге сделали. А ведь мог оперативно помочь коллеге, да и сам освежить свою память по этому кейсу.
Я как-то с другим сеньором решал проблему того, что созданный мок в тестах не отрабатывал, те не отрабатывал verify на вызове его метода (если не поняли, то ничего страшного) 🤔. Проблему мы как-то решили и забыли. А буквально вчера в общем чате джавистов про похожую кто-то спросил, а я не запомнил и не записал, что в итоге сделали. А ведь мог оперативно помочь коллеге, да и сам освежить свою память по этому кейсу.
Количество или качество 🤔
Несмотря на наш технический и иногда творческий род деятельности (именно творческий при решении нестандартных кейсов), менеджеры, любого звена, прежде всего оценивают разработчиков через количественные характеристики - задачи, сторипоинты, часы разработки, а бывает и коммиты. По этой причине часть из нас бывает пренебрегает качеством решения задач, пытаясь успеть выполнить то ли 'хотелки' бизнеса, то ли доказать себе свою продуктивность. На самом деле это очень опасная ловушка, в которую попадают многие - так уж сложилось, что последнее время мне все больше приходится наблюдать чужой код (что я считаю хоть и допнагрузкой, но все же плюсом).
Попытка успеть многое в ущерб качеству решения задачи приводит к большему количеству дефектов, иногда даже очень и это только то, что находится на поверхности при тестировании фичей и обнаруживается на раннем этапе. Бомбы замедленного действия могут сработать в самый неподходящий момент, и решение последствий привести к громадным затратам ресурсов (на такое даже есть статистика в умных книжках).
Конечно ошибки не исключены даже при должном подходе к разработке, но вы должны понять одно - нельзя всегда идти на поводу управленцев, иногда могут приниматься не очень хорошие решения, мною в том числе, но это в основном временные и самое главное обдуманные по рискам как со стороны бизнеса, так и разработки. Оправдание из разряда 'нас торопят' не должно быть постоянным оправданием костылей.
Несмотря на наш технический и иногда творческий род деятельности (именно творческий при решении нестандартных кейсов), менеджеры, любого звена, прежде всего оценивают разработчиков через количественные характеристики - задачи, сторипоинты, часы разработки, а бывает и коммиты. По этой причине часть из нас бывает пренебрегает качеством решения задач, пытаясь успеть выполнить то ли 'хотелки' бизнеса, то ли доказать себе свою продуктивность. На самом деле это очень опасная ловушка, в которую попадают многие - так уж сложилось, что последнее время мне все больше приходится наблюдать чужой код (что я считаю хоть и допнагрузкой, но все же плюсом).
Попытка успеть многое в ущерб качеству решения задачи приводит к большему количеству дефектов, иногда даже очень и это только то, что находится на поверхности при тестировании фичей и обнаруживается на раннем этапе. Бомбы замедленного действия могут сработать в самый неподходящий момент, и решение последствий привести к громадным затратам ресурсов (на такое даже есть статистика в умных книжках).
Конечно ошибки не исключены даже при должном подходе к разработке, но вы должны понять одно - нельзя всегда идти на поводу управленцев, иногда могут приниматься не очень хорошие решения, мною в том числе, но это в основном временные и самое главное обдуманные по рискам как со стороны бизнеса, так и разработки. Оправдание из разряда 'нас торопят' не должно быть постоянным оправданием костылей.
👍3
JVM Brain | Java&Kotlin
Для удобства навигации по чату были созданы теги, в информации о группе они не очень удобны, поэтому оставлю тут и кину в закреп #задачавыходногодня - небольшие тесты #mustread - что почитать (из лично прочитанного) #вакансия - тут можно найти работу (обычно…
Аларм! В закрепе есть полезные материалы. Как напоминание тем, кто вдруг забыл или не знал.
👍2