An interesting point my co-worker made is that, almost by definition, if an interviewee does not know how to answer a question, they don't know why that question is important or where that type of problem is applied. So from the point of view of an interviewee who's can't do well on all the questions (that's most of us in most interviews) some of the question will always seem like minutiae / lacking application. (Of course, there's also plenty of just bad interview questions)
Using pseudocode is a great idea. We've talked about that. We've not done it because we still need to decide what style of syntax to use (and that will still preference certain programmers). But maybe we should think about it again!
The intent was that node.children would be the giveaway. The question is about BFS, and you'll notice that only one of the answers references the node's children (in a sensible way). The intent was that that would be enough to answer it without knowing python queue syntax (for what it's worth, I know python well and don't have the deque API in my head)
I am actually curious to know of cases of insecure string comparison vulnerabilities being exploited. I think there are real cases. But I tried recently to to this against a toy server over my local network, and could not get it to work without adding a delay to the comparison.
The goal of this quiz is to be a little challenging and fun and maybe educational. It's not to judge whether someone can do a software engineering job!
The answers to the graph problems are indeed fairly straight forward. But asking about why one might use a BST in place of a sorted list prompts interesting discussion. And going into Dijkstra's vs A* and iterative deepening depth first search is (I think) pretty interesting!
This quiz is just supposed to be fun :) We opted for speed over security, on the idea that anyone who cared enough to pull out the answers deserves a 100!
Timing attacks like this still work over a network, you just have to make an LOT of duplicate requests, and average the times. The lucky thirteen attack (https://en.wikipedia.org/wiki/Lucky_Thirteen_attack) is a real example.
Good point about the accidental answers. I'll look at that.
Well, objects in Java are only accessible via references. So the result is behavior identical to Python and JS (primitives are passed by value, objects are passed by reference)
For what it's worth, we run our interviews in the language of the engineer's choosing (including clojure), and get people jobs at Clojure and Haskel and C++ companies. We went with Python for this (toy) quiz because it's the most common language we see among applicants. I tried to add comments to explain anything python specific, and make the question about the underlying logic. But it seems it's still easier for Python folks.
If you understand the graph traversal algorithms in question, there's nothing to memorize. You can just think through the problems. Is it important to understand graph traversal algos? I don't think it is for everyone. But a lot of people who like CS find it interesting. And if you work on, say, a web crawler or a game AI, then you'll need them.
I am sorry that our process makes you feel bad :( The simple truth is that there are a lot of different ways to be a skilled programmer. One ways is being really good at CS (and to people who want skills in CS, talking about DFS is a reasonable low-bar question). However, another way is writing great, well-structured rails code. We work with people all the time who don't have CS backgrounds (we help them get jobs at companies that don't care about CS). The intent of our process is to measure both CS and practical skills (we actually break it down on more axes, but you get the idea).
This does mean that if you go through our process, you will be asked CS questions. But you'll also be asked to code. And not knowing the CS questions is not an obstacle to passing.
Yup, we see that issue too. But in that case, I think it's python specific (how python handles default values). Ruby, for example, does not have that behavior.
Ah, you're talking about going through our regular process and looking for a job? In that case, we try to make it clear that what you're doing is applying for a job (and we require an account creation at the beginning of the process).
This quiz posted here is something we created because some people (like you?) are applying to our process just to answer the questions. So we created this version (which does not require an account creation or ask for an email) and totally gives you a score and shows what we think the answers are.
Re the % scores, they're currently set based on the people we had test the quiz yesterday. May well not have been a representative group! We'll reset them later today.
The truth is that there's just a lot less demand for remote engineers, and among companies that do hire remote, it's usually for very specialized roles. (There are obviously exceptions.) Looking at our stats, about 5% of the companies we work with are interested in remote engineers. We're not going to expand to remote jobs until we have that number up to a point where we can provide a good experince. I don't have a time-frame, but not in the next 3 months (over the next 3 months we're focused on expanding to other cities)
Hmm. We included those issues, because we see a lot of programmers get stuck on exactly those two bugs! (In all sorts of languages, not just Python). I guess maybe that's the definition of a gotcha -- a thing that a lot of programmers get stuck on? In any case, I don't think it's an arcane gotcha! Being clear about references and shallow / deep copies is important.
Hmm. Just checked again. Two of the expressions match neither word, one matches both, and one matches only one.
EDIT: I see. The confusion is over partial match vs whole match. I thought whole matches were standard when talking about regular expression in the abstract, but looks like I was wrong. Just changed the problem to include the anchors. Thanks for pointing this out.
Well, the questions get into other things too.(Character encoding, timing attacks, graph algorithms.) Writing a good single-paragraph description of iterative deepening depth-first search was a challenge!
Good point. I think that objects are passed by reference in a high enough % of language in common use (PHP and C++ are the two exceptions I can think of) that this is a fair question. But if enough people think it's bad, we'll remove it.
We talked a bunch about this. Python and JS are the two most common languages we see on our site, and Python has slightly more compact syntax, which works well in the questions. The idea, however, was not to require any python-specific knowledge. Which question do you think is looking at syntax?
We've been using a quiz as part of our hiring process (at Triplebyte) for the last two years. However, a lot of people do our quiz for fun. So we decided to create a version optimized for this (and hopefully a little education). The problems come from the most common mistakes / misunderstandings we see when giving interviews, and ramp up in difficulty. We put a lot of effort into writing interesting answers.
So... I showed up for this interview without realizing it was going to be on video! Can you see the terrified look in my eye? But Craig did a great job and got me through it. Thanks Craig!
An interesting point is that about half the companies we work with want their front-end developers to show full-stack understanding and strong CS (the argument is usually that they want to hold the entire team to the same standard so that people can move around freely on the between teams). The other half of the companies don’t care about anything other than productive, practical front-end coding (often focusing on speed). We find that front-end interviews value speed a lot.
Yeah. Trial employment better be paid! :) Even with pay, unfortunately, folks with an existing job often can't take the time off. And when people have the option between one company making an offer and another with a trial period, they often go for the offer (which makes sense). The other issue is that a company can't do a trial period with every person who applies (too much cost for the team), so there has to be screening step in front, which sort of just moves the problem to an earlier level.
I do think trial employment can be a great thing. But it's not a universal replacement.