Конечно же это не хорошо. Если он решает поставленную задачу не уточняя ничего и потом споря о том, что он сделал как написано, а не так как надо, то ничего хорошего в этом нет.
А вот этим олимпиада от работы и отличатся. Вы можете бесконечно долго спорить с менеджером или заказчиком о том, что вы решали именно поставленную задачу, и, возможно, даже получите деньги за это, но на следующий заказ найдут другого исполнителя.
А где вы увидели, что на собеседовании проверяется "умение решать такие задачи"? На этом собеседовании проверили общие знания об алгоритмах и их сложности, умение задавать уточняющие вопросы, осознавать требования и способность подстраиваться под изменение требований. Ну и заодно посмотрели на то, как человек код оформляет.
Беда большинства кандидатов в том, что они не понимают в чем смысл собеседования. Они почему-то думают, что решение алгоритмических задач проверяет только умение решать алгоритмические задачи.
Полно разных статей написанных сотрудниками "компаний мечты" и даже на хабре попадались. Кому-то нравится, кому-то не очень. Не знаю, что вы имеете ввиду под "доказывать работодателю".
Иногда и такие попадаются. Но это как раз не имеет значения. Из решения такой задачи очень хорошо видно, как человек мыслит и как свои мысли излагает. И если он не в состоянии структуировать свой подход на элементарных задачах собеседования, то трудно ожидать, что он сможет это сделать потом на реальных задачах.
А на интервью не смотрят на "умение щёлкать алгоритмы". На интервью смотрят то, как вы берётесь за решение задачи, какие вопросы ставите, как код пишите, как тестируете...
на спринте выдают тикет, ты его делаешь, создаешь пул реквест, его ревьюят, мержат, тикет закрывают.
В моём понимании, вы описываете совсем уж зелёного junior. В нормальной ситуации разработчик сом создаёт тикеты ознакомившись с функцииональными требованиями, продумывает и обсуждает архитектуру и дизайн, выполняет ревью, задумывается на оптимизацией, организацией тестов и т.п.
Как можно ставить минусы за такой текст? Можете объяснить?
Вот вы сами чуть ниже пишете, что хотите знать авторов минусов потому что вам не важно, как человек отреагировал, а важно кто. Вот так и многие читатели оценивают не то, что вы пишите, а ваш профиль и ставят минус просто за тот факт, что вы написали ещё один комментарий. Такое вот реноме вы заработали. Да, конечно можно сказать, что это всё подлые тролли минусуют, но факт в том, что они далеко не всех подряд минусуют.
Вы хотя бы в Википедии посмотрите определения для "групп", "полугрупп", "колец" и т.п. чтобы совсем уж ерунду не писать и не вводить читателей в заблуждение.
Running a program means loading program binary image from secondary storage to main memory. Execution of program means it's running and consume CPU cycle.
Мы не можем найти хорошего разработчика». Учитывая что последние 3 года реклама курсов звучит из каждого утюга то потребности в специалистах вообще не должно быть
А какое отношение имеют курсы к "хорошим специалистам"? После курсов и плохим специалистом-то редко кому сразу удается стать.
мой акк в соцсети как познавательная штукенция для меня выгоднее. Де факто выгоднее, чем хабр.
За эту фразу глаз зацепился. Странно сравнивать хабр с фейсбуком. На фб личная страница - это личная страница. Комментирующие приходят к автору в гости и общаются с автором. Хабр устроен по другому. Комментарии под статьей - это не личное пространство автора статьи, а площадка для дискуссии. Целевой аудиторией комментаторов является не автор статьи, а все читатели. Поэтому для сообщества ценнее, если под статьей про особенности git комментаторы будут цепляется к правилам разбора CSV. Даже если автору это не нужно, это нужно другим читателям, чтобы они не повторяли ошибок автора. Естественно, что есть и люди, которые используют эту площадку для того, чтобы тем или иным образом "выделиться" (но опять же не в глазах автора, а для всей аудитории).
Ну это значит, что вы с плохими запросами на больших данных не сталкивались. Там никакое железо не спасает. А специалист, которого модно посадить и оптимизировать стоит в несколько раз больше, чем те горе разработики на зарплату которых пожлобились. Да ещё и для оптимизации после рекомендаций спеца потом полприложения тем же разработчикам придётся переписывать.
Мне кажется, что проблема из пальца высосана. По крайней мере без подтверждающей статистики никаких оснований верить в то, что авторы ушли из-за того, что их заклеивали - нет. Мне кажется, что есть много других причин, по которым авторы пишут одну статью и замолкают. Глобально можно разделить на две категории :
автор и так добился того, чего хотел (например, получил статус пользователя со статьей на Хабре или выплеснул свою проблему людям)
автор отчаялся получить то, что хотел (например, ожидал, что авторство на Хабре повысит авторитет среди коллег или как-то изменит самоощущение, а этого не случилось). Может быть для каких -то особо чувствовительных персонажей негативные комментарии и стали причиной ухода, но не думаю, что таких много.
Написать много однотипных select where и update where проблемы не составляет. А вот лечить приложение, которое умерло из-зв того, что ленивые разработчики положились на JPA и не потестировали его на реальных данных - это реальная проблема. И даже на один такой кривой запрос уходит намного больше сил и времени (к тому же высококвалифицированного), чем на написание сотни однотипных запросов.
Конечно же это не хорошо. Если он решает поставленную задачу не уточняя ничего и потом споря о том, что он сделал как написано, а не так как надо, то ничего хорошего в этом нет.
Я так понимаю, что статью вы до конца не дочитали. А там это как раз указано.
А вот этим олимпиада от работы и отличатся. Вы можете бесконечно долго спорить с менеджером или заказчиком о том, что вы решали именно поставленную задачу, и, возможно, даже получите деньги за это, но на следующий заказ найдут другого исполнителя.
А где вы увидели, что на собеседовании проверяется "умение решать такие задачи"? На этом собеседовании проверили общие знания об алгоритмах и их сложности, умение задавать уточняющие вопросы, осознавать требования и способность подстраиваться под изменение требований. Ну и заодно посмотрели на то, как человек код оформляет.
Беда большинства кандидатов в том, что они не понимают в чем смысл собеседования. Они почему-то думают, что решение алгоритмических задач проверяет только умение решать алгоритмические задачи.
А кому нужны кандидаты которые только с "верно поставленными задачами" работать способны?
Полно разных статей написанных сотрудниками "компаний мечты" и даже на хабре попадались. Кому-то нравится, кому-то не очень. Не знаю, что вы имеете ввиду под "доказывать работодателю".
Иногда и такие попадаются. Но это как раз не имеет значения.
Из решения такой задачи очень хорошо видно, как человек мыслит и как свои мысли излагает. И если он не в состоянии структуировать свой подход на элементарных задачах собеседования, то трудно ожидать, что он сможет это сделать потом на реальных задачах.
А на интервью не смотрят на "умение щёлкать алгоритмы". На интервью смотрят то, как вы берётесь за решение задачи, какие вопросы ставите, как код пишите, как тестируете...
Гарнец - это четверть ведра. Вполне на месте смотрится в одном ряду с другими числительными и мерами.
В моём понимании, вы описываете совсем уж зелёного junior. В нормальной ситуации разработчик сом создаёт тикеты ознакомившись с функцииональными требованиями, продумывает и обсуждает архитектуру и дизайн, выполняет ревью, задумывается на оптимизацией, организацией тестов и т.п.
Вот вы сами чуть ниже пишете, что хотите знать авторов минусов потому что вам не важно, как человек отреагировал, а важно кто. Вот так и многие читатели оценивают не то, что вы пишите, а ваш профиль и ставят минус просто за тот факт, что вы написали ещё один комментарий. Такое вот реноме вы заработали.
Да, конечно можно сказать, что это всё подлые тролли минусуют, но факт в том, что они далеко не всех подряд минусуют.
Вы хотя бы в Википедии посмотрите определения для "групп", "полугрупп", "колец" и т.п. чтобы совсем уж ерунду не писать и не вводить читателей в заблуждение.
Я встречал такое определение:
Да вы что. Царь-то хороший. Это бояре плохие.
А какое отношение имеют курсы к "хорошим специалистам"? После курсов и плохим специалистом-то редко кому сразу удается стать.
За эту фразу глаз зацепился. Странно сравнивать хабр с фейсбуком.
На фб личная страница - это личная страница. Комментирующие приходят к автору в гости и общаются с автором.
Хабр устроен по другому. Комментарии под статьей - это не личное пространство автора статьи, а площадка для дискуссии. Целевой аудиторией комментаторов является не автор статьи, а все читатели. Поэтому для сообщества ценнее, если под статьей про особенности git комментаторы будут цепляется к правилам разбора CSV. Даже если автору это не нужно, это нужно другим читателям, чтобы они не повторяли ошибок автора.
Естественно, что есть и люди, которые используют эту площадку для того, чтобы тем или иным образом "выделиться" (но опять же не в глазах автора, а для всей аудитории).
Ну это значит, что вы с плохими запросами на больших данных не сталкивались. Там никакое железо не спасает. А специалист, которого модно посадить и оптимизировать стоит в несколько раз больше, чем те горе разработики на зарплату которых пожлобились. Да ещё и для оптимизации после рекомендаций спеца потом полприложения тем же разработчикам придётся переписывать.
Мне кажется, что проблема из пальца высосана. По крайней мере без подтверждающей статистики никаких оснований верить в то, что авторы ушли из-за того, что их заклеивали - нет.
Мне кажется, что есть много других причин, по которым авторы пишут одну статью и замолкают. Глобально можно разделить на две категории :
автор и так добился того, чего хотел (например, получил статус пользователя со статьей на Хабре или выплеснул свою проблему людям)
автор отчаялся получить то, что хотел (например, ожидал, что авторство на Хабре повысит авторитет среди коллег или как-то изменит самоощущение, а этого не случилось). Может быть для каких -то особо чувствовительных персонажей негативные комментарии и стали причиной ухода, но не думаю, что таких много.
Написать много однотипных select where и update where проблемы не составляет. А вот лечить приложение, которое умерло из-зв того, что ленивые разработчики положились на JPA и не потестировали его на реальных данных - это реальная проблема. И даже на один такой кривой запрос уходит намного больше сил и времени (к тому же высококвалифицированного), чем на написание сотни однотипных запросов.