TAOCP is too detailed and too deep as a beginner's book; you first want something lighter that you can worth through end-to-end before taking on a 7-volume book that is still not even finished (volume 4b of 7 in progress at the time of writing).
Note I am _not_ saying TAOCP isn't readable, I consider it very well written. But it's terse, hard, too deep and too detailed for a beginner, IMHO.
Having unscripted conversations is one of the best way to be swayed by unconscious bias in interviews.
Even though this advice sounds awesome, I will be cautious of putting it into practice without thinking through the bias problem.
I do remember reading multiple research papers on this, but unable to find them at the moment. From anecdote - In the last company I worked in London, only one team (DevOps) did not follow scripted interviews. It was the least diverse team, not just in terms of representation, but in terms of diversity of thought. Most of it was comprised of "tech-bros".
Scripted interviews do not mean you ask through a basket of questions. It just means that you stay within the guardrails of a set of topics and you go through all the topics. With in a topic, you have fair amount of flexibility. For example if you are hiring for a mid level Java programmer your topics may include - Java 8, Testing pyramid, Functional programming, type safety, developer safety(CI/CD/Rollbacks/Code reviews/Pair programming etc), some domain specific knowledge and so on.
> In the last company I worked in London, only one team (DevOps) did not follow scripted interviews. It was the least diverse team, not just in terms of representation, but in terms of diversity of thought.
Did this result in poorer job performance for the DevOps team, or any other negative business results that were specific to that team? If not, who’s to say which interviewing method was better or worse?
As an interviewer I’ve always felt very constrained by scripted interviews and “approved question lists”. I always struggle to really evaluate a candidate when I’m asking pre-selected questions without knowing why I’m asking those questions.
> Did this result in poorer job performance for the DevOps team, or any other negative business results that were specific to that team? If not, who’s to say which interviewing method was better or worse?
It did. And even if it had not in this particular case, it will hurt the company in the long run. There is not even a shred of doubt in my mind that diversity (of thought) is the best investment that leads to success.
I have been using scripted interviews, the same method I mentioned in original comment, for more than 5 years now, hiring more than 200 engineers in three continent and I am super happy with my results.
> It did. And even if it had not in this particular case, it will hurt the company in the long run.
Honestly, having been on plenty of interview panels for a decade now for DevOps and SRE roles, I'm not sure structured interviews, no matter how awesome they are, can solve the recruitment diversity problem. The war was already lost the moment the job description was published, IMO.
I think it's also important to keep in mind that at minimum it would take a generation to truly solve in a root-cause way (one that won't just come back the minute you focus on something else). Many of these biases get built during childhood when your brain is so so much more plastic.
I have seen the same thing happening in recruitment for marketing roles. Totally unscripted interviews often leads to suboptimal results in terms of the quality of the candidate and their fit for the role. Made this mistake firsthand before devising my own process of hiring.
And the process I follow is based on having an exhaustive list of questions covering all areas of the role but during the interview if something else comes up, I don’t mind pursuing that and going unscripted. It often helps me add more questions to my list so my list of questions keeps improving.
I’ve been following this process for last couple of years and the structured process has helped me hire some of the best people I had the privilege of working with. Also, I feel more confident that I’m hiring the right candidate. But of course, there could be an element of bias in there.
Side point - I’ve just finished a SEO hiring guide that covers my whole process of hiring an SEO person (both junior and senior roles). Will be publishing that in the next 4-5 days. If anyone is interested in purchasing a copy, my email is in the bio.
Research shows more diverse teams deliver better results. You’re asking something that can’t be proven though: is this thing that is occurring better than the thing that didn’t occur. We can’t know the answer to that.
> Research shows more diverse teams deliver better results.
FYI, there's plenty of nuance in the research that people like to gloss over. My understanding is that diversity of background / experience improves team performance. But having a diversity of values amongst your team decreases performance.
For example, if you form a diverse team where some people care about profits above all else, and other people care more about doing good in the world, the team will become less effective. Its really hard to use this research when hiring because a lot of values questions (like "who did you vote for?") are somewhere between creepy and illegal to ask.
Source: I used to work with someone who had a PhD in psychometric assessment. People saying "diversity=good" was one of her bug bears. I haven't read the research myself.
I would ask if there was any published studies showing that "diversity of values" was bad, because searching Google for "diversity of values bad" does not yield any relevant results.
Then I would ask what her political leanings were next.
Studies seem to show that diversity initiatives fail mostly because of a lack of comprehensive diversity and inclusivity effort, e.g. companies talking big about it, but not backing it up with action, money, people, etc.
> Research shows more diverse teams deliver better results. You’re asking something that can’t be proven though: is this thing that is occurring better than the thing that didn’t occur. We can’t know the answer to that.
Research is based on the cumulative results of many recorded events, in which we try to garner a pattern of relationship.
A singular event might have two inputs: we either do the thing or we do not. We can observe the results of what we do, but we cannot observe the results of what we do not. With the aforementioned research, we can _estimate_ the results, and, in some cases, we should make decisions with those estimates in mind, but these are two entirely different concepts. Macro and micro.
> Research shows more diverse teams deliver better results
Seems like a bit of a sacred cow - how much better? Better enough to sacrifice, say, experience, contacts, or unique business knowledge for? How much, exactly?
Odd comment. We hate the tech interview because it doesn't fairly evaluate on the job performance of candidates, but apparently it's ok to reject them because they don't fit the interviewer's tribe.
I wonder when will diversity require to also be skill-wise: like it is required to have someone on your team who cannot code at all, just for the sake of bringing "different perspective".
I'm going to go out on a limb here and say I think most candidates don't hate scripter interviews, they hate robotic interviewers that go mindlessly through a checklist.
When I train interviewers my advice is: have a script, but be happy to go off it. If interviewers keep an authentically engaged conversation, the questions will blend into the background.
Scripts helps in several fronts. They help to reduce bias, standardise calibration and practices between teams, and provide a fallback to get the interview on track. However good interviewers should keep a living conversation with candidates, and take interesting cues off script.
It also means you have definitive qualifications for correctness. It’s harder to say “I’m not sure about this person,” when they quantitatively answered every question correctly. If you “have a conversation,” it’s a lot easier to have those itches, which might be primarily driven by bias, make your hiring immediately become problematic.
Lack of diversity of thought is easy to spot IMO. Bigger point is - you should ensure your processes are setup to at least try to achieve the kind of diversity you would like to achieve. Those processes may still fail, just like anything else.
If someone answered every question the way the interviewer thought it should be answered that is probably an indicator of lack of diversity of thought, but I think it would actually be hard to spot because they would really look like the perfect candidate - unless the interviewer thought of themselves as a bad candidate / unoriginal thinker - which is unlikely.
On the other hand someone answers in a way that you have decided before hand is just the misguided answers of a particular tribe can be lack of diversity of thought, because you happen to be right about the preconceived ideas of said tribe, but pretty hard not to see that as the result of bias.
If on the other hand someone says some things you don't understand, espouses ideas completely alien - insane!
You are taking diversity of thought comment, which I mentioned as an attribute of a team and trying to apply to an interview, which is not what I intended. Your interview processes need to ensure that you do not hire based on biases, so that you will have a diverse team.
Also interview processes are not just interviewer protecting against his/her bias, but also against bias of interviewee which seems to be somehow lost in these discussions.
I have tried using fakes over mocks, but it becomes cumbersome if it is a large-ish code base with handful of developers contributing to it. Keeping expectations on what a particular Fake does gets contentious. Mocks however usually allow a developer to encapsulate entire mock behavior within the boundaries of a unit test.
I am curious to know if you ran into similar problem, if you did how you managed to overcome it?
As a counter point, I was almost fired for not choosing to build a SPA for an internal app which was going to be used by 3-5 people, 5-10 times a month, if that many.
I worked at large accounting software provider, and internal billing system used static pricing which was changed once a year. The company wanted to move to a more flexible system where pricing can be setup based on few rules like customer type. For this the ui and backend system needed to be developed. Design I proposed was a single "monolithic" service which did everything including UI and UI was supposed to be a old style mustache templates and some minor jquery. Instead they went with pub-sub systems, 4 different microservices, a react based UI, api which used json-schema, even to send data back to UI. When I left a team of 6-7 people was working full time on this and they were about 20% done.
If you join an early stage startup today, it will only be a matter of time until a developer comes in who builds a microservice for what would normally be a single function calling a third party api and then discovers that Kubernetes is necessary. Its almost impossible to stop this happening because business folk want microservices, or they might have heard microservices were going out of fashion but still want Kubernetes...which is only really necessary for microservices.
Devs like to have fun, learn new things, play with complicated things - that's all it is. It counteracts the dull features that most developers have to ship.
I have met enough devs that don't necessarily love to make everything Dockerized microservices on Kubernetes, just that if we don't learn this stuff we risk becoming unemployable.
Are you me? We had an (admittedly more complex) monolith application for customer contracts and billing. It wasn't ideal, and was getting long in the tooth (think Perl Catalyst and jQuery), so the powers that be wanted to build a new service. But instead of decomposing the monolith into a few more loosely integrated services, they went way overboard with 20+ microservices, every DB technology imagineable (Oracle RDBMS, Mongo, MariaDB), a full message bus via RabbitMQ, and some crazy AWS orchestration to manage it all.
What could've been an effort to split the existing service into manageable smaller services and rewrite components as needed turned into a multi-year ground-up effort. When I left they were no where near production ready, with significant technical debt and code rot from already years out of date libraries and practices.
Sounds like my current project. I was tasked to start working on a project and was told I could use "whatever [I] want." So me and the other frontend guy started working using Clojurescript with Reagent and Re-frame (highly recommend). Save for a few hiccups along the way the project was stable and fast.
It went swimmingly right up until QA was more or less told not to file any issues found, and then those issues were used as a reason we needed to use a TypeScript and Material-UI app he wrote over a weekend and said was "almost done." The bugs in question turned out to be minor visual bugs, and like I said, none of them were filed or even mentioned until this replacement got dropped in our lap. In fact, no problems of any kind were reported until this moment.
Instead it took another 6-8 months to get to feature parity with the app we'd already developed and now thrown away (or feature "parody" as my boss put it), it was full of bugs, development is slow and pretty directionless, my boss gets bored and contributes code that runs in the O(n^12) range (yes, really) before languishing in a draft PR for months and then getting dumped on us to actually implement for real, and it's been a year and a half with no end even remotely in sight.
I really want to find somewhere else but that doesn't seem like a realistic goal right now. Not to mention my enjoyment of programming died years ago and I haven't written code for fun in as long as I care to remember.
IMO the real failure here was not having an internal administration website with all the auth and API plumbing already set up, which you could tack a new page onto with minimal fuss, and a backend to tack a new API endpoint onto with no hassle.
If you're building a new internal webapp from scratch for a small internal use-case, you just end up with a hundred different poorly-maintained apps.
But in the situation where you're adding a page to an internal app, it's trivial to make that new page a SPA React app, since the framework is already there waiting for a new component.
At least as per the wikipedia page[1], there is a lag of 2 years between product and company, and there prior history of him working on similar products. So I think it is reasonable to give benefit of the doubt that open source product was created in good faith and commercial interests only got explored later.
Most open source to commercial success stories like Kafka, Mongodb, and Elastic do seem to follow similar path.
Interesting but I doubt it. Vaanaras do not appear prominently in any of epics/puranas following Ramayana. Only Hanuman is present in Mahabharata and he is clearly living a solitary life when he meets Bheem.
That's an interesting point (no idea why you've been downvoted for it). I have a few theories why that might be:
1. Groups like these were more likely to survive if they were isolated and not occupying territory that the (presumably) more sophisticated Homo Sapiens coveted, so maybe they just didn't get interacted with otherwise. Rama had a Vanavasa (forest-living) and a generally weird out-of-pattern life for the time, so had a slightly higher chance of encountering them.
2. If people in later stories did come in contact with them, they were probably trying to expand their territories or otherwise conquer the land. In that case, the stories are going to mythologize them as savage Asuraas, to give further justification to the conquests.
3. We only have a few stories, of unknown time origin, remaining out of hundreds of thousands of stories told by different groups in different places over the millenia. So even if a significant portion of the stories featured Vaanaraas, it's plausible they might all have been lost before they could reach us.
4. In particular, given that such groups were declining in numbers over time, and the fact that more recent stories are more likely to survive, it makes sense that stories featuring them are more likely to have been forgotten and lost to time.
There is also Jambavan who appears in both Ramayana and Mahabharata. Jambavan’s army fought alongside the Vanara army in Ramayana.
Even though he is depicted as part of the monkey army, he was really known to be a bear. A bear like giant creature.
He appears again in Mahabharata as the possessor of the Syamantaka Gem that was stolen and was in his possession. They live in a cave and hidden from the rest of the people. He is defeated by Krishna and he accepts defeat. He also offer Krishna his daughter Jambavati’s hand in marriage.
In the Puranas ..after the Ramayana war, all the monkeys and bears who lost their lives were brought back to life and they returned to their abode. Mahabharata is to have happened in a different yuga.
Hanuman keeps appearing in all puranas because he is Chiranjeevi..one without death. And hence more of an archetype than a character in every yuga.
The Vedas do not mention monkey people (vanaras), but the Mahabharata and the Ramayana do. The Vedas were composed 800-1000 years before these two epics. So the invention of the vanaras probably happened later, perhaps due to influence from indigenous religious ideas or perhaps a new set of myths. Interestingly, the Ramayana only gives vanaras monkey-like features but doesn't identify them as such, so there is some ambiguity about how they are to be represented.
I paid for bumble during the pandemic mostly to meet people closer to me who were looking for lock down buddies. Not a romantic or sexual relationship, but a platonic one using the BFF mode it offers. I did meet few interesting people around with that.
My suggestion is to not indulge in any content moderation which is not illegal. Only take down content which is required by a court order. Limit use of automated content moderation only for easy to solve cases like child pornography.
Why?
It is fairly clear at this point that content moderation at internet scale is not possible. Why? A. Using other users to flag dangerous content is not working. Which users do you trust to bestow this power with? How do remove this power from them? How do you control it becoming a digital lynch mob? Can you have users across political, gender, other dimensions All mostly not solvable problems.
B. Is it possible to use machine learning? To some extent. But any machine learning algorithm will have inherent bias, because test data will also be produced by biased individuals. Also people will eventually figure out how to get around those algorithms as well.
The causality between content published on the internet and action in real world is not immediate. It is not like someone is sitting in a crowded place and shouting fire causing a stampede. As there is a sufficient delay between speech and action, we can say that the medium the speech is published in is not the primary cause of the action, even if there is link. Chances of direct linkage are fairly rare and police/law should be able to deal with those.
Content moderation, at least the way Twitter has been trying to do, has not been effective, created lot of ways for mobs to enforce censorship, and there is absolutely no real word positive impact of this censorship is. Only use of this moderation and censorship has been for right to claim victimhood and gain more viewer/readership to be honest.
You realize that the approach you suggest pushes out a different set of people, right?
For example, a soldier with PTSD may want an environment that moderates content. Or a journalist with epilepsy may want a platform where people don't spam her with gifs designed to trigger epilepsy when she says something critical of a game release.
Doesn't that require the active cooperation of bad actors? Sure, you can create a filter to hide all posts tagged with "epilepsy-trigger", but that doesn't help if the poster deliberately omits that tag. Allowing users to tag other people's posts patches this issue, but opens up the system for abuse by incorrect tagging. (E.g. Queer-friendly posters being flagged and demonetized after being maliciously tagged as "sexual content".)
At some point, there needs to be trusted moderation.
I’d point out that child sexual abuse content is not an “easy to solve case”. The extent to which Facebook, Google, and more recently, Zoom look the other way on this issue is horrifying and it seems to be a very hard problem due to the laws surrounding the handling of such material. I’m not faulting the laws, I just think this is an inherently hard issue to crack down on. Gabriel Dance and Michael Keller at the NYT did some very high quality reporting on this whole issue in 2019 (https://www.nytimes.com/interactive/2019/09/28/us/child-sex-...).
That link is pay/auth-walled for me, but I do get your point. Perhaps easy to solve was underestimate the technical problem as I was more thinking in terms of political problems. From that perspective no one, other than pedophiles themselves, disagrees with removing that kind of content. But completely agree on tech side of it.
I am only commenting on this in the context of community standards and user generated content and should not be extrapolated to all content in all other contexts.
That is a fair question/comment. In my original comment "Limit use of automated content moderation only for easy to solve cases like child pornography." . It is reasonable to extent that list beyond just child pornography. I did not intend to give impression than this list is exhaustive.
In case of spam - Emails do show you spam emails, just hide them behind a spam folder. So instead of outright removal, it is possible to use similar techniques. And let users decide whether they ever want to see spam comments.
- Rackspace was sold to private equity and restructured and made public a second time.
- LogMeIn was sold to private equity
- Kaplan is part of bigger company
- Ultimate software merged with Kronos
- Shutterfly was acquired by private equity
- Wirecard is a scam.
- Grubhub is going to be acquired by a bigger competitor
- Travelport, Expedia and Bookings are 3 very similar companies which bought all the smaller competitors.
Also note that these are internet companies and do no include myriad other software companies, including enterprise tech. So I am not sure if I agree with your concern on tech being reduced to 5-10 big companies.
