AI / ML Engineer

auric-ai

Bengaluru NM Years Exp Posted 1h ago

The signals are designed to defeat you: A modern LPI radar deliberately spreads its energy below the noise floor. A frequency-agile emitter changes frequency every pulse. Your job is to find structure that has been deliberately hidden.
You will not have real training data: Zero, for the signals that matter most. Before you can train a model, you have to answer a harder question: what does it mean for a model trained entirely in simulation to be trustworthy in the real world? You will design the synthetic data pipeline, the channel models, the validation methodology, and the test for knowing when your simulator is wrong.
Every emitter is unique: Two radars of the same model number have hardware differences (oscillator drift, amplifier non-linearities, timing jitter) that fingerprint them individually. The problem is not “which class of radar,” it is “have I seen this specific transmitter before, even in a different mode, even years ago.” Open-set, fine-grained, unlabelled.
The DSP world will tell you it cannot be done: Some of their reasons are right. You will need to engage with them honestly, then figure out which ones are wrong and why.

Not a list of traits, those describe nothing. Specific, observable things we will recognise when we see them:

AI-native instinct: Your first instinct on a new problem is not “what filter, transform, or heuristic applies here” but “what should a learned function take in, what should it output, and what is the right inductive bias.” You think in terms of data, loss, and architecture the way a DSP engineer thinks in filter coefficients. You see hand-engineered features as priors to be questioned, not assumed.

You reason about whether a model fits its data: Not just whether it trains. You can look at a problem and argue, before writing code, why a particular architecture is or is not suited to the structure of the data it will see. You know that complex-valued signals, long-range temporal dependencies, and small distribution shifts each break specific assumptions, and you can name which.

You design experiments that can fail: Most ML work tunes until the loss goes down. Yours starts with the question: what result would prove I am wrong. You build the falsifying test before you build the model. With synthetic data and no real ground truth, this discipline is the entire difference between research that works and research that only seems to.

You read papers to find what the authors did not say: You reproduce a paper and notice the seed dependence the authors quietly omitted, the dataset preprocessing buried in the appendix, the hyperparameter that does most of the work. This habit is rare and it is what separates engineers who absorb a field from engineers who collect summaries of it.

The best work on your CV is work nobody assigned: A paper you reproduced because the result seemed too clean. A side project that became four months. An idea you kept thinking about after the class or job that introduced it had ended. The single hardest thing to fake.

You can turn a vague objective into a defensible ML problem: “Detect this radar” is not a specification. You can take an objective in plain English, decide what the inputs are, what the outputs should be, what the right loss is, and what evaluation would actually mean the system works in the field. This translation is most of the job.