Какой код показать заказчику/работодателю?

На что лично я бы обратил внимание:

1. Оформление кода. Весь код должен строго придерживаться одного стиля. Идеально, если он будет соответствовать актуальному стандарту, например PSR-2. Обязательно говорящие имена переменных, никаких a, b, row, foo и прочей жести. Именование классов в соответствии с названием используемого паттерна. Код должен быть самодокументирующимся. Обязательно везде PHPDoc комменты в соответствии со стандартами. Комменты с описание особо сложных мест.
   
   
2. Если это фреймворк - то соответствие принятым в фремворке стандартам и рекомендациям. Никакой самодеятельности.
   
   
3. Общая архитектура проекта. Никаких портянок в контроллерах. Чёткая разбивка кода по сервисам. Никаких адовых функций по 100500 строк. Логичное разделение кода по классам. Применение подходящих паттернов для решения задач.
   
   
4. Минимум велосипедов. Если есть отличная библиотека для решения задачи, а человек пишет свой говнокостыль - это явный минус. Если есть готовая функция - аналогично. Кроме случаев, когда готовая библиотека чем-то не подходит.
   
   
5. Использование менеджера пакетов для проекта. Ну думаю в 2016 году без него уже никто не кодит:)
   
   
6. Думаю разбираться в работе сложных алгоритмов я бы не стал, и ограничился тем, что перечислил выше.
   
   
7. Я бы отдавал предпочтение коду на фреймворках. Так же не плохо, если это сборная солянка на готовых компонентах, заточенная под свои задачи.
   
   
8. Полный самопис - это явный минус. Не использовать в наши дни хорошие готовые решения, делая вместо этого стрёмные, никому не понятные велосипеды - это глупость.
   
   
9. На CMS код можно даже не присылать. Там в любом случае будет говнокод. Сами CMS к этому обязывают:)
   

Вам приходилось оценивать чужой код, на что смотрели (ну кроме отступов и имён переменных) )))

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

Специально чтобы только показать в портфолио крутой проект вы не сделайте. Это слишком много усилий. Просто работайте. И покажите одно из своих лучших - очевидно одно из самых последних

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

В общем так:
Вычитывать код, вникать в его суть - никто не станет. Просто нет времени. Даже для сеньоров - проще нанять человека и проверить его на испытательном сроке, а на гитхабе смотрят примерно так:

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

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

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

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

У нас тестовые задания придумывали сами, давали комп с инетом и оставляли на 15-60 минут (в зависимости от уровня). Строго время не спрашивали, просто говорили - сделаешь - зови. Потом смотрели на решение, уточняли выбор решения и его правильность.
Единственный раз заподозрили нечестность, когда один кандидат звонил другу по телефону, чтобы тот ему подсказал. Искать готовое в гугле - не запрещается, но консультация с другим человеком - как бы читерство.