Amazon also refuses to give feedback and then spam mails you to provide them feedback on the interview process. That tells you a lot about how they are as a company.
I spent 3 years as cto cofounder at a startup. After leaving I interviewed at lots of startups but I did not get much interest despite many having what I would consider a tech leadership vacuum. I ended up taking an offer from a FAANG and I am better off for now. This is in NYC and I have a degree and more varied corp experience so results may vary.
If you have a bunch of companies on your resume that no one has heard of then it doesn't help. If you are getting interviews though then there are other factors at play that I think you are dismissing. Are you fluent in in-demand skills? Do you do side projects? Did you do interview prep, especially coding exercises? What would you say are your biggest strengths?
It's a good list and these points are indeed very bad signals. When you break it down most points fall under the category of basic professional courtesy and it's shocking how rare that is. Most people that I interview and give prompt and honest feedback really appreciate it. You do have to deal with the occasional rude response however - it's the cost of being a professional.
"They tell you they like you, you’d be a great fit, your code looks great, but then discontinue because they just noticed you don’t have a piece of paper."
It could be that they somehow didn't notice and then singularly rejected you for that reason. It's also possible that they were willing to overlook it but once they had the chance to evaluate you as a whole they decided that the total package wasn't enough and the degree was the reason given. To me the degree is more about proving that the candidate has true interest in the subject and has been able to commit to it over an extended period of time more than anything else. I am asking them for a big commitment over an extended period of time to join my company after all.
> It's a good list and these points are indeed very bad signals. When you break it down most points fall under the category of basic professional courtesy and it's shocking how rare that is. Most people that I interview and give prompt and honest feedback really appreciate it. You do have to deal with the occasional rude response however - it's the cost of being a professional.
This is very true. Interviewing is critical for basically every company, but the actual interview process sucks for the employee who actually is doing it. A lot of companies, and startups especially, don't have the discipline or foresight to realize this and instill in their employees that professional courtesy is important, even if the actual interviewing process is annoying and that professional courtesy is likely to be "wasted" on somebody you won't hire.
But I do think it is a useful (bad) signal, because a company that doesn't have the foresight to create a decent interview experience probably is dropping the ball in other critical areas and should be avoided.
"Internal reviews identified that the heart of the problem was the fact that the different design groups working on the project had used different Computer Aided Design (CAD) software to create the engineering drawings. The development of the aircraft was a collaboration between 16 sites spread across 4 different countries. German and Spanish designers had used one version of the software (CATIA version 4), while British and French teams had upgraded to version 5."
Really interesting! While I've hardly worked on anything as complex as an A380, I take it as a high priority for all software packages, from dev to test to prod, all be on the exact same version. Python 3.4 on one box and 3.6 on another? Let's not.
Several years ago I worked with a large multinational company where every site had their own IT teams. A lot of mergers, etc. Probably much like BAE. A firm who's major product is info.
Some of those teams were extremely incompetent.
My client had made a video of the CEO speaking to the whole company which turned out wouldn't fit on their internal sharepoint site because there was a 50 meg limit for videos. The CEO was not at all impressed with the quality of a 20 min video at 50 meg so in desperation, they ended up asking us to host it for them.
But then vimeo didn't work for some sites, then wistia for others, in the end we ended up having to set it up on Amazon's cloudfront. So each site had their own firewall rules, own white-lists, bad IT connections, etc.
Throughout this debacle, we got claims of our incompetence by IT personnel at their various sites. Really opened my eyes at how disorganised a large organisation can become, as well as how people can hold positions in large orgs that they have no ability to perform by politicking.
And that's how you end up with loads of different versions of software at different sites in the same company.
EDIT: Actually, I recall incorrectly, we originally used cloudfront, which didn't work, then vimeo was blocked on some sites, but no-one had blocked wistia yet as they were still a fairly new entrant.
Random endorsement: Wistia are great, love their API, love their support, great video hosting company.
I see the same at my company. I think the reason is that the top guys in non-IT industries don't see IT as core competence but as a cost center that ideally gets outsourced to the lowest bidder. Unless there is a very strong CIO different divisions won't talk to each other and no standardization happens. Even if one division does a good job they usually can't sustain that for long because their budgets will get cut. It's a very unhappy situation for everybody and the best people leave after a while.
Not sure politicking is the root reason for Airbus: Catia is just hugely expensive, so upgrading is really a considerable cost. But probably not worth causing $6.1bn delay – Technical debt can bite you in weird ways.
That is true for almost all Telcos I worked for. As they are a result of multiple mergers, the internal environment is absolutely horrible and moved by chaos. I'm currently working, as a consultant, with a Telco that has the worst IT team I've ever worked for and whose only job seems to be to blame us (the integrator) for everything.
I work for an aerospace-related org. You would be shocked at how even within a single org nobody enforces standards across different groups. Even within this one org they use a handful of different CAD systems whether by choice, or as a result of time passing and people and technology changing.
Nobody spends the money to bring old drawings forward into newer tech when it changes either, and the CAD files tend to often be proprietary binary formats that are difficult to work with.
Really quite annoying and wasteful, but it is the way it is because people don't think about these problems and plan/ spend in advance to avoid them.
Yep. At my employer, all programs that get deployed to production must be built with either the current version of the toolchain, or the previous version. All builds are hermetic, and it's a requirement that all programs get rebuilt and redeployed at least once every N months, so that the programs out in the wild aren't built with toolchains and libraries that are too wildly different from head.
But there's a whole team dedicated to the task of maintaining that state here. I can imagine that at a company where this is not the core competency, there would be some slippage.
In a way it is ironic because in aeronautical engineering everything is well tested with backup systems when it comes to making the airframes, engines, and the entire airplane.
Yet, they did not engineer their software system according to the same standards of residency which is a part of engineering often forgotten about by many.
One of the great value-added of firms using open source software is indeed the integration testing of various software packages.
EDIT: Autocorrect correction:
Yet, they did not engineer their software system according to the same standards of ++resiliency++ which is a part of engineering often forgotten about by many.
> Really interesting! ... I take it as a high priority for all software packages, from dev to test to prod, all be on the exact same version. Python 3.4 on one box and 3.6 on another? Let's not.
The canonical way to get around this is unit test and CI.
This article shows that airbus did that...and still got screwed.
Being able to correctly identify logical fallacies is an important skill in and of itself. Persuading someone that they are wrong is a totally separate exercise.
> Being able to correctly identify logical fallacies is an important skill in and of itself.
It's not, really. A person who understands the notions of necessity and sufficiency, knows what a counterexample is, and knows their truth tables (with or without really knowing the textbook definitions of these things) should be able to function just fine without knowing the names of all the various fallacies.
(consider how many people who are inclined to complain about logical fallacies do not understand these things, and therefore misapply the labels)
> A person who understands the notions of necessity and sufficiency, knows what a counterexample is, and knows their truth tables (with or without really knowing the textbook definitions of these things) should be able to function just fine without knowing the names of all the various fallacies.
Not really. They help for the same reason memorizing formulas in math help - they save the work and time needed to derive the formula again and again. That matters an awful lot in real time discussion. Also, if you know what fallacies exist it is much easier to recognize and encounter them compared to when you have to process the fallacy for the first time. You can even think them through in advance and prepare the argumets.
> They help for the same reason memorizing formulas in math help - they save the work and time needed to derive the formula again and again.
The rules surrounding syllogisms are so simple that I cannot believe anyone would use the word "derive" to describe the process of recognizing a problem with the logic with something like that (the syllogistic fallacies). I'm not sure most people even need to think consciously about the logic, let alone the taxonomy of possible problems with the logic.
On the other hand, informal fallacies, or inductive fallacies... you've got a point there in some cases, I suppose.
You are confusing physics with biology, if you will. You could say the entire field if biology is redundant -- it's all consequences of basic physics -- and yet biology is a very useful science.
Arguments aren't presented mechanically step-by-step with a citation of rule at each step; they elide and summarize information, and skip logical steps.
The fallacies show you where to look for insufficencies, to avoid being misled by invalid shorthand arguments.
Well, no. We can trivially identify the presence of a fallacy by knowing a few things about logic and so on. The same is not true of biology: an experienced physicist won't necessarily have much ability solving biology problems, as you know.
(I don't remember thinking about the individual fallacies by name very much at all except when I was learning logic, where they were used as examples. Once you're a little more experienced, it would be akin to saying to oneself "okay, now I am using the present tense" while writing.)
There's simply not enough time to do all those things yourself. Find someone "good enough" in one of those areas and have them take over main responsibility.
I have a long list of features that I want to implement at some point. When I get feedback from users for those same features I move them up somewhat in my priority list. If it's something that's not on my list I add it to the bottom of the list and re-evaluate it's importance a few days later. I think it is a good way to avoid immediacy bias and keep a handle on what's a true priority.
