You probably shouldn't be learning assembler. First, compilers are really quite good. Yes, it's possible to beat them (I do) but generally not by much. And not by much ain't gonna put bacon on the table. You can probably get what you need from gcc inline asm() calls. Take a look at the linux sources and figure out why and when assembly is used there:
Secondly, writing in assembler is not low level. You just think it is. You should really be understanding caches and you can improve your cache performance in C.
Anyways, unless you deeply know what's going on inside of the microarchitecture of a modern superscalar, out of order, speculative, renaming, μop-cached, hyper-threaded, multicore beast then you shouldn't be fooling yourself by writing in assembler.
Unless you've really read Intel's Intel 64 and IA-32 Architectures Optimization Reference Manual (and ARM's Cortex®-A72 Software Optimization Guide) and meditated on the suras of Agner Fog's Microarchitecture you won't even know what's going on with something as simple as mov RAX, RBX.
Look, most compiler writers don't even know this stuff (Intel C Compiler yes, llvm occasionally) and frankly, it isn't very useful because Intel spends a billion dollars a year to make your bad x86 code run reasonably fast. Consider a switch statement which compiles into an indirect branch, jmp reg. That branch has to be predicted by the BTB before the jmp reg instruction is even fetched and that's really hard to do. Every year they get better and better to the point that you're not even aware of it. But if you want to the help the CPU out, you could put a UD2 right after the jmp reg. This is insanely hard to understand and will help very little.
Don't go there.
It's similar to learning a functional language. I have no idea if I'll ever use Haskell professionally but learning a bit of it has been a good way to see problems and logic differently. I think both assembly and Haskell have made me a better programmer, even if I never become truly proficient in either or use them directly in my job.
Just today, I helped a coworker debugging a segmentation fault that occurred in a library where the debugging info was stripped out by looking at the assembly code.
Being able to debug applications which don't have debuginfo (particularly optimized builds) is highly valuable though.
I'm in an area where there are relatively few opportunities to do close to the metal work. The ones that do, don't pay any more than backend web developers make. In fact I've come to assume that they can offer less due to either the intrigue of the work, or because you often compete with computer/electrical engineers who aren't expecting outsized developer salaries.
Likewise, while I have loved the skills I've learned in embedded and low-level work, working at an embedded shop has taken a lot of the joy out of the learning. You trade off an inherent rewarding development environment with the realities of developing against hardware, where project cycles are long, you're often dependent on horrible vendor APIs and support, and where everything moves much slower.
The counter to that is the type of work I believe you're describing, which sounds like HFT optimization on Intel. I got into embedded because I wanted to eventually end up there, but again, it's an extremely limited market. And as someone who has indeed dabbled in the Fog optimization manuals, you quickly learn to realize how much the ROI of assembly isn't worth it. The future of speed isn't going to be going lower down the programming stack. It's going to be in new hardware: FPGAs and ASICs, writing RTL for system specific CPUs. And that is highly exciting, though it necessitates a pure programmer has to learn hardware at a deep level as you imply.
As for me, I concur with the statements others are making about using my skillset for security research and reverse engineering. Working in embedded development has bored me to tears, and taken the magic out of learning to love the skills themselves. I'd much prefer to work at a pace that isn't limited by the pace of a cross functional team of software and hardware engineers.
Learn the skills, yes, completely. The knowledge is worth it. But for the love of God, don't get expect to get joy out of working in it.
I'm only extra cynical because I'm dealing with that right now. As I have many times before, though. It's part and parcel.
The big issue is timing (and latency) - the chip guys are working on long timelines - they're already working on the next chip when the first chip's silicon comes back, their investment and attention is elsewhere, the software guys aren't going to rev up much before real hardware is in their laps, and certainly aren't going to spend any time on that second chip while they're still wrangling the first one - it's not so much a cultural gap between the groups as a gap in time
Earlier in my career, I had a driver that compiled to about 8500 bytes. I noticed the part was spec'd at 16K and wondered if it could get re-spec'd at 8K if I got it down to 8K. Yep and I got mad props from the HW types.
Here is a sample opening at Waymo -
Sure my experience may be skewed too but there are definitely great jobs with rewarding experiences of shipping tangible products for low level programmers. Not many people get the joy of shipping something your friends and family use and literally say "wow".
1. Writing embedded software. You're not going to get very far if you don't know how to set up your memory, text section, etc.
2. Debugging embedded software. Good luck interpreting your JTAG output if you don't have a good knowledge of assembler. Even if you get to use gdb/Wind River Debugger/etc., you will want to be able to tell what is happening. Symbols only go so far. A backtrace will get messed up and you'll need to look at the stack to figure out what happened. An access violation will occur and you'll need to figure out what line of code it corresponds to.
3. Debugging without source code. Same as #2, even more difficult.
3. Reverse Engineering. You are trying to figure out what is happening in a proprietary driver binary blob (such as NVidia's Linux driver). You are trying to figure out how to get your software to work with an ancient piece of software whose author has long since been out of business. Even if you have the cash for Hex-Rays decompiler or can readily use the Hopper decompiler, this code is simply not high-level enough to interpret without knowing assembly and having a deep understanding of the stack and memory.
4. Vulnerability research / hacking. You are writing an open-sourced client for a proprietary protocol, looking for a memory corruption vulnerability, etc. You can pretty much forget it unless you know assembly.
I know a hell of a lot more about what our code is actually doing up and down the stack than my colleagues, including most of the managers I've had and "Principals" I've worked with and so on. It helps, a whole lot, in fact, and I find that it's personally rewarding, but it doesn't amount to much more than being the person who gets asked the challenging profiling/performance/optimization questions.
Also: to say its a calling is accurate. I love what I do because what I create is physical and interacts with the physical world. I can hold my projects in my hands and say "I made this". I've done web and desktop stuff and can say that this work is significantly more fulfilling to me.
That may sound harsh but it's actually the point of a good compiler design (which LLVM has). You can write an optimizer pass without understanding the C parser. You can write a backend without understanding register allocation. You can get something working without really getting it tuned. You can specify superscalar machine instruction scheduling latencies without really understanding instruction scheduling itself.
I'll add that while full-time native work may be in short supply, it's an awesome skill to have in your belt. You many not need it often but when you're suddenly up against limits where current technology doesn't suffice(Java/Python/Ruby/etc) it can seem like magic to break down into the lower stack and get 10-50x performance boost.
Having that escape hatch available is incredibly valuable and for me distinguishes the engineers I hold in high regard.
Assembly is useful for understanding early initialization code for embedded platforms (startup file). Depending on how aligned the vendor's board support package is with your actual target, you might have to touch this, and since this code runs at a time where there is neither stack nor heap (can't have a stack unless the stack pointer has been set up), this is easier in assembler than in the stackless C variant that you might coerce your compiler to support. The same applies to debugging issues bootloaders, where you'll have to inspect how the reset vector looks.
Genuine question: what would you quantify “not by much” as here? In my experience, it's not uncommon to see 2x+ speedups from well-written software pipelined hand-optimised assembly in hot loops. (Especially so for in-order processors, like you might see in embedded applications or as a LITTLE core in your smartphone.)
Also while software pipelining is possible on something like Haswell ... its limited register set makes it a limited technique. Modular variable expansion is tough with not so many registers but renaming does help somewhat.
I think tools like VTune are awesome for finding hotspots and reading assembler is like reading Latin. But programming in assembler? I think it's best to disassemble and rewrite your C accordingly.
I should have mentioned this in the first post: if you're not a VTune ace, if you're not looking at the Intel PMRs and scratching your head, you probably should not be writing in assembler in 2017. Also, VTune deals with C (and Java) quite nicely (just not on OS X).
Anyways, you may get 2x+ on something but that approach won't work with a GPU. Similarly, Apple doesn't provide microarchitectural information on the a10. Nvidia doesn't on Denver. Even though assembly will still be with us, this low level approach is going away. Apple, Intel, Arm, Nvidia, ... really want you to write in C.
I say all this as a hardcore knuckle dragger.
The more a company spends on infrastructure, the more they need low-level people. A good low-level programmer can reduce cost requirements 10x or more. Any company spending millions or billions on infrastructure can make enormous savings by hiring the right people. Crucial for Google, Amazon, Facebook, and even midsize startups can see a big improvement.
And its difficult to fill those jobs. Which means, there's opportunity there.
I"ll go on and make another bold claim. Focusing on lower level stuff and systems concepts lay an excellent foundation for designing complex systems regardless of the language used. Once you understand how a program is executed from the ground up i.e. right from the program counter to page table lookups to cache hits to cache coherency, all abstractions are easier to deconstruct and understand. I work up and down the stack and this has been my, quite possibly just anecdotal, experience.
When you know what the stack and the heap are, when you know how memory locality affects performance, when you know the full cost of allocations, you can write better Java/C#/OCaml/Haskell, you can check on the assembler they output, you will be ready to occasionally write small C libraries if portions or slow, etc.
Ignoring this stuff completely leads to text editors made in electron.
However I do agree with you, getting into web dev is easy. Doing things closer to metal is harder. I would definitely love to do more low level C programming.
The funny thing is, its the opposite for the low level stuff. Nobody does it, so there's a huge demand, which results in too much work for those who are filling those roles.
Game development is broken for a litany of reasons, but I resist the urge to go into it to keep things on topic. I will say that it gets kids in STEM, and for the youngin's, getting into the low level stuff is a safe bet for a profitable career.
This was not my experience or the experience of people I know at all.
I imagine that it depends on which companies you work with, or what country you're in, but my experience was that low level skills often didn't give you very much in the way of extra job security, and certainly didn't save you from crunch, low pay (much lower than everywhere else in software), etc.
Still, I have to say that there is indeed an opportunity for a few low level people there.
How much does an engineer making $200k a year have to reduce X by before he pays for himself? Not much, and simply finding a hotspot and doubling the performance by aligning a data structure or whatnot could pay for his salary for a decade.
The old adage that computers are cheap and engineers are expensive is about 15 years out of date for a large portion of the software being written today. That is when companies stopped being able to generally externalize the costs of shitty code. Plus, as microcontrollers ate the world, the ability to ship a $1 micro controller instead of a $10 one on a product run of 100k units can mean the difference between a competitive growing company and a dying one.
As a real world example, if an operation involves a network call and you see the RTT dominating the time. You may want to think of ways to avoid the call (caching etc..) if possible to get really good gains.
But I'm an EE, so maybe I misunderstood some finer points?
A fairly obvious conclusion which can be drawn at this
point is that the effort expended on achieving high
parallel processing rates is wasted unless it is
accompanied by achievements in sequential processing
rates of very nearly the same magnitude.
A point made when we read the paper was that Seymour Cray always made sure that his computers were also the fastest scalar computers even though they were sold as vector processors.
I think mathematicians consider an upper limit a positive bound - positive, in the sense of being well defined; you're using negative in the other sense? I actually like that quite a bit.
Everything in this style guide is covered in CS:APP https://matt.sh/howto-c
There's also http://rust-class.org/ and https://www.nostarch.com/Rust
I'm studying (at my own pace) the book, practicing the problems, and watching the lectures--I even downloaded the Panopto iPhone app to watch lectures while on the bus ride into work.
The course is very rewarding: x86, memory systems, systems programming, linking, socket programming ... all packed in a single book, providing a holistic view of systems, from a programmers perspective.
Here's the situation: No Starch, being as awesome as they are, are totally happy with printing an open-source book. The Rust project wanted to do a second edition of the book for various reasons, so Carol and I have been doing that, but also, working with No Starch's editors. So they've been collaborating with us on it. It also means you can get a nicely laid out eBook, the paper copy, all of that.
The proceeds are going to charity.
If you look at everyone reinventing the wheel in electron and not caring about performance I don't think the situation is going to get better anytime soon.
My point is that your job market is not representative of the whole world and you're acting as if it were.
I can't say I've ever lacked for work and I make $125k in a very low cost of living area, and if I wanted something new I could have interviews arranged tomorrow both where I currently live and pretty much any major US city.
It's probably not on the same scale as web dev, but there's also a lot fewer of us working on this side of things.
I wound up in this field doing a co-op during college with an employer that had a variety of different job types. I have always liked C so I went with more low level jobs during my co-op rotations.
My primary skill set is being comfortable developing on bare metal or in the kernel, reverse engineering, and debugging painful problems. One of my first tasks was porting part of a custom OS to hardware that didn't have JTAG (it wasn't our hardware... someone else made it and we were tasked with getting our OS on there.)
The only thing I had to debug with were memory dumps in raw hex. It was painful but a lot of fun. It's not so much that I'm particularly bright but I'm too dumb to know when to give up.
The most obvious example would be the video game industry were you're not straying very far from C++ anytime soon. Performance, speed and native compatibility are a big deal there.
There's definitely a valid career path there.
He replied that he'd have better job security than any of us in IT doing stuff like PHP or Java. He said the reason is he had to be on-site to do his work. Impossible to out-source. When I pointed out in-sourcing (H1-B, etc), he said they preferred people with both strong command of English (avoid costly misunderstandings) and experience (avoid costly mistakes). The experience often comes from working locally in colleges or companies.
So, I definitely encourage people to explore coding in C and C++ for local, embedded systems at the least. There's other jobs that don't require local or embedded where those languages are used. They're not outsourcing-proof w/ consistently good pay, though. ;)
I'm the following is not very scientific, but just to give you an idea of where I'm coming from.
Firstly comparing just the numbers of jobs (even tho this is probably a bad time of year near the holidays):
PHP Jobs, 100k/year minimum:
3 added today, 7 the day before
C++ Jobs, 100k/year min:
0 today, 1 yesterday
And some of those aren't even C++ jobs, switching sorting from date to relevant gets you C++ jobs from 14 days ago that would already have moved along in their hiring process.
As a cherry picked example, dropping down to 80k/year there's this Embedded C role that requires specific experience in card payment software:
To me those requirements seem stricter than what i see in the PHP jobs (experience with MySQL + some form of MVC framework). And on top of that it's paying less.
Another example is the finance job I applied at that was paying 70-90k. But to get in the high end of that range you would need previous stock trading software experience. They also wanted 5 hours of my time for the interview process, but that's a separate topic.
Also, if you're dealing with uCs, you'll almost always want at least a Saleae and a 100+mhz scope.
For my home-lab I went the el cheapo way and bought my own hackable Rigol (brought it to 100 Mhz) and, to my great shame, I bought a Saleae clone. I promise, Sealae guys, I'll buy an original on my next raise, I promise!
I've gone the same direction with my home setup. "hacked" Rigol DS1054Z + power supply and anti static mat. It's not as nice as my Tek at work but it'll do most of what I want. I usually just borrow the saleae from work if I need one and I have a little bus pirate that's occasionally indispensable for SPI/serial/I2c stuff
"[buzzword] systems need lots of training data. To process that data quickly, systems must parallelize and distribute computation. Concurrent queues are a basic building block in parallel and distributed systems. They are used both internally in [buzzword] systems and directly by engineers building ingest pipelines and serving systems. Engineers need to know the trade-offs of different concurrent queue implementations to avoid introducing unnecessary bottlenecks in [buzzword] systems."
You have to wonder what percentage of devs are jumping on these trains out of naivete and what percentage are jumping on out of cynicism, as both are good explanations. The explanation that rarely applies is "this is the best way to solve our problem".
None of us should be so naive to believe that the developer market, or even subsets of the developer market, are a cozy little corner for engineers and tinkerers where rationality wins the day. It's big money (even if you don't pay anything for your tools), and that means that advanced marketing tactics are at work. Hackers are not invincible, though they like to think they are.
Can you elaborate on this? This intrigued me but I didn't follow your arguments after. Can you give a concrete or specific example?
However, VCs do deviously manipulate the wage market in early startups by pumping a false narrative about how it takes young (read: naive, as these are virtual synonyms) people to innovate, and how when the company gets really super duper big, the equity will make up for the crappy salary. This trick is used to get young people to accept an apartment split with 6 other "founders" and some ramen, or in the case of early employees, a salary 40%-60% below market, in exchange for a pull on the VC slot machine.
If you figure a 1 year cliff and then 25 percent a year vesting schedule. You are into the startup for 5 years to be fully vested. How many of those can you do in a career? How many companies continue to be awesome enough to stay for 5 years? How many of those will actually IPO? The odds don't seem that great.
I think the zeitgeist is manipulated by large players like Google and Amazon to promote their cloud offerings. They know everyone is going to follow them wherever they go head first. Thus, they focus on driving the industry toward rented hardware that they can sell at a large markup, and gives them many other ancillary advantages, not the least of which is making large swaths of the internet's infrastructure dependent on themselves, a very powerful position to be in.
There are even articles that freely admit Google released Kubernetes to get more people on its cloud , and they run industry groups like the CNCF ("Cloud Native Computing Foundation") to promote the idea that running your own hardware is the devil, and why don't you just let Google handle it all for you, OK sweetheart? You wouldn't want people to call you a philistine, would you? Google is cutting-edge, and you're just a working slob.
Nevermind that a lot of people are adopting k8s only because cloud servers are so expensive, and they're looking for a way to consolidate that expense. Amazon should be trying to counteract Google here and stress the high labor costs associated with running a k8s cluster and the pre-requisite conversion of apps to work well on one.
Most people don't need something like k8s and, for that matter, most people don't need something like TensorFlow. Google releases these things because they have one big positive net effect: a lot of people paying a lot of money for cloud servers.
There is no reason to run a real database like PgSQL on Kubernetes. None. If you want to do this, you are a victim.
VCs are looking for a similar type of influence, just on a smaller scale, by getting into dev tools. Dev tools are the key to platform dominance; they are, after all, the root from which the software which will keep people on your platform arises.
Microsoft understood this, which is why they were crapping themselves when Java picked up steam in the mid-90s, why they had to supplant NetScape, and why Steve Ballmer had a conniption yelling "DEVELOPERS!" not too long after that . It's why they've continued to pour billions and billions of dollars into .NET and Visual Studio down to this day.
It's also why they're making moves into new platforms like TypeScript and hiring away major k8s contributors: they hired k8s co-founder Brendan Burns  and their acquisition of Deis was announced just this week . They want to retain as much platform influence/control as possible.
Once you have the developer, and by extension the user, on your platform, there are many ways to trap them and make them give you money. Lock-in has always been the holy grail in software because it's the best way to make money. Lock-in is gained by platform control.
We need to watch our butts here and be careful about what we're willing to believe. There are many vultures looking to get a piece; I've seen this amp up ridiculously over the last 10 years, and I don't think we're even at critical mass.
 https://www.wired.com/2015/06/google-kubernetes-says-future-... ; Google's PR has been meddling here, the title used to read "Google open-sourced Kubernetes to boost its cloud", see https://news.ycombinator.com/item?id=9693853 (from 672 days ago)
Let's take a look at Google: they have the browser (Chrome), they have the OS (Android), they have their cloud, they have a popular programming language (Go), they have the internet gateways (Google search + other services), they have the data (Google analytics, data mining in all of their other services), they have the hardware (Android phones, Chromebooks), they will have the car (Android auto + self-driving efforts), they want to have the ISP (Google fiber), they have the communications (several chat efforts), they have the social network (Google+, several other efforts). I'm probably missing several things.
Now Microsoft: they have the browser (Edge, IE), they have the OS (Windows, Windows phone, Xbox), they have their cloud, they have several popular programming languages (C#, F#, Typescript), they have the internet gateways (MSN, Bing, LinkedIn), they have the data (data mining in Windows and all of their other services), they have the hardware (Surface, Xbox), they have the communications (Skype, Yammer). Once again, I'm probably missing several things.
Apple: browser (Safari), OS (iOS, macOS), cloud, languages (Swift, Objective-C), hardware (iPad, Macbook, iPhone, Apple TV), communications (iMessage, FaceTime). They don't have the data and internet gateways because they're the only ones still holding themselves back from large scale data-mining.
They say the web is open because "it opposes private, exclusive, proprietary Web solutions". But the web is built with Microsoft and Google tools on Microsoft and Google clouds and viewed with Microsoft and Google browsers on Microsoft and Google operating systems. Maybe we can swap one cloud with Amazon, or one device with Apple, but that's the current situation.
The ideals of opens-source have been almost circumvented in this age of platforms.
The interopretability is huge.
It's something I dabble in and think I'm getting quite good, but unless I start publishing/presenting, I don't obviously see it leading to paid work.
I have a lot of long-time friends in InfoSec but don't really want to exploit those connections to look for work (yet).
I often have the same mindset you do about exploiting connections, and although it's been a struggle for me to change my habits, using people as educational outlets has been something that I've found to be extremely helpful to me personally and also often enhances my relationship with that individual as well.
Folks who work in the DC Metro area probably make a good bit more than that.
I'm not actually involved in hiring, just recruiting and trying to find good engineer candidates.
Places where you can buy decent stand-alone homes for $50,000 and/or have no state taxes are rather different from Mountain View and Manhatten.
It's funny how people in the pricey places look at a $100,000 salary and not see how it is, all by itself, plenty to support a large family in a home with a big yard. People living that life look back at the city folk and can't imagine how they could ever afford the same thing in a city -- it'd be roughly $2 million (a factor of 40) in San Francisco.
The only hard requirement is you must be a US citizen.
1) Good code sample showing non-trivial piece of code, ideally in C. (craftsmanship)
2) Reasonable github profile, showing ability to contribute to some opensource projects (which means: basic git skills, communication skills, testing) (craftsmanship)
3) Reasonable experience from CV (assuming we're not talking about hiring for junior role) (craftsmanship)
4) Genuine interest and experience in one of crypto or security or networking. (depth)
5) Debugging skills. Systemtap? Valgrind? (depth)
6) Basic understanding of different programming paradigms. Haskell, erlang, scala or prolog count. (breadth)
Occasionally, threads about low-level work on HN - you should link to a job post :)
in a capitalist society, small/rare usually means high-paying! don't make it your career but it pays to know these things when writing your high-level code.
Otherwise, I agree with you. Those that understand low level issues tend to, in my experience, just plain understand computing better... even if they're working in the deeply abstracted high level code.
My personal additional to the list would be "What Every Programmer Should Know About Memory" https://people.freebsd.org/~lstewart/articles/cpumemory.pdf
And, Stan Warford's systems programming class is exceptional:
I believe you can get the video lectures through iTunes U.
For university courses, these are both really good.
I've worked at a high level for so long that I've forgotten how much low level work I take for granted.
EDIT: Thanks for the replies. Alot of good links.
- For concepts as well as execution, from the bottom up (hardware level etc.), I've read that nand2tetris is good. It gets mentioned once in a while here on HN. Check hn.algolia.com for threads about it.
- any good book on assembly language programming. I've looked at Randall Hyde's book earlier, seemed good. There is also another which I think is good, by an American professor called Paul Carter, IIRC.
Googling should find all of those and more.
Like an arduino kit (https://www.arduino.cc/) or ARM mbed (http://mbed.com/).
Either one is fairly low-level (C, or C like), but has plenty of beginner-friendly documentation. And if they progress beyond that, moving down to assembler is supported for both.
It's really quite depressing.
We know the bias against defence contractors, against the south, against the non-urban parts of the USA, and so on. We know we aren't wanted around here.
The jobs can be nice though! My place is looking to hire dozens per year. We do emulators, JIT, hypervisors, stuff like valgrind, debuggers, manual disassembly, and vulnerability research. I've been here 11 years. I've worked with more than 10 different CPU architectures and more than 10 completely different OSes. I don't normally work overtime, and I get paid more if I do. I have extreme flex-time. I never have to worry about outsourcing or H1B people. I'm never expected to take work home or be on call. I get to live in a place with no state income tax, a stand-your-ground law, almost no crime, almost no traffic or commute, and houses that commonly go for $100,000 to $400,000. We're hiring in Florida, Texas, Virginia, Maryland, Georgia, South Carolina, Alabama... totally the dream for SF and NYC people I'm sure!
Email acahalan, at gmail, if this suits you. Be sure to mention this comment.
That said, it's obvious to me who you work for but anyone who'd be offended won't know.
I'd love to move to Melbourne, FL to do vuln research but I'd have to convince my family to make the move first.
I happen to like all that, but I'm not the average Hacker News reader and I know it.
To convince your family about the Melbourne, FL area: you can afford 5 acres, or a house on the beach, or a commute of less than a mile, or a huge McMansion. You can surf all year long. I suspect Texas (Austin and San Antonio) and Virginia are pretty good too.
It was pretty great. Just know that it will be horrendously muggy during the summers. I miss it though.
The next step (for that particular company's work) would be to actually reverse engineer some complex code and write about it on a blog.
If you want to basically guarantee yourself an interview, reverse engineer and find a vulnerability in some software, and write about it. Then apply with that information.
If you're looking for the "easier" way, just apply to DoD in Maryland or Virginia for an ultra-low-paying, but connected job that allows you to learn all this stuff on the job.
Mixing personal projects and work and education...
Some of our people have backgrounds doing driver development and embedded system programming. An excellent background would be compiler development. We have hired people who did assembly back when that was totally normal, getting their first job around 1970. We hire some people straight out of
college; Carnegie Mellon University has the best program for this. We don't actually require a degree, but most people have one, and there are a few people with the PhD. Some people have worked on cars, writing software for stuff like airbag deployment (no bugs allowed!) and infotainment stuff.
We hired a former Atari 800XL game developer who was kind of famous. I had done Linux kernel development, been an embedded RTOS developer, and written the "ps" program that Linux uses. We hired a guy who wrote a TI calculator emulator. We hired a guy who got himself sued for exposing
security holes in a speech at Blackhat or DEF-CON, and almost hired another person who did the same thing. (the one not hired had an awful attitude) We hired a person who wrote code to run hardware that would extract platelets from blood. Some employees have written boot loaders. A few
people have done stuff with neural networks. Some have worked on radar. Some have done GPGPU and FPGA programming. We had an employee who wrote a PC demo scene boot sector (512-byte bootable screensaver) that used one of the bytes 3 ways, as data and as two distinct instructions. We have many people who participate in hacking competitions such as ShmooCon's "Ghost in the Shellcode" CTF and DEF-CON's CTF. We have people who got addicted to hand-optimizing code, vectorizing things and counting things like pipeline stalls. We have a person who worked on the JIT for an open source Nintendo emulator. We have some people with math backgrounds
who take interest in automated proofs that programs will or will not do various things, and who can figure out how to automatically create program inputs to make the programs excercise various parts of the code. We hired
a guy who bought his own parking meter (!!!) and then figured out how to hack into it via the pass/token thing it used. We hired a guy who hacked into a bathroom scale that had WiFi. We hired a person who did Dell's BIOS.
Seems like people have a lot of experience going into that field. Most of my hobby stuff isn't that interesting. I did write a mostly working chip8 emulator lol. Thanks for the info
You might want to see what you can do with an interactive disassembler. Your choices are:
1. IDA Pro freeware version -- this is x86 only and kind of obsolete
2. IDA Pro demo version -- this is wonderful except that you can't save your work and it times out after about an hour
3. Hopper -- this is cheap
4. Binja (binary ninja, from Vector 35) -- mid price
Grab some firmware updates off the web, especially for things you happen to own, or some normal executables. See how well you can understand them with the interactive disassembler. You might need to decompress them; look for magic numbers that indicate compression.
Thank you, though; that is a darned tempting offer.
Maybe that will change down the road but it doesn't look like it right now.
I would recommend anyone with curious mind to read it, even if day to day work does not involve much low-level programming. It will open up a whole new set of ideas / knowledge in problem solving toolbox.