Так в реальной работе мы тоже в основном пазлы собираем, просто кусочков больше, и грани описаны в документации и/или в подсказках IDE. На мой взгляд, быстрый результат очень хорошо помогает завлечь, а это первое что нужно от первого "языка". Другое дело, что тут не нужно долго задерживаться.
Пусть я окажусь в меньшинстве, но по-моему правильный путь должен быть похож на Scratch, Pascal, C. Очень обзорно, буквально пощупать, понять как работают массивы, структуры, функции и указатели. А дальше уже смотреть, что нравится человеку, главное донести акцент, что в итоге большую часть времени человек будет код читать и пытаться в нем разобраться, а не писать.
При этом требования к скорости разработки обычно исключают возможность освоения чего-то, что никак не пересекается с навыками кандидата. Впрочем, разумеется, зависит от позиции. Наверное, до мидла включительно, вы более правы.
Ну кажется и да, и всё-таки нет. Если этот навык прилагается к другим, актуальным, то это не просто плюс, это вау. А если этот навык единственный, то ну... Как-то такое себе.
Всё так, ты берешь на себя ответственность, что всё взлетит, если это вообще может взлететь. Но сроки, само собой, имеют право стать более резиновыми (кстати, в обе стороны, т.к. чаще всего оказывается, что для достижения цели нужно намного меньше работы, чем было бы по ТЗ).
На мой взгляд немного не так. Чётко поставленная задача зачастую требует действительно колоссальных усилий и траты времени. Мне лично больше импонирует формат, в котором ставящий задачу объясняет цель и предлагает идеи для её декомпозиции, а исполнитель имеет пространство для конечных решений и возможности для диалога. Но да, это подходит не в любых условиях и не с любыми людьми.
Да отличная статья, иногда в рамках развлечения нравится выдавить пару тактов в какой-нибудь литкодной задачке, и уверен, что найду применение прочитанному.
В груви это приводит к огромному числу внезапностей и неожиданностей. Например, что будет если положить в HashMap в качестве ключа GString, а искать String?
Исходники протокола недостаточны (а точнее бесполезны). Слать кому нужно что нужно можно и в рамках протокола, даже имея сквозное шифрование, если клиентское приложение подконтрольно. Например, отправлять на другой сервер данные без шифрования) или в рамках зашифрованных сообщений манипулировать размерами пакетов/задержками.
Если всё под синхронизацией, то volatile не нужен, видимость и так корректна при всех вариациях и реордерингах.
Но весь этот подход избыточен: загрузка классов сама по себе ленива (и потокобезопасна). Достаточно не иметь других статических методов и полей в классе, и всё будет хорошо, просто и понятно: static final Singleton INSTANCE = new Singleton();
У меня было так, что собеседующий в Гугле не знал языка, но это вообще не было проблемой, он просто поинтересовался сложностью конкретной операции в конкретной коллекции моего кода, я в двух словах пояснил сложность, почему она такая, как она устроена, и какие бывают альтернативы, он быстро сверился с документацией и никаких проблем.
Вообще об алгоритмических собеседованиях в Гугле только самые теплые чувства, в отличие от Яндекса. Потому что дело не в задачах, а в интервьюере. Сами алгоритмы по большей части проверяют не твои навыки, а твою мотивацию потратить пару дней (недель) на подготовку, потому что при наличии подготовки любой опытный инженер порешает литкодные задачки без особых сложностей, особенно, если они идут через усложнение от простого.
Некоторые инженеры отлично решают задачки и без подготовки - ну ок, тоже неплохо)
Будут ли эти навыки использованы на работе? Ну только если делать что-то проактивно, что в целом весьма поощряется в Гугле, и когда-то поощрялось в Яндексе (теперь всё вымыто напрочь голзами и беспощадными ревью, где нужно найти причину (не)дать бабло).
Если я ничего не путаю, вы утверждали, что вакансий за 20-30к достаточно? Но да, в тех компаниях, в которых работал я, есть возможность выбирать из сотни джунов, и приоритет будет у тех, кого мы сами обучали в рамках наших образовательных проектов, на которых фильтр и на входе, и на выходе.
Я тоже не разделяю хайпа вокруг "войти в айти", но если вы всё же решились на это, то скорее всего, придётся пройти тот же путь, что и большинству остальных людей.
Моя первая зарплата была что-то в районе 24к рублей на галере (которой я благодарен за опыт). И это при том что у меня не было приставки "Джуниор", потому как к моменту первой работы некоммерческого опыта у меня было лет 8.
Этот этап гребли за околобесплатно иногда обойти получается, но далеко не у всех.
Так в реальной работе мы тоже в основном пазлы собираем, просто кусочков больше, и грани описаны в документации и/или в подсказках IDE. На мой взгляд, быстрый результат очень хорошо помогает завлечь, а это первое что нужно от первого "языка". Другое дело, что тут не нужно долго задерживаться.
Пусть я окажусь в меньшинстве, но по-моему правильный путь должен быть похож на Scratch, Pascal, C. Очень обзорно, буквально пощупать, понять как работают массивы, структуры, функции и указатели. А дальше уже смотреть, что нравится человеку, главное донести акцент, что в итоге большую часть времени человек будет код читать и пытаться в нем разобраться, а не писать.
Одно другому вообще никак не мешает, скорее даже наоборот.
Очень большая куча кала)
При этом требования к скорости разработки обычно исключают возможность освоения чего-то, что никак не пересекается с навыками кандидата. Впрочем, разумеется, зависит от позиции. Наверное, до мидла включительно, вы более правы.
Ну кажется и да, и всё-таки нет. Если этот навык прилагается к другим, актуальным, то это не просто плюс, это вау. А если этот навык единственный, то ну... Как-то такое себе.
По секрету скажу, что есть и следующий уровень, на котором 80% времени человек сам знает, что сейчас ему стоит делать.
Всё так, ты берешь на себя ответственность, что всё взлетит, если это вообще может взлететь. Но сроки, само собой, имеют право стать более резиновыми (кстати, в обе стороны, т.к. чаще всего оказывается, что для достижения цели нужно намного меньше работы, чем было бы по ТЗ).
На мой взгляд немного не так. Чётко поставленная задача зачастую требует действительно колоссальных усилий и траты времени. Мне лично больше импонирует формат, в котором ставящий задачу объясняет цель и предлагает идеи для её декомпозиции, а исполнитель имеет пространство для конечных решений и возможности для диалога. Но да, это подходит не в любых условиях и не с любыми людьми.
Да отличная статья, иногда в рамках развлечения нравится выдавить пару тактов в какой-нибудь литкодной задачке, и уверен, что найду применение прочитанному.
В груви это приводит к огромному числу внезапностей и неожиданностей. Например, что будет если положить в HashMap в качестве ключа GString, а искать String?
В этом смысле явное точно лучше неявного.
Вот это уже достойно.
Исходники протокола недостаточны (а точнее бесполезны). Слать кому нужно что нужно можно и в рамках протокола, даже имея сквозное шифрование, если клиентское приложение подконтрольно. Например, отправлять на другой сервер данные без шифрования) или в рамках зашифрованных сообщений манипулировать размерами пакетов/задержками.
Парадокс дней рождения всё ещё понятным образом оценивается в зависимости от вероятности отдельного события.
Если всё под синхронизацией, то volatile не нужен, видимость и так корректна при всех вариациях и реордерингах.
Но весь этот подход избыточен: загрузка классов сама по себе ленива (и потокобезопасна). Достаточно не иметь других статических методов и полей в классе, и всё будет хорошо, просто и понятно: static final Singleton INSTANCE = new Singleton();
Буфер предсказания переходов не бесконечен, и существуют ситуации, когда производительность значительно деградирует из-за его переполнения.
Ну вообще уже давно пытаются переписать на Java, с переменным успехом.
Ну казалось бы современная наука в данном конкретном вопросе щёчки надувать перестала и очень активно чешет репу.
Ходят слухи, что команда таки не собирается останавливаться на достигнутом, и это может быть не последним дополнением.
У меня было так, что собеседующий в Гугле не знал языка, но это вообще не было проблемой, он просто поинтересовался сложностью конкретной операции в конкретной коллекции моего кода, я в двух словах пояснил сложность, почему она такая, как она устроена, и какие бывают альтернативы, он быстро сверился с документацией и никаких проблем.
Вообще об алгоритмических собеседованиях в Гугле только самые теплые чувства, в отличие от Яндекса. Потому что дело не в задачах, а в интервьюере. Сами алгоритмы по большей части проверяют не твои навыки, а твою мотивацию потратить пару дней (недель) на подготовку, потому что при наличии подготовки любой опытный инженер порешает литкодные задачки без особых сложностей, особенно, если они идут через усложнение от простого.
Некоторые инженеры отлично решают задачки и без подготовки - ну ок, тоже неплохо)
Будут ли эти навыки использованы на работе? Ну только если делать что-то проактивно, что в целом весьма поощряется в Гугле, и когда-то поощрялось в Яндексе (теперь всё вымыто напрочь голзами и беспощадными ревью, где нужно найти причину (не)дать бабло).
А самое главное, что все понимают, что "сделать ручкой" - самый эффективный путь для построения карьеры.
Если я ничего не путаю, вы утверждали, что вакансий за 20-30к достаточно? Но да, в тех компаниях, в которых работал я, есть возможность выбирать из сотни джунов, и приоритет будет у тех, кого мы сами обучали в рамках наших образовательных проектов, на которых фильтр и на входе, и на выходе.
Я тоже не разделяю хайпа вокруг "войти в айти", но если вы всё же решились на это, то скорее всего, придётся пройти тот же путь, что и большинству остальных людей.
Моя первая зарплата была что-то в районе 24к рублей на галере (которой я благодарен за опыт). И это при том что у меня не было приставки "Джуниор", потому как к моменту первой работы некоммерческого опыта у меня было лет 8.
Этот этап гребли за околобесплатно иногда обойти получается, но далеко не у всех.