Not so well. Some teams have a high threshold for hiring, some don't, but overall it's been going down because it becomes more and more difficult to find new employees.
Private companies and banks see coops as the devil [for very obvious reasons] and fight them using regulatory capture and not engaging in business with them. It's pretty well-known in the coop world.
Coops sometimes mitigate this disadvantages by networking with each other.
Coops and startups are in different categories. It doesn't make sense to lump them in to the same group here, though I understand we are on a very techie-oriented forum.
It uses an internal tool but the implementation is not important. Applications and libraries and packaged independently just like any Linux distribution.
I've been in companies that owned their datacenters and it was much, much cheaper than using any cloud service.
Poorly managed datacenters exist but that's an organization problem. Remove the datacenter and you'll have poorly managed cloud instances and services costing millions.
Isn't XMPP the base of all major chat services?
I used my own client (Psi+) for a while with Facebook chat but since I no longer use Facebook I don't know if that still works. Too bad none of them support federation any longer.
Google Talk/Hangouts still uses XMPP and I use that right now.
At least 8 banks in my city use XMPP for internal chats since 2005 at least. Cisco has an xmpp product. Oracle uses xmpp for internal chat communications (i know it because their employees contacted us many times, and we slightly modified our xmpp client so that could connect to it without problems). Fortnite, eve online based their chats on xmpp, WhatsApp runs on a modified XMPP. Quite enough serious organisations, no?
> who ... understand the OS internals? ... How about write a library for their fav language? How about actually troubleshoot a misbehaving *nix process?
Ex-Amazon here. You are describing standard skills required to pass an interview for a SDE 2 in the teams I've been in at Amazon.
Some candidates know all the popular tools and frameworks of the month but do not understand what an OS does, or how a CPU works or networking and do not get hired because they would struggle to write or debug internal software written from scratch.
[added later] This was many years ago when the bar raiser thing was in full swing and in teams working on critical infrastructure.
LoL. Also Ex-Amazon here. I can tell you for a fact that most SDE2s I've worked with had zero clue on how the OS works. What you're describing may have been true 5-10 years ago, but I think is no longer true nowadays (what was that? raising the bar they called it). A typical SDE2 interview will not have questions around OS internals in it. Before jumping on your high horse again: I've done around 400 interviews during my tenure there and I don't recall ever failing anyone due to this.
This term is really getting over-used. The purpose of job interviews is to decide who gets to pass through the gate. It is literally keeping of a gate.
The term is perfectly apt and descriptive here, because gate keeping isn't about the keeping of a gate, it's about the inappropriateness of the criteria that is used.
Software engineers, even the ones that are so superpowered that they :gasp: got a job at Amazon once in their life, can go an entire successful career without knowing how to use a kernel debugger, or understand iptables or ifconfig, or understand how virtual memory works.
Some engineers might need to know some of those things, but it is absolutely bonkers to claim that you could never progress past level 2 at Amazon without knowing such things. I know this because I once taught a senior principal engineer at Amazon how to use traceroute.
For many roles in Amazon (particularly the tens of thousands of SDE positions that will end up working with the JVM all day long), asking such low level questions about how OSes work is about as useful of a gatekeeping device as asking them whether white cheese tastes better than yellow cheese. And that's why the term gatekeeping is used.
Yikes. Do you think Amazon engineers are overall just dumber or just less used to the lower abstractions? After all, I can’t even ssh into the machines my code runs on nowadays.
Yes they do. There is too much software to be written. A person with adequate knowledge of higher abstractions can produce just fine code.
Yes, if there is a nasty issue that needs to be debugged, understanding the lower layers is super helpful, but even without that knowledge you can figure out what's going on if you have general problem-solving abilities. I certainly have figured out a ton of issues in the internals of tools that I don't know much about.
Current big tech here (not Amazon) and very few know lower level things like C, systems or OS stuff. Skillsets and specializations are different. Your comment is incredibly false. Even on mobile if someone is for instance a JS engineer they probably don't know Objective-C, Swift, Kotlin or Java any native APIs. And for the guys who do use native mobile, they can't write Javascript to save their lives and are intimidated by it.
I agree with you, as opposed to the other ex-amazon comments you've had (I had someone reach out to interview me this week if that counts? ;)).
Playing devils advocate I guess it depends on what sort of software you're writing. If you're a JS dev then I can see why they might not care about pointers in C. I know for sure as a Haskell/C++ dev I run like the plague from JS errors.
However, I do think that people should have a basic understanding of the entire stack from the OS up. How can you be trusted to choose the right tools for a job if your only aware of a hammer? How can you debug an issue when you only understand how a spanner works?
I think there's a case for engineering accreditation as we become even more dependent on software which isn't a CS degree.
Not so well. Some teams have a high threshold for hiring, some don't, but overall it's been going down because it becomes more and more difficult to find new employees.