Собеседования - Что вам не нравится в X?

Так он тебе и говорит, что mercurial, как и любая другая DVCS, тебе не нужен.

«Это был сарказм, Шелдон» © Я понял, что он говорит, но поломало опускаться до банальностей о том, что он не умеет читать. Если бы прочитал начало подветки, что я писал, то вопрос бы у него не возник :)

Какие недостатки у ping?

Хочешь сказать, это идеальный продукт? :)

Навскидку: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=iputils-ping;dist=unstable

Что не отменяет и наличие недостатков.

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

Человек, взявший инструмент в первый раз и есть плохой, неквалифицированный пользователь.

Я бы поспорил что скорее неквалифицированный пользователь эти «недостатки» сразу же найдет. А «квалифицированный» и «с нулевым опытом использования конкретного инструмента» - это всё-таки немного разные понятия.

В этом случае он может назвать недостатки неверно. Но — назовёт.

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

И в этом случае он всё равно может указать на недостатки.

Которые исчезнут после исправления, и больше на них он указать не сможет.

А вопрос не про ворчание, а про знание недостатков.

Если человек адекватен, то недостатки мешающие работе отсеются на предыдущем этапе. А если «недостатки» инструмента не мешают работе, то разве это недостатки? Вот у go такой ужасный недостаток есть - где-то он go, а где-то он golang. Капец, как жить теперь? На rust'е писать?)

Вот у go такой ужасный недостаток есть - где-то он go, а где-то он golang. Капец, как жить теперь?

Да. Название неудачное. Это недостаток, при чём вполне объективный — затрудняет поиск информации. Небольшой, но недостаток.

На rust'е писать?)

Если для тебя критично — может быть. Для мне — не критично. Но далеко не все недостатки — критичны.

Ты путаешь баги с недостатками. Если меня спросят какой баг в Go меня больше всего аффектил - я c легкой душой расскажу про «резолвинг „как у GNU“ при CGO_ENABLED=0 в отсутствии nsswitch.conf». А вопрос про недостатки языка подразумевает что яйца у чувака, который сидит напротив тебя, круче чем у Роба Пайка, а ты пришел тут ему про генерики рассказывать.

Ничего он не затрудняет, если ты не junior, конечно.

Ты путаешь баги с недостатками

Баги уже не являются недостатками?

А вопрос про недостатки языка подразумевает что …

Это твоя собственная трактовка.

Ничего он не затрудняет, если ты не junior, конечно.

Ладно, проехали. Молодой, горячий, категоричный и идеализирующий :)

В любом ПО есть баги. Является ли это недостатком ПО?

Если багов много, они кого-то аффектят, но их не исправляют - да.

Но в общем случае, особенно если эти баги уже нашли, но всем на них пофиг - нет.

А если он не будет без него страдать, то зачем он нужен?

Чтобы страдать, нужно знать, чего лишился.

иногда пушит коммиты содержащие строчки «<<<<<<<< HEAD», а другая часть приносит мержи из 10 веток без ребейза... Правду ли люди говорят что mercurial спасает от подобного рака головного мозга?

Правду ли люди говорят что mercurial спасает от подобного рака головного мозга?

Насчет «<<<<<<< HEAD» - такого не было. Отчасти потому, что в Mercurial по дефолту merge tools нормальные, отчасти - при конфликете файлы помечаются и закоммитить их просто так невозможно. Зачем делать ребейз перед мержем - не понял, в Mercurial rebase - это вид мержа (думаю, в git - тоже).

пинг разный бывает, уточни аффтара пакета :)

Спуфонька, так тебе с твоими запросами в самый раз осваивать Common Lisp. И, разумеется, Emacs и slime.

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

Большинство вопросов по проблемам Go пропадёт при знакомстве с тем как он развивался, и тем как устроен этот процесс. Вопросы по области применения и на что обратить внимание при разработке того или иного сервиса - это отдельные вопросы, странно отвечать на них когда спрашивают про недостатки.

Если прям упереться, и пойти эти недостатки искать, то можно конечно найти:

https://github.com/golang/go/issues?q=is:issue is:open label:LanguageChange

Но вот врядли там есть что-то, что beastie ожидает услышать от кандидата. А сам я не уверен что смогу получить какую-то инфу, от рассказа про такой недостаток, кроме как что кандидат знает что я упоротый интервьюер и реально заморочился подготовиться к собеседованию под меня.

Вот к примеру, когда-то я думал, что вот такое определение символов int a, b, c = 0;

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

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

А вопрос про недостатки языка подразумевает что яйца у чувака, который сидит напротив тебя, круче чем у Роба Пайка, а ты пришел тут ему про генерики рассказывать.

Почему? Какие-то странные комплексы. Почему я не могу спросить про недостатки, например, хаскела, несмотря на то, что ни строчки на нем не написал?

Собеседования - Что вам не нравится в X? (комментарий)

как ты тогда достоверность ответа оценишь

Можешь спросить, а я отвечу «ну это функциональный язык такой, нормальный, явных недостатков, если ты не приверженец Lisp, нет».

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

Да насрать мне на достоверность тридцать три раза. По тому, в какой плоскости ты станешь отвечать на вопрос, я пойму чего ты стоишь гораздо лучше, чем углубляясь в дискуссию «является ли XXXX недостатком, багом или фичей».

я пойму чего ты стоишь гораздо лучше

ожидаемый уровень оплаты можно спросить прямо, а не вопросами про хаскель

ожидаемый уровень оплаты

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

а знания можно оценить по выполненным работам, примерам кода в гитхабе и прочим контрибуциям в свободное ПО

Тоже не всегда. Встречал неплохих спецов, у которы не было github аккаунта. Но это конечно плюс, если есть и есть на что посмотреть.

если спец никогда не пилил для себя что-то из любви к искусству, то это имхо плохой спец

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

А мне уже будет всё равно, потому что я на Haskell-разработчика пришел собеседоваться, а ты хочешь то ли CTO который организует IT-отдел и наладит найм, то ли эникейщика который прочитал на wikipedia про haskell.

Ну и если ты вдруг уже успел понанимать «IT'шников» которые умеют словами красиво русалок на мясо пускать, то мне в такой компании точно делать нечего :).

В любом языке есть проблемы и ты, если их используешь постоянно, должен знать.

сколько ни юзал Паскаль, проблем не видел. Так же и с ассемблером, проблем не было. Ну кроме прерывания int 21h, но это проблема не языка, а DOS. С тринадцатым прерыванием проблем не было.

а я бы взял :)

Харе оправдываться. Нормальные пацаны палят кандидата по первым секундам. Если прёт - имеем дело. Если отторгает (запах, поведение, сука - умный и т.д - Бабенэ). А вот Ваши формулировки: " а не попи@#ть ли нам, есть ли, сука, жысть на марсе?", от обезьяны не требуются. Или Вы ищете себе партнёра, а не исполнителя? Печаль, короче...

По Лурку: резко, бешенно:

В общем, у тех, кто инструментом не пользуется или пользуется только поверхностно, такого опыта нет.

Дело не в инструменте, дело в кандидате (и своём самом ценном - времени).

Встречал неплохих спецов, у которы не было github аккаунта.

Мне жаль, что так мало у Вас опыта.

Серьёзные пацанчики не палятся. Им Ваш «Базар» и даром не нать. За ними бегают... Ну да ладно.

Ладно, проехали. Молодой, горячий, категоричный и идеализирующий :)

Мягче. Корм должен настояться ;)

ты тут-же на лету код исправил, а твой сервер как работал, так и работает без перебойно.

Я, короче, падаю ниц. Круто ты умеешь троллить.

ты тут-же на лету код исправил, а твой сервер как работал, так и работает без перебойно.

Я, короче, падаю ниц. Круто ты умеешь троллить.

Я слегка пригорел. Зырнул в твой прошлый пост. Пацаны, простите! Не знал!

Дополню ЦыТаТой: «Едадил — лучшее мобильное приложение про скидки в магазинах в России и Европе.»

Пошёл, сука, перенимать я опыт у второго левела..

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

Да, это был самый четкий коммент в треде.

Если бы я openbsd'шный линканул, то у него был бы недостаток что хрен ты его где найдешь :).

есть ещё busybox-ping

Если тебе не нравится инструмент - нафига учиться с ним работать?

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

Фанатики не нужны.

Я знаю 15 языков программирования, половину из них активно использую сейчас или использовал в далёком прошлом. Для каждого могу привести список не только достоинств, но и недостатков. При этом недостатки не вызывают у меня какой-либо негативной реакции - ведь я прекрасно понимаю, что в правильных задачах недостатки правильного языка незаметны, а достоинства очень даже. И да, у меня нет любимого языка программирования. Мне нравятся все языки, которые я знаю, но какой я бы предпочёл использовать зависит от задачи. Я буду скептически относиться как к написанию прошивки для микроконтроллера на Python (хотя технически это нынче возможно в некоторых случаях, но я бы не советовал), так и к написанию веб-приложения на plain C.

Это всего лишь замыливание взгляда и ничего хорошего в этом нет.

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

Люди делают ошибки, это их неотъемлемое свойство, даже если знать на 100% все особенности типов JS это не исключит вероятность банальной опечатки или «перепутал» (если проект сложный, то забыть пару деталей про его кишки - обычное дело).

Однако, динамическая типизация открывает хорошие возможности для метапрограммирования. Где-то это полезно, где-то не особо.

Главная и основная проблема Assembler - привязка к одной архитектуре процессора. Для многих задач это сразу отметает данный язык. Хотя если мыслить только виндой и только x86, то может прокатить. Но на винде MS продвигает UWP и .NET, так что лет через 10 и при таком раскладе с асмом могут быть трудности.

Главная проблема Pascal - значительно меньшее количество библиотек и хуже оптимизации компилятора по сравнению с C/C++. Также компиляторы поддерживают меньшее количество платформ (а компилятор C есть для любой кофеварки).

Заметь, я ничего не говорил про многословность, синтаксический сахар и шансы выстрелить себе в ногу. Сугубо объективные недостатки, но однако наличие недостатков != «плохой язык» (у всех языков они есть), но должно учитываться при выборе инструмента для решения задачи. Например, писать мобильное приложение на Assembler - плохая идея с какой стороны не подойти - потому что тот же Android работает как минимум на 4 архитектурах (x86, arm, arm64, mips) и изучать 4 разных ассемблера и писать 4 разных версии одного и того же - такое себе удовольствие, при том что на 99% задач разницу в производительности и размере никто не заметит, а в 1% случаев хватит написать на асме небольшие критические участки.

Почему бы интервьюеру не задать конкретный вопрос, типа «мы тут ещё микроконтроллеры на Python программируем, что вы об этом думаете»? Ведь то что микроскопом не удобно забивать гвозди не относится к его недостаткам?

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

Python как минимум не очень шустрый (даже из интерпретируемых языков - тот же JS быстрее), а ещё у него многопоточность имеет специфику (GIL). Это значит, что, например, сайт или прикладную утилиту написать на нём можно (там где основная нагрузка на библиотечные методы или I/O), а вот программу вычисления миллионного знака числа Пи лучше писать на C/C++.

Пример с ассемблером и мобильными платформами позабавил. Многие приложения до сих пор пишут на разных языках, полностью самостоятельные версии под каждую платформу.

Не претендую на единственно верное мнение, но по-моему необходимость писать отдельные приложения это недостаток именно подхода, а не используемых технологий. То есть, надо сравнивать два подхода к конкретной задаче («единый кроссплатформенный код на Qt или React» vs «отдельные приложения на Java и Obj-C»), а средства их реализации это только аттрибут подхода, а не сам объект.

Не кажется что сравнения «Python vs Assembler» и «Молоток vs Микроскоп» не так далеки друг от друга, что различие основных функций в одном случае можно считать недостатком, по твоей логике, а в другом - нельзя?

программу вычисления миллионного знака числа Пи лучше писать на C/C++

Всё зависит от условий задачи. А условий задачи в изначальной постановке вопроса про недостатки - нет.