Saying I'm selling myself short on one point is kind of unfair, so let me give you the rest of the job:
RF knowledge at a product to market level. Implies knowledge of PCB for RF design, codes, standards, and practices for consumer devices. Probably means you're required to know BT and WiFi stacks, as well as all of the standards that dictate that.
FPGA/VHDL/Verilog/C# at a single point of contact / knowledge base level, with product to market experience. This person is the senior engineer and is over others working with the same devices.
Military contract product to market knowledge. This is a military contractor, and as the person is the lead, implies knowledge of all of the standards that entails, and that's a nightmare in itself. You need a person just for this point.
Test engineering, Product development, Project management, every aspect of electrical design knowledge from Cables to Packaging.
Will "Wear Many Hats"
PMP needed.
Clearance required.
edit: There's some software packages listed, I'm familiar with it and rejected it at a previous employer as "overly complex, too expensive, and doesn't do it better than what we have now." Did I mention this person is the top guy and is a manager over other engineers? They want someone that's coming in and hitting the ground running.
This is literally the top person. And I bet you they don't pay shit for Boston. There's no fucking way I'm qualified for this - My engineering manager who is the top dude at my current place would probably look at this and go "Wow..."
Seems fairly straightforward. If you're a veteran and worked on anything even remotely like product-to-market (where coding and industry standards are required), are not lazy, and had decent references, I'd hire you to do the job.
You wouldn't be doing this in a vacuum. You'd gather use cases and explicit requirements which you could build to instead of having to asspull this. There may be ruggedness requirements which you could easily build to with pilot groups (AFTER accounting for stupid shit in lab tests...if this is a product that will be used by grunts, they will figure out ingenious ways to break shit).
It is stressful, though, to do this work. But some people enjoy it/love the challenge. That's how it was at the last place I worked before the current place I am at.
If you, in particular, do not feel comfortable doing this stuff, even if you have the capability, you should not be thrown into it and you're making the right call. You have to be hungry.
Have you heard of those "black box" teams? They are thrown a problem and they have to make a device that solves a problem or hits a specific set of requirements? That's what this feels like. These feels more like an area for an experienced coder/engineer than your every day normal coder. Very similar to the last job I had: we burned people out and the people who stuck around had a specific type of personality that loved that work.
"Black Box" team actually sounds about like what this is. I get the impression from talking to the recruiter that the company doesn't have a "product" so to speak, they're the skunk works, refiner, and manufacturer for "product," whatever that may be. The term bio-med was tossed around in the description as well, so take that for what it's worth.
I'd love to be part of a team like that, but I'm not the kind of person that can or wants to manage it. My current job has taken me a good two years to go from "I know what this device is" to being able to sit down with you, talk about the test plan that the original contractor developed, what they were trying to accomplish with it, and why that didn't work and exactly what makes it the stupidest thing I've ever read. I feel like I now know more than the OEM, which can't seem to make it work.
I got into a project to be the lead guy on an ERP module I had only read about and learned OJT cuz they couldn't find anybody who had even read up on it. By the end I was writing documentation other people were reading to learn the module. Did it take a lot of reading, yeah. But was it worth it, yes.
(post is archived)