Comments 205
Тут к гадалке не ходи, результат найма ясен. Я предпочитал давать на собеседовании реальные задачи из реального проекта — написать тест в существующий проект, создать микропроект на час-два работы с наблюдением за процессом разработки.
В чем соль: ответы на шаблонные вопросы легко можно выучить походив по собеседованиям, а вот как ты пишешь новый код или разбираешься в существующем — тут уже не слукавишь…
В чем соль: ответы на шаблонные вопросы легко можно выучить походив по собеседованиям, а вот как ты пишешь новый код или разбираешься в существующем — тут уже не слукавишь…
Ну и конечно же практика никак не отменяет теорвопросы по ООП, шаблонам, языку программирования и технологиям из проекта ( не обязательно все знать, но быстро учиться и умение искать ответ самостоятельно — must have). Это только аспекты техскрининга при найме. Еще много важных вещей при подборе команды разработки за пределами программирования!
Только если это используется в проекте.
А то собеседующие корчат из себя на собеседования непойми что, первый раз видя вопросы и ответы на них. :)
А то собеседующие корчат из себя на собеседования непойми что, первый раз видя вопросы и ответы на них. :)
Меня раньше часто спрашивали про паттерны, но я так и не понял зачем. Ну ладно синглтон, фасад, адаптер, итератор. Деократоров я не писал ни разу, прокси тоже. Комманд? Это о чём вообще? Билдер? Ну… обычно я предпочитаю fluent аксессоры. В общем паттернов которые надо прямо знать — очень мало. И если даже человек их не знает — это говорит ровно ни о чём.
Когда кто-то применяет «из прикола» и по принципу паттерном код не испортишь, то получается overengineering. Проект который точно так же как и говнокод невозможно прочитать и сложно поддерживать, содержит избыточно абстракций. Как везде важен контекст — уместность и обоснованность применения.
Просто знание паттернов может быть общим языком между коллегами и помощником в работе при создании нового функционала.
Просто знание паттернов может быть общим языком между коллегами и помощником в работе при создании нового функционала.
Основная польза знания паттернов — общий язык для разработчиков, ИМХО. Т. к., даже их не зная, рано или поздно приходишь к их использованию в тех задачах, для которых они предназначены.
А также паттерн стоит спрашивать тогда, когда именно этот паттерн используется или собираются использовать в проекте…
Вы про паттерны, как про фреймворки рассуждаете… Или Вы реально их используете, только когда в описании задачи написано «вот тут используй паттерн Proxy, а вот тут Decorator»?
Хм.
Самому на работе не приходилось городить огород из паттернов, они уже готовые. Бери и используй.
А если начнешь выеживаться, выдумывать велосипед, то могут и вломить.
Но если это простейший CRUD, какие там нафиг паттерны.
Для большинства сайтов никакие дополнительные паттерны не нужно прикручивать: все реализовано в CMS/фреймворке.
KISS. Задачи нужно решать самыми простыми способами.
Паттерны нужно применять не потому, что ты такой не в рот программист, что другие тебя не поймут, а потому что это упрощает поддержку кода.
Да и многие используют паттерны, сами не осознавая это и что это называется каким-то крутым словом.
Применение паттерна — это больше компетенция архитектора.
У меня на прошлой работе тим-лид говорил: Так, еще подумаю, какие паттерны можно заюзать.
А в это время сортировка данных проводилась на приложении, а не в БД, а также HTML выводился через echo 'некоторый код таблицы'.
Самому на работе не приходилось городить огород из паттернов, они уже готовые. Бери и используй.
А если начнешь выеживаться, выдумывать велосипед, то могут и вломить.
Но если это простейший CRUD, какие там нафиг паттерны.
Для большинства сайтов никакие дополнительные паттерны не нужно прикручивать: все реализовано в CMS/фреймворке.
KISS. Задачи нужно решать самыми простыми способами.
Паттерны нужно применять не потому, что ты такой не в рот программист, что другие тебя не поймут, а потому что это упрощает поддержку кода.
Да и многие используют паттерны, сами не осознавая это и что это называется каким-то крутым словом.
Применение паттерна — это больше компетенция архитектора.
У меня на прошлой работе тим-лид говорил: Так, еще подумаю, какие паттерны можно заюзать.
А в это время сортировка данных проводилась на приложении, а не в БД, а также HTML выводился через echo 'некоторый код таблицы'.
Оригинал был недоступен, видимо, лишь временно. В данный момент он открывается.
Как раз больше всего бесит когда слишком сильно обращают внимание на математику при оценке навыков. Я черт побери всегда плавал в математике (в той самой углобленке теории графов и так далее), не потому что я тупой (хотя кто знает), а потому что никогда не считал нужным держать тысячи формул и методов в голове, так как если мне понадобиться решить задачу которая связана с какой то областью математики, то я все равно вспомню куда мне нужно копать и найду это в учебнике и гугле и решу проблему без необходимости помнить то как решать эту проблему досканально. За то все кто со мной обучался и прекрасно знал математику и конткретно щелкал все задачи и проблемы по вышмату, совершенно не могут программировать и создавать сложные системы, продумывать архитектуру проекта, и вылетают со своих мест работы достаточно быстро — потому что тот факт что ты смог забить себя формулами до отказа не делает тебя математиком или програмистом, это скорее ближе к гуманиторному подходу изучения, где знание равноценно навыку в большинстве случаев, но никак не в програмировании и вообще разработке ПО.
То, что Ваши сокурсники хорошо знали математику, еще не значит, что они ей хорошо владели. Вы правы: они могли забить в голову шаблонные решения и ими оперировать. Но шаг влево и у них начинается ступор, так как шаблонного решения в голове для такого расклада нет.
Но ведь есть и те, кто осознает математику и потом в программировании показывает выдающиеся результаты (именно там, где требуется математика. Ведь сейчас не во всем программировании углубленная математика нужна).
Как ни крути, но лучше, когда есть теорбаза. У меня вот была обычная вузовская математика, без углублений. Иногда при программировании возникают задачи, которые требуют знание комбинаторики, алгоритмов и прочего. Из-за отсутствия этих знаний на решение подобных задач у меня уходит на порядок больше времени.
Подход «если чего не знаю, быстро загуглю/прочту/изучу, я ж инженер» конечно работает. Но кто будет ждать, пока Вы разбираетесь с тем, что должно быть уже давно сделано?
Но ведь есть и те, кто осознает математику и потом в программировании показывает выдающиеся результаты (именно там, где требуется математика. Ведь сейчас не во всем программировании углубленная математика нужна).
Как ни крути, но лучше, когда есть теорбаза. У меня вот была обычная вузовская математика, без углублений. Иногда при программировании возникают задачи, которые требуют знание комбинаторики, алгоритмов и прочего. Из-за отсутствия этих знаний на решение подобных задач у меня уходит на порядок больше времени.
Подход «если чего не знаю, быстро загуглю/прочту/изучу, я ж инженер» конечно работает. Но кто будет ждать, пока Вы разбираетесь с тем, что должно быть уже давно сделано?
>Но кто будет ждать, пока Вы разбираетесь с тем, что должно быть уже давно сделано?
А где те, кто не хочет ждать, возьмут столько разработчиков которые все помнят и не ходят в гугл для обновления знаний по различным аспектам программирования, математики и всем что с этим связано?
Эти люди в курсе, что программирование (как и любые другие в общем-то направления деятельности человека), в целом не стоит на месте и развивается? Что появляются более эффективные решения уже решенных проблем?
Гуглинг как раз позволяет узнать об этом, в процессе обновления своих знаний.
Вопрос только в одном, если например разработчик каждый раз гуглит как сделать обычный цикл))
Но это крайний случай и с ним все понятно.
В целом, обновлять свои знания это правильно и полезно для компании.
А где те, кто не хочет ждать, возьмут столько разработчиков которые все помнят и не ходят в гугл для обновления знаний по различным аспектам программирования, математики и всем что с этим связано?
Эти люди в курсе, что программирование (как и любые другие в общем-то направления деятельности человека), в целом не стоит на месте и развивается? Что появляются более эффективные решения уже решенных проблем?
Гуглинг как раз позволяет узнать об этом, в процессе обновления своих знаний.
Вопрос только в одном, если например разработчик каждый раз гуглит как сделать обычный цикл))
Но это крайний случай и с ним все понятно.
В целом, обновлять свои знания это правильно и полезно для компании.
Чем больше человек знает, тем быстрее он находит решение. Я не говорю, что гуглинг это плохо, но все должно быть в меру. Одно дело, если человек знает свое дело и гуглит только для поиска нетривиальных проблем и новых подходов. Другое дело, если разработчик гуглит типичные задачи и базовые вещи.
В прошлом году работал с человеком, который по образованию был инженером-программистом. Грамотный и умный человек, но в вебе он был новичком. Он во всем мог разобраться без проблем, но из-за того, что ему нужно было сначала изучить, понять, разобраться, а потом сделать, на задачи у него уходило очень много времени. Его работу было тяжело прогнозировать и как-то планировать график разработки. Эта ситуация была похожа на ту, что описана в статье.
В прошлом году работал с человеком, который по образованию был инженером-программистом. Грамотный и умный человек, но в вебе он был новичком. Он во всем мог разобраться без проблем, но из-за того, что ему нужно было сначала изучить, понять, разобраться, а потом сделать, на задачи у него уходило очень много времени. Его работу было тяжело прогнозировать и как-то планировать график разработки. Эта ситуация была похожа на ту, что описана в статье.
Всё зависит от человека ешё, есть люди дотошные, есть быстрые, есть в меру.
Вот вам ярый пример, был курс углублённых графов. Есть теория, на которую нужно было выучить 45-46 определений слово в слово (не на русском и не английском), и собственно есть практики где учили считать и давали алгоритмы. Так вот, я зачёт программы по практике все на максимальный бал и последний проект (визуализацию топологической сортировки по шагам) тоже на высший бал. Защита проекта совершенно меня не пугала, так как в ходе реализации я разобрался с данным алгоритмом и был готов. Но зачёт я не получил. Так как выучить 45 определений слово в слово мне тяжело, рассказать своими словами могу, а вот слово в слово не могу. Но я это к чему, ребята которые смогли заучить и сдали лекции, очень плохо сдавали практики, так как заучить дело 1 а программировать совершенно другое, защитили они на 1\13, 4\13. И на минутку это магистратура на курсе программирования.
Вот вам ярый пример, был курс углублённых графов. Есть теория, на которую нужно было выучить 45-46 определений слово в слово (не на русском и не английском), и собственно есть практики где учили считать и давали алгоритмы. Так вот, я зачёт программы по практике все на максимальный бал и последний проект (визуализацию топологической сортировки по шагам) тоже на высший бал. Защита проекта совершенно меня не пугала, так как в ходе реализации я разобрался с данным алгоритмом и был готов. Но зачёт я не получил. Так как выучить 45 определений слово в слово мне тяжело, рассказать своими словами могу, а вот слово в слово не могу. Но я это к чему, ребята которые смогли заучить и сдали лекции, очень плохо сдавали практики, так как заучить дело 1 а программировать совершенно другое, защитили они на 1\13, 4\13. И на минутку это магистратура на курсе программирования.
прям как я в быдловузе
понял смысл ассемблера х86, хотя лет 15 не понимал его
стал усиленно кодить, мозги трещали по швам, потом ко мне стали обращаться одногруппники и я даже нашел ошибку в библиотеке препода и дал ему исправлять
в итоге зачет писали на бумажке в 2012 году, я ответил почти на все вопросы, код там написал какой-то, первый сдал и ушел
оказывается не сдал, а другие как-то сдали
понял смысл ассемблера х86, хотя лет 15 не понимал его
стал усиленно кодить, мозги трещали по швам, потом ко мне стали обращаться одногруппники и я даже нашел ошибку в библиотеке препода и дал ему исправлять
в итоге зачет писали на бумажке в 2012 году, я ответил почти на все вопросы, код там написал какой-то, первый сдал и ушел
оказывается не сдал, а другие как-то сдали
> слишком сильно обращают внимание на математику при оценке навыков
Смотря о какой математике идёт речь. Нарисовать алгоритм обхода графа (особенно, если его благополучно забыл с института), это замечательный тест, например. Я могу по своим наблюдениям сказать: человек, который выучил синтаксис языка программирования, какие-то библиотеки и фреймворки, и может отвечать на вопросы по ним, с равным успехом может быть и хорошим программистом, и плохим. Человек, который умеет сочинять алгоритмы и решать задачи, он практически всегда окажется хорошим программистом. Ну потому что выучить инструментарий, умея решать задачи, может каждый. А научиться решать задачи, владея инструментарием, уже дано далеко не каждому.
Смотря о какой математике идёт речь. Нарисовать алгоритм обхода графа (особенно, если его благополучно забыл с института), это замечательный тест, например. Я могу по своим наблюдениям сказать: человек, который выучил синтаксис языка программирования, какие-то библиотеки и фреймворки, и может отвечать на вопросы по ним, с равным успехом может быть и хорошим программистом, и плохим. Человек, который умеет сочинять алгоритмы и решать задачи, он практически всегда окажется хорошим программистом. Ну потому что выучить инструментарий, умея решать задачи, может каждый. А научиться решать задачи, владея инструментарием, уже дано далеко не каждому.
Человек, который умеет сочинять алгоритмы и решать задачи, он всегда будет хорошим программистом.
Может когда-нибудь и будет. Если научится. А может и не будет. Если не научится. Но сейчас, в данный момент, решать задачи и сочинять алгоритмы — этого недостаточно чтобы быть хорошим программистом. Поэтому сейчас, в данный момент, хорошим программистом он не является.
(Ну и вообще, тогда определение хорошего программиста в студию для начала).
> Может когда-нибудь и будет. Если научится. А может и не будет. Если не научится.
Это уже вопрос не фундаментальный, а вопрос мотивации. Если захочет — то обязательно научится, никаких других препятствий для этого нет. Человек, который во взрослом возрасте не умеет решать задачи, вполне вероятно, не научится этому уже при всём желании, т.к. для этого нужно иметь соответствующий образ мышления и длительную подготовку. Примерно как у спортсменов — с детства.
> Ну и вообще, тогда определение хорошего программиста в студию для начала
Я не думаю, что у вас могут быть какие-либо проблемы представить себе человека, который делает качественно и в срок свою работу. Независимо от его профессии.
Это уже вопрос не фундаментальный, а вопрос мотивации. Если захочет — то обязательно научится, никаких других препятствий для этого нет. Человек, который во взрослом возрасте не умеет решать задачи, вполне вероятно, не научится этому уже при всём желании, т.к. для этого нужно иметь соответствующий образ мышления и длительную подготовку. Примерно как у спортсменов — с детства.
> Ну и вообще, тогда определение хорошего программиста в студию для начала
Я не думаю, что у вас могут быть какие-либо проблемы представить себе человека, который делает качественно и в срок свою работу. Независимо от его профессии.
Это уже вопрос не фундаментальный, а вопрос мотивации.
Вопрос мотивации самый фундаментальный вопрос с сотрудниками.
Я не думаю, что у вас могут быть какие-либо проблемы представить себе человека, который делает качественно и в срок свою работу. Независимо от его профессии.
Осталось понять, какое отношение это имеет к математике и алгоритмам.
> Вопрос мотивации самый фундаментальный вопрос с сотрудниками.
Вопросы мотивации, знаете ли, успешно решают намного чаще, чем вопросы подбора квалифицированных кадров.
> Осталось понять, какое отношение это имеет к математике и алгоритмам.
Ну я даже не знаю, как вам объяснить. Вот давайте попроще пример. Улавливаете связь между умением работать рубанком, и плотником, который делает качественную табуретку. Уловили? Теперь давайте чуть сложнее. Вот улавливаете связь между пониманием алгоритма обхода B-дерева, с пониманием хэш-таблиц и т.д, и с программистом, который это умеет применять в нужных местах, в противовес программисту, который использует там же динамический массив с последовательным перебором? Понимаете разницу между программистом, который для расширения динамического массива выделяет память по одному элементу по мере их поступления, и между программистом, который это делает крупными блоками? Кто из них лучше на собеседовании решит задачу на алгоритмы?
Вопросы мотивации, знаете ли, успешно решают намного чаще, чем вопросы подбора квалифицированных кадров.
> Осталось понять, какое отношение это имеет к математике и алгоритмам.
Ну я даже не знаю, как вам объяснить. Вот давайте попроще пример. Улавливаете связь между умением работать рубанком, и плотником, который делает качественную табуретку. Уловили? Теперь давайте чуть сложнее. Вот улавливаете связь между пониманием алгоритма обхода B-дерева, с пониманием хэш-таблиц и т.д, и с программистом, который это умеет применять в нужных местах, в противовес программисту, который использует там же динамический массив с последовательным перебором? Понимаете разницу между программистом, который для расширения динамического массива выделяет память по одному элементу по мере их поступления, и между программистом, который это делает крупными блоками? Кто из них лучше на собеседовании решит задачу на алгоритмы?
Вопросы мотивации, знаете ли, успешно решают намного чаще, чем вопросы подбора квалифицированных кадров.
Предположим, и?
Понимаете разницу между программистом, который для расширения динамического массива выделяет память по одному элементу по мере их поступления, и между программистом, который это делает крупными блоками?
А это кстати уже инженерный подход скорее, с математической точки зрения всё равно как выделять. По одному элементу даже более математично — логичнее, проще и стройнее алгоритм, абстрактнее. Правильный математик не будет блоками выделять.
Кто из них лучше на собеседовании решит задачу на алгоритмы?
Тот кто их знает и понимает, очевидно. А разработка ПО здесь причём?
> А это кстати уже инженерный подход скорее, с математической точки зрения всё равно как выделять.
Инженерный подход и математический — это крайне родственные вещи, оба они — следствия умения логически мыслить и решать задачи.
> Тот кто их знает и понимает, очевидно. А разработка ПО здесь причём?
Ну потому что программа, представьте себе, это и есть алгоритм. Точнее, алгоритм + данные, если цитировать классиков.
Поэтому уметь решать задачу на алгоритмы = уметь писать программы. Это эквивалентные понятия.
Инженерный подход и математический — это крайне родственные вещи, оба они — следствия умения логически мыслить и решать задачи.
> Тот кто их знает и понимает, очевидно. А разработка ПО здесь причём?
Ну потому что программа, представьте себе, это и есть алгоритм. Точнее, алгоритм + данные, если цитировать классиков.
Поэтому уметь решать задачу на алгоритмы = уметь писать программы. Это эквивалентные понятия.
Инженерный подход и математический — это крайне родственные вещи, оба они — следствия умения логически мыслить и решать задачи.
Умение логически мыслить и решать задачи стоит в основе и научного подхода, например. Значит ли это, что любой учёный хороший программист?
Ну и я вам только что привёл пример, где математический подход и инженерный дают в некотором смысле противоположные решения.
Ну потому что программа, представьте себе, это и есть алгоритм.
Ну и что? Кулинарные рецепты — тоже алгоритмы. Составители хороших рецептов — хорошие программисты?
Поэтому уметь решать задачу на алгоритмы = уметь писать программы. Это эквивалентные понятия
Мы вроде про разработку ПО говорили, а не про «писать программы» (что бы это ни значило).
Кулинарные рецепты — тоже алгоритмы.Кулинарные рецепты все сплошь на нечёткой логике. А большинство шагов вообще пропущены. Так что называть их алгоритмами — это перебор.
Смотря какие. В сетевом общепите, например, всё довольно чётко прописано и стандартизировано.
А можно пример?
Нет, у меня под рукой нету. Да и чаще всего это внутренние документы, интеллектуальная собственность компании, их так просто нельзя выкладывать. Возможно в интернете есть что-то, не знаю.
Есть такой сайт, как раз для тех, кому не нравятся кулинарные рецепты на нечёткой логике: http://www.cookingforengineers.com/
> Значит ли это, что любой учёный хороший программист?
Естественно, учёный, который умеет логически мыслить и решать задачи, тоже сможет работать программистом. При желании. Насчёт «любой», вы, когда писали это слово, мыслили не логически :) Разве тот факт, что человек работает в какой-то профессии, автоматически делает его специалистом?
> Ну и я вам только что привёл пример, где математический подход и инженерный дают
> в некотором смысле противоположные решения.
Одинаковые решения они там дадут. Вы просто зачем-то поставили разные целевые функции для вашего воображаемого инженера и для вашего воображаемого математика. Поставьте им одинаковые (обоим достичь максимального быстродействия, например), и результат у обоих будет одинаковый.
> Ну и что? Кулинарные рецепты — тоже алгоритмы. Составители хороших рецептов — хорошие программисты?
Скажите, вас устроит месячная зарплата в 10 долларов? Ведь 10 долларов — это тоже деньги, как и 10000 долларов, верно? Вот и с алгоритмами то же самое. Они бывают простыми, бывают сложными. Поверьте, теоретический кулинар, который способен сделать рецепт из сотни последовательных технологических операций, также сможет работать программистом. Если вы найдёте такого кулинара.
> Мы вроде про разработку ПО говорили, а не про «писать программы»
Да, извините, я забыл. «Писать программы» было принято лет двадцать назад. Сейчас это не программы, а программное обеспечение, и их не пишут, а разрабатывают. И не программисты, а девелоперы. Ну как, такой уровень понтов вам достаточен?
Естественно, учёный, который умеет логически мыслить и решать задачи, тоже сможет работать программистом. При желании. Насчёт «любой», вы, когда писали это слово, мыслили не логически :) Разве тот факт, что человек работает в какой-то профессии, автоматически делает его специалистом?
> Ну и я вам только что привёл пример, где математический подход и инженерный дают
> в некотором смысле противоположные решения.
Одинаковые решения они там дадут. Вы просто зачем-то поставили разные целевые функции для вашего воображаемого инженера и для вашего воображаемого математика. Поставьте им одинаковые (обоим достичь максимального быстродействия, например), и результат у обоих будет одинаковый.
> Ну и что? Кулинарные рецепты — тоже алгоритмы. Составители хороших рецептов — хорошие программисты?
Скажите, вас устроит месячная зарплата в 10 долларов? Ведь 10 долларов — это тоже деньги, как и 10000 долларов, верно? Вот и с алгоритмами то же самое. Они бывают простыми, бывают сложными. Поверьте, теоретический кулинар, который способен сделать рецепт из сотни последовательных технологических операций, также сможет работать программистом. Если вы найдёте такого кулинара.
> Мы вроде про разработку ПО говорили, а не про «писать программы»
Да, извините, я забыл. «Писать программы» было принято лет двадцать назад. Сейчас это не программы, а программное обеспечение, и их не пишут, а разрабатывают. И не программисты, а девелоперы. Ну как, такой уровень понтов вам достаточен?
Естественно, учёный, который умеет логически мыслить и решать задачи, тоже сможет работать программистом.
Как я и писал выше, возможно сможет, после определённого обучения, возможно довольно длительного. (А возможно скажет — да пошло оно всё, скобочки, хренобочки, мутатень одна, то есть — не сможет). Про что собственно и пост, вы его читали? Там же реальная ситуация описана, крик души.
Гуманитарные науки — тоже науки. Учёный-гуманитарий тоже сможет?
Насчёт «любой», вы, когда писали это слово, мыслили не логически :)
Это вы, когда это писали, мыслили нелогически ))
Я ведь ничего не утверждал, а просто задал вопрос. Вполне закономерный вопрос.
Одинаковые решения они там дадут.
Ну я как бы всё намекаю, что математик от инженера отличается, и оно, похоже, всё не намекается.
Да, извините, я забыл. «Писать программы» было принято лет двадцать назад.
Ах вот оно что. Вы считаете, что между «разработка ПО» и «писать программы» разница только в понтах. Ну тогда конечно. О чём мы вообще говорим.
Откройте классиков разработки ПО, к примеру — Фредерик Брукс «Мифический человеко-месяц» и Йен Соммервиль «Инженерия ПО» (пишу по памяти). Внимание вопрос — если
уметь решать задачу на алгоритмы = уметь писать программы. Это эквивалентные понятия
и, по вашему, «писать программы» эквивалентно «разработка ПО» минус понты, то как получается, что в приведённых книгах про алгоритмы практически ничего? Выходит там одни понты?
> Гуманитарные науки — тоже науки. Учёный-гуманитарий тоже сможет?
Ответ на это есть в моём предыдущем посте.
> Как я и писал выше, возможно сможет, после определённого обучения, возможно довольно длительного
> (А возможно скажет — да пошло оно всё, скобочки, хренобочки, мутатень одна, то есть — не сможет).
А к чему это вообще? Ни в статье, ни в моих комментариях не было предложения взять учёного и насильно заставить его превратиться в программиста. Речь шла о собеседовании человека, который уже пришёл к вам на вакансию программиста, чтобы работать программистом. И смысл моей позиции прост: если он умеет составлять алгоритмы, не вопрос, остальное действительно дело времени. Если не умеет, дальше можно не пробовать. Времени, кстати, не длительного. Уж поверьте, синтаксис Java учится за неделю, синтаксис С# с плюшками за две недели. А что касается библиотек/фреймворков, так их наизусть все равно никто не знает, помнят только какое-то основное подмножество в своей предметной области. А остальное гуглят, когда надо.
> то как получается, что в приведённых книгах про алгоритмы практически ничего?
А получается так потому, что вы в споре о работе программиста приводите в пример книги, написанные для проджект-менеджера. Вам бы Дональда Кнута почитать, он как раз для программистов пишет. Поверьте, там алгоритмов по самое нехочу.
Ответ на это есть в моём предыдущем посте.
> Как я и писал выше, возможно сможет, после определённого обучения, возможно довольно длительного
> (А возможно скажет — да пошло оно всё, скобочки, хренобочки, мутатень одна, то есть — не сможет).
А к чему это вообще? Ни в статье, ни в моих комментариях не было предложения взять учёного и насильно заставить его превратиться в программиста. Речь шла о собеседовании человека, который уже пришёл к вам на вакансию программиста, чтобы работать программистом. И смысл моей позиции прост: если он умеет составлять алгоритмы, не вопрос, остальное действительно дело времени. Если не умеет, дальше можно не пробовать. Времени, кстати, не длительного. Уж поверьте, синтаксис Java учится за неделю, синтаксис С# с плюшками за две недели. А что касается библиотек/фреймворков, так их наизусть все равно никто не знает, помнят только какое-то основное подмножество в своей предметной области. А остальное гуглят, когда надо.
> то как получается, что в приведённых книгах про алгоритмы практически ничего?
А получается так потому, что вы в споре о работе программиста приводите в пример книги, написанные для проджект-менеджера. Вам бы Дональда Кнута почитать, он как раз для программистов пишет. Поверьте, там алгоритмов по самое нехочу.
А что касается библиотек/фреймворков, так их наизусть все равно никто не знает, помнят только какое-то основное подмножество в своей предметной области. А остальное гуглят, когда надо.
Вот этим и отличается опытный программист от неопытного.
Алгоритмы — они общие. И не так уж и много алгоритмов надо знать. Знать про существование методов сортировки и их различия для фронтэнд разработчика, наверное, имеет смысл. Но вот алгоритмы на графах, аналитическая геометрия, кнут-моррис-пратт тот же ему нафик не сдалисью
А вот фреймворки везде свои. И зачастую эффективно может писать только программист, имевший несколько месяцев (а то и лет) опыта работы с фреймворков.
> Вот этим и отличается опытный программист от неопытного.
Это же как раз понятно. А вот по умению сочинять алгоритмы программист отличается от непрограммиста. Я не про их знание наизусть, а про умение их самостоятельно составлять или в нужном месте применять «библиотечные» алгоритмы.
Это же как раз понятно. А вот по умению сочинять алгоритмы программист отличается от непрограммиста. Я не про их знание наизусть, а про умение их самостоятельно составлять или в нужном месте применять «библиотечные» алгоритмы.
А вот фреймворки везде свои. И зачастую эффективно может писать только программист, имевший несколько месяцев (а то и лет) опыта работы с фреймворков.
А иногда эффективнее писать без фреймворков :)
А иногда эффективнее писать без фреймворков :)
Попробуйте попрограммируйте на C++ без STL и Boost, на C#, не используя ничего, кроме System. на JS, не используя вообще ничего.
Уточню:
Говорю о PHP, там куча разных расширений и без фреймворков. :)
Для фронтэнда JS хватает jQuery (это библиотека, а не фреймворк)
А это не Стандартная библиотека шаблонов?
https://ru.wikipedia.org/wiki/Стандартная_библиотека_шаблонов
Говорю о PHP, там куча разных расширений и без фреймворков. :)
Для фронтэнда JS хватает jQuery (это библиотека, а не фреймворк)
C++ без STL
А это не Стандартная библиотека шаблонов?
https://ru.wikipedia.org/wiki/Стандартная_библиотека_шаблонов
Стандарт языка не называет её «STL», так как эта библиотека стала неотъемлемой частью языка
> без STL и Boost
Это ж не фреймворки. Без фреймворков, это не означает, что и без библиотек. Там парадигма работы разная. С библиотекой работаешь в свободном режиме, это набор кубиков, из которых строишь нужную конструкцию. А фреймворк — это чья-то готовая конструкция, которую надо крутить, допиливать и настраивать, чтобы она делала нужные тебе вещи.
Кстати STL в С++ уже стала частью самого языка. И перетащила в себя многое из Boost.
Это ж не фреймворки. Без фреймворков, это не означает, что и без библиотек. Там парадигма работы разная. С библиотекой работаешь в свободном режиме, это набор кубиков, из которых строишь нужную конструкцию. А фреймворк — это чья-то готовая конструкция, которую надо крутить, допиливать и настраивать, чтобы она делала нужные тебе вещи.
Кстати STL в С++ уже стала частью самого языка. И перетащила в себя многое из Boost.
остальное действительно дело времени
Научиться составлять алгоритмы тоже для многих людей вопрос мотивации и времени. Не врождённая же это способность.
Уж поверьте, синтаксис Java учится за неделю
И разбирай потом эту лапшу с алгоритмами, плавали, знаем. Умение написать алгоритм и умение написать читаемый, идиоматический, расширяемый и удобно отлаживаемый реюзабельный код слабо связаны. Это требует конкретного опыта (а кое-что и на конкретном языке).
Ну вот в статье девушка пишет, что всё это осваивается не так быстро. Она хорошо алгоритмы создаёт и математикой владеет, а программировать — всё равно сложно. Хотя и старается. Живое же опровержение ваших слов.
написанные для проджект-менеджера
Эта книга окажет неоценимую поддержку студентам и аспирантам, изучающим дисциплину «Инженерия
программного обеспечения», а также будет полезна тем специалистам по программному обеспечению,
которые хотят познакомиться с новыми технологиями разработки ПО, такими, как спецификация
требований, архитектура распределенных структур или надежность программных систем.
И ведь ни слова о менеджерах.
Что у Брукса написано, можете сами нагуглить. Хотя она, конечно, больше на менеджеров ориентирована, чем Соммервиль.
В общем ладно, я вижу, что вы не понимаете разницы между «инженерией ПО» и «писать программы». Нет смысла продолжать. Рассказывать в чём разница мне не интересно.
А, да. Кнута я в своё время читал, спасибо.
> Научиться составлять алгоритмы тоже для многих людей вопрос мотивации и времени.
> Не врождённая же это способность.
Нет, не врождённая. Просто она, в отличие от знаний Java, нифига не «учится» на третьем десятке лет.
> Умение написать алгоритм и умение написать читаемый, идиоматический, расширяемый и удобно отлаживаемый реюзабельный код слабо связаны.
Да вы что? А то тут раньше до вас все писали, что это одно и то же :)
Фишка в том, что для умения писать читаемый и так далее… код, вам нужно всего лишь поработать в команде с нормальной культурой разработки. Вы этому нигде в другом месте не научитесь, ни в институте, ни самостоятельно на пет-проектах (по крайней мере, если вы не гений самоорганизованности). Поэтому вы уже словоблудием занимаетесь. Предложите ещё сравнить умение составлять алгоритмы с трассировкой печатных плат, что ли. С чем вы там ещё не сравнивали.
> Ну вот в статье девушка пишет, что всё это осваивается не так быстро.
> Она хорошо алгоритмы создаёт и математикой владеет, а программировать — всё равно сложно.
> Живое же опровержение ваших слов.
Я не претендую на охват своим мнением всех семи с половиной миллиардов человек на Земле. Я описываю всего лишь свой опыт как работодателя на основании выборки из пары сотен собеседований, которые мне довелось проводить. И я считаю, что выборка достаточно репрезентативна, чтобы выработать более-менее эффективную стратегию собеседования. Эффективную в отношении большинства. Естественно, с какой-то вероятностью на ком-то вроде этой девушки она сработает неправильно. Но это же не страшно, верно?
>
написанные для проджект-менеджера
> Эта книга окажет неоценимую поддержку студентам и аспирантам
Ок, извините, для будущего проджект-менеджера, для системного архитектора и т.д. Программисты там каким боком?
> В общем ладно, я вижу, что вы не понимаете разницы между «инженерией ПО» и «писать программы».
Ээээ, а куда «разработка ПО» пропала? :)
Вы, конечно, разницу понимаете. Вот только плохо понимаете, кто чем должен заниматься в команде. Ваш «программист» должен быть и архитектором, и управленцем и на дудочке играть.
Нет, прочтение этих книг, конечно же, не повредит и обычному программисту. Для общего развития Но вот оно как раз не пригодится ему в начале карьеры.
> Не врождённая же это способность.
Нет, не врождённая. Просто она, в отличие от знаний Java, нифига не «учится» на третьем десятке лет.
> Умение написать алгоритм и умение написать читаемый, идиоматический, расширяемый и удобно отлаживаемый реюзабельный код слабо связаны.
Да вы что? А то тут раньше до вас все писали, что это одно и то же :)
Фишка в том, что для умения писать читаемый и так далее… код, вам нужно всего лишь поработать в команде с нормальной культурой разработки. Вы этому нигде в другом месте не научитесь, ни в институте, ни самостоятельно на пет-проектах (по крайней мере, если вы не гений самоорганизованности). Поэтому вы уже словоблудием занимаетесь. Предложите ещё сравнить умение составлять алгоритмы с трассировкой печатных плат, что ли. С чем вы там ещё не сравнивали.
> Ну вот в статье девушка пишет, что всё это осваивается не так быстро.
> Она хорошо алгоритмы создаёт и математикой владеет, а программировать — всё равно сложно.
> Живое же опровержение ваших слов.
Я не претендую на охват своим мнением всех семи с половиной миллиардов человек на Земле. Я описываю всего лишь свой опыт как работодателя на основании выборки из пары сотен собеседований, которые мне довелось проводить. И я считаю, что выборка достаточно репрезентативна, чтобы выработать более-менее эффективную стратегию собеседования. Эффективную в отношении большинства. Естественно, с какой-то вероятностью на ком-то вроде этой девушки она сработает неправильно. Но это же не страшно, верно?
>
написанные для проджект-менеджера
> Эта книга окажет неоценимую поддержку студентам и аспирантам
Ок, извините, для будущего проджект-менеджера, для системного архитектора и т.д. Программисты там каким боком?
> В общем ладно, я вижу, что вы не понимаете разницы между «инженерией ПО» и «писать программы».
Ээээ, а куда «разработка ПО» пропала? :)
Вы, конечно, разницу понимаете. Вот только плохо понимаете, кто чем должен заниматься в команде. Ваш «программист» должен быть и архитектором, и управленцем и на дудочке играть.
Нет, прочтение этих книг, конечно же, не повредит и обычному программисту. Для общего развития Но вот оно как раз не пригодится ему в начале карьеры.
Нет, не врождённая. Просто она, в отличие от знаний Java, нифига не «учится» на третьем десятке лет.
Я всё-таки склоняюсь к тому, что математические, логические и прочие способности являются врождёнными. Да и просто существование IQ не стоит, наверное, отрицать.
Умение писать красивый и понятный код — это опыт и культура, а не способности — тут я согласен.
Но вот что касается привлечения студентов на свои проекты:
троешники действительно неспособны решать сложные задачи, даже если программируют с горящими глазами; хорошисты — рабочие лошадки; отличники же быстро теряют интерес к рутинным задачам.
Просто она, в отличие от знаний Java, нифига не «учится» на третьем десятке лет.
На четвёртом десятке я полагаю. А какое это имеет отношение к разговору?
Да вы что? А то тут раньше до вас все писали, что это одно и то же :)
И что? Мне-то вы об этом зачем пишите?
всего лишь поработать в команде с нормальной культурой разработки
Да-да, нужно всего лишь научиться хорошо писать код, применять правильные инженерные практики и т.д. Это так просто, что людей, которые умеют, просто завались в профессии!
Вы этому нигде в другом месте не научитесь
Вот именно. Нужен опыт именно разработки, а не алгоритмов. У меня возникло ощущение, что вы возражаете не моим утверждениям, а каким-то другим.
Я описываю всего лишь свой опыт как работодателя на основании выборки из пары сотен собеседований, которые мне довелось проводить. / Но это же не страшно, верно?
Не вопрос, ваш опыт — это ваш опыт, ваши выводы — это ваши выводы. / Да, это не страшно.
Ок, извините, для будущего проджект-менеджера, для системного архитектора и т.д. Программисты там каким боком?
Лично я под современными программистами подразумеваю разработчиков ПО, они же специалисты в «Инженерии программного обеспечения», Software Engineers в общем. Про кого вы говорите — мне не очень понятно. Возможно про программистов, которые писали вычислительные алгоритмы на фортране 20 лет назад, не знаю. Или, может, тех, кто реализует какие-то вычислительные алгоритмы, обработка сигналов там, или нейросети, я не в курсе, как сейчас там дела обстоят.
Собственно эта книга как раз для программистов (= разработчиков ПО).
Ээээ, а куда «разработка ПО» пропала? :)
См. выше. В данном контексте я использую эти понятия как взаимозаменяемые.
Вы, конечно, разницу понимаете.
Более-менее
Вот только плохо понимаете, кто чем должен заниматься в команде. Ваш «программист» должен быть и архитектором, и управленцем и на дудочке играть.
Ну раз вы так говорите.
Нет, прочтение этих книг, конечно же, не повредит и обычному программисту. Для общего развития Но вот оно как раз не пригодится ему в начале карьеры.
Я не очень понимаю, что такое для вас «обычный программист». Видимо не кодер (кодеру нужно хорошо знать язык и платформу), не системщик, не архитектор, не тот, кто должен спроектировать модуль/приложение и написать, не тот, кто должен бизнес-логику положить на код, не бизнес-аналитик, не фронтэндщик/бэкэндщик, не синьёр, у которого много опыта и житейской мудрости. В общем непонятно кто. Полуфабрикат что ли? Из которого вы делаете кого вам нужно? Или математик-алгоритмист?
Я возражал вот этому утверждению (читайте выше):
Человек, который умеет сочинять алгоритмы и решать задачи, он всегда будет хорошим программистом.
Tолько после того, как хорошо освоит дистициплину «Инженерия ПО», примерный смысл которой и описан в книге Соммервиля. Потому что современная разработка ПО и есть эта инженерия ПО. Собственно в ВУЗах (и западных и наших) тем, кто учится на специальность Software Engineer/Программист, эту дисциплину читают.
Это если рассматривать обобщённо. Всегда бывают исключения, конечно.
В общем, дискуссия затянулась, и мне становится не интересно. Тем более что мы уже по кругу ходим. Что такое для вас хороший программист я уже спрашивал и вы, по большому счёту, не ответили. Поэтому дальше рассуждать, как выявить того, не знаю кого, довольно быссмысленно.
> А какое это имеет отношение к разговору?
Самое непосредственное. Вы уже, наверное, забыли, о чём речь была, да?
> Да-да, нужно всего лишь научиться хорошо писать код, применять правильные инженерные практики и т.д.
> Это так просто, что людей, которые умеют, просто завались в профессии!
В том-то и дело, что людей, которые не умеют, намного больше, чем которые умеют, и… представьте себе, софт пишется, продаётся и т.д. Как же они справляются, без этих важнейших навыков, приобретаемых годами? Может, необходимая для входа в профессию база всё-таки не настолько сложна, ась? Вы не задумывались над этим?
> Вот именно. Нужен опыт именно разработки, а не алгоритмов.
Нет, еще раз: опыт разработки можно взять и получить где угодно. Более того, вы этот самый опыт будете постоянно приобретать, менять, совершенствовать, старый отбрасывать и т.д. Поэтому ценность хранимого в багажнике вашего мозка опыта разработки, она так себе. Профессия программиста, она такая вот.
> данном контексте я использую эти понятия как взаимозаменяемые.
А, ну да, я с таким сталкивался. Я там «написание программ» тоже использую как взаимозаменяемое с «разработкой ПО».
> Я не очень понимаю, что такое для вас «обычный программист»
Да, я наверное недостаточно разжевал. Видите ли, проекты бывают разного уровня. Одни выполняются командой и требуют управления разработкой, другие делаются одиночками на коленке. Одни имеют сложный жизненный цикл, другие сдаются заказчику, и про них можно забыть. И т.д. Так вот, программисты, которые работают над простыми «одиночными» проектами, они действительно всё делают сами. Но им не требуются особые знания в Software Engineering. Программисты, которые работают в командах, имеют специализацию. А ещё там есть… не программисты, но связанные с разработкой профессии — бизнес-аналитики, системные аналитики, системные архитекторы, менеджеры проектов и т.д.
Так вот, в том самом «обобщении» программисты не касаются «Software Engineering». Они пишут код. А то, о чём вы талдычите, это более высокий уровень, это уже проектирование, системный анализ, организация управления командой и т.д. Да, тимлид вырастет из программиста. И ему нужно знать эту дисциплину. Но человек, который только входит в работу программиста, прекрасно без неё обойдётся.
> В общем, дискуссия затянулась, и мне становится не интересно
Но если вам не интересно, что же вам мешает мне просто не отвечать? То, что в интернете кто-то неправ? :)
Самое непосредственное. Вы уже, наверное, забыли, о чём речь была, да?
> Да-да, нужно всего лишь научиться хорошо писать код, применять правильные инженерные практики и т.д.
> Это так просто, что людей, которые умеют, просто завались в профессии!
В том-то и дело, что людей, которые не умеют, намного больше, чем которые умеют, и… представьте себе, софт пишется, продаётся и т.д. Как же они справляются, без этих важнейших навыков, приобретаемых годами? Может, необходимая для входа в профессию база всё-таки не настолько сложна, ась? Вы не задумывались над этим?
> Вот именно. Нужен опыт именно разработки, а не алгоритмов.
Нет, еще раз: опыт разработки можно взять и получить где угодно. Более того, вы этот самый опыт будете постоянно приобретать, менять, совершенствовать, старый отбрасывать и т.д. Поэтому ценность хранимого в багажнике вашего мозка опыта разработки, она так себе. Профессия программиста, она такая вот.
> данном контексте я использую эти понятия как взаимозаменяемые.
А, ну да, я с таким сталкивался. Я там «написание программ» тоже использую как взаимозаменяемое с «разработкой ПО».
> Я не очень понимаю, что такое для вас «обычный программист»
Да, я наверное недостаточно разжевал. Видите ли, проекты бывают разного уровня. Одни выполняются командой и требуют управления разработкой, другие делаются одиночками на коленке. Одни имеют сложный жизненный цикл, другие сдаются заказчику, и про них можно забыть. И т.д. Так вот, программисты, которые работают над простыми «одиночными» проектами, они действительно всё делают сами. Но им не требуются особые знания в Software Engineering. Программисты, которые работают в командах, имеют специализацию. А ещё там есть… не программисты, но связанные с разработкой профессии — бизнес-аналитики, системные аналитики, системные архитекторы, менеджеры проектов и т.д.
Так вот, в том самом «обобщении» программисты не касаются «Software Engineering». Они пишут код. А то, о чём вы талдычите, это более высокий уровень, это уже проектирование, системный анализ, организация управления командой и т.д. Да, тимлид вырастет из программиста. И ему нужно знать эту дисциплину. Но человек, который только входит в работу программиста, прекрасно без неё обойдётся.
> В общем, дискуссия затянулась, и мне становится не интересно
Но если вам не интересно, что же вам мешает мне просто не отвечать? То, что в интернете кто-то неправ? :)
Так вот, в том самом «обобщении» программисты не касаются «Software Engineering». Они пишут код.Ну вот теперь понятно. Вы про кодеров, которые не знают языка и платформу. Не понятно только, как такой кодер может быть «хорошим программистом», ну да ладно, не так важно.
Но если вам не интересно, что же вам мешает мне просто не отвечать?Ну я человек вежливый, стараюсь отвечать, пока есть возможность и пока собеседник адекватный.
То, что в интернете кто-то неправ? :)Не, это у меня давно за деньги. За переубеждение повышенный тариф, кстати.
А вас вот уже заносит, хамить начинаете:
вы уже словоблудием занимаетесь.
Да, я наверное недостаточно разжевал.
вы талдычите
Не надо так раздражаться, сохраняйте спокойствие. Подумаешь, ну написали вы разных глупостей, с каждым может быть. И со мной бывало.
В общем всего вам доброго, хорошего настроения и здоровья.
> Ну вот теперь понятно. Вы про кодеров, которые не знают языка и платформу.
Я про программистов, которые знают язык и платформу, но которым в силу профессиональных обязанностей не нужно знать про то, как организовать в коллективе Waterfall или Agile, не нужно думать, как сделать мотивацию разработчиков, не нужно знать, как собирать требования с заказчиков и т.д. Таких, как вы говорите «кодеров», в нашей профессии 99%. Но уж извините, не все могут быть Д'Артаньянами, кому-то и работать приходится.
> А вас вот уже заносит, хамить начинаете:
Вы первый начали :P
Я про программистов, которые знают язык и платформу, но которым в силу профессиональных обязанностей не нужно знать про то, как организовать в коллективе Waterfall или Agile, не нужно думать, как сделать мотивацию разработчиков, не нужно знать, как собирать требования с заказчиков и т.д. Таких, как вы говорите «кодеров», в нашей профессии 99%. Но уж извините, не все могут быть Д'Артаньянами, кому-то и работать приходится.
> А вас вот уже заносит, хамить начинаете:
Вы первый начали :P
Ничего себе, думал, что только я один такой вывод сделал :)
Надоело уже наблюдать, как сокурсники зазубривают формулы лишь бы только экзамены сдать. Через пол года спрашиваешь, что такое функция, а в ответ невнятный говор…
Также, я считаю, что по математике материал преподается отдельно от практики.(я не про мехмат). То есть даже нет объяснения того, как и где нам эти знания помогут в будущем. Задачки из задачника на этот вопрос уж точно не отвечают…
Надоело уже наблюдать, как сокурсники зазубривают формулы лишь бы только экзамены сдать. Через пол года спрашиваешь, что такое функция, а в ответ невнятный говор…
Также, я считаю, что по математике материал преподается отдельно от практики.(я не про мехмат). То есть даже нет объяснения того, как и где нам эти знания помогут в будущем. Задачки из задачника на этот вопрос уж точно не отвечают…
То есть даже нет объяснения того, как и где нам эти знания помогут в будущем.
Это все вузы такие в большинстве случаев такие (у нас в Украине). Напихают разного мусора в студента и получат денег из бюджета.
Но именно вышку нам хорошо преподавали. Да и в задачы обычно не абстрактные в вакууме были.
Интеграл — площадь чего-то, расстояние, количество (от времени).
Производная — скорость процесса, нахождение экстремумов.
Это еще из школы помню.
Транспортные задачи — логистика.
Меня не особо на собеседованиях спрашивали по алгоритмам вышки или другим разделам математики, которых я не изучал. Зачастую хватало смекалки.
UFO just landed and posted this here
Это от того зависит, что вы в «вышку» включаете.
Пофиг, что я включаю. :)
Высшую математику (2 семестра на первом курсе нам отлично преподавали)
Также хорошо математическое программирование, теория вероятности.
Какой физический смысл двойственной задачи?
Смысл более экономический:
http://elis.dvo.ru/~shamray/lp/lecture/econom_inter.pdf
Экономический смысл первой теоремы двойственности можно интерпретировать и так: предприятию безразлично, производить ли продукцию по оптимальному плану и получить максимальную прибыль либо продать ресурсы по оптимальным ценам и возместить от продажи равные ей минимальные затраты на ресурсы.
Экономический смысл двойственных оценок зависит от экономического содержания модели.
1. Целевая функция – продукция. Ограничение по ресурсу. Двойственная оценка vi есть предельная производительность i-го ресурса. Она показывает, насколько возрастет (сократится) продукция при добавлении (сокращении) i-го ресурса на единицу.
2. Целевая функция – издержки. Ограничения по минимально допустимому объему производства i-го продукта. Двойственная оценка vi есть предельные издержки производства i-го продукта. Она показывает во сколько обойдется производство дополнительной единицы i-го продукта.
с 2-мя остальными не сталкивался.
Не вся математика может применятся на данном этапе.
Много математики лежит в CDMA, сравнительно новой технологии.
Суть математики в институтах\школах\etc в том, чтобы люди научились думать. Если они этого не осознают, то начинается «забивание головы шаблонами», от которого уже трудно будет уйти в дальнейшем. Матан и правда хороший инструмент для приобретения навыков именно «думанья», но далеко не единственный…
И вправду, почему такие перекосы?
вообще обманом устроилась на работу
Скорее всего так оно и было. В вакансии, помимо указания знания алгоритмики, точно был указан ЯП и еще кучу всего. Она, не зная этой кучи и ЯП, пошла на собеседование, надеясь, что и так прокатит. И прокатывало. Конечно, виноваты компании, что плохо собеседовали, но обман-то с её стороны — ведь она делала вид, что знает ЯП.
А вот в моей практике все было по-другому. Мне никогда не давали алгоритмические задачи. Более того, даже тестовые задания дали только в 2-3 местах. Чаще это была проверка теории. Иногда давали небольшие задачки (5-6 строк кода) прямо на собеседовании.
Но здесь стоит внести дополнение: я собеседовался на PHP. Возможно поэтому требование более мягкие.
Но на днях мне все-таки дали алгоритмическую задачу перед собеседованием. Интересно то, что вакансия даже не на позицию программиста.
UFO just landed and posted this here
В вашем случае, ситуация все же иная. В требовании был С и за незнание Objective-C Вас бы никто не наказал, да и Вы бы не услышали слов про обман. Вина в данном случае полностью на плечах компании и к Вам у них никаких претензий быть не могло.
JavaScript, Java да даже J# — какая разница, правда?
Я знаю девушку, которая прошла тестовое задание на позицию Frontend Developer, в котором было чётко обозначено — решение должно быть на Javascript — на усмотрение исполнителя, хоть Angular, хоть jQuery, хоть Vanilla. Когда она его прошла и была принята на испытательный срок, оказалось, что в компании программируют на Java, а Javascript там авто-генерируемый продукт работы Java приложения. Ещё раз отмечу, что в тестовом задании не было упоминания про Java. Была часть задания «со звездой», включающая реализацию backend части, на любом языке и любом фреймворке, например на Laravel (PHP) или NodeJS.
Был вопрос о том, как её аккуратно уволить, не обидив :( Я был очень удивлён.
Был вопрос о том, как её аккуратно уволить, не обидив :( Я был очень удивлён.
Разница, конечно, есть. Но в идеале программист не должен сильно быть привязан к какому-то конкретному языку программирования. Опыт естественно набирается в основном на 2-3 языках, но это не блокирует возможность программировать на любом другом.
Изучить синтаксис другого языка и названия функций — не проблема. А вот разобрать окружение, особенности работы — это проблема.
Согласитесь, Java и JavaScript — это совершенно разные языки, которые работают на разных платформах, имеют свои особенности и доступные подходы. Перескочить для постоянной работы с одного языка на другой в данном случае будет не просто.
Согласитесь, Java и JavaScript — это совершенно разные языки, которые работают на разных платформах, имеют свои особенности и доступные подходы. Перескочить для постоянной работы с одного языка на другой в данном случае будет не просто.
Платформы разные. Но в принципе платформ ограниченное количество (и гораздо меньше, чем языков). Так что, при желании, хоть в какой-то мере можно с каждой ознакомиться… Но это конечно уже не про джуниоров, да и вообще холиварная тема вглубь vs вширь.
Языки разные. Скучный, вязкий и противный жестко статически типизированный Java и динамическое безумие JavaScript. Дело не только в платформе.
Языки разные знать надо… Нельзя себя только одним типом языков ограничивать, даже джуниорам. Есть общие критерии, по которым можно представить себе язык даже если ты его никогда раньше не видел:
- cлабая динамическая типизация, GC, OOP (prototype-based), HOF
- сильная статическая типизация, GC, OOP (class-based)
Если эти критерии сами по себе понятны, то от языка понадобится только синтаксис и стандартная библиотека. Для ещё более хорошего описания список критериев можно слегка расширить простыми пунктами типа: мутабельность данных, мономорфность операторов и т.п.
На любом другом?!
Если Вы не знакомы с ФП вообще, то программировать на ФП у Вас с ходу не получится. Если Вы вдруг незнакомы с ООП (маловероятно, но всё же), с ходу программировать с ООП у Вас так же не получится.
Программировать возможно на любом концептуально схожем языке. Я например, не зная Visual Basic — смог разобраться с программой на этом языке. Но хрен бы я так быстро разобрался с программой на Forth или на Erlang'е.
Если Вы не знакомы с ФП вообще, то программировать на ФП у Вас с ходу не получится. Если Вы вдруг незнакомы с ООП (маловероятно, но всё же), с ходу программировать с ООП у Вас так же не получится.
Программировать возможно на любом концептуально схожем языке. Я например, не зная Visual Basic — смог разобраться с программой на этом языке. Но хрен бы я так быстро разобрался с программой на Forth или на Erlang'е.
А где вариант — мне нравится язык А, и не нравится язык Б? И если я устраивался на работу на стек технологий А, то было бы неприятно требовать от меня в рабочем процессе осваивать стек Б. Нанимайте вторую позицию, в конце концов.
Backend, frontend — какая разница, end есть, а в остальном разберётся? Потом и появляются уродливые неповоротливые монстры, когда без опыта пытаются ваять на типа-похожем языке. Одно дело когда есть возможность изучить и потренироваться (и стать fullstack), но другое — «да чём там учить? Ща сделает и в прокашн зальём».
А это, кстати, во многом претензия к авторам этих языков.
Скорее всего так оно и было.
Скорее всего так не было. Потому что описание вакансии — это лишь предварительные пожелания к кандидату, не более того. Даже если что-то помечено в ней как «обязательное». Подходит кандидат или нет, решается на собеседованиях и других мероприятиях при приёме на работу. Потому что объявление о вакансии — это начальный этап переговоров. А в ходе переговоров позиции сторон имеют тенденцию меняться.
Так что если она не подделала документы и не солгала на собеседовании (и я думаю она этого не делала), то подобные обвинения, всего лишь обычные эмоциональные завывания или манипуляции и попытки переложить с больной головы на здоровую.
По моему опыту, собеседования в подавляющем большинстве компаний проводятся просто свехнепрофессионально. Ну, тут уж как умееют, чего там.
Потому что описание вакансии — это лишь предварительные пожелания к кандидату, не более того.
Кстати да.
У меня явно в резюме указано одно.
Мне приходит вакансия, где указаны совсем другие требования :)
Говорю: Я ж этого не знаю. А они: Та пох, выучишь. :)
А также часто в вакансиях указывают модные слова, которые на проекте не используются и не собираются :)
Скорее всего так оно и было. В вакансии, помимо указания знания алгоритмики, точно был указан ЯП и еще кучу всего.
Она год после универа. Откуда у нее будет 10 лет опыта? :)
Работодатель ССЗБ.
Ну если в задачи компании вход найм overqualified сотрудников, то пусть она этим и занимается.
Вообще говоря, задачи, где нужны подобные навыки, действительно существуют. Но таких задача — один на тысячу, остальные задачи — рутина, для которых подобные знания не нужны.
Вообще говоря, задачи, где нужны подобные навыки, действительно существуют. Но таких задача — один на тысячу, остальные задачи — рутина, для которых подобные знания не нужны.
Её же не на тимлида брали, а на какого-нибудь джуниора. А ему главное — не знание языка и платформы (чего у него нет, иначе устраивался бы уже на мидла), а сообразительность. Так что всё правильно её гоняли.
Так дело в том, что сообразительность в решение математических и околоматематических задач слабо коррелирует со способностью решать задачи программистские.
Странно это слышать от человека подписанного на: C++; Алгоритмы; Обработка изображений; Параллельное программирование.
Очевидно что если делаем формочку над базой данных, то не нужно. Если стоит задача обработки данных, то это уже необходимость.
Был у меня случай в жизни, работал в конторе по разработке систем мониторинга сетей передачи данных. Мой начальник, выпускник университета телекоммуникаций, запилил алгоритм со сложностью O(n^3). Когда мы развернули систему в Челябинске на небольшой подсети Ростелекома, то мы сели в лужу.
И каким же боком знание математики и демонстрация высоких аналитических способностей при решении головоломок связаны с пониманием О-нотации и умением прикинуть быстродействие алгоритма?
Вам ответили, каким боком:
https://habrahabr.ru/post/309424/#comment_9799596
https://habrahabr.ru/post/309424/#comment_9799596
Странно это слышать от человека подписанного на: C++; Алгоритмы; Обработка изображений; Параллельное программирование.
Почему странно? Лично мне эти знания мешают работать программистом: вместо того, чтобы просто писать код, постоянно придумываю в голове, а как же оптимальнее всего решать данную задачу (это негативно сказывается на сроках), иногда начинаю решать другие задачи, потому что они мне интересны. Собственно, поэтому я чистым программистом и не работаю.
И по своим наблюдениям: чем больше человек математик, тем больше его заносит в сторону от решения поставленной задачи.
«Лично мне эти знания мешают работать программистом: вместо того, чтобы просто писать код, постоянно придумываю в голове, а как же оптимальнее всего решать данную задачу (это негативно сказывается на сроках), иногда начинаю решать другие задачи, потому что они мне интересны. Собственно, поэтому я чистым программистом и не работаю.»
ты — это прям вылитый я
ну просто один в один, только я ничего не понимаю в матане и блевать тянет
как перестать заморачиваться над оптимизацией и просто начать писать код?
ты — это прям вылитый я
ну просто один в один, только я ничего не понимаю в матане и блевать тянет
как перестать заморачиваться над оптимизацией и просто начать писать код?
ты — это прям вылитый я
ну просто один в один, только я ничего не понимаю в матане и блевать
как перестать заморачиваться над оптимизацией и просто начать писать код? тянет
Вот у математиков эта тяга ещё более выражена, в клинических случаях вплоть до невозможности практического решения поставленной задачи.
как перестать заморачиваться над оптимизацией и просто начать писать код?
Я, когда есть несколько решений с разными временными расходами (и не только), спрашиваю тим-лида какое взять, указывая ± каждого.
Не далее как на прошлой неделе проходил собесед на лида в нидерландскую компанию. Собесед проводили украинский архитектор и русский менеджер, которые достаточно быстро перешли на русский и решение алгоритмических задач. Практически 0 вопросов про опыт, про подходы, про управление, про архитектуру. Полтора часа студенческих задач с оценкой сложности по памяти и скорости.
Собесед прошел. При приглашениии на второй этап помахал им ручкой, т.к работать там мне явно не хочется.
Это я к чему: есть подозрение, что это какая-то очень распространненая болезнь из стран бывшего СССР. Выборки нормальной у меня нет, но такие впечатления
Собесед прошел. При приглашениии на второй этап помахал им ручкой, т.к работать там мне явно не хочется.
Это я к чему: есть подозрение, что это какая-то очень распространненая болезнь из стран бывшего СССР. Выборки нормальной у меня нет, но такие впечатления
Это я к чему: есть подозрение, что это какая-то очень распространненая болезнь из стран бывшего СССР.
Девушка из штатов…
А тут оратор https://habrahabr.ru/post/309424/#comment_9799744
говорит, что оценка сложности — это никакая не математика. :)
Девушка-то из штатов, а собеседовали ее люди откуда?
Возможно это привязка не к стране, а к образованию, я хз
Иметь представление об оценки сложности и различиях между популярными алгоритмами / структурами данных нужно, иначе можно понаписать интересного кода. (был у меня опыт, когда аутсорсер вместого того, чтобы заюзать простейший словарь, бегал по массиву постоянно. На его 1-2-3 тестах все было классно, а у нас массив данных был в пару гб...).
Но решение алгоритмических задач уже чистая математика. Люди задающие задачи откуда-то из hackerrank автоматически идут лесом.
По своему опыту — тестовые задания гораздо показательнее, если они нормально задаются.
Возможно это привязка не к стране, а к образованию, я хз
Иметь представление об оценки сложности и различиях между популярными алгоритмами / структурами данных нужно, иначе можно понаписать интересного кода. (был у меня опыт, когда аутсорсер вместого того, чтобы заюзать простейший словарь, бегал по массиву постоянно. На его 1-2-3 тестах все было классно, а у нас массив данных был в пару гб...).
Но решение алгоритмических задач уже чистая математика. Люди задающие задачи откуда-то из hackerrank автоматически идут лесом.
По своему опыту — тестовые задания гораздо показательнее, если они нормально задаются.
Но решение алгоритмических задач уже чистая математика. Люди задающие задачи откуда-то из hackerrank автоматически идут лесом.
По своему опыту — тестовые задания гораздо показательнее, если они нормально задаются.
Большинство программистов просто выбирает из базы и сохраняет в базу.
Тут алгоритмы не нужны.
А на собеседовании нужно проверять то, с чем сталкивались сами, а не сферических коней.
Но когда что-то сложнее, математика скорее даст плюс, чем минус. Вы и сами пример привели. :)
кажется это какой-то уж очень кривой перевод какой-то левой статьи, написаной какой-то левой журналисткой. тему про интеврью можно было бы и получше раскрыть, чем читать вот это шило
А мне доводилось самому искать джуниора и собеседовать его по тех.части.
И практика показала, что научиться программировать — выучить операторы, ООП (на уровне «дать определение по учебнику»), — как раз таки намного проще, чем научиться абстрактному мышлению, которое необходимо, чтобы писать алгоритмы, решать задачи и проектировать архитектуру.
Вроде бы от джуниоров этого вначале никто и не ждёт, но хочется ведь рассчитывать на их рост в перспективе.
Т.е. задумка в том, что если соискатель не вполне продвинут в тонкостях работы с БД или плохо знает какой-то конкретный ЯП, но достаточно талантлив, чтобы всё это освоить в ближайшем будущем — это более хороший вариант, чем вызубренные базовые знания при отсутствии способностей к глубокому освоению сути происходящего.
Сейчас есть языки с очень низким порогом входа, и действительно много кандидатов, которые, никогда особо не разбираясь в естественных науках (прямо скажем — троечники), вдруг в свои 25-30 лет решили стать программистами.
Поэтому я как раз думаю, что лучше задавать вопросы и задачки, которые выявят способности к математике и абстрагированию, вместо проверки на знание встроенных классов или функций одного конкретного ЯП.
Шанс нарваться на математика, не способного выучить язык, совсем небольшой.
И практика показала, что научиться программировать — выучить операторы, ООП (на уровне «дать определение по учебнику»), — как раз таки намного проще, чем научиться абстрактному мышлению, которое необходимо, чтобы писать алгоритмы, решать задачи и проектировать архитектуру.
Вроде бы от джуниоров этого вначале никто и не ждёт, но хочется ведь рассчитывать на их рост в перспективе.
Т.е. задумка в том, что если соискатель не вполне продвинут в тонкостях работы с БД или плохо знает какой-то конкретный ЯП, но достаточно талантлив, чтобы всё это освоить в ближайшем будущем — это более хороший вариант, чем вызубренные базовые знания при отсутствии способностей к глубокому освоению сути происходящего.
Сейчас есть языки с очень низким порогом входа, и действительно много кандидатов, которые, никогда особо не разбираясь в естественных науках (прямо скажем — троечники), вдруг в свои 25-30 лет решили стать программистами.
Поэтому я как раз думаю, что лучше задавать вопросы и задачки, которые выявят способности к математике и абстрагированию, вместо проверки на знание встроенных классов или функций одного конкретного ЯП.
Шанс нарваться на математика, не способного выучить язык, совсем небольшой.
Вроде бы от джуниоров этого вначале никто и не ждёт, но хочется ведь рассчитывать на их рост в перспективе.
В многих компаниях, особенно крупных, рост джуниоров, наоборот, нежелателен. Потому что всегда есть задачи, которые требуют низкой квалификации.
Поэтому я как раз думаю, что лучше задавать вопросы и задачки, которые выявят способности к математике и абстрагированию, вместо проверки на знание встроенных классов или функций одного конкретного ЯП.
Вам шашечки или ехать? Сотрудник с хорошими математическими способностями, но слабой программистской базой, скорее всего, будет рассматривать такую компанию как перевалочный пункт. Набравшись опыта, он просто будет искать другую работу. А вот джун с посредственными способностями никуда не денется.
Шанс нарваться на математика, не способного выучить язык, совсем небольшой.
Из своего опыта могу сказать, что шанс, что крутой математик будет неспособен к рутинному промышленному программированию, близок к 100%.
> А вот джун с посредственными способностями никуда не денется.
И как сильно вы хотите набирать к себе в компанию и работать постоянно с такими людьми?
И как сильно вы хотите набирать к себе в компанию и работать постоянно с такими людьми?
В многих компаниях, особенно крупных, рост джуниоров, наоборот, нежелателен. Потому что всегда есть задачи, которые требуют низкой квалификации.
Не сталкивался с таким, но допускаю, что вы правы.
Хотя в статье всё больше упоминаются стартапы — они, думаю, чаще не могут себе такого позволить.
крутой математик будет неспособен к рутинному промышленному программированию, близок к 100%
Программисты — это не только кодеры, системные архитекторы и системные аналитики — это тоже программисты, которые и должны быть крутыми математиками.
Из своего опыта могу сказать, что шанс, что крутой математик будет неспособен к рутинному промышленному программированию, близок к 100%.
В школе и универе был крутым математиком :)
Если проекту нужен формошлепер / верстальщик, то ему не нужен математик. :)
Современная разработка ПО — не математическая, а инженерная специальность. Соответственно требует не математического, а инженерного мышления.
И это не отменяет того факта, что неотъемлемым качеством хорошего программиста является способность к абстрактному мышлению.
И проверить наличие этого качества на собеседовании можно с помощью неких задачек.
В идеале — это может быть решение задачи в виде кода на конкретном ЯП.
Но это не всегда уместно и может занять много времени — и тогда приходится выбирать: проверить способность абстрактно мыслить или знание синтаксиса языка.
И проверить наличие этого качества на собеседовании можно с помощью неких задачек.
В идеале — это может быть решение задачи в виде кода на конкретном ЯП.
Но это не всегда уместно и может занять много времени — и тогда приходится выбирать: проверить способность абстрактно мыслить или знание синтаксиса языка.
«является способность к абстрактному мышлению.»
а что это такое?
а что это такое?
Ну а каких задачек то?
Типа почему люки круглые? (Где правильный ответ — они не всегда круглые, бывают, например, и квадратные. Но тем, кто задаёт вопрос, этот ответ не сильно понравится).
Задачи про алгоритмы? Ну так это нужно знать и помнить алгоритмы, а абстрактное мышление — оно и без алгоритмов может быть.
Ну и инженерное мышление-то как будете проверять?
Типа почему люки круглые? (Где правильный ответ — они не всегда круглые, бывают, например, и квадратные. Но тем, кто задаёт вопрос, этот ответ не сильно понравится).
Задачи про алгоритмы? Ну так это нужно знать и помнить алгоритмы, а абстрактное мышление — оно и без алгоритмов может быть.
Ну и инженерное мышление-то как будете проверять?
Вот, конкретный пример, с которым я сталкивался:
Есть пачка файлов (около 700), в которых описаны формы слов примерно в таком формате:
Вложенность в фигурных скобках в первой строке может быть произвольной глубины.
Задача: сформировать файл, в котором будут все возможные формы слов и их базовые варианты через пробел («человекольвами человеколев»), каждая пара в отдельной строке.
Вроде, не так уж сложно. Не головоломка. Не сортировка пузырьком. Просто включаем мозг и пишем рекурсию, да пару циклов. БД или даже ООП тут использовать не требуется.
Собственно, даже код писать не обязательно, если человек сможет объяснить решение на пальцах.
Но 80% кандидатов в джуниоры не справляются.
Есть пачка файлов (около 700), в которых описаны формы слов примерно в таком формате:
{ев,ьв{а,у,ом,е,ы,ов,ам,ами,ах}} ев {л} -ЕВ муж спец.
л
полул
человекол
Вложенность в фигурных скобках в первой строке может быть произвольной глубины.
Задача: сформировать файл, в котором будут все возможные формы слов и их базовые варианты через пробел («человекольвами человеколев»), каждая пара в отдельной строке.
Вроде, не так уж сложно. Не головоломка. Не сортировка пузырьком. Просто включаем мозг и пишем рекурсию, да пару циклов. БД или даже ООП тут использовать не требуется.
Собственно, даже код писать не обязательно, если человек сможет объяснить решение на пальцах.
Но 80% кандидатов в джуниоры не справляются.
Отлично. Про люки я так понял уже не будем спрашивать. Ок, дальше.
Как часто подобные задачи приходится решать например фронтэнд разработчику? Как из этой задачи можно сделать вывод является ли кандидат хорошим инженером или нет? (Напомню, математики нас не интересуют, разрботка ПО — инженерная специальность).
Хотя соглашусь, что конкретно эта задача в принципе хорошая. Она не требует помнить никаких классических алгоритмов и достаточно простая, чтобы её можно было задать на собеседовании. Но понять с помощью неё, хороший перед нами инженер (а тем более хороший ли сотрудник) — к сожалению невозможно.
А это тут причём вообще?
Как часто подобные задачи приходится решать например фронтэнд разработчику? Как из этой задачи можно сделать вывод является ли кандидат хорошим инженером или нет? (Напомню, математики нас не интересуют, разрботка ПО — инженерная специальность).
Хотя соглашусь, что конкретно эта задача в принципе хорошая. Она не требует помнить никаких классических алгоритмов и достаточно простая, чтобы её можно было задать на собеседовании. Но понять с помощью неё, хороший перед нами инженер (а тем более хороший ли сотрудник) — к сожалению невозможно.
Но 80% кандидатов в джуниоры не справляются.
А это тут причём вообще?
Фронтэнд разработчику — почти никогда, бекэнд — случается. Собственно, эта задача появилась не на ровном месте.
Из неё можно сделать вывод, скорее, не о качестве человека как инженера, а о складе ума и способе мышления.
И, по моему мнению, это куда важнее для начинающего разработчика, чем фреймфорки, паттерны и прочее, потому что, как тут уже писали, они выучатся со временем, а вот то, как человек думает, почти невозможно изменить (мы говорим о взрослых людях).
А это тут причём вообще?
Просто к слову пришлось.
UFO just landed and posted this here
Когда-то давно возникла необходимость реализовать поиск по сайту, который учитывал бы все возможные формы слов. Длительный гуглинг привёл меня в итоге не помню куда, где находился этот архив с такими вот файлами (могу залить на гитхаб, если интересует).
В каждом файле представлен 1 корень слова. Синтаксис файла не соответствует ничему известному, т.е. это не regex, хотя и немного похоже.
1я строка " {ев, ьв{а, у, ом, е, ы, ов, ам, ами, ах}} ев {л} ":
- Вначале в фигурных скобках перечисляются все возможные суффиксы+окончания (далее просто окончания) для слов с этим корнем. Вложенные скобки раскрываются путём склеивания всех перечисленных в них вариантов с буквами перед ними: ьва, ьву, ьвом, ьве и т.д.
- после фигурные скобок написано "ев" — это окончание для базовой формы слова (инфинитив для глаголов, ед.число, имен.падеж для сущ и т.д.)
- оставшаяся часть первой строки "{л} -ЕВ муж спец." роли не играет, там просто доп.сведения.
И далее, со второй стоки перечисляются основы слов (т.е. то, к чему мы будем крепить окончания)
Т.е. алгоритм должен
- раскрыть все фигурные скобки и составить массив возможных окончаний;
- найти окончание для базовой формы слова ("ев");
- для всех основ слов сгенерировать базовую форму, добавив к концу "ев";
- для всех основ слов сгенерировать все возможные формы, добавив каждое из окончаний в массиве из п.1.
Английское слово «list» переводится на русский язык как «список». Сортированный список, двусвязный список и т.д. Слово «лист» в данном случае — ложный друг переводчика. Оно означает по-русски совсем другое.
Когда математик идет на программиста…
Обычно проверяют на сообразительность, потому что умение написать код — оно приходит. В любой компании свои стандарты кода. И потому на месте придется привыкать заново к новому стандарту. В 2014 я устроился на работу в компанию, которая в с++ использовала макросы и гото. Почти в каждом методе. Коду больше 20-и лет и переписывать всю базу из более 10 миллионов строк кода — долго и сложно. Потому такой стандарт.
И вот на такой проверке тут вдруг наступает облом — обычно программисты плохо подкованы математически, у них нет в голове готовых решений на задачки и им приходится соображать на ходу(в одной компании мне дали задачку на весы: есть обычные чашечные весы — больше, меньше, равно, за сколько взвешиваний можно найти дефект массы в одном из 13 шариков и почему так? Я честно ответил, что такую задачу я разбирал целиком и полностью, вплоть до вывода формул. Мне дали другую задачу). В итоге, проверяется сообразительность. Но героиня с ее натренированным сознанием выдает ложноположительный результат. И в итоге, к ней ДЕЙСТВИТЕЛЬНО предъявляют повышенные требования. Потому что она лихо разобралась с задачами…
Я думаю, что если бы она сразу предупреждала интервьюера о том, что она математик и ЗНАЕТ решения задач, то таких обломов она бы избежала.
Обычно проверяют на сообразительность, потому что умение написать код — оно приходит. В любой компании свои стандарты кода. И потому на месте придется привыкать заново к новому стандарту. В 2014 я устроился на работу в компанию, которая в с++ использовала макросы и гото. Почти в каждом методе. Коду больше 20-и лет и переписывать всю базу из более 10 миллионов строк кода — долго и сложно. Потому такой стандарт.
И вот на такой проверке тут вдруг наступает облом — обычно программисты плохо подкованы математически, у них нет в голове готовых решений на задачки и им приходится соображать на ходу(в одной компании мне дали задачку на весы: есть обычные чашечные весы — больше, меньше, равно, за сколько взвешиваний можно найти дефект массы в одном из 13 шариков и почему так? Я честно ответил, что такую задачу я разбирал целиком и полностью, вплоть до вывода формул. Мне дали другую задачу). В итоге, проверяется сообразительность. Но героиня с ее натренированным сознанием выдает ложноположительный результат. И в итоге, к ней ДЕЙСТВИТЕЛЬНО предъявляют повышенные требования. Потому что она лихо разобралась с задачами…
Я думаю, что если бы она сразу предупреждала интервьюера о том, что она математик и ЗНАЕТ решения задач, то таких обломов она бы избежала.
им приходится соображать на ходу
В итоге хорошие программисты, умеющие работать с легаси и понимающие когда и как лучше отрефакторить идут лесом, а попадают либо математики, которые в лучшем случае идут лесом после испыталки (а в худшем превращают весь проект в не поддерживаемый ужас), либо rockstar-ы, которые сами скоро уйдут из за скуки.
Проблема в том, что каждый стартап думает что он google, не меньше, и предъявляет требования для отбора кандидатов, которые на самом деле ему не нужны.
Стандартная проблема всех людей — недостаток осознанности и карго культ. Слышали, что кто-то успешный так делает, значит и мы будем так делать. А почему он так делает, подходит ли это нам — разбираться некогда, некому и вообще не до этого. Так у всех и везде, поэтому имеем то, что имеем.
Те, кто проводит собеседования — обычные люди, с неба звёзд не хватают. Никто их не учил, как правильно это делать (более того, никто и не знает, как правильно это делать).
Те, кто проводит собеседования — обычные люди, с неба звёзд не хватают. Никто их не учил, как правильно это делать (более того, никто и не знает, как правильно это делать).
в одной компании мне дали задачку на весы: есть обычные чашечные весы — больше, меньше, равно, за сколько взвешиваний можно найти дефект массы в одном из 13 шариков и почему так?У них это используется?
Если нет, то нефиг спрашивать.
Мне дали другую задачу). В итоге, проверяется сообразительность.Другую задачу дали бы в любом случае. :)
Я думаю, что если бы она сразу предупреждала интервьюера о том, что она математикОни не спрашивали образование? :)
сам так попадал, в начале нифига нормально не собеседуют, а потом начинают мозг компостировать, типа а чего так медленно. А фигли я быстро буду, если в 1-ый раз это делаю.
Особенно так собеседуют люди, кот.:
1) сами нифига не знают
2) самостоятельно ничего не изучали, а им старший добродушный дяденька-программист всё рассказал, или изучали, но это было по их специальности, кот. изучалась в университете
3) начинающие начальники из п.2
Особенно так собеседуют люди, кот.:
1) сами нифига не знают
2) самостоятельно ничего не изучали, а им старший добродушный дяденька-программист всё рассказал, или изучали, но это было по их специальности, кот. изучалась в университете
3) начинающие начальники из п.2
Вы написали откровенного коня в вакууме из вашего личного мнения из узкого и лично вашего опыта.
На деле обстоят дела иначе:
1) Человек, который выпускается из школы/университета имеет 100% хорошую память и умеет запоминать слова. Так хотят считать работодатели и им так приходится считать.
2) Исходя из п1. делаем вывод, что прочитать статью по ООП и зазубрить разницу между абстрактным классом и интерфейсом может каждый. С этим приходится мириться. Особенно работодателям.
3) п.1 и п.2 это совсем не показатели навыков программирования, это просто показатель памяти.
А как же проверять навыки программирования? Ведь люди приходят писать код, а не запоминать? Верно? И тут появляются задачки. Которые и показывают, как человек умеет подходить к решению проблем. Память у него по умолчанию есть. Или нет? Тогда ваш ЕГЭ куплен и диплом куплен. Пожалуйте в тюрьму за взятку.
Что может быть лучше, чем попросить написать на листке strcasecmp(char*, char*) или треугольник Паскаля растущий вверх с отрицательными значениями.
На деле обстоят дела иначе:
1) Человек, который выпускается из школы/университета имеет 100% хорошую память и умеет запоминать слова. Так хотят считать работодатели и им так приходится считать.
2) Исходя из п1. делаем вывод, что прочитать статью по ООП и зазубрить разницу между абстрактным классом и интерфейсом может каждый. С этим приходится мириться. Особенно работодателям.
3) п.1 и п.2 это совсем не показатели навыков программирования, это просто показатель памяти.
А как же проверять навыки программирования? Ведь люди приходят писать код, а не запоминать? Верно? И тут появляются задачки. Которые и показывают, как человек умеет подходить к решению проблем. Память у него по умолчанию есть. Или нет? Тогда ваш ЕГЭ куплен и диплом куплен. Пожалуйте в тюрьму за взятку.
Что может быть лучше, чем попросить написать на листке strcasecmp(char*, char*) или треугольник Паскаля растущий вверх с отрицательными значениями.
Думаю, Вы не поняли, что имею в виду. Я говорю, про низкую квалификацию работодателя в плане собеседований, кот. её собеседует. Он трезво не оценивает, что для изучения некоторых вещей может потребоваться время и какое время. Теор минимум проверил, а практические навыки — нет. Но в тоже время берут её, а передавать знания ей не хотят: делай, доложишь о результате.
Как пишет девушка:
Как пишет девушка:
Это объяснимо, ведь многие из них научились программировать в двенадцать лет, и они освоили программирование так же, как я научилась решать головоломки. А теорию они подучили уже в колледже. Но я-то практиковалась в задачках с десяти лет и поэтому имею все основания сказать: программирование — охренительно трудная штука. Такая-же трудная как и решение головоломок, если не труднее. И если я с ходу справляюсь с общими элементами в несортированном листе, циклами связанных листов и кратчайшим путем в сети, то это еще не значит, что я буду знать все что требуется для программирования в первые недели работы.
разницу между абстрактным классом и интерфейсом
Третий раз за сегодня в разных темах спрашиваю, а какая, собственно, разница? :)
Абстрактный класс предполагает наследование от него, причём реализация конкретного метода может быть хоть на пятом родственном колене.
Интерфейс предполагает имплементацию. То же самое.
Если не реализовать на каком-то колене, то такой класс нужно объявлять абстрактным. То же самое при имплементации интерфейса.
(PHP)
Если не реализовать на каком-то колене, то такой класс нужно объявлять абстрактным. То же самое при имплементации интерфейса.
(PHP)
> Интерфейс предполагает имплементацию. То же самое.
Неа, совсем не то же самое. Интерфейс — это просто соглашение. Дескать, у нас есть такой-то набор вот таких методов, и если вы хотите общаться с нашим объектом, вы должны его использовать.
Неа, совсем не то же самое. Интерфейс — это просто соглашение. Дескать, у нас есть такой-то набор вот таких методов, и если вы хотите общаться с нашим объектом, вы должны его использовать.
Но его нужно тоже реализовать.
Это смотря с какой стороны интерфейса вы находитесь :)
В любом случае, интерфейс — это именно интерфейс. Воспринимайте это просто как описание какого-то подмножества «рычагов» для управления объектом. Причем у одного объекта может быть множество интерфейсов, а один и тот же интерфейс может подходить к совершенно разным объектам, не имеющим между собой наследственной связи.
А абстрактный класс — это база, на основании которой спроектирован класс вашего объекта. Причём она может быть далеко не пустой, а иметь какой-то функционал.
В любом случае, интерфейс — это именно интерфейс. Воспринимайте это просто как описание какого-то подмножества «рычагов» для управления объектом. Причем у одного объекта может быть множество интерфейсов, а один и тот же интерфейс может подходить к совершенно разным объектам, не имеющим между собой наследственной связи.
А абстрактный класс — это база, на основании которой спроектирован класс вашего объекта. Причём она может быть далеко не пустой, а иметь какой-то функционал.
разница в принципах и назначении. Абстрактный класс используется в отношениях «is» / «является», в то время как интерфейс это «can do» / «могу делать».
Интерфейс в принципе говорит только о том, что класс что-то может сделать. Классы при этом остаются никак не связанными.
Абстрактный класс позволяет задавать какое-то базовое поведение, которое будет использоваться по потомкам.
Плюс есть всяческая доп разница по языкам. Скажем, в c# нет множественного наследования, но можно реализовывать множество интерфейсов.
Так же один из распространненых паттернов при заведении интерфейса — сделать абстрактный класс реализующий куски этого интерфейса для упрощения пользовательской реализации
Интерфейс в принципе говорит только о том, что класс что-то может сделать. Классы при этом остаются никак не связанными.
Абстрактный класс позволяет задавать какое-то базовое поведение, которое будет использоваться по потомкам.
Плюс есть всяческая доп разница по языкам. Скажем, в c# нет множественного наследования, но можно реализовывать множество интерфейсов.
Так же один из распространненых паттернов при заведении интерфейса — сделать абстрактный класс реализующий куски этого интерфейса для упрощения пользовательской реализации
Абстрактный класс используется в отношениях «is» / «является», в то время как интерфейс это «can do» / «могу делать».
Мне кажется, это и есть суть.
Спасибо.
Просто мне не пришло бы в голову, допустим наследовать абстрактный класс Iterable() вместо имплементации интерфейса. :)
Видимо это я и не говорил на собеседованиях, остальное говорил.
разница в принципах и назначении. Абстрактный класс используется в отношениях «is» / «является», в то время как интерфейс это «can do» / «могу делать».
Именно так. Интерфейс стоит воспринимать как trait или concept.
Плюс есть всяческая доп разница по языкам. Скажем, в c# нет множественного наследования, но можно реализовывать множество интерфейсов.
Этому другая причина. Множественое наследование классов довольно неудобно с точки зрения реализации: вместо одной vtable приходится заводить несколько, что увеличивает потребление памяти объектов; затруднено преобразование типов.
Кстати, аналогов интерфейсов C# и Java в том же C++ просто не существует.
+1
Я 2 раза успешно проходил собеседования, при этом указывая, что с такими-то технологиями я не работал.
Увольняли в течение месяца :)
Я 2 раза успешно проходил собеседования, при этом указывая, что с такими-то технологиями я не работал.
Увольняли в течение месяца :)
Меня на собеседованиях и в Яндекс и в Джетбрейнс спрашивали по алгоритмам, обход двусвязного списка и проч. На должность веб-разработчика. Веб-разработчика фронтендской части (JavaScript), Карл! Еще где-то спрашивали, но я уже просто послал: «Либо вы нормальные вопросы задаете, либо я встаю и ухожу». За всю свою жизнь после универа мне понадобилось написать алгоритм примерно 1 раз! И этот раз относился к моему собственному проекту.
На фронтенде — математика — последнее, что может потребоваться от программиста. Более того, самый худший код пишется именно математиками, которые про преждевременную оптимизацию и ее последствия слухом не слыхивали. Я уже не говорю о десятках собеседований, когда разговариваешь с ведущим программистом или тимлидом, голова которого пухнет от знаний и глаза загораются от очередной задачки, но тебе совсем не смешно становится. И директору, с которым потом общаешься, тоже не смешно, потому что, проект стопорится из-за сложности, качество падает, штат растет, сотрудники зашиваются. И непонятно почему. Все же крутые ребята работают, которые задачки хорошо решают.
На фронтенде — математика — последнее, что может потребоваться от программиста. Более того, самый худший код пишется именно математиками, которые про преждевременную оптимизацию и ее последствия слухом не слыхивали. Я уже не говорю о десятках собеседований, когда разговариваешь с ведущим программистом или тимлидом, голова которого пухнет от знаний и глаза загораются от очередной задачки, но тебе совсем не смешно становится. И директору, с которым потом общаешься, тоже не смешно, потому что, проект стопорится из-за сложности, качество падает, штат растет, сотрудники зашиваются. И непонятно почему. Все же крутые ребята работают, которые задачки хорошо решают.
Интересно, мнение автора совпадает на 100% с моим. Правда, я по другую сторону баррикад. С вышкой в универе справился ровно на 3 и то редко без пересдач. И вышка мне представлялась — выучиванием способа решения очередной группы уравнений.
Так вот программирую уже больше 10 лет, и никакие универские высшие математики либо точные науки не пригодились. Я бы сказал, что в программировании главное логика, сообразительность и память.
Только на одном собесе на тим лида лет 5 назад задавали вопросы а-ля метод сортировки пузырьком (или как там). На что честно сказал — не знаю. Работу, кстати предложили, несмотря на кучу неотвеченных вопросов.
Так вот программирую уже больше 10 лет, и никакие универские высшие математики либо точные науки не пригодились. Я бы сказал, что в программировании главное логика, сообразительность и память.
Только на одном собесе на тим лида лет 5 назад задавали вопросы а-ля метод сортировки пузырьком (или как там). На что честно сказал — не знаю. Работу, кстати предложили, несмотря на кучу неотвеченных вопросов.
Чтобы кто-то писал меньше математики в коде, кто-то должен писать больше математики в коде. Чтобы вы могли проходить собеседование без математики, кто-то должен проходить собеседования состоящие из одной математики. Порой складывается впечатление, что хабр это сайт для школьников с манией величия и крайностями.
Наверное, вы математик. У меня столько вопросов уточняющих, по-поводу того, что вы имели в виду.
1) Что значит — больше или меньше математики в коде? Есть задание, там либо требуется что-то знать из высшей математики, либо нет. И, практически всегда, это — нет. А на 1-2 случая за 10 лет — можно погуглить.
2) Что значит собес с математикой или без? Я также провожу собесы без математики. Т.к. сам не знаю эту математику.
3) Это вы про меня пишите «школьник с манией величия»?
1) Что значит — больше или меньше математики в коде? Есть задание, там либо требуется что-то знать из высшей математики, либо нет. И, практически всегда, это — нет. А на 1-2 случая за 10 лет — можно погуглить.
2) Что значит собес с математикой или без? Я также провожу собесы без математики. Т.к. сам не знаю эту математику.
3) Это вы про меня пишите «школьник с манией величия»?
А на 1-2 случая за 10 лет — можно погуглить.
Эффективность такого — примерно как погуглить и пойти сделать хирургическую операцию.
Ну вы сравнили. Погуглил, почитал, запилил. Чем это отличается от всего остального, что кто-то пока ещё не знает?
А эффективность 5 лет обучения из-за 1-2 случаев за 10 лет?
На самом деле, меня всегда смущало то, что у меня огромная нехватка знаний в области высшей математики и тому подобного. И, что какой-то я не-до-программист. Однако, годы идут, проекты сдаются. Вобщем статистика — против математики. Да и вот статьи тут математики пишут.
А эффективность 5 лет обучения из-за 1-2 случаев за 10 лет?
На самом деле, меня всегда смущало то, что у меня огромная нехватка знаний в области высшей математики и тому подобного. И, что какой-то я не-до-программист. Однако, годы идут, проекты сдаются. Вобщем статистика — против математики. Да и вот статьи тут математики пишут.
Ну вы сравнили. Погуглил, почитал, запилил. Чем это отличается от всего остального, что кто-то пока ещё не знает?
Вам привести пример задач, которые будут не по зубам обычным программистам без дополнительных навыков? Пожалуйста:
1. Программерско-алгоритмические скиллы. Берёте какую-нибудь задачу с финала ACM (желательно пожёстче, с которой справилось не более 20% всех команд), далее читаете разбор задачи (описание алгоритма её решения) и пытаетесь написать реализацию, которая прошла бы все тесты.
2. Математические скиллы. Вот научная статья, в которой хорошо и подробно описан алгоритм супер-разрешения. Несмотря на то, что это 2004 год, этот метод до сих пор считается одним из лучших. Сколько времени уйдёт на реализацию этого алгоритма обычным программистом?
А эффективность 5 лет обучения из-за 1-2 случаев за 10 лет?
Люди, сознательно занимающиеся математикой, не работают обычными разработчиками.
Берёте какую-нибудь задачу с финала ACM
Вы же понимаете, что аргумент не в вашу пользу.
Математические скиллы. Вот научная статья, в которой хорошо и подробно описан алгоритм супер-разрешения
Подключаем библиотеку… Есть теория, есть практика. Я делюсь своими мыслями исходя из опыта и задач с которыми каждый день сталкиваюсь. Там математики — нет, но это не значит что задачи эти простые.
Люди, сознательно занимающиеся математикой, не работают обычными разработчиками
В каком-то смысле про то и речь. Они, впринципе, могут не работать разработчиками. Могут быть плохими разработчиками, хорошими, отличными. Как и те, кто математику знает на троечку-двоечку.
Только само по себе углубленное знание математики — не даёт вам никакой гарантии.
Так ведь на собеседованиях на программиста обычно никто и не просит вас решать диф.уравнения.
Но логика, абстрактное мышление, воображение, в конце концов — это больше, чем просто выучить операторы языка.
Потому, я думаю, чаще предполагается, что синтаксис конкретного языка соискатель либо знает, либо быстро выучит, и на собеседованиях концентрируются на таких качествах, которые прямо в лоб проверить не всегда возможно, вот и предлагают всякие странные задачки.
Если у вас есть подтверждённый 10ти-летний опыт в программировании, то да, странно, наверное, предполагать, что вы не умеете абстрактно или логически мыслить.
Но в статье речь идёт о начинающем специалисте — и тут как раз есть повод для сомнений и проверок.
Но логика, абстрактное мышление, воображение, в конце концов — это больше, чем просто выучить операторы языка.
Потому, я думаю, чаще предполагается, что синтаксис конкретного языка соискатель либо знает, либо быстро выучит, и на собеседованиях концентрируются на таких качествах, которые прямо в лоб проверить не всегда возможно, вот и предлагают всякие странные задачки.
Если у вас есть подтверждённый 10ти-летний опыт в программировании, то да, странно, наверное, предполагать, что вы не умеете абстрактно или логически мыслить.
Но в статье речь идёт о начинающем специалисте — и тут как раз есть повод для сомнений и проверок.
Вот про диф. уры как раз хотел написать. Собеседовался году в 2009, кажется в РБК, который как раз купил qip и его некому было писать. Собеседовать было тоже некому, поэтому пригласили каких-то чудиков, которые как раз спросили задачу, которая свелась у меня к дифуру. Зачем все это было нужно — теряюсь в догадках до сих пор.
и никакие универские высшие математики либо точные науки не пригодились
Большая часть программирования не требует никакой математики:
выбрал данные в базе и сохранил обратно. :)
Но знание математики это плюс.
Кмк, к программированию проявляют способности / склонности больше как раз те, кому нравится математика.
UFO just landed and posted this here
Напомню про еще один изыск прикладных психологов который продержался в тренде довольно долго: "уметь программировать вообще не надо, главное чтобы человек хороший попался". Согласно этому принципу некоторые большие и известные компании нанимали выпускников колледжей гуманитарных специальностей после теста на общую сообразительность и ожидали что те научатся писать через пару месяцев. Я с некоторыми из этих людей работал, действительно умные ребята, хотя многие из них программистами так и не стали по большому счету.
Так что описанная ситуация — всего лишь частный случай под условным названием "главное чтобы аналитические способности были", и это еще не самый худший вариант.
Просто стартапы слепо копируют эту тактику собеседований с таких компаний, как Google, Microsoft, Amazon, и т.д.
Но Гугл и Амазон можно понять — они могут себе это позволить. Им ежедневно присылают сотни и тысячи резюме от программистов, которые отлично знают языки и инструменты, и простыми вопросами типа «чем отличается абстрактный класс от интерфейса» людей не отобрать — а всех в офис на интервью не повезешь. Для таких компаний, задачи на логику и алгоритмы — это, наверное, единственный способ отбора кандидатов, при котором уверенно можно сказать, что у одного соискателя логическое и абстрактное мышление лучше, чем у другого.
Но тут надо понять еще две вещи.
Во-первых, крупные компании заинтересованы в долгосрочной перспективе. Т.е. даже если у человека возникнут трудности в первые пол года работы, какой-нибудь amazon может позволить себе обучать этого сотрудника, потому что они знают, что он вряд ли куда-то уйдет, и их интересует именно долгосрочная работа с этим человеком.
Во-вторых, одними задачами на алгоритмы в таких компаниях никто никогда не ограничивается. Там это используется скорее в качестве скрининга перед тем, как приглашать человека на собеседование в офис. Опять же — лучших способов отсеять N человек из овер9000 пока еще никто не придумал. Ну а если уж у человека реально слабо с программированием и ООП но он хорош в математике, я уверен, что такому человеку найдут применение.
Естественно, при этом стартапы, получившие свой первый раунд инвестиций, любят возомнить себя Гуглом, и начинают слепо применять их тактики и копировать за ними все подряд, не разбираясь в сути. При этом причина одна — такие люди, как правило, просто ничего не понимают в собеседованиях, и просто не знают, как нанимать людей на работу.
Но Гугл и Амазон можно понять — они могут себе это позволить. Им ежедневно присылают сотни и тысячи резюме от программистов, которые отлично знают языки и инструменты, и простыми вопросами типа «чем отличается абстрактный класс от интерфейса» людей не отобрать — а всех в офис на интервью не повезешь. Для таких компаний, задачи на логику и алгоритмы — это, наверное, единственный способ отбора кандидатов, при котором уверенно можно сказать, что у одного соискателя логическое и абстрактное мышление лучше, чем у другого.
Но тут надо понять еще две вещи.
Во-первых, крупные компании заинтересованы в долгосрочной перспективе. Т.е. даже если у человека возникнут трудности в первые пол года работы, какой-нибудь amazon может позволить себе обучать этого сотрудника, потому что они знают, что он вряд ли куда-то уйдет, и их интересует именно долгосрочная работа с этим человеком.
Во-вторых, одними задачами на алгоритмы в таких компаниях никто никогда не ограничивается. Там это используется скорее в качестве скрининга перед тем, как приглашать человека на собеседование в офис. Опять же — лучших способов отсеять N человек из овер9000 пока еще никто не придумал. Ну а если уж у человека реально слабо с программированием и ООП но он хорош в математике, я уверен, что такому человеку найдут применение.
Естественно, при этом стартапы, получившие свой первый раунд инвестиций, любят возомнить себя Гуглом, и начинают слепо применять их тактики и копировать за ними все подряд, не разбираясь в сути. При этом причина одна — такие люди, как правило, просто ничего не понимают в собеседованиях, и просто не знают, как нанимать людей на работу.
и простыми вопросами типа «чем отличается абстрактный класс от интерфейса»
В 4-ый раз за сегодня спрашиваю: чем же? :)
Пока получил вроде только 1 ответ :)
Абстрактный класс — это класс, который нельзя инстанциировать, от него можно лишь наследовать другие классы. Абстрактный класс может содержать как абстрактные методы, так и обычные (в случае с C# — override/virtual) с логикой.
Интерфейс — это как абстрактный класс, который не может содержать не-абстрактные методы. Интерфейс по сути содержит лишь список методов/сигнатур, которые обязан реализовать класс, который унаследован от интерфейса. Например, в C# есть встроенный интерфейс IComparable. Если ваш класс наследуется от IComparable, он обязан реализовать функцию сравнения CompareTo.
Соответственно, другие классы знают, что ваш класс умеет это делать. Наследование от интерфейса, это по сути просто объявление, «я, класс, реализую вот такой набор методов, которые вы можете использовать». Именно поэтому не поддерживается множественное наследование классов, но поддерживается множественное наследование интерфейсов.
Ответ устраивает?
Интерфейс — это как абстрактный класс, который не может содержать не-абстрактные методы. Интерфейс по сути содержит лишь список методов/сигнатур, которые обязан реализовать класс, который унаследован от интерфейса. Например, в C# есть встроенный интерфейс IComparable. Если ваш класс наследуется от IComparable, он обязан реализовать функцию сравнения CompareTo.
Соответственно, другие классы знают, что ваш класс умеет это делать. Наследование от интерфейса, это по сути просто объявление, «я, класс, реализую вот такой набор методов, которые вы можете использовать». Именно поэтому не поддерживается множественное наследование классов, но поддерживается множественное наследование интерфейсов.
Ответ устраивает?
Позвольте побыть занудой.
Не реализовать, а иметь. Функция может быть реализована и в базовом классе.
Если ваш класс наследуется от IComparable, он обязан реализовать функцию сравнения CompareTo.
Не реализовать, а иметь. Функция может быть реализована и в базовом классе.
Да. Но если честно, не видел ни разу, что бы так делали. Если базовый класс имеет функцию CompareTo, то почему бы ему самому не наследоваться от интерфейса IComparable, а не его потомку?
Эти пункты для моих собеседующих были недостаточны, хотя тут все истина :)
Кстати, в java это уже не так (начиная с 8 версии), где в интерфейсах появились default-методы, имеющие реализацию. Ключевое отличие, которое сохраняется кроме отсутствия множественного наследования по абстрактным классам — интерфейсы не содержат состояния (полей). Trait'ы в rust'е ведут себя так же (содержат поведение, но не состояние).
Если говорить про плюсы, то там интерфейсами иногда называют классы не содержащие полей и содержащие исключительно чисто виртуальные функции.
Ключевое отличие, которое сохраняется кроме отсутствия множественного наследования по абстрактным классам — интерфейсы не содержат состояния (полей).
И в Java, а в C# у интерфейсов есть 2 принципиальных отличия от абстрактных классов:
1. Методы интерфейса всегда закрытые (virtual sealed/final). Чтобы их перезаписать (override), нужно унаследовать интерфейс ещё раз. При этом это будет уже новый интерфейс, т.е. нельзя до него достучаться из базового класса.
2. В случае абстрактного класса один из классов-потомков обязан перезаписать метод. В случае интерфейса, наоборот, метод должен быть определён в текущем или одном из базовых классов.
Если говорить про плюсы, то там интерфейсами иногда называют классы не содержащие полей и содержащие исключительно чисто виртуальные функции.
Но при этом они все равно не являются аналогами интерфейсов C#/Java. Только Borland C++ Builder рассматривает такие классы как интерфейсы. На самом деле, без счётчика ссылок интерфейсы не имеют смысла.
- Методы интерфейса всегда закрытые (virtual sealed/final). Чтобы их перезаписать (override), нужно унаследовать интерфейс ещё раз. При этом это будет уже новый интерфейс, т.е. нельзя до него достучаться из базового класса.
- В случае абстрактного класса один из классов-потомков обязан перезаписать метод. В случае интерфейса, наоборот, метод должен быть определён в текущем или одном из базовых классов.
Как минимум, в java — нет. Семантика final методов в java другая. Их нельзя override'ить вообще, и в интерфейсах их не бывает в принципе, только в абстрактных и конкретных классах. Ключевого слова sealed в java просто нет.
Можно имплементировать интерфейс, имея реализацию метода из базового класса, дополнительного override'а не требуется. Можно override'ить ниже по иерархии классов, можно повторно указывать implements SomeInterface, можно не указывать — никакой разницы с точки зрения java-разработчика не будет, AFAIK. Метод Class#getInterfaces вернёт массив всех интерфейсов, реализуемых данным классом, вне зависимости от того, на каком уровне иерархии был implements.
Можно не override'ить неабстрактные методы из базового класса (даже если данный класс является конкретным). И можно не override'ить любые методы, если данный класс является абстрактным.
На самом деле, без счётчика ссылок интерфейсы не имеют смысла.
Опять вы за своё понятие интерфейса из COM/COM+. С чего вы взяли, что в той же jvm интерфейсы должны иметь ref counting? Выгрузка классов-имплементаций из permgen/metaspace осуществляется не на основе наличия живых объектов реализующих интерфейс, а на основе живых объектов этого или дочерних классов. Где именно будет храниться эта информация — детали реализации конкретной jvm. GC в permgen/metaspace не относится к языку java.
Как минимум, в java — нет. Семантика final методов в java другая.
Семантика final в Java для методов такая же, как sealed в C#.
Их нельзя override'ить вообще, и в интерфейсах их не бывает в принципе, только в абстрактных и конкретных классах. Ключевого слова sealed в java просто нет.
Отличие заключается в том, что в Java методы по умолчанию виртуальные и открытые, а в C# — нет.
В C#, если класс реализует интерфейс, то методы, реализующие интерфейс, из обычных неявно преобразуются в виртуальные и закрытые (кроме случаев, когда открытость указывается явно). Повторная реализация интерфейса в классе-потомке приводит к созданию нового метода с той же сигнатурой.
Ничто не мешает явно помечать методы открытыми и добиться функционала, как в Java, но в этом случае вызов методов станет более медленным.
С чего вы взяли, что в той же jvm интерфейсы должны иметь ref counting?
Да причём тут COM вообще? Он мне до лампочки.
В .NET и JVM за жизнь объекта отвечает GC. Но в C++ придётся извращаться со shared_ptr, чтобы добиться аналогичного функционала.
Да причём тут COM вообще? Он мне до лампочки.
Значит я вас с кем-то перепутал. Была недавно длиннющая дискуссия с отстаиванием позиции, что интерфейсы без ref counting — ничто и java использует механизмы из COM для интерфейсов.
Отличие заключается в том, что в Java методы по умолчанию виртуальные и открытые, а в C# — нет.
ОК, значит в C# нагородили чуть больше ключевых слов и семантики ради упрощения оптимизации за счёт использования невиртуальных методов. В java-то их просто нет, только виртуальные.
Тогда такое различие между абстрактными классами и интерфейсами в C# понятно и естественно.
интерфейсы без ref counting — ничто
Это логично следует из типичного usecase интерфейсов. Либо GC, либо счётчик ссылок, либо костыльный код.
Тогда такое различие между абстрактными классами и интерфейсами в C# понятно и естественно.
Тем не менее, второй пункт относится в равной степени и к Java, и к C#.
В случае java я привёл два варианта, когда это (второе) утверждение ложно для абстрактных классов:
- неабстрактный метод абстрактного класса может не override'иться ниже (в том числе и в конкретных классах), например,
j.u.Collections.EmptyList<E>не переопределяетj.u.AbstractList<E>#add(E); - абстрактный класс может не переопределять абстрактный метод суперкласса.
В случае интерфейса метод может быть не переопределен, если интерфейс имплементируется абстрактным классом или является суперинтерфейсом для данного. Плюс с 8 версии java добавились default-методы, как я уже писал выше, которые не требуют переопределения даже в конкретных классах.
Это логично следует из типичного usecase интерфейсов. Либо GC, либо счётчик ссылок, либо костыльный код.
Разверните мысль. Например, что вы считаете типичным usecase'ом интерфейсов.
В случае интерфейса метод может быть не переопределен, если интерфейс имплементируется абстрактным классом или является суперинтерфейсом для данного. Плюс с 8 версии java добавились default-методы, как я уже писал выше, которые не требуют переопределения даже в конкретных классах.
Ну так в C# точно такая же ситуация будет (кроме default методов, которых в C# нет). Вас, видимо, смутил термин «определён», под которым подразумевается «defined», а не «implemented». Всё-таки иногда проще выражать мысли по-английски.
Разверните мысль. Например, что вы считаете типичным usecase'ом интерфейсов.
Типичная ситуация — когда объект после создания сразу преобразуется к интерфейсу. Т.е. явное удаление объекта невозможно.
Я бы на собесе сказал — ок. Продолжил бы собес, а себе в голове пометил — человек знает синтаксис, а саму суть не уловил.
И в чем же заключается не уловленная суть, если не секрет?
Ну вот если бы вы написали как кто-то выше
Я бы больше ничего не спрашивал.
Если вы сравниваете интерфейс и абстрактный класс — 100 пудова не в теме.
Прежде всего вы должны понимать что такое ООП. И что оно про объекты
Раскажу вам пример Интерфейса. Может так проще понять.
Например, есть Интерфейс Commentable, который можно навесить на любой класс.
Что это значит? Как только вы его навесили, любой объект этого класса стало можно каментать. Магия
Немного подробнее — у вас, ещё есть 2 функции. Одна — addComment, которая в качестве аргумента принимает только Commentable объект и сам текст коммента.
А вторая функция displayComments(Commentable $object). Не Commentable объект ругнётся и не отобразится. А у Commentable — сама функция будет уверенно дёргать известные методы интерфейса и отобразит комментарии.
Хочешь, чтобы теперь и юзеров можно было каментать (а в ООП 1 объект = 1 юзер, а не как бывает намутят) — добавляешь к классу юзера Commentable. Не релизовал методы интерфейса — прилага тупо не запустится. Красота…
И где тут сходство с абстрактными классами?
Просто сам вопрос не совсем корректный.
Более правильный «Для чего стоит использовать интерфейс, а для чего абстрактный класс?»
Я бы больше ничего не спрашивал.
Если вы сравниваете интерфейс и абстрактный класс — 100 пудова не в теме.
Прежде всего вы должны понимать что такое ООП. И что оно про объекты
Раскажу вам пример Интерфейса. Может так проще понять.
Например, есть Интерфейс Commentable, который можно навесить на любой класс.
Что это значит? Как только вы его навесили, любой объект этого класса стало можно каментать. Магия
Немного подробнее — у вас, ещё есть 2 функции. Одна — addComment, которая в качестве аргумента принимает только Commentable объект и сам текст коммента.
А вторая функция displayComments(Commentable $object). Не Commentable объект ругнётся и не отобразится. А у Commentable — сама функция будет уверенно дёргать известные методы интерфейса и отобразит комментарии.
Хочешь, чтобы теперь и юзеров можно было каментать (а в ООП 1 объект = 1 юзер, а не как бывает намутят) — добавляешь к классу юзера Commentable. Не релизовал методы интерфейса — прилага тупо не запустится. Красота…
И где тут сходство с абстрактными классами?
Как только вы его навесили, любой объект этого класса стало можно каментать. Магия
Странное утверждение. Не знаю, что вы называете словом «навесили» и «магия», но от того, что вы добавите классу интерфейс Commentable, сам собой класс не станет комментируемым, пока вы не напишете свою реализацию комментирования. Поэтому он и называется интерфейс — использование извне остается неизменным, а реализация и поведение может отличаться.
А если делать интерфейсы без методов и использовать их в качестве «пометок» на классах — за такое надо бить по рукам.
Корректен ли вопрос или нет — это уже обсуждение из другой области. Я не фанат таких вопросов (я вообще считаю, что лучшее, что может показать скилл программиста — это его код).
Но как можно увидеть из обсуждения выше, у интерфейсов есть гораздо больше особенностей, в том числе особенности реализации и использования в различных языках/средах (C# vs Java).
Где сходство с абстрактными классами? В С++, например, нету нативной реализации интерфейсов на уровне языка. Там интерфейс реализуется через абстрактные классы (которых, впринципе, в языке тоже как таковых нет).
Ну а насчет «не уловил суть» — не вижу, чем ваш пример отличается от моего. Я привел в пример IComparable — существующий в стандартной библиотеке языка интерфейс, который говорит о том что объект класса, реализующий («на который навесили») интерфейс IComparable, имеет метод CompareTo, который можно вызывать, что бы сравнивать объект с другим. А еще может быть generic класс, который требует сравнения хранимых объектов (например, двоичное дерево поиска). И оно может работать с любым типом объектов, основное требование — что бы их можно было сравнивать через CompareTo. Это можно сделать через задание generic constraint с интерфейсом IComparable.
А если делать интерфейсы без методов и использовать их в качестве «пометок» на классах — за такое надо бить по рукам.
Маркерные интерфейсы — общепринятая практика. Почему вы считаете, что надо бить по рукам?
Например, в java маркерные интерфейсы j.l.Serializable и j.l.Cloneable сообщают о выполнении соответствующего контракта.
Маркер j.u.RandomAccess используется для утверждения о том, что данная реализация интерфейса j.u.List поддерживает эффективные операции выборки (обычно за O(1)). Этот маркерный интерфейс позволяет generic-алгоритмам менять своё поведения в зависимости от его наличия, дабы использовать более эффективные алгоритмы для списков с последовательным доступом.
Ещё один стандартный вариант применения (до java 1.5, сейчас не актуально) — вместо аннотаций для использования при AOP.
Не уверен насчёт Java, но в C# эту роль прекрасно выполняют атрибуты. Msdn Interface design гайдлайн прямым текстом не советует использовать маркерные интерфейсы.
В Java, насколько я понимаю, их использовали до появления аннотаций, и сейчас это считается легаси техникой. Поправьте, если я не прав, опять же, я имею довольно общее представление о Java и её best practices.
Но в любом случае, для меня это выглядит как костыльное решение. В моем понимании, смысл интерфейса именно в том что бы разделить использование и реализацию, а не в том что бы использовать их в качестве пометок/маркеров.
В Java, насколько я понимаю, их использовали до появления аннотаций, и сейчас это считается легаси техникой. Поправьте, если я не прав, опять же, я имею довольно общее представление о Java и её best practices.
Но в любом случае, для меня это выглядит как костыльное решение. В моем понимании, смысл интерфейса именно в том что бы разделить использование и реализацию, а не в том что бы использовать их в качестве пометок/маркеров.
Из существенных различий, пожалуй, скорость: instanceof работает на полпорядка быстрее на простой синтетике (у меня примерно в 3.5 раза) вне зависимости от того где в иерархии был добавлен маркерный интерфейс по сравнению с проверкой аннотации только на классе объекта. Если же искать аннотацию во всей иерархии, то это ещё медленнее, т. к. требует её обхода.
Попробую объяснить, почему именно не уловили, и почему магия.
Дело в том, что класс и не станет комментируемым. Объект этого класса можно будет откомментать.
Реализация комментирования будет в функциях addComment и showComments, которые вне класса и которые принимают Commentable объект. У вас в системе могут быть Юзера, посылки, страны, заказы комментируемыми, просто путём навешивания Commentable.
В самом Commentable интерфейсе будет обозначен простой метод. Например, getSystemwideUniqObjectId. Больше ничего и не нужно.
Функционал комментирования — он не внутри этого класса и будет вешать комменты на этот уникальный айдишник. (Это к примеру).
Дело в том, что не «я класс, реализую… методы», а объект этого класса можно сравнивать с другими объектами классов, которые реализуют IComparable.
То же самое с любыми другими базовыми Интерфейсами. Serializable — значит объект этого класса можно серилизовать, Iterator — значит можно сделать foreach по этому объекту.
сам собой класс не станет комментируемым
Дело в том, что класс и не станет комментируемым. Объект этого класса можно будет откомментать.
пока вы не напишете свою реализацию комментирования.
Реализация комментирования будет в функциях addComment и showComments, которые вне класса и которые принимают Commentable объект. У вас в системе могут быть Юзера, посылки, страны, заказы комментируемыми, просто путём навешивания Commentable.
В самом Commentable интерфейсе будет обозначен простой метод. Например, getSystemwideUniqObjectId. Больше ничего и не нужно.
Функционал комментирования — он не внутри этого класса и будет вешать комменты на этот уникальный айдишник. (Это к примеру).
Ну а насчет «не уловил суть» — не вижу, чем ваш пример отличается от моего. Я привел в пример IComparable — существующий в стандартной библиотеке языка интерфейс, который говорит о том что объект класса, реализующий («на который навесили») интерфейс IComparable, имеет метод CompareTo, который можно вызывать, что бы сравнивать объект с другим
Я, класс, реализую вот такой набор методов, которые вы можете использовать
Дело в том, что не «я класс, реализую… методы», а объект этого класса можно сравнивать с другими объектами классов, которые реализуют IComparable.
То же самое с любыми другими базовыми Интерфейсами. Serializable — значит объект этого класса можно серилизовать, Iterator — значит можно сделать foreach по этому объекту.
Абстрактный класс — наследование реализации.
Интерфейс — наследование требований.
В вырожденном случае абстрактный класс может быть ужат до интерфейса, но не наоборот.
Интерфейс — наследование требований.
В вырожденном случае абстрактный класс может быть ужат до интерфейса, но не наоборот.
Её нанимали в первую очередь для деверсификации штата сотрудников и из-за шанса, что она вывезет.
На медиуме очень много обратных статей, вроде я не буду работать в этом стартапе, так как в нём одни белые мужики.
На медиуме очень много обратных статей, вроде я не буду работать в этом стартапе, так как в нём одни белые мужики.
«В одной типовой программе я обнаружила безымянную функцию, которая передает значение другой функции и не врубилась в смысл происходящего. Но все остальные сразу-же поняли, несмотря на то, что до этого также не имели работали с бэкенд Javascript-ом! Они потратили полчаса, чертя для меня диаграммы с кучей стрелок и в конце-концов, опираясь на целый ряд метафор, я смогла кое-что понять. Потом, когда я наблюдала, как лихо они перебрасывают обратные вызовы, все равно для меня это оставалось мистикой и я самой себе казалось такой тугодумшей.»
это про меня прям
я как яваскрипт увидел, так до сих пор уже лет 16 не понимаю его, особенно эти анонимные функции
и так же не понимаю, как люди могут это вообще понять?
самый тупо язык, что мне встречался пока
«А теорию они подучили уже в колледже. Но я-то практиковалась в задачках с десяти лет и поэтому имею все основания сказать: программирование — охренительно трудная штука.»
всегда говорю, что программировать очень сложно и не понимал, как люди идут на программиста учиться, если компутер только для игрушек покупали, но слышали про большие зарплаты
это про меня прям
я как яваскрипт увидел, так до сих пор уже лет 16 не понимаю его, особенно эти анонимные функции
и так же не понимаю, как люди могут это вообще понять?
самый тупо язык, что мне встречался пока
«А теорию они подучили уже в колледже. Но я-то практиковалась в задачках с десяти лет и поэтому имею все основания сказать: программирование — охренительно трудная штука.»
всегда говорю, что программировать очень сложно и не понимал, как люди идут на программиста учиться, если компутер только для игрушек покупали, но слышали про большие зарплаты
Все просто же.
Многоуровневое собеседование могут себе позволить компании из топ-списка, просто потому что они могут себе это позволить. Когда очередь на собеседование прописана на 2 месяца вперед, можно выеживаться как угодно и устраивать многоуровневые 6-дневные собеседования. Правда потом и появляются топики, как на rsdn.ru/abroad, где люди попавшие в MS, жаловались в какое болото попали (что наверно очевидно, если олимпиадника посадить в огромный проект мелкие минорные баги фиксить, где творчества вообще 0, а рутины 100%).
У обычных же компаний обычно и собеседования адекватные. Год назад менял работу, специально проштудировал cracking the code interview и до кучи всякие задачки про гномиков, никто ничего оттуда не спросил, даже обидно было :) Вообще, такое ощущение что мода на такие задачи проходит — все уже про них знают, и к ним готовятся. Проще (да и эффективнее) дать небольшое тестовое задание, приближенное к предметной области.
Многоуровневое собеседование могут себе позволить компании из топ-списка, просто потому что они могут себе это позволить. Когда очередь на собеседование прописана на 2 месяца вперед, можно выеживаться как угодно и устраивать многоуровневые 6-дневные собеседования. Правда потом и появляются топики, как на rsdn.ru/abroad, где люди попавшие в MS, жаловались в какое болото попали (что наверно очевидно, если олимпиадника посадить в огромный проект мелкие минорные баги фиксить, где творчества вообще 0, а рутины 100%).
У обычных же компаний обычно и собеседования адекватные. Год назад менял работу, специально проштудировал cracking the code interview и до кучи всякие задачки про гномиков, никто ничего оттуда не спросил, даже обидно было :) Вообще, такое ощущение что мода на такие задачи проходит — все уже про них знают, и к ним готовятся. Проще (да и эффективнее) дать небольшое тестовое задание, приближенное к предметной области.
На последнюю работу лет 10 назад устраивался так:
— На том то, том то пишешь… ок, что такое ООП должен знать, так?
— Да, конечно, это…
— Ок, стоп, знаешь.
— А правда, что вот это писал и это. И сколько народа это писало?
— Да, вот к примеру…
Смотрят в глаза.
— Ок, верим. Когда сможешь выходить на работу?
— В понедельник.
— Давай, приходи.
Это люди, которые сами отличные программисты и руководители. Проработал более 5 лет, самые лучшие впечатления и от работы и от команды, которую они собирали(-ют).
— На том то, том то пишешь… ок, что такое ООП должен знать, так?
— Да, конечно, это…
— Ок, стоп, знаешь.
— А правда, что вот это писал и это. И сколько народа это писало?
— Да, вот к примеру…
Смотрят в глаза.
— Ок, верим. Когда сможешь выходить на работу?
— В понедельник.
— Давай, приходи.
Это люди, которые сами отличные программисты и руководители. Проработал более 5 лет, самые лучшие впечатления и от работы и от команды, которую они собирали(-ют).
Проходил собеседование в один ростовский стартап, на позицию сеньор-фронтенд разработчика. Эти ребята начали опрос с «какие бывают команды x86-процессора», как работают потоки, что такое TLS (не тот, о котором вы наверно подумали) и какие есть примитивы синхронизации. Порвали ребятки шаблон мне. Видимо, их фронтенд весьма специфичен.
А по-моему статья про то, что нет нормального и доступного обучения программированию.
А где вы его ожидаете получить? Чтобы научиться делать горшки, их надо делать. Выслушивать лекции по устройству гончарного круга не повредит, но этого совсем недостаточно. С программированием то же самое. Устраиваетесь на работу, и учитесь.
И где это Вы встречали работодателей, берущих «нулевых», но способных сотрудников?
(и повелительное наклонение неуместно)
(и повелительное наклонение неуместно)
> И где это Вы встречали работодателей, берущих «нулевых», но способных сотрудников?
Я беру, например. И многие берут. Если бы не было таких работодателей, взрослых программистов бы практически не существовало, т.к. замкнутый круг. ВУЗы и курсы не дают достаточной подготовки для профессиональной работы, самоучек мало, а на работу берут только со знанием предмета :)
> (и повелительное наклонение неуместно)
Между словами «устраиваетесь» и «устраивайтесь» есть существенная разница.
Я беру, например. И многие берут. Если бы не было таких работодателей, взрослых программистов бы практически не существовало, т.к. замкнутый круг. ВУЗы и курсы не дают достаточной подготовки для профессиональной работы, самоучек мало, а на работу берут только со знанием предмета :)
> (и повелительное наклонение неуместно)
Между словами «устраиваетесь» и «устраивайтесь» есть существенная разница.
> Я беру…
Что, сразу после школы берете?
> Между словами «устраиваетесь» и «устраивайтесь» есть существенная разница.
Недоглядел…
Что, сразу после школы берете?
> Между словами «устраиваетесь» и «устраивайтесь» есть существенная разница.
Недоглядел…
> Что, сразу после школы берете?
Месье, ваше остроумие обескураживает.
Естественно, не детей малых берём, а хотя бы курса с третьего института.
Месье, ваше остроумие обескураживает.
Естественно, не детей малых берём, а хотя бы курса с третьего института.
Ну так Вы тогда определитесь, или «устраиваетесь на работу, и учитесь» или «не детей малых берём»…
Неа, лучше уж Вы тогда попробуйте разобраться, чем отличается стоковое образование от профессиональной подготовки.
Странно, что синонимом слова «нормальное» у Вас является слово «стоковое».
Я не имел в виду «нормальное». Нормальное образование — это какой-то критерий качества, пригодности знаний для практических целей. Т.е. вот взял выпускника, а он уже может к работе приступать. Вот такое образование, оно в ПТУ бывает. Там учат работать, например, на токарном станке, и выпускник ПТУ по специальности токаря может выйти, и сразу начать работать на токарном станке. И даже будет не все заготовки пороть, а только какую-то часть. Выпускник ВУЗа имеет массу теоретических знаний, которые могут оказать ему помощь в дальнейшей профессиональной подготовке. Но он этой самой профессиональной подготовки не имеет от слова вообще. По крайней мере, в сферах, не связанных с преподаванием или научной деятельностью. И её ещё надо будет проходить, прежде чем он сможет делать какую-то работу.
До этого в колледже я написала, от силы, двадцать строк на C
У нас даже экономисты пишут код в универе :)
но не умеют отличить абстрактный класс от интефейса
temujin
Какие их отличия? :)
Целый пост на Хабре писали https://habrahabr.ru/post/30444/
Я на собеседованиях на вопрос «В чем различия между интефейсом и абстрактным классом?» все то, что написано в той статье говорил, правда не так широко. Но мне говорили, что ответ не правильный. :) Хотелось узнать секреты. :)
Просто сам вопрос не совсем корректный.
Более правильный «Для чего стоит использовать интерфейс, а для чего абстрактный класс?»
Просто сам вопрос не совсем корректный.
Более правильный «Для чего стоит использовать интерфейс, а для чего абстрактный класс?»
В восьмой джаве разница только в том, что в интерфейсе нельзя хранить состояние наследников.
Сейчас программирование во многом сводится к производству большого количества кода, не имеющего отношения к бизнес-логике, но требуемого фреймворками, библиотеками или самим языком. Для того, что бы хорошо писать такой код, математику можно и не знать.
А вот что бы реализовать сложный алгоритм, убедится в безопасности и эффективности кода — здесь математические навыки будут очень кстати.
Или если программировать на декларативных языках, Haskell, Prolog и тд. Сами языки очень просты и осваиваются новым работникам быстро, но требуют умения мыслить математически.
Да и то же наследование из ООП математику понять будет легко, если излагать ее через теорию категорий и логику первого порядка, а не через метафоры для школьников, и это понимание будет более надежным.
А вот что бы реализовать сложный алгоритм, убедится в безопасности и эффективности кода — здесь математические навыки будут очень кстати.
Или если программировать на декларативных языках, Haskell, Prolog и тд. Сами языки очень просты и осваиваются новым работникам быстро, но требуют умения мыслить математически.
Да и то же наследование из ООП математику понять будет легко, если излагать ее через теорию категорий и логику первого порядка, а не через метафоры для школьников, и это понимание будет более надежным.
Да, сейчас модно копировать вопросы собеседования как в Гугле… И часто это делают именно HR-ы, потому что этим «лучшим» практикам их обучили на модных курсах подбора персонала, люди далекие от реального программирования.
В итоге на собеседовании вы получаете математические и логические задачи которые якобы покажут какой вы спец. по программированию. Но! Программирование это не только алгоритмы, это еще черт возьми и хорошее знание технологий и умение решать конкретные реальные проблемы, не связанные с абстрактными алгоритмами и задачами!
Меня просто удивляет как такие конторы набирают команды разрабов. Ведь команда это живой организм, как человек. В нем должны быть разные люди и они должны гармонично сочетаться… кто то силен в алгоритмах и математике но не любит рутину, кто то может писать код быстро если ему дадут алгоритмы, кто то может делать рутину и заниматься техподдержкой, кто то силен в какой то области технологий но пишет хавнокод в другой, кто то лидер, кому то на все пофиг. Люди в большинстве своем сильны только в небольшой области знаний и мало гениев реально умеющих все…
В итоге на собеседовании вы получаете математические и логические задачи которые якобы покажут какой вы спец. по программированию. Но! Программирование это не только алгоритмы, это еще черт возьми и хорошее знание технологий и умение решать конкретные реальные проблемы, не связанные с абстрактными алгоритмами и задачами!
Меня просто удивляет как такие конторы набирают команды разрабов. Ведь команда это живой организм, как человек. В нем должны быть разные люди и они должны гармонично сочетаться… кто то силен в алгоритмах и математике но не любит рутину, кто то может писать код быстро если ему дадут алгоритмы, кто то может делать рутину и заниматься техподдержкой, кто то силен в какой то области технологий но пишет хавнокод в другой, кто то лидер, кому то на все пофиг. Люди в большинстве своем сильны только в небольшой области знаний и мало гениев реально умеющих все…
Sign up to leave a comment.
Дорогие стартапы, хватит задавать математические задачки, чтобы понять умею-ли я программировать