Михаил Р.

Все есть в коде

Другое дело что это сделано реактивно

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

СЕО - не только работа по чеклисту, настройка тех. части и написание текстов, давно уже СЕО - совокупность работы маркетолога, программиста и дизайнера, ну и где-то там копирайтер, и самая ответственная работа тут у маркетолога-аналитика, который будет анализировать сайт, поведение и стараться сделать сайт лучше, составлять ТЗ на разработку новых компонентов, которые упрощали бы пользование сайтом, давали новый полезный функционал и, собственно, все то, что было бы необходимо для того, чтобы посетитель нашел ответы на все его вопросы, иными словами сделать так, чтобы сайт с ним "говорил" не хуже манагера-консультанта в магазине.

Это такой продукт, который можно улучшать бесконечно.

Заходите на страницу с объявлением и ищите это:

<span class="show-phones" id="tm-telephone-body" data-url="/a/ajaxPhones?id=28104015" data-id="28104015">
  Показать телефон
</span>

Далее берёте ссылку из атрибута data-url и выполняете запрос с заголовком XMLHttpRequest:

curl -X GET \
  'https://krisha.kz/a/ajaxPhones?id=28104015' \
  -H 'x-requested-with: XMLHttpRequest'

В ответ получаете:
["+7 707 892 8095"]

Забыли вызвать родительский конструктор в потомке: Construct1.apply(this, arguments);.

Это функциональный стиль.
Посмотрите про прототипный стиль тут https://learn.javascript.ru/prototypes

Это не резюме, это набор слов, ничем Вас не выделяет из общей массы и даже делает низовым в списке общей массы.

1. Такой кучи тегов даже у меня нет)) Если Вы знаете названия технологий, не говорит о том, что Вы знаете сами технологии. С Вашим опытом никто не поверит, что Вы имели реальный опыт со всем этим, а не просто hello world написали. Выберите те, в которых по Вашему мнению Вы лучше всего разбираетесь.

2.

Отличное знание WinForms, ASP.NET, LINQ и WPF. Паттерны: MVVM, MVP, Repository, IoC.

Для третьекурсника звучит самонадеяно. При такой формулировке на техническом собеседовании будут проверять "отличное" знание и я почти уверен, что Вы его провалите. Лучше сказать что-то подобие: имел опыт работы с, для реализации использовал технологии, имею <начальные> навыки работы с и т.д.

3.

Занимался исправлением мелких багов, написанием небольших SQL-запросов и unit-тестов, решал небольшие задачи.

Этим занимаются все разработчики, даже мидлы с сеньорами. Из Вашей фразы не понятно, какого уровня проект, какой стек, какие конкретно задачи Вы решали, как успешно Вы их решали. Работодателю нужно понимать Ваш реальный опыт и Ваши реальные возможности, а не нечто эфемерное "решал небольшие задачи".

4.

Если вспомнить css и html

Вот такое никогда не пишите. Лучше соврать или преувеличить, или даже написать "Отличное знание", но не так как Вы здесь сформулировали.

5. Не нужно оставлять ссылки на каждый проект в репозитории. Либо один, самый интересный на Ваш взгялд, либо одна ссылка на сам репозиторий. Работодатель пойдет туда только, если Вы заинтересуете его, не раньше. И ему пары файлов хватит оценить ваш уровень. Он не будет делать ревью всех Ваших проектов.

6. Опыта одного проекта мало. Где опенсерс проекты, где участия в хакатонах, где амбиции стартапов, посещение конференций? Работодатель хочет понимать как Вы заинтересованы развиваться, какие у Вас планы для дальнейшего роста. Он берет вас нулевым не из альтруистических побуждений, а с надеждой, что Вы быстро вырастите и вернете ему прибылью затраченное на Вас время. Из Вашего резюме видно только одно: я студент - дайте работу. А почему Вам, за какие такие заслуги и что с этого будет иметь работодатель - не понятно.

7. Я посмотрел Ваш код. Я бы не хотел, чтобы так писали у меня в проекте, начиная от именований и заканчивая некоторой логикой. Вас надо очень осторожно подпускать к реальным задачам и контролить, что Вы там напишете, просто чувствуется маленький опыт и до "отличных знаний" там далеко.

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

А если перед innerHTML вам что-то нужно сделать с "девственным" объектом?
Второй вариант лучше и читабельнее.
Не мешайте объявление переменной и работу с ней.

Плохо писать текст в элемент через innerHTML.
Второй вариант короче (на одну строку), и подходит тогда, когда потом нужно снова использовать element. Мне кажется, он предпочтительнее.
UPD: ой, я и не заметил (читая вопрос через смартфон), что в первом коде используется два раза равенство. Такой код работать будет, но он не явный, а неявные штуки - зло. Новичков он может поставить в ступор, т.к. не сразу ясно, что будет содержаться в переменной. И этот код также похож на опечатку, типа вероятно нужно было использовать сравнение (в данном случае, по названию переменной все понятно, но все же).

снг-бодишопов перфоманс ревью опен-сорс

Лец ми спик фром май харт.

По теме:
1). Каким образом вы сделали данные выводы? Вы описываете исключительно свои частные субъективные наблюдения или у вас есть какие-нибудь источники, может, HR-handbook, где прямо описывается практика вешания ярлыков? Не сочтите за какую-то грубость, просто так можно что угодно утверждать.

2). Вопросы, которые вы перечислили, вполне нормальные, мне на каждом интервью их задавали. Так проверяется мотивация, любовь к своему делу, уровень развития собеседника.

3). Развиваться на и вне работы - рядовое качество нормального айтишника. Если кто-то говорит, что уже достиг каких-то высот и дальше ему развиваться некуда, то этот человек либо лжёт, либо скоро устареет и потеряет ценность. Область IT меняется постоянно и относительно быстро и изучать что-то самому - суровая необходимость, ибо на ряд специальностей нет образовательных программ даже на Западе.

Вас взломали и у вас нет квалификации в расследовании взлома?
Делаем образ выключенной системы снаружи и бекапим его себе (зачем? Возможно найдете того кто сможет расследовать)
Берем список софта и убираем из него все, что не требуется для работы сервиса
- пхпмайадмин, фтп, как раз примеры такого софта

Сносим ОС (считайте что скомпроментирован рут и все тулзы ОС)
И ставим по хорошему мануалу с изрядной долей паранои (чаще всего одна статья не поможет - делайте свои заметки при установке)
Максимально изолируем все от всего
Наружу смотрит только вебсервер
ссш по портпиннингу (оно делается в полпинка, как на стороне клиента так и на стороне сервера)
Ваши цмс и скрипты должны обновляться регулярно
Следите за логами - часто взлом происходит в течении нескольких дней и простой греп по логам покажет, кого вам нужно забанить по ип и где поставить капчу

То что у вас есть бекапы делает вашу ситуацию в разы лучше

let result = array.reduce((acc, elem) => (elem > 0) ? acc + elem : acc, 0)

В общем добавьте стартовое значение аккумулятора = 0 перед закрывающей скобкой редьюса

const array = [-1, 0, 1, -5, 2, 3];

const result = array.reduce((acc, currentNumber) => {
  if(currentNumber >= 0) {
    return acc + currentNumber;
  }
  return acc;
}, 0);

Vue Native это обертка над React Native.
NativeScript это отдельный кроссплатформенный фреймворк который дает доступ к нативным компонентам платформы. И оба эти инструмента это не WebView.
NS использует движок V8 JavaScript для Android и JavaScriptCore для iOS. RN использует только JavaScriptCore
для обеих платформ. NS может в JS, TS, Angular и в этом году добавили официальную поддержку Vue за счет интеграции с плагином nativescript-vue
Можно в playground'e пощупать.

С RN я не работал, как и с VN, но мне интересно развитие NS.
В общих чертах RN и NS похожи, но отличаются архитектурой взаимодействия с родными модулями платформ.
NS работает c API интерфейсом платформы непосредственно в движке JS, отправляя вызовы и конвертируя данные на лету. При компиляции все XML компоненты передаются на собственные компоненты Android и iOS перед упаковкой в ​​двоичный файл платформы. В оф.документации все расписано
Есть хорошая статья в блоге NS, где они разбирают серию статей от Airbnb об опыте с RN.

Считаю что NativeScript недооценен сообществом, годный продукт.

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

Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

Что в монге определённо не нравится (и это не моя "идея", об этом пишут даже в учебниках под монге) - это тотальная денормализация данных. Которая в некоторых случаях может сыграть злую шутку. Например, все комментарии "поста" обычно хранятся прямо в самой сущности поста. Это очень удобно и довольно быстро работает, но... иногда это приводит к полному коллапсу. Особенно, когда у Вас перекрестная ссылочность.

Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
1. Очень низкая квалификация администратора БД проекта
2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.