skysight-inc/HackerNews huggingface dataset:
Here's an idea for how to actually do a technical test (if you do want to do one).

1. You bring the candidate in to your office. You have their future desk already available with computer and development environment already functional. Pick a somewhat standard environment configuration.

2. Have an exercise already prepared. Best option is not a "build this from scratch" but have something that already works and needs some additional feature. Something small that could be done in, at most, an hour. Another option is two or three smaller tasks that together would take as long.

3. You give the candidate incomplete information. You describe the task clearly and in a mostly complete way, but leave out a number of details.

4. Very clearly explain these things. One: You won't be on them; this is not pair programming and they should feel at ease and free to do however they want. But you will be sitting in the next desk and you will be doing something unimportant so they can -and should- ask you anything and all they want. They can also use S.O. or whatever search service they want but you'd prefer that they asked you first. Two: You won't be looking at their code unless they want to show you. Three: they have around one hour, but time doesn't matter that much. If giving out more than a single task, indicate that they won't be judged by how many they manage to finish.

5. During that time, you focus on the questions they ask you. What they ask, how they ask them, which problems they face, what things they do or don't understand. This is the key. This is what will tell you about how they think, what things they know and which ones they don't. Keep an eye on them, if they seem too quiet you can interrupt them with simple "how's it going?" or "something wrong?", but don't push it too much so that you don't stress them. You may even suggest a 5 minute break for a coffee/water half-way through if you feel they might need it.

6. The whole idea is to get them to do some task but more importantly to get them to talk about it. When they are done, or when enough time has gone by, don't go over their code. Instead, ask them how it went, what they managed to do, if they got stuck. If they got it running, they can run it. If they want, they can show you the code or part of it. but you don't need to focus on that. Focus on their talk.

7. Finally, do offer them the option of showing the code. But then, get them to show it and explain it. Don't just go over it yourself.

8. The task(s) should be adequate and reasonable for the role, of course. But try to lean on the easier side more than on the harder one. And remember: do leave some information out. The task should be clearly understood but not finely detailed so that they will need to ask and maybe even make some decisions. (You can make them have to decide something by giving them more than one option as answer to some question.)
Just reading source code is a whole different experience than actually implementing something yourself. Implementing something pretty much forces you to "be right" in your understanding, while reading can be anything from "really studying" to skimming.
I wonder how you avoid it devolving into feudalism, it doesn't seem like a system that can hold itself in place.
What's your effective day rate using on an average project based price if you don't mind sharing?
A good manager will use metrics as information to help in assessment of work, not as the sole measurement. Very important for any manager to coach is the real organizational concern behind the number.

If you’ve got more that n=5 things, at a certain point you _need_ metrics to make sense of how things are going. Are we getting our product to customers when they want it (OTD)? Being able to say, yes 90% of the time is very helpful compared to saying “who knows, we don’t do metrics here.”
Based on personal impressions, I think Switzerland is a good example of distributism. Much attention is given to the Swiss banks and the "gold" but in reality, IMO, the strength of the Swiss economy lies in the small & medium business sector.

There are over 300K businesses classes as SMBs in Switzerland, many of them family owned. For a country of 8 million people that means one SMB per 26 people. There are few "high street chains" aside from the supermarkets - unlike the UK for example where the high street of most towns and cities looks the same.

According to this article - https://www.thelocal.ch/20171114/report-swiss-are-richer-tha... - 63 percent of Swiss adults have financial assets above $100,000 which means, although there is a small percent of extremely wealthy people, there's a good distribution of wealth.

That in turn means if you want to start a business here, there are plenty of potential customers with disposable income they might be willing to risk on your product or service.
It appears to have been done full-time, and a lot of shortcuts have been taken. I would say the main achievement is maintaining determination for that period of time without doing so as part of employment or a course of learning.
sing Happy Birthday to the lion
I had a C= 64, but didn't know it ran Microsoft Basic. All I saw was "all rights reserved" and "32kb ram ready".
It would get you averages or the salaries of people whose marketability you don't know.

It doesn't get you "Hey! That bozo now earns £20K more than me"
I never understood these arguments. Isn't it like claiming self-driving cars via neural networks would never be possible because you can't test that the neural network would take the correct decision in every situation?

I view the whole issue stochastically, with the immediate aim being to make (significantly) fewer errors than the current approach, which is having a human decide. I don't claim that I can design an experiment which could selve as an indication whether we are improving upon human judgments, but I think this should be the goal.

Reflecting upon my view, i think it comes from the experience of training ml-algorithms. You are always minimizing errors, but you goal is almost never to make 0 errors, because often your data is noisy and you are probably overfitting. I know the medical enviroments are more sensitive, but I can't really wrap my head around how we could design a learning algorithms that does not make any error and works on all abnormalies. I think it will always missclassify.

Rephrasing my argument: I think the approval should be given if an significant expected improvement over the distribution of real-life abnormalies can be detected and not over the uniform-dsitribution over all abnormalies.

EDIT: detecting out-of-distribution samples is hard and I don't think this is a solution and leads to a false sense of security.
For the Successful Future of AI, Women Have to Take the Lead
Why UX Design Must Be the Foundation of Your Software Product
> The combination of C++ and OpenGL is really the ultimate in portability.

Wouldn't the credit belong to Magnum rather that C++ plus OpenGL, given the tremendous amount of work that goes into making things seem portable to the end user of the library?
Firefox > Reader View

Save your eyes.
> "Further, some distributists argue that socialism is the logical conclusion of capitalism, as capitalism's concentrated powers eventually capture the state, resulting in a form of socialism"

This greatly resembles Karl Marx's criticism of capitalism, which has failed to hold up to reality so far.

Frankly, this sounds a lot like repackaged socialism using labor unions and guilds rather than a central government. Might not be as bad a state socialism (i.e. they might actually be able to manage the businesses better), but I sincerely doubt it would solve any of the major problems we see today.

While you do have inequality in capitalist systems the "elites" tend to rotate, with empires falling apart and new ones taking their place. Wealthy families maintaining their wealth and power are the exception and not the norm.

Introducing guilds or more unions will likely make it much harder for competition and innovation to thrive, introducing a huge barrier of bureaucracy interested only in maintaining the status quo for their own benefit.
When I do interviews I try to give good feedback. My goal is that in 2 or 3 years if the candidate is interested in working with us again that they will certainly pass the interview. However, "You are not a good match for our company culture" is feedback I've definitely given and it's a bit hard to give details.

There are a couple of main things. Usually when I have this issue it's because the candidate seems really keen to do things or have things that we just don't offer. For example, "Every piece of code must be a micro service". Some of our code works that way but lots doesn't and we aren't going to change it. Another example might be a very junior person saying, "I want to be the scrum master". Well, we don't do scrum master in our team and even if we did, we would be unlikely to pick that person.

Basically, "You aren't a good match to our company culture" is saying "I really think you would be very unhappy here based on your responses". Again, I try to explain if I can but I also don't want to get into an argument. If I'm getting "no go" feelings and they aren't reciprocated, this seems doubly like a problem.

My advice, if you are getting this response a lot, is to consider how you are responding to questions. You may be projecting an inflexible attitude. Don't wait until the end of the interview to ask questions about how things work. Try to make sure to fit it in at every place you can. How are they doing their development? What are the people like? How do they resolve disputes? How do they decide on their tech stack? etc, etc.

However, also think critically about the place you are applying into. If you think, "Oh this is an awesome place" and they think "This guy isn't a good fit", That's a pretty bit mismatch. Did you listen well enough to their explanations? Are you sure that it works the way you think it does? However, if you are thinking, "Oh well, this place is OK. There are problems, but I can fix them", maybe there is a mismatch between what you think is a problem and what they think is a problem.

And while you might be thinking that "not a good match" is corporate speak for "you can't balance a B-tree", my experience is that it really means exactly what it says. As much as my ego takes a hit when I experience it myself, in retrospect every time I've gotten that response it's because it was true. I would have hated that job.

Sorry for the rambling nature of this reply. I should be working, but I hope it was helpful.
Tencent Pony Ma Highlights the Future of Industrial Internet During IT Summit
Maybe of topic, but:
I find it interesting that the author lists user experience in his "what I would like to talk about" list yet uses super bright yellow as background.
apparently you can run the following on a commodore shell for a Microsoft easter egg:

WAIT 6502,0
Thanks, changed that setting.
Yes, yes, and mostly yes.

This is no different from entering a name of someone written with a less common combination of kanji. You can either enter the word phonetically and pick the kanji you want (this trains the IME), or manually add an IME dictionary entry.

I fully expect all IME's in common use to have updates for this within days, if not already.
> It is possible for a newer version to contain a new bug that would increase the accident rate significantly, but given the existence of realtime collision data, that seems like the sort of thing that would be caught and corrected rather quickly, before it would dramatically affect the long-term average.

This assumes they correctly diagnose the fault and know how to fix it, and are able to fix it without any adverse side effects on superficially similar situations requiring a different course of action. This, and the assumption of a monotonic decrease in bugs and other undesired behaviour, seems like assumptions which are inconsistent with real world development of complex software aimed at handling a near-infinite variety of possible scenarios. Any driver is going to encounter situations which are subtly different from those the car has been trained to handle on a constant basis, so the probability of being the first to encounter a new bug doesn't strike me as being particularly low. The gross human accident rate per million miles driven is very low (and a driver who is experienced, responsible and not intoxicated has good reason to believe their own probability of causing an accident is substantially lower)

> That doesn't help you much when the intoxicated driver is driving a vehicle that hits you rather than the vehicle you're a passenger in. You presumably would prefer that vehicle to be self-driving rather than operated by the aforementioned drunk driver.

I don't get to choose what vehicles other people use. I do get to choose whether to pay more attention to a car's actual erratic behaviour than a statistical claim that various previous iterations of the software have had fewer accidents than a set of humans whose accidents are heavily skewed towards people with less regard for road safety than me.

> The somewhat ironic thing about stories like this is that whenever they discover something like this, it automatically becomes the focus of engineering time, both because a specific problematic behavior has now been identified and because not fixing it is bad PR.

This argument works in theory, but videos of Teslas accelerating at lane dividers are neither a new phenomenon nor one which is reported to have been fixed. I'm sure plenty of engineer time has been devoted to studying them (despite Tesla's actual PR strategy being to deny the problem and deflect blame onto the driver rather than announce fixes) but the fixes aren't trivial or easily generalised and approaches to fixing them are bound to produce side effects of their own.
Flagged as duplicate
My experience has been the same. It's great when the code base is designed and maintained by people who view assemblies as isolated, fully separable entities. But many programmers walk into dotnet not understanding the approach and make a mess of it.
I agree with the sentiment behind your comment. Rust is very portable, but isn't portable to all platforms. Obviously it works on the big ones like Windows, macOS, most variants of Linux, BSD etc. but it doesn't on Alpine Linux. IIRC there was an issue compiling it without glibc (which Alpine lacks).

Edit - apparently rustc can now be linked to musl instead of glibc in nightly. Cool!
Show HN: Technology Book Search
It's not even a word in Manyōshū. It's two characters taken from two words in a sentence from there, 令月 and 和ぎ.
It's just uses Emscripten SDL2 for audio output. Here's build with MIDI music enabled: https://milek7.pl/openttd-wasm-music/
> "Distributism favors the dissolution of the current private bank system, or more specifically its profit-making basis in charging interest"

Does not sound very Swiss to me.
> All the things most programmers do these days are pretty mundane and the only thing you need to ascertain is if they are familiar with the technologies that are being used.

this is exactly the company/boss i would not want to work for.
It is exactly the opposite. You should not care if the person if familiar with the tech you use. Who cares if you do php or c#? Does it REALLY make any difference when it comes to taking the business logic and adapting it into MVC/API?
Yes, I will. I'm theroadchoseme.com
A perspective from the interviewer's side. Since I run a small startup, when hiring, my first thing to determine was that whether I would be able to work with the candidate. Hence, I would come up with a puzzle, a maths problem, or even a guesstimate, just to see the thought process and that whether there is any "gelling". Things to evaluate are, original thinking, how well the candidate puts his perspective forward, how well he takes suggestions, how quickly he reaches the crux of the problem etc. If there is a face to face interview, the general assumption is that the candidate is talented, more important is that whether he can work with others in the company. If I am hiring someone who will work alone, without anyone's inputs, I might change the process (something like an integration or SSIS workflow) but have not needed to encounter that as of yet.

I usually go through the resume, and have interviewed enough coders to understand that they would know about what is written on the resume. Hence, knowing the background is good enough for evaluation, but feels repetitive during the interview. (Also, if you have had 4-5 years of experience, and 2-3 jobs, you can only stay for long if you had good skillset)
Cool, but then you end up with less money overall.

The smart move is to accept the counter, then keep looking for something better with the negotiating position that you're paid $salary x 2. Better yet, push for a title to go with the salary that'll help you land an even better job.

This is assuming all else is equal. If you're moving on for better future propsects, because the company culture is stressing you out, or because of a lack of trust, it might be better moving on anyways.

But there's no guarantee the new lot is going to treat you any better either, and companies do what's best for them, so there's nothing wrong with playing the same games yourself.
A CEO Who’s Scared for America
Show HN: Conn2.me
Is it an aspiration for the company and are they close? Is it miscommunication between product and marketing? Or is it intentionally lies? Are you offering some sort of information automation? To me I can see anyone not in computer science easily being confused. So maybe intention here matters
I am a continental European myself and have lived in three European countries, two of which are republics (not France though). You?
As a Scandinavian, I think that makes no sense. Germany introduced modern welfare reforms long before Scandinavia: Bismarck - a far right monarchist - introduced a pension system and healthcare insurance in the 1880's. His rivals on the right at the time mockingly accused him of being a "state socialist", and he embraced the term, because his intent was to out-flank the socialists of the time by offering limited concessions that went further than even some Marxists. At the same time as he offered the carrot, he applied the stick: dozens of socialist organizations and newspapers were outlawed, their leaders arrested.

Through European history, we've seen universal healthcare and pensions and general welfare reforms come about largely as a result of the combined efforts of two groups: growing labour movements, and Christian democrats. In Germany Bismarck leaned on the Catholic party Zentrum, forerunners of the modern ruling centre-right CDU, and argued heavily from a point of view of Christian morality to get his reforms through.

In Norway, the first welfare reform was introduced in 1894, after Bismarcks model. After World War II, there was broad agreement across the board for welfare reforms, but it was first a broad coalition of centrist and centre-right forces that introduced the first major expansion of welfare: The Borten government, led by the agrarian "Centre Party", in coalition with Left (classic liberals), the Christian Peoples Party (centre right Christian democrats) and Right (classical small-c conservatives, which in Norway makes them the traditional right wing, but relatively moderate). They certainly got the support of the left, and the Labour Party subsequently expanded the welfare system, but the foundation of welfare in Norway like in most of the rest of the developed world was not a unilateral expansion of socialism but reflective of a combination of growing labour movements and Christian morality.

Some notable exceptions: In the UK, the Christian voter groups are split between Labour the Conservatives, for example, with internal factions in both causing tension.

What is unique about the Scandinavian model is not healthcare or higher pay per se, but the compressed pay scale. It's a bit embarrassing to earn "too much" in Norway, for example. Salaries ranges are much flatter.

But that is not just due to Scandinavia changing, but due to the rest of the world changing. Look at pre-Reagan America for example, and executive pays were a far lower multiple of the company averages.
I would rather compare an auto-driving failure more to an airbag that failed to deploy or was otherwise rendered useless. An airbag that is inadequate for the amount of force applied might still save your life, and is still serving its intended purpose. Auto-driving incidents are so outrageous because they represent systematic failures.
The only problem is with some of people using English word when there's clearly alternative. Like a marketing trends.

Hashtag, Meeting, Proof of concept have clear traduction. They don't know what a proof of concept is and use it for testing product…

We don't care about the french academie because the way people talk is way more important and make these change to the writting after.
I use it as leverage at performance review time. Non-emotional, but “hey I like working here and contributing to the goals of company x, but I want you to know I’ve received an offer for $z. I believe that’s a fair evaluation of my market rate. I’d like to see a commitment from (current employer) that matches that in the near future. Do you think that is workable?”

You clearly need to be someone your manager is willing to fight HR in order for this to work. But it’s been effective for me.
5 AM club is a scam
India is also a little bit protective ( rightfully so in my opinion). Eg. A marketplace can't sell their own products -> Amazon
Market Manipulation as a Security Problem
“I love working here, and because of that I need to let you know that other opportunities are becoming financially better alternatives. Would you reconsider the maximum salary that you think I’m worth here, so that we can keep working together?”
How do you measure intangibles like knowledge or customer service or innovation? How do you weigh any number against another?

Surely a single number or sign only is insufficient for such broad areas. Much less a predictor based on one of those numbers which is why... measures lie. People lie less often and in a more detectable way.

The tangible results of them can be measured but there are multiple variables affecting it, from politics, through skill, talent and finally luck. If any of those elements fail, you get nothing, despite intangible gains that may provide a long term advantage.
The confusion probably stems from the way it is written in the calligraphic representation of 令和 presented by the government, which does do the same vertical stroke as in print.

In normal handwriting マ is totally fine and common.
I hope you've discovered Venture Bros? Best of them all!
At work they’re doing some half-assed metrics based on scrum story points, which is fine, I do about as many as anyone else, but it doesn’t really capture that the entire project we’re working on was almost entirely my idea and that a lot of the backlog that everyone is working from was generated by my ideas. I spend 80% of my day reading and thinking and maybe 20% coding at best. I used to think that if I spent more time coding I’d be more productive, but I don’t think I could spend more time coding and still produce anything worth while. I enjoy coding 2-3 hours a day. I absolutely hate coding 7-8 hours a day. I do better work when I’m enjoying it.
The billionaire is a man very well off financially. He has his way of seeing things. Most of his people have suffered a lot to succeed. I think these are examples to follow.