Задать вопрос
Пользователь пока ничего не рассказал о себе

Достижения

Все достижения (15)

Наибольший вклад в теги

Все теги (101)

Лучшие ответы пользователя

Все ответы (443)
  • Почему не могу найти работу Junior'ом C#?

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

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

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

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

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

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

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

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

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

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

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

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

    @kttotto
    пофиг на чем писать
    Во первых нужно закладывать время на разбор легаси кода, об этом сразу надо говорить с заказчиком. Зная задачу, всегда понимаешь, ЧТО надо написать, но в случае с легаси надо еще и понять КУДА это написать. Без этого никак и поэтому это время надо учитывать.

    Второе. Когда-то меня учили, что код нужно менять только дописывая его, в крайнем случае удаляя, но ни в коем случае не переписывая. Поэтому, если надо изменить поведение - наследуешься, переопределяешь метод и используешь новый класс. Мне сложно судить о php, как этот проект реализован, но ООП для того и придумали, что его легче поддерживать и он легче модифицируется.

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

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

    А вообще чтение легаси, это дело опыта. Я помню первые свои чужие проекты, я думал, что попал в ад. Сейчас копаться в чужом коде, это мое любимое дело) Я могу часами сидеть разбирать чужой код, что начальству приходится меня попускать: "я понимаю, я тоже это люблю, но надо дело делать")) Люблю просто на гитхабе полазить по чужим проектам, посмотреть как люди думают.
    Ответ написан
    Комментировать
  • Как правильно дождаться выполнения всех потоков, созданных в цикле?

    @kttotto
    пофиг на чем писать
    У Вас не правильный подход. Во первых забудьте про Thread и используйте TPL. Во вторых для распараллеливания запросов в цикле есть замечательный метод Parallel.ForEach. В третьих для ожидания выполнения всех параллельных задач есть Task.WaitAll.
    В общем Вы можете создать список Task-ов и запихнуть их в Task.WaitAll, но лучше пройдитесь параллельным форичем по Вашему периоду и внутри запускайте Ваши методы. Код за форичем будет ожидать завершения всех потоков в цикле.
    Ответ написан
    2 комментария
  • Какие решения для создания UI вы используете?

    @kttotto
    пофиг на чем писать
    Windows Forms устаревшая технология. Сейчас для десктопа под виндовс разрабатываются на WPF. Там спецом все сделано для возможности гибкого дизайна.
    Ответ написан
    3 комментария
  • Насколько сложно сделать рефакторинг проекта и переписать код с C# на Python/Java?

    @kttotto
    пофиг на чем писать
    Если, как Вы говорите, проект написан чисто, задокументирован и адекватно выполняет свои задачи, то зачем его переписывать? Если дело только в виндовс, то дешевле и быстрее перевести под Core, будет Вам линукс.

    насколько адекватно оставлять Backend на C# в 2018 году?

    Вот именно сейчас это адекватно) Большинство нового интерпрайза начинают писать на C#. Нам, наоборот, приносили большой проект с Питона переписать.

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

Лучшие вопросы пользователя

Все вопросы (25)