Anton Mashletov

куча старых фриланс-сайтов, код которых стыдно показывать, и все они не взлетели (не из-за меня): посещаемость 100 чел в день максимум

посещаемость не важна.
показывайте что есть.

пустой github-аккаунт

конечно не стоит.

пару intranet закрытых CRM - тут неплохо, но не могу продемонстрировать или дать на ревью

постараться договориться с теми, кому делали.
как минимум им еще нужна поди от вас тех. поддержка - пойдут навстречу.

Надо сделать портфолио на github.

Стоит ли мне сейчас судорожно заполнять эти пробелы? Делать какой-нибудь надуманный опенсорс, например.

Именно это я и делал...
Да, не хотелось, а тренд - навязывает... (к сожалению...)

Портфолио такая штука интересная... Вот я с WP работаю 10+ лет, опыта вагонище. А показать тоже осбо нечего. Либо старье, которое может быть вполне норм само по себе, но уровень то у меня уже совершенно другой, не репрезентативно. Все свежее, крупное и вкусное - под NDA. Опенсорса немного есть, есть контрибюшены в экосистеме WP, но этого вроде как мало. Что делать? Для себя я выбрал несколько проектов под NDA, поговорил с клиентами и получил добро показывать их непублично, оговаривая эту особенность с новыми клиентами при показе. Это дает плюсы – во-первых, если клиент решить связаться с владельцем такого сайта и спросить референс, я буду уверен что бывший клиент не сделает круглые глаза, а подтвердит мое участие в проекте и даст нормальную рекоммендацию. Во-вторых, новому клиенту такое уважение к NDA и клиентским данным однозначно придется по душе, они такое любят. Особенно крупные, у которых и деньги есть на разработчиков с рейтом выше среднего. При найме та же кухня.

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

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

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

Плюс указывает, что это выражение (Function Expression), а не Function Declaration. То же самое делают скобки.

не могу исправить какую-либо ошибку без гугла

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

самые базовые команды типа ls, cat, ln, sed, dpkg, apt, nano;

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

плохо знаю bash/sh, даже не знаю чем они отличаются;

для backend разработчика это очень плохо, bash простой язык, база учится за день-два(на хабре можешь поискать свежие уроки). Зная его и базовые команды( ls, cat ...) ты уже будешь чувствовать себя полубогом в системе, ну а далее дело практики.
Учи именно bash(это расширенный sh), во многих системах sh уже просто заменяют симлинком на bash.

если после перезагрузки система не загрузится, или GUI не загрузится, то я не в состоянии буду починить это

Админская работа. Разработчику обычно не надо. Но если хочется - можно освоить. Делается это в основном чтением логов, чтением логов, чтением логов и нудным гуглингом с применением вычитанного, потом длинными матами, потому что нифига не заработало, опять чтением логов, опять гуглингом... Работа интересная, но ... если есть склонность поадминить :)

не могу исправить какую-либо ошибку без гугла

Не поверите - и я зачастую не могу :)

писать какие-то сложные и длинные команды в одну строчку

Это и не особо надо и кстати, я тоже не особо люблю. Например, установка Calculate делается из консоли одной дилнной-длинной-длинной командой, и только такая ленивая жопа, как я, ставит Х, чтобы запустить графический инсталлер :D

плохо знаю bash/sh, даже не знаю чем они отличаются; не умею в vim

"Скрипач не нужен". Те, кто понтуются, что работают только в vim/emacs - они в основном понтуются. Те, кто работают - они вообще не понтуются :) Есть кучка консольных редакторов поудобнее vim - nano, pico, mcedit. Не знать sh - это плохо, но поправимо. Bash - это суперсет sh, его фичами можно просто не пользоваться :)

компилировать из исходников

Для работы в пакетном дистрибе типа бубунты умение компилить вручную не только не полезно, а вредно, если конечно не компилить свои программы :) Сборка программ в пакетных дистрибах должна быть исключительно пакетным менеджером! Ну, пока не научитесь разбираться в зависимостях, вручную удалять пакеты, ставить без зависимостей и подымать упавшую набок систему :)
Сборка из исходников и понимание того, что творишь - непременный атрибут source-based дистриба

Центральный показатель для бизнеса, а следовательно и руководителей, как людей представляющих интересы этого самого бизнеса - это коэффициент возврата инвестиций (ROI). Соответственно, сотрудник должен приносить компании больше денег, чем потребляет. Естественно, что чем выше разрыв между затратами и прибылью, тем лучше, поэтому фонд оплаты труда руководитель должен держать на том минимальном уровне, который гарантирует бесперебойную работу сотрудников. Один из факторов этой бесперебойности - низкая текучка. Сотрудников терять нежелательно. И чем ценнее для компании сотрудник, чем более он профессионален и/или чем больше на него завязано, тем дороже обходится его потеря. Натурально в деньгах. Придётся затратить больше, чем обычно, денег на поддержание работы без него. Придётся затратить деньги и время (те же деньги) на поиск, найм, введение в работу, возможно, обучение нового сотрудника. При этом он может оказаться совсем неподходящих и цикл придётся повторить. Или может оказаться просто хуже прошлого и эффективность отдела снизится. Поэтому, когда сотрудник приходит просить прибавку, руководитель оценивает может ли этот сотрудник уйти или только блефует, насколько легко его будет заменить, какой урон компании будет нанесён его уходом. Потом руководитель оценивает стоимость расширения ФОТ - есть ли резервы, какой сейчас ROI, будет ли больший ROI от реинвестиции этих средств во что-то другое? Если уход сотрудника будет стоить меньше, чем увеличение ФОТа, сотруднику откажут.

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

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

Собирать из исходников нужно в очень редких случаях, на столько редких, что знать как это делается вообще не нужно. Так что можно смело отмести этот навык.

Надо:
Знать где какие логи есть и уметь их читать, решать ошибки.
Всякие банальные вещи, типа запуск/перезапуск демона, убить процесс, уметь читать баш-скрипты и чуть-чуть писать (на уровне что-то подправить и чтобы не поломать всё к чертям)

Для бекендера надо уметь устанавливать и настраивать тот софт с которым работаешь: nginx, apache, mysql, postgres, redis, mongodb и так далее.

Vim можно вообще не знать, в *nix обычно есть редактор проще, типа nano, joe или вообще mcedit.
Самое главное - научиться выходить из vim прежде чем испортишь файл ;-)

Если работаешь с языком, у которого есть свой пакетный менеджер (npm, yarn, pip) нужно уметь установить его и разруливать ошибки при установке через эти пакетные менеджеры.
Например для python-pip требуются установленные компилятор и заголовочные файлы питона. Имею ввиду, что такие тонкости надо знать.

ssh само собой надо уметь настраивать, генерация ключей, настройка авторизации по ключу, копирование файлов scp.

git настраивать bare-репозитории чтобы заливать на сервер и там же разворачивать, при работе без сторонних сервисов типа github, bitbucket.

Ровно настолько, чтобы хорошо выполнять свою работу: писать рабочий back-end код.
Что изучить:
1. https://debian-handbook.info/
2. qref.sourceforge.net/Debian/reference/index.ru.html

потому что, фактически, ваше выражение выглядит вот таким образом:

var x = 0
if (6 || (5 && (x = 1))) document.write(x); // 0

логический оператор || работает следующим образом: если первый операнд можно привести к true, остальная часть выражения не вычисляется.

https://tc39.github.io/ecma262/#sec-binary-logical...
вторая часть п.12.13.3 касается как раз указанного в начале обсуждения случая.