I'm working on SPHNX, a voice-based AI coding interviewer. While problem solving is crucial for passing interviews, in a live interview you are also getting tested for your communication, debugging, thinking on the spot, testing, code clarity, and other skills. You can't practice these on leetcode, but it's easy with SPHNX. I've just added rich feedback reports last week that turned out more helpful than I expected.
Right now it works as a mock interviewer for algorithmic (leetcode-style) problems, you can sign up for the waitlist here, I'll send you an invite right after:
It actually works pretty well, but we're having trouble getting users (some sign up but don't end up doing even a single interview?!).
We're thinking whether we could sell a version of this to companies to do their technical screens in, perhaps with problems that are more similar to the actual software engineering work (e.g. debug existing piece of code, write tests, and extend it).
We're generous with interview credits if you give us good feedback =)
I work at Coda and would love to hear more about your experience. We are focused on our tables and formulas and I am surprised to hear that you had such a bad time with them. Feel free to reach out at gleb at coda dot io.
The main thing is that the extension would still have to be able to run its JS on any page to be able to show the interactive sidebar. Not sure there is a way around that, unless chrome decides to implement the sidebar api that firefox has (https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...), then the sidebar code doesn't have to run in the same context as the page.
Yeah, I will write it down on the website. As I mentioned below (https://news.ycombinator.com/item?id=28700703), I do not store the URLs that you go to (though of course you have to trust me on that), and as all the processing is done on the server, that URL doesn't get sent to any external APIs (though if I go through with adding reddit I might need to send it to the reddit API).
I do collect some telemetry statistics (right now the number of times you have seen the sidebar + the number of times you clicked/scrolled/closed it), aggregated hourly.
Thanks! My intent definitely was to make it a little bit chaotic =) I will try to figure out how to make it a bit easier to follow, heard some advice to space it out a bit possibly.
But as I said elsewhere, in my experience I rarely use it myself since that requires a bit of effort to click and with an unknown reward it rarely seems worth the click.
I have actually seen your extension when I was trying to figure out how to get started with making one in cljs. I've used shadow-cljs though instead of figwheel.
Yeah after reading all the comments like this I thought maybe I should just take the top 1000 most popular websites and not show it by default on them.
For ampie you can just get its source, modify the manifest file, and build it yourself, no need to bother with repackaging: https://github.com/posobin/ampie
webNavigation together with tabs is needed to detect page URL changes correctly and update the sidebar (I don't remember exactly, but I think the main problem were pages that use history api to update the URL), storage is for localStorage to store extension settings, cookies to read/change cookies (limited to "https://ampie.s3.amazonaws.com/", "https://hacker-news.firebaseio.com/", "https://*.ampie.app/", to be able to get your auth token for ampie not to log in twice), unlimitedStorage was used previously because the caches of links stored were much more than the 5mb that is the default indexedDB limit. The caches are not used anymore, but I kept the permission so far because I am thinking of adding functionality for storing and visualizing your browsing history.
I am not sure what you would want to disable here.
If an extension includes content script that runs on all websites, then it can't avoid having the "read and change all your data on all websites": content script is JS code from an extension that runs on web pages, it can access the DOM and send requests. Ampie needs to run the content script on all pages to be able to add the sidebar. The other option is to run the content script on clicking the extension icon: as I mentioned elsewhere, while this approach might sound appealing in theory, the extension turns out to be much less useful this way as you simply forget/don't bother to click it and miss out on some interesting discussions.
As I said in email, you only see the sidebar two times per domain (unless there are mentions of the particular URL you are on, then two times on that URL). You can also disable ampie on a domain completely by going into settings: click on the ampie icon in the extension toolbar, and you can add blocked domains there. URLs from those domains won't get sent to the server to be checked, and the sidebar won't pop up.
It pops up the first two times you go to a domain or a URL that has mentions, so it should stop bothering you after a little bit of usage. I do hear you though, several people brought this up. The problem with making it a button is that people forget to click it (me included), and most of the interesting connections go unnoticed this way. If you have ideas how to make this better, please tell me!
Actually Ampie used to work differently: Ampie would store the local cache of links from your twitter feed and links submitted to HN, and check against it when you went to any web page. If there were hits, it would show a small tab in the bottom right corner, showing that there are N tweets, M HN submissions with this page. Then you could click on the tab and the sidebar would pop up, so no requests were sent until you actually clicked on the tab.
There are two problems with this: first, the cache had to be large, several hundreds of megabytes, because there are a lot of links (~200k from HN, and each person I follow on average tweeted 1k links among the last 3k tweets that twitter lets me access) and indexeddb is not memory-efficient. Second, this is easy to miss, and those numbers alone don't give enough information to go through the effort of clicking there every time. And this doesn't include the backlinks and HN comments mentions (fun fact: there are about 4m URLs mentioned in HN comments), so you'd miss out on a lot of stuff. You could suggest Bloom filters as caches, but that is a bad solution since now you only can show if there is a hit or not (instead of two numbers), but also there are false positives so the sidebar is not reliable anymore, and given that you go to hundreds of URLs a day, the FP rate has to be really low which makes the cache really large. Maybe using something like https://jlongster.com/future-sql-web would have reduced the memory usage, but at that point I gave up on that approach already.
Given how technically hard it was to maintain those caches of links (they had to be updated incrementally, for example, not to send hundreds of MB every time they were recomputed, you had to wait to download the cache after installing ampie), the fact that most of the friends I have talked to didn't mind if the request was sent on every URL visit (as long as I promised not to save it), and the fact that this made the sidebar less fun, I decided to remove those caches and just send the URL to the server on every visit.
So yes, every URL you go to is sent to the ampie server, but I do not save the URLs sent to the server, and if ampie is disabled on a domain (you can disable it on a domain in the settings), it will not request information about pages on that domain at all.
IIUC the content scripts that extensions use load after the page is loaded, so this shouldn't affect page load times. But please reach out if you feel like it does!
Right now it works as a mock interviewer for algorithmic (leetcode-style) problems, you can sign up for the waitlist here, I'll send you an invite right after:
https://sphnx.dev
It actually works pretty well, but we're having trouble getting users (some sign up but don't end up doing even a single interview?!).
We're thinking whether we could sell a version of this to companies to do their technical screens in, perhaps with problems that are more similar to the actual software engineering work (e.g. debug existing piece of code, write tests, and extend it).
We're generous with interview credits if you give us good feedback =)