Leetcode, Hackerrank и прочие сайты с задачами
2337
24
Каждый из тех кто приходит в этот раздел, как-то косвенно связан с айти или программированием в целом. Возможно студент кафедры, которая нацелена на ИТ, или желающий вкатиться, или школьник, который еще размышляет над будущей профессией, а возможно уже программист.
Но все как-то слышали про алгоритмы, задачки связанные с ними, которые особенно дают на собеседованиях, и чем лучше компания тем сложнее задачи (им же как-то надо отсеивать людей, среди десяток тысяч желающих в неделю).
Поэтому тяжело пройти мимо таких известных платформ какhttps://leetcode.com/
Все кто как-то связан с программирование, советую туда зайти. Один из мировых лидеров в этом деле.
В двух словах, создаете акк, решайте задачи. По возможности решайте сами, потом делитесь решением с другими или смотрите на их решения. Также есть решения с подробными ответами, но они не к всем задачам доступны (там можно купить прем аккаунт). Но можно пользоваться абсолютно бесплатно, за исключением 10% редкостных новых задач + подробные объяснения к некоторым задачам.
Советую начать с Easy и т.д.
Делимся своими достижениями.
Если интересует, что-то связанное с математикой + программирование могу еще посоветовать древний сайт https://projecteuler.net/
Там есть задачи, которые решает всего 100 человек из нескольких миллионов. Можете быть гением, кто придумает решение, на 6к как-то катайте, а задачу решить слабо что-ли ?
В чем плюсы ? Мозг качается, также как от сборника задач Демидовича. Попав на собеседование в нормальную контору (а именно туда надо идти), вы без проблем сможете решить все эти вещи. Ну и как вишенка на торте, просто весело проведете время.
Как правило, многие скипают алгоритмы, в надежде, что это не играет роли, главное код красивый и т.д. Могу сказать что в 95% случаях, всем плевать какой код, хоть в книгах об этом постоянно пишут, на деле "главное что работало и стабильно, быстро", а ваша кухня и что внутри, это лишь в скоупе команды. Например, был проект где каждую переменную, поле, параметр в нужно было помечать как final, если ссылка не менялась (язык Java 1.7 еще был), но по факту, это бесполезное занятие. Не скорости (о чем было сотни споров), ничего оно толком не давало, но такие были правила внутри тимы.
Ну и делимся результатами.
leetcode
AMDkrolyan сказал(а):↑
пфф видел бы ты сорсы многих решений, там можно прикапываться к каждому методу, и что никто не юзает что-ли ?
миллионами юзают у себя в проде
Нажмите, чтобы раскрыть...
Видел бы ты многомиллионные проекты, где требования к поддержке кода такие же высокие, как и требования к производительности.
МужикДругалёкЧервяк сказал(а):↑
Дядя, ты же джавист(я тоже), ты реально думаешь что тебе нужен этот литкод для задротов дед инсайдов?) на крайняк можно потренится на 10-6 ку на кодварс, этого достаточно) лучше посоветуй учиться решать серьезные задачи и правильно: интеграция апишек, миграции бд, запросы в баду, грамотная реализация апи системы, юнит тесты и тд и тп.
Насчет final орнул) ну типа лол, когда у тебя большой проект, то стоит его использовать, тем более в методах на 100+ строк. Когда у тебя 3 обьекта с похожим названием, и то начинаешь что-то менять - это может тебя спасти)
Ну и у меня вопрос, в каком это месте всем плевать на код?)) где это ты работаешь, что при ревью все плюют на твой код?)
когда я ревьювлю(и когда меня), всегда стараемся заставить чела на что-то обратить внимание. Бывает такое, что я заставляю, например, тим лида вынести не только код который он написал в другой метод, но и то что было написано до него, так как там например уже 9999 строк, а никто не хочет его разбивать(ведь в таске этого не было
). А потом сиди разбирайся в этом полотне в след раз опять... это не хорошо...
Видел бы ты многомиллионные проекты, где требования к поддержке кода такие же высокие, как и требования к производительности.
Нажмите, чтобы раскрыть...
>> Дядя, ты же джавист(я тоже), ты реально думаешь что тебе нужен этот литкод для задротов дед инсайдов?)
Я работаю не только на джаве.
>> интеграция апишек, миграции бд, запросы в баду, грамотная реализация апи системы, юнит тесты и тд и тп.
Это все и так понятно, тут есть книга designing data intensive applications тоже к чтению, помимо алгоритмов
>> Насчет final орнул) ну типа лол, когда у тебя большой проект, то стоит его использовать, тем более в методах на 100+ строк. Когда у тебя 3 обьекта с похожим названием, и то начинаешь что-то менять - это может тебя спасти)
Что может спасти, причем здесь большой, IDE не неслышал, не в блокноте же код пишешь, как файнал спасет не перепутать имя объекта ? короче какая-то несурациза
>>Видел бы ты многомиллионные проекты, где требования к поддержке кода такие же высокие, как и требования к производительности.
Я работал на многомиллионных проектах, и только на нескольких есть код ревью, и то в основном для джунов, ибо они порой могли поломать релиз. Насчет производительности, собственно о чем речь и идет, не имея базовых знании для оценки перфоманса своего кода
>>Ну и у меня вопрос, в каком это месте всем плевать на код?)) где это ты работаешь, что при ревью все плюют на твой код?)
95% компаний, или ты думаешь где-то, кто-то сидит рили запаривается смотрит. На архитектуру и интеграцию сопутствующую время нужно тратить, а какая кому разница юзаю я здесь стримы или цикл фор.
Особенно когда это микросервисы и ты под него бек в соло пилишь.
AMDkrolyan сказал(а):↑
Что может спасти, причем здесь большой, IDE не неслышал, не в блокноте же код пишешь, как файнал спасет не перепутать имя объекта ? короче какая-то несурациза
Нажмите, чтобы раскрыть...
Забей хрень сказал.
AMDkrolyan сказал(а):↑
Насчет производительности, собственно о чем речь и идет, не имея базовых знании для оценки перфоманса своего кода
Нажмите, чтобы раскрыть...
мм? Не понял
AMDkrolyan сказал(а):↑
95% компаний, или ты думаешь где-то, кто-то сидит рили запаривается смотрит, на архитектуру и интеграцию сопутствующую время нужно тратить, а какая кому разница юзаю я здесь стримы или цикл фор.
Особенно когда это микросервисы и ты под него бек в соло пилишь.
Нажмите, чтобы раскрыть...
Миф то что стримы медленней циклов настолько что и их не стоит юзать еще существует?:)
Под словами производительность я имею ввиду такие ситуации как лишние запросы в дб, лишние создания объектов, выбор коллекций, решения с созданиям новых таблиц и тд.
AMDkrolyan сказал(а):↑
Я работал на многомиллионных проектах, и только не нескольких есть код ревью, и то в основном для джунов, ибо они порой могли поломать релиз. Насчет производительности, собственно о чем речь и идет, не имея базовых знании для оценки перфоманса своего кода
Нажмите, чтобы раскрыть...
Ммм, ты считаешь что только джун может затупить и сделать глупую ошибку?) Эх щас бы в мастер мерджить без ревью, мм вкусно)
МужикДругалёкЧервяк сказал(а):↑
мм? Не понял
Нажмите, чтобы раскрыть...
Ну много всяких ситуаций, когда вместо одной коллекции лучше использовать другую, писать не два цикла, а один с хешмапой и кучу других алгоритмов.
Те же запросы в хранилище, когда чуваки вместо того, чтобы написать более сложный запрос, чтоб он отработал в базе, делают это через код на сервисе.
Цитата:
Миф то что стримы медленней цикловнастолько что и их не стоит юзать еще существует?:)
Нажмите, чтобы раскрыть...
Существует, но там миф что оно просто медленее, но тут речь не о том. Я к тому, что фактически результат твоей фичи это ее рабочее состояние, а заюзал ты там фор или стрим, имеет уже десятый приоритет. Конечно если время там или условия позволяют сидеть, и это все ревьювить круто. Но были ситуации когда код ревью семерых людей, занимало у меня по 3-4 часа в день, из-за чего рабочий день превращался в 10-12 часовой.
Цитата:
Ммм, ты считаешь что только джун может затупить и сделать глупую ошибку?) Эх щас бы в мастер мерджить без ревью, мм вкусно)
Нажмите, чтобы раскрыть...
Любой может натупить, и код ревью тоже не поможет. Порой это не возможно ибо ты один пилишь, или три человека пишут разные вещи. Чекают изменения логики, вот это самая главная цель код ревью. Что, то, что ты пишешь имеет смысл (в контексте задачи) и архитектуры, а не исключать все ошибки. Ты же в голове код не откомпилишь. Были проект, где чекали все вплоть, писали не юзай user.getId() два раза, лучше вынеси это в переменную, хотя там обычный объект, или там юзай IntStream вместо fori. Ну такое, плюс что самое забавное, еще требовали писать все в срок) Надо было ждать пока какой-то вася посмотрит.
Еще бывали смешные чекстайлы, из разряда объект имеет наследование длиной в 3, типо это плохо. А объект из либы.
Например, пулл реквесты в опенсорс ревьювят как правило 1-2 чела максимум, кто шарит в этой области.
Если подытожить я не против код ревью, просто говорю, что не везде его можно позволить (мало проектом сейчас, где над одним кодом работает по 15-30 чел). Ну и если код ревью это якорь, то тоже такое себе.
Плюс эти алгоритмов. То что, их спрашивают на собеседовании в Google, Netlifx, Microsoft и т.д.
AMDkrolyan сказал(а):↑
Ну много всяких ситуаций, когда вместо одной коллекции лучше использовать другую, писать не два цикла, а один с хешмапой и кучу других алгоритмов.
Те же запросы в хранилище, когда чуваки вместо того, чтобы написать более сложный запрос, чтоб он отработал в базе, делают это через код на сервисе.
Нажмите, чтобы раскрыть...
Ну так я о том же
AMDkrolyan сказал(а):↑
Но были ситуации когда код ревью семерых людей, занимало у меня по 3-4 часа в день, из-за чего рабочий день превращался в 10-12 часовой.
Нажмите, чтобы раскрыть...
НУ во-первых я хз че там ревьювить 3-4 часа, тогда вы просто не умеете разбивать на таски эпик/стори, если один ПР нужно ревьювить час)Расскажу секрет, можно выделять себе 1-1.5 часа в день на ревью, и покс что там 10 ПРов висит, ты работаешь и ты занят.
AMDkrolyan сказал(а):↑
Любой может натупить, и код ревью тоже не поможет. Порой это не возможно ибо ты один пилишь, или три человека пишут разные вещи. Чекают изменения логики, вот это самая главная цель код ревью. Что, то, что ты пишешь имеет смысл (в контексте задачи) и архитектуры, а не исключать все ошибки. Ты же в голове код не откомпилишь. Были проект, где чекали все вплоть, писали не юзай user.getId() два раза, лучше вынеси это в переменную, хотя там обычный объект, или там юзай IntStream вместо fori. Ну такое, плюс что самое забавное, еще требовали писать все в срок) Надо было ждать пока какой-то вася посмотрит.
Нажмите, чтобы раскрыть...
Суть код ревью не проверить на правильную реализацию(ты это тупо не проверишь, для этого есть юнит тесты и QA, а почистить код, ну и конечно же потенциальные проблемы, аля архетектурные). Конечно, в первую очередь это ответственность того кто писал, но ревью очень помогает, поверь. Не нужно ревьювить баг фикс в 4 строки, но новую фичу обязательно, даже маленькую.
AMDkrolyan сказал(а):↑
Еще бывали смешные чекстайлы, из разряда объект имеет наследование длиной в 3, типо это плохо. А объект из либы.
Нажмите, чтобы раскрыть...
Ну на это рили покс)
AMDkrolyan сказал(а):↑
Если подытожить я не против код ревью, просто говорю, что не везде его можно позволить (мало проектом сейчас, где над одним кодом работает по 15-30 чел). Ну и если код ревью это якорь, то тоже такое себе.
Плюс эти алгоритмов. То что, их спрашивают на собеседовании в Google, Netlifx, Microsoft и т.д.
Нажмите, чтобы раскрыть...
Да лол, дрочить алгоритмы ради этих компаний?) 90% даже не стремятся туда попасть, а еще 90% из оставшихся не попадут)
Алгоритмы оч полезные, но я бы сказал больше опытным людям, чем пре-джунам)
AMDkrolyan сказал(а):↑
Любой может натупить, и код ревью тоже не поможет.
Нажмите, чтобы раскрыть...
В смысле не поможет? Код ревью делается как раз таки с целью не допустить очень кривой код в прод, чтоб в будущем потом не пришлось сразу гору костылей разгребать. И код не обязательно должен быть сломанным, он может работать, но его не допустят в прод и попросят переделать. И есть огромное кол-во компаний где код ревью является обязательным этапом чтоб допустить код в прод.
Плюс к этому, это не только отсеивание плохих ошибок, а еще и поиск более адекватной реализации, потому что ты увидел и решил проблему по-своему, а человек, который делает ревью, увидел более удобный способ это реализовать. И это не обязательно будет тимлид, это может быть человек твоего уровня, просто потому что два разных взгляда на код полезнее чем один.
И, к слову, в компаниях, которые ты перечислил ниже в своем сообщение (Google, Netlifx, Microsoft), код ревью - обязательная часть работы. Ты там будешь писать свой код и проверять чужой (аналогично и с твоим кодом, его будет проверять человек который его не писал).
Вебмакака сказал(а):↑
В смысле не поможет? Код ревью делается как раз таки с целью не допустить очень кривой код в прод, чтоб в будущем потом не пришлось сразу гору костылей разгребать. И код не обязательно должен быть сломанным, он может работать, но его не допустят в прод и попросят переделать. И есть огромное кол-во компаний где код ревью является обязательным этапом чтоб допустить код в прод.
Плюс к этому, это не только отсеивание плохих ошибок, а еще и поиск более адекватной реализации, потому что ты увидел и решил проблему по-своему, а человек, который делает ревью, увидел более удобный способ это реализовать. И это не обязательно будет тимлид, это может быть человек твоего уровня, просто потому что два разных взгляда на код полезнее чем один.
И, к слову, в компаниях, которые ты перечислил ниже в своем сообщение (Google, Netlifx, Microsoft), код ревью - обязательная часть работы. Ты там будешь писать свой код и проверять чужой (аналогично и с твоим кодом, его будет проверять человек который его не писал).
Нажмите, чтобы раскрыть...
p.s. сообщение отправлено на премодерацию лол, еще раз попробую.
Вебмакака сказал(а):↑
В смысле не поможет? Код ревью делается как раз таки с целью не допустить очень кривой код в прод, чтоб в будущем потом не пришлось сразу гору костылей разгребать. И код не обязательно должен быть сломанным, он может работать, но его не допустят в прод и попросят переделать. И есть огромное кол-во компаний где код ревью является обязательным этапом чтоб допустить код в прод.
Плюс к этому, это не только отсеивание плохих ошибок, а еще и поиск более адекватной реализации, потому что ты увидел и решил проблему по-своему, а человек, который делает ревью, увидел более удобный способ это реализовать. И это не обязательно будет тимлид, это может быть человек твоего уровня, просто потому что два разных взгляда на код полезнее чем один.
И, к слову, в компаниях, которые ты перечислил ниже в своем сообщение (Google, Netlifx, Microsoft), код ревью - обязательная часть работы. Ты там будешь писать свой код и проверять чужой (аналогично и с твоим кодом, его будет проверять человек который его не писал).
Нажмите, чтобы раскрыть...
Ну тем не менее, код ревью не дает 100 гарантию, баги были есть и будут, потому-что код ревью, делает такой же человек, да он может заметить потенциальное нарушение в логике (неправильное использование паттерна, неоптимальный запрос или метод не в том сервисе), но какой нибудь хитрый наллпоинтер, и т.д. найдет лишь тот кто пишет код.
Я ревьювил много кода. И видел ошибки уровня OutOfMemory когда, с ResultSet шла выборка, sql запроса без лимита. Естественно синьер мидла не послушал, в итоге я ловил лулзы от постоянных падений на проде.
AMDkrolyan сказал(а):↑
Идет джоба 15 минут билда + юнит тесты
Нажмите, чтобы раскрыть...
шооо? У меня все летает, проект огромный, в докере билдится пару минут, тесты 20-30 сек.
AMDkrolyan сказал(а):↑
Юнит тестами максимум можно пару строк в проекте добавить, еще интересно, зачем нужны юнит тесты если там 90% теста это мок ? Так чтобы просто изменения в коде фиксировать, ну и можно примерно покрыть что и как, а так они смысловой нагрузки мало несут, хоть они и были мастхев.
QA - сразу как ты выходишь в прод они отваливаются, и релизишь уже напрямую кастомеру это, когда я начинал такое было. В продуктовых, эти тестеров на свой код, редко когда выловишь. Они тестируют продукт уже потом в целом. Личного тестера тебе не дадут.
У нас было около 15к юнитов, 10к рестестов и интегрейшен, 5к смок тестов (там уже акуа работали), но все равно баги появлялись. Хотя все, все смотрели и ревьювили, и не только я один как выше писал, это было и до, и после.
Нажмите, чтобы раскрыть...
ну так это галера, где ты всем занимаешься в проекте... У нас в команде 2 QA :) А команда из 7 человек считая пма)
Любой ПР тестится QA, даже если это баг фикс. Практически каждый день вылавливаются новые баг фиксы, в плоть до того, что в проекте, которым пользуются дохреналион людей, этот баг возможно случился бы раз-два в сто лет у одного из юзеров)
AMDkrolyan сказал(а):↑
В первую очередь ради себя, чтобы не стать спринг\джаваее дрочером, которых тут кругом полно.
90% могут стремиться куда угодно, а то что не попадут, это зависит от уровня подготовки.
Нажмите, чтобы раскрыть...
ну ради себя да, но мне например давно впадлу что-то делать вне рабочее время, хотя вот пет проектик какой-то бы начал пилить, но идей нет)
mne_realno_vse_ravno сказал(а):↑
жесть тс жесткий, участвуешь во всяких cup'ах на литкоде или codeforces?
Нажмите, чтобы раскрыть...
Раньше постоянно участвовал, codeforces, в универе были еще такие олимпиады как KPI Open и т.д. Эх было время. Когда после пар ты мог хоть весь день про это читать, теперь по ночам или после работы онли.
Вк кап даже когда-то помню был, жаль тогда не прошел, ну хоть футболку выиграл.
МужикДругалёкЧервяк сказал(а):↑
шооо? У меня все летает, проект огромный, в докере билдится пару минут, тесты 20-30 сек.
Нажмите, чтобы раскрыть...
Там не было ни куба, ни докера, точнее оно деплоилось вроде на чистую EC2 машину. Проект старый с 2014 года.
15 мин шел билд, потому-что очень огромный проект (ты же сам писал про многомиллионные), плюс там еще была скала sbt, это еще медленее.
Интегрейшен тесты локально оч тяжело запустить, даже практически нельзя. Они могли занимать до 20-40 минут со смоками, поэтому их отдельно (там докер, накатывается база и т.д.), 2\3 все пролетало ок, а если еще проверить ендпоинты, которые потенциально могли заафектиться, то там шанс 1\10 что сломается, но сверхразумы были, которые такое не делали.
МужикДругалёкЧервяк сказал(а):↑
ну так это галера, где ты всем занимаешься в проекте... У нас в команде 2 QA :) А команда из 7 человек считая пма)
Любой ПР тестится QA, даже если это баг фикс. Практически каждый день вылавливаются новые баг фиксы, в плоть до того, что в проекте, которым пользуются дохреналион людей, этот баг возможно случился бы раз-два в сто лет у одного из юзеров)
Нажмите, чтобы раскрыть...
Это была галера первая, епам. дальше в продуктовых в основном работал, и там как повезет внутри компании, были проекты где ты в соло, были где команда, тут как повезет. В основном куа играются с релиз версиями, редко когда были проекты, что я мог попросить куа потестировать мой код, да и зачем. Как им тестить бекенд онли, смотреть в базу, ну тут АКУА надо.
МужикДругалёкЧервяк сказал(а):↑
ну ради себя да, но мне например давно впадлу что-то делать вне рабочее время, хотя вот пет проектик какой-то бы начал пилить, но идей нет)
Нажмите, чтобы раскрыть...
попробуй начни, сделать пару пулл реквестов в опен сорс
AMDkrolyan сказал(а):↑
Там не было ни куба, ни докера, точнее оно деплоилось вроде на чистую EC2 машину. Проект старый с 2014 года.
15 мин шел билд, потому-что очень огромный проект (ты же сам писал про многомиллионные), плюс там еще была скала sbt, это еще медленее.
Интегрейшен тесты локально оч тяжело запустить, даже практически нельзя. Они могли занимать до 20-40 минут со смоками, поэтому их отдельно (там докер, накатывается база и т.д.), 2\3 все пролетало ок, а если еще проверить ендпоинты, которые потенциально могли заафектиться, то там шанс 1\10 что сломается, но сверхразумы были, которые такое не делали.
Нажмите, чтобы раскрыть...
Так огромный проект. Томкат мгновенно запускается(если миграции уже подтянулись).
компиляция с clean ну может быть 1 минуту(не помню).
Ну без докера это конечно рофл) sbt? у меня сейчас вообще ant XD
AMDkrolyan сказал(а):↑
Это была галера первая, епам. дальше в продуктовых в основном работал, и там как повезет внутри компании, были проекты где ты в соло, были где команда, тут как повезет. В основном куа играются с релиз версиями, редко когда были проекты, что я мог попросить куа потестировать мой код, да и зачем. Как им тестить бекенд онли, смотреть в базу, ну тут АКУА надо.
Нажмите, чтобы раскрыть...
хз не бывал в епаме, но думал там все проекты, тем более на джаве, пишутся командами и все грамотно организованно...)
Ну да QA тестят если надо и бекенд и фронт, они считай знают больше чем дев по фичам проекта, могут рассказать что делает та или иная штукенция, какие колонки в таблицах есть и как что можно найти и все в таком духе. В общем без QA было бы очень сложно новичку вкатиться в такой проект, они ходячий ноледж шейринг.
а что такое АКУА?
AMDkrolyan сказал(а):↑
попробуй начни, сделать пару пулл реквестов в опен сорс
Нажмите, чтобы раскрыть...
да не спс) не интересно. Помню как-то когда искал первую работу, нашел опенсорс, там попробовал чето сделать, ну и мне дали тесты писать пару раз
Сделал пару коммитов(каждый из них по много попыток, так как различные проверки падали.) и бросил
Тема закрыта
-
ЗаголовокОтветов ПросмотровПоследнее сообщение
-
Сообщений:2
Просмотров:3
-
Сообщений:7
Просмотров:14
-
Сообщений:11
Просмотров:29
-
Сообщений:40
Просмотров:78
-
Сообщений:10
Просмотров:35


