Interviews are prediction machine that answer the question “will the candidate be successful (technical, design, soft skills, team integration…) in the role over time. The prediction is made with an extremely small sample, a few hours at most compared to months or year of training and employment.
Considering that, of course the interview won’t be a slice of real work - there just isn’t enough time. We try to compress the software development experience of months to an hour - so it gets lossy. That’s why, in the interview, we gloss over details that we won’t in real life.
Which is where ChatGPT’s answer really excel. Sure, it won’t really be able to design and code the system. But it can mimic knowing how to do it for the purpose of the test quite well.
>> While large language models may be able to answer some of the questions in an interview, they do not have the ability to demonstrate problem-solving skills or adaptability to new technologies and frameworks. These skills are essential in a software development role and cannot be measured through a simple recall of answers or code snippets.
>> Therefore, it is important for the interviewer to design an assessment that focuses on evaluating these skills and abilities, rather than relying solely on the ability of the interviewee to recall specific answers. This can be done through a combination of open-ended questions, coding challenges, and group discussions that require the interviewee to demonstrate their understanding of fundamental concepts and apply them to solve real-world problems.
The short answer is we haven't fully solved it yet. We have two modes we can operate in - directly encrypting in the database, or doing just-in-time encryption as the query results come back. For the former most queries other than direct comparison won't work - we have some early work started on using both homomorphic encryption [1] and format-preserving masking to help there.
With JIT response encryption none of that is an issue, but it can be slow for large amounts of data. Any kind of big-data analytics will be a poor fit for JumpWire right now.
yeah, FHE isn't, yet, something that can be used in a busy production env. At best I'd say it's a specialized tool, though in my mind it's a toy solution - can work for n=1, possibly for n<(low numbers) but not for large N.
Totally agree. We're likely going to implement a partially homomorphic solution that allows for some specific queries. We aren't trying to build a general purpose computational environment as the use cases we support don't require arbitrary computation. The data people encrypt with JumpWire is pretty much all strings and the queries on them are mainly doing some sort of substring matching (mainly prefix/suffix).
Ugh. This “zero knowledge encryption” is NOT zpf. Just a per user PBE hiding a shared symmetric key.
I kept reading, trying to find the innovative way of encrypting large amount of data while not revealing the same key to all participant - some SSS variant or fast FHE or maybe a cool new PRE.
Also, all value added features besides shipping the bytes are gone when something like this is in effect. Search, preview, co-edit, metadata extraction.
I guess I’m disappointed / venting because of crushed hopes. I’m in this field and hoped something new and exciting is starting. Not trying to criticize the engineering work, which looks quite well done, just sad there isn’t new algorithmic development.
Boxcryptor was originally just a wrapper around Encfs and a Dropbox API client and probably hasn't significantly changed how they worked since they made it a fancy service. I assume that they rebuilt something like Encfs, but closed source.
Seriously, I would love to have a chat with the product manager in charge. With over 6.2M call-minutes per minute and over 300M daily active users [1], how can "mute", the most important functionality in a video call (I would argue even more than disconnecting the call) still be missing?
Just a tiny dot that sets a mute/unmute flag on the mic, preferably with an audible cue. Don't even involve the phone, just mute it on the device itself. I know HSP/HFP don't support mute command but a device level option should be easy. Moreover Apple could, as it's done before, implement an Apple-to-Apple extension of either of these protocols.
If airpods had mute buttons, tons of people would complain about accidentally muting themselves. People already have mute functionality in the paired device's OS and the app they're using. Adding mute functionality to a third place just increases confusion. And worse: if you build it how you're suggesting (purely in-headphone, without notifying the paired device), people won't have any indication that they're muted other than a one-time audio cue. They'll end up toggling mute/unmute in Zoom and/or their device's OS, then assume that the headphones are broken. It's a UX nightmare.
The biggest advantage of CRT is that my cat could sit on one. He would be drawn to that heat generating machine, lay on top of it with his fore legs dangling over the edge of the screen and snooze while I played whatever video game was the current hit well into the night.
One of my cats loved snoozing on my big 19" CRT as well. When I replaced the CRT with my first LCD monitor, he tried to hop onto the non-existent top of the screen. In a mad scramble to not fall he put all of his front claws in the plastic cover of the screen. The LCD went from zero to hundreds of bad pixels within a day :-(
My cat used to sleep on my crt during 36 -48 gaming sessions of Everquest during school holidays with my best buddy. Two computers next to each other. Too much cola. Huge amounts of rage when we would die. Most likely because we barely slept. Heh.
Then when I got my first MacBook Pro around 2007 my cat decided that the hot as keyboard was the new sleeping spot. No more computer use for me when he wanted to sleep haha.
Not having the Touch ID lose Apple at least one, if not more, upgrades. At least in my case. I’m on an iPhone 7 that’s definitely showing it’s age. I would e upgraded a long time ago but held off “because maybe the next version will have Touch ID back.”
Well, that never happened and I’m now in the position of having to upgrade a phone that’s starting to crash due to battery issues, will probably be out of iOS updates in September and is frankly getting too slow for even simple yet surprisingly power demanding apps.
I don’t know what I’ll upgrade to. Likely an iPhone, but which? I hate buying something that’s not the current generation but the thought of having to deal with Face ID multiple times a day leaves a sour taste in my mouth.
I guess it depends on which “tech” specifically you care about. The jump from an iPhone 7 to the 3rd gen SE will probably feel amazing, considering it has the same SoC as all the iPhone 13 models. Sure, the SE doesn’t have the nice camera system like the high end models, but again, coming from a 7, it will be quite an improvement for you.
Most of latest tech? I found it to be a great upgrade coming from the iPhone 8: overall faster, slightly better battery life, better camera with a few new tricks. As I wrote in the article, I wouldn't mind upgrading every four or five years to new versions of this phone with newer internals. It just works.
I'll second the new SE recommendation. It's the best iPhone available right now unless your most important use case is the camera, which it can't be for you, because you'd have upgraded a long time ago otherwise.
Because US average family size is 3.3, especially in suburban areas, while Europe is 2.7, less in the wealthier countries. Ever tried fitting 3 car seats in a Nissan Leaf?
Moreover, US suburbia, with its huge distances between home, school, sports and entertainment centers, has a tradition of kids car pooling. In Europe distances are shorter and biking or walking are more popular.
These, with proper marketing, almost forces US families to have at least one large car. Whether it's gas or electric is a matter of status, disposable income, area of living (suburbia has less charging stations because population density makes it less profitable) and local political climate.
Good suggestions on 1 and 2. Thanks for being on-topic.