I've been using Google Workspace for over a decade. Historically, after removing a user from your organization, it was always easy to migrate their data (e.g. Google Drive folders) to your own user. Suddenly, I recently had a nightmare experience where I needed to remove users no longer in my company, but I was unable to save their very important data. Google intentionally removed the feature in order to promote their new "Archive" user feature, where "data is safe" and you pay for it at continued unnecessary, extortionist rates.
Separately, I just had another terrible interaction with my own data through Google Labs Flow. That is the site that is serving the latest Nano Banana image and Veo video generations. My takeaways on the quality and value and issues with those "world models" are for another time. Here I'm pointing out another unique "dark pattern" that product managers seem compelled to apply: "if you want us to save your data in a database, then you have to let us view that data and train models on it". It's ridiculous, either I can have my data automatically deleted and have sessions be completely "dumb", or I can submit my soul for eternity and "allow any reviewer to analyze".
Beware, founders and developers relying on Google. Don't be surprised if you wake up with your data held hostage. Don't be surprised when you realize your intellectual property can either be deleted or stolen, but not simply saved.
I happen to have a background at this interface as well, as the founder of DeepEarth and Ecodash.ai. I can tell you that I would greatly value such experience in collaboration, although I am not currently hiring. While having such a specific interdisciplinary niche can feel limiting, I also see it as a potential superpower in excelling in a very important domain. I'll also add that machine learning and other modeling techniques are a great bridge between classical natural sciences and modern tech today, that I would look for in collaborators. More specifically from the earth sciences, "GeoAI" would be a key focus.
I propose, as well, that we “weed them out” with a week of hunger games, battle bots, and rocket launch tests.
In seriousness, through a decade of experience in AI, I have found that most “famous” and “exotic” algorithms that software engineers love testing (e.g. OP’s references to sorting, tree searching, and recursion) come up exactly never in my day-to-day.
Please, limit testing to the actual data structures and algorithms that dominate 99% of the proposed work. If the proposed work is not in a field you are truly an expert at, then don’t be responsible for technically interviewing this person.
In my branch of AI, if I’m not getting solely evaluated on my ability to work with tensors, vectors, graphs, …, then I realize there is no AI group at this company (or it is inferior in its autonomy). There are so many extremely useful specializations in real-world moonshots, that would otherwise get bludgeoned upon any interview within a general purpose software engineering culture.
Text tokens are high-dimensional vectors, not 8 bits per character. Every token has a deep embedding, e.g. 1024 float values per text token.
DeepSeek-OCR proved 10x+ compression from visual embedding of text, which was a groundbreaking result. [1]
Very cool to see OP's project hacking on this principle. It's still not lossless, as noted in the github, but is a promising research direction.
[1] https://github.com/deepseek-ai/DeepSeek-OCR/blob/main/DeepSe...