LINUX.ORG.RU

Ответ на: комментарий от ox55ff

Учи алгоритмы. Нужны алгоритмы. Что под этим подразумевается?

Начинаешь с малого: с самых примитивных алгоритмов и структур данных (массив, односвязный список, двоичное дерево, хеш-таблица; сортировки, сложность алгоритма). Потом начинаешь узнавать про другие типы деревьев, читаешь, чем они отличаются, как используются и как реализуются. Потом читаешь про, например, lock-free алгоритмы. И так далее. В конечном итоге ты должен быть в состоянии из известного тебе множества алгоритмов выбрать наиболее подходящий для решения задачи. Не обязательно помнить их наизусть, но знать, чем, к примеру, быстрая сортировка отличается от сортировки слиянием, ты должен

XMs ★★★★★ ()
Ответ на: комментарий от next_time

в «серьезных фирмах» (ТМ) иногда безголово внедряют гит там, где всю жизнь был перфорс и это было нормально, потому что «стало модно в этом сезоне» — (например, в гите ужасно мержатся XML простынки метаданных, которые только и понимает одна широко известная облачная система при деплое :)) И потом спешно организуют внутренние курсы по гиту — и ПМ не верит «вон тому парню, который знает гит», что то к чему они привыкли в централизованной системе делается в децентрализованной по-другому — призывают «гуру гита»... который, под хруст попкорна, рассказывает ровно то же самое (и пара ссылок на атлассиан или хабр, откуда он узнал про гит). И на этом всьо :)

slackwarrior ★★★★★ ()
Ответ на: комментарий от knovich

Кстати, а что такое «разработка собственных паттернов»?

Был у нас один сеньор. Так он даблтон изобрёл, хотел ещё мультитон запилить, но его тимлид на кодревью зарезал.

Deleted ()
Ответ на: комментарий от Deleted

Критерии просты, джуниор может сделать маленькую фичу под присмотром, мидл может сделать среднюю фичу без присмотра, сеньор может сделать и сдать большую фичу.

anonymous ()
Ответ на: комментарий от anonymous

Не, ну консолью все равно надо уметь пользоваться

Да, в консоли автоматизируется рутина. Буквально на днях писал скрипт для простановки тегов. SmartGit блокирует интерфейс пока команда не завершится, поэтому выполнение подобных операций превращается в боль. Без скриптов никуда.

ox55ff ★★★ ()
Ответ на: комментарий от next_time

Я бы назал это умением пользоваться, а не «знанием». Это инструмент, знать в нём нужно ровно то, что требуется для выполнения задачи. Остальное при необходимости можно в мане почитать, или загулить, да.

WitcherGeralt ★★ ()
Последнее исправление: WitcherGeralt (всего исправлений: 1)

Вообще процесс отбора кандидатов улетает в другую вселенную. В итоге знания для успешного прохождения собеседования и знания для успешного выполнения задач на этой работе пересекаются лишь частично.

ox55ff ★★★ ()
Ответ на: комментарий от ox55ff

Для серьёзных людей это не проблема.

Как раз проблема. Превратят серьёзный инструмент в тыкву, а на него бизнес-процессы повязаны. И не откатишься и не форкнешь.

peregrine ★★★★★ ()

а потом приходишь работать, а там Ся разбавленные конструктором, деструктором и классом std::string. А за все остальное бьют на ревью по рукам;)

zudwa ()
Ответ на: комментарий от WitcherGeralt

эксель-программист

Разные люди работающие с big data смотрят на тебя с удивлением, т.к. exel довльно удобный инструмент для работы с тестовыми выборками, прежде чем бежать писать код.

peregrine ★★★★★ ()
Ответ на: комментарий от trex6

Стандарты - я бы сдвинул немного «вниз», т.е. знание C++11 вообще мало ценно сейчас, можно везде менять на 14, 14 на 17 и т.д.

Знание 14 и 17 как бы предполагает знание 11. Из 98 да, кое-что выкинули, хотя большая часть как была, так и осталась

annulen ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

Ну там по ссылке утверждается, что у синьора знание гита должно быть уровня не ниже экспертного. И я вот хз, где они таких синьоров нашли. Нормальный синьор код пишет, а не часами в гите ковыряется.

next_time ★★★★★ ()
Ответ на: комментарий от next_time

ну потому что основные каждодневные операции запоминаются, а всё прочее 99.9% времени тебе не требуется. а если вдруг надо - есть гугл или маны. учить наизусть весьма странный набор команд гита нет никакого смысла. у программиста есть куча других, более важных задач.

Iron_Bug ★★★★ ()

имхо, сей документ - какая-то вкусовщина. очень своеобразное понимание требований к программисту. причём программирование, по их мнению, сводится к работе в IDE, что как-то сразу напрягает. обычно такие вещи составляют люди, которые имеют поверхностные знания в программировании.

вообще, программистов в вакууме не бывает. под каждую задачу есть довольно узкая специализация и область применения. программист обычно знает какие-то конкретные области применения, а языки программирования - это просто инструмент. конечно, хорошо, если кандидат знает основные паттерны. но даже паттерны привязаны к области применения, чаще всего: есть паттерны для хардварного программирования, паттерны для риалтайма, паттерны для сетей, паттерны для всякого гуеписательства и т.д. универсальных писателей кода для всего и сразу просто не существует. так что нельзя взять и просто создать универсальную таблицу «требований к программисту». это слишком абстрактная задача.

Iron_Bug ★★★★ ()
Ответ на: комментарий от Iron_Bug

под каждую задачу есть довольно узкая специализация и область применения.

Чем дальше, тем больше прихожу к выводу, что это — полная хрень в тапочках. Я за свою, пока ещё, не такую долгую карьеру успел поработать в геймдеве (игровую физику делал, на C++ и немного на C, а также чуть-чуть гуй на Flash), антивирусах (в том числе на уровне виндовых драйверов — опять C++ и немного C, плюс немного тулзов на Haskell), позаниматься распределёнными вычислениями (на Эрланге и чуть-чуть на C), а сейчас пишу вебню (бэкенд, на Scala и чуть-чуть на JS) и потихоньку тимлидю. И, доложу я вам, хорошие программисты — они везде хорошие программисты, а которые не везде хорошие — они нигде не хорошие.

Miguel ★★★★★ ()
Ответ на: комментарий от Miguel

при таких скачках обычно получается говнокод. это я по большому опыту наблюдений говорю. чем больше человек работает в какой-то области, тем более качественный код он выдаёт. и есть разница между нубом, которому дают мелкие задачки (в вашем случае скорее всего так и было) и программистом, который проектирует весь софт и раздаёт эти задачки нубам.

Iron_Bug ★★★★ ()
Ответ на: комментарий от Iron_Bug

нубом, которому дают мелкие задачки (в вашем случае скорее всего так и было)

В начале пути. Сейчас я, как уже сказал, потихоньку тимлидю. И да, участвую в проектировании.

это я по большому опыту наблюдений говорю

Видимо, вы имели дело исключительно с такими програмистами, которые «не везде хорошие».

Miguel ★★★★★ ()
Ответ на: комментарий от Miguel

тимлид может быть вообще не программистом. у нас в одной компании был замечательный тимлид. он был никакой программист (так, скрипты написать, не более), но он обеспечивал команду замечательными плюшками и поддерживал нормальный дух коллективизма в команде. это и есть основная задача тимлида. но на собеседования он приглашал меня, потому что он не был способен оценить программистские навыки человека, тут нужен был программист.

я видела очень много программистов. и прыжки из одной области в другую тоже иногда совершала. один такой прыжок был вынужденный. в стране тогда был кризис, нам 4 месяца не платили зарплату, а мой квартиросдатчик не хотел ждать лучших времён и денег требовал здесь и сейчас, поэтому мне пришлось резко менять работу. а так как резко работу подходящего профиля я не нашла бы, то мне пришлось временно устроиться в веб. в вебе тогда была какая-то движуха, в отличие от промышленного производства. это было самое неправильное решение в моей жизни, относительно работы. изучить пых было несложно, на это ушло две недели. но веб сам по себе имеет, как и все прочие области, свои паттерны, свои тонкости и стандартные решения. которых я, естественно, не знала. поэтому мне поначалу приходилось реально говнокодить, что мне решительно не нравилось. я отлично понимала, что моя писанина в сравнении с людьми, которые проработали фрилансерами лет по десять, была просто ничтожной. и мне было просто неприятно и стыдно за такой код, но моментальное изучение всего объёма такого материала было невозможно даже чисто физически. с другой стороны, я видела, что говнокодят там почти все, и от этого мне было ещё противнее. в итоге, я с радостью вернулась в ту область, в которой я могла нормально программировать и не ощущать неприязни к процессу.

и потом я совершила второй большой прыжок, но уже сознательно, предварительно потратив лет десять на подготовку: я перешла на Linux. я отбросила все свои достижения под маздаем (а я его знала вдоль и поперёк, от написания дров до сервисов, юзерских оснасток в консоли управления и прочего барахла) и начала практически с нуля под Linux. но тут я очень заранее начала готовиться, и только когда я поняла, что я действительно имею достаточный запас знаний и опыта, я перешла на программирование под Linux профессионально, в качестве основной работы. тут уже не было никаких проблем.

вообще, качественное освоение любой достаточно крупной области знаний (причём не только в программировании, но и в любой другой области вообще) требует в среднем десять лет. это такой средний срок на изучение языка программирования вроде плюсов, или изучения системного программирования, или веба, или даже изучения академического вокала. везде все до единого специалисты говорят именно про десять лет. это общее правило. всё, что меньше - это азы и поверхностные знания.

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от trex6

дело не в коде. дело в области его применения. код не существует в вакууме, он всегда решает конкретные задачи. и бОльшая часть знаний программиста - это та самая область применения. а язык программирования - этому и студентов учат. вот таблица у ТСа - как раз яркий пример студенческого подхода к пониманию программирования. но программирование - это не языки. и не «качество кода». это куда больше. человек должен знать очень много смежной специфической технической информации. и по сравнению с самим программированием это намного сложнее. но формального программирования не существует, вот в чём проблема. формальное программирование существует только на кафедрах в институтах. а любая реальная задача требует больше знаний, чем дают в институтах. и эти знания как раз и накапливаются с опытом работы.

я могу привести конкретный пример пользы опыта в области применения. когда я перешла с маздая под линь, там не было ничего общего, но мне пригодились мои знания элекроники, потому что все протоколы, вся работа железа под одной системой или под другой в сущности не изменились. точно так же не изменились, например, сетевые протоколы. и в переходе с сетевых приложений под одну систему на другую не было особых проблем, если знать все RTF-ы почти наизусть. с другой стороны, если их не знать вообще, то никакие стандарты плюсов не помогут. потому что область применения куда важнее стандартов.

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

тимлид может быть вообще не программистом

Может, а при чём тут?

вообще, качественное освоение любой достаточно крупной области знаний (причём не только в программировании, но и в любой другой области вообще) требует в среднем десять лет.

В среднем по больнице.

Miguel ★★★★★ ()
Ответ на: комментарий от Iron_Bug

когда я перешла с маздая под линь, там не было ничего общего,

и в переходе с сетевых приложений под одну систему на другую не было особых проблем

Так ничего общего, или никаких проблем с переходом?

А RFC-шки, к счастью, знать наизусть не надо, они все в интернете лежат.

Miguel ★★★★★ ()

Единственная польза таблицы с таким огромным числом градаций - это чтобы HR при очередной оценке мог доклепаться до какого-нить пункта и отказать в повышении зарплаты.

Alve ★★★★★ ()

Самый главный вопрос: таблица подтверждена какой-либо практикой? Например: взяли достаточную выборку программистов на с++ (около 1000 участников); прогнали по тестам вместо того, чтобы работу работать (1000*Х человекочасов на тестирование); увидели некоторую системность результатов тестов и решили запечатлеть в виде таблицы.

anonymous ()