All streams
Search
Write a publication
Pull to refresh
25
0
Send message

Когда давно научился игнорировать абсурдные требования )

Если требование абсурдно, нужно просто поднять вопрос об этом, а не игнорировать. Это может быть связанно с тем, что программист чего-то не знает.

Хотя конечно бывает, что никто не знает зачем, но сделать надо обязательно. Бежать из таких мест надо.

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

Так проигнорировать вакансию целиком это и есть игра по правилам.

Начало (напишите в поле фиолетоый) - похоже на фильтр от ботов.

Какой смысл программисту через ботов ходить к рекрутёрам?

Возможно фильтр от людей которые не готовы играть по правилам. Человек либо не заметил или просто забил. Есть шанс, что потом придётся перевоспитывать.

Человека продают, человеку платят зарплату, на остальное гудят.

Разница между мидлом и сеньёром огромна. Только-что повышенный мидл может быть с годом опыта, а синьёр идущий на повышение может иметь лет 8 опыта. Соответственно маржа с них сильно разная. А переезд это риски и фиксированные расходы.

> В целом компания хорошая,

Это про epam? Он очень большой и разный. Я там поработал с офигенными людьми. Но и некоторое количество негатива тоже имеется. В общем лотерея.

L1 виза для переезда в эту же компанию в Америке. 1 год работы это условие её получения. Эту визу легко делать.

А вот H1b которая без привязки к компании, сложнее делать. Поэтому с этим и не замарачиваются.

Насколько было бы дольше сразу устроиться в Убер в плане релокации и зелёнки?

Более того, если ты по факту уровня архитектора, то для тебя важнее понимать скорее для каких задач нужны какие деревья (и нужны ли они вообще), чем уметь инвертировать бинарное дерево.

Кстати это как раз задачка из разряда, не знал, но придумал. Это почти идеальная задача, в том плане, что она действительно проверяет как человек думает.

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

Именно это я и имел ввиду под "простые операции сложно и дорого"

А еще можно использовать для того, чтобы сделать простые операции сложно и дорого.


Например, берём структурированные данные и гоняем регулярки, как в Пример 4. Получение даты из строки и Пример 8. Извлекаем данные из html-файла. Годные костыли для мелких задач очень удобно, а вот в долговременные проекты лучше не пихать.


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


Я комфортно работаю с регулярками и поэтому при ревью их не пролистываю в ужасе.
Большие выражения часто являются источником проблем.

На зло всем хейтерам, которые говорят, что python медленный, мы смогли достичь ускорения кода в десятки раз.

Питон создан чтобы управлять, а не для того чтобы работать в поте лица. Пахать должен С++. Отдайте команду numpy, pands, sqlite и они сделают работу быстро и эффективно.


очищать руками память и удалять ненужные элементы по ходу выполнения кода

Я бы скорее это во вредные советы записал. Это всё загромождает код. А с тем что реально получится легко ошибиться.


Например если в dict есть 10000 ключей, мы удаляем оттуда 10000 ключей. Как изменится место занимаемое в памяти?


multiprocessing

Я бы добавил еще асинхронщину.


Разные интересные моменты про производительности
James Powell — Furious & Fast Python 7: Writing Fast Python Code

Вы точно что переизобрели одну из популярных GPLv2 библиотек поисковой машины Sphinx написанную на C++, при этом SphinxAPI доступен также на PHP, Java, Perl, Ruby и Python.

Так автор и ставил себе целью написать собственную реализацию этого алгоритма.

Полный провал разведки. Каждый раз сюрприз от несовпадение ожидания с реальностью. Зачем же так? Это же не рога и копыта, о том что ожидать можно узнать заранее из многих источников.


Про то зачем нужны алгоритмические задачки и почему у некоторых компания это работает Гэйл Лакманн Макдауэлл написала целую главу в книге. Посмотрите на досуге.


В это плане Яндекс играет в открытую, по своим правилам. Тут либо соглашаться, либо жаловаться.

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


При звёздочках надо заполнять __all__ или получишь всё что есть внутри. Если свои аттрибуты можно спрятать через правильное именование (начать с нижнего подчёрквания) то что делать с теми которые импортируешь?


from my_module import pprint

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

Вот еще вариант на классах.


class Fib:
    def __init__(self):
        self._x1 = 0
        self._x2 = 1

    def __call__(self):
        x3 = self._x1 + self._x2
        self._x1, self._x2 = self._x2, x3
        return x3

А если __call__ переименовать в __next__ то будет вообще хорошо. Без генераторов это исследование выглядит неполным.

Импорт со звёздочкой идёт в лес.


В PEP8 даны достаточно однозначные рекомендации, которые не сложно соблюдать.


А еще flake8 умеет ругаться на использование F403 ‘from module import *’ used; unable to detect undefined names.

Если модуль импортируется любым способом, то его __name__ != "__main__", всё что внутри if не выполняется.


А еще можно в этот процесс добавить немного магии и импортировать динамически созданные сущности: https://plumbum.readthedocs.io/en/latest/local_commands.html#import-hack

Спасибо, за детальное исследование внутренностей.


25 миллисекунд разницы на миллион запусков набегает. Это именно то, что я имел ввиду под "разницы в производительности нет"

А что именно символизирует мужик с досками в шее: перл или автотестирование?

Девелопер с опытом не будет дискутировать на тему, что юнит-тесты не нужны, как и не будет дискутировать на тему, что юнит-тесты нужны.

Конечно он же с опытом, поэтому сделает КАКОБЫЧНО. :)

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

Публичный контракт cервиса, но при этом не часть API которое святое? Алгоритм генерации вполне попадает под юниттесты.


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

Примерно так и описывают плохую архитектуру. Поменяли в одном углу, отвалилось в другом.


Тут попасть в клинч как с добрым утром — один репликатор отследил изменеия в таблице А и внес изменение в таблице Б.

Жесть какая. Тут я бы смотрел в сторону инструментов-валидаторов. В теории если выдрать из репликаторов имена таблиц, то можно построить граф и на нем найти проблемные/потенциально проблемные места. В отличии от тестов этот инструмент можно написать один раз и использовать со всеми новыми версиями. От написания тестов он не избавит, но позволит получать фидбэк намного быстрее.

Это ошибка выжившего. Если ты сидишь на золотой жиле то каким бы хреновым не был способ добычи, он намного эффективнее любого дргого способа в месте где золота нет. Качество и скорость важны там где есть конкуренция, а где её нет там качество и не нужно. Спросите у прогаммистов 1С.

Information

Rating
4,909-th
Registered
Activity