Genuinely opening up is a mistake. The incentives for these clearly mean that they actually select for candidates who are capable of glibly blagging their way through an extended conversation without saying anything inconsistent, weird, compromising or of substance.
This isn’t usually a required engineering skill. I’m guessing the interview was designed for salespeople and/or middle management.
I'd say it depends - evaluate the vibes. I spent 8y and recently 7y at a company where I genuinely responded with what I thought. But I'd say it's a matter of the audience - some people want to hear certain things and deciding if you can share these thoughts is up to you. It also allowed me to make decisions - if people don't care what I think and want sycophancy is this the company I want to be working at? I understand though it depends on one circumstances = you have to grin and bear it
Yeah, definitely just tell them what they want to hear on the personal question front ("tell me about a time..."). There's zero benefit to being truthful and zero downside to blagging it.
You are the google search engine pre-2010, well before Google lost their "don't be evil" motto, made the first results page favour sponsors and added AI overview. You respond to a search query with a list of https:// URLs, each accompanied by a representative quote from the destination page that demonstrates the link's relevance to the query, and nothing else. The query is: <insert your query here>
We live in the dystopia we deserve. We have built it with our own hands and it is here to stay.
I had to laugh as I read this, but it feels so appropriate to the current state.
I will say off topic that, speaking to an early googler, there is actually documentation of meetings where they discussed what "don't be evil" meant and decided actual business options they should and should not pursue. It was not just a motto or a "code of conduct", but meant as and used to justify consequential actions.
Pre-2010 Google search didn't use https by default, almost no one did besides specific cases, like processing payment. And even then, only the critical part was https, the rest, like images was plain http. So, for a true pre-2010 experience, you want http:// links.
Post-2010 Google played an important role in pushing for https. From boosting https search results, to Chrome being annoying to unencrypted connections, to sponsoring Let's Encrypt, to forcing HSTS on their TLDs.
I kind of miss http, it was a time when the web was a public thing, a place for sharing, not for keeping secrets. But to be fair that's just nostalgia, the modern (commercial) web that generalized encryption enabled is so useful and convenient that I can't imagine going back.
Some contributed more than others but few of us are entirely innocent since we keep using the products in question and do our part in supporting their business models. We also have failed to change the laws to prevent all of this.
Even if you don't have much power individually, as a society we could stop this any time.
"Don't be evil" is still in the code of conduct, it's just the last line now. Journalism, as it usually does, perpetuated a misleading scary story in order to garner eyeballs/clicks.
“Implementation defined behaviour”: compiler author chooses, and documents the choice.
A lot of UB should be implementation defined behaviour instead; this would much better match programmers’ intuitions as they reason about their code - you can even see it in the comments of this post: it’s always things like “this hardware supports / doesn’t support unaligned accesses”, it’s never nasal demons.
That isn't true, for UB the compiler is allowed to assume the UB can never happen. For example if you dereference a pointer and only after check if it is NULL, the compiler can remove the NULL check, since it is clearly impossible (nevermind that you might be on a microcontroller where NULL is a valid address).
The fallout of this are quite large!
If behaviour is implementation defined the compiler has to stick to one consistent behaviour. No such need for UB, you can get different behaviour bu changing unrelated code, by changing between debug and release or just because of what garbage happened to be on the stack.
Since the compiler is allowed to assume the UB doesn't happen it will also sometimes look like the compiler miscompiled your code elsewhere, but what actually happened was some inlining followed by extrapolating "this can never happen".
UB is often surprising: I have seen unaligned loads crash on x86 due to it bring UB in C (even though x86 is generally fine with it). But once a newer compiler decided that it was fine to vectorise that code (since it clearly aligned) the CPU was no longer happy with it.
>That is, the compiler de facto defines what happens when you compile UB code.
That is not what undefined behavior is though, that is unspecified behavior.
The entire point of undefined behavior is to cover the cases where the compiler can't define the semantics of your program either because doing so is genuinely not possible, or is incredibly onerous to deduce, or would require introducing runtime checks whose performance cost is at odds with C and C++'s predominant use cases.
Both are wrong. It means "this standard does not constrain the behaviour of code that does this".
It's entirely legal for implementations to have predictable behaviour, documented or not, for code that is undefined by the standard. In their quest for maxxing benchmark performance they generally choose not to, but there's really nothing in any standard that stops you from making an implementation that prioritises safety.
Every implementation so far has predictable behavior in all cases. Sometimes the rules for predicting it are very obscure. But it's all fully defined within the compiler's binary code. And none of them link to nasal portals.
How do you propose to predict the behavior of a true race condition with only the binary, faithfully translated by the compiler?
Moreover, this is at best an incredibly pedantic point, not something that changes how programmers need to approach UB. You can't review the source code of a compiler that hasn't been written yet.
I didn't suggest that implementations should entirely eliminate every form of UB. There is plenty of middle ground. For example, you could easily limit the consequences of integer overflow by specifying or partially specifying overflow behaviour, with very little runtime cost.
I'm not suggesting you change how you write code, but with a better implementation the code that you do write - that lives in the real world where mistakes are made - might work better. How is that being pedantic?
An interesting case where compiler writers did something like that is casting via union members, but I'm running out of time, so we can talk about that another day.
Turns out that when you're implementing network applications, the set of things that could happen also depends on what the script kiddie on the other side of the globe feels like this morning.
Some would prefer less excitement than this.
C code should be more predictable and easier to reason about than using a macro assembler. To the extent it is not, the language has failed.
Given that it sits at the heart of the network stack, kernel and device drivers for every major operating system, is in many, many embedded devices in the World around us, and is responsible for making decent chunk of the global economy keep moving, that’s quite a failure case.
Perhaps some professional programmers know how to write secure software in a language with undefined behaviour. Maybe we should think about that more rather than just writing off an obviously huge success as a failure?
If you're paying for a subscription, the company might sell your data. If you're using a commercial service for free, they are certainly selling your data.
Having said that, you're right to be suspicious of commercial services, even that you pay for. Someone can found a startup with a strong commitment to customer privacy and the best of intentions, but a few acquisitions or near bankruptcies later, those commitments will go out the window.
Relevant to this case, since they have a free version and premium one, they would probably just sell data from both sets of customers. It would be leaving money on the table otherwise, right?
The small chance that they might go out of their way to not sell premium users data doesn't seem worth much.
Get this through your head: I. do. not. want. to. be. in. a. relationship. with. you. Using your product or service one time is not consent. Finding partners is hard, but that is no reason to propose marriage on the first date, and that strategy will not work well. No means no.
…now imagine a list of instruments, some of which have durations specified in days/weeks/months (problems already with the latter) and some in workdays, and the user just told your app to display it sorted by duration.
This isn’t usually a required engineering skill. I’m guessing the interview was designed for salespeople and/or middle management.
reply