dms105

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.

Vicarious (http://www.vicarious.com) | Union City, CA | Full-time | Onsite

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.

Interested? Apply at http://careers.vicarious.com/

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.

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 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.

The real weaknesses of technical interviews are:

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.

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.

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.

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.