The New Joiner’s First 90 Days: How EurthTech Onboards Engineers into Real Products

Author: Srihari Maddula  •  Founder & Technical Lead, Eurth Techtronics Pvt Ltd

Category: Culture & Career Growth  •  Estimated Reading Time: 18–20 minutes

Published: April 2026

A Note Before We Begin

I am writing this blog directly to you — the engineer who is thinking about joining EurthTech, or who has just joined, or who is curious about what kind of company this is and how we think about the people we bring in.

Over the past several months, EurthTech has grown. New engineers have joined the team. Some came from college, bringing the energy and theoretical foundation of a fresh education. Some came from other companies, bringing habits, expectations, and skills shaped by different environments. All of them have been through some version of the same experience in their first ninety days — an experience that I want to be transparent about, because I think transparency about what happens here is the most respectful thing I can offer to someone considering a decision as significant as where they will spend their engineering career.

This is not a recruiting pitch. I am not going to tell you that EurthTech is the best place to work or that we have the best culture or that you will love every day here. What I am going to tell you is what actually happens in your first ninety days — what we put in front of you, what we expect from you, what will challenge you, and what you will have become by the end of it if you engage with it fully.

If that picture appeals to you, we should talk. If it does not, this blog has done you a service by being honest before we invested each other's time.

FROM THE FOUNDER  EurthTech is a company that builds real electronics products for real clients — in agriculture, industry, healthcare, and strategic. There is no simulated environment here, no training project that goes in a drawer. If you join us, your work ships. Your decisions matter. That is both the appeal and the demand of this place.

Section 1: What Kind of Company EurthTech Is — And Why It Matters for How We Onboard

1.1 — An Electronics Product Design Company, Not a Software House

This distinction matters more than it might appear. Software companies onboard engineers into codebases. We onboard engineers into systems — hardware, firmware, signal chains, physical deployment environments, manufacturing constraints, and client relationships that have timelines and consequences. The learning curve here is not just technical depth in one domain. It is breadth across multiple domains simultaneously, held together by a systems engineering perspective that takes time to develop.

At EurthTech, a firmware engineer is expected to be able to read a schematic, understand why a sensor is behaving unexpectedly, have a conversation with a client about what their problem actually is, and write a test plan for a subsystem they are developing. They are not expected to be expert at all of these from day one. They are expected to be moving toward all of them continuously.

If you came from a company where your job was to write application logic and someone else handled hardware, someone else handled client communication, and someone else handled testing — you will find the first ninety days here disorienting. Not because the individual skills are beyond you, but because the expectation that you hold all of them simultaneously, at a professional level of quality, on a real client project, will feel different from anything you have done before.

1.2 — Small Team, Real Accountability

EurthTech is not a large company. We do not have the luxury of layers of review, redundant team members who can catch your errors before they reach the client, or a dedicated QA team whose job is to find what you missed. In a small company, quality is everyone's direct responsibility — not a function that happens downstream of your work.

This means that the bar for what you deliver — even in your first weeks — is set by what a client can actually use, not by what looks acceptable in an internal review. That standard is higher than what many engineers have been held to in larger organisations, and it is higher than what most universities hold students to. Adjusting to it takes time, and some engineers find it uncomfortable. The ones who adjust become meaningfully better engineers, faster, than they would in an environment where their output has more buffer between it and its consequences.

HONEST TRUTH  Joining a small, fast-moving engineering company is harder than joining a large one in the short term. There is less structure, less documentation, less repetition of familiar tasks. In the medium term, the growth rate is higher. The question to ask yourself honestly is whether you are optimising for comfort in the next six months or capability in the next three years.

1.3 — We Build Across Sectors

In a given month, EurthTech may be working on an agricultural sensor deployment, a medical device subsystem, an industrial monitoring platform, and a defence electronics requirement simultaneously. Each of these sectors has different regulatory context, different client vocabulary, different deployment constraints, and different definitions of what an acceptable product looks like.

A new engineer joining us will be exposed to this variety whether or not they are assigned to multiple sectors immediately. The conversations in the office, the code reviews, the design discussions — they span domains. An engineer who is curious about sectors beyond their immediate assignment will absorb understanding that makes them more valuable across every future project they work on. An engineer who walls themselves inside their assigned task will develop more slowly, not because they are less capable, but because they are using less of what EurthTech offers.

Section 2: The Gap Between What You Were Taught and What Real Hardware Demands

I have onboarded engineers from some of the best engineering colleges in Andhra Pradesh and Telangana. I have brought in engineers with three and five years of experience at other companies. And across almost every one of them, the first significant adjustment in their first ninety days is the same: the discovery that what they were taught, and what they practised in their previous environment, is a simplified model of what real hardware engineering actually looks like.

This is not a criticism of their education or their previous employers. Simplification is necessary for learning. You cannot teach embedded systems design without starting with ideal components, ideal signals, and ideal protocols. The gap appears when the simplifications are removed — when the components are real, the signals are noisy, the protocols fail at inconvenient moments, and the deadline is not extended because the hardware is behaving unexpectedly.

The table below maps the most common theory-versus-reality gaps that I have seen new engineers at EurthTech encounter in their first ninety days. I am sharing this not to discourage you, but because I believe that naming a challenge honestly is the most useful preparation for it.

What You Learned (Theory)	What EurthTech Will Teach You (Reality)
Datasheets are complete and accurate	Datasheets are marketing documents. The real behaviour is in the errata, the application notes, and the forum threads at 2am.
The schematic is the truth	The schematic is the intention. The PCB is the truth. And the field is the final exam.
If it works on the bench, it works	The bench is a controlled fiction. The field is the uncontrolled reality. Design for the field.
More resolution means more accuracy	A 16-bit ADC on a noisy board measures noise at 16-bit resolution. Resolution is ceiling, not floor.
The protocol guarantees delivery	Every protocol has failure modes. Your firmware is responsible for what happens when the protocol fails.
Debug until you find the bug	In hardware, 'debugging' often means forming a hypothesis, designing an experiment, and accepting uncertainty.
The software can fix the hardware problem	Software can compensate for hardware limitations. It cannot reverse physical reality.
If the spec says it works, it works	Specifications describe typical behaviour under typical conditions. Your deployment is rarely typical.

Every engineer who has shipped real hardware has been through the experience of discovering these gaps. The ones who become excellent engineers are those who, when they discover the gap, become more curious rather than more defensive. They ask why the datasheet was optimistic. They ask what made the bench different from the field. They build a mental model that includes the gap, and they use that model to make better decisions on the next project.

The ones who struggle are those who respond to the discovery with frustration directed at the hardware, the client, the product specification, or the team. Hardware does not care about your frustration. It responds to understanding.

HONEST TRUTH  The most important thing I look for in an engineer during their first ninety days is not how quickly they deliver. It is how they respond when something does not work the way they expected. Curiosity and systematic reasoning in the face of unexpected behaviour is the single strongest predictor of long-term engineering effectiveness that I have observed across more than two decades in this field.

Section 3: The 90-Day Structure — What Actually Happens

The first ninety days at EurthTech are not a formal programme with a fixed curriculum. They are a structured progression with clear milestones, adapted to the individual engineer's background and the active projects at the time they join. The structure below represents what a typical first ninety days looks like — not as a guarantee of exact sequence, but as a representation of the progression we aim to create.

Phase	Theme	What Happens	What You Achieve
Week 1	Orientation	Tools, environment, codebase walk-through, meet every active project	Understand what we build and how we build it
Week 2–3	Guided Contribution	First real task on a live project — small, bounded, well-defined, with a senior alongside	Make your first commit to production code
Week 4	Independent Task	Own a defined deliverable end-to-end — from understanding the requirement to verified output	Deliver independently, ask the right questions when stuck
Week 5–6	System Exposure	Read the full architecture of one product — hardware, firmware, cloud pipeline, test strategy	Hold the full picture of one real product in your head
Week 7–8	Debug Ownership	Take a bug or anomaly from report to root cause to fix, with documentation	Debug something you did not write, in hardware you did not design
Week 9–10	Client-Aware Work	Contribute to a deliverable that goes to a client — review, timeline, quality bar awareness	Understand what 'good enough for a client' means in practice
Week 11–12	First Ownership	Own a complete module, sensor driver, or system component — spec, implementation, test	Ship something you can put your name on

The progression from guided contribution to independent ownership is not arbitrary. It is designed around a principle that I have observed holds consistently across engineering domains: you learn a system most durably by contributing to it under gradually decreasing guidance, not by reading about it or watching others work on it. The orientation week gives you enough context to be useful. The guided contribution phase gives you enough exposure to ask better questions. The independent tasks give you the experience of owning an outcome. By Week 12, you should be someone the team relies on, not someone the team is teaching.

3.1 — Week 1: Orientation — Respect for Context

The first week is not a formality. It is the foundation on which everything else is built. In that week, you will meet every active project — not just your assigned one. You will understand what we are building for each client, at what stage, and why the technical choices made so far are what they are. You will set up your development environment, understand our version control discipline, and read the documentation that exists — including, honestly, the documentation that does not exist yet and should.

The most important thing you can do in Week 1 is ask questions without embarrassment. The questions that feel obvious to you are often the questions that expose assumptions the team has been making without examining them. New eyes see things that experienced eyes have stopped noticing. Your questions in Week 1 are valuable — more valuable than most new joiners realise.

At the end of Week 1, you should be able to answer: what are the five active projects at EurthTech right now, what is the client need for each, and what is the current technical status? If you cannot answer that question at the end of the week, ask for more time with the projects you have not understood yet.

WHAT WE EXPECT  By end of Week 1: You can describe every active project at EurthTech at the level of client need, technical approach, and current status. You have your development environment running. You have read the most important documentation for your assigned project. You have asked at least ten questions that you did not know the answers to.

3.2 — Week 2 to Week 4: The First Real Work

From Week 2, you are working on a live project. The task you receive in Week 2 is deliberately scoped to be completable — it has a clear input, a clear expected output, and a clear way to verify that the output is correct. It is not trivial, but it is bounded. The senior engineer alongside you is not doing the work for you. They are available when you are stuck, they will review your output before it goes anywhere consequential, and they will tell you honestly when what you have produced is not ready.

Week 3 typically involves the first experience of something not working in the way the task description suggested it would. This is not a design flaw in the onboarding. It is the most important learning event of the first ninety days, and it is intentional in the sense that real engineering always involves unexpected behaviour and the task is always designed from real project work, not from a textbook problem.

How you handle that moment tells me more about your engineering potential than any technical test. Do you read the datasheet more carefully? Do you probe the signal on the hardware? Do you form a hypothesis and design an experiment to test it? Do you ask the right person the right question? Or do you spend two days in the same loop, trying the same approaches with diminishing confidence?

Week 4 is the first independent delivery. You own the scope, the timeline estimate, and the quality of the output. Your senior engineer is not looking over your shoulder. You will plan, execute, encounter the unexpected, adjust, and deliver. By the end of Week 4, you will have the first real data point on what it feels like to own an engineering outcome at EurthTech.

3.3 — Week 5 to Week 8: Building System Understanding

The middle phase of the first ninety days is where the most significant growth in systems thinking happens — and it is also the phase where engineers who came from narrow specialisation find the adjustment most demanding. During this period, you move beyond your immediate task and begin to understand the full architecture of a real product.

This means reading firmware you did not write, understanding hardware decisions you were not part of, and asking why things are the way they are — not to critique them, but to understand the reasoning that produced them. Every product at EurthTech has a history. Components were chosen for reasons. Architectural decisions were made under constraints. Some of those constraints no longer apply, and some of those decisions should be revisited. But you cannot have that conversation usefully until you understand the original reasoning.

The debug ownership task in Week 7 to 8 is one of the most valuable experiences of the entire first ninety days. You will be handed a problem that you did not create — a bug, an anomaly, an unexplained behaviour — and you will be responsible for taking it from report to root cause to verified fix. The product of that exercise is not just the fix. It is a written root cause analysis that explains what happened, why it happened, and what design or process change would prevent it from happening again.

That document is the most useful artefact a junior engineer can produce, because it proves to the team — and to yourself — that you can reason systematically about a system you did not build, in a domain that may be partly unfamiliar, and arrive at a defensible conclusion. That is the core skill of embedded systems engineering, and it is the skill that separates engineers who grow quickly from engineers who plateau.

WHAT WE EXPECT  By end of Week 8: You can describe the full architecture of at least one EurthTech product — hardware, firmware, connectivity, and deployment. You have debugged and documented at least one issue you did not create. You have had at least one conversation where you disagreed with a technical decision and explained your reasoning clearly.

3.4 — Week 9 to Week 12: Client Awareness and First Ownership

The final phase of the first ninety days introduces the dimension that most distinguishes commercial engineering from academic or hobby engineering: the client. At EurthTech, the client is not an abstract stakeholder. They are a person or organisation whose operations depend on the product we are building for them, whose money is funding the work, and whose trust in us is something we have earned and must maintain through the quality of our output.

Client-aware work does not mean you are in client meetings from Week 9. It means that every deliverable you produce during this phase is reviewed against the question: would a client whose name I know and whose requirements I have read accept this as production-quality work? That standard is different from the standard of 'does it work on my bench'. It includes documentation quality, code comments, test coverage, edge case handling, and the confidence you can express about the failure modes you have and have not validated.

The first ownership milestone in Weeks 11 and 12 is the most significant moment of the first ninety days. You take responsibility for a complete module, driver, or system component — from reading the requirement, through implementation, through writing your own test cases, through documentation, to review and merge. The output of this milestone is not just the code or the hardware deliverable. It is the experience of having built something complete, at professional quality, that you can describe and defend in a design review.

Engineers who reach this milestone with a genuine sense of ownership — who can say 'I built this, here is how it works, here is how I tested it, here are its known limitations' — are engineers who are on a trajectory that will make them excellent. Engineers who reach this milestone with relief that the ninety days are over are engineers who may have completed the tasks without internalising the growth that the tasks were designed to produce.

FROM THE FOUNDER  What I want to see at the end of ninety days is not a list of completed tasks. I want to see an engineer who has become harder to rattle — who is less surprised by unexpected hardware behaviour, more systematic in their debugging, more honest about what they know and do not know, and more curious about the domains they have not yet explored. That is the person I want working on the products that carry EurthTech's name.

Section 4: What EurthTech Gives You in Return

Accountability flows in both directions. If I am asking you to work on real projects, hold yourself to a professional quality standard, develop breadth across hardware and firmware domains, and grow quickly in an environment that does not have the support structure of a large company — then I owe you an honest account of what you get in return.

4.1 — Exposure That Takes Years to Get Elsewhere

In a large company, a junior engineer may spend two years in a single domain — a specific protocol, a specific product line, a specific class of sensor. At EurthTech, in ninety days, you will have touched multiple domains, multiple sectors, and multiple layers of the product stack. That breadth is not comfortable — it requires you to be frequently outside your knowledge boundary. But it is the fastest way to develop the systems engineering perspective that makes embedded engineers valuable at the highest level.

The engineers who leave EurthTech after two or three years — to start their own ventures, to take senior roles elsewhere, or to work on deep-tech projects that require broad system-level capability — consistently tell me that the breadth they developed here was the thing that opened those doors. You cannot develop that breadth in an environment that keeps you safely inside a single domain.

4.2 — Direct Access to the Founder

I am not a distant CEO. I am in the office, working on the same problems, sitting in the same design reviews, and available for the technical conversations that matter. If you have a question about why a design decision was made, you can ask me. If you disagree with a technical direction, you can tell me why. If you are struggling with something, you can say so directly rather than navigating layers of management to get to someone who can actually help.

This access is unusual. It is one of the genuine advantages of a small company that I want to name explicitly rather than assume you will discover. Use it. Engineers who are too intimidated by the founder's presence to ask hard questions waste an opportunity that engineers at larger companies would value enormously.

4.3 — Products That Matter

The work we do at EurthTech is not abstract. The agricultural monitoring systems we build affect the livelihoods of farmers who use them. The medical devices we contribute to affect the clinical decisions of physicians who depend on accurate measurement. The industrial monitoring systems we design affect the safety and efficiency of facilities that operate twenty-four hours a day.

That weight is real, and it is one of the reasons we hold the quality standard we hold. It is also one of the reasons that working here feels different from working on software that has no physical consequence. When a system you built is deployed and operating correctly in the field, there is a quality of satisfaction that is not available from shipping a web page or a mobile application. It is the satisfaction of engineering something physical into the world and having it work as designed, in conditions that you did not fully control, for a person who depended on it.

4.4 — An Honest Assessment of Your Progress

I will tell you what is working and what is not, clearly and directly, without the corporate softening that makes feedback technically accurate but practically useless. If your code quality is not at the standard required, I will tell you specifically what is wrong and what needs to change. If your debugging approach is ineffective, I will tell you what a more systematic approach looks like. If you are growing faster than I expected, I will tell you that too, and I will adjust what we put in front of you accordingly.

This directness is not comfortable for everyone. Some engineers prefer feedback that is delivered more gently. I respect that preference and I will not be needlessly harsh — but I will not sacrifice clarity for comfort, because unclear feedback is not kind. It is a waste of the engineer's time and a disservice to their development.

WHAT WE EXPECT  What I ask in return for direct, honest feedback is that you receive it as information, not as judgment. A critique of your code is not a critique of your worth as an engineer. It is data about the gap between where you are and where the work requires you to be. Engineers who can hold that distinction consistently are engineers who improve rapidly.

Section 5: Who Thrives at EurthTech — and Who Finds It Difficult

I want to be as honest about this as I can, because the wrong fit is costly for both parties — for the engineer who spends months in an environment that does not suit them, and for the team that invests in someone who will not grow in the way the work requires.

5.1 — Engineers Who Thrive

The engineers who grow fastest at EurthTech are almost always characterised by one thing above all others: genuine curiosity about how physical systems work. Not curiosity as a personality trait they describe in interviews, but curiosity as a behaviour that shows up consistently — in the questions they ask, in the experiments they run to validate their understanding, in the problems they choose to investigate even when nobody asked them to.

Beyond curiosity, the engineers who thrive here are those who are honest about what they do not know. In a small team working on real client projects, an engineer who claims to understand something they do not understand creates problems that are discovered at the worst possible moment. An engineer who says 'I am not certain about this and here is my current understanding' creates the opportunity to correct a misunderstanding before it becomes a production issue.

They are also engineers who find breadth energising rather than exhausting. The firmware engineer who is genuinely interested in why the PCB layout choice matters, who reads the hardware schematic not just for pin assignments but for signal chain architecture, who asks the client questions about their operational context not because they were told to but because the context helps them make better technical decisions — that engineer will grow faster here than anywhere else they could be.

5.2 — Engineers Who Find It Difficult

The engineers who find EurthTech difficult are typically those who came looking for a stable, well-defined role with clear boundaries — a specific domain, a specific set of tools, a specific process that they can master and repeat. That is a legitimate preference and it describes many excellent engineers. It is not what EurthTech offers.

Engineers who find it difficult often also struggle with the accountability structure of a small company. When your work goes directly to a client and directly affects a product that is deployed in the field, the gap between effort and consequence is very short. Some engineers find that motivating. Others find it stressful in a way that does not resolve over time.

And there are engineers who find the theory-to-reality gap demoralising rather than energising. When the datasheet is wrong, when the bench result does not match the field result, when a design that looked correct on paper produces unexpected behaviour in hardware — some engineers experience this as a failure of themselves or of the design. The engineers who thrive experience it as an invitation to understand something they did not understand before. That difference in orientation is fundamental, and it is very difficult to change in someone who has not already developed it.

HONEST TRUTH  If you are reading this and recognising yourself in the 'finds it difficult' description — that is not a reason not to join us. It is a reason to think carefully about whether this is the right moment in your career for this kind of environment, and to be honest with yourself about what you are genuinely looking for. EurthTech will be here when the fit is right. Working here when the fit is wrong helps neither of us.

Closing: What Ninety Days Actually Builds

If you engage fully with the first ninety days at EurthTech — if you bring curiosity to the orientation, push yourself through the discomfort of the first independent task, invest in understanding the full architecture of a real product, debug something that stumped you, and ship a complete module with your name on it — you will be a different engineer at the end of it.

Not a perfect engineer. Not an engineer without gaps. But an engineer who has experienced what it feels like to hold a complete system in your mind — hardware, firmware, signal chain, deployment environment, and client expectation — and to contribute meaningfully to that system under real conditions.

That experience is not transferable by description. You cannot acquire it by reading about it, including by reading this blog. You acquire it by doing the work, in an environment that holds you to the standard the work actually requires.

That is what EurthTech offers. That is what the first ninety days are for.

If you want to have a conversation about whether this is the right place for you at this point in your career, reach us through the Careers page on our website. I read those applications personally.

— Srihari Maddula, Founder & Technical Lead, EurthTech

About the Author

Srihari Maddula is the Founder and Technical Lead of Eurth Techtronics Pvt Ltd, an electronics product design and IoT engineering company based in Hyderabad, India. EurthTech has delivered many embedded systems products across industrial, agricultural, medical, and stretigc applications. This blog series shares frameworks and principles from real product development practice.

Eurth Techtronics Pvt Ltd  •  www.eurthtech.com  •  Hyderabad, India  •  Careers: www.eurthtech.com/jobs