I would. It shouldn't take more than a couple of weeks to start being effective and 2 months to be productive.
Never used C# and got thrown on a project that required coding in C#. It was similar enough to Java (but still different enough that I had to do a lot of reading, copying, and pasting in the beginning). Created a secure print service firmware. Took me a couple of weeks. That was in addition to other projects. Similar story for the Apple Watch when it came out: NFC to open badge readers. A new tech that no one developed, ever. We wanted to be "latest and greatest." And we did it. Took 2 months. Had a working prototype (that was shitty) in 2 weeks. I don't do any of this shit anymore but this was par for the course: new shit all the time that none of us had ever done before. You just do it. It's the willingness to do the work, research, and dig in that hiring management should look for.
Nothing crazy or extreme about learning IEEE content. Make a list. Document current state. Document target state. Document gaps. And formalize efforts around those gaps to hit the requirements/target state. Stand up a test group/test process. Have acceptance testing in place after passing. Have a clear set of UI/UX requirements from right out the gate. If it helps, create a persona and walk the persona through the features to ensure the persona needs are met with the product. To make things easier, define with your sponsor/client what a minimum viable product looks like and work towards that (goes a long way to have an MVP - makes your clients very happy).
Basically, if you've done any work even remotely in the same area, you're qualified if you have a willingness to get work done. That can come out in your interview and references.
Edit - I've talked with you about some stuff on this site. You have a good brain. You're selling yourself short.
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.
(post is archived)