skysight-inc/HackerNews huggingface dataset:
> It seems then that a good solution would be to force many different types of proof of work.

This would create many more opportunities for finding shortcuts like ASCIBOOST. Some of them might be much worse.
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.
> You use the word stack as if it could only possibly apply to one particular type of usage, when that is manifestly not so. Therefore you disrespect your audience in the extreme

HN: where people can't convey opinions without using extreme hyperbole.
Personally, I haven't heard anything about renewed debates related to Spring vs. JEE in many years. And if you read the Gartner report in question[1], it's not about that at all. Hmm. Maybe I'm just cynical, but when I saw he was part of the company behind Spring I thought maybe this was more of a contrived argument. The truth is, framing a debate as Spring vs JEE perhaps stands to benefit both technologies since in many people's minds they are both complex and bloated. It's just about positioning; yes, Spring is "lightweight" compared to traditional JEE, but so is everything!

1. https://www.gartner.com/doc/reprints?id=1-3N8E378&ct=161205&...
I write thrillers. My research showed me how easily terrorists can strike us
Thanks...could you please cite specific examples?
Some interesting info on the OS/2 subsystem is here: https://www.microsoft.com/resources/documentation/windowsnt/....

My favorite part is how NT didn't directly use CONFIG.SYS — but, if you edited C:\CONFIG.SYS from an OS/2 editor, NT would render a "stub" CONFIG.SYS file from the OS/2-specific settings from the Registry; then, when the editor saved the file, it would translate those settings back into appropriate Registry keys!

Another interesting tidbit: Up through NT 4.0, Microsoft sold the "Windows NT Add-On Subsystem for Presentation Manager" that let 16-bit OS/2 GUI apps run on NT.

So much work went into the OS/2 subsystem, but I can't imagine it was important at all to NT's eventual marketplace success.
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.
As far as debugging goes, use KHR_debug extension, as well as RenderDoc or similar tools.
As far as (automated) testing goes, I don't really know any solutions there beyond a "fuzzy" comparison to a set of "known good" images. But the problem is, this only works for regression testing. When implementing something new (say, you want to add reflections to your engine), there isn't anything to compare to, you just have to actually look at it.
Noone is entirely sure exactly when we'll reach level-5 autonomy, however, that doesn't matter for the specter of unemployment - the currently demonstrated level of availability seems clearly enough to put half of truck drivers out of work by all kinds of automation e.g. trucks self-driving on the regulated toll roads during time that drivers have their mandated rest; one driver supervising multiple trucks or driving a column of two-three trucks, etc. This alone is sufficient for both a significant tick in unemployment and as a downward pressure on wages of there low-skill workers that have a job.

The question of "replacing drivers" isn't about when machines will be able to do exactly what drivers do now, it's about when we'll figure out to achieve the same end result with much less labor, likely implementing significant changes to the process.
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.
was it a binary tree or a binary search tree? a BST can be uniquely identified by one of pre/post-order traversal, whereas a binary tree requires an in-order traversal and one other. or placing sentinels that specify a state machine [PUSH_LEFT, PUSH_RIGHT, POP] that specify how to move down and up the tree structure.
I just implemented the reading quiz idea this term, and I thought that it went really well. Give the students a manageable chunk of reading material (in my case, the material came from various sources, not a single textbook), and give them an offline quiz to test their reading comprehension. The quizzes were graded by a TA, but the weight was quite small; small enough not to matter if they cheated (and cheating won't help them in the final exam. Aside: is it cheating if they didn't read the material but just hunted for the answers by skimming?) but enough to provide extra incentive to read.

In class we go over the answers to the quiz. I don't post the answers (the TA will have provided them the feedback they need when grading); rather we make it an interactive session. I answer questions the students have, we go over examples, I supplement the reading with slides if need be. Effectively, a flipped classroom.

This was done more out of necessity: first time teaching the course, no proper textbook (and in a quickly changing tech landscape for the topic at hand), lack of confidence in my own understanding of the material (I also tried gathering student questions beforehand so I could investigate them offline and come to class prepared to answer them), but now I think I'm going to stick to this way of teaching this course in the next installment next year.
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.
The article that I just read following the submitted link was from the perspective of neither, but of someone looking at the hiring process as an observer. The anecdotes are anecdotes and they don't matter except to lighten up a newspaper article for the masses, so we can ignore them - I'm talking about what was actually studied.
I'll put my disclosure up-front: I work for Pivotal on a Cloud Foundry project. Pivotal employs many members of the Spring team. I am not speaking for either Spring or Pivotal.

Both Spring and Java EE are very featuresome because of a long period of evolution across multiple partial paradigm shifts (3-tier, CORBA, Web 1.0, App Containers, SOA, VMs, Web 2.0, Containers...).

I'm personally only familiar with Spring. And by "familiar" I mean I've learnt enough to be dangerous. But I've also learned to ask, before doing something: "Have the Spring team already solved this?"

Take, for example, retrying an operation. A slightly hacky way to achieve this is to nest try-catches. A slightly less hacky way is some sort of loop. Then we extract this functionality out. I dunno, lambdas maybe?

Or: I could use Spring-Retry[0].

That's just one example from my own experience.

It used to be that Java EE was it. And it had to be: the mega-buyers insisted that there were sufficiently rigorous standards that they could switch vendors. Every giant corporation bleeds gold to some ancient vendor and they have an immune reaction, nearly a spasm allergy, to vendor lockin[1].

Opensource tools kinda sail around this, because ... uh ... what vendor lockin? Who has you grasped, by what kind of delicate hair? Nobody. It's opensource. You can wait for community action, or engage a consultancy, or a related product company, or hire specialists, or sponsor something ... you have a wider range of options.

Oh sure, there's tech lockin, but that's true of any decision. Either you exploit the features of a platform and tie yourself to it, or you write a rubber-room abstraction layer and tie yourself to that instead, but at your expense.

In my observation as a 1st? 2nd? party, the Spring team pay close attention to the standards and support them. And, not coincidentally, many standards look -- gee, just awfully similar to something Spring had road-tested a few years prior.

I think a lot of the shade thrown in this debate is happening because of money. Pivotal backs Spring very strongly, because it helps to sell our version of Cloud Foundry (imaginatively: Pivotal Cloud Foundry).

Meanwhile, Oracle owns a lot of Java products, some inherited from Sun, as well as being the stewards of the Java EE standards process. Red Hat own a solid suite of Java EE-capable and platform products, a portfolio largely overlapping with Pivotal's, IBM's and SAP's.

In each of these cases there's a zero-ish sum-ish game underway. A company that bets on Red Hat doesn't bet on IBM. A company going all-in with Oracle (RIP your chequebook) isn't going to buy much from Pivotal.

Meanwhile, the Spring team are just writing software. I lurk some of their internal Slack channels. It's almost exclusively technical and usually very thoughtful. As a Pivot indoctrinated by Pivotal Labs, I appreciate having a very different example of how to develop high-quality software.

[0] https://github.com/spring-projects/spring-retry

[1] You will often find companies accusing each other this.
I think there is a setting to turn the stickiness off and you can switch between windows of the same application with Alt + Tilde. I guess people were impatient with Unity and found it easier to just switch DE's than to try to figure out how to customize it.
Architecturally, how often is there a slam dunk engineering case that the core business logic should handle an obscure protocol or oddball database directly rather than abstracting over the requirements and leaving the implementation details to another layer in the stack?

While Python is not Javascript, 'pip what?'

For SQL: https://pypi.python.org/pypi?%3Aaction=search&term=sql&submi...

For RabbitMQ?: https://pypi.python.org/pypi?%3Aaction=search&term=rabbitmq&...

For Hadoop?: https://pypi.python.org/pypi?%3Aaction=search&term=hadoop&su...

Having PiP (or Quicklisp) does not so much solve the problem as transfer it to a problem in a different domain. The new problem may or may not be easier to solve than the original one. Sometimes Nginx is a good answer. Sometimes SimpleHTTPServer is. Sometimes Sinatra. Sometimes Rails.
To Curb Global Warming, Science Fiction May Become Fact
Yes. This is the reality of distributed computing: most of the problems you want to solve do not have off-the-shelf libraries. Rather, you need to know an algorithm, and various algorithmic-design techniques, well enough that you can decompose it into steps and then recompose steps so that they can be partitioned among many different computers, with appropriate failure modes if machines or network connections go down. That requires intimate knowledge of both the algorithm and of the types of problems you run into in a distributed setting.

MapReduce, Pregel, Bigtable, Flume, etc. are building blocks: they solve some of the distribution problems, but you still need to understand how the algorithms that run on top of them work, on a step-by-step level, to implement on top of them.
Those of us with legs suffer at least 4x more -
The price has been at least partly compensated for by cramming more people in.
“DON” StatusNet Node – Part One: Read Protocols
What about when you know what the concept of big O is, know why it's often touted as important, and disagree that it's as important as it's touted?

My opinion is that big-O often ends up being used as a premature optimization effort hindering "just get the right answer first". Maybe that brute force method will work in a reasonable clock-time cost, despite having egregious algorithmic cost. You won't know if you're busy overengineering and optimizing before you even have a working solution.
I don't see how using FB tools is related to supporting/opposing FB. Can you explain?
Most jobs require 8 hour day. If you add 6 on top of that, plus walk to-from work, that's 15 hours per day on just work. When do you sleep and eat?
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.
I think Wayland development was lagging when Ubuntu started with Mir. That did light a fire under Wayland's behind because it has seen considerable improvement since. The way Canonical handled the announcement of Mir is debatable but I think Mir has been a positive influence as a whole.
> Where scale matters is at big companies. When you already have a lot of customers, you’re first version of any new feature or product must already be at scale. Amazon couldn't have launched a non scalable prime now, or echo. Google can't launch a non scalable chat service, etc.

This is the point I was going to make. When you are designing the very platforms on which all these "does it scale? who cares" startups are going to be built, you do not have the luxury of having that attitude. Definitely don't take that mindset into an interview at google or amazon. :)

I do agree with the OP's sentiment for startup projects in general. I have had the experience of worrying about scale too early and over-engineering a system which never had more than a few dozen users, and the opposite experience of tossing something together that wouldn't scale and then going through the hairy scrambling at every order of magnitude of scale through tens of millions of users. The latter was definitely a better strategy.
Help make HN a better place by engaging constructively, pointing out hyperbole calmly with substantive responses. Commenting with a gross generalization of the HN community as a whole (which you are choosing to participate in) does nothing to improve the discourse on HN.
> I'd argue that a slimmed down , globally deployed implementation of a several decades battle-tested protocol has a lower security risk than some vendor specific, device specific, single-developer self-designed integrity and authenticity scheme.

Is there a TLS client library released in April 2007 or earlier you are comfortable running today?

Is there a data signature checking library released in April 2007 or earlier you are comfortable running today? Note that OpenSSL didn't support TLS 1.1 or 1.2 until OpenSSL 1.0.1 release march 2012

My guess is that if you took the signature checks from an OpenSSL build from 2007, they're either still fine today if you used them separate from the TLS stack, or they're broken enough that you can easily bypass certificate authentication. From a brief look at the openssl vulnerability list, it's also likely that there's a certificate handling bug that you could exploit to bypass the checks anyway.

HTTP may be more complex than necessary, but it travels through firewalls with pretty good ease, and it's not that complex if you speak HTTP 1.0 without transfer-encoding, and only need to understand response headers enough to discard them. HTTP 0.9 is even easier, but some transparent proxies have trouble finding the destination server, so the Host header available in HTTP 1.0 is helpful to ensure requests can be routed. The MVP HTTP 1.0 client is:

int where = 0;
char rnrn[4] = "\r\n\r\n";
int c;
fprintf(fd, "GET %s HTTP/1.0\r\nHost: %s\r\n\r\n", url, host);
shutdown (SHUT_WR, fd);
while (c = read(fd, buf, 1)) {
if (!c) { return -1; } // bad server
if (buf[0] == where[0]) {
++where;
if (where == 4) {
break;
}
} else {
where = 0;
}
}
// here comes the data
// be sure to have a reasonable sized buffer
// and stop reading when its full
// check the signature before you process the data

That's not really that complex (I didn't test the code, it's an illustration). You could also abort without checking the signature if the server sends data beyond your buffer, but the signature check should fail anyway. You could look for a content-length header as well, but header parsing is some amount of work.
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.
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.
Tourists to US may get asked to hand in passwords or be denied entry
The functions arguments are pushed onto the stack. From within the function you can think of the stack as an array.

void test(a, b, c)
stack[0] == a
stack[1] == b
stack[2] == c

But to get the items in the stack in that order you have to...

puch c
push b
push a

If you wanted to do that, and still allow for left to right evaluation you could...

temp_a = a
temp_b = b
temp_c = c

push c
puch b
push a

That would be 2x instructions for every (already expensive at that time) function call. Defining unordered evaluation as UB was to avoid having to do temp_a, temp_b, temp_c. Now compiles can do that and trivially optimize that sort of thing out.
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.
You're right, it's not; I was just showing the smallest code. :)

This is unsafe specifically because of the mutable static; you can deal with that in a few different ways, but that wasn't the point of the example.
Careful. First and most obviously, the "pool of questions" concept is structured only if you have a Google-scale volume of candidates and reliably assigning specific subsets of those questions to candidates.

But even then, for such a process to be rigorously structured, the questions themselves need to be determined a priori and without reference to the candidates background or preferences. Otherwise:

* You're subject to the interviewers and judges (probably subconscious) biases about the merits of different questions.

* You're more exposed to the candidates own innate ability to interview well by navigating themselves to more easily-answered questions.
Miami’s fight against rising seas
> I bought $70 books for my master's courses in Sweden that would have been $300 in the US (where I did my undergrad). The "invisible hand" of capitalism at work!

I personally believe free markets ("invisible hand" of capitalism) work well in nearly all cases (yes, there exist cases of market failure, but these are IMHO rare). The problem rather is that copyright laws prevent a free market, since the copyright holder has a monopoly (i.e. opposite of free market) on the work.
Intel's QuickAssist is about to be standard on Xeon E5 chipsets and can do very high scale gzip at the cost of a PCIe round trip. Intel published some patches to ZoL for this.
Location: London, UK

Remote: yes

Willing to relocate: no

Technologies: React, Redux, Node, Express, Firebase, Git, JavaScript, HTML, CSS

Résumé/CV: https://www.linkedin.com/in/antony-kwok/

Email: hello@antonykwok.com
It ensures they have the basic: writing code. That you can learn alone on your computer when you are 15. That's entry level developer.

The part where you make large software, working in teams, to serve real users, can only be learnt on a job.

These competitions are not looking for anything fancy. They recruit juniors, they'll be trained on the job.
The idea that some children do homework until midnight is fact. The idea that all children do was not suggested anywhere here.

The idea that children should do homework until midnight is stupid, and instances quite arguably a bug report against the educational system in question. No one has asserted that that is all systems.
> You would think that with all that incredible detail, the pathfinding AI would not kill the framerate just from two dozen pastured sheep all trying to find their next clump of grass to eat.

Dwarf Fortress is kind of the ur-example of passionately solving the wrong problem.

It's a fantastic game, and it's heartbreaking to me how much more fantastic it could be if the author adjusted his priorities a bit.
Similar music can be made purely by using computers, but what's inside computers today is digital, while all this gear was analog. Also, the physical interface of all those synths can not yet be reproduced inside a computer, that's still dependent on outboard gear or simulations such as graphical buttons/sliders, etc.

There's been a huge resurgence of modular synthesizers and analog gear in the last decade or so, as people appreciate their advantages over trying to do everything on a computer.