В чем моя причина провала тестового задания Яндекса?

Question

[Максим Иванов]

Всем привет, недавно решил опробовать себя на летннюю стажировку в Яндекс, как раз каникулы будут. Учусь в Москве, 2 курс, вроде не глупый, не шибко умный, однако вроде бы стараюсь восполнять свои знания теорией, вот только практики не хватает, другой вопрос. Исходил из расчета, что на стажировке тебя из сопляка сделают солдатом, расчетливым и хладнокровным, коим сейчас не являюсь. Так вот, прислал заявку, мне выслали задание:

https://yadi.sk/i/IiGzf4GTqSMf4

Максим, здравствуйте! 
Спасибо за вашу заявку! 
Чтобы поучаствовать в отборе, решите, пожалуйста, тестовое задание. Оно находится по ссылке: https://yadi.sk/i/IiGzf4GTqSMf4 
На его выполнение у вас есть неделя. Мы сообщим вам о результатах в течение двух недель после выполнения тестового задания и расскажем о дальнейших шагах. Если у вас возникнут какие-либо вопросы, напишите нам, мы обязательно ответим. 
Желаем успехов! 
-- 
С уважением, 
Кривова Юлия 
Яндекс

Спрашивал подробности, по почте, как конкретно можно решать задачу, не отвечали. Ну, как понял задачу, так и стал решать ее. Выслал отчеты:


Ссылка на текст задач и решения:
https://github.com/splincode/codework

Через неделю ответили:

Максим, добрый день! 

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

С уважением, 
Кривова Юлия 
Яндекс

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

Вопрос к публике: Что я не так сделал, что поставило на мне крест? Может просто быдлокодингом занимаюсь, так как исправляться, что изучать, и как правильно надо было решать эти задачи? Какой опыт из этого можно извлечь? Стоил ли вообще лезть в эти стажировки крупных компаний, если даже нет боевого опыта, да и как этот боевой опыт получить, когда не берут толком никуда?

Спасибо.

Comments

[Максим Иванов]

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

Answer 1

[Сергей Протько]

Ну давайте я покритикую:

возьмем файлик

1) вы не разобрались как объявлять методы у прототипов с новой нотацией `class`:

class Travelsort {
    constructor() {}
    sortTickets(tickets) {}
}

2) вы не умеете пользоваться исключениями.

if (!Array.isArray(cards)) {
    throw new ValueError('Wrong input');
}

3) использование let там где должен использоваться const

4) в принципе использование переменных там где их быть не должно

5) вы зачем-то реализовали свою функцию сортировки, я не увидел в требованиях отсутствия возможности использовать старый добрый Array.prototype.sort

6) Общие замечания по кодинг стайлу. snake_case там где должен быть camelCase, пишите с большой буквы то что должно быть с маленькой и т.д.

7) нарушения принципа единой ответственности. У вас объеткт умеет и сортировать и писать куда-то. Это категорически плохо.

8) Если исправить 7-ой пункт то наш класс превращается просто в функцию.

Далее... берем следующий файлик

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

2) вы зачем-то тут в прототип объекта строки впихиваете функции для парсинга CSS. Таким образом мы нарушаем принцип единой ответственности. Да и в целом расширять без надобности прототипы объектов как-то не ок.

Чуть дальше проскролил - вы пытаетесь расширить прототип строк для того что бы добиться API jquery? ух, батенька.

3) очень много дублирования.

4) очень плохо с protected variations.

Справедливости ради, ваш код входит в категорию ">50% JS кода", так что не расстраивайтесь. Просто для работы в яндексе нужен чуть более высокий уровень и понимание вещей.

Comments

[Максим Иванов]

1) Я так и хотел вначале сделать, но там не работают приватные свойства, почему?

class Travelsort {
let list; // не правильно, однако с точки зрения С++ приватное свойство
constructor() {}
sortTickets(tickets) {}
}

ну да ладно, тогда, если в конструкторе объявить let list. Почему sortTickets() не видит эту переменную, потому что она не глобальная, а как ее глобальной сделать?

2) Очень редко исключениями пользовался, всегда пользовательскую обертку писал, даже на С++ слышал, что try{ } catch() { } тоже не всегда используется из-за потери производительности.

ValueError - я так понял, наш класс исключений?

3) const там где что-то не изменяется, у меня там каждая переменная-массив была подвержена изменению в дальнейшем, если только len - переменная размера массива, но это тоже частный случай, привычка var писать осталась. К тому же, в будущем, мы можем использовать ту же переменную len для хранения размера другого массива.

4) И где же не должно быть переменных?

5) Так я же сортировал исключительно по словам, придумывал свой алгоритм, или стандартная сортировка бы прокатила? Хм, тогда у меня класс практически пустой был бы

6) printError ? и sort_ticket?

7) Ну писать он может только свой собственный приватный список маршрутов, разве он не может иметь интерфейс вывода? Странно..

8) В том и дело, тогда как надо было решать задачу?

[Максим Иванов]

По второму файлику:
1) Ну вот, не знаю, как комментировать правильно, увы, для себя оставлял комментарии

2) ну, да, я знал, что расширять прототипы объектов не очень хорошо, как раз переводил одну статью: https://habrahabr.ru/post/281110/#thirteen

но все же решил потетстить этот момент, но уж, очень удобно без названия объекта просто в скобках указать (dom) и применять к нему методы, удобно и работает на примере моего решения СЛАУ, и циклов блоков

('#element').html('code');

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

3) Дублирования много, но я ведь и так в отдельные функции все вытаскивал, для каждого нового метода

4) protected variations, а что это такое? и как с этим работать?

[Максим Иванов]

более высокий уровень - что для этого посоветуете?

[Сергей Протько]

splincodewd:

1) ну разберитесь с синтаксисом, это не объявление приватных свойств, это переменные. Ну и да, в js нет приватных свойств, инкапсуляция достигается там через модули.

2) да, исключения пагубно влияют на производительность, но в продакшен коде у вас не должно вообще возникать исключений (в идеале). Если исключения начинают влиять на производительность js кода - стало быть у вас где-то баг.

3) вопервых вы меняли сам массив, а массивы в js хранятся по ссылке, то есть можно было смело использовать const. Во вторых вместо мутации состояния (к слову забыл упомянуть что stateless всегда лучше stateful) можно было просто собрать новый массив. Да и опять же возвращаемся к пункту 1 - мы не умеем работать с объектами (свойства, методы, прототип объекта)

4) свойства вместо переменных.

5) в "стандартную сортировку" можно передать функцию сортировки, который реализует эти правила.

6) все названия функций и методов - camelCase, конструкторы объектов (ну или имена классов если мы про сахар над Object.create) - CamelCase.

7) он должен предоставлять состояние, а работать с document.write должен кто-нибудь другой. Если бы это были отдельные функции - все было бы хорошо (а это могли бы быть просто отдельные функции). А так у нас выходит объект с нарушением принципа единой ответственности.

8) от вас требовалось javascript api, а не класс. Это мог бы быть просто модуль предоставляющий одну единственную функцию или две функции.

[Сергей Протько]

splincodewd: развиваться и учиться. Учить JS, читать умные книжки всяких фаулеров, кентов бэков и т.д. (то есть большая часть необходимых знаний вообще не привязана к языку программирования). Почитать что-нибудь на тему функционального программирования (о том что мутация состояния - это плохо, а в вашем коде много побочных эффектов из-за этого всплывает). Про ООП почитать. Ну и задавать вопросы и пытаться разбираться.

[Максим Иванов]

мне казалось, что API это класс с методами и свойствами (как jQuery библиотека)

[Максим Иванов]

а что означает категория ">50% JS кода"?

[sanex3339]

`нарушения принципа единой ответственности` - я щас пишу проект по работе без использования каких либо либ (только TS + сборка Webpack'ом), всякие сортировки, и ф-ии хелперы выношу в папку Helpers, а в ней для каждого хелпера свой файлик, откуда этот хелпер экспортируется. Вот как раз сегодня вечером вынес из одного класса ф-ию прохода по многомерному объекту в новый хелпер, который теперь можно использовать по мере необходимости.

[Сергей Протько]

sanex3339: справедливости ради - "хелперы" - плохое и ленивое имя, не говорит ничего. Можно же именовать как-то более красиво, "сортировка" например, "фильтры". Что бы обозначало что там лежит.

splincodewd: API это набор методов, а объект это, просто функции экспортируемые модулем - это уже мелочи. Объекты надо использовать тогда, когда мы хотим изолировать побочные эффекты (или хэндлить внутреннее состояние) или удобненько управлять зависимостями, хотя с этим и модули неплохо справляются, инверсию зависимостйе можно и ими организовать.

[sanex3339]

Сергей Протько: Helpers - папка. В ней по каждому хелперу - свой файл, с соответствующим именем.

[riot26]

splincodewd: комменты tl;dr, но от себя посоветую книгу "Чистый код" Мартина, судя по качеству кода, она Вам нужна

[Сергей Протько]

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

[sanex3339]

Сергей Протько: Ну так то да.

[Tsiren Naimanov]

вместо тысячи слов:
Царское пояснение!!!
без сарказма :)

[Dave]

Сергей Протько: Требовать от джуниора знание SOLID и понимание слоев абстракции, а это правильно или нет?

[Сергей Протько]

Dave: ну вот давайте рассуждать. Требовать от джуниора понимание инкапсуляции нужно или нет? Или хватит того что бы определение заучил для собеса?

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

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

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

[yesworld]

А кто нибудь пытался решить эту задачу? Мне вот реально интересно, как решают профи подобные вопросы...

Answer 2

[Артур Мудрик]

Жесть. Посмотрел гифку на Гитхабе, там, где весь процесс наглядно показан, код даже не смотрел.

Ну вот смотрите, ясно же, что информация о маршрутах, вот все эти текстики, типа, «Из Стокгольма на пароме до Риги, каюта 6a…», это всё должно генерироваться из данных, а не ручками в textarea писать :)

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

Из {откуда} на {транспорт} до {докуда}, {тип_места: каюта, сиденье, место и т.п. в зависимости от типа транспорта} {номер_места} и прочие данные… — и еще для всего этого нужна локализация (не только же на русском тексты будут), и еще всё это нужно просклонять, если уж вообще перфекционистски делать — согласитесь, «Из Стокгольм до Рига…» звучит ужасно.

А у вас просто всё это пишется в текстовом поле — тогда уж вообще нужно одно текстовое поле вместо всей вашей формы и кнопочек, и там оператор напишет кучу текста сам, с кучей ошибок, несистемно :)

Вот сейчас возьмите всё, что вы сделали, и представьте, что номер рейса изменился, или номер сиденья изменился (вас поменяли с кем-то, и у вас изменилось место и у другого человека) — как вы это обрабатывать будете? Заходить в каждый маршрут и ручками править текст в textarea?

А насчет данных и сортировки, элементарно — данные самые обычные, обычный жисончик, массив из объектов. Сортировка по левому и правому ключу, nested sets, чтобы можно было создавать маршруты любой глубины, например, не просто Рига → Стокгольм, а между ними маршруты по Риге и маршруты по Стокгольму... ну, как дерево, можно раскрыть один маршрут, а там подмаршруты.

Comments

[Максим Иванов]

1) "Ну вот смотрите, ясно же, что информация о маршрутах, вот все эти текстики, типа, «Из Стокгольма на пароме до Риги, каюта 6a…», это всё должно генерироваться из данных, а не ручками в textarea писать .."

В смысле? Мы сами же должны создавать эти карточки. А как вы это сделаете, зависит от вас. В интернете до меня было много способов, я выбрал свой..

https://github.com/GAMERSKZ/YA_TEST/blob/master/te...
https://github.com/Dexig/testSolution
jsfiddle.net/dpSsN

2) Из {откуда} на {транспорт} до {докуда}, {тип_места: каюта, сиденье, место и т.п. в зависимости от типа транспорта} {номер_места} и прочие данные… — и еще для всего этого нужна локализация (не только же на русском тексты будут), и еще всё это нужно просклонять, если уж вообще перфекционистски делать — согласитесь, «Из Стокгольм до Рига…» звучит ужасно.

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

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

Поэтому я решил, что строгими входными данными будут только инпуты ОТКУДА и КУДА, неважно на каком языке вы пишите, всегда только в именительном падеже будут города, а информация о карточке была бы независима, поэтому не нужно было парсить текст карточки и проверять по склонениям, а это извините, жесткая задача, отсюда как раз и следует, что задачу изначально, в пример, давали на английском.

У меня был алгоритм сортировки по этим самым инпутам ОТКУДА-КУДА.

3) Да, у меня все было в textarea, нам же не сказано было, что это все должно было создаваться системным оператором, может это сам путешественник писал для себя на листке бумаги. Наверное, надо было запилить простой интерфейс с селектами и тд, был бы API. Но мне показалось это скучным, поэтому я сделал сортировку по инпутам ОТКУДА-КУДА, повторяюсь, но сортировка мне понравилась тем, что хотя бы работало идеально, алгоритм на нахождение путей в ориентированном графе. А это для меня было достижением. Видимо, усложнил.

4) "Вот сейчас возьмите всё, что вы сделали, и представьте, что номер рейса изменился, или номер сиденья изменился (вас поменяли с кем-то, и у вас изменилось место и у другого человека) — как вы это обрабатывать будете? Заходить в каждый маршрут и ручками править текст в textarea?"

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

5) В моем случае, был обычный js-массив, json-чик тоже самое практически...

Answer 3

[Елизавета Борисова]

Что я не так сделал, что поставило на мне крест?

Это не крест, это нормальная ситуация. В яндекс глубоко рано.
По коду вам написали комментарии. Возможно, Вам стоит вернуться к C++, т.к. язык более знаком, и вывести его на лучший уровень сначала, так Вы будете развиваться в глубину.
По резюме, не пытайтесь изучать все вширь, не думайте, что это все полезно. Работайте по списку выше, Кормен, английский.
По возможности возьмите ментора для регулярных консультаций С++ или JS.

Answer 4

[xmoonlight]

Я думаю, что у них оценивается: минимум кода, самый короткий (оптимальный) алгоритм. Здесь нигде не требовали использование ООП.
1. Задание 1 - динамические цепочки (очереди). Надо было "растащить вагоны" и "сцепить" их (конечный с начальным пунктом). Это делается в 1 проход по списку карточек.
2. Задание 2 - проверка знаний нативки JS и логики работы мозга при самопостановке задачи и её реализации: селекторы/regex, деревья: просто перебор нужных с изменением/запросом свойств объектов.
PS: может им на C++ написать и прогнать через LLVM на asm.js?)
хотя, думаю, тоже не прокатит - им же JS-исходник нужен)

Comments

[wkololo_4ever]

Можете пояснить, как это можно сделать за один проход по списку карточек?

[xmoonlight]

wkololo_4ever: так вроде я написал: есть входящая очередь, есть сортировка. Нет связки - создаём новую цепочку. После присоединения карточки к цепочке - проверяем начало-конец всех других звеньев: если есть связка - присоединяем одну цепочку к другой. И берём новую карточку из входящей очереди. И так до тех пор, пока не закончится входящая очередь.
В итоговой сортировке будет одна (если все карточки взаимосвязаны через начальный и конечный пункты) или несколько цепей (если есть несвязанные между собой карточки, например - "потерянные").

[wkololo_4ever]

>проверяем начало-конец всех других звеньев
Так все равно будет сложность O(n^2)

[xmoonlight]

wkololo_4ever: обоснуйте Ваш вывод

[wkololo_4ever]

xmoonlight: Цикл по входящим карточкам и цикл по всем существующем цепочкам. А в худшем случае карточки будут разбросаны так, что не одну цепочку сразу соеденить не получиться

[xmoonlight]

wkololo_4ever: всё верно. но чтобы было O(n^2) - нужен исключительно худший случай.

[wkololo_4ever]

xmoonlight: "O()" и обозначает худший случай.

[xmoonlight]

wkololo_4ever: ну вероятность худшего крайне мала, соотв. O(N^2)->O(N)

[wkololo_4ever]

xmoonlight: ну так не считают -_- O(n) там никак не будет. https://habrahabr.ru/post/196560/

[xmoonlight]

wkololo_4ever: да и не важно) проход всё равно - один будет!

[xmoonlight]

wkololo_4ever: если все перемешанные карточки будут идти четко одна за другой - сложность алгоритма будет однозначно: O(n) !

[KeFA]

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

[xmoonlight]

KeFA: Советую вАМ почитать про алгоритмы чуть больше.
Этот: НЕ сортировка))) (а уж тем более "пузырёк")

[KeFA]

xmoonlight: "Алгоритм сортировки — это алгоритм для упорядочивания элементов в списке." Из Википедии. Если вы считаете, что упорядочивание билетов в списке не является их сортировкой, то это ваши проблемы. А про пузырек-не пузырек и O(n^2) предлагаю вам реализовать свой алгоритм в коде, тогда и поговорим. На словах, как я понял, вас не переубедить.

[xmoonlight]

KeFA: ок. каждый цикл - это выборка из массива по "ключу" и далее: стыковка (слева и справа) или создание нового элемента массива. Т.е. создание последовательностей цепочек. Здесь сложность какая будет?

[KeFA]

xmoonlight: O(n^2), если выборка по ключу - это просмотр всего массива. Напишите работающий код или хотя бы псевдокод.

[xmoonlight]

KeFA: "если выборка по ключу - это просмотр всего массива." - ну тут я не согласен. это однозначная связка с данными элемента массива. (хотя я могу ошибаться...)

[KeFA]

xmoonlight: ну вот напишите код, тогда и посмотрим.

[xmoonlight]

KeFA: ок

Answer 5

[KeFA]

После беглого взгляда на ваше решение, могу сказать, что Вас не взяли как минимум из-за алгоритма сортировки за O(n^3), когда билеты можно отсортировать за O(n) по времени и O(n) доп. памяти. Псевдокод:

val tickets = [ ... ... ... ]

val from = new hash_map()
val to = new hash_map()

for (t in tickets) {
    from[t.from] = t
    to[t.to] = t
}

val begin = null;
for (t in tickets) {
    if (to[t.from] == null) {
        begin = t
        break
    }
}

tickets[0] = begin
for (i in range 1..tickets.length-1) {
    tickets[i] = from[tickets[i-1].to]
}

Comments

[Максим Иванов]

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

Answer 6

[Александр Nameless08]

"Не тот пропал, кто в беду попал, а тот пропал, кто духом пал."

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

Учился как-то на курсах веб-разработки, по большей части чтоб получить диплом, дающий право занимать соответствующие позиции в компаниях, ну так на всякий случай. Кстати, до сих пор не пригодился ))

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

Вот этот второй - у него вечно были какие-то проблемы. То ему нечего в резюме писать, то он без конца толдычил что он слаб, то нет портфолио... Это при том, что он не женат, детей нет, ипотеками, рассрочками и прочим не одарен, еще и живет в своей квартире - есть масса вариантов как взять старт. Я ему и резюме сунул, и планы действий нарисовал и варианты как проникнуть - итог один - "Но я же, а у меня же, но блин..."

PS: "В любых делах при максимуме сложностей
Подход к проблеме все-таки один:
Желанье — это множество возможностей,
А нежеланье — множество причин." - вроде Асадов.

Comments

[Максим Иванов]

Как мне писали выше:
для работы в яндексе нужен чуть более высокий уровень и понимание вещей

... а не жизненная позиция

[Александр Nameless08]

Максим Иванов, они всем что-то подобное пишут, но суть не в этом

[Максим Иванов]

ну я не отчаиваюсь, стараюсь тренироваться

[Александр Nameless08]

Максим Иванов, правильно

Answer 7

[Егор Казанцев]

Я вообще не понимаю такую любовь к яндексу... срочно забей и иди пилить свой стартап

Comments

[Артур Мудрик]

А я не понимаю нелюбовь к Яндексу — единственная ровная IT-контора на всём постсоветском пространстве, имхо.

[Егор Казанцев]

Артур Мудрик: Так идите работайте туда. О широте вашего знания предмета говорит хотя бы "единственная ровная IT-контора на всём постсоветском пространстве"

[Максим Иванов]

Яндекс работает с высоконагруженными проектами, а это в первую очередь опыт. Тем более, кому не хочется опыт работы в крупных компаниях, сроком хотя бы на 3 месяца. Артур прав, Яндекс довольная мощная IT-компания, в которую нужно стремится попасть. Но как писали выше и выше, туда берут только мастеров.

[Егор Казанцев]

splincodewd: Да ладно , где вы там узнаете нагрузку , сервера админят одни люди , другие делают ПО и то по частям. Туда берут зануд с академическими знаниями , full-stack там нет.

[Максим Иванов]

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

[Егор Казанцев]

splincodewd: Читайте Макконнелла. А занудой можно просто быть.

Answer 8

[John Doe]

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

Comments

[Максим Иванов]

Если бы руки были прямые, я бы уже работал где-нибудь, а так мне 22 года и я безработный... На фрилансе огромная конкуренция, эх, жизнь боль... Поэтому и надеялся получить фидбэк от Яндекса, вдруг смогу себя зарекомендовать.

[John Doe]

Пробуй freelansim.ru поработаешь год появятся постоянные поставщики заказов

[Максим Иванов]

Пытался, не вышло, обманули как-то, я и ушел...

[Роман]

splincodewd: Мне 19 и я работаю на фрилансе. Еще не все потеряно.

[John Doe]

)))) мне почти 29, и тоже работаю на фрилансе, фриланс не так уж и плох ))))

[private_tm]

Максим Иванов: upwork.com будешь на разрыв и при деньгах, поверь мне) если будешь качественно делать. И не подаваться на мелочные заказы для индусов.

[John Doe]

upwork.com это муть какая то

[Максим Иванов]

почему муть?

[John Doe]

На freelansim.ru получить заказ легче, и цена выше.