My phone screen technique is more old school but I think works well. I pick their top language or domain (web or mobile or whatever) and ask 10 trivia questions. Medium difficulty questions I'd expect a programmer with any experience to answer. I look for maybe 70% correct and I look for quick answers. You know it or you don't. And I set that expectation up front so they can give me a few "I don't know"s with no penalty.
This is my sanity check and I think it's faster and more accurate than a FizzBuzz and doesn't require screenshare.
>My phone screen technique is more old school but I think works well. I pick their top language or domain (web or mobile or whatever) and ask 10 trivia questions. Medium difficulty questions I'd expect a programmer with any experience to answer. I look for maybe 70% correct and I look for quick answers. You know it or you don't. And I set that expectation up front so they can give me a few "I don't know"s with no penalty.
This is basically what I've found all Triplebyte challenges to be like. It's a bit off-putting at first to be asked to do a "quiz" before anyone will even speak to you, but honestly I've realized it's better for everyone involved than doing the traditional "recruiter runaround" which can introduce bias and be highly inefficient.
> I look for maybe 70% correct and I look for quick answers. You know it or you don't. And I set that expectation up front so they can give me a few "I don't know"s with no penalty.
I like that system. I recently took the TripleByte technical quiz and I liked that "I Don't Know" was an acceptable answer for most of the questions. When paired with the timer (or in your case, looking for a fast answer) it seems like a system that encourages honesty and "moving along" so you don't waste time on questions that you will probably do poorly on anyway.
As an aside, does anyone happen to know what the "levels" of performance on the TripleByte technical quiz are? When I took it (and I realize this will sound like a humblebrag), I was told I did "exceptionally well" and could be paired with "approximately 27 top tech companies", but I didn't feel I did all that well on it at all.
I ask because they say they only invite the "top few percent" of quiz takers to continue, but all I typically see when I search this online is other people mentioning they also did "exceptionally well." Anyone have feedback on the process?
I interviewed as an iOS Developer. Took the initial screening quiz and did "exceptionally well" and was scheduled for an online interview with one of their interviewers. Online interview consisted of making some rather straightforward additions to a very basic core application and getting the features up and running and manually tested. After that it was another series of questions. During the interview the interviewer took several short breaks to record feedback in their system. A few days later I received the decision that they would not be moving forward with my application. Feedback was fairly generic and vague imo with no real suggestions on how to improve other than to practice small coding problems and other suggestions oddly didn't coincide with any of the actual code part I was asked to implement or the questions of the quiz. Nothing was mentioned about my strengths eventhough they claim what they look for is a candidates strengths. I guess I just don't have any? Overall I think the process was on par with other technical coding interviews I've had and the feedback was equally useless.
I love how they mention small. I think small problems test for problem solving and understanding while large engineering questions test for knowledge of libraries that anyone can learn. I know I'm probably overinterpreting the use of the word "small" here.
As an aside, does anyone happen to know what the "levels" of performance on the TripleByte technical quiz are? When I took it (and I realize this will sound like a humblebrag), I was told I did "exceptionally well" and could be paired with "approximately 27 top tech companies", but I didn't feel I did all that well on it at all.
I tried one of their quizzes once, out of curiosity after it was mentioned somewhere I think. The questions I saw were routine enough for an experienced developer and I'd have expected anyone senior to get a near-perfect score. I'm pretty sure I still got shown something very close to what you got shown at the end, though.
That said, the other recruiting site that comes to mind for plugging how selective it is is TopTal, which claims to only take the top 3%. Given that 100% of people I've encountered who claimed to be in that group would also have failed a junior developer interview with me in minutes if not seconds, I'm guessing the population of people who seriously apply to these sites skews very low on skill and experience. Maybe anyone mid-level or above who actually knows what they're doing really is exceptionally good within that population, and even though you didn't feel it went that well you were still a good prospect among their applicants.
I think a lot of companies do this, but it ends up being weird stuff that doesn't happen in the real world like bit shift operators in Java.
It would be excellent if it was all relevant stuff. I took one for a job, about 30 questions. I was really surprised that I got about 93% on it, purely guessing. The person who made the test later told me that if you have enough experience, you'd probably know things like "findViewById" instead of "findViewByID", because it's muscle memory.
Yeah, I hate that. Other folks were asking about truthiness cases in JavaScript which is just so arcane that I'd never expect someone to know all the cases by heart.
But, I have to agree. Some trivia helps quickly identify the people who don't really understand a technology. It's also useful if you're trying to hire an expert in something you aren't.
What do I mean? For example, I'm not an expert in Objective C. I've written quite a bit, but sometimes I need to hire someone who clearly knows more than I do. So what do I do? I ask questions like, how does memory management work? What does autorelease mean? These are topics that someone who's been working with the language for years needs to know! But, someone who really hasn't done much Objective C might not know.
I think that's a great way of interviewing! But don't you fear this only works for smaller companies? Imagine some company like Google or Facebook would do that: I would expect people to just start learning answers by heart..
People more or less memorize a subset of leetcode and CTCI solutions and the bullet points from various scalable architecture books and resources, all of which are provided by recruiters in their email conversations with candidates. Fresh grads, the affluent, and people who have few or no social obligations (e.g. family) spend a few weeks (or months) doing what amounts to cramming for a test to prepare for these things.
By medium I just mean, stuff beyond CS 101. So for Java, I'd ask about standard lib or basic language-specific features or tools. What's the difference between a List, Set and Map? What does the final keyword do? What does it mean for a class to be thread safe? What do you use for dependency management? What's the difference between a checked and unchecked exception?
For JavaScript I can ask about let vs const? What are arrow functions good for? Maybe specific framework stuff if they say they know react.
For general web stuff, I can ask about response codes. What's the difference between 400 and 500 level? What's a CDN for? What is HTTPS?
You can ask basics about version control or CI. Sometimes I'll do process questions about agile.
I try to stick to what they claim on their resume (and what I know about) and can tell pretty quickly if they are actually what they say they are based on how quickly, confidently and succinctly they answer.
"What do you think are the top strengths and top weaknesses of <language X>?"
Doesn't matter what the specific answers are, much less if you even like language X or not. Instead it says: does the person really have an understanding of the language; do they have enough experience to say "well I really do like X, but I do often wish it had feature y of language Z". or "yes, I have a lot of JS experience since that's the job and I sure know how to sling it, but I far prefer Lisp which I found made me more productive than any other. Why? Well because at XXX I was able to do YYY...."
Not the OP, but for iOS developers I've asked: "What's one thing you would change about Objective-C (this was pre-Swift), and what's one thing you would change about Cocoa [the framework that iOS apps are developed with]?" It's the kind of question that there are a lot of good answers to, any experienced iOS developer will be able to answer off-the-cuff, and it gives a good sense of the kind of work that they've done and how (plus it gets across if they know the difference between a language and a framework, which is useful).
I also think this could be very effective first round of screening. The questions don't have to be all trivia though. Something that is simple for legit developers in that domain to answer should also work. Time they take to answer also correlates well with experience.
This is my sanity check and I think it's faster and more accurate than a FizzBuzz and doesn't require screenshare.