Ask HN: How I get a job that uses C?
My wife is pregnant and I need a job urgently... and like when I needed a job urgently in the past to pay student loans, I feel inclined to accept whatever offer I get.
But what I really wanted was work with C. But even searching for that is hard (often a company writes C/C++ and they mean only C++ and not C at all).
I tried in the past seeing if embedded would work but even entry positions require experience.
So no idea where to look for such jobs.
The vacancies list I found right now is just a long list of full stack, frontend, backend, sometimes java, the occasional SQL, nosql, and sometimes python or ruby. Not a single C job.
Where the C users are hiding? Is living programming in C even possible or it became a purely hobby language for people doing angular.js on their day jobs?
125 comments
[ 0.24 ms ] story [ 193 ms ] threadC is still widely used. I think if you really want to just work with C you should focus on embedded stuff, surely not every job in embedded requires experience.
One industry which is quite C heavy is aerospace. You do not need to work for Boeing/Airbus though, there are many, many suppliers who are doing embedded work.
We are mostly using C++. C skills do come in handy for the existing body of software in systems such as Linux, but we very rarely write new code in C.
I would absolutely hate working in embedded (if it runs linux it's not the kind of embedded I'm talking about) for a salary. Nobody treats C with any care or respect in those areas. Either that or the language is written like a legal document. If you like C because you've played around with it, understand the abstract machine and can write it safely working with a modern standard, don't expect embedded development to be ANYTHING like that.
Anybody who is interested in learning/using C/C++ SHOULD absolutely look into Embedded Programming. That is where the "rubber meets the road" and gives you the intellectual satisfaction of learning/understanding "everything" (i.e. HW & SW). Embedded Development encompasses a broad spectrum from Application programming (eg. Apps in a Network WiFi Router), Kernel/Device Driver programming (eg. RTOS/Linux in the same Network WiFi Router) to bare-metal programming (eg. 8-bit etc. MCUs). So one really gets to know how to use C/C++ (the Good, the Bad and the Ugly) as the situation demands to solve a problem. All the standards are merely guides to follow (i.e. not commandments from above) which is only deviated from when needed.
- Apple
- Microsoft
- Google (linux kernel)
- Amazon (they have some embedded teams)
- Facebook (some Android teams)
- Tesla
- Uber
I think most of those companies require relevant experience before they'll look at someone's resume, though..
What do you mean by lifetimes?
C++ codebases can anything from literal "C with some classes" to C++20-style practically-functional
I'd have been inclined to say embedded would be essentially your only option, but without some experience and/or an EE background, you'll have a very hard time finding your feet in that world.
Yep. We hire embedded people to write C (some of the time) but the critical qualification isn't C experience or even general programming skill. It's knowing what a multimeter, oscilloscope, and logic/protocol analyzer are and not being afraid to use them.
As far as the skill-gap, its a lot easier to train an EE signals dude to use C programming, than to teach a C programmer how to use an oscilloscope or otherwise do circuit theory.
In my experience, embedded work really isn't about C programming at all, and is more about understanding the device drivers / manuals. You _happen_ to be programming in C, but the real skillset is reading CPU-manuals or device manuals.
Its not "void foobar(int blah){}" that's hard to write. Its knowing how many cycles IO-pin B needs to be held low for.
Just a hobbyist here with ATMega328pb stuff and various 8052 stuff + some college-level student training. Not really a professional at this. But I figure the pros do similar kinds of work. And its really not the CPU-manuals that are hard (CPU manuals are often written clearly and relatively concisely). Its the various I2C boards and SPI boards that don't always function correctly that's the issue... and struggling through some incomplete / poorly written docs on that matter. (But you got like 10 spare parts you can experiment / blow up with. So its just a matter of playing with the darn thing until it works...)
-------
Asking for a C programmer would be like asking for a journalist who has "English Writing experience". Like... yeah, that's... expected. But that's not what you ask for. The skills they need are far beyond "just" C programming.
Not always haha. I've seen manuals for some very widely used ARM SoCs that are just a few hundred pages of registers with poorly translated, one sentence descriptions.
The manuals for CPUs that are frequently used by hobbyists are written clearly and concisely (decoding the causality to be left as an exercise for the reader). For many of the others (including a quorum of those priced for use at scale), you'd be lucky to get a document that's been machine-translated from x-ese, with an errata roughly the same size.
A lot of embedded C code looks like (to take some from an esoteric project I can share)
This is not interesting, nor is it intelligent, nor is it (arguably) safe. It is, however, fast and functional and directly talks to the hardware. The difficulty in doing this isn't understanding what is going on in the code. It's in working out what the <bleep> is actually happening if you see the right blips on a logic analyser and nothing comes out the other end -- and that often touches on physics as well as EE and computing. I personally really like it, but it's much, much more frustrating as far as experiences go (at least compared to Stack Exchange and "apt install $magic_package_version" to solve your immediate problem)...Every scope made in the last 20 years has an autoconfig/autoset button...
You're not teaching electrical theory in 10 minutes. No sir, no way. I'm going to guess that it takes you more than 10 minutes to adequately explain what a ground loop is, even if the other guy is reasonably trained in electrical theory.
EDIT: Recognizing a ground-loop, understanding where it comes from (Oh, X device isn't grounded and my Y device ground is the Oscilloscope's ground right now), and finally solving it (switching to AC mode if you're cool with capacitive coupling).
And it can be rather dangerous / fire hazard / electrical hazard if you made a stupid choice (ex: connect X's ground to Y's ground. Are you sure there's no serious voltage difference here? After all, if there wasn't a voltage difference, you probably wouldn't be having a ground loop problem to begin with)
This book from a parent post looks pretty good: Understanding Signals with the PropScope from the company Parallax [2] and it looks like there’s a bundled kit on Amazon.
[0] https://artofelectronics.net/
[1] https://www.cambridge.org/us/academic/subjects/physics/elect...
[2] https://www.jameco.com/Jameco/Products/ProdDS/2134871UsersMa...
https://www.onsemi.com/pdf/datasheet/p2n2222a-d.pdf
https://www.mouser.com/datasheet/2/308/1/2N3904_D-1801586.pd...
They're both NPN type BJT transistors. There's a bit of knowledge you need to see the difference.
Anyway, when you're at the level where you're analyzing components like that and picking between them, that's when you're ready to read TAoE. I'd caution against jumping into it too early, there's just so much to learn before that textbook is relevant to you.
---------
I don't... really remember my 200-level classes. But there was at least one semester of rather boring, beginner level electronics. Just using OScopes, power-supplies, and shoving electricity into resistors, capacitors, inductors, diodes (etc. etc) and learning how to read / measure that stuff.
I think an older beginner book that teaches like, 555-timers and other simple circuits are what you need. As well as just a lot of lab time with an OScope + breadboard, debugging and groking, and understanding these already made designs.
Once you get a gist of how the common components work, then you are able to choose various components and make them work together yourself.
As a software engineer who's been learning electronics in the last two years and now does know how to use an oscilloscope: Try it, it's not hard at all to get started, and very much fun.
But sitting at home with an existing job, it's a lot easier to learn C than pick up an oscilloscope and some hardware to run it on. I can't exactly tear apart my home appliances as easily as I can write throwaway programs on a computer.
- Lots of used hardware on eBay/craigslist, if you're looking to acquire skills by dismantling or repairing stuff
- Good free tools (i.e. KiCAD)
- Affordable services to order PCBs from
- Lots of businesses selling parts to hobbyists
- Test gear such as scopes and DMMs are now much more affordable, with many low-budget options that are good enough - $1000-$1500 gets you a reasonably complete home lab
- Lots of 3D printing options for encasing what you make
- Large, vibrant communities full of other hobbyists to get help from (or buy used stuff from, if $1000 is above your means)
It's quite satisfying and achievable to build physical things on the side, or build complete systems with your hardware/device components involved.
Another reason it makes for a great hobby: It feels work-adjacent enough (to a software job) to be worth the time investment (i.e. you are gaining useful insights and knowledge that can inform your work as a SWE), while being different enough to feel like a change of pace.
I imagine the situation is vastly different for those working on a microcontroller, but that isn't the entirety of embedded systems.
You at least need some common vocabulary. "Hey the gpios are floating at startup and messing with the meter. Can we pull them down? Hmm no but perhaps we can reset the meter after startup to a known state." That sort of thing.
These have many large software teams working together. Most software engineers on these embedded programs are just that: software engineers. I've worked in embedded for a long time and have never "physically" debugged or otherwise physically touched the hardware I work on. There's a lot to embedded systems outside of microcontrollers.
The problem for switching from pure software to embedded is that companies like you to have EE experience, even if the job doesn't require it at the moment, so you can use it if you need it. Of all my embedded coworkers, only one was a pure CompSci major. The rest were CompE or EE.
Personally I consider myself more SWE than EE, and half of my job titles have been "Software Engineer" instead of "Firmware Engineer" or "Embedded Engineer".
Some embedded devices have robust OSes between you and the hardware; some don't. (This isn't a sign of bad engineering on the devices that don't, by the way.) The ones that don't, you need to get to know the hardware fairly well.
When i started learning Embedded Systems (lots of C/C++ Programming experience but without an Electronics background) it was understanding the needed Electronics and how to interface/debug the Hardware-Software interface where i had the most difficulty.
I found the following helpful in my education and hopefully people with a Software-only background who want to get into Embedded Systems will also find these useful;
* Designing Embedded Hardware by John Catsoulis - Very good introduction to relevant practical Electronics without drowning you in nitty-gritty details.
* Patterns for Time-Triggered Embedded Systems by Michael Pont (free pdf available at his company SafeTTy website) - Full of C code showing how to interface to hardware and do stuff.
* Practical Electronics for Inventors by Paul Scherz, Simon Monk - Reference for when you need more Electronics knowledge.
* Understanding Signals with the PropScope from the company Parallax (search for free pdfs online) - Practical lab book showing how to use PropScope(a USB based Oscilloscope) to study Signals on circuits built using the Parallax BASIC Stamp MCU board. You can use any other MCU/Oscilloscope combination (eg. Arduino with Analog Discovery 2 aka AD2) to build the same circuits and do the lessons. Digilent also has a lot of lessons on using the AD2 at its website.
* Introduction to Embedded Systems: Using Microcontrollers and the MSP430 by Manuel Jimenez et al. - Excellent and nicely illustrated textbook to learn Embedded Systems from. The MSP430 MCU is used as a case study but everything is presented in a general way.
People make bad decisions in high level languages all the time...
Believe it or not this is still a very large part of the industry.
It would also be helpful to know if you're likely eligible for a security clearance in whatever country(ies) you hope to work.
Trying to get a Portuguese citizenship but mess with Portuguese ancestors renaming without informing the government is making it hard.
I made my living doing C when I worked on Samba + Illumos.
Really, if it isn't systems or embedded, C is very rare, even for someone like me with 20+ years of it, I won't code in C unless it is really the "language of choice" for the problem. And that ain't often.
That said... I do write some C time to time, still.
Personally I find that kind of work very frustrating, and the limitations of C makes it worse.
That's somewhat ironic considering that C is one of the few languages which can do literally anything, from the lowest-level direct memory access to the highest-level abstractions. It's the language many other languages are implemented in, so it can demonstrably do anything they can do.
Obviously C is a much better programming language for human use than x86, but the mere fact that a high-level language can be implemented in a low-level language is not evidence that the low-level language has no limitations. The limitations live in meatspace, between keyboard and chair, but they're very real.
Otherwise you're basically just saying C is Turing-complete. Which, yeah, so are most languages. That's not actually a special property.
And then, if an FFI is required do to X, can you really say it's possible to do an X in your language? C/C++/unsafe Rust or another language that can directly reference memory still ends up being required in that end.
Using only the C language, you cannot make a device driver. Full stop. You must use an FFI / inline assembly to establish critical pieces of it. And if you're allowing that for C, then you necessarily need to allow that for all languages. Thus, C isn't very unique here. C's lack of anything resembling safety makes it "good" at working with things like device drivers, sure. But it's not actually that unique of a property, shared by quite a number of AOT'd languages. C++, Rust, Go, D, Zig, etc... heck, even Haskell ( https://tommd.wordpress.com/2009/09/13/kernel-modules-in-has... all can be used in this role.
C's prevalence in the kernel space is arguably more to do with legacy & inertia than actually being a good fit for it. See for example all the undefined behavior suddenly making kernel devs scream and wail endlessly.
Many APIs, like Vulkan or OpenGL are using pure C.
While yes the Vulkan & OpenGL APIs are pure C, that's very, very little of what you actually code against. You very quickly abstract that or use a middleware like bgfx or whatever. In the case of Vulkan while the spec API is C, there's first-class C++ wrappers/bindings provided as well: https://github.com/KhronosGroup/Vulkan-Hpp
And other than Vulkan & OpenGL, you'll find that most other APIs/libraries in the space are C++, not C. Valve's libraries are C++. Dear ImGui is C++. Bullet & PhysX are C++. Microsoft's glTF SDK is C++. etc...
You can argue endlessly about how "true C++" those all are or if they're just "C with namespaces" but that's largely irrelevant - they aren't C and they need a C++ compiler.
bgfx and imgui are very close to C in practice.
This is not very common practice but a few small to medium size studios are using C only.
TheMachinery was pure C.
My own engine is built in C with C/C++/Zig APIs.
Embedded, firmware, systems jobs all tend to use C. So using those terms to widen your job search may help.
Searching through my email, "Triple Crown" and "EdgeWater" are two recruiters I had good conversations with.
Apply for those jobs anyway. Requirements are often flexible.
For some reason people don't even take the first step of applying for a job they want/like just because it lists "X years of experience needed". This is never ever a hard requirement. Most companies try to over provision or are completely clueless about their needs. So don't doubt your abilities, be clear about where you stand and what you want and finally be willing to negotiate both on Salary and Position to get/do what you want.
When I started out I was looking for the same thing in the embedded space but there wasn’t any jobs strictly using C.
The “best” you could find out there is old code base is in C, new code is in C++. Which there are good reasons for.
About half my work is programming B&R PLCs in C, albeit it's C with a custom IDE and code generation that makes it quite different from a normal embedded environment. (The other half is Python, networking, radio comms, sysadmin, etc etc)
But it's actually somewhat rare to find people programming PLCs in C. The vast majority seem to be using a PLC-specific language, and even B&R is starting to move towards Python.
I can guarantee Garmin uses plenty of C, and continues to make new software libraries in C.
> what I really wanted was work with C.
I'd understand if the second sentence was "Where can I find a job that (pays really well | allows for parental flexibility | has high security | ...)" -- what is it about your wife's pregnancy that triggers selecting a rare job you really wanted?
As I read the OP's sentence, there's such no implication of causality.
This is the sort of extremely sensitive personal situation that requires a gentle touch. Internet comments about this kind of thing, including questions with assumptions baked into them, can easily come across as personal attacks. The burden is on the commenter to avoid that (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...).
But embedded pays 40% less then frontend/backend.
Games pay good, but is stressful and demanding.