My understanding is if an employee who gets paid largely in tips isnt making more than min wage, that employee is almost always let go or quits. Employment layers dont love trying to prove a case that is pretty unlikely to be provable.
They can always find a reason, such as "so and so customer complained about your level of service and I can't have any complaints as a business owner" which on its face is a legitimate reason to fire someone.
I got to meet him and person and tell him that his books (along with The Coming Technological Singularity) had a huge influence on my decision to go into ML. He seemed pleased. I just wish he had wrapped up the Fire Upon the Deep series.
I got to meet him once too! Unexpectedly met him at a Media Lab demo day. I was trying to play it cool though and didn't gush to him around how he's one of my favorite authors. I regret not doing so now.
There is a difference between knowing how to find and use the ordered list of complexities for big O notation, and knowing these by heart. The difference is irrelevant when you design or code, but it’s important for interviews and exams.
I get very annoyed when llms respond with quotes around certain things I ask for, then when I say what is the source of that quote? they say oh I was paraphrasing and that isnt a real quote.
At least wikipedia has sources that probably support what it says and normally the quotes are real quotes. LLMs just seem to add quotation marks as, "proof" that its confident something is correct.
I dont know about that! In theory it sounds good. I know a company that hired a very good hands on cto who then hired 5 50k entry level engineers that was largely the extent of their team for 1-2 years. Then they started to hire more senior people.
I'm sure the cto did a massive amount of training early on but this is a near billion dollar company in a fairly complicated industry. You dont HAVE to have 4 incredibly senior super engineers as your first hires. It might make coding easier early on, but its going to make hiring much much harder.
I don't think you need "super engineers" either. They just should have made it through their first mistakes on someone else's money. If your founding team is not technical, it's important that one of them has seen the problems that will come up in your first 5 years.
No matter what you do, you will make wrong decisions and need to fix things once you need to scale. That's the way of startups. However, you also need to prevent the high level footguns such as OWASP top 10 and exponential algorithms with minimal supervision.
