I must respectfully express my concern over: "Grabb-it Inc. turns rideshare cars into digital billboards." There's probably a market for it as online advertisers face an uncertain future with possible regulation, and at least scrutiny, of social media companies, but is this really the future we want to build? Where the only goal of some of these companies is to unrelentingly cover every square inch of the world with ads? Surely there are lawsuits waiting to happen when drivers, distracted from these eye-catching ads on all the cars around them, kill people.
I am worried that our public spaces are turning increasingly hostile to our citizens. Won't this trend continue to make the public space more unpalatable?
[0] https://techcrunch.com/2018/08/15/grabb-it-wants-to-turn-you...
> It’s meant to only run when the driver is between rides. Once a passenger hops in the car, the projector is shut off — because, well, no one wants a projector blasting light in their face on the way to their next meeting.
So, they intend to use it as a means for drivers to make money when they are not in the middle of a trip.
This is terrible idea and poor investment.
I also wonder if they misunderstand the vitamin market in China. Whereas it is mostly bros looking to buff up in the states, in China, you buy them abroad to show your elderly parents/grandparents you care for them. But maybe my views are outdated?
Example:
foo = do_a()
bar = do_b(foo)
foo = do_a()
bar = do_z(foo)
baz = do_b(bar)
foo = do_a()
bar = foo + 10
baz = do_b(bar)
What Optic seems to do is to recognize the pattern, create a single model out of it, and allow you to re-use that pattern elsewhere, or even transform it into new ones and re-use those new patterns elsewhere.
Again, this would be a new kind of abstraction. One whose leaks are easier to fix. You can have your cake and eat it too!
You're definitely understanding the premise of our parser. It evaluates a regex-like set of rules on an AST tree to match different forms of code. These rules can be recursive as you can see in the first example of our home page [0]. In that example Optic matches an express js route and the headers, parameters and responses inside it. The result is a nice json object with shape {method, url, parameters: [], headers: [], responses" []}. OOTB the JS interpreter couldn't do this because it doesn't encounter the calls to req.query.param_name until that code runs.
PG wrote about building the language/abstraction to fit your problem [1]. In an ideal world we all would do this, but in practice there's always a gap between our program and the abstraction we describe it in. Today that gap is only bridged by a human understanding the code. Until now...Optic is allowing us to programmatically deal with these implicit abstractions.
We believe most of the dev tools created over the next decade will be built on top of your code in a way that allows them to collaborate with real developers. To realize this world we need a programatic interface to read, generate and mutate code so we created Optic.
[0] https://useoptic.com [1] http://www.paulgraham.com/progbot.html
One method to define that function would be to do it the way explained in this [0] comment. That is, express the solution with small, composable functions. This would work as long as you can express the program in a composable way. This is what I usually try to do first, unless I find expressing my solution with composable pieces is not worth the effort.
For example, an async solution to a problem would be very difficult to express composably without well thought-out building blocks. One such collection of building block is Reactive Extensions [1], which is the result of years of research and development. So, before RX and similar libraries existed, it was costly to express async programs composably. That cost may or may not have been worth it.
Another method to define that function, if we're not going for "composable," would be to write it with an `options` argument, which would look something like:
type Options = {use_cache: boolean, skip_one_cycle: boolean, number_of_retries: number, ...}
Third method would be to define multiple variants of that function, like `do_things()` and `do_things_with_cache()` and `do_things_and_retry()`, etc. Here, each function is simpler than a single function taking an `options` arg, but then core logic would be repeated in all of them.
And since these three methods are not binary options, one may even use all three of them to some extent.
What Optic seems to provide is a fourth option which allows you to forgo defining that function (as long as that makes sense) and repeat your core logic in many different parts of your code. The devtool would then recognize the core logic in all those different repetitions and assign it a single identity, which would allow you to manage that core logic from a single place. This would be especially useful in a language that does not support macros.
(Btw, macros would be your fourth option if you're coding in lisp/rust/etc. The one tradeoff with macros is that they are yet another layer of abstraction that the author and the reader of the code should keep in their head.)
function baz(modifier) {
let foo = do_a();
let bar = modifier(foo);
return do_b(bar);
}
Example 1: baz((foo) => foo);
Example 2: baz((foo) => do_z(foo));
Example 3: baz((foo) => foo + 10);
baz = (modifier) => do_b(modifier(do_a()))I'm not trying to scold the founders. It just confounds me that people would start companies like this when there's clearly no net value to social capital.
Let's just say I'm skeptical. I hope it works out, but...
MacD looks interesting... but I'm kinda surprised YC would invest. A Mac n Cheese company? Very strange.
I'm very excited about the biotech space, so looking forward to seeing how that shakes out.
Crunchyroll's interview process definitely was not consistent, which is why I spent my final two years there trying to improve our processes. I learned a lot from it, and that's why we're doing CSPA :)
- James Lin (james@cspa.io)
Can you elaborate?
I thought the coding challenge was fun. They basically give you a URL, and the URL contains a list of numbers, which you append to the URL. Visiting each URL+number returns either a list of other numbers (which you keep traversing), a FAIL message (dead-end, of which there are many), or a SUCCESS message (only one). You task is to traverse the entire tree, determine how many dead-ends there are, which number is the successful end, and which path is the shortest path from your starting node to the success node. It was pretty fun, and the solution wound up being basically a breadth-first search or a depth-first search (pros and cons for each).
(You can do the challenge here, if you want: http://www.crunchyroll.com/tech-challenge/roaming-math/yourn...)
I submitted my answer and got set up with a phone call. I don't remember anyone's names, but this guy was touted as a PhD and a genius, so I was excited to talk to him. Over the phone, he gave me another challenge: "Imagine you're Photoshop, and someone selects a pixel with the Fill tool. How do you know which pixels to fill?" As you can imagine, this turned out to be another breadth-/depth-first search problem. You look at the surrounding pixels, decide whether they're the same color or not, and then proceed to the next level and repeat.
I was offered an on-site, which I accepted. I arrived and sat in the lobby. They have a giant big-screen TV that was showing anime. Makes sense, since CrunchyRoll is an anime streaming service. The current show had a woman eating in a restaurant with some men. I couldn't understand the words, but it was clear that she was having orgasms while eating, and the men were watching. At the time it was mildly amusing, but in retrospect, it was quite inappropriate.
Eventually, I was shown to a room with a whiteboard. The first person (an engineer) comes in, says "Hi, I'm Jack. So you have M trains and N stations..." and starts writing on the board. No idea who this guy is or why he's talking to me. I, being nervous, tried to follow along. His question was ultimately another search problem. Due to poor time management, I didn't have time for questions. He nodded and walked out to get the next person.
Second engineer comes in. "Hi, I'm Brad. You have M dogs and N cats..." and jumped right into his problem. No context, no anything. Yet another search problem. At the end, there was no time for questions.
Third guy comes in, same thing.
Fourth guy comes in, he actually introduces himself. He's the head of Product (or at least some Product Manager). He asks me a couple of questions, then gives me a coding challenge on the whiteboard. Another search problem.
Fifth guy comes in, the PhD guy comes in, says "Hi, I'm Kevin. You have..." and launches into yet another search problem (again!). Having done six of them by this point, I breezed through it and finally had time for one question. I said, "You guys must do search problems a lot here at CrunchyRoll."
He cocks his head to the side, looks at me like I'm crazy, and says, "No, never."
The sixth guy comes in and gives me something different! "You have a box and a bunch of random objects. What's the most efficient way to pack it?" which, of course, is the Knapsack Problem, which I believe has not been fully solved. But I do my best.
At this point, I'm over it.
I know CrunchyRoll does not fill boxes. I know they don't do any of the things they're quizzing me on. I don't know anything about the business other than what I've read online. I don't know what any of these people do. I haven't been given any context about anything, and when I did manage to ask some questions, I got nonsensical answers. I don't know which team I'd be working on or what role I'd take over. I don't know which of these alleged geniuses would be my coworkers (or god forbid, my boss). I don't know what problems CrunchyRoll's engineering team is trying to solve. I don't know their tech stack, their culture, or their company strategy.
I was not offered a position, but even if I had been, I would have turned it down. It was pretty bad across the board.
Ironically, the next company I worked for did some work on behalf of CrunchyRoll in the data engineering space. Thought that was funny.
I had a similar experience at Zenefits the next day, but halfway through the interview I declined to proceed further once I realized it was the same thing.
On the positive side, I've interviewed with a dozen other companies in the intervening years, and most of them have been fairly positive.
I thought it would be about computer science and engineering fundamentals. It has some of that (e.g., representation of integers, memory access speeds, etc.) but I also noticed it’s full of completely inessential things, like escaping XHTML, identifying valid JSON payloads in HTTP, and alignment rules in CSS. There was heaps of JavaScript, HTML, CSS, SQL, and drawn out shell exercises.
To be clear, I’m not claiming that’s all useless knowledge. It’s not! But, as a hiring manager, I’d rather look for strong critical thinking skills and strong foundational knowledge. Remembering that keys in JSON must be quoted strings is not at all a demonstration of that.
The exam seems to be more of a “well rounded full-stack engineer” rather than what they suggest.
[1] https://cspa.io/
Adaptive scoring algorithms and ways to let employers create custom projections of our multidimensional data is something we're thinking about. If you have ideas on how to build this, I'd love to hear them! james@cspa.io
A standardized assessment is literally the farthest thing from what happens in real world programming. In contrast, the Triplebyte interview questions focus heavily on what an engineer actually does day to day. When I completed Triplebyte, I was pleasantly surprised at how well orientated the assessment was. CSPA just looked plain insane in comparison.
Even the time commitments are a good contrast. Triplebyte’s commitment on the quiz side is about 30 minutes, and the final interview is a couple hours. CSPA is five hours.
I provided feedback that included this issue, I believe around when it was first a "Show HN" post, but the page was never updated.
That would certainly give me pause as to the accuracy of a technical (or detail-orientation) assessment.
We're constantly improving the CSPA questions, and our latest iteration has quite a few changes. Some of the examples you mentioned assess how detail-oriented the candidates are. We're interested in how this data correlates with how bug-prone someone is.
That said, we trimmed some of those down in our latest version and replaced it with more substantial questions.
- james
Someone also brought up a point regarding the validity of testing for skills in web development if test takers won't end up in those fields anyway. However, when looking at similar exams (e.g. MCAT), you can make the argument that the majority of doctors won't use Organic Chemistry or won't need to know about the minutiae of Psychology & Sociology to be successful. The MCAT becomes a successful discriminator of good vs bad test takers because of the amount of work and critical thinking skills that is needed to cover the litany of subjects tested. Similarly, the CSPA could follow a similar pattern as the MCAT by testing a range of subjects as a means of measuring one's ability to learn a large sample of topics.
The only thing I can really think of that CSPA can improve upon is providing more preparatory materials. Additionally, it'd be useful to see how people end up performing on the exam and if there is an actual "Bell Curve" like distribution of scores that results.
Even with 100% truthful reviews, they're interested in different things and need very different language.
Open up in Chicago please!
Biocontainment solutions (Synvivia) that prevent environmental contamination of genetically modified organisms looks to be a very high demand market.
Yep...then the on-off switch jumps species and the only way to survive is to consume a particular (patent pending) brand of parsnip which can't be grown from seed.
Pretty much the only place I could reasonably be accused of being a luddite is in releasing GM organisms into the wild.
You can use oxygen, temperature, and light-sensitive gene promoters and toxin-antitoxin plasmids to make ON-OFF switches that would hobble bacterial replication in the wild.
It's a tough problem, and my guess is you'd want to use several of these switches together. There's no guarantee that stressed bacteria will 'run' your programs. And you're right that the gene could move horizontally, so you'd have to be very clever with your kill switches, and keep up with evolution.
Apart from the last resort of antibiotics, you can also selectively deplete particular bacteria from your poop using adhesion inhibitors such as mannosides and galactosides (https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5654549/ - research from my lab).
When you've got the answers for common diseases from the doctor who gets them from an app, the doctor himself is a repleacable middleman and can be anybody with enough confidence, even if faked.
Sadly, really only useful for wet labs.
I'm not an insider on the terminology, but it seems a "wet lab" is what a lay person, like myself, thinks of when we hear "a lab" (in the physical sciences context).
What's the "dry" (or is the term of art different?) lab situation you wish it would be useful for?
There could be a different startup opportunity, if it's scalably computer-heavy [1]. I'm aware of computer-controlled instruments for wet labs being a very underserved market (and presumably with high margins for the computer portion), but that seems like a consulting/services/labor-intensive business.
[1] Around HN, that usually means software, but my background is Ops, so I actually consider commodity hardware quite scalable, too, despite the hardware-is-a-nightmare-we-have-to-do-cloud mythology.
"Wet lab" is useful to distinguish people with actual labs vs. my lab, which is just a bunch of people with laptops.
The situation I'm dreaming of, is, for example, it not being my problem when a grad student is having trouble getting software installed on the server. That would be something I'd love a lab manager or dedicated programmer to deal with, but for a small lab, I don't have nearly that level of funding.
Clever idea!
This is definitely the kind of product that takes several iterations to get right so thank you for following our journey.