Check Levi9 best QA positions to Backbase team!
×Закрыть
ML Engineer в MEGOGO
  • Экс-гуглер Илья Полосухин — о том, как создать свой стартап, и почему Долина — не место будущего

    Да, вряд ли возьмут с колёс без ярких рекомендаций. Но суть не в этом. Нужно иметь решать реальные задачи на алгоритмы, разбирать по косточкам реальные архитектуры, что-то придумывать и креативить, быть дружелюбным и хорошим коммуникатором, быть продуктово-ориентированным бойцом. Вот что главное.
    Кто в Украине так проводит собеседования? Большинству местных синьоров подавай СОЛИД. Это вообще другой уровень осознания работы программистом.

    Поддержал: Bot Bot
  • Собираем команду в стартап!

    Кстати самый важный вопрос для любого статапа на старте.

    Знаю. Поэтому и задаю его.
    Деньги в рекламу — это прожигание бюджета. Без внятного плана удержания юзеров для превращения их в актив и дальнейшей монетизации, вам не дадут на это деньги. А их понадобится очень много.
    Вот это важно озвучить. А не то, как будут доли распределены.

    Кроме того, частичная занятость в стартапе? Рили?

  • Собираем команду в стартап!

    Как вы планируете привлечь и удержать критическую массу пользователей?

  • Як співбесідувати сіньйорів-помідорів?

    потом это убожество плавненько переписывают, чтобы его можно было поддерживать и развивать

    И при этом критично важно, чтобы человек, возглавляющий этот процесс, умел правильно приоритизировать задачи с точки зрения ценности для продукта и был способен надавать по рукам девелоперам, заигравшимся в код.
    Понимание, что идеального кода не бывает, а есть код с уровнем качества, достаточным на данном этапе развития продукта и который нужно поддерживать,- залог здоровья проекта.
    Но, боюсь, истории синьоров с саблями наголо «тут_место_для_баззворда — это круто и поэтому давайте всё тут нахрен перепишем», будут вечными...

    Поддержал: Viktor Chyzhdzenka
  • Як співбесідувати сіньйорів-помідорів?

    ))))))
    Принимается!
    Теперь каждый собес буду начинать с опроса на знание SOLID.

  • Разработчики, какие ивенты вы посещаете?

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

  • Як співбесідувати сіньйорів-помідорів?

    Если 90% падает, это — всё-таки правило, сорри.

    Это правило для тех, кто не хочет даже пытаться что-то сделать «с идеей на миллиард». Для фаундеров единственное правило — ни шагу назад. Всё остальное — апостериорная вероятность фейла. Никто не начинает стартап, следуя упаднической логике «мы всё равно умрём». Это абсурд. Вера команды в продукт и успех — вот что важно. Нет этого огонька внутри — энтерпрайз, пенсия, смерть. Мы же всё равно все умрём. Это — правило! )))

  • Як співбесідувати сіньйорів-помідорів?

    Изначально «в ящик» проектов не бывает.

    Да-да, не бывает. Они ими становятся, когда команда несколько лет надрачивает на свои исходники, но не решает основную проблему — боль кастомеров. ))) В последствии чего, инвестор или закрывает проект, или вяло финансирует, надеясь выиграть немного времени на впаривание кому-то этого булшита.

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

    В реальной жизни «компромиссного варианта» не существует, потому что человек пишет +/- на одном уровне и от него особо не отступает.

    WTF?! Люди развиваются, читают книжки, строят архитектуры, контрибьютят оупенсорс, вырастают из зелёных джунов в бородатых синьоров, пересматривая свои взгляды на разработку ПО в целом. Взрослеют в конце концов. Это нормальный процесс становления разраба, суть которого не в очередной лычке, а в ежедневном развитии. Какой ещё ± один уровень?

    Опять же, к SOLID это не имеет отношения, ну).

    Ещё как имеет. Невозможно создать 100% каноничный код. Просто невозможно. Но периодически попадаются персонажи, которые в угоду этой каноничности и своей синьорности начинают наслаивать такое количество «абстракций», что весь проект превращается в каноничный кусок говна, приправленный массой красивых терминов, но не менее от этого воняющий.

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

    Мы уже давно отошли от темы топика.
    Помимо бородатых синьоров, которых ещё нужно захантить и удержать, на проектах есть 2/3 джунов-мидлов, которые далеко не всегда могут отличить хороший код от плохого. И с ними нужно как-то взаимодействовать, чтобы получить результат в виде продукта.
    Честно говоря, я даже не уверен что для проекта хуже: очевидно для всех и прогнозируемо говняющий джун, или синьор с серьёзным лицом неочевидно для всех два года педалящий за зарплату очередной идеальный фреймворк, которые решит все мировые проблемы и ответит на главный вопрос Вселенной, вместо того чтобы решить какую-то одну проблему конкретного юзера.

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

    Идеализм, не? Стремления — это прекрасно. Но есть бабло, которое платят кастомеры за продукт, которое перенаправляется бизнесом в зарплаты разрабов, создающих продукт. Нет продукта — нет бабла. Всё просто. Да, это бизнес-контекст. Но он есть в любом продукте. И, очевидно, в гораздо меньшей степени в «сервисных компаниях». Отсюда и основная разница во взглядах на разработку в целом. Помимо персонализированного «человеческого фактора».

    Да, беда случается, когда саппорт продукта в следствии неправильных/ситуативных архитектурных (или на любом другом уровне) решений становится слишком дорогим. Но ИМХО это происходит абсолютно с любым продуктом, кем бы и как бы он не был создан. Это естественная эволюция. Это просто неизбежно. И задача бизнеса, архитекторов, синьоров — управлять хаосом и находить баланс. Иначе сожрут конкуренты, которые стартовали чуть позже, но имеют преимущество в виде уже накопленной экспертизы, подогретого рынка и готовых кадров, которых можно схантить у динозавров.

    90% стартапов не взлетают, камон, какая цена, какое «бывает», если упасть — это правило для стартапа, а не исключение.

    Стартап — это совсем о другом. Упасть — это не правило, это следствие либо негативной проверки гипотезы наличия рынка реальным продуктом, либо тупорылости принимаемых решений на любом из уровней. Но стартап жив, пока есть хотя бы один человек, которые верит в свой продукт. Стартап — это не о смерти. Стартап — это история о силе веры в свой продукт и способности либо услышать своих кастомеров и решить их проблемы, либо создать для кастомеров нечто совершенно новое и убедить их в том, что это обязательно нужно купить.
    В основе всего — продукт, решающий конкретную проблему, состоящий из строчек кода, написанных инженерами. И если инженеры не способны за этими строчками кода видеть целостный продукт как цель своей работы — пушной зверь придёт очень быстро за этим стартапом.
    Допускаю, что в кровавом энтерпрайзе ситуация иная и там есть возможность годами педалить идеальный код, теряющийся в миллионах других строк кода и планах развития на 25 лет. Но я не имел чести в нём работать, посему графоманить могу только о мелких/средних продуктах.

    Поддержал: Valeriy Shvets
  • Як співбесідувати сіньйорів-помідорів?

    Между проектом «в ящик» с командой, разгоняющей кофе по утрам сон и скуку, и реальным стартапом, где люди бьются за результат даже ценой выкидывания нахрен всего что было написано,- пропасть.
    Лично я считаю, что стартап-культура — это единственно приемлемая в динамичном мире айти. Продукт и захват мира — цель любого стартапа, которую я разделяю и проповедую. Не код. Продукт.

  • Як співбесідувати сіньйорів-помідорів?

    Много проектов пишутся «в ящик» или через некоторое время закрываются. Поэтому обобщение 80го левела.

    Значит хреново работали, если проект закрылся. Причём, на всех уровнях. Так бывает.
    Если проект изначально «в ящик», то на кой в него вообще идти работать? В чём смысл? ЗП получать?

    Если принимаемое решение ведёт к прибыли или убыткам, оно относится не к кодингу как таковому, а к выбору идеи/инструментов/приоретизации/архитектуре etc.

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

    Решать проблемы — однозначно, платить — как получится. А вот за поддержку потом платить придётся, и чтобы не пришлось платить очень дорого, нужны в т.ч. солид принципы.

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

    Я не отрицаю необходимость знать базовую теорию. Не отрицаю необходимость писать maintainable/supportable код. Не отрицаю, что изначально «правильная архитектура», вдумчиво реализованная бородатыми синьорами, будет легче в дальнейшем саппорте и всех прочих акспектах. Но во-первых, не все готовы писать такой код. Во-вторых, сколько это будет стоить? В-третьих, когда будет релиз? Поэтому когда в команде появляется персонаж, который ничего не видит дальше своей IDE, то это скорее не преимущество, а сигнал приглядывать за ним повнимательнее чтобы после череды заваленых пулриквестов «патамуша не по солид» не стал для проекта проблемой.

  • Як співбесідувати сіньйорів-помідорів?

    Работать в вашей компании большая честь? )

    Я не по этой части. Я больше по теме поколбасить код. Посто не приемлю работу с людьми, у которых mindset «что сказали — то и буду делать».

  • Як співбесідувати сіньйорів-помідорів?

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

    Поддержал: Andriy Maletsky
  • Як співбесідувати сіньйорів-помідорів?

    Ой, всё ©

  • Як співбесідувати сіньйорів-помідорів?

    Любая написанная строчка кода, любое принимаемое на рабочем месте решение в той или иной степени ведёт либо к прибыли, либо к убыткам. Но программисты почему-то считают своей целью написание кода. Желательно — идеального. А на самом деле их задача — создать продукт, который будет решать проблемы юзеров, которые будут платить за это деньги. Пока видение конечного результата ограничивается кодом, то и холивары как правило о коде.

  • Як співбесідувати сіньйорів-помідорів?

    Дело не в том, кто и куда контрибьютит. А в подтверждениях книжных теорий реальными проектами, проживших хотя бы пяток лет.
    Лучшая архитектура — та, которая приносит максимум денег. Всё остальное — вечное бла-бла-бла об идеальном коде.

  • Як співбесідувати сіньйорів-помідорів?

    Всё понятно. Теоретики...

  • Як співбесідувати сіньйорів-помідорів?

    А можно конкретный пример проекта без нарушений SOLID? Только не какие-то поделки или «внутренний мега-секретный проект под NDA», а что-то из мира open source, чтобы все дружно могли оценить и поучиться.

  • DOU Labs: как в IntelVerse создали AI-коуча по персональному развитию

    Всё понятно.

  • DOU Labs: как в IntelVerse создали AI-коуча по персональному развитию

    Обучаясь на обратной связи, наш AI с каждым разом будет давать все более релевантные советы.

    Что из себя представляет функция потерь?
    На каких данных вы обучали модели и как верифицировали их работоспособность?

  • Как создать свой алгоритм поиска локаций, используя AI

    Да и программирование в целом — это очень просто. Спасибо стековерфлоу. :)

    Поддержал: Alexander Konduforov
← Сtrl 123456...19 Ctrl →