Many people want privacy and control over the vehicle they're in, and will pay a premium for it. When you take a bus you're sharing it with random people, can't stop to take a break whenever you want, and can't go directly door to door.
Trains can be a superior alternative depending on what country you're in. In the U.S. we're far behind some other countries in high speed rail infrastructure, so over long distances trains are usually slower than driving.
If there is political will to fund the research needed and create the infrastructure for autonomous highway driving lanes, surely politicians in the US can find the incentives to fund the infrastructure needed for extra buses (including luxury lines with first class seating; for those willing to pay the premium) and train lines.
Edit: As an example of political will for the established and proven solution of mass public transit system, over the unproven non-existent solution of autonomous highway driving lanes. Look at the steam (pun intended) the idea of establishing high speed rail between Portland OR, and Vancouver BC is getting from the public and politicians alike.
Positions: AI Researcher, Developmental Roboticist, Software Engineer
We are building a unified algorithmic architecture to achieve human-level intelligence in vision, language, and motor control. Currently, we are focused on visual perception problems, like recognition, segmentation, and scene parsing. We are interested in general solutions that work well across multiple sensory domains and tasks.
Using inductive biases drawn from neuroscience, our system requires orders of magnitude less training data than traditional machine learning techniques. Our underlying framework combines advantages of deep architectures and generative probabilistic models. We use modern software engineering practices, and we strive to maintain a codebase and a culture that are a joy to work in.
We have raised ~$70M in funding and are not constrained by publication, grant applications, or product development cycles. At Vicarious, there is room to develop new approaches that would otherwise not be supported in academia or industry.
The Vicarious team leverages progress in machine learning and computer vision communities, and we are always looking for exceptional researchers to join our team.
You could argue that building software has a higher potential for complexity than work in any of those fields. So how do you measure someones ability to be good at that within a reasonable time frame using limited resources (interviewer time)? You're always going to have a "broken" process with those limitations, because you can't test for every possible scenario they may encounter. This leads to a small subset of questions that you use to generalize ability, which leads to errors.
There are two things that guarantee at least a nominal level of competency in those fields:
1) For junior positions, both have professional accreditation, with standardized testing that ensures a basic level of competency. Not to mention the mandatory schooling (in most cases).
2) If you screw up as a doctor or lawyer, you can end up with official sanctions on the public record. If you screw up too bad, you lose your ability to continue to do your job.
I've worked with plenty of dead weight developers who wouldn't pass even these nominal competency tests.
Further, it just seems to me it's easier to benchmark your successes as a doctor or lawyer. At least in a way that has meaning to your potential employer.
I think part of that has to do with the fact we pretty much all work on teams. The actual projects themselves might be somewhat verifiable, but figuring out that developer's actual contribution is a pure crapshoot.
I list of successes for a doctor or lawyer are going to be both more individual, and also verifiable (i.e., less likely to be bullshit).
I'm not a doctor, but from the outside, it seems that practicing medicine is mostly about memorizing a whole bunch of things and then doing them correctly over and over again.
Law actually seems quite similar to programming. You can think of the jury as your users and facts/precedent/laws as the statements available in your programming language. Then your job is to assemble the statements into a program that compiles and that your users want to buy.
I like the law/programming analogy, but theres probably more of a margin for error when your job is to convince some people, depending on if you're prosecuting or defending. If you make even a small mistake when programming, it could break your entire program.
You misinterpreted what I was trying to say. I was simply trying to highlight that theres a difference between dealing with people and dealing with a perfectly logical machine, to support the point that interviewing programmers is harder than interviewing lawyers. And I'm not a programmer.
> There are easily many more programmers who work on potentially life-or-death systems than there are lawyers who litigate death-penalty cases in court.
But potentially life-or-death cases are not limited to death penalty cases, they are just the most obvious class of cases that are life-or-death.
There are far greater numbers (and proportion) of lawyers who work on potentially life-and-death work -- not limited to death penalty cases -- than programmers who do so.
Well, the OP said "sentenced to death" specifically, which is why I mentioned the death penalty. But ok. Either way I still don't think I agree, though frankly I'm just going off gut feeling and don't have any numbers. But think about how much medical device software is out there, plus industrial control equipment, airplanes and other vehicles, military stuff, etc. I know on HN the image of "programmer" is "person taking VC money to write a photo sharing app" but there's a lot of other work out there.
Though for what it's worth this is less a "programmers are awesome and important!" argument than it is a "don't get your view of lawyers from television shows" argument -- if the OP had gone with doctors or something I wouldn't have said anything.
1) They usually just measure the amount of effort a person has put into studying interview questions. Whether or not the ability to do this translates to being a better engineer is debatable.
2) An interviewer almost always exercise some form of personal bias, whether it be educational, personal, etc. This doesn't always show up in written feedback, but the interviewers with stronger personalities usually dominate interview debriefs, and often influence others into hire/no-hire decisions. This is especially prevalent in smaller startups where the process is more informal, things move quickly, and decisions are based more on gut feelings.
I had a 800+ page study guide while living in SF for the ridiculous technical interviews they'd put you through. Then you'd see their code base and realize they've never actually done anything that would remotely resemble best practices.
The best part though was realizing if you didn't answer that one question exactly how the "brilliant" person interviewing you wanted it answered, you were done. So at that point I'd quiz them on all their shortcomings that were evident based on what they'd told me.
In my experience hiring it's not that difficult. Good attitude, good aptitude, genuine interest in the field (software engineering), ideally interest in the applied product (if not a software product), decent communicator and good hygiene. If they've done well in those areas, I've never had to let someone go.
Lol, no. It's mostly just an amalgamation of all the technologies and stupid fucking interview questions that you get.
I have 10-12 different documents. CS/OO (basics for reminders with some simple algorithms), .Net, SQL (I always forget this shit, it's why I have data layer and use ORMs + LINQ), LINQ, jQuery, Vanilla JS, HTML5+CSS, Architecture/Patterns, ASP.Net vs MVC, Tuning, etc.
Haven't updated them in a few years because I left the bubble. My interviews in the midwest are typically an hour or two at most with very little quizzing. At worst they ask you to make them a small simple app (which I find irritating but better than SF interviews).
Your company is appropriately named, as hiring for sales is certainly more of an art than hiring engineers. It's difficult to hire for sales and other customer facing positions without taking into account personality fit and likability, which are hard to measure/quantify and will often result in someones idea of unfairness.
In my experience the lack of communication is caused by a combination of workload and lack of experience. A lot of the larger tech companies have an assembly line approach to recruiting, with teams of coordinators, sourcers, and recruiters each handling a portion of the process.
These teams tend to grow fast and hire of a lot of junior people - that lack of experience combined with pressure and a huge volume of interviews(at a fast growing firm) results in a lot of inconsistent communication. When a sourcer/recruiter is dealing with 5-10 interviews a day with 80% of them not making the cut, sometimes they make the decision to prioritize building pipeline over closing the loop properly with people. And sometimes people just have poor time management abilities and let things get lost in the shuffle.
Ive always offered to give detailed feedback to my candidates that didn't pass a technical screen. I'd say about 80% of them were eager to hear it, and were grateful to get information that could help them get better at coding, or at least interviewing. It leaves people with a good impression of the company, and you get the satisfaction of knowing you helped someone. You aren't going to get sued for telling someone which type of sorting algorithm is most efficient for x sized data set.
Those have usually been ones that did very poorly, so they probably already have some idea of what they were missing.
Some candidates have other offers to fall back on and just don't care that much, and some just don't want to discuss technical details with someone in a non technical role, which is understandable.
Trains can be a superior alternative depending on what country you're in. In the U.S. we're far behind some other countries in high speed rail infrastructure, so over long distances trains are usually slower than driving.