MongoDB and Realm make it easy to work with data, together – MongoDB - <AUTHOR> https://www.mongodb.com/blog/post/mongodb-and-realm-make-it-easy-to-work-with-data-together <comment><USER2> As an ex-Realmer, I'd like to congratulate everyone involved in Realm in the past few years. Great engineering talent, extremely dedicated and motivated people. This is the company that has helped me understand the value of good marketing. I've also been inspired by what a good product owner can do.

Kudos to everyone. It's been a long road, and I'm glad that the codebase that initially started as a text editor finally found a new home.

</comment><comment><USER3> This is awesome! Two of my favorite products joining together. Now I just hope they keep their promise and keep investing in Realm.

</comment><comment><USER4> At some point I'll write up my notes about how I've been using MongoDB. I've basically given up on SQL databases. Every architecture, for every scale, from small to Enterprise, is really better handled by MongoDB, sometimes in conjunction with Kafka (since any sufficiently large operation is automatically heterogeneous and polyglot, with different database technologies).

When you're a small startup and you're just starting up, you can create a single MongoDB instance (ignore everything about you've heard about Web Scale) and stuff data into it as needed, without thinking much about the structure. You can add in contracts on your database functions, which slowly specify the contract, as you learn more about what your project is really about. To get a sense of that style of development, please see what I wrote in "How ignorant am I, and how do I formally specify that in my code?"

[http://www.smashcompany.com/technology/how-ignorant-am-i- and...](http://www.smashcompany.com/technology/how-ignorant-am-i-and-how-do-i- specify-that)

MongoDB is great for ETL. You can pull JSON from 3rd party APIs and store it in its original form, then later transform it into the different forms you need.

In large Enterprises, you will inevitably be trying to get multiple services and databases to work together. The old style for dealing with this was the ESB (Enterprise Service Bus) or SOA (Service Oriented Architecture) but in recent years most of the big companies I've worked with have moved toward something like a unified log, as Jay Kreps wrote about in "The Log: What every software engineer should know about real-time data's unifying abstraction". If you haven't read that yet, go read it now:

[https://engineering.linkedin.com/distributed-systems/log- wha...](https://engineering.linkedin.com/distributed-systems/log-what-every- software-engineer-should-know-about-real-time-datas-unifying)

In this context, MongoDB can offer a flexible cache for the most recent snapshot your service has built, based off of what it read from Kafka.

Some people are sabotaged by MongoDB, and they start treating canonical data as a cache. Obviously that leads to disaster. I believe this is what happened to Sarah Mei. Her experiences caused her to write "Why You Should Never Use MongoDB"

[http://www.sarahmei.com/blog/2013/11/11/why-you-should- never...](http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use- mongodb/)

The one rule I would suggest is that you always need to be clear, in your own head, which collections are canonical and which are cache. When I talk to teams who are new to this, I tell them to use a naming convention, such as adding a "c_" to the start of every collection that is canonical. All other collections can be assumed to be caches. And the great thing is, it is very cheap to create caches. You can have 20 caches for the same data, in slightly different formats. You can have one cache where the JSON is optimized to what the Web front-end needs, and another cache where the JSON is optimized for the mobile app, and another cache where the JSON is optimized for an API for external partners. Just don't fall into the trap that Sarah Mei mentions, where you treat everything as a cache. You need to be clear in your head which data is canonical. If you are using Kafka the way Jay Kreps mentions, then the data in Kafka is canonical and everything in MongoDB is a cache. But at smaller operations, I've used MongoDB to hold both the canonical data and the caches, in different collections.

<comment><USER5> _When you 're a small startup and you're just starting up, you can create a single MongoDB instance (ignore everything about you've heard about Web Scale) and stuff data into it as needed, without thinking much about the structure. You can add in contracts on your database functions, which slowly specify the contract, as you learn more about what your project is really about. To get a sense of that style of development, please see what I wrote in "How ignorant am I, and how do I formally specify that in my code?"_

This strategy seems like it forgoes what I consider an important step in any project, which is, thinking critically about your data model and getting that right before you start building code on top of that structural foundation.

I could see doing what you're describing to build a prototype, which I would then extrapolate my learnings from, and subsequently toss out, but this seems like a dangerous way to get started with something that will end up in production (and potentially maintained for years to come), as it glosses over the importance of coming up with a really coherent data model, and let's face it, data is the heart and soul of most projects.

Am I wrong?

<comment><USER4> " _I could see doing what you 're describing to build a prototype_"

It's very much for prototypes, and especially greenfield projects. If I was, instead, doing something like building a new service, inside an Enterprise that was already using something like the unified log architecture that Jay Kreps has described, then I would certainly think hard about what the schema would be for the particular service I was building -- after all, in such situations you're never going to pull all of the data out of Kafka, so you automatically have to figure out what part of the data you want. LinkedIn currently stores 900 terabytes of data in its Kafka instance, and I'm unlikely to write a new service that actually needs all of the 900 terabytes of data. So merely by thinking about the question "What of this data do I need?" I'm already implicitly thinking about a schema.

Having said all of that, how often have you written a service where you got the schema 100% correct on your first try, and no further changes to the schema were needed. Possibly you are smarter than I am, but I personally have never done that. All of my first attempts need later adjustment.

</comment></comment></comment><comment><USER6> Can someone confirm that Realm raised USD 40 M and was acquired for USD 39 M?

<comment><USER7> TechCrunch is reporting those stats: [https://techcrunch.com/2019/04/24/mongodb-to-acquire-open- so...](https://techcrunch.com/2019/04/24/mongodb-to-acquire-open-source- mobile-database-realm-startup-that-raised-40m/)

</comment></comment><comment><USER8> I'm sure mongodb is fine now but it's too late. I don't care. I'll never use it again or recommend it to anyone</comment>


Proof that Scheme will never be faster than C - <AUTHOR> http://www.cs.princeton.edu/~appel/papers/conteq.pdf

<comment><USER2> It looks like a joke to me. The program always just calls exit(0); straight away if the main function is the expected one, which is why it's so fast. All the rest is just noise to hide that. All he seems to be saying is that the competition could be won by implementing fastroot() as just calling exit(0).

<comment><AUTHOR> Thanks. The choice of ;=) as the operator did make me suspicious.

</comment></comment><comment><AUTHOR> Andy Wingo linked this on his blog, with this cryptic title and no elaboration. I read it, but I'm not sure I got it. What's the deal?

<comment><USER3> This isn't really proof that Scheme will be faster than C, and in fact doesn't really mention Scheme at all, except to show that it is a language that supports call-with-current-continuation as a primitive operation.

What I got from the paper is that using continuations with intensional equality (that is to say their contents are the same) can be used to dramatically speed up a program. And so, a primitive way to create intensional equal continuations would be a potentially worthwhile primitive for a language.</comment></comment>


Donate to the Internet Archive - <AUTHOR> https://archive.org/donate/index.php <comment><USER2> I've donated to the Internet Archive and I'm a big fan of Jason Scott, but the Internet Archive _is not an archive_. Any site on it can go down without warning, thanks to the fact that they apply current robots.txt rules to past archives. Once a domain squatter or regretful admin forbids archivebot (or crawlers in general), archive.org's copy goes down.

This has ruined many supposedly permanent links. The infamous "She's a Flight Risk" blog from a decade ago is down.[1] My first website is missing. Even public domain stuff like NASA's report on nuclear propulsion is gone.[2]

With just a small rule change (obey robots.txt at the time of crawling), they could eliminate the risk of a page disappearing. Instead, we're stuck with a slower version of the link rot we're used to. It doesn't stop me from supporting them, but it's incredibly frustrating.

1\. [https://web.archive.org/web/*/http://www.aflightrisk.blogspo...](https://web.archive.org/web/*/http://www.aflightrisk.blogspot.com)

2\. [http://web.archive.org/web/20121029225832/http://ntrs.nasa.g...](http://web.archive.org/web/20121029225832/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19770085619_1977085619.pdf)

<comment><USER3> Just for the record, we are an archive, just one with some policies (that I myself have been working to have tuned) that you might not like. I understand that you don't like the policy.

<comment><USER2> Wow, _the_ Jason Scott! While you're here, can you please answer two questions:

Does the Wayback Machine retain data excluded by new robots.txt rules? (In other words: If you change your policy in the future, can the change be retroactive?)

Why does archive.org keep this policy? It drastically limits what The Wayback Machine could be. I've searched quite a bit, but I haven't found a satisfying answer.[1]

1\. [https://archive.org/post/1019415/retroactive-robotstxt- remov...](https://archive.org/post/1019415/retroactive-robotstxt-removal-of- past-crawls-aka-oakland-archive-policy) contains links to previous discussion on archive.org.

<comment><USER3> Answer One: Archive.org does the right thing. Answer Two: Long ago agreed to this policy: [http://web.archive.org/web/20130628205733/http://www2.sims.b...](http://web.archive.org/web/20130628205733/http://www2.sims.berkeley.edu/research/conferences/aps/removal- policy.html)

The irony that the policy can only be viewed through the wayback machine is not lost on me.

</comment></comment></comment></comment><comment><USER4> They need a whole $75/person instant as compared to Wikipedia's $3/person instant and they're not resorting to shouty, loud boxes that open modals on mobile platforms.

I love you, Internet Archive.

<comment><USER5> I don't know about mobile (I've only noticed a small banner on at the bottom of the page on WP), but it appears they're using the exact same style of banner that Wikimedia use? They even explicitly give thanks to Wikimedia in the footer of their fundraising banner. I think both services are great, so I don't really mind if either of them decide to optimize their conversion rates, just like any other startup would.

</comment></comment><comment><USER6> Archive.org has been an absolute godsend for historians and others who use rare books. Case in point: when I was doing PhD research in Lisbon three years ago, I had to search several rare book shops and ended up paying 80 euros for a very rare 19th century Portuguese book I needed for my research. Here it is on archive.org in multiple editions, all text-searchable: [https://archive.org/search.php?query=duarte%20ribeiro%20de%2...](https://archive.org/search.php?query=duarte%20ribeiro%20de%20macedo)

</comment><comment><USER7> I hate to sounds bitter, but I've been a donator for ~8 years, and the one time I asked for help (really: filed a bug report re: an archive they said they had but which didn't acually resolve & which I needed access to) they did not get back to me, ever, despite numerous support requests and additional donations.

I'm not sure whether that means they need more funding or whether they're simply unresponsive, but it definitely didn't help me solve my problems with a trademark troll.

</comment><comment><USER8> There have been a bunch more donations since this has been posted on HN. The easiest way to see this is the subset that is donated via bitcoins: [https://blockchain.info/address/1Archive1n2C579dMsAu3iC6tWzu...](https://blockchain.info/address/1Archive1n2C579dMsAu3iC6tWzuQJz8dN) more disks and bandwidth!

</comment><comment><USER9> Just in case you'd like to look at their financials before donating, they are at faqs.org [1]. I couldn't find the official IRS Form 990 online.

[1] [http://www.faqs.org/tax-exempt/CA/Internet- Archive.html#anal...](http://www.faqs.org/tax-exempt/CA/Internet- Archive.html#analysisOfRevenueAndExpenses)

<comment><USER10> Their 2012 990PF: [http://18.104.22.168/EINS/943242767/943242767_2012_09c9e75b...](http://18.104.22.168/EINS/943242767/943242767_2012_09c9e75b.PDF)

[http://www.eri-nonprofit- salaries.com/?FuseAction=NPO.Summar...](http://www.eri-nonprofit- salaries.com/?FuseAction=NPO.Summary&EIN=943242767&BMF=1&Cobrandid=0&Syndicate=No)

</comment></comment><comment><USER11> I just donated... I use them all the time to look up old computer magazines from the 90s.

<comment><USER12> That's how I read BYTE. It's also a good source/reference for (some (specific)) WP articles.

[https://archive.org/details/byte-magazine](https://archive.org/details/byte- magazine)

[http://en.wikipedia.org/w/index.php?title=CHIP-8&diff=585383...](http://en.wikipedia.org/w/index.php?title=CHIP-8&diff=585383077&oldid=580877928)

[http://en.wikipedia.org/w/index.php?title=Halt_and_Catch_Fir...](http://en.wikipedia.org/w/index.php?title=Halt_and_Catch_Fire&diff=593246287&oldid=580194900)

<comment><USER11> Look how many computer magazines are available: [https://archive.org/details/computermagazines](https://archive.org/details/computermagazines)

</comment></comment></comment><comment><USER13> Sounds reasonable. I did just have to use them as "backup of last resort" to recover a web site. A little scraping turned "sorry, its gone", into "web site is back online".

</comment><comment><USER14> This is something I am happy to donate for. These guys have been plugging away quietly for a long time to give us a record that would otherwise literally disappear into thin air.

</comment><comment><USER15> Here's a link to the donation page (rather than to the main page, which happens to have a donation banner now): [https://archive.org/donate/index.php](https://archive.org/donate/index.php) .

<comment><USER16> Thanks, we changed it from [https://archive.org](https://archive.org).

</comment></comment><comment><USER17> Are you kidding me, I'm trying to take down my internet history, not keep it around.

<comment><USER12> Except _internet_history_ is no-one's to control; once something is on the internet, it belongs to The People.

<comment><USER18> Right, like revenge porn and Celebgate! Once someone has seen it online, everyone has the RIGHT to see it until the end of time.

<comment><USER19> Who gets to decide what is and isn't of historical value?</comment></comment></comment></comment>


Show HN: Social engineering with Chrome's autofill - <AUTHOR> https://www.isimonbrown.co.uk/address-game/#

<comment><USER2> On first attempt it took me to my address in Chrome's autofill preferences, then second time it worked (got the alert).</comment>


The Utter Uselessness of Job Interviews - <AUTHOR> https://www.nytimes.com/2017/04/08/opinion/sunday/the-utter-uselessness-of-job-interviews.html <comment><USER2> I find it quite problematic that researchers get to talk about their own research and present it as facts without anyone taking a critical look.

Over time I've become more skeptical about this kind of psychology research (as more studies fail to replicate) and, as is often the case, here the sample size is quite small (76 students, split across 3 groups), predicting something relatively noisy as GPA. It is unclear to me that one would be able to detect reasonable effects.

Furthermore, some claims that make it into the piece are at odds with the data:

> Strikingly, not one interviewer reported noticing that he or she was > conducting a random interview. More striking still, the students who > conducted random interviews rated the degree to which they "got to know" the > interviewee slightly higher on average than those who conducted honest > interviews.

While Table 3 in the paper shows that there is no statistical evidence for this claim as the effects are swamped by the variance.

My point is not that this article is wrong; verifying/debunking the claims would take much more time than my quick glance. But that ought to be the responsibility of the newspaper, and not individual readers.

Politicians don't get to write about the successes of their own policies. While there is a difference between researchers and politicians, I think we ought to be a bit more critical.

<comment><USER3> Of course we should be more critical, the methodology here is far from perfect. But right now, people have much faith in interviewing, and this research suggests that this faith may not be justified. As you mentioned, this is not the only research that reaches this conclusion. There is also the work by Daniel Kahneman[1] which I find pretty rigorous and draw the same conclusions about interviewing.

So obviously, the title of this article should be _" Maybe interviewing is not that useful"_ instead of _" The utter uselessness of job interviews"_, but besides this I find your comment unjustified. In fact, it's quite the opposite, I believe this type of work contributed to make us more critical by questioning some basic facts about interviewing, that i would have never questioned just a couple of years ago.

> Over time I've become more skeptical about this kind of psychology research > _(as more studies fail to replicate)_

ok, this is interesting, where is it mentioned?

[1] Think fast and think slow. There is this short article which mention some of the results and has been discussed on HN a couple of times already. [http://www.nytimes.com/2011/10/23/magazine/dont-blink-the- ha...](http://www.nytimes.com/2011/10/23/magazine/dont-blink-the-hazards-of- confidence.html)

<comment><USER4> It's easy to present data that shows flaws with today's interviewing.

It's a lot harder to present a better way of predicting candidate performance in the workplace, along with substantial data that indicates it's better than today's methods. Corporations would _love_ more effective ways to determine effectiveness/performance before hiring.

Interviewing is terrible, but that doesn't mean there is a better option.

<comment><USER5> Nonsense. First step is to acknowledge that interviewing doesn't work very well. You can't keep deluding yourself because you haven't found a better way. Accept reality.

This is one of the biggest problems I see with business guys today. They want absolute certainty in a world which can't offer it. Start accepting that there is a lot of stuff we don't know and can't know at the moment and we simply have to work towards getting better.

You can't get better if you don't acknowledge that there is a problem in the first place.

These silly, must have +5 years of experience, and check all these boxes with technologies to get the job clearly shows the industry is completely lost at the moment and isn't willing to acknowledge it.

<comment><USER6> I still don't understand why employers can't simply set up a two week "trial contract" where as promising candidates simply work for two weeks so everyone can actually see and judge, with real world empirical data, how well the person does in the environment at the actual job.

Yes yes..of course I know this could be gamed as well, but no matter...you can't really argue that this wouldn't be magnitudes better then the typical current/broken interview process.

<comment><USER7> The concept of a two week trial contract is interesting, but also as flawed as anything else.

I switched roles to a new team, and the first 2 weeks were a trainwreck. It was almost of no predictive quality on how I would do.

Now, there are many reasons why that was the case, and perhaps those underlying issues should be addressed, but from all the role changes I've had, the first two weeks shows how well the group you're going into can onboard, more than it shows how productive the individual will be in the long term.

<comment><USER8> You would need a longer trial period, a few months is fine with a clause that allows earlier termination.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Laszlo Bock (former SVP of People at Google) did a great job summarizing decades of research around structured interviewing in his book 'Work Rules!'

For a quick reference, the two defining criteria for a structured interview are:

1.) They use one or several consistent set(s) of questions, and

2.) There are clear criteria for assessing responses

That second point is really important. You can't only ask candidates the same sets of questions and have a structured process: you need to understand what a "one-star" response vs. a "five-star" response actually looks or sounds like. Training and calibrating all of the interviewers in a large company around a similar rating system is nightmarish, so most companies don't bother.

The book also outlines that pairing a work sample with a structured interview is one of the most accurate methods of hiring.

If anyone is interested in some in-depth structured interview questions or work sample ideas, feel free to email me. I've spent the last few years working on a company in the interviewing space and would love to chat.

<comment><USER4> How does this work in practice?

If there are consistently used questions and specific criteria for assessing responses, can a candidate just learn the likely questions and what constitutes the "right" answer?

<comment><USER10> This is a good and important question. Also: while I have a lot of respect for people at Google trying to innovate on hiring, make no mistake: Google's heart is in the right place, but they aren't at the forefront of structured hiring, and their hiring processes are notoriously capricious.

The reality is that generating good questions for a structured interview is difficult. You can't just pose a programming problem. As you've noted, most programming problems have multiple good answers. Differentiating between multiple good answers from different candidates re-introduces subjectivity. Your brain would rather convince you that one valid answer is less good than another, even when it's not, that to admit to you that it can't differentiate or generate a narrative for you. The part of your brain that generates narratives is incredibly powerful and does not care about how accurate your hiring process ends up being.

What we tried to do was create questions that generated _lists of facts_. "Spot all the errors in this code" would be an example of this approach (but none of the three we used). We went into the process wanting to embrace epistemological uncertainty, generating a historical trail of data that we could retrofit to candidate performance.

In the end, work sample testing was so much more powerful a predictor for ourselves that we never fully got around to analyzing the data. Sometimes we'd get candidates that clearly generated inferior "lists of facts"; I think there may have been 1-2 instances where that outcome actually overruled work-sample testing delivered prior (out of a few tens of engineering hires and probably ~100 interviews).

<comment><USER11> Making sure I understand you: When you refer to work sample tests here, that refers to the crypto challenges and things like that that you published at Matasano? And you're saying that was much more predictive than the list of facts methods, right?

<comment><USER10> That's what people ordinarily assume I mean, but while our work sample challenges were similar to the cryptopals and Microcorruption stuff, they were not the same, or even derived from them. They were designed specifically to qualify candidates, and in fact predated our public challenges.

<comment><USER12> Just to further clarify, by work sample you do NOT mean an example of previously produced work? This still seems fickle: my dozen years of work output (for example, building and running a site with perfect uptime for millions of users) is not as valid an indicator of my future performance as how I happen to score on some arbitrary timed test?

<comment><USER10> Absolutely not. Samples of previous work are deceptive at the best of times.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> I have some major issues with their conclusions... and the title of the article (which is mostly nonsensical clickbait).

The real conclusion should be that "unstructured interviews provide a variable that decreases the average accuracy of predicting GPAs, when combined with (one) other predictive variable(s) (only previous GPA)."

This conclusion seems logical. When combined with an objective predictive measure of a person's ability to maintain a certain GPA (that person's historical ability to maintain a certain GPA), a subjective interview decreases predictive accuracy when predicting specifically a person's ability to maintain a certain GPA.

To then go on to conclude that interviews then provide little, to negative, value in predicting something enormously more subjective (and more complicated), like job performance, is absurd - and borderline bad science.

There are numerous (more subjective) attributes that an unstructured interview does help gauge, from culture fit to general social skills to one's ability to handle stressful social situations. I'd hypothesize all of these are probably better measured in an unstructured (or structured) interview than in most (any) other way. To recommend the complete abandonment of unstructured interviews (which is done in the final sentence of the actual paper) is ridiculous.

<comment><USER14> > There are numerous (more subjective) attributes that an unstructured > interview does help gauge, from culture fit to general social skills to > one's ability to handle stressful social situations. I'd hypothesize all of > these are probably better measured in an unstructured (or structured) > interview than in most (any) other way. To recommend the complete > abandonment of unstructured interviews (which is done in the final sentence > of the actual paper) is ridiculous.

Well, based on what? Is there any evidence for any of these hunches?

<comment><USER13> I didn't say it was based on hard data, that's why it's a hypothesis...

But, if you really believe that it's a huge leap to hypothesize that interviews would be a better measure of subjective social skills than metrics like GPA, I don't know what to tell you.

<comment><USER14> I mean let's go further back. I question the assumption that selecting for "culture fit" does much more than shut people out whose ethnic background or social class is too different.

<comment><USER13> I mean, that's an extremely narrow reading of "culture fit".

Believe it or not, there are non-racist and non-classist character traits that are also not represented in one's GPA.

But, I guess hiring for one's willingness to work with specific clients, or for one's happiness with the organization's structure (in, for example, a holacracy) wouldn't be valid things to hire around to you?

</comment></comment></comment></comment></comment><comment><USER15> I've been a programmer for a bit over ten years. I've worked at scrappy little startups, midsized companies, now for a tech giant for a few years. The engineers I work with at the tech giant are consistently better engineers than my other coworkers have been, and I credit the very structured interview process. We're trained to ask specific questions, look for specific types of answers, and each interviewer is evaluating different criteria.

Also, it is quite often not the technical questions that end up making us decide not to hire someone. That's just one area. I know it's the part that sticks out, and candidates give a lot of weight to it in their memory of the interview, but you shouldn't just assume it was that your whiteboard code wasn't quite good enough. I actually don't think that's the most common thing we give a "no hire" for.

<comment><USER16> Which of the companies paid the best/has the best benefits?

If it's the tech giant, it's very possible they attract better candidates because they offer more.

<comment><USER17> In my experience, the big Corps don't tend to offer anywhere near as much compensation but better days off etc etc.

The best sofware guys I've ever seen work at those big corps. The big corps are the ones that have the resources to work on the REALLY hard problems and not writing the same CRUD app over and over again. Those same companies also provide tons of educational benefits so that you become an expert in your field.

Things like fighter jet software are fantastically complex. You hear about the dumb mistakes that are made (International Date Line Issues), but you never hear about the thousands of hours of testing every change to code goes through and the insane calculations that are made every second in even standard level flight.

I have no idea why there is such a backlash against interviews. What's so hard about studying for a job you want? Even if you don't USE knowledge, you should at least be able to rederive things using your base knowledge. Thoe interviews I've seen at aero companies are damn hard. Tons of grilling on if you actually understand mechanics and fliud dynamics.

<comment><USER18> >I have no idea why there is such a backlash against interviews. What's so hard about studying for a job you want?

That's a really good question and I had to think about why I don't like interviews.

1\. It's an interrogation and the stakes are extremely high. There are so many aspects of it you don't control. Some guy had a shitty morning, or just doesn't like you, dropped your resume on the way back to his office, etc.

2\. It's completely phony and it starts with the first question, "So why do you want to work at generic company X?" "I need money," is not an acceptable answer. Now I have to be phony and tell them why their company is awesome (it's not) which makes be feel like a kiss ass. I have to pretend to be excited about working at a boring ass company. Just shoot me.

3\. We _have_ to do it, unless we have rich parents that died young like Batman.

4\. The person or people that are interviewing you have no notion of what you've accomplished aside from skimming your resume. All the hard work I've done to produce miracles in the last 20 or so years means, really nothing.

5\. Companies only reward tenure at that company. It signals the start of something new but that's typically a bad thing when it comes to work. Less vacation, less credibility, less influence, etc.

6\. You really don't know if the person or people you are interviewing are bozos or not. It doesn't matter, they cut the checks, they have the power.

7\. As the article insinuates, they're fairly pointless.

</comment></comment></comment></comment><comment><USER10> Take a second to read about the experiments this author conducted. They included:

Dummy candidates mixed in with the interview flow that gave _randomized_ answers to questions (interviews were structured to somewhat blind this process), and interviewers lost no confidence from those interviews.

Interviewers, when told about the ruse, were then asked to rank between no interview, randomized interview, and honest interview. They chose a ranking (1) honest, (2) randomized, (3) no interview. Think about that: they'd prefer a randomized interview to make a prediction with over no interview at all.

Of course, the correct ranking is probably (1) no interview, (2) a tie between randomized and honest. At least the randomized interview is honest about its nature.

<comment><USER19> The interview is also selecting for a single thing - GPA. You can be an utter arsehole and have a high GPA. You can have personal hygiene that stinks out any room you're in and have a high GPA. Basically, you can be completely impossible to work with and have a high GPA. The research they've done is suspect, because they weren't interviewing for an ongoing role, but for a single KPI.

Similarly, the people doing the prediction were _other students_ rather than teachers who know better what to look for. The research would better fit HR people hiring for roles they know nothing about than experienced team members hiring for roles similar to what they do.

The research results are massively over-applied, and in no way whatsoever is sufficient to use the term "utter uselessness of X". Unsurprising, given it is research by a 'professor of marketing'.

<comment><USER10> Like everyone else, I agree a face to face interview is the best way to verify a candidate doesn't smell bad.

I assume that interview could be pretty short.

<comment><USER19> Well, I suppose you could fish out the most trivial part of the comment and refute that. Why not set up a battery of short unit tests for the candidates? "Follow me, Jones, and we'll see how you handle the 'coworker with chewing gum' test next..."

The study was done on students, who almost universally have zero experience selecting people to work under them in an industry setting (or at all). Drawing conclusions from this particularly inexperienced subject pool and then extrapolating out is bogus, particularly given the extremely certain language of the article. The subject pool is at an age (18-22) where people are still figuring out what to make of themselves and others; they have extremely little adult experience of the workplace and judgment of character - indeed, at this age, people are notorious for making bad decisions in their personal lives.

When you look at the actual paper they link, out the window goes the declarative language, and instead the article is unusually full of weasel- words ('can', 'may'). There's a _major_ difference between "utterly useless" and the actual conclusion of their paper: "interviewers probably over-value unstructured interviews".

<comment><USER10> In the experiment the authors ran, interviewers felt more confident after interviewing a "candidate" who had secretly been instructed to randomize the answers. Later, they informed the researcher that so great was the value of the information they extracted from interviews, they'd _prefer_ a randomized interview to no interview at all. I think the authors made their point quite well.

</comment></comment></comment></comment></comment><comment><USER20> It's the whole process that's useless.

Remember a few years ago when this forum was drowning about how to find and hire "10x" people? 98% of employees were useless in the face of the 10xer.

The reality is, most of the time screening for general aptitude, self- motivation and appropriate education is good enough.

I've probably built a dozen teams where 75% of the people were random people who were there before or freed up from some other project. They all work out. IMO, you're better off hiring for smart and gets thing done and purging the people who don't work.

<comment><USER21> This I think is a very a good point. The scariest point about Lazlo Block's book is that he is very against the idea that people can improve or be trained better. To him there is this idea of predestination. You're either always good and always have been, or you're not good and won't get better and there is nothing Google can do.

I feel like as a company you could exploit a lot of value by just hiring people and training them. Training btw doesn't mean at work. Think how much you learned in college lectures vs. reading the actual textbook. It means going home and studying, and the incentive should be that you're getting things that make you more employable, so this shouldn't count towards hours (if it was say a very proprietary old programming language though I could see this argument falling apart).

Not saying this is the best way but shocked that everyone is "trying to find the best". What kind of world will that leave us in if all companies want to hire the same 3% of people? Businesses move slower, talent is lost, and inefficiencies accrue.

<comment><USER22> One wonders what exactly happened to this industry, why instead of training, companies are offloading the work to universities, MOOCs, and boot camps.

<comment><USER23> All about cost and trying to offload it somewhere else. Sadly it's very predictable, most businesses work that way.

Then again, theoretically this gives a huge edge to the proactive learners.

</comment></comment></comment></comment><comment><USER24> The problem is GPA itself isn't necessary a valid data point. It's less fallible than "gut instinct", as the author here seems eager to claim, but personality type can be more important than ability to memorize facts.

I'd rather hire a programmer who knew less and could get along with others than a master dev who's a total a-hole.

</comment><comment><USER25> It should probably have been titled "The Utter Uslessness of Unstructured Job Interviews", because that's the kind of interview the author criticizes.

In my personal experience, structured interviews can be very helpful in determining a candidates abilities.

<comment><USER10> Are you sure you're using the same definitions as the author? In practice, across a pretty decent sample of large tech companies, I've never seen a truly structured interview outside of Matasano, where I was almost murdered by my employees for instituting them. I think we'd hear far more complaints about them if they were common.

It's possible that what you consider to be a structured interview is in fact what this author (and I) would call unstructured. Specifically: if the interviewer has _any discretion about questions at all_ , the interview is probably fundamentally unstructured.

In a structured interview, the interview is less an interrogator than a proctor or a referee. Every candidate gets identical questions. The questions themselves are structured to generate answers that facilitate apples-apples comparisons between candidates: they generate _lists of facts_. The most common interview questions, those of the form "how would you solve this problem", are themselves not well suited to these kinds of interviews. It takes a lot of work to distill a structured interview out of those kinds of problems.

<comment><USER26> How did you feel about your experience using structured interviews for hiring?

<comment><USER10> Truly structured interviews are better than even the most rigorous traditional interviews. They are also more expensive to design and much more painful to deliver. Some kind of interview is probably necessary for every serious tech hiring process. Organizations should be realistic about the low quality signal they'll get even from structured interviews. Take time away from interviews and feed that time to off-site work-sample testing.

<comment><USER27> I've tried work-sample testing with middling results:

-The more hoops a candidate has to jump through, the more likely they are to bail out of your recruiting funnel. This is especially bad for college/postgrad recruiting when you aren't the #1 employer in your field. Everyone wants to work for the Googles and Facebooks of the world. It's hard getting someone to spend a couple hours for your startup job.

-People cheat. We usually issue a short coding project, grade for correctness, then do a code review over Skype or face-to-face. Many candidates turn in the exact same responses. I've even seen people cheat and have a friend do the Skype session with a totally different guy flying out. Do you proctor your test in a secure center? Use an online service to lock down their machine and record? Both are pretty invasive. Switching up the questions constantly is tough and makes your signal noisier.

-Industriousness and raw intellect trump skills/knowledge most of the time. Sure there's a baseline level of skill required to train someone quickly enough, like I wouldn't hire someone who didn't know basic data structures, but work-sample tests are often biased to those with a very specific background. I don't want employees who are great at doing what I need today. I want ones who will be great at figuring out what to do years down the line.

<comment><USER10> First: if you make candidates do work sample tests, you should reduce the amount of in-person interviewing you do to account for it. Up to a limit, most candidates would prefer your selection/qualification process to happen from their homes than from your office. Unfortunately, companies aren't serious enough about their tests to trust them, and do indeed tend to make this just another hoop.

Second, incorporate the work sample tests into your in-person (or even telephone) interviews. Now you have a (hopefully interesting) technical problem _they ostensibly just solved_ to talk about. Your evaluation should be by formal rubric, not interview, but it's easy to see if someone actually did it. We had no problems at all with people cheating (of people we hired with this process, over about 4 years, we fired not a single one).

Finally, I could not be less interested in the kind of amateur psychoanalysis tech interviewers hope they're accomplishing as a side effect of quizzing people about code in their conference rooms.

</comment></comment></comment></comment></comment></comment><comment><USER28> This discussion misses an important element, the skill of the interviewer. It is unsurprising that unskilled interviewers' assessments are poor predictors of future performance. It would be interesting to measure the accuracy of interviewers who have had years of experience interviewing, hiring, and managing people.

Here's how I think it works. Skilled interviewers are biased toward rejecting candidates based on _any_ negative impression. Structured interviewing has the same effect. It's the precision versus recall tradeoff. For this use case only precision matters. Extremely low recall is fine.

Also, in the GPA prediction example, the interviewer is penalized for predicting a low GPA for a person who performed well. But in hiring, there is no penalty for failing to hire someone who would have performed adequately.

(Yes, I understand there is an implicit assumption in my argument that candidates are not in short supply, but that's usually true, certainly at Google)

<comment><USER29> > For this use case only precision matters. Extremely low recall is fine.

Only if you have arbitrarily large amounts of time you can spend interviewing. Most of us don't.

</comment></comment><comment><USER30> > The key psychological insight here is that people have no trouble turning > any information into a coherent narrative. This is true when, as in the case > of my friend, the information (i.e., her tardiness) is incorrect. And this > is true, as in our experiments, when the information is random. People can't > help seeing signals, even in noise.

People see patterns where there are none. I think this is fundamentally why humans fail at statistics. If every fiber of your being wants to see patterns then you will see patterns. Probably why people hallucinate when in sensory deprivation tanks as well. The brain will make up patterns just so it can continue to see them.

The paragraph right after follows up with the statistical failure that pattern seeking leads to

> They most often ranked no interview last. In other words, a majority felt > they would rather base their predictions on an interview they knew to be > random than to have to base their predictions on background information > alone.

So people would rather do busy work in order to continue to satisfy established pattern seeking habits than figure out a better way.

</comment><comment><USER31> Matt Mullenweg advocates audition/tryouts instead of job interviews.

[https://hbr.org/2014/04/the-ceo-of-automattic-on-holding- aud...](https://hbr.org/2014/04/the-ceo-of-automattic-on-holding-auditions-to- build-a-strong-team)

<comment><USER32> That has to be one of the most employee-hostile hiring strategies I've ever read.

<comment><USER26> You're pretty much limited to hiring either only the jobless or someone with the ability to work two jobs at once for an extended period of time while you hold your tryout. There are a lot of people who can't devote that kind of time to a second job (some candidates burn a week's vacation!)

And it's not some mere formality, according to their stats they hire about a third of the people they try out.

<comment><USER32> > or someone with the ability to work two jobs at once for an extended period > of time while you hold your tryout.

This is the part that's crazy to me. If you think you can accurately judge someone based the work they perform _after_ a full normal workday/week, I have some beachfront property on the moon to sell you...

I have a feeling their conversion rate is so low because a lot of people get another offer during their trial and immediately jump ship.

<comment><USER33> > I have a feeling their conversion rate is so low because a lot of people get > another offer during their trial and immediately jump ship.

Or because they're just selecting against good candidates in the first place; if you've got a good job and are performing well elsewhere, you're less likely to jump through that kind of hoop. It's easy to persuade yourself you're hiring the best candidates by being strict about selecting from a pool that is already heavily biased (I'm pretty sure Joel Spolsky wrote something along those lines years ago, so this is hardly a new insight).

</comment></comment></comment></comment></comment><comment><USER34> As someone who has worked at every level of IT (startup to Fortune 500 executive), hired thousands of people, and personally interviewed hundreds of candidates of all levels of experience, the conclusion I have come to is that interviews are almost entirely worthless.

</comment><comment><USER35> It's interesting, because I'd argue that the best companies in tech have have interviews that are _very_ structured and predictable.

<comment><USER36> Is that true? Isn't the generic accusation against AmaGooFaceSoft that your interview performance largely depends on whether you happened to study some interviewer's pet topic (e.g. parallelism, dynamic programming, networking, etc.)?

<comment><USER25> Having done interviews at a few of time, I'd say that's mostly false, at least for the last 2-3 years.

As far as I can tell, there's always a pre-defined pool of questions. Some of them are pretty 'open ended', but still targeted towards getting a good impression of a certain area of knowledge.

That being said, I had an interview with Google at some point in the past where one of the interviewers almost seemed appalled that I didn't know the exact list of items that can be found in a filesystem superblock. But at all other companies it seemed a bit more sane. I guess it's partially a function of the type of personalities a company is willing to hire :)

<comment><USER37> Recently I failed an interview at Facebook because I chose to serialize a binary tree into a list of N items, rather than a list of N items and O(N) sentinels. Most of the interview was spent convincing the interviewer that this could possibly be correct.

<comment><USER38> i recently failed a programming test after acing all tests except one where i needed a text diff and pulled in a library instead of writing my own in less then ten minutes. they said i need to get better at algos. which is fair. but i dont know anyone that can program a decent working text diff in less then ten minutes.

<comment><USER39> Based on your description, it sounds possible they were just looking for a Levenshtein distance implementation, which is definitely in the Universal Weird Corpus of Interview Questions and for which people who prepare for interviews a ton would have a good shot.

</comment></comment></comment></comment></comment></comment><comment><USER40> When interviewing for smaller orgs you do have to answer the question: can I work with this person everyday? Subjective and arguably harder to predict than technical performance, and oftentimes more important.

</comment><comment> m-j-fox Known useless indicators:

* Resumes

* Skills tests (hacker rank)

* Whiteboard interviews

* Unstructured interviews

* Employee referrals

No wonder headhunters have such a good business. Not that they're more discriminating, but they can pretend to be the solution to an intractable problem.

<comment><USER41> I agree with most, but referrals are one of the most important indicators. "A hire As, B hire Cs". A known issue, however, is the workforce diverse given the heavy use of referral methods.

<comment> m-j-fox All my referral tells you is I have a friend who needs a job and that I want $5000. Whether my friend is any good or not is something you'll find out after I cash my check.

</comment></comment></comment><comment><USER42> The traditional recruiting and hiring process is broken. I say this as a former technical recruiter. I wrote about the problems of recruiting for a closed-source startup here:

[https://www.linkedin.com/in/chrisvnicholson/recent- activity/...](https://www.linkedin.com/in/chrisvnicholson/recent- activity/posts/)

I mention closed-source for a reason. For technical hiring, there is nothing better than open source. Open-source projects allow engineers and their potential employers to collaborate in depth over time. The company can experience whether the engineer is competent, reliable and friendly. The engineer can judge the team's merits in the same way. And they can both decide whether the fit is right.

Closed-source and/or non-engineering jobs are the opposite. You get a resume, a Github repo if you're lucky, and a half-day's worth of interviews and tests. Then you roll the dice on that imperfect information.

This is one reason why a lot of recruiting and hiring happens through the networks of people that a company can tap into. It may seem corrupt or nepotistic, but the advantage of those referrals is that someone with more information than you is willing to stake their reputation on a candidate's performance.

Large companies with lots of historical data have the opportunity to train algorithms to learn how job applications and long-term performance/flight risk/etc. actually correlate. From what I can tell, most haven't.

<comment><USER43> Hiring candidates through interviews or through known contacts list is just about taking a chance. There are several unknowns which can only come out in the course of time.

I agree with vonnik, that running the Project in Open Source definitely has an edge in the interviewing process. The potential employee has already seen your code (or you can make sure that he has), knows what he/she is getting into. I would seek for some links of their contributions to other projects which will help me evaluate if their code.

Of-course less than 5% of the job applicants now have had the opportunity to develop for open source. (Either the folks contributing in the open source love their job so much, that they hardly look around or they are already being offered jobs without looking..).

</comment></comment><comment><USER44> It's not surprising. Employee selection is basically voodoo. Outcomes don't get fed back into redesign of the process, and the process is far more based in tradition than data. When the process gets challenged it's ripe to fall apart.

<comment><USER45> The sample size is too small to do any useful feedback and humans are too complex to be mapped/binned in the way interviews attempt to do. Not only that but things that happen after hiring may have a bigger influence on the success/failure of the hire than the factors the interview is looking for. E.g. who you end up working with, internal politics, the specifics of the job.

Kahenman's work on the illusion of validity comes to mind. It kind of boils down to our hiring process must be right because we're doing it.

</comment></comment><comment><USER46> As someone with many interviews coming up in the near future, this scares me. It's easy to get in a self-conscious feedback loop when you know every behavior, response, and gesture is being fed into a fundamentally irrational character-judging process.

The best interview I've ever been on was one for a young startup. They gave essentially a homework problem, a day to solve it, and then in the interview we talked about the problem and my solution. The worst interview I've been on was sitting in front of multiple engineers as each one threw out a random CS question (from seemingly the entire space of CS) and asked me to talk intelligently about it. When I seemed unsure of myself, they glanced around nervously and disapprovingly.

Interviews are the worst. I've spent my time trying to bolster my OSS projects, so that I can point to them as evidence of my competence, but I can't help but prepare for the worst anyways.

<comment><USER47> "...fundamentally irrational character-judging process" is really the wrong impression to go into interview with as a candidate. Seriously, you will handicap yourself if you see it this way.

Competency is only one component of a hiring decision. After some base threshold of competency, the question then becomes whether or not you, the candidate, is going to be someone that the team WANTS to work with.

Bolstering your OSS projects is fine but you'll get a better return on investment for your time to practice "behavioral interview" questions. This is absolutely the hardest type of interview but in the hands of experienced hiring managers it works better than any other technique, IMHO.

If you can find an experienced mentor who will do mock behavioral interviews with you and give you honest constructive feedback, that will boost your interview skills more than anything else.

<comment><USER46> Good advice, thanks. My experience so far has been difficulty appearing confident on the technical portions of the interviews. Other devs seem to sense blood in the water when nerves and shyness have you fumbling through whiteboarding obscure topics.

</comment></comment></comment><comment><USER48> They're useless if it's attempt to prove you know more tham them about some algorithm that's been implemented 150x times (every job interview in California). I'd rather work with someone pleasent, hard working, and concerned with everyone's well being.

<comment><USER49> Hell, all I want is someone that could easily learn and understand an algo they're not already familiar with if needed. I remember being asked to basically implement the Day-Stout-Warren algorithm in an interview a few years ago and wondering what that person really learned about me from that memorization exercise.

</comment></comment><comment><USER50> Articles like this - and the comments that follow - always overlook the primary value of job interviews, which to me is answering the question: "Do I want to work for this company?"

<comment><USER51> Sure, because poor management, crippling technical debt, and a toxic work environment are totally plainly presented to you in an interview. /s

<comment><USER50> Not plainly, no, but easily inferred.

<comment><USER51> You should publish because I know I and a lot of other people would be incredibly interested in divining this information during a job interview.

<comment><USER52> The best I've come up with is a few proxies, like their deployment process. Someone doing continuous or frequent deployments probably have pretty decent code quality. A company that takes several weeks, several rounds of QA and a dozen release documents that need to be signed in triplicate, they have that process because they've been burned and need scapegoats when the inevitable happens.

The best part is that most people at companies like this aren't aware that it's not normal, so they'll be open about it.

<comment><USER50> Yeah, that's basically all it takes. Talk to engineers about their everyday processes. (If the company doesn't let you talk to their engineers during the interview process, or if they're unwilling to discuss, consider that the huge red flag).

</comment></comment></comment></comment></comment></comment><comment><USER53> All that this article says is that past performance, in terms of GPA, is the best performance of future performance - rather than a 30 minute interview predicting future performance. This sees like a basic truism to me and the main lesson that tech hiring processes can take away from this article.

In my experience (having hired > 100 engineers) one of the basic problems that tech hiring, as a whole, has is that it misunderstands the point of a technical interview. Organizations and hiring managers see the interview process as a way of improving the brand of the engineering organization - "We have super high standards and to prove this our interview process is really hard - therefore if you think you meet these standards you should apply". This leads to the current interviewing trends of super academic/puzzle/esoteric technology based interviews. Applicants leave those interviews saying that it was super hard reinforcing the brand messaging (classic marketing).

Rather, in my experience, the best results come from viewing the hiring/interviewing process for what it is - an attempt to predict future performance (and specifically performance at your organization) using a variety of techniques which interviewing is one. In this context, of attempting to predict future performance, interviews are not a great tool - better to look at specific past performance.

Past performance is always the best predictor of future performance and the point of a technical interview, in my mind, is to critically inspect that past performance to understand how closely it relates to the future performance that your organization needs.

</comment><comment><USER54> My basic problem with interviewing is you are observing behavior in one sort of situation, and on that basis trying to predict behavior in a very different sort of situation, namely job performance, which is actually a whole bundle of different types of situations.

It seems like it would be much better to instead put the job prospect in situations that model the sorts that would come up at work.

</comment><comment><USER55> I wonder if we can extrapolate to marriages and to how arranged marriages (at least in India) having a higher success rate. Usually the parents on either side decide on a match based on family background, financial stability, education background etc,. rather than letting the to-be married decide.

<comment><USER56> What is 'success'?

My evidence is anecdotal, but I've spoken with multiple Indian women who are in arranged marriages, have zero real love in the relationship, and aren't particularly happy, but the idea of divorce is entirely unthinkable to them. The lack of divorce probably makes this a 'success' by most metrics, but doesn't seem particularly successful to me.

</comment></comment><comment><USER57> > In one experiment, we had student subjects interview other students and then > predict their grade point averages for the following semester.

Not sure how using inexperienced interviewers proves anything. Would have been more interesting to have lecturers interview the students.

<comment><USER58> There's a reference in the article that covers that kind of scenario.

      The additional 50 students that the school interviewed but
      initially rejected, did just as well as their other
      classmates in terms of attrition, academic performance,
      clinical performance, and honors earned.

</comment></comment><comment><USER59> I am a recruiter. Recently, I started working with a new employer. We could not get anyone through their interview process. Eventually I asked the HR person to clarify precisely what was being asked in these interviews.

She said that, essentially, the interviews were ad-hoc, with the interviewer just coming up with whatever questions they thought relevant based on the resume - often asking the candidate to go through their career history.

I explained that the only effective approach I have found with recruiting is to have a set of pre-defined questions, and each question is specifically designed to give insight into how the candidate meets the pre-defined job requirements. Very much like software development, where test cases are related to software requirements.

I explained also that it is not critical to stick precisely to these questions, but that should mostly be the case - interviews are human interactions and some flexibility is required depending on circumstance.

The HR person then explained this to the hiring managers at the company, and worked with the hiring managers to define interview questions that give insight into the job requirements.

The next two people interviewed got the jobs, after months of no one getting through the interviews.

In the early days of software development, the business was often dissatisfied with software delivered because it simply did not meet the requirements of the business. So the software development process matured and came up with the idea of tests that can be mapped back to the requirements via a requirements traceability matrix. Thus the business has a requirement, the developers write code to meet the requirement, and a test is designed to verify that the software meets the defined requirement.

Recruiting currently has no such general understanding in place of the relationship between job position requirements and definition of quantifiable questions that identify to what extent a given job candidate meets a requirement.

Once you get your head around the idea that recruiting should be very similar to software development in this regard, then it is easy to see that ad-hoc interviews do nothing to verify in any organised way to what extent a candidate meets the requirements of a given job opening.

<comment><USER52> > I explained that the only effective approach I have found with recruiting is > to have a set of pre-defined questions, and each question is specifically > designed to give insight into how the candidate meets the pre-defined job > requirements. Very much like software development, where test cases are > related to software requirements.

This creates a system that can be gamed though. The interviewees can pass this information back to the recruiter and the recruiter can couch future interviewees. The recruiter has a vested interest in placing people.

It would be better to have a thousand questions that are randomly selected.

</comment></comment><comment><USER60> You hear lots of these stories about stupid interviews. You rarely hear the stories about the horrible, terrible employees that weren't weeded out, got hired and did great harm to the company and their coworkers.

Interviews can be good and bad, I'd venture to say that many the horrible hire has been avoided by any interview at all. Thus, don't make perfect the enemy of good, and try to improve on good.

The set of potential bad hires is vast compared to the good hires, and that ratio is only remedied by good filtering before and during the interview.

<comment><USER61> > You rarely hear the stories about the horrible, terrible employees that > weren't weeded out, got hired and did great harm to the company and their > coworkers.

Actually, stories about horrible co-workers that weren't weeded out by interview or any other hiring process are quite common workplace stories in every field, including tech.

</comment></comment><comment><USER62> One thing interviews can't select for: creativity and motivation. And in tech those two criteria are the most vital, especially motivation. I can easily fill in the skills gap in someone who's motivated. I can't do anything with someone who doesn't give a shit, even if they're the second coming of Albert Einstein. So folks, please, don't apply for jobs you don't really care about. Save yourself and your prospective employer time, aggravation, and the opportunity cost.

<comment><USER23> I find it unfair that you're downvoted. I mostly agree with you.

However, "don't apply for jobs you don't really care about" is a very 50/50 advice. Right now I have _zero_ money reserves. If I somehow got fired tomorrow, I'll be in the red even after 2 days of unemployment. So sometimes you have to make a hard choice.

That being said, it's good to be open about this after you get your act together months later and decide what to do with your current employer, during a lunch for example.

<comment><USER62> Well, don't wait to get fired then. Find a better paying job you like and go for it. It doesn't seem like you have much to lose anyway, and the best way to increase your paycheck is by moving around and not letting employers take you for granted. Just don't sell your soul for a buck in the process. This game is a marathon, and grinding it out never really works in the long term.

<comment><USER23> I fully agree, and that's exactly what I am doing -- even if an offer from another company ends up only being a leverage to force a raise in my current company (see below for clarification). However, I am taking it slow and I am patient (even though NOT being able to randomly go to the cinema or a restaurant with my girlfriend is getting on the nerves of both of us lately; money is tight and I'm very unhappy with my current compensation) because I don't want to replace one problem with the same problem in another company. So I am picky, I am clear in my requirements, I don't accept terms I know will make me hate the job, and I am perfecting my negotiating skills during this entire process.

CLARIFICATION on the leverage remark: it's my opinion that 99% of the time leveraging an offer from another company that wants to give you more money, to make your old company give you more money, is a _huge mistake_. Most businessmen HATE being strong-armed, or, to use a milder language, hate being shown that their employees have power over them, and this makes them hate you even if they very much need you in a business sense. They end up actively looking for a way to get rid of you, even if it costs them more money and/or stress in the long-term. I've witnessed it.

SOURCE: 4 of my stupider younger acquantainces from 7-12 years in the past. And an observation from my first job. After I "strong-armed" my first employer to double my then pretty measly salary, he went on a hunt to replace me (even though it took him around a year to really do it), but I was smart enough to detect the signs and resigned long before he had the chance. No regrets.

</comment></comment></comment></comment><comment><USER63> No interview will tell you the future, so to my mind, the only thing the interview can tell you immediately is how much someone knows and whether their personality will mesh with the company's culture.

In order to ascertain this, I propose job-hiring hackathons. Have the company hold a mini-hackathon, once every 2 weeks or once a month, where all job applicants must show up and work on projects (corporate employees' presence can be optional). Just watch them complete the projects and hire the best candidates.

</comment><comment><USER64> I believe a lot of places hire a candidate through a consensus, meaning some members in the team accept or reject a potential candidate. When enough accept the candidate, the hiring is done.

Is there any company that tracks who rejects a particular candidate during an interview process, and how often that negative feedback turned out to be true. I guess with the turnover rate at todays tech places, such tracking of a record of an interviewer is not really possible?

I always wonder about this.

</comment><comment><USER65> Structured interviews are better than unstructured ones, but in my experience they are really a Trojan horse for the idea that interviews in all forms are largely worthless (as predictors for good hiring).

Once you start collecting data on your hiring pipeline work sample hiring becomes so much obviously better that it makes little sense to spend the time to do the hard work of making a good structured interview process.

</comment><comment><USER66> We had 2 slackers on the team. One jumped directly to Google.

The other jumped around for few years, got laid off by some company, recently joined FB.

<comment><USER67> One of the most incompetent developers I've ever known got hired at Facebook, then Apple. Every line of code the guy right was just...exceptionally bad and poorly thought out.

I guess he was good at whiteboard exercises, though?

</comment></comment><comment><USER68> Odd - I was trained to do competence based interviews 20 years ago, apparently this is now rediscovered knowledge or something!

</comment><comment><USER69> > So great is people's confidence in their ability to glean valuable > information from a face to face conversation that they feel they can do so > even if they know they are not being dealt with squarely. But they are > wrong.

If people utterly refuse to learn from proven mistakes, then all hope is lost. Einstein was right, human stupidity is infinite.

</comment><comment><USER70> I'm sure it has been discussed before, but what factors push people away from say two-day internships? Is it because these things are so short that they too can eventually be gamed? Or is it because you need to have staff of the same specialty dedicating their resources to a potentially short-lived investment?

</comment><comment><USER71> The problem is that most people have no training in how exactly to interview someone. It's like asking people with no training in building rockets to get you to the Moon and then deciding that because because they failed tickets are "utterly useless".

</comment><comment><USER72> It certainly does feel like job interviews are a coin flip to me after having done many interviews.

</comment><comment> mck- If you care about your company's culture, a person's humbleness, art of concise debating, etc - more important parameters than sheer GPA or coding skills imho - you can never do away with in-person interviews.

Calling them "utterly useless" is an utter click-bait.

</comment><comment><USER73> > Alternatively, you can use interviews to test job-related skills, rather > than idly chatting or asking personal questions.

Alternatively? How is this not the focus of an interview?

Sure, confidence and social skills are important, but obviously they cannot predict a person's actual ability.

</comment><comment><USER74> The issue with silicon valley interviews is that it's leading a new paradigm of management styles that deal with knowledge and creative work

This shift MUST be accepted by everybody ornostracism is risked. (Like trump supporters)

But paradigm shifts take time and the majority of managers still want cogs. But instead of filtering dor cogs they have to dress the filters up as filtering for a "i give smart people freedom team" and the convoluted mental gymnastics needed for this creates shitty interview processes.

All "well this technique worked for us" stories are mostly Not useful because tehy are just N=1 stories about managers using their preferred filters.

The issue isn't with the filters themselves (all sorts exist) but with a culture that obligates everyone to out on false facades.

People who just want to be paid and can work well need to pretend to be passionate. Managers who want well-paid cogs need to pretend to promote individualistic thinking etc...

</comment><comment><USER75> More accurately, the article is about the use of _unstructured_ free-form interviews.

</comment><comment><USER76> It is some time we are going towards word of mouth and peer recommendations as the preferred way to hire new personnel. Cold applications are for outsiders and as such a very different market, with all the strings and the bulls.it attached.

</comment><comment><USER77> Well, the worst interview I've ever had was the ones where the interviewer wouldn't deviate from the script, even after he recognized that these questions made no sense for someone with my background (I was self-taught, and had never managed my own memory or written a sort algorithm. They were also irrelevant to the position in question).

It was painfully awkward.

It was also a fantastic way to accidentally discriminate against women and older candidates.

I'm not saying anyone should conduct an interview completely by the seat of their pants, but please don't encourage this foolish consistency.

</comment><comment><USER78> Does it bother anyone else that the example given in the article (showing up 25 minutes late) is judging interviewing by its worst rather than its best?

</comment><comment><USER79> I'm coming late to this discussion, but there is one point I'd like to make. Our "interviews" in the world of software engineering, are immensely different from "interviews" in the standard sense of the word.

I've worked in different fields, and I talk to people who work in other fields. Most of those fields work in a way that is described in this article - interviews are question and answer sessions, where people are evaluated by a number of highly subjective criteria. "Tell me about your fundraising experience?" "How do you deal with difficult clients or coworkers". That kind of thing.

Software interviews are exams. They're not "more like" exams, they are flat out exams. There is very little banter. The closest I've come in google and Netflix interviews has been the more open-ended system design style question they often put in there, but even that has an academic test quality to it.

It's pretty much 5 hours of technical exam. "How do you find all matching subtrees in a binary tree" might be a question - and you really are expected to get it written at the whiteboard. "Find all permutations of a set". "Find all square sub matrices in an NXM matrix." The "top" companies are good at modifying the question so that you must know how to do this but can't just regurgitate it.

Alternatively, you may do a "take home" exam. Most recently, I did a mini rails project. I actually liked my result, I kind of enjoyed writing it. However, it was a no-hire, one reason given was that my routing was non- standard. True. I hadn't really thought about it, it was a take-home, so I mainly focused on the UI and code, and just chucked in a couple of named routes for demo and testing purposes. The other reason was that there was some duplicate code (I disagreed and had a reason for this, but there is no chance to defend your code, you write it and send it in, and they say "no hire").

I have no idea if it was a real piece of crap and they were just being nice. It had 100% test coverage and git for version control, and implemented a few features. Unfortunately, like I said, I never got a chance to defend the code.

Our processes in high tech are badly broken. I'm probably done interviewing, my next job will have to be one that doesn't involve a software interview. The routing and duplicate code, along with a google interview, pretty much sealed the deal for me.

My advice to people is (this isn't my idea) be an X that programs, not an X programmer. Coding is an amazing tool for a job, but avoid making it your job. For instance, I actually know a fundraiser who does a lot of data science, and he's a rock star in his field, but I guarantee you nobody asks him to reverse a binary tree in an interview!

Best of luck out there. Our interviewing processes are their own special version of horridness, just not uselessness described here.

</comment><comment><USER80> How do you know that the person you'll be marrying won't cheat on you and won't leave you in hard times? If you apply the methods we use today for interviews you'll end up with a 50/50 chance at best, a coin toss.

Yet why do some marriages last forever (till death do us apart) while others fail miserably or crumble even after 20 years?

The search for the global optimum cannot be performed by asking a set of questions. I argue that it cannot be done consciously. It's gut/instinct thing. If you have a mechanical approach, anyone can game the system and get a job because humans can be like chameleons to present themselves as the right candidate, and they can study for the interview. Only way IMO is to have that 3rd eye or whatever you call it... instinct, gut feeling, etc

The problem with this conclusion is that instinct and sexism/racism are often conflated.

No good answer.

<comment><USER81> This article is critiquing the unstructured get-to-know you interview. It is not critiquing highly structured interviews with clear goals, nor technical challenges, nor references checks or past performance.

In your example, how would you structure a series of questions and procedures to limit the risk of marrying someone who will abandon you or cheat on you? I think you can apply good interview process techniques to this quite well!

1\. Have they been divorced or cheated on someone before? People who have been divorced before are much more likely to divorce again. The 50% divorce rate in the US is slightly misleading, as many of the divorces are concentrated in repeat divorcees. In fact, among younger (early to mid twenties) first-time marriages, the divorce rate plummets to something like 15-20%.

2\. Have their parents been divorced or cheated? Children of divorced parents are much more likely to get divorced themselves.

3\. Have they been physically, emotionally, or sexually abused as a child? People with traumatic early childhood experiences are much more likely to develop trust issues with long-term partners, especially if they never had extensive counseling.

4\. Do they have a good relationship with their family? People who have a difficult or unstable relationship with multiple family members are more likely to see tumultuous relationships as a norm.

This is all equivalent to reference checks in a job.

Then a long dating / engagement period is necessary. How do you they treat you during this period? Do they cheat? Are they abusive? Do they leave you during a period of difficulty? Do you have the same religious views? Do you split housework evenly? Do you both want kids? How do you view money? The three most common reasons for a fight among couples are 1) money, 2) housework, 3) free time (and how to spend it).

People who are otherwise happy and well-adjusted adults who get married and then divorce bitterly after 10 years are not the norm. Most divorces can be predicted. And most divorces happen before 2 years of marriage. If you are aware of the warning signs and are not blinded by a "gut instinct" I think you can definitely minimize the potential for marrying a snake -in-the-grass.

<comment><USER82> The trouble with this advice is that, while it's accurate if your one and only goal is to predict the likelihood of someone divorcing or cheating on you, it seems profoundly unfair.

To examine this "unfairness", let's imagine it at its most extreme: a society in which divorcees are so stigmatized that it's practically impossible to ever re-marry; in which children of divorcees are likewise stigmatized; in which victims of child-abuse are further victimized by a society that considers them potential "snakes-in-the-grass". Do we really want to live in such a society?

Obviously I don't think you were advocating this. But it's a thought experiment which demonstrates a classic class of problem: what's good for the individual isn't always good for society, especially taken to extremes.

<comment><USER83> Isn't that true for any system you use to predict? If you rely on "gut instinct", then you filter out people who aren't good at fooling gut instinct. Ugly people, short people, people with poor social skills, autistics, etc. That's hardly fair either.

If you want to make the most accurate predictions possible, you absolutely should not use gut instinct. If you want to be fair, then have a lottery or select randomly. You can't have both. There's nothing remotely fair about gut instinct. See, e.g. judges giving unattractive people twice the sentences of attractive ones. I can provide tons more examples of stuff like that. Gut instinct should be illegal.

</comment></comment></comment></comment><comment><USER84> But surely structured interviews just test a candidate's ability to improvise plausible stories? Whether they are truthful or not is a different matter..

<comment><USER85> Structured interviews improve the ability to systematically test the relationship between policy and results. Real experiments are then possible.

As opposed to a situation where your interviewers are asking off-the-cuff questions, and you're uncertain whether the questions have a systematic bias toward a bad direction -- racism, sexism, or just selecting for something idiosyncratic that adds unnecessary constraint to your candidacy pool. You also now don't know whether it's your policy that's systematically bad (or good!), or that your interviewers are systematically bad.

<comment><USER19> And yet unstructured interviewing basically works and the world keeps spinning. If 'random' truly was a better result (as the article suggests), then in a hiring round for a programmer last year, we might have discarded our candidate that won and is awesome for the one that _couldn 't conceptually 'get'_ FizzBuzz.

Or put another way: if 'random' was better than 'unstructured', you'd never have a round of hiring where there were _no_ unsuitable candidates - one will have been chosen.

<comment><USER84> Better to give someone a job related task perhaps?

</comment></comment></comment></comment><comment><USER86> i have an interview with apple for a mechanical engineer. i will report back once its done.

<comment><USER23> Please do. I'll be watching for your response to this message.

</comment></comment><comment><USER87> Such a careless claim and writing articles and throwing on peoples faces gives just a chance to everyone to debunk ny times articles

</comment><comment><USER88> Once we get to the point where most people have several jobs with separate contracts, interviews become superfluous because you can just hire someone for a few hours at a time and then fire them. The only reason that doesn't work today is we're still clinging to the idea that you only work for one entity at a time. Never mind that most people already manage at least a couple bosses within the same company.

<comment><USER89> I've done a bunch of consulting and contract work, and that can be fine. But it's expensive, because to be continually finding new work, you must continuously invest in marketing, and every time you do something new there's a lot of switching cost. A company also needs a lot more supervisory capacity to be monitoring people who come and go, so it's not cheap for companies, either.

It's also limited. I can be much more productive when I do one thing full time than a bunch of things part time. Depth takes time, as does keeping up with changes. You just can't get as far with fractional attention as with serious focus.

And uncertainty is also uncomfortable. Many people just want to settle into a solid, reliable situation and do the work. They want to be able to plan their future with some confidence. Even if they can make more money juggling a variety of things, they'd rather make less and have less chaos.

So I don't think we'll ever get to the point you suggest.

<comment><USER23> You both have a good point.

I too quit my freelancing for a stable remote job but looking at it 18 months later I found out that I sucked a lot in managing my freelancing gigs.

So IMO with some good contract and budget management -- and confidence, and actually having a choice -- you can reap most the benefits of freelancing and almost none of the drawbacks, if you can take the thought of switching customers every 3-6 months.

I understand not everybody can pull this off -- I am not sure I am yet ready to do this that well. But I've seen people doing it very successfully and almost stress-free.

</comment></comment></comment><comment><USER90> > not one interviewer reported noticing that he or she was conducting a random > interview. More striking still, the students who conducted random interviews > rated the degree to which they "got to know" the interviewee slightly higher > on average

Yeah well, when you're asking questions of someone who looks thoughtful very briefly, then answers almost immediately after, it sounds like you might have more reason to think you know them better than the one actually considering their answer

Might be introducing a confound or two that you then _proceed to completely ignore_ and even conclude past lest someone accidentally draw other conclusions</comment>


Mrustc – Alternate Rust compiler in C++ – Now broken the bootstrap chain - <AUTHOR> https://www.reddit.com/r/rust/comments/7lu6di/mrustc_alternate_rust_compiler_in_c_now_broken/ <comment><USER2> Cool.

Is there a good enough rust to wasm compiler available already? I mean other than emscripten or binaryen?

<comment><USER3> rustc includes the LLVM wasm backend.</comment></comment>


Building a command line tool to help with Google searches - <AUTHOR> https://johnlekberg.com/blog/2020-08-15-cli-google.html <comment><USER2> Really handy, thanks for sharing</comment>


Booted Up in 1993, This Server Has Been in Continuous Operation Ever Since - <AUTHOR> http://www.computerworld.com/article/3162416/data-center/booted-up-in-1993-this-server-still-runs-but-not-for-much-longer.html <comment><USER2> It would have been nice if they had given some of the technical specs of the system. After all, it is an article in "computer" world.

<comment><USER3> From /r/sysadmin discussion earlier today:

 _Stratus servers are nuts; got to rip an old one up a long time ago, it had individual batteries backing each hard drive, dual mumble kilowatt main PSUs, etc, etc. all in support of a set of Motorola 68020 cpus and 128mb RAM in 1990 or so._

[https://www.reddit.com/r/sysadmin/comments/5qo1rs/booted_up_...](https://www.reddit.com/r/sysadmin/comments/5qo1rs/booted_up_in_1993_this_server_still_runs_but_not/)</comment></comment>


How Yahoo Blew It - <AUTHOR> http://www.wired.com/wired/archive/15.02/yahoo.html?pg=2&topic=yahoo&topic_set= <comment><USER2> It's an interesting read. One note: you linked to the 2nd page of the article instead of the first.

<comment><AUTHOR> I need to pay closer attention...</comment></comment>