Андрей Сергованцев

ИМХО
1) Обо мне – не стал бы писать, кому какая разница какой я коммуникабельный, проактивный и эмпатичный человек. Лучше привести примеры работы с ссылками на сайты и с подробно расписанными кейсами. Не просто простыня из рендеров страниц, а подробное описание: Цель, задачи, трудности, как решил, какой стек, результаты работы. Условно, можешь это писать на каком-нибудь medium и просто подтягивай на страницу портфолио. (Medium.com явно будет индексироваться лучше, чем твой сайт)
Еще прикрепи свой github и активно веди его, отмечай какие-то свои находки, веди проекты, разрабатывай инструменты для сообщества и так далее.
Да, контакты тоже нужно не забыть прикрепить.
2) Всё, что не стесняешься приложить (телеграм, почта, социальные сети) [почтовый адрес не надо]
3) Ты конечно можешь сделать "просто и понятно как у эпл", но зачем. Сделай как тебе нравится и как тебе хочется, ведь к тебе придут люди предложить работу и лучше пусть их зацепит то, что нравится тебе, тогда ты будешь кайфовать от работы.

Добавить в портфолио

UPDATE: реальные тестовые задания и разборы здесь, ответы на все вопросы из поста в моем блоге об обучении react.

не включая основы js

Извините, но стандартная задача, про "напишите функуцию add, которая при вызове add(1)(2) вернет 3" - многих положила на лопатки =) Поэтому будьте готовы..

React
0) Какую проблему решает react ?
1) Мгновенно ли срабатывает setState? Если нет, то как выполнить код, который 100% выполнится после того, как новый state будет установлен?
2) Зачем многие постоянно пишут в constructor: this.FUNCTION_NAME = this.FUNCTION_NAME.bind(this) и отсюда вопрос вытекает чему равно this в разных местах вашего компонента...
3) в каких методах жизненого цикла стоит выполнять xhr запросы? В каких стоит "обновлять state на основе props"?
4) Что будет если вызвать this.setState в render методе компонента?
5) зачем нужен componenWIllUnmount, приведите пример..
6) Контролируемые, не контролируемые компоненты
7) Как организовать роутинг в реакт приложении? (ответ: взять react-router - подходит, но было бы круто, если бы вы рассказали, как он примерно работает)*
8) Зачем нужны propTypes? Что происходит с ними в production сборке?
9) Как можно удобно "отлаживать" чужой код приложения, написанного на react (намек в сторону React devtools)
...

Redux
0) Какую проблему решает redux?
1) Зачем многие создают типы действий NAME_REQUEST / NAME_SUCCESS ? А заодно, что такое "действие", а что такое "создатель действия"...
2) Что такое редьюсер? Можете написать простой редьюсер без react/redux?*
3) Для чего нужен redux-thunk? Как он работает? Напишите (можно псевдокод) асинхронный создатель действия (либо, если надоело говорить "терминами" - асинхронный aciton)
4) Как компоненты приложения получают "пропсы" из "стора"?*
5) Можно ли (и считается ли это нормальным) использовать state, если используется Redux?
6) Почему в reducer'ax мы возвращаем новые объекты? Приведите пример, когда вы возвращаете новый объект, а когда тот же самый.
6.5) А так же, "как в js вообще это работает?". Например:

let obj1 { name: 'Test', age: 100 }
let obj2 = obj1
obj2.name = 'Test_new'

Что будет в obj1, почему? В каких случаях объекты могут быть равны?
7) Что возвращает функция connect (из react-redux)?
...

Общее:
0) package.json
1) Webpack, gulp, etc...
2) node.js
3) promise

Что-нибудь практическое:
1) Как бы вы валидировали форму, если ошибки валидации приходят после submit'a ее на сервер..
2) Почему не работает следующий код, сделайте чтобы работало
...
На истину не претендую, но такие вопросы имели место быть на собеседованиях. В беседе можно многое разузнать дополнительными вопросами и так далее. Так же, если часть вопросов вам неизвестна - не беда, многие и на половину ответить не могут.

p.s. возможно дополню...
p.p.s. звездочкой отметил, на мой взгляд не самые необходимые для junior-собеседования вопросы.

Давай так, котлеты отдельно - мухи отдельно. Твоя проблема это на самом деле две проблемы:
1. Нарушен режим сна. Это поправить легче всего. Вне зависимости от того во сколько ты ляжешь сегодня спать, встань завтра в 7:00, на следующий день повторить и зациклить. Первые два дня будет тяжело - потом все выправится.
2. Ты не умеешь в тайм-менеджмент, что в 21 веке как-то совсем прискорбно. Поправить это посложнее, но тоже реально. Списки дел, дневник, планирование дел на конкретные часы - все это фигня полная и в эпоху постмодернизма не работает. Все что тебе нужно сделать на первом этапе это прочесть книгу "Getting Things Done" Дэвида Аллена, она совсем небольшая и в ней есть все ответы. Прочесть можно за день, если штудировать то за 2-3.
P.S. Обязательно прочти "Семь навыков высокоэффективных людей" Стивена Р. Кови. Название может казаться пафосным, не обращай на этот факт внимания, книга просто маст рид.
P.P.S. Если после этого останутся вопросы - пиши, с удовольствием отвечу.

Есть еще хороший маркер - заказчик думает что лучше вас знает как делать работу, как частный случай - "This will take no more than an hour for a good professional"

Вот, например, надо сделать простейшую фотогалерею.

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

$image= new Image(); //создаем пустой объект имаж, чтобы иметь его настройки(таблица, поля...)
$gallery = new Collection ($image); //создаем новую коллекцию объектов типа имаж, пока пустую.
$gallery->getCollectionByField(array("galleryid"=>"64")); // инициализируем из базы, используя
// ид галереи, теперь в гэлери одной строчкой мы загрузили все картинки в свойство (например),
// $gallery->collection  и можем к ним обращаться как к элементам массива, и в свойстве
// $gallery->collection[1] будет объект типа $image. Как вариант реализации.

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

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

ps:
ваш код - почему бы не писать так:

$post=BLOG::getPost($айди_поста);
// меняем 
$post = new Post($айди_поста);

echo $post['content'];
// меняем 
echo $post->content; // не обязательно так, может вот так:
echo $post->getContent(); // тогда при выводе можно будет сделать какую-то предварительную обработку, 
//заменить тэги, еще что-то...

$comments=BLOG::getComments($айди_поста);
// меняем
$comments = new Comments($post);
echo $comments->getTree(); // хотя тут скорее всего от вьюшки зависит, я бы тут возвращал не 
// строку, а массив для итератора, это правильнее для разделения на мвц, мухи отдельно - 
// котлеты отдельно, в смысле код и хтмл.