Проблема в том, что не все умеют либо любят торговаться.
Это проблема самого человека. Неприятно — но это факт. Остается либо учиться, либо мириться с з/п ниже той что вполне реально было бы выторговать. Не все что приходится делать, доставляет удовольствие, селяви.
Иногда бывают проекта интересные и ипотека, и приходится бросать эти интересные проекты и идти за угол, потому что там 110.
По моему опыту как-то оказалось что все равно оно к лучшему. Те проекты, которые мне сильно нравились в прошлом, и с которых я ушел на более высокую оплату, сейчас меня бы совсем не заинтересовали даже за хорошую з/п. Видел я просто специалистов, зависших лет на 10 с плюсом на одном месте, зачастую довольно печальное зрелище — они очень хорошо могли знать какие-то ньюансы использования фреймворка или библиотек, используемых в проектах фирмы. Одна беда, зачастую эти фреймворки и библиотеки оказывались либо никому за пределами фирмы неизвестными внутренними поделками, либо древними и вышедшими из употребления общеупотребимыми. Соответственно их цена как специалистов на внешнем рынке труда оказывалась совсем невысокой.
Зависеть от благополучия одной организации в наше время это не очень хорошо — можно оказаться на улице с никому не нужным опытом работы с никому неизвестными фреймворками.
Ну и стандартная ситуация когда на интервью вынимают всю душу вопросами про алгоритмы, структуры данных и все вот это вот, а потом, если соискатель успешно прошел все этапы интервью, ему вручают тонну замшелого легаси из категории «рефакторить нельзя, допиливать».
Хахахаха, вот это в точку! На предыдущей работе троллил тимлида вопросами вида — какого хрена, ты, дорогой «товарисч» сношал мне мозг на собеседовании вопросами про SOLID, паттерны проектирования, TDD, и прочим, когда у вас тут в коде такая куча чудовищного легаси, громадные классы, делающие кучу всего одновременно, с тысячами строками кода, про большую часть которого уже никто не помнит что он делает и для чего он именно так был написан. Зачем было задавать вопросы про лямбы, замыкания, что нового в восьмой яве, если вы до сих пор со всем этим барахлом не можете переползти даже на седьмую.
Ну, это прекрасно, на самом деле. Вам сразу дали понять что рассчитывают на то что вы будете пахать без выходных и с переработками. Это намного лучше чем дойти до оффера, принять его, выйти на работу и в первый месяц понять что вы не хотите посвящать себя всего без остатка работе. После таких вопросов вы уже можете для себя определиться, стоит вообще дальше общаться или может быть лучше вежливо откланяться.
По статье — немало за последние десять лет пособеседовался, видел всякое, наталкивался и на очень странные интервью, но все-же неадеквата видел намного меньше чем тут описано. Обычно когда спрашивали о чем-то чего я не знаю я не воспринимал это как попытку потыкать меня в мое невежество. Просто переспрашивал, просил уточнить вопрос, напомнить о чем идет речь, если понимал что не знаю ответа или просто забыл из-за того что долго не использовал какую-то технологию, честно об этом говорил. Проблем обычно не было. Главное самому не тупить, рассказывать о том что знаешь, что умеешь. Хорошо прокатывают всевозможные примеры из реальной работы, как что-то поднимал, какие интересные баги фиксил, что и как оптимизировал… Часто получал офферы после тех собесов на которых откровенно «плавал».
Все-же собеседование это реально ближе к торговле, тут надо уметь продавать. Я не то что-бы хорошо умею, но все-же немного «насобачился».
Без понимания «выгоды отказа от тестов в денежных единицах» и вы не способны достаточно внятно подтвердить точку зрения ненужности или вредности юнит тестов. Это проблема обоюдная, как у противников так и у сторонников покрытия тестами.
Без точных количественных оценок обе стороны будут просто гадать и делать субъективные оценки.
Пишу на Котлин на новой работе примерно уже пару месяцев, до этого его вообще не знал (любопытствовал, но даже до хелловорда не доходил). Пока что главный плюс для меня в сравнении с Явой — более чистый, визуально, код. Тупо «меньше букв», читается намного приятнее. Сам по себе язык менее многословный, плюс необязательность объявления типов в тех местах где они могут быть выведены компилятором.
Не ради того что-бы потроллить… Это заблуждение про какие-то «выдающиеся мозги». С мозгом та-же история что и с мышцами. Если у человека нет каких-то физических патологий, то он мозги как и мышцы может очень серьезно прокачать. Разговоры о том что «вот Васе сказочно повезло, он сильный» — это чаще всего что-то из разряда оправдания своего нежелания ходить в спортзал и тратить время на занятия (не буду давать этому оценки — в таком желании/нежелании нет ничего плохого в принципе — важно просто не врать самому себе). Гипотетический «везунчик Василий» годами упорно занимался, тратил время на спорт и из «дрища» стал весьма накачанным парнем, это не разу не везение, это работа над собой.
С головой та-же история, даже если у человека просто феноменально мощные мозги, но он их просто заливает бухлом и глушит просмотром футбола или мыльных опер, то к 60-ти у него там будет все очень грустно.
Я все это к чему, просто если есть цель — и ее реально хочется достичь, то возраст это просто одна из помех, не самая серьезная, которую упорный человек в состоянии преодолеть.
Так даже лучше — есть реально нужные кому-то приложения. Развивайте их, переписывайте при необходимости хоть даже начисто. Анализируйте в чем там «говнокод» и старайтесь это исправить. При возможности найдите какого-либо достаточно лояльного спеца, который подскажет что не так и куда стоит копать что-бы это исправить, да хотя-бы на форумах, там, конечно вас непременно попинают, но и много дельного могут подсказать.
Мне очень помогла поначалу статья, которую я где-то на Хабре нарыл, о том что нужно изучить джуну в Яве, там был список необходимого (он уже правда несколько устарел), с такой дорожной картой намного проще, понятно куда и зачем движешься.
Вдогонку — стоит различать действия и цели. Нет смысла выносить в название функции действия, там должна быть цель. Потому название tryLock правильно, оно говорит о цели. Для достижения этой цели может быть произведено очень много разных действий, и это нормально и понятно, в этом легко разобраться и это легко поддерживать.
А вот если функция кроме того еще и пишет статистику, то у нее оказывается больше чем одна цель, и ее тоже нужно как-то вывести в название, а еще правильнее вынести достижение этой цели в отдельный код.
А почему-бы просто не сделать две функции: попить() и поесть() вместо этих костылей в аргументах?
Если в таких функциях оказывается много копипасты, то это повод задуматься о том, что их так-же стоит декомпозировать и копипасту вынести в отдельные функции, которые и использовать. Да, получится что вместо одной функции у вас уже стало несколько, но такой код и понимать и поддерживать как правило намного проще, и ошибки в нем легче заметить и исправить.
Часто наблюдал в коде функции (точнее методы), размером так в пару-тройку тысяч строк, и у них тоже, как правило огромный список аргументов на входе, в котором разобраться непросто даже когда на этого монстра есть какая-то документация (а ее чаще всего нет, либо она уже сильно устарела)
«А если функция кроме своих действий пишет статистику это побочный эффект?»
Да это побочный эффект, и да это плохо что на ней помимо основных обязанностей висит еще и «запись статистики». В таких случаях аспекты неплохо рулят — в функции нет ничего лишнего, но вся статистика по ее работе ведется… другой функцией, заточенной только под ведение статистики.
Плохое название стоит исправить на хорошее, а вызовы подряд зачастую лучше чем вызов одной универсальной функции, на которую навешаны десяток разных обязанностей
Сильно от ситуации зависит, какую стратегию выбрать — «бей» или «убегай». В некоторых обстоятельствах попытка разобраться с конфликтом может оказаться слишком дорогой в плане времени, нервов или денег (или всего этого вместе), не всегда оно того стоит.
«Рассылаю резюме — либо не отвечают, либо сразу отказ. Предполагаю, что отпугивает сочетание возраста и отсутствия практического опыта.»
У меня был похожий опыт, разве что моложе тогда был, лет 35. Перешел с С на Яву, но в Яве у меня был объективно уровень начинающего.
Составил список фреймворков, которые нужно знать хорошему мидлу, и начал все это усиленно изучать с написанием учебных проектиков, большая часть выглядела натуральным говнокодом, но руку набил, разобрался во многих ньюансах, и сразу же начал ходить на собеседование на уровень мидла.
Тут главное не опускать руки после первых неудач, часто поначалу самолюбию было очень больно, когда я понимал что собеседование провалил и причем выглядел на нем очень слабо. Больше упорства, делал выводы после каждого собеседования, подтягивал знания, где явно плавал, и через месяц такого марафона нашел работу. З/п была где-то на уровне между джуном и мидлом, сама по себе работа была так-себе, но она позволила мне зацепиться и дальше уже пошло легче. Сейчас уже и з/п хорошая и работа отличная, и сам себя чувствую неплохим специалистом.
upd: насчет опыта немного врал, говорил что на яве писал на предыдущей работе, по этой же причине замкнутого круга — на работу не берут из-за отсутствия опыта, опыт отсутствует потому что не берут, этой ложью я круг разорвал. Возможно не очень этично, но оно сработало, тем более что свои обязанности я на работе исполнял вполне добросовестно.
Со статистикой тоже нужно аккуратно обращаться, что-бы не получить «среднюю температуру по палате». Сложность трудоустройства очень сильно зависит от многих факторов, которые нельзя не учитывать. В большом городе, в стране с более-менее развитой экономикой, в востребованной профессии одна картина, и совсем другой расклад в каком-либо депрессивном Кобылозадовске, да еще и у людей с невостребованной профессией. Потому заявлять что после 40-ка «Шлёма всё» — слишком сильное утверждение, которое легко можно опровергнуть реальными примерами.
Возраст помимо минусов дает и плюсы, и ими можно и нужно правильно распоряжаться.
Бывают ситуации когда чекед эксепшен слишком сложно пробросить наверх, а что с ним делать в текущем контексте совершенно непонятно. Тут, ИМХО, намного разумнее его перехватить, вывести информацию в лог (включая стектрейс) и выбросить рантайм эксепшен. Тогда это исключение либо перехватят и обработают где-то совсем наверху, либо оно уронит все приложение и с проблемой быстро разберутся, обычно еще на этапе тестирования.
У меня просто бывало нередко что люди в целом производившие неплохое впечатление о себе, в экстремальной ситуации так раскрывались, что просто удивляет, и таких людей, к сожалению немало. Все хорошо «до первого шухера», и тут вроде бы твой даже приятель, с которым вы вместе весело общались и грызли печеньки на обеде, вдруг тебя жестко и весьма осмысленно подставляет, что-бы прикрыть свою задницу. К сожалению это совсем не редкость.
Это еще пол беды, хотя-бы какую-то информацию об ошибке выводят, хуже всего когда просто перехватывают все исключения и не делают вообще ничего. Встречал такое в практике, хотелось найти автора и сделать с ним что-либо нехорошее, ибо натыкался на такое как правило когда возникали странные ошибки, которые поймать было очень сложно.
У функций должны отсутствовать побочные эффекты, она должна делать только что-то одно, но делать это максимально хорошо. Если она написана именно так, то при ее описании не возникает желания использовать «и», и тем более перечисление побочных эффектов.
Вкрячивание булевых параметров, которые кардинально меняют поведение функции — это такой кривой костыль, автор об этом. Само собой у любого эмпирического правила подразумевается разумный подход его исполнителя (в этом основные плюсы и минусы таких правил) Любое разумное правило можно довести до абсурда если его выполнять тупо и формально, не задумываясь о последствиях.
Это тождественно выражению «не работайте». В любом коллективе есть хотя-бы один мудак (если в вашем нет — то у меня для вас неприятная новость). Это я гиперболизирую, конечно, но все-таки…
В 99% случаев — когда у вас просят совета в чем-бы то ни было, человек сознательно или не отдавая сам в том себе отчета, хочет переложить ответственность с себя на внешние обстоятельства, в данном случае на советчика.
Если совет окажется правильным — то очень быстро будет забыт тот кто его дал и человек все лавры присвоит себе, если совет окажется негодным — у него всегда будет возможность сказать что это не он накосячил — а вот этот вот — насоветовал!
Это проблема самого человека. Неприятно — но это факт. Остается либо учиться, либо мириться с з/п ниже той что вполне реально было бы выторговать. Не все что приходится делать, доставляет удовольствие, селяви.
По моему опыту как-то оказалось что все равно оно к лучшему. Те проекты, которые мне сильно нравились в прошлом, и с которых я ушел на более высокую оплату, сейчас меня бы совсем не заинтересовали даже за хорошую з/п. Видел я просто специалистов, зависших лет на 10 с плюсом на одном месте, зачастую довольно печальное зрелище — они очень хорошо могли знать какие-то ньюансы использования фреймворка или библиотек, используемых в проектах фирмы. Одна беда, зачастую эти фреймворки и библиотеки оказывались либо никому за пределами фирмы неизвестными внутренними поделками, либо древними и вышедшими из употребления общеупотребимыми. Соответственно их цена как специалистов на внешнем рынке труда оказывалась совсем невысокой.
Зависеть от благополучия одной организации в наше время это не очень хорошо — можно оказаться на улице с никому не нужным опытом работы с никому неизвестными фреймворками.
Хахахаха, вот это в точку! На предыдущей работе троллил тимлида вопросами вида — какого хрена, ты, дорогой «товарисч» сношал мне мозг на собеседовании вопросами про SOLID, паттерны проектирования, TDD, и прочим, когда у вас тут в коде такая куча чудовищного легаси, громадные классы, делающие кучу всего одновременно, с тысячами строками кода, про большую часть которого уже никто не помнит что он делает и для чего он именно так был написан. Зачем было задавать вопросы про лямбы, замыкания, что нового в восьмой яве, если вы до сих пор со всем этим барахлом не можете переползти даже на седьмую.
По статье — немало за последние десять лет пособеседовался, видел всякое, наталкивался и на очень странные интервью, но все-же неадеквата видел намного меньше чем тут описано. Обычно когда спрашивали о чем-то чего я не знаю я не воспринимал это как попытку потыкать меня в мое невежество. Просто переспрашивал, просил уточнить вопрос, напомнить о чем идет речь, если понимал что не знаю ответа или просто забыл из-за того что долго не использовал какую-то технологию, честно об этом говорил. Проблем обычно не было. Главное самому не тупить, рассказывать о том что знаешь, что умеешь. Хорошо прокатывают всевозможные примеры из реальной работы, как что-то поднимал, какие интересные баги фиксил, что и как оптимизировал… Часто получал офферы после тех собесов на которых откровенно «плавал».
Все-же собеседование это реально ближе к торговле, тут надо уметь продавать. Я не то что-бы хорошо умею, но все-же немного «насобачился».
Без точных количественных оценок обе стороны будут просто гадать и делать субъективные оценки.
С головой та-же история, даже если у человека просто феноменально мощные мозги, но он их просто заливает бухлом и глушит просмотром футбола или мыльных опер, то к 60-ти у него там будет все очень грустно.
Я все это к чему, просто если есть цель — и ее реально хочется достичь, то возраст это просто одна из помех, не самая серьезная, которую упорный человек в состоянии преодолеть.
Мне очень помогла поначалу статья, которую я где-то на Хабре нарыл, о том что нужно изучить джуну в Яве, там был список необходимого (он уже правда несколько устарел), с такой дорожной картой намного проще, понятно куда и зачем движешься.
А вот если функция кроме того еще и пишет статистику, то у нее оказывается больше чем одна цель, и ее тоже нужно как-то вывести в название, а еще правильнее вынести достижение этой цели в отдельный код.
Если в таких функциях оказывается много копипасты, то это повод задуматься о том, что их так-же стоит декомпозировать и копипасту вынести в отдельные функции, которые и использовать. Да, получится что вместо одной функции у вас уже стало несколько, но такой код и понимать и поддерживать как правило намного проще, и ошибки в нем легче заметить и исправить.
Часто наблюдал в коде функции (точнее методы), размером так в пару-тройку тысяч строк, и у них тоже, как правило огромный список аргументов на входе, в котором разобраться непросто даже когда на этого монстра есть какая-то документация (а ее чаще всего нет, либо она уже сильно устарела)
Да это побочный эффект, и да это плохо что на ней помимо основных обязанностей висит еще и «запись статистики». В таких случаях аспекты неплохо рулят — в функции нет ничего лишнего, но вся статистика по ее работе ведется… другой функцией, заточенной только под ведение статистики.
Плохое название стоит исправить на хорошее, а вызовы подряд зачастую лучше чем вызов одной универсальной функции, на которую навешаны десяток разных обязанностей
У меня был похожий опыт, разве что моложе тогда был, лет 35. Перешел с С на Яву, но в Яве у меня был объективно уровень начинающего.
Составил список фреймворков, которые нужно знать хорошему мидлу, и начал все это усиленно изучать с написанием учебных проектиков, большая часть выглядела натуральным говнокодом, но руку набил, разобрался во многих ньюансах, и сразу же начал ходить на собеседование на уровень мидла.
Тут главное не опускать руки после первых неудач, часто поначалу самолюбию было очень больно, когда я понимал что собеседование провалил и причем выглядел на нем очень слабо. Больше упорства, делал выводы после каждого собеседования, подтягивал знания, где явно плавал, и через месяц такого марафона нашел работу. З/п была где-то на уровне между джуном и мидлом, сама по себе работа была так-себе, но она позволила мне зацепиться и дальше уже пошло легче. Сейчас уже и з/п хорошая и работа отличная, и сам себя чувствую неплохим специалистом.
upd: насчет опыта немного врал, говорил что на яве писал на предыдущей работе, по этой же причине замкнутого круга — на работу не берут из-за отсутствия опыта, опыт отсутствует потому что не берут, этой ложью я круг разорвал. Возможно не очень этично, но оно сработало, тем более что свои обязанности я на работе исполнял вполне добросовестно.
Возраст помимо минусов дает и плюсы, и ими можно и нужно правильно распоряжаться.
Вкрячивание булевых параметров, которые кардинально меняют поведение функции — это такой кривой костыль, автор об этом. Само собой у любого эмпирического правила подразумевается разумный подход его исполнителя (в этом основные плюсы и минусы таких правил) Любое разумное правило можно довести до абсурда если его выполнять тупо и формально, не задумываясь о последствиях.
Если совет окажется правильным — то очень быстро будет забыт тот кто его дал и человек все лавры присвоит себе, если совет окажется негодным — у него всегда будет возможность сказать что это не он накосячил — а вот этот вот — насоветовал!