It doesn't fit my definition of "clean" at all, but that's a subjective word anyway. I do have some feedback (unrelated to being clean):
- The search field is arguably the most important element on the site. It might benefit from a magnifying glass icon and/or some visual distinctions that make it actually look like a text input for searching. It's thick border and shadow make it look like all the other boxes on the page that have thick borders and shadows!
- Speaking of the search field, it would be really nice if it supported fuzzy search. For example, I searched for "greater than" and got no results. I had to search for "greater-than" (with a dash) to find the math symbols (like ≥).
- The small font size of the symbols makes them really hard to see for old people like me who are pretending not to be old.
- Ditch the analytics and cookie consent nonsense. These are anti-developer!
+1 The small font size combined with the big black box with green arrow that, at least on my iphone xs, covers part of the symbol itself, makes it really hard to see the symbols themselves on front page.
This post is woefully one-sided. There's no mention of the negative aspects of system design interviews, or the shortcomings of those conducting them, so I'll provide the missing balance:
### Not enough use of AI
I once had an interviewer tell me I wouldn't be advancing to the next round because I didn't use enough AI. My approach was to consult AI about every 10 minutes during a 45-minute interview. To this day I wonder just how many more prompts would have been "right" and how many would have been too many. Either way, it was ridiculous.
### Zero research about the candidate prior to the interview
Interviewers almost invariably ask questions that are literally answered on my resume—so they clearly haven't read it. I also like to keep a few subtle differences between my resume and my LinkedIn page to see if the interviewer is astute enough to discover something about me. They never do—they can't be bothered to spend 60 seconds perusing my LinkedIn page.
### Not starting with the customer
System design interviews often start with little more than API requirements and a drawing app. There's no mention of any customer. It's a fake scenario, lacking any real depth, usually conducted in a way that stigmatizes candidate mistakes.
### Hypocritical expectations on spend
Many companies spend 10x more on AWS than they should, and simultaneously have no appetite for refactoring or technical debt. Your company is probably no different, so please spare me the lecture about making money.
### Inflexibly following the corporate interview prompt
System design interviewers often have a reference diagram of the completed problem, and a set of answers to common questions. If your diagram doesn't match theirs enough, or you don't ask some arbitrary percentage of their questions, you don't advance. Ironically, if you ask a question not in their list, they don't know how to answer but you don't get any bonus points for stumping them.
Why not? People can't fake their way through a deeply technical, probing, 2-hour conversation.
You'd be amazed just how much you can learn about someone's actual skills and experience (or lack thereof) through long-form discussion. I think we don't truly talk enough in our currently broken interview process.
Funny enough, I got into my one only and hopefully last BigTech company without a single coding interview even though my job description required me to know how to code. It was all behavioral. It was for a cloud application architect position at AWS ProServe (yes direct hire with the standard 4 year structure between base + bonus + RSUs).
My current job was also behavioral where I am a staff architect at a 3rd party company and it does require coding. As an interviewer, I also only do behavioral interviews. But let’s be realistic, it doesn’t take much to be a competent enterprise dev or even an enterprise architect.
The type of hard problems that BigTech has to solve is completely different. While I would never have trusted any developer I ever met at AWS within 100 feet of a customer, they also shouldn’t let me within 100 feet of the code that runs any of the AWS services.
Even at my medium size consulting company we have a 0.4% application/offer rate. Can you imagine what it is at BigTech? How do you filter just by talking to someone?
It’s about 10% acceptance rate once you get the interview. I don’t know what stage of interview - HR, technical or behavioral/architecture interview. I’m in the interview pool for the last level.
Now imagine there are 1000 people who are capable of submitting an application that appears to match the job description. Do you have a way to help either winnow out the 750 worst or (better) identify the 50 best of the lot to start to engage in these 2-hour deeply technical discussions?
I have worked exclusively on web apps for my entire career (~17 years), but something is pulling me toward C development. I have no idea how to really get started though. I'm doing a little hobby project, but I'm not sure where to channel my study/effort to become good enough for a career change. I picked up the second edition of The C Programming Language by Kernighan/Ritchie, but I assume it's outdated by now. Any advice?
I'm not sure I'm the best person for advice on this matter, or maybe it is great advice for some. I took a leap, believed in myself, and it worked out okay.
I'm self taught when it comes to computers and software development. For years before I landed a paying development job I did a lot of hobby projects. When I decided to take the leap and landed my first development job I took a fairly steep cut in pay. I was single, could afford the cut and was doing something I really wanted to do. It got the experience I needed and after the first year and changing jobs, my pay substantially increased.
I realize not everyone can take the approach I took. It may not even work these days. I did this 38 years ago when the industry was a bit more accepting of developers without a college degree.
Addendum: I also networked. I went to the equivalent of meet ups of the day. Talked with other developers, showed them my work, etc. This is how I found my first job.
Got my start with C via Linux kernel hacking in the 90s. It's practical so that's where I would recommend. (or a BSD kernel which are often better organized).
With ~17 years of experience already, start with the study of the structure of C programs. Recreate some of it manually, build it, and research the things that do not behave as expected.
Bonus of using an open source kernel is they have a lot of eyeballs on them. They will be pretty dialed in versus studying random Github projects that happen to be written in C.
Would recommend avoiding cognitive overload, wait until you get into comfortable flow writing, building, fixing as needed, simple programs before you dive into lower level debugging, trying to grasp assembly structures that a compiler spits out.
Honestly, they shouldn't even need to touch a debugger if they're able to reasonably manage their memory "well enough". Like in general. I'd only touch a debugger myself if I knew I was dealing with a memory problem.
Overall I agree. But in the early learning stages, getting used to interacting with and interpreting the debugger is useful. So when it is essential to resolving an issue, they don't get off in the weeds figuring it all out.
Start by writing a few basic hello world style programs while focusing on the "C way of doing things" - most importantly how you manage memory in C. That's probably the biggest pitfall I see people coming from higher level programming trip up on. Study how objects work, different forms of math, etc. And that's all console code btw - don't move onto GUIs until your console knowledge is solid. GUIs are a whole different beast in C/C++ (and are a big reason why frameworks like Electron were built).
LLMs can also help you break into C development by a large degree. But they still get overwhelmed on a sufficiently large C codebase just like any other language. Your mileage may vary there.
If you want a book that digs deeper, try Modern C by Jens Gustedt. It’s update for C23 this year, and it’s CC (free).
If you want to make something like TigerBeetle or Redis, that’s sort of just specialised back-end development.
You can also do embedded in C. And you can make operating systems.
What people often do when they want a career change is: they work on New Thing in their spare time; they find this little niche at work where New Thing could fit; they find that there’s a limit to how much workplace will let them prioritise New Thing; they start applying for jobs where New Thing is a focus point, with a non-empty resume.
> As Mozilla moves forward, we will focus on becoming the trusted software company.
Does this sentence feel incomplete to anyone else? Is it supposed to say "the most trusted software company" or is it supposed to be an emphasis (i.e. the trusted software company)?
I can't believe people voted me down for this! It's a direct quote from the movie, after Vizzini uses the word "inconceivable" you warthog-faced buffoons:
- The search field is arguably the most important element on the site. It might benefit from a magnifying glass icon and/or some visual distinctions that make it actually look like a text input for searching. It's thick border and shadow make it look like all the other boxes on the page that have thick borders and shadows!
- Speaking of the search field, it would be really nice if it supported fuzzy search. For example, I searched for "greater than" and got no results. I had to search for "greater-than" (with a dash) to find the math symbols (like ≥).
- The small font size of the symbols makes them really hard to see for old people like me who are pretending not to be old.
- Ditch the analytics and cookie consent nonsense. These are anti-developer!