Как стать автором
Обновить

Комментарии 21

Заблуждения о Computer Science начинаются с упорного нежелания её переводить.

P.S. Интервью у самого себя? Забавно.

Я как-то думал над объяснением работы компа. Так вот - логическая машина, созданная в этом мире человеками, это механизм работы/обработки цепочек или, что удобнее понять, списков. Программист имеет дело только со списками, основа которых просто линейная память. Код-обработчик - это алгоритм модификации списка данных, с которым он конкретно работает в этом месте. Вообщем-то, это всё объяснение всей глобальной компьютерщины.

Есть конкретная ячейка памяти, что бы до неё добраться сразу не нужно проходить остальные. О чем Вы? Какой список?

Нужно подумать прежде, чем спрашивать очевидное.

А кто говорил, что нужно проходить остальные?

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

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

Ты слишком кичишься своим заумством, товарищ. Список в обыденном понимании человека разумелого, но далекого от IT, уже упорядочен, пронумерован и может быть перебран по индексам. Исходя из этого, компьютер целиком представляет собой систему обработку списков. Какого ты уровня? asm лобал хоть раз?

Это что, компьютерная философия?

почему вот так лучше вообще не делать.

Вызов функции во вложенном цикле это конечно дорого, но в предположении что о "func" ничего не известно и код однопоточный - вряд ли тут можно сделать как-то по-другому. Пример плохой.

Можно запихнуть вложенный цикл в func(). К тому же, всегда есть альтернативный путь-путь бездействия

Для этого надо доп. условие, что func() контролируется нами (не библиотечная). =)

Но да, цикл надо внутрь функции если есть такая возможность

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

Первый же пример кода имеет О(1) время выполнения, т.б. постоянное и не зависит от длины входа, если конечно функция не стейтфул и ее время выполнения не зависит от количества предыдущих прогонов ;)

Есть глупенький вопрос, но здесь его задать как нельзя кстати.

Стоит ли на пути к junior python backend developer начинать грузить себя computer science? Очень трепещущий меня вопрос. Лучше пока оставить это до получения работы/оффера или до изучения основных фреймворков, или до прямого столкновения с computer science, или лучше начать заранее (что займет дополнительное время до желаемой цели в виде оффера)? Очень хочется посмотреть, куда гуляют мнения в этом вопросе

Учите то что нравится. Сделайте какой нибудь pet-project, в процессе вы столкнетесь с 50% необходимого и изучите. Ещё 40% изучите если будете периодически интересоваться как сделать то что вы сделали лучше. На собеседовании людей будут интересовать как вы думаете, какой у вас есть опыт (проекты) , что применяли и знаете, а не сложность алгоритмов. Ну кто-то может и погоняет по базам или паттернам, ну помечаете себе что спрашивали, а вы не смогли ответить, и изучаете эти темы.

Это зависит от того, какой оффер хочется получить. Можно стремиться к Junior в условном Гугле, а можно пойти в какую-нибудь веб-студию. Я не знаю, где лучше зарплата будет, но требования на приёме будут сильно разными.

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

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

Так сделаешь несколько собесов (а может и с первого всё ок будет) и устроишься на работу. Собесов не бойся - тебя никто в чёрный список за незнание добавлять не будет ;) Все мы обычные смертные и тоже где-то что-то не знаем или иногда ленимся, всё хорошо. Главное, что ты работаешь над собой. Неудачный собес тебе будет полезнее удачного - тебе подробно опишут твои недостатки и, вероятно, подскажут ссылку на ресурсы, где набраться знаний.

Это вопрос этики, ха-ха. Вопрос развития, глубины мышления. Сверху собраны только рычаги. Одному рычаги, другому - интересны шестеренки под капотом. То есть чел не может назвать себя инженером, зная только рычаги, как пилот не может назвать себя разработчиком самолета. А словцо "developer" - это наклейка на лоб.

А зачем себя "называть"? Это ведь тоже наклейка.

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

а токарь может называть себя Разработчиком деталей? или Разработчик это только конструктор станка? а конструктор, который разработал деталь тоже Разработчик или нет?

Программисты в основном чинят чужие баги.
Поэтому навыки дизайна алгоритмов особо не нужны.

В программировании микроконтроллеров базы данных абсолютно не нужны.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации