The sad reality of programming interviews is that it's absolutely necessary to ask several near-trivial questions in order to flush out the candidates with awesome resumes and impressive degrees who simply have no idea how to analyze a simple problem and solve it using a computer.
Lately, I've been asking "given the starting and ending times of two calendar appointments, determine whether or not they conflict." No loops, no fancy algorithms, no tricks... and asking it has not been a waste of time. I get people writing doubly-nested loops over all of the seconds in the two intervals, comparing for equality; I get multi-line predicates full of redundancy that still yield false positives and negatives; it's depressing as hell.
It's all fun and games until one of your appointmets is specified in rfc2550 format, and the meeting room is on a big ship crossing the international date line on the same day daylight savings time changes for the ship's country while a new timezone is voted into effect. Meanwhile the other meeting room is a videoconfrerence between the international space station and a ship travelling at close to the speed of light, but the real twist is the two meetings don't actually have anyone in common!
I used to disbelieve hiring managers regularly encountered candidates who actually couldn't code, or whatever other basic technical thing was reported on their resumes. Such a possibility - even the audacity of it on a conceptual level - simply seemed beyond the pale for me. I had interviewed before and not done well, and that I could absolutely understand. But I had no way of relating to the idea of someone entering an interview without the fundamental mental schema requisite for doing the job.
Then I started interviewing people for engineering and security engineering roles. That's when I realized that unless you put a lot of effort into curating your candidate pipeline, you interview engineers who literally (without exaggeration!) cannot complete anagram toy programming questions in their "favorite languages." That was a sobering moment for me.
I'm in agreement that a lot of tech hiring is suboptimal, selects for noisy heuristics and is even (sometimes) sadistic. But I've also met engineers - typically people who have not done interviewing or hiring much - who think that reports of fizzbuzz failures have been greatly exaggerated. They have not been exaggerated.
I haven't interviewed anyone in over a year, but back when I was doing it weekly I used to mentally sigh with relief when the candidate I was talking to could actually approach technical questions, even if they ultimately didn't give winning answers. It is a sad reality indeed; the bar is low enough that you have an edge by merely engaging with the problem and reasoning about it with technical competence in an interview.
I think the best part of this is how many people are getting it wrong in the comments here or not fully thinking it through. Perhaps it's not as easy a question as you think it is in the heat of the moment during a stressful interview?
It's actually a tricky problem to think clearly about unless you start enumerating the cases, or get pen and paper out to draw some boxes. I don't think it's completely trivial to verbalise. But I also don't think a competent programmer should fail to work it out.
I like the problem, and I'll probably use it in future :) It'll be a low bar for those times where you're getting the impression that a bigger task will be beyond the candidate, and you want to cut your losses early.
FWIW, I've seen similar complete failures to reason when applied to the even simpler problem of testing to see if a point is inside a rectangle. Some people seem to have a very underdeveloped one dimensional measure function in their brains.
I have similarly asked "write a function, minimum(), that takes a list of integers and returns the smallest integer in the given list" for quite some time. It's disturbingly effective.
I've always asked something that involved a loop, to ensure that candidates understood how to write a for loop.
(I have a variant of the above, a "more complicated" question, that involves maintaining two pointers/iterators; that removes another huge chuck of candidates…)
Depending on what you're hiring for, it's really not all that depressing.
If someone has been doing maintenance programming in a company without excellent culture that values code quality - their brains start to rot pretty quickly.
Five years later, they know how to debug, estimate, work on a team, just not really develop anything from scratch or think critically.
If you want people to do real development, those are hard to come by. If what you really need is someone to maintain some bloated codebase and make it worse, but not too fast, then most people will do just fine.
Another thing is: what do you really want from a candidate? What led you to start asking them trivia questions in the first place?
The really good ones will be put off by trivia because it brings them zero value. If you ask questions that actually pertain to the field you're hiring for, it'll go over much better.
For example I applied to work at a major bank, and got asked a bunch of security questions, which exposed me not understanding how main in the middle attacks worked. The interviewee had requested that I go home, do a bit of research and email them the answer.
This brought them value because they found out that's an area I have little knowledge in, and it provided me with value because it pointed me in the right place to go research.
Trivia puzzles don't add value to anyone. Frankly if you're doing trivia and are upset by the response you're getting, a part of that is your fault :)
> given the starting and ending times of two calendar appointments, determine whether or not they conflict.
Say the first appointment goes from a to b and the second goes from c to d. What does it look like if the appointments _don't_ conflict? This happens just when one appointment ends no later than the other begins; in other words, when b ≤ c or d ≤ a. So, the appointments conflict just when not(b ≤ c or d ≤ a). We can then distribute the negation using [De Morgan's laws](https://en.wikipedia.org/wiki/Negation#Distributivity) to arrive at this: the appointments conflict just when b > c and a > d.
The most logical and clear answer for me (assuming I didn't already screw up by making assumptions about the data format, problem definition, etc.) is:
1. Figure out which appointment starts first
2. Check if first_appointment.end > second_appointment.start
So:
boolean AreAppointmentsConflicting(int start1, int start2, int end1, int end2) {
// first and second refer to the start time of the appointments.
// The first appointment is the one with the earlier start time.
int first_appointment_end, second_appointment_start;
if (start1 > start2) {
first_appointment_end = end2;
second_appointment_start = start1;
} else if (start1 < start2) {
first_appointment_end = end1;
second_appointment_start = start2;
} else { // same start time
return true;
}
return first_appointment_end > second_appointment_start;
}
The problem with interviews is that there is no time for false starts. When approaching a coding problem in real life, I pick a solution that seems to be right.
Half the time I pick a good solution and half the time I've rushed in and picked the wrong one.
If I have picked the wrong one, I know within 30 mins that it is a flawed approach, but have usually explored the problem sufficiently to pick a good solution. The interview unfortunately ends after 30 mins.
I should also add that I'm not much better at this after 13 years of professional development than I was when I left uni, when it comes to manipulating linked lists and arrays. My systems design is a lot better though.
Spending a week working beside an engineer (or seeing how they complete a substantial project) almost certainly provides a better measure of their abilities than watching them solve interview problems for 1 hour
Trial employment is expensive for the company.
[...]
Trial employment (and large take-home projects) are expensive for the candidate.
I can't help but think there's way to mitigate that expense among several (dozen) companies.
Triplebyte is already interviewing for other companies, why not set a low bar and hire everyone who passes it for a week? Charge your clients accordingly. If you have 25 clients hiring for overlapping skills, have them all pay to hire a person for a week.
40 hours of of labor / 25 clients = 1.6 hrs of labor per client, or about what it costs to do a single technical interview.
Meanwhile, the interviewee gets to do a single, focused project for a week, but effectively interviews with 25 companies!
I can get on Dice right now and find over 100 openings for python/java/golang/javascript/c++ engineers, certainly all of those companies would benefit from something like this.
More power to Triplebyte if they can figure out how to take those projects and turn it into a client deliverable on top of defraying interview costs.
If I'm already employed, it be weird to take a week off just to work for another company. Also ramp up time takes at least a day or two. This whole process seems troublesome for both the employee and employer
IMO, trial employment works because interviewer gets to spend a week with the candidate personally to get a feeling of how they approach and solve problems. Having Triplebyte do that without the interviewer being there to work with the interviewee on something, then it wouldn't be any different from an hour long interview
> Meanwhile, the interviewee gets to do a single, focused project for a week, but effectively interviews with 25 companies!
Isn't this basically what bootcamps are about? (at least from a job seeker's perspective)
In practice, only those without jobs have the time to attend one... and if one isn't actively working in the field, then 2-3 weeks might be better than 1 week.
That's an interesting idea! The hard part would be convincing companies to trust an external trial week fully (part of what's great about a trial week is the chance to actually see how an engineer will interact with your team / your problems). But I like the idea!
I find it odd that so many comments here highlight the fact that people are giving interview questions that have little to nothing to do with day-to-day employment tasks.
It seems to me like an enormous amount of time wasted for both interviewers and interviewees.
When considering someone for a development/engineering role there are a few basic questions to figure out:
1. Does this person have competence within our technology stack?
2. Can this person communicate clearly?
3. Is this person productive/can this person be productive in our environment?
4. Does this person have characteristics that will allow them to succeed in our environment?
Making people jump through hoops like some sort of dancing monkey while they are on a job hunt is needlessly cruel and is a waste of everybody's time.
If you regularly see people who can't succeed with what you consider basic engineering questions, you either have a recruiting problem or you yourself have a communication problem.
If you expect an interview candidate to expend 8 hours or more working on interview tasks, you should be presenting a unique enough opportunity to justify it.
If you expect an interview candidate to whiteboard a solution to a coding problem that they received in the room, that should be part of your everyday work experience and you should go through the process yourself in front of them so that they have an understanding of what your expectations are.
If you want to review their code and talk with them about it to determine competency, provide an example of your own code and a set of questions and answers that would be successful.
Don't put engineers through a gauntlet of challenges that you would have trouble successfully navigating under the pressure of feeding your own family. They have more than one company they are interviewing with and each company has their own focus. Put them in a position to succeed and give them the chance to do so. That's what you want out of your own people - the ability to succeed given a reasonable amount of guidance and clear parameters for success. If you can't provide the guidance or the parameters for success for an interview, how can anyone expect to succeed in your actual working environment?
My own 2 cents for interviewing, for engineers and most other vaguely technical positions but perhaps broadly applicable:
- Don't ask them to whiteboard, especially don't ask them to whiteboard some absurdity
- Don't put a panel of 5-10 people against a single candidate, but if you must absolutely (why?) do not do it on the first interview
- Don't ask time-wasting stupid questions about manhole covers, boiling bagels on mars, overlapping clock hands, or how many eggs fit into a phone booth
- Don't put someone into a socially awkward situation
- If you ask a knowledge question and the response is something like "I don't know, but I would google it" that should be acceptable if they are demonstrably capable of using what they find
- Do ask them to walk through their own projects, their code, their past work/contributions, etc
- Do try to effectively convey the corporate culture so the candidate can know if they are a good fit or not ahead of time
- Do try to accurately convey what their actual job duties and day-to-day work will be
I've taken recently a row of interviews. I've had my first whiteboard exercise and it wasn't as bad as I've expected to be. It actually proved to be very useful, as I could abstract away details that I otherwise had to deal with if I had to implement the solutions on a computer. I've also had those five interviewers on the other side of the desk! It was pretty funny for me, but I concede it may have been stressful for somebody else.
> background-blind interviews, looking at coding skills, not credentials or resumes.
Subtext: "Did you create a famous open source tool, write a book, have patents in your name or architect some amazing system at a big company? Doesn't matter! Our hiring process prefers code monkeys who can solve our puzzles instead of system thinkers."
> An interview can result in a bad engineer being hired and later fired (a false positive).
Subtext: "A hire can either be good or bad. It's never management's fault if it doesn't work out."
>Subtext: "A hire can either be good or bad. It's never management's fault if it doesn't work out."
I agree that the article gets this wrong. It reminds me of Diego Forlan's time at Manchester United.
Diego Forlan is/was an Uruguayan striker at Independiente (Arg) where he scored 36 goals in 77 games (a very good rate). He then moved to Manchester United (Eng) in January of 2002 and was anticipated to take off. He made 18 appearances in the 2001-2002 season but failed to score. It took him until October to net his first Premier League goal.
He was loved by the fans as he has/had a great attitude and had some delightful near misses. He also famously scored twice against Liverpool[1]. But he continued to struggle at United, scoring only 17 goals in 63 appearances until he was sold to Villareal (Esp) in August of 2004. In his first season at Villareal he won the Pichichi Trophy (golden boot for La Liga) and the European Golden Boot. What a turnaround!
Forlan went on to have a terrific career and is considered one of the best Uruguayans to play modern football (soccer). His time at United was certainly a misstep but it wasn't because he was bad. And it wasn't because United were bad. It just didn't work. Sometimes it just doesn't work.
It's hard to know if a patent holder or system architect actually did the work or just took credit for it. It's easy to check if someone can print out a binary tree. Certainly a "system thinker" who can't write the simplest code and assumes it's for "monkeys" to do it is worthless both as a programmer and in any higher-level capacity, whereas someone who can program might be able to do meaningful higher-level work.
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)
I had a guy work for me that was very academic minded regarding programming. He had a hard time letting go of the "pure" way of doing things and taking a good/practical approach to just getting stuff done. It can definitely be, but won't always be, a detriment in my experience.
I have a CS degree from CMU, and I've only run into that sort of attitude once. The interviewer nit-picked my solution to some character array manipulation question. I didn't get an offer. The interviewer wrote some snarky comment on his Twitter the day after my interview; something about "the difference between a computer scientist and engineer". Six months later his company was bought and chopped up. He got laid off. Karma's a bitch.
Conversely, I've been hired, without a formal interview, twice merely for having gone to CMU. I guess it can work out either way.
In senior positions CS knowledge is less relevant day-to-day, because your experience overrides a lot of that theoretical stuff. However, whenever I apply to companies, the questions about basic CS usually result in me turning down interviews. It would be a poor use of my time to memorize that stuff again only to not use it beyond the interview.
I think it's largely just human nature. People don't know what they don't know, and those who "make it" without college are often particularly disdainful of academics. They may also be hesitant to hire those with a deeper background (which is a general phenomenon in many areas). In many fields, the percentage who can "make it" without higher education may be higher, but it's certainly do-able in our industry -- especially if they stick to a certain kind of software. Someone in this position may develop a real knack for avoiding hard problems (in the computational complexity sense) without ever quite realizing that is what they are doing. I almost didn't go to college, since I thought I knew it all, and had plenty of offers when I graduated high school. One of the most general things I learned was how much useful stuff there was to know, that I would have never fathomed.
In my experience, people are often hesitant to hire people who are higher on some (perhaps tacit) measure of nerdiness. Only when people want to win badly enough and it's clear that others are doing better, will many people start questioning such biases.
Too much focus on academic topics is likely a sign of inexperience. If the candidate had good real-world experience, they could (and should) speak of practicalities instead of theory. If the explanation involves a reasonable amount of theory, that's all well and good, but too much is an orange flag because it signals inexperience. It may also signal a propensity for dwelling on theory instead of Getting Things Done(TM). Companies almost always favor iterative execution of imperfect systems over protracted theorizing/analysis.
Depending on context and delivery, overfocus on academics could also be interpreted as snobbery, giving an impression that the candidate is difficult to work with, or that they think less of potential colleagues who don't have the same formal training.
Since people in this thread are trotting out the old "we have to FizzBuzz people to weed out the millions of fake coders" argument:
Remember that FizzBuzz was originally proposed as a response to the number of CS degree holders who allegedly could not code their way out of a paper bag.
I don't care if someone can derive the hierarchy of Turing degrees from first principles. I care if they can do the job I'm trying to hire for.
I think we all know people who are very detail oriented and will argue ad infinitum about minutiae, but don't actually get a lot done in a speedy fashion.
I imagine they correlate an over interest in CS concepts with said group.
We've had success with take-home coding challenges.
After 1-2 technical phone screens, we send applicants a coding challenge for which they have 48 hours to complete. The coding challenge is representative of some of the work we do (e.g. Given our API, create a D3 visualization of X) and should take applicants several hours to complete.
In submissions we look at everything from overall program structure and approach to applicants' attention to detail and usage of good industry practices.
This coding challenge quickly weeds out applicants that interview well but code poorly and is an efficient way for us to see the quality of work we can expect from them (and conversely, the type of work they can expect to do with us).
After a successful challenge, we bring applicants in to meet the team. At this point, it's largely just about culture fit.
Do you specifically hire D3 developers? This sounds like a pretty difficult "coding challenge" for a non-D3 guy, let alone someone who may not even primarily use javascript. Having used D3 sparingly before i've found it something that requires a fair amount of upfront domain knowledge to get much done beyond something extremely simple (unless of course you copy an existing example, which is what I always did). This seems unreasonably difficult for someone with no prior knowledge to accomplish in a 48 hour window whilst working etc -- you may find you are inadvertently optimizing your interview process for the unemployed with this kind of time limit / coding investment.
I've performed interviews and phone screens for years and out of all the techniques I've tried all of them typically end up with me thinking I'm doing it wrong. Basic domain questions, problem solving, white boarding, white boarding along side the person helping them out, coding in an IDE, take home projects. As of today, in Kansas City, I'm looking at around 4% pass rate, and close to 90% utter face palming failures.
I check my ego at the door, I try to make the person as comfortable as possible, small talk, help them out as much as I can, provide them with answers or explanations when they get something wrong. I've never asked an algorithm or data structure question, I've rarely asked a patterns question. Most people can't answer basic every day questions.
Overtime my goal in interviews turned into making sure the interviewee left with more domain knowledge than when they came in hoping it will help them do better somewhere else.
Ended up creating a pre-screening service that asks the same basic questions and in the end provides the user with a study guide based on how they answered. Currently piloting with two local recruiting companies and I'm finding the same similar statistics of failure/success. Maybe that makes me the issue :)
As someone with an actual accredited engineering degree, I find it bizarre that Silicon Valley has decided that the term "engineer" doesn't even need to be qualified anymore. Even without getting into the flame war over whether "software engineers" are real engineers or not, there's a very large pool of engineers to which this post doesn't apply at all. I can't be the only one in the latter pool that reads HN, can I?
Where I work, we'd be totally happy to ask interviewees how to reverse a binary search tree. As soon as an actual developer creates a pull request that does as such. Which hasn't happened yet. So we don't ask about things like that. And everyone seems happier.
Here's a concept I had a question about that I don't think gets discussed that often...
If a company were to offer a base salary at a mere third of the Google base salary for the same job, why should an applicant have to copy Google's depth of computer science abstraction in the coding interview?
Is the onus on the developer for even entertaining such a demanding question at a low pay, or does the current economy favor employers in such a way that developers have no other choice?
Or rather, is the knowledge of available jobs asymmetric enough to where employers can pay pennies, piss, and peanuts for A-level employees?
Honestly drop the question/answer aspect for technical checkouts. Offer a problem then work with them to solve it. The most important aspects are two fold, What questions do they ask, and now that you are being cooperative and a team mate, how do they interact with you.
EDIT: But during the entire process keep in mind they are hopefully interviewing your company. Far too many companies forget this aspect and the entire process has become lopsided in favor of companies making candidates jump through hoops.
Looking for a job has become a full time job. In depth technical discussions about the technicalities, then about technical quirks, onsite visits and time spend on researching what on earth the company is doing and what their project is about, then the curse of the industry - take home assignments. Once I signed my last employment contract I said to myself "I'm exhausted, there is no way I'll move a finger during the first months of employment in this company".
Also I learned to be more picky. "Want to see my code and apps? Show me your code, show me how you work!" Eclipse required? Bad workflows with weird limitations? "This is how we do it here, it works for us" attitude? High discipline environment with daily standups? Cheapskate workplace/outsourcing center? Sorry, I'm passing.
>"After an engineer passes our process, they go straight to the final interview at companies we work with (including Apple, Facebook, Dropbox and Stripe)."
Can anyone from any of these companies confirm this? This strikes me as really odd. So only one employee from FB, Apple, Dropbox, and Stripe needs to interview a candidate that Tripplebyte say is a "Go"? I'm having a hard time believing that.
Interesting read from the POV of the staffing agency and hiring company. But why should I jump through those hoops when I don't even know if I'm interested in the job? I really think the hiring companies need to sell me on them before they ask me to spend an hour of my time.
At my company our engineers defined the following process.
First, we defined the skills we're looking for i.e. Programming / SysAdmin / Cybersecurity.
Our process goes as follows:
1. We ask candidates to answer a quizz by phone, with questions in the 3 chosen fields. Duration = 1h.
2. We ask candidates to solve remotely with Google Docs 5 real-world problems asking for skills in Algorithmics, Data Modeling, Object-Oriented Programming, Software Design, and Parsing. We also add a bonus question like "how many people can get into a train". Duration = 1h.
3. We have a HR meeting at our office with a non-technical member of the team. Duration = 1h.
The quizz helps us to remove of our list the candidates that do not have the technical culture we're looking for, and to see what they already have worked on.
The 5 problems helps us to see how the candidates can code, the bonus question helps us to see how they approach new issues and manage their stress.
The final HR meeting is very typical: we try to see if we would be happy to take a 6 hours long flight with the candidate.
Most candidates do not go through first step, and roughly half on them do not go through second step.
This simple process definitely helped us to reduce the time spent on hiring and to make the really good candidates shine.
[+] [-] pklausler|8 years ago|reply
Lately, I've been asking "given the starting and ending times of two calendar appointments, determine whether or not they conflict." No loops, no fancy algorithms, no tricks... and asking it has not been a waste of time. I get people writing doubly-nested loops over all of the seconds in the two intervals, comparing for equality; I get multi-line predicates full of redundancy that still yield false positives and negatives; it's depressing as hell.
[+] [-] missblit|8 years ago|reply
[+] [-] dsacco|8 years ago|reply
Then I started interviewing people for engineering and security engineering roles. That's when I realized that unless you put a lot of effort into curating your candidate pipeline, you interview engineers who literally (without exaggeration!) cannot complete anagram toy programming questions in their "favorite languages." That was a sobering moment for me.
I'm in agreement that a lot of tech hiring is suboptimal, selects for noisy heuristics and is even (sometimes) sadistic. But I've also met engineers - typically people who have not done interviewing or hiring much - who think that reports of fizzbuzz failures have been greatly exaggerated. They have not been exaggerated.
I haven't interviewed anyone in over a year, but back when I was doing it weekly I used to mentally sigh with relief when the candidate I was talking to could actually approach technical questions, even if they ultimately didn't give winning answers. It is a sad reality indeed; the bar is low enough that you have an edge by merely engaging with the problem and reasoning about it with technical competence in an interview.
[+] [-] weaksauce|8 years ago|reply
[+] [-] barrkel|8 years ago|reply
I like the problem, and I'll probably use it in future :) It'll be a low bar for those times where you're getting the impression that a bigger task will be beyond the candidate, and you want to cut your losses early.
FWIW, I've seen similar complete failures to reason when applied to the even simpler problem of testing to see if a point is inside a rectangle. Some people seem to have a very underdeveloped one dimensional measure function in their brains.
[+] [-] deathanatos|8 years ago|reply
I've always asked something that involved a loop, to ensure that candidates understood how to write a for loop.
(I have a variant of the above, a "more complicated" question, that involves maintaining two pointers/iterators; that removes another huge chuck of candidates…)
[+] [-] alexashka|8 years ago|reply
If someone has been doing maintenance programming in a company without excellent culture that values code quality - their brains start to rot pretty quickly.
Five years later, they know how to debug, estimate, work on a team, just not really develop anything from scratch or think critically.
If you want people to do real development, those are hard to come by. If what you really need is someone to maintain some bloated codebase and make it worse, but not too fast, then most people will do just fine.
Another thing is: what do you really want from a candidate? What led you to start asking them trivia questions in the first place?
The really good ones will be put off by trivia because it brings them zero value. If you ask questions that actually pertain to the field you're hiring for, it'll go over much better.
For example I applied to work at a major bank, and got asked a bunch of security questions, which exposed me not understanding how main in the middle attacks worked. The interviewee had requested that I go home, do a bit of research and email them the answer.
This brought them value because they found out that's an area I have little knowledge in, and it provided me with value because it pointed me in the right place to go research.
Trivia puzzles don't add value to anyone. Frankly if you're doing trivia and are upset by the response you're getting, a part of that is your fault :)
[+] [-] bumbledraven|8 years ago|reply
Say the first appointment goes from a to b and the second goes from c to d. What does it look like if the appointments _don't_ conflict? This happens just when one appointment ends no later than the other begins; in other words, when b ≤ c or d ≤ a. So, the appointments conflict just when not(b ≤ c or d ≤ a). We can then distribute the negation using [De Morgan's laws](https://en.wikipedia.org/wiki/Negation#Distributivity) to arrive at this: the appointments conflict just when b > c and a > d.
[+] [-] FT_intern|8 years ago|reply
1. Figure out which appointment starts first
2. Check if first_appointment.end > second_appointment.start
So:
That can be shortened to: Or shortened even further in https://news.ycombinator.com/item?id=14641485The third answer would get massive upvotes for brevity on LeetCode. The first answer would be preferable for readability in an actual code base.
[+] [-] macca321|8 years ago|reply
Half the time I pick a good solution and half the time I've rushed in and picked the wrong one.
If I have picked the wrong one, I know within 30 mins that it is a flawed approach, but have usually explored the problem sufficiently to pick a good solution. The interview unfortunately ends after 30 mins.
I should also add that I'm not much better at this after 13 years of professional development than I was when I left uni, when it comes to manipulating linked lists and arrays. My systems design is a lot better though.
[+] [-] venture_lol|8 years ago|reply
[+] [-] padobson|8 years ago|reply
Trial employment is expensive for the company.
[...]
Trial employment (and large take-home projects) are expensive for the candidate.
I can't help but think there's way to mitigate that expense among several (dozen) companies.
Triplebyte is already interviewing for other companies, why not set a low bar and hire everyone who passes it for a week? Charge your clients accordingly. If you have 25 clients hiring for overlapping skills, have them all pay to hire a person for a week.
40 hours of of labor / 25 clients = 1.6 hrs of labor per client, or about what it costs to do a single technical interview.
Meanwhile, the interviewee gets to do a single, focused project for a week, but effectively interviews with 25 companies!
I can get on Dice right now and find over 100 openings for python/java/golang/javascript/c++ engineers, certainly all of those companies would benefit from something like this.
More power to Triplebyte if they can figure out how to take those projects and turn it into a client deliverable on top of defraying interview costs.
[+] [-] angryasian|8 years ago|reply
[+] [-] fwefwwfe|8 years ago|reply
[+] [-] Kpourdeilami|8 years ago|reply
[+] [-] ssivark|8 years ago|reply
Isn't this basically what bootcamps are about? (at least from a job seeker's perspective)
In practice, only those without jobs have the time to attend one... and if one isn't actively working in the field, then 2-3 weeks might be better than 1 week.
[+] [-] dexterdog|8 years ago|reply
[+] [-] ammon|8 years ago|reply
[+] [-] Steeeve|8 years ago|reply
It seems to me like an enormous amount of time wasted for both interviewers and interviewees.
When considering someone for a development/engineering role there are a few basic questions to figure out:
1. Does this person have competence within our technology stack?
2. Can this person communicate clearly?
3. Is this person productive/can this person be productive in our environment?
4. Does this person have characteristics that will allow them to succeed in our environment?
Making people jump through hoops like some sort of dancing monkey while they are on a job hunt is needlessly cruel and is a waste of everybody's time.
If you regularly see people who can't succeed with what you consider basic engineering questions, you either have a recruiting problem or you yourself have a communication problem.
If you expect an interview candidate to expend 8 hours or more working on interview tasks, you should be presenting a unique enough opportunity to justify it.
If you expect an interview candidate to whiteboard a solution to a coding problem that they received in the room, that should be part of your everyday work experience and you should go through the process yourself in front of them so that they have an understanding of what your expectations are.
If you want to review their code and talk with them about it to determine competency, provide an example of your own code and a set of questions and answers that would be successful.
Don't put engineers through a gauntlet of challenges that you would have trouble successfully navigating under the pressure of feeding your own family. They have more than one company they are interviewing with and each company has their own focus. Put them in a position to succeed and give them the chance to do so. That's what you want out of your own people - the ability to succeed given a reasonable amount of guidance and clear parameters for success. If you can't provide the guidance or the parameters for success for an interview, how can anyone expect to succeed in your actual working environment?
[+] [-] notadoc|8 years ago|reply
- Don't ask them to whiteboard, especially don't ask them to whiteboard some absurdity
- Don't put a panel of 5-10 people against a single candidate, but if you must absolutely (why?) do not do it on the first interview
- Don't ask time-wasting stupid questions about manhole covers, boiling bagels on mars, overlapping clock hands, or how many eggs fit into a phone booth
- Don't put someone into a socially awkward situation
- If you ask a knowledge question and the response is something like "I don't know, but I would google it" that should be acceptable if they are demonstrably capable of using what they find
- Do ask them to walk through their own projects, their code, their past work/contributions, etc
- Do try to effectively convey the corporate culture so the candidate can know if they are a good fit or not ahead of time
- Do try to accurately convey what their actual job duties and day-to-day work will be
[+] [-] cyrux004|8 years ago|reply
[+] [-] restalis|8 years ago|reply
[+] [-] kulu2002|8 years ago|reply
[+] [-] mychael|8 years ago|reply
Subtext: "Did you create a famous open source tool, write a book, have patents in your name or architect some amazing system at a big company? Doesn't matter! Our hiring process prefers code monkeys who can solve our puzzles instead of system thinkers."
> An interview can result in a bad engineer being hired and later fired (a false positive).
Subtext: "A hire can either be good or bad. It's never management's fault if it doesn't work out."
[+] [-] fnord123|8 years ago|reply
I agree that the article gets this wrong. It reminds me of Diego Forlan's time at Manchester United.
Diego Forlan is/was an Uruguayan striker at Independiente (Arg) where he scored 36 goals in 77 games (a very good rate). He then moved to Manchester United (Eng) in January of 2002 and was anticipated to take off. He made 18 appearances in the 2001-2002 season but failed to score. It took him until October to net his first Premier League goal.
He was loved by the fans as he has/had a great attitude and had some delightful near misses. He also famously scored twice against Liverpool[1]. But he continued to struggle at United, scoring only 17 goals in 63 appearances until he was sold to Villareal (Esp) in August of 2004. In his first season at Villareal he won the Pichichi Trophy (golden boot for La Liga) and the European Golden Boot. What a turnaround!
Forlan went on to have a terrific career and is considered one of the best Uruguayans to play modern football (soccer). His time at United was certainly a misstep but it wasn't because he was bad. And it wasn't because United were bad. It just didn't work. Sometimes it just doesn't work.
[1] https://www.youtube.com/watch?v=49Zym0gaZqA
[+] [-] yosefk|8 years ago|reply
[+] [-] ammon|8 years ago|reply
[+] [-] jobu|8 years ago|reply
That seems really weird. Academic CS isn't really necessary for most programming jobs, but I can't see how it would ever be a detriment.
[+] [-] rsyring|8 years ago|reply
[+] [-] supran|8 years ago|reply
Conversely, I've been hired, without a formal interview, twice merely for having gone to CMU. I guess it can work out either way.
In senior positions CS knowledge is less relevant day-to-day, because your experience overrides a lot of that theoretical stuff. However, whenever I apply to companies, the questions about basic CS usually result in me turning down interviews. It would be a poor use of my time to memorize that stuff again only to not use it beyond the interview.
[+] [-] threepipeproblm|8 years ago|reply
In my experience, people are often hesitant to hire people who are higher on some (perhaps tacit) measure of nerdiness. Only when people want to win badly enough and it's clear that others are doing better, will many people start questioning such biases.
[+] [-] cookiecaper|8 years ago|reply
Depending on context and delivery, overfocus on academics could also be interpreted as snobbery, giving an impression that the candidate is difficult to work with, or that they think less of potential colleagues who don't have the same formal training.
[+] [-] crdoconnor|8 years ago|reply
Knowing how to code quicksort or reverse a binary tree isn't, but an understanding of normalization definitely is...
[+] [-] ubernostrum|8 years ago|reply
Remember that FizzBuzz was originally proposed as a response to the number of CS degree holders who allegedly could not code their way out of a paper bag.
I don't care if someone can derive the hierarchy of Turing degrees from first principles. I care if they can do the job I'm trying to hire for.
[+] [-] zumu|8 years ago|reply
I imagine they correlate an over interest in CS concepts with said group.
[+] [-] sidlls|8 years ago|reply
[+] [-] mpetrovich|8 years ago|reply
After 1-2 technical phone screens, we send applicants a coding challenge for which they have 48 hours to complete. The coding challenge is representative of some of the work we do (e.g. Given our API, create a D3 visualization of X) and should take applicants several hours to complete.
In submissions we look at everything from overall program structure and approach to applicants' attention to detail and usage of good industry practices.
This coding challenge quickly weeds out applicants that interview well but code poorly and is an efficient way for us to see the quality of work we can expect from them (and conversely, the type of work they can expect to do with us).
After a successful challenge, we bring applicants in to meet the team. At this point, it's largely just about culture fit.
[+] [-] aldarn|8 years ago|reply
[+] [-] cl0wnshoes|8 years ago|reply
I check my ego at the door, I try to make the person as comfortable as possible, small talk, help them out as much as I can, provide them with answers or explanations when they get something wrong. I've never asked an algorithm or data structure question, I've rarely asked a patterns question. Most people can't answer basic every day questions.
Overtime my goal in interviews turned into making sure the interviewee left with more domain knowledge than when they came in hoping it will help them do better somewhere else.
Ended up creating a pre-screening service that asks the same basic questions and in the end provides the user with a study guide based on how they answered. Currently piloting with two local recruiting companies and I'm finding the same similar statistics of failure/success. Maybe that makes me the issue :)
[+] [-] 0xffff2|8 years ago|reply
[+] [-] timebomb|8 years ago|reply
[+] [-] FilterSweep|8 years ago|reply
If a company were to offer a base salary at a mere third of the Google base salary for the same job, why should an applicant have to copy Google's depth of computer science abstraction in the coding interview?
Is the onus on the developer for even entertaining such a demanding question at a low pay, or does the current economy favor employers in such a way that developers have no other choice? Or rather, is the knowledge of available jobs asymmetric enough to where employers can pay pennies, piss, and peanuts for A-level employees?
[+] [-] paulie_a|8 years ago|reply
EDIT: But during the entire process keep in mind they are hopefully interviewing your company. Far too many companies forget this aspect and the entire process has become lopsided in favor of companies making candidates jump through hoops.
[+] [-] expertentipp|8 years ago|reply
Also I learned to be more picky. "Want to see my code and apps? Show me your code, show me how you work!" Eclipse required? Bad workflows with weird limitations? "This is how we do it here, it works for us" attitude? High discipline environment with daily standups? Cheapskate workplace/outsourcing center? Sorry, I'm passing.
[+] [-] bogomipz|8 years ago|reply
Can anyone from any of these companies confirm this? This strikes me as really odd. So only one employee from FB, Apple, Dropbox, and Stripe needs to interview a candidate that Tripplebyte say is a "Go"? I'm having a hard time believing that.
[+] [-] DenisM|8 years ago|reply
Any thoughts on that?
[+] [-] LordHumungous|8 years ago|reply
I agree with this. Better yet ask a multi-part question that has an easy first part and a harder follow on.
[+] [-] danthemanvsqz|8 years ago|reply
[+] [-] andrewstuart|8 years ago|reply
No "reject" decision can ever be reconsidered or questioned by anyone, ever.
[+] [-] altharaz|8 years ago|reply
First, we defined the skills we're looking for i.e. Programming / SysAdmin / Cybersecurity.
Our process goes as follows:
1. We ask candidates to answer a quizz by phone, with questions in the 3 chosen fields. Duration = 1h.
2. We ask candidates to solve remotely with Google Docs 5 real-world problems asking for skills in Algorithmics, Data Modeling, Object-Oriented Programming, Software Design, and Parsing. We also add a bonus question like "how many people can get into a train". Duration = 1h.
3. We have a HR meeting at our office with a non-technical member of the team. Duration = 1h.
The quizz helps us to remove of our list the candidates that do not have the technical culture we're looking for, and to see what they already have worked on.
The 5 problems helps us to see how the candidates can code, the bonus question helps us to see how they approach new issues and manage their stress.
The final HR meeting is very typical: we try to see if we would be happy to take a 6 hours long flight with the candidate.
Most candidates do not go through first step, and roughly half on them do not go through second step.
This simple process definitely helped us to reduce the time spent on hiring and to make the really good candidates shine.