Это если головой думать. Если я был достаточно сообразителен, чтобы вычислить название компании по его письму-заманухе, наверное у меня будет достаточно сообразительности послать СВ напрямую компанейской хрюхе, если рекрутер мне не понравится. И чувак делал все, чтобы мне не понравится. 
Я, правда ему отплатил - сказав что до него у меня было еще трое. Он, бедный, чутли со стула не упал.
Это ты вопрос задаешь про плохого кодера и при этом сам понять не можешь, про что тебе люди пишут. Интересно получается
1 лайк
Команды, правда оформить их можно и как методы. Прямыми запросами сейчас мало что делается
В каком смысле мало?? 
Веб-приложение лезет в БД всегда прямым запросом, даже если используется фреймворк. Естественно , лезть должно безопасно, чтобы не вызвать injections .
Если какому-то приложению прикрутили костыли и дали этими костылями пользоваться, то это только юзерам, типа тех.поддержки и тестеров.
1 лайк
Приложение да. Естественно в конечном счете запрос улетает в бд в голом виде. Но разработчик, как правило, пользуется методами данного приложения и только в редких случаях пишет прямой запрос.
В каком смысле? Кто пишет эти методы? Не разработчик? 
Что такое реальный сектор?
У меня всегда первый вопрос, какая компания и как нанимает, если нет ответа вообще не продолжаю.
У многие крупных компаний первоначальный отбор на аутсорсе, так что напрямую тупо ни вакансий на сайте нет, ни тем более контактов, кому из сотни ХР отсылать.
В современных системах веб приложение коммуницирует с бэкэндом через какие-нибудь микросервисы, чтобы обеспечить унифицированный интерфейс для разных клиентов, например мобильных приложений или интеграции с другими платформами. Так чтобы веб морда напрямую лезла в базу, уже давно не видел, разве что в каких то легаси системах внутри компании к которым внешние пользователи не имеют доступа. ( И на которые как правило бюджет особо не выделяется)
1 лайк
Есть разница откуда он улетает в бд в голом виде: от клиента или от бэкэнда. Ещё раз повторюсь, в нормальном дизайне, где пользователь не является владельцем базы (как например в keepass) юзерский интерфейс не должен коммуницировать с базой напрямую.
1 лайк
заводы-параходы, пекарни, и т.д. Создающие конечный продукт, который можно пощупать руками.
Если это small или family business, то да, скорее всего, карьеру в такой компании на булшитинге не сделаешь, да и вообще не сделаешь.
Если что-то покрупнее, с ХР и корп культурой, то теже яйца только в профиль
1 лайк
Эти микросервисы пишутся разработчиками приложения. И даются для использования явно не тем кто имеет 15 лет опыта в программировании.
Вы путаете готовый фреймворк с тем, который надо писать самому.
1 лайк
Ты явно на заводе не работал. Даже с конвеера тебя попрут, если руки из задницы.
Где конвеер, и где карьера?
1 лайк
Я про это и говорю.
Разработчик написал фреймворк. Дальше с этим фреймворком работают уже другие разработчики, которые не просят этого разработчика написать прямой запрос к базе, а используют как правило конкретные классы для работы с бд, в которых есть уже готовые методы. И только в редких случаях пишутся прямые запросы.
Какая разница готовый фреймворк или самопальный? Даже если он самопальный (Вопрос зачем?), он должен придерживаться принципам solid, пишется набор сервисов, для коммуникации с юзер интерфейсом, компонент/ы с бизнес логикой и компонент для коммуникации с базой, в идеале на каких-нибудь prepared statements, и набор юзерских интерфейсов. Все отдельные компоненты, если конечно это не студик на коленке склепал, всё в одном классе/методе. Вообще в энтерпрайзе ожидается, что программисты будут пользоваться готовыми фреймворками, а не изобретать колесо, чтобы гарантировать стабильность, maintainability и безопасность приложения. И да, в готовом фреймворке, те же сервисы, воркфлоуы надо написать - это не магия какая-то, которая всё сама сделает.
Если разработчик , которому даны уже написанные кем-то методы, не понимает что стоит за этими методами и не может с ними разобраться если потребуется - это крайне низкий уровень. И о 15 лет в программировании ( о чем. пишет автор) и речи не может быть.
А уж непонимание что именно стоит за методами update и delete - это вообще за гранью.
1 лайк
Честно говоря с опытом 15 лет и нормальным карьерным развитием, разработчик должен уже другими вопросами заниматься. И только в США я столкнулся с тем, что ищут разработчиков с 10летним+ опытом на задачи, которые максимум должны бы решать миды, и все потому что такую задницу на говнокодили, что хрен разберёшься. Просто лес непролазный. Плюс, если это ещё и большая контора, да ещё и финансы, то хрен это всё ещё и изменишь/перепишешь не пройдя 7 кругов бюрократического ада.
В той отрасли, в которой я работаю (аэроспейс), крупные компании набирают либо через своих (штатных) рекрутеров либо напрямую. Не думаю, что Боинг или Нортроп будут заниматься такой клоунадой. А вот аутсорсные рекрутеры для стартапов - аж бегом.