Hacker News Reader

Comment by ampdepolymerase | Hacker News Reader

This is a classic supply and demand problem. EE and FPGA jobs don't pay well. You can see the same thing happen in entry-level ML. Applicants want to design models, not spend their days cleaning data. If you pay well enough you will get good candidates who will be willing to put up with mindnumbing jobs. The Zip CPU author sounds like those software "artisans" who regularly get posted on HN. There is plenty of room for pontificating and navel gazing after you receive a nice FAANG-level pay check.

Maybe he should ask his client how much they are offering first before complaining about the South Asian labour supply. Post the total compensation offered at the start of the blog post. I am sure there are plenty of talent from IIT who will be more than qualified if his client is willing to pay well. Ask his clients to price match the hire's salary with his own Gisselquist Technology per-hour consulting fees.

View on HN

I think the disconnect was not about compensation, but expectations. If you are working for a small business, you have to wear many hats. There are not enough X jobs to fill all your time, so you do X 60% of the time and Y, Z, and Q the other 40%. In a BigCo, there is enough work to go around that 200 people can work full-time just on X. If you get hired for X, you don't have to do anything but X.

The client, if they had to ask an outside consultant to vet a candidate for them, must be a small business. They do not have enough work 5 full-time employees, one of whom works on design. The designer is the verification engineer and the project manager and the customer support person. I don't mean the person works 100 hour weeks. They will work the normal 40, but there won't be enough design work to do 40 hours of it per week.

If the candidate wanted to do one thing and one thing only, they won't find it in any small business. They should focus on applying to large companies. And the client should find someone who is fine with being a "full-stack" hardware engineer, instead of a hyper-focused professional.

All these problems will solve themselves if the companies raise their compensation. You see this in the ML industry all the time. Many non-tech companies and even small to medium sized tech companies expect their data scientists to be fullstack engineers. And yet refuse to offer a similar level of compensation. Then they wonder why all the top talent flock to unicorn and FAANG type corporations.

While remuneration is an important part of job satisfaction, it's not the only factor. If hire someone who hates travelling for a job that requires 90% travel time and give them a generous salary, they accept it, but will be completely miserable in it. They won't quit because of the golden handcuffs, but is that a "solved problem"?

Big banks do this to the juniors: pay them tons of money and work them to death. They have no problem finding talent. But I prefer companies find ways to make their employees lives not miserable instead of saying "here's some money for your misery, you may want to spend some of it on a good psychologist".

I am saying this as someone who has seen what working in oilsands does to people. Some people enjoy it, but some only stay for the money. They are extremely well-paid, extremely miserable, and never quit.

I do agree no one should be whining about being unable to find sufficiently-skilled people to hire when the only real problem is they don't offer enough to get them. But I'm not sure it's fair to hold all businesses to the pay standard of massive tech giants who can monopolize one new product niche after another by leveraging their current dominant positions along with the patent/legal systems. Not to mention their exuberance-driven stock to throw around. Such a business model simply can't be available to all.

However I suspect we aren't talking about FAANG/unicorn-capable top talent here, hence the candidate applied to this job in the first place. I'd also be suspicious the candidate is ducking questions because they can't answer them. Unless it's just interview practice for them and a waste of time for the company anyway.

> EE and FPGA jobs don't pay well.

The problem is that EE/FPGA jobs have to compete with FAANGs.

However, hardware, by and large, isn't VC funded. Hardware also has a fairly objective criterion for success.

So, you're not going to get offered $200K unless you actually know what you're doing and bring direct business value. And, if you don't know what you're doing, that's going to be apparent real quick.

As for the ZipCPU author:

1) I don't have to make interviewees go through projects. A simple state machine is enough to separate the wheat from the chaff in Verilog. Practically every online tutorial gets non-blocking and blocking assignment wrong--so interviewees who get that right have demonstrated that they have been bitten by real experience.

2) Quoting Bible verses is a GIGANTIC red flag for me, personally. All the businesses I have dealt with that have done this have been owned by absolutely terrible people with only a single exception to the contrary.

> The problem is that EE/FPGA jobs have to compete with FAANGs.

Too bad. That is the free market. The market is not obligated to provide companies with labour, just like companies are not obligated to provide people with jobs.

No argument.

But the flip side is that I'm also not required to hire someone either.

However, programmers don't get to complain that the FAANGs are gatekeeping/discriminating/etc. when the programmers decided that FAANG jobs are the only ones paying salaries they're willing to work for.

I'm curious about FPGAs but don't have any background in stuff like that. How many weeks would it take to build something useful?

It can take as little as a couple of days--most of the tools even let you draw simple logic schematics. But this is useful only if you have something that fits the use cases for FPGAs.

The problem with FPGAs is that they're only really useful in very narrow niche applications--generally with hard real-time constraints. So ... motor controllers, high-speed ADC/DAC interfacing (think software defined radio), weird processing algorithms that don't work well on a DSP, safety interlocks, etc.

Most people are far better off learning a microcontroller family in depth (think: STMF32 series, for example). You can really bend the functional units of a microcontroller a long way from their intended usages in order to abuse them to do what you need under most circumstances.

I don't reach for FPGAs much anymore as an embedded engineer. Normally I trawl through the various microcontrollers to see if I can make something do what I need. If those don't work, the next layer is to look at SoCs like the AM3359 from the BeagleBone Series which have stronger processors to run Linux (Linux provides larger storage, CPU, and lots more communication options) but have hard real-time units (the PRUs).

Finally, if even those don't work, then I'll start thinking about a cheap FPGA in concert with an external microcontroller.

One unusual thing is that I'm an absolute bigot about not putting microcontrollers inside my FPGA (neither soft nor hard cores). Even the worst microcontroller toolchain is better than the best FPGA toolchain so I am adamant about external microcontrollers.

Reply on news.ycombinator.com