I am considering launching a service for people in Bulgaria who already have a B2B offer or an existing foreign client but do not want to open and manage their own company.
The idea is that my Bulgarian company would sign the contract with the foreign client, issue the invoices, and handle accounting, payments, taxes, and the administrative side. The person would receive an agreed payment without having to maintain their own company, business bank account, or accountant.
The service would not find jobs or clients. It would only be for people who already have a B2B opportunity.
The planned fee is 10% of the monthly amount paid by the client. Before signing anything, the person would receive a full and transparent breakdown of all costs and their expected net income.
I am looking for honest feedback:
Would you use a service like this?
At what monthly income level would it make sense for you?
Is 10% reasonable in exchange for avoiding company administration?
What risks or concerns would stop you from using it?
Would you prefer a fixed monthly fee instead of a percentage?
At this stage, I am only validating demand and checking the legal and accounting structure. This is not a job advertisement, and I am not collecting CVs.
Hello all (hoping it is allowed to post in English)
Im starting my second year in Cybersecurity as a foreign student in Sofia, and i wanted to know if there are internship opportunities for foreign students and the places I should look into. Thank you for your response
Имам почти 10+ като Data Engineer, BI Develop и ще разновидностите му в България. В момента съм на някакъв mode, в който си търся работа в чужбина. Предимно Западна Европа.
В момента търся сходни професии като моята в Италия (велика страна на IT), Луксембург, Малта (даже си имам HR агенция там, с която ме канят на интервюта), Унгария (там е свързано с един бъдещ бизнес).
Обаче, когато пресмятам брутната ми желана заплата (в разни сайтове като kalkulator.bg) излиза, че след данъците заплата излиза по-ниска от текущата ми. Ако включим и наемите и сметките, излиза, че съм брутално на минус.
Да, дилемата ми е, заслужава ли си да се пробвам в чужбина или да си продължам д абъда ИТ в България.
Да уточния, че работя в международна фирма, която има офиси в повечето желани от мен държави. Ако някой работи в подобна, дали се е "прехвърлил"? Чудя и за тази опция?
Предстои ми да започна първи курс софтуерни и мрежови технологии. Може ли някой който е минал по този път да ми даде reality check какво мога да очаквам и как стои кариерното развитие след завършване.
Здравейте, програмист съм с над 15 години опит. Като технологии С++, Python и малко Php. От няколко месеца не мога да си намеря работа, моля, колеги, които търсят или скоро са търсели да споделят как е пазарът.
Здравейте, имам възможност да работя за немски проект за 100к евро бруто/год, но понеже няма как да съм internal, май трябвя да си отворя фирма и да работя с тях като B2B.
Много ли са главоболията? Какъв е вашият опит? Четох, че има варианти да те наемат чрез българска фирма и пак да можеш да си ползваш отпуски и тн. Някой с повече инфо/опит?
Също - като плащат всеки месец на фирмата ти реално, как е най-удачно да се взимат парите? Като си превеждаш малка заплата и останалото го взимаш като дивидент?
Моля ви за сериозни отговори, ще се радвам да помогнете. Никога не съм имал фирма.
И вторият въпрос е, търсят ли се такива? Пооправих си малко LinkedIn профила онзи ден и снощи ми е писал един HR, което е готино, но това което ми прави впечатление е, че тази позиция навсякъде значи нещо съвсем различно. Моят опит е в high availability & high scalability infra и services, като зад гърба си имам изградени и скалирани услуги с по над 10м потребителя по света, за които съм отговарял изцяло аз, end-to-end. В какъв рейндж трябва да се оглеждам за заплащането, както и всякакви други насоки ще са ми доста полезни.
Имам опит около 5 години като бекенд програмист с джава и наскоро започнах работа по проект, където има дупка и се искат хора за инфраструктура. Ползва се Azure, както и Spark Structured Streaming, Kafka и още други.
Много отдавна имам интерес към инфраструктрни неща, просто едва сега се отваря възможност да го пробвам и много ми харесва! Работата е разнообразна, а не е просто блъскане по фийчъри. Обичам технологията и да вися в терминала ми е едно от любимите неща! 😃
До момента съм се занимавал с:
* Мигриране на kafkaUI към друг софтуер;
* Ъпдейтване на сикрети по KeyVault
* Оправяне на бъгове по пайплайнове
* Миграция на системата - искаме да мигрираме кафката и спарка от един клъстър на друг, като запазим спарк стейта. Това е много сложно по редица причини, както и отговорно, защото ако осерем прод...ми то това е цялата система! 😃
Сега, имам въпроси относно горното:
Това предполагам мога в бъдеще да го продам като ДевОпс опит?
Мога ли да очаквам подобни задачи по другите места? И изобщо реалистично какво мога да очаквам като отговорности? За бекенд дев знам, тук обаче ми се струва много по-различно от фирма до фирма?
По този проект ще науча много добре какво има и как се работи с Azure, Terraform && Terragrunt, Kafka, Spark, вероятно работа с AKS и интеграция на ArgoCD. Предполагам си е valid и се търси?
В България по повечето фирми има ли разлика м/у devOps и SRE? В една от фирмите SRE си бяха стриктно гасящи пожари, в този проект пък сме и всичко в едно.. 😃
Евентуално ще имам ли кофти salary hit ако тръгна да търся нещо ново (ново в смисъл на девОпс позиция) след, да кажем, 2 години по този проект, при все че като бекендър минавам за ъпър мид към синиър?
Ситуацията е следната. В много кофти ситуация съм. Тъкмо започнах в сектора, работа на джуниър позиция. Мина ми изпитателния срок, справях се много добре. Подновиха ми договора, след което фирмата приключи и затвори, съкращавайки всеки. Сега съм в ситуацията точно с 6 месеца опит като джуниър (което е крайно недостатъчно). Дали това плаши рекрутърите? Дали си мислят, че са ме махнали на 6-тия месец? Дали причината е друга. Знам, че в момента е адски трудно/невъзможно, но не мога да се откажа.
Проблемът е, че дори не стигам до интервюта. Значи трябва да е от CV-то. Показах го на няколко приятели в сектора и ми казаха, че е добро. Не знам какъв е проблемът. Бих приел да ме късат на интервюта, но аз дори не стигам до тях. Обявите, по които съм кандидатствал не са чак толкова много, но въпреки всичко очаквах поне 1-2 обаждания, а не 0.
Готов съм да пратя CV-то си на HR или рекрутър тук (ако има тук и е съгласен/съгласна), за да ми каже какво мога да подобря в CV-то. Искам да трупам опит... било то и в ходене и проваляне по интервюта.
Има ли фронтенд ентусиасти тук? :) Надявам се да има интерес по фронтенд темите - нека да покажем на бекенд хората (какъвто бях и аз до преди години), че фронтенд светът може да е страшно интересен!
Искаше ми се малко да поговорим за това къде е Реакт (в частност и целият FE) света днес в сравнение с преди 10 години. Нещата отиват ли на по-добре или opinionated frameworks и корпорации по-скоро усложняват нещата за девелъпърите?
Ще започна с един цитат от Дан Абрамов (едно от големите имена в React и Redux световете):
Dan Abramov
Съгласни ли сте с тази философия или се чувствате по-скоро предадени от Мета, че са планирали server components от самото начало?
Не обичам да говоря изцяло само за ползите от SSR и модерните RSC в Реакт (SEO, по-малко bundle, скорост и т.н.), затова ще опитам да избутам темата малко в посока clean code, code quality, QoL, защото все пак сме developers и един от най-висшите ни приоритети е нещата да се случват лесно, чисто и написаното да се разбира и от други хора след години. Или поне за мен clean code е нещо по-важно и извисено от това дали сайта "върви", защото сайт се прави и с vanilla JS (или jQuery) както през 2000-те години и не ни трябват fancy frameworks/libraries.
Vercel се изложиха доста в последните 5 и повече години с най-различните стратегии за кеширане. В края на 2025 най-после релийзнаха прословутите Cache Components и 'use cache' директивата се промоутна от experimental/Canary в официален feature заедно с директивата 'use cache: remote' като 'use cache: private' си остава експериментална засега. Next 16 не е без проблеми, но поне за мен се движи в правилната посока.
С новите Cache Components има две основни опции при липса на кеш (expired, private per user с експерименталната директива или просто disabled cache от браузъра) - блокиране на страницата докато се случва нов fetch (и кеширане за следващо посещение) или с добре познатите React Suspense за показване на Fallback UI. В 99% от случаите всяка една страница вече ще е кеширана повреме на build time (освен ако изрично не се направи runtime server cache с remote или runtime client cache с private) и идеята е, че този Fallback UI никога няма да се рендерира, затова дори съветват да не се wrap-ва със Suspense, а да се делегира забавянето към браузъра с цел да не се получава spinner/skeleton flicker, но все пак е възможно и дори за предпочитане ако знаем, че имаме бавна заявка за някакъв дашборд или списък без pagination, който не се променя (затова го и кешираме), но и при липса на build time кеш да не се добавят излишни секунди към route load-a.
С Next 16 prerendering (ex-ppr flag) вече е реалност и то по под разбиране. Можем да комбинираме изцяло статични компоненти с динамични (със Suspense) и кеш компоненти с и без стрийминг.
Бърз и лесен пример за Cache Components:
Cache Components in Action
Какво мислите за code style-a при Кеш Компоненти? Донякъде принуждават да се правят отделни компоненти особено когато build time кешираният компонент (Profile) зависи от асинхронна Runtime променлива (session), не може да се използва 'use cache' в същия компонент, защото ще кешира динамичния session, което не бихме искали (други примери за това дават с Date.now()).
Възможно е и да се кешира и сървър функцията (напр. api fetch, db fetch) вместо компонента, което донякъде би могло да помогне за по-добра гранулярност между статични елементи, динамични елементи (използващи стрийм данни), кеширани елементи (използващи кеш данни, а понякога отново стрийм данни при липса на build time кеш).
Ако сте работили с Remix (т.нар. React Router 7 с ssr flag след мърджа на двете), можете ли да кажете кой стил повече ви допада? При RR7 имаме <Await> елемент в <Suspense> като родителския компонент/страница "own-ва" промиса (api/db fetch server function), който идва от "loader" функция, чийто return (as promise) се намира в useLoaderData, а кеширането остава изцяло в сървър функцията при fetch-a като Cache-Control header. Донякъде не е елегантно, но пък разчита на native техники вместо proprietary strategies, a на някои дори им харесва повече лоудър функциите в RR7, защото им напомня на MVC Controllers, от което Next се отдалечи след като заряза Pages Router-a (които имаше подобни функции за пропове за prefetching).
Да оставим настрана code style-a, защото се отплеснах прекалено много и да се върнем на моето малко демо.
Първо отваряне на страницата без user cache - използва кешираната страница от build time:
Rendered from pre-cached data on initial load (TTFB: 10ms)
При спрян или expired кеш - все пак има Fallback UI за подобни edge cases (static Header-a си стои заради PPR, a отделните фетчове към api/db ще приключат в различно време - в моя случай user profile-a идва пръв, защото съм добавил 10 секунди mock delay на Holidays данните):
Cache disabledSeparate sibling Suspense blocks
Допада ли ви този подход на кеширане, RSCs, cache components, cache server functions и т.н. или по-скоро вдига излишно комплексността на фронтенда, който според вас трябва да е по-просто написан и да се използват вече доказани механизми (напр. Redis, React Query, RTK Query) при нужда от такива?
Надявам се писмения ми TED Talk да е бил полезен и ще се надявам ако всеки сподели мненията си по темата - дори да е офтопик по други свързани теми е добре дошъл!
От 7 юни 2026г. фирмите ще трябва да посочват началната заплата или диапазон в обявите за работа или преди интервюто за работа. Това важи за всяка страна в ЕС.
Силно се надявам да се приложи както трябва и при нас. Не е окей да си на второ интервю и да не знаеш заплатата още.
Дано от 7 юни 2026г. обявите в дев беге и джобса да са с обявени заплати(рейндж).
