Restaurants typically have fairly low profit margins, so there generally isn't a strong desire to spend limited free cash flow to upgrade/replace a point-of-sale system that's functioning satisfactorily.
Especially since it's not something capable of a significant ROI since the PoS system usually has little-to-no impact on either revenue or profit. A slow one could impact productivity - but this is rarely a bottleneck so in most cases there would be little gained by spending money to upgrade to a newer system.
> I've essentially stopped getting delivery which is a bad sign since I'm basically the target audience
Same, rarely ordered delivery pre-pandemic but then was ordering two or three times a month but eventually got sick of food taking over an hour to arrive from places only a mile or two away so stopped entirely (until discovering a nearby restaurant that does their own delivery and it's great - arrives within 20 or 30 mins and the food is always piping hot).
> the idea of asking people to write code during an interview what sort of revolutionary
And I think it's a great idea, personally I would never consider working anywhere that hired devs without seeing them write some code. But my problem is with the types of questions asked at many companies, specifically the types that require weeks (or months!) of prepping.
During my last job search one interview that stood out (positively) was a problem around parsing some HTTP headers (it started simple and then had layers of complexity added as I solved each one). It was honestly one of the best questions I've seen in an interview as it requires the candidate to be able to write code and solve a problem but without requiring/expecting the candidate to have prepped beforehand to learn (or brush up on) theoretical stuff far removed from the types of problems we actually solve on a daily bases (evidence of this disconnect is demonstrated by the fact people need to prep).
> Why would anyone be stupid enough to trust google to keep the "ad free" experience ad free?
One can cancel their YouTube Premium subscription at any time for any reason, including and especially if it is no longer delivering an ad-free experience. In the meantime I'm quite happy paying $10 a month (annual plan) to never see ads.
> if you pass in a negative number then that's your own dumb fault if it does something unexpected
If a negative number isn't valid input that should be gracefully handled by the program (e.g. by responding with an appropriate error indicating what is valid and/or invalid) instead of doing something unexpected.
I'm not much of a fan of the current state of tech interviews but seeking clarity around validity of input and how to react to invalid input is one aspect that does (or at least should) mimic "real life"
> People working for tabacco companies have always been in the same boat.
That's not a very fair comparison - there aren't exactly any huge positives associated with tobacco use. So it's not like someone could work for a tobacco company and say "sure some people die from consuming our product but on the other hand look at all the good we're doing..."
That's very different than Facebook where yes there may be some negatives but there's also positives (e.g. it's certainly raised countless millions for various charities, helped people keep in touch with others and discover (or rediscover) relationships, and spread the awareness of important social issues).
Yes they would pay, you wouldn't even know the person(s) were conducting an audit. All major hotel chains already do exactly this, typically at least once a year and the property has no idea until weeks later when they get the (very detailed) report.
> I also don't understand the "product-agnostic" part. Isn't k8s a product?
Product-agnostic meaning despite kubernetes.academy being provided by VMware it's not covering Project Pacific[1] or any other specific Kubernetes offering or integration by them or anyone else.
From the article: Rober deleted about a minute and a half from his original YouTube video yesterday, and reuploaded it—something YouTube allows you to do without sacrificing the number of hits a user has accumulated.
YC-funded startups can post job ads: These appear on the front page, but are not stories: they have no vote arrows, points, or comments. They begin part-way down, then fall steadily, and only one should be on the front page at a time.https://news.ycombinator.com/newsfaq.html
> Your argument was that almost all creative professions have auditions similar to whiteboard interviews
No it wasn't. Feel free to re-read my original comment[1]. My point was not that they have auditions, it's that the auditions don't closely mirror what they'll actually be doing if they get the gig (which is one of, if not the, most common complaint about whiteboarding).
However, it seems your primary concern is that the whiteboarding is done in front of an "audience" - I can sympathize with that but there's going to be an audience (by your definition of the word) regardless of the structure of the interview, i.e. your "looking through a past portfolio of work" example[2] is still discussing your work to an audience (as opposed to creating new work on the spot) and is still very dissimilar to the actual day-to-day work (N.B. I've never actually been an "illustrator, a graphic designer, a writer, or an architect" but I'm pretty sure their days aren't spent just sitting around discussing their portfolios).
> Perhaps it's time to look at similar industries and spend some time trying to figure out if we are really so different instead of insisting that programming is so uniquely challenging that it requires such a controversial interview process
Perhaps I'm mistaken (I'm by no means an expert on the history of our profession) but my understanding is whiteboarding interviews are a relatively new phenomenon (i.e. last decade or two) and presumably programming interviews prior to that were more similar to many other disciplines. It seems unlikely (though certainly possible) that our entire industry would move away from that if it didn't have major shortcomings.
If you feel you have found a better way to hire developers than what most of the industry does I would encourage you not just to use it for the interviews you conduct but also to share your thoughts and findings with others via a blog or maybe even a book. Either would certainly have more potential impact than debating the issue with me in a buried thread of a day old HN discussion. It's been an interesting discussion and you've motivated me to research the history of software dev interviews, best of luck to you in your career and interviews.
It's a bit odd you responded to various parts of my comment but not the "But more importantly I think you missed my point..." portion (i.e. kind of silly for us to debate this audience straw man)
> That's the important part of nearly everyone's job. Architects, graphic designers, engineers, sales people, mechanics, plumbers.
Communication, like problem solving, is likewise an important part of nearly everyone's job, but the importance of good communication skills (as valuable as they are) are much less important to being a good software engineer or good plumber than they are to being a good reporter or trial lawyer or public relations professional.
I'm guessing, like most developers, this is your first/only profession - but it's not mine (I switched careers in my early 30s), and I can assure you not every job requires the level of problem solving we deal with on a regular basis (and no, that doesn't make us "so special", not all jobs are identical, some have more or less value in different areas, but one is not more special than another because of the importance of problem solving or communication or empathy or creativity or anything else).
> Actors and musicians perform in front of an audience
Some actors/musicians. Movie actors never perform in front of an audience, TV actors usually don't perform in front of an audience, studio musicians rarely perform in front of an audience - these professions have auditions (unless you're an A-list actor, but I'm sure most software companies would hire John Carmack without an "audition" so we likewise do the equivalent). But more importantly I think you missed my point, in that the audition for these professions are under very different conditions than what you'll actually be doing "on the job" (one of the bigger complaints with whiteboarding seems to be that it doesn't closely mirror the actual work).
> Interviewing an illustrator, a graphic designer, a writer, or an architect generally involves looking through a past portfolio of work with the interviewee
That'd be fine if the point of the technical interview was to determine they know how to write code, but it's not IMO. As I mentioned above it's to determine they're capable of problem solving, because that is the important part of what we do (you should also obviously make sure a candidate knows how to code before you hire them, but that's the point of the phone screen).
> I agree with the sentiment but almost no other profession does this
Almost no other creative profession doesn't do this. Our profession is much more similar to actors and musicians than it is to doctors or lawyers. You also have to factor in practicality and gatekeeping (for lack of a better word) - it's not very practical for a doctor to perform mock surgery for an interview, whereas it's very feasible asking someone to write some code on a whiteboard; and if you're a surgeon you have things that indicate you know how to perform surgery at a much higher level of confidence than knowing someone can problem solve (well) just because they list "developer" on their resume, surgeons have to go to many years or medical school, they have to spend time in residency, they have to pass their boards, if software development had the equivalent of all this (and I'm not necessarily saying it should) then yes there'd be much less need for "auditions" in our field.
That's the analogy I use when people complain that whiteboarding doesn't mimic/approximate they day-to-day job. If you're the casting director for a play you're going to have auditions, you're not going to cast people based (solely) on their resume and having a conversation about their acting background. But auditions are very different than an actual performance: there's no audience or costumes or props, the lighting is completely different than what it will be, you're reading from a script, you may be the only person on stage while the other roles are read offstage, you're being accompanied by a piano instead of a full pit orchestra, you're mostly standing in one place instead of moving to established blocking, and so forth. The point of an audition isn't to mirror performance night, it's to get an idea if you're capable of acting/singing/dancing/whatever. Likewise the purpose of whiteboarding isn't to mirror the day-to-day work, it's to get an idea of your problem solving capabilities (some might argue it's also to see if you actually know how to code, but personally I feel that's what the technical phonescreen is for).
If you sell right when it vests there's a negligible capital gain (or loss). The value of the RSUs are taxed at regular income when they vest. Any difference between that value and the value when you sell them is a capital gain (or loss) and that is what's subject to capital gain taxes. i.e. if you sell once they vest the capital gain/loss is essentially zero (because the stock hasn't had time to move much)
e.g. if your RSUs are valued at $1000 when they vest and you sell it a few minutes later and the value is now $1005 you'll pay regular income taxes on $1000 and have a $5 capital gain (i.e. when you file your taxes the cost basis for the holding are $1000, not $0)
compile: convert from one language to another (though usually used in the specific context of converting from high level source code to lower level code like assembly/machine/etc)
cross-compile: convert from one language to another that will be executed on another platform (e.g. compiling something on a linux box to be ran on a windows machine)
transpile: convert from one (typically high level) source language to another (high level) source language
> in reality we don't really know what its development arc is
That's true, but we know we're past the rapid advancement portion of the arc. Look at the most widely used languages today, the top ten, regardless of methodology[1][2][3], are dominated by languages that are ~20 to 30+ years old.
> advancements in how we describe and create and interact with it
As a funny, but accurate, CommitStrip[4] pointed out, you'll need to create a specification, and we already have a term for a project specification that is comprehensive and precise enough to generate a program...it's called code.
> One potential example that I am looking forward to learning more about is Luna
That was discussed on HN recently[5] and some people were pointing out it appeared to have made little to no progress since the previous time it was submitted and others mentioned various short-comings of these types of visual programming languages in general. Time will tell, we'll see what happens /shrug
Especially since it's not something capable of a significant ROI since the PoS system usually has little-to-no impact on either revenue or profit. A slow one could impact productivity - but this is rarely a bottleneck so in most cases there would be little gained by spending money to upgrade to a newer system.