Никто не мешает.
Не привлекает, увы. Никакие деньги не вернут мне 8 часов работы с идиотами.
В том и соль - когда человек на ровном месте заявляет, что данные не нужно обрабатывать в базе - а нужно вытягивать на бэкенд, не углубляясь в постановку задачи и граничные условия - хочется уточнить, бился ли этот человек головой о твердые предметы, и если да - госпитализировали ли его?
1 лайк
Подскажи, а со слабыми знаниями алгоритмов и структур вообще есть вакансии в Амазон, ради которых могли бы из РФ перевести по H1B/L1? Слабые знания - это пара книг (алгоритмы на Python и Cracking the Coding Interview) и задачки на Codility. 14 лет опыта PHP/JS, который можно приравнять к 5 годам в более менее нормальном офисе. Образование - 4 года колледжа по компьютерной специальности (не CS).
Смотрел вакансии на Амазоне, вроде есть такие. Но не уверен, что на эти вакансии кого-то повезут по H1B/L1.
Если это не вариант, подскажи пожалуйста, какие знания нужны для работы в Амазоне? Алгоритмы, структуры данных само собой буду прокачивать постепенно. Есть нормальный PHP, JS на четверку, Python базовый. Java буду учить, без него вообще никуда похоже. На что еще стоит обратить внимание? И что приоритетнее “прокачать”?
Не юлите и не передергивайте. Речь шла о конкретной ситуации, а вы кинулись в обобщение. А теперь пытаетесь оправдываться.
Я не знаю с кем вы разговариваете, я лично имел в виду
Если вам где-то как-то показалось, что кто-то попытался задеть ваш нежный внутренний мир - вам просто показалось. Просто сны.
Лучше, конечно, полное резюме посмотреть, тогда можно более детально разговаривать. Плюс, как я уже говорил, я SDE и собеседую SDE, не WDE - какая там кухня - не знаю. Все что ниже - про SDE, и там структуры данных и алгоритмы нужны, ибо это реально используется.
Вот это нужно понимать и уметь использовать. Плюс один из современных языков - C++/C#/Java/Go, желательно с опытом использования.
Про H1b - я не помню точно, что там по образованию требуется. Помню, что MS or (BS + 5 лет опыта), но вот насколько 4 года колледжа по компьютерной специальности подойдут под BS - хз, надо диплом смотреть. L1 - только через Индию/Китай скорее всего, в РФ у Амазона офисов нет (из ближайшего - Румыния).
В общем по H1b/L1 - перевозят SDE-II+, SDE-I только в составе команды. Хотя хз что будет, когда HQ2 откроют.
1 лайк
Довольно частая проблема со свежими выпусниками - они много знают алгоритмов, но простые вопросы могут поставить в тупик. Например - если нужно отсортировать массив из 10 элементов - какую сортировку использовать? Или “как найти K-е максимальное число в последовательности неизвестной длины”.
Их учат про quicksort/merge sort - но вот про insertion они не понимают. Не понимают часто про важность константы (та самая, которая не присутствует в big-O, но она есть). Знают про k-max, но не знают как можно без него.
Даже с rainfall не всегда справляются, несмотря на отскакивающие от зубов характеристики radix sort или 2-3 tree.
Снова юлите. Не оправдывайтесь.
Впрочем, спасибо и за то, что не начали вспоминать про кастрюли и сковородки как в соседней теме 
А в чём вообще цимус ломиться в Амазон, да ещё с таких скромных стартовых позиций?
В огромных корпорациях легко затеряться и жить припеваючи, особо не напрягаясь. Главное блюсти формат корпоративных гласных и негласных правил.
Денис Киряев, спасибо, очень полезно.
Много причин, многое не устраивает в мелких компаниях и стеке.
Например, тяжело доказать таким клиентам, что ты хоть чем-то лучше абсолютного новичка, даже если у тебя куча приложений за спиной и есть какие-то вещи, которые явно или неявно показывают твои знания и опыт. На Upwork на Laravel проект практически всегда наймут вордпрессовца за 30-40 баксов, нежели за 50 Laravel специалиста с лучшим портфолио на бирже. Тупость неимоверная, но это так работает, потому что практически все клиенты без технических знаний и они не нанимают специалистов для оценки знаний кандидатов.
Технические навыки вообще никто не проверяет. Тесты процентов 95% компаний не пишут. На хорошие практики всем наплевать, как и на поддерживаемый код. Каждый проект - это солянка из велосипедов и неправильных инструментов, которые были выбраны только потому, что разработчик хотел этот иструмент в резюме вписать. Чем выше растешь, тем больше это болото напрягает.
Другая причина - деньги. Да, “чистыми” в веб фрилансе теоретически можно получать примерно столько же, но, как я сказал выше, в подобных стеках никому качество не нужно и за него никто платить не хочет. В крупных компаниях с деньгами получше и потолок зарплат повыше.
Еще одна причина - это желание двигаться в сторону Software Engineer и расти дальше в компании. В небольших компаниях вырасти сложнее или вообще невозможно.
Следующая причина - крупные компании перевозят инженеров в США, пусть и не всех.
Почему именно Амазон? Я смотрю не только на Амазон, но у этой компании есть целые наборы интересных продуктов (AWS). На Ютюбе сотрудники хвалят компанию. Зарплаты неплохие.
Конечно, я могу ошибаться и любая крупная компания может оказаться по-своему болотом, но попробовать хочется.
И на счет “скромных стартовых позиций”. Это ведь зависит от того, с какой стороны посмотреть. Кто-то из разработчиков с открытым ртом смотрит на Топ-1 на SO, например. Кому-то вообще пофиг. В Laravel вчерашний выпускник c MS будет абсолютно бесполезен, а человек который впитал этот стек, выдаст результат, в десятки раз превосходящий тот, что выдаст выпускник. Точно также, выпускников с руками отрывают Гуглы и Амазоны, а ценность твоего Laravel на нуле. В общем, все зависит от того, с какой позиции смотреть на опыт.
И кто знает, может в отдельной крупной компании ценится реальный опыт с ООП/паттернами/ORM/Clean Code, набитые шишки и глубокое знание конкретного языка. Я не говорю про Software Engineer вакансии, там понятно, что база CS нужна.
В огромных корпорациях легко затеряться и жить припеваючи, особо не напрягаясь. Главное блюсти формат корпоративных гласных и негласных правил.
На счет “затеряться” - каждому свое. Проще ведь на фрилансе “затеряться”. Сидеть в трусах с бутылкой колы с теплой бабой и неплохо зарабатывать без поездок до офиса, бумажной волокиты, митингов, начальников и пр.
Уважаемый тёзка!
Из вашего пространного поста могу сделать только один вывод - вы никогда не работали не только в огромной корпорации, но даже в относительно крупной компании. Слишком оптимистично смотрите на ситуацию. Но это ваше право.
На всякий случай ознакомьтесь с довольно свежей статьей на эту тему, может быть она окажется полезной, хотя не все так однозначно
В Гугле не работал, хз что там на самом деле с промоушенами, но у этого чувака менеджер - редкостный мудак. Вот это вот, что менеджер не участвует в промоушене - полный BS, он как минимум должен был помочь документ отполировать, ну и бардака с проектами избежать по-максимуму.
А еще там какая-то детская обида сквозит, и походу, человеку больно дается осознание простого факта - nothing personal, just business. Уж сколько я это твержу программистам, а каждый раз это открытие - вы работаете за деньги, не за идею. Бизнес нанимает вас, чтобы вы помогли достичь целей этого бизнеса, а он за это вам платит деньги, и чем лучше вы помогаете бизнесу достигать его целей, тем больше денег он будет вам платить. Поэтому важно знать и понимать эти самые цели. Ибо чистый код, автотесты, красивая архитектура, scalability и прочий availability нахрен сам по себе никому не нужен - это все ваши, как инженера, инструменты для достижения целей, и вы должны уметь их комбинировать и выбирать необходимые под конкретные задачи. А у бизнеса цели могут быть как выйти на рынок раньше всех (и тогда скорость важнее качества кода, как бы это ни было печально для инженеров), так и придавить конкурентов качеством (а теперь все наоборот). Был я когда-то молодой да горячий, и работал в компании, где основатель и директор - выпускник того же факультета, что и я, лет на 10 старше, и вот он с усталостью в голосе (зная бесполезность попыток) пытался нас, безбашных, образумить, втолковать это. Эххх… В общем, как просветление наступит, так карьера и пойдет. У кого-то оно случается быстро, а кому-то и целой жизни не хватает.
Присоединюсь к предыдущему оратору - у меня сейчас команда из молодых и очень перспективных программистов-датасайенс. И вот они поголовно не видят за деревьями леса - один ушел в себя чтобы оптимизировать какую-то свою фигню для работы не за 30 минут, а за 25. То, что остальные компоненты трубы отрабатывают за часы (а все в куче - сутки) - его мало интересует. У него там задачка на какие-то кривые, он это знает, любит и умеет. Но вот бизнесу надо чтобы мы могли быстро взять новые данные от клиента и запихнуть в репорт - а это скучно, там надо буквально писать sed/awk и прочие штуки, которые в замках из слоновой кости не ценятся.
Так и живем.
Ох не надо соль на рану… За
for (T key : someMap.keySet()) {
value = someMap.get(key);
…
}
скоро буду с истерическим хохотом расстреливать…
Это классика, я такое проходил в середине 2000-х. Почему-то народу невдомек, что помимо алгоритмов было бы еще неплохо посмотреть в банальный API documentation, чтобы узнать что вместо someMap.get можно сделать entrySet. В случае скалы или питона - можно только горестно вздыхать, глядя на код модели с копипастой одного и того же метода в 13 разных местах.
В целом я делаю разделение между CS/DS и SD, для SD нужно понимать отличие ArrayList от LinkedList, но знать про балансировку AVL-tree необязательно. Но критично уметь делать декомпозицию системы, понимать SOLID (в случае с СУБД - ACID, а если у нас распределено все - то CAP theorem), писать код который можно протестировать и не умереть.
CS/DS же пусть занимаются своими алгоритмами, к написанию кода их допускать нельзя.
Кто с кем это сейчас разговаривает?
Именно так!
Но какой вывод напрашивается из ваших верных слов?
Программирование, как отрасль, довольно молода, и сейчас находится на раннем промышленном развитии по аналогии с промышленной революцией конца 19-начала 20 веков. Еще три десятилетия назад большинство программистов были что-то вроде ремесленников. Каждый из них, в одиночку, мог создать продукт от идеи и алгоритмирования до финального тестирования. Конечно, и тогда работали команды, но это не было нынешней “конвейерной системой” в хорошем смысле этого термина.
Лично я входил в программирование в начале 90-х, начинал с ассемблера под DOS. Когда раздумывал поехать работать в Германию, то потенциальному работодателю вместо резюме просто отправил свою программу на ассемблере, тренажер азбуки Морзе с псевдографическим интерфейсом. При этом, exe-файл был размеров всего в 8 кбайт (не опечатка, именно кбайт). Через два дня получил оффер, но по семейным обстоятельствам так и не смог им воспользоваться.
Сейчас в крупные компании, выпускающие софт индустриальными методами, такой подход не требуется. Нужны работяги на конвейер, кодеры “индусы”.
Но вот вопрос, зачем такому кодеру знать паттерны проектирования, различные алгоритмы и т.п.? Кодер != инженер. Скорее, техник, котрый должен более-менее квалифицированно реализовывать задачи, точно сформулированные инженером.
Но и инженеру нет надобности помнить наизусть все паттерны и алгоритмы. Он должен знать и уметь найти подробности в справочнике. Задача инженера не зубрить, но думать.
Заседание сэров с моноклями в курительной комнате объявляю открытым!
Радуйтесь что не переписывают написанное предшественниками.