And Blue Box (https://www.blueboxcloud.com/) a month and a half ago. Looks like they're investing in or acquiring cloud platform software companies like gangbusters at the moment.
I feel like completely specifying the problem does everyone in an actual engineering interview a disservice and isn't a good analogue to actual engineering problem-solving. That said, it might be acceptable or even encouraged for the purposes of this site.
In the case that you mention, if someone asked me "Can I short sell?" I'd be happy that they considered the order of events there and were trying to explore the problem. I'd certainly remember it in my interview feedback. My response as an interviewer would be more or less "That's an interesting thought. To simplify the problem, let's say we're risk averse and prefer a finite loss potential. Go ahead and just consider purchase before sale."
One of the biggest criteria I looked for from junior engineering candidates was that they didn't just jump into implementation and asked clarifying questions. That's hard to do with the sort of site this is so maybe in this case more complete specification is useful, but any way that a bit of ambiguity can be introduced means that you can have a meaningful conversation with an engineer about representation, the shape of the problem, the inputs, what the criteria for success are, what is truly necessary to solve a problem. I want working code in the end, but hearing the things a person does or does not consider about a problem is interesting and valuable to understand a potential teammate and how they think.
I attended this conference and spoke with the presenter about his talk both before and after. My takeaway was that the presenter was trying to accomplish one thing: educate front-end developers who (rightly or not) have been characterized as unfamiliar or ignorant of cryptographic techniques with a survey of those techniques. I believe this was the sense "Bringing Crypto To The Masses" was meant.
I appreciated the energy and enthusiasm the speaker had for the subject matter and would be delighted if any of that transferred into his audience, but I don't feel it was effectively communicated. In the time constraints presented, even something as simple as, say, discussing what cryptographic hashing (or symmetric crypto or public key crypto or digital signing, take your pick) was and doing a deep dive only in this domain would have been a valuable experience and opened a lot of eyes. I'm fairly familiar with all the topics discussed during this talk and I had a difficult time following along with it. I can't imagine what the experience of the intended audience was or what they managed to glean from it.
I would imagine this has something to do with having an existing package dependency management system company-wide and it causing friction trying to get the two to coexist.
I have similar issues where I work with trying to integrate an internal build system and rubygems. Our answer is to essentially mirror the gem version internally into our own repo. It's not the best answer I could hope for.
Another identifier which would seem to help accomplish the task is identifierForVendor. As a bonus, it isn't something that can be opted out of like the advertisingIdentifier.
Maybe it's just being on a team that's more focused on nontechnical users, but I still see plenty of PowerPoint. Product, sales, and business process people seem to swim in the stuff.
Neither. If you look at the S3 URL, they are URLs with expiry times after which they stop serving the content. The cryptographic signature makes it... let's call it "infeasible" to manipulate the URL to change the expiry time.
