The Technical Interview Rift
blog.techmasters.chatSome useful advice, but something about the overall tone seems a bit off:
You are a manager and it’s time to hire a new developer to join your impressive team of A+ players.
That's where things started to go of course. You're not an "A+ player", and most of your team aren't "A+ players" either. You're just human beings doing the best you can and (hopefully) trying to improve a bit each day -- like anybody else.
No one wants to work with losers. But any (serious) talk of of "We're all A+ players here!" or "I know how to spot A+ players!" is just motivational kool-aid, and ultimately a distraction from the real work you have to do -- including the task of finding the best people you can hire, and who are willing to throw their lot with your cause.
Especially when it's quite often the people hired for their seeming "A+" qualities (which they are able to exude in spades) who turn out to be the most toxic, morale-killing members of your (once) impressive team.
>, but something about the overall tone seems a bit off: [...] You're not an "A+ player", and most of your team aren't "A+ players" either.
I believe you misinterpreted the author's backhanded "compliment" about teams' _self-proclaimed_ "impressive A+ players". His tone is sarcasm if you combine it with the repeated fixation on "Fibonacci" puzzles in the rest of the essay:
- quote: , what possible insight does questions like “solve a Fibonacci sequence” + whiteboard + no internet give you to know about a person fit for a development role?
- Go Beyond Fibonacci Pen/Paper Tests to Assess Candidates
- If you get Fibonacci’ed in your next job interview, perhaps you should look elsewhere? If you are the one doing the Fibonacci’ing, you are doing it wrong.
(In other words, if your team bombards candidates with Fibonacci, you of course will think your company consists of A+ players!)
His "tone" might have tripped the obvious sarcasm detector more readily if he wrote it to say: "it's time to hire a new developer to join your impressive Project Euler hackathon champions. blah blah blah"
Ah - so he's a bit ahead of me (with his sarcasm), then. It's just that I see the "A+" label (and its various synonyms: "phenomenal", "astonishing", "rockstar", "badass", "10x-er", etc.) touted in all seriousness, far too often -- that I guess I've become conditioned to being always a bit negatively triggered by them.
But he also says "After all, the primary purpose of doing technical interviews is to ensure A+ players are identified and are persuaded to join your team. If your process is preventing this, then you are doing it wrong."
That doesn't sound like sarcasm to me...
It may not be in that particular sentence since he's directing that "A+" label towards the candidates. (He's being genuinely charitable towards the job seekers.) However, when he's directing the "A+" label towards the interviewing team, it comes across as a backhanded swipe.
Perhaps calling it "sarcasm" is too strong since his sarcasm is very subtle. If you integrate his entire essay about "Technical Interview Rift", he essentially wants to lecture the "too cool for school" dev teams that pride themselves on Fibonacci puzzles, etc. However, he can't go into full-frontal sarcasm mode like Stephen Colbert / John Stewart because he doesn't want to make the very audience he's trying to reach tune out from his message.
Therefore, he has to dance around his intended message in such a way as to not insult his target. There's probably a better word to describe what he's trying to accomplish but I couldn't think of it so I called his passive-aggressive tone: "sarcasm".
When I see job postings or recruiter messages talking about how they only hire The Best I immediately tune out. At best they'll be extremely misguided and delusional. At worst they'll be massive Dbags
A+ is also relative to the environment. Performance doesn't always extend across companies. Solo programmers who are an A+ in informal environments struggle in environments that require more inter-programmer coordination. And some A+ specialists sometimes struggle when expected to be generalists, and vice versa. Some big company superstars thrive in small companies, but not all. And some startup superstars would fall apart with the structure of Microsoft and Google.
oh you said toxic.
I think Triplebyte has the right idea: essentially a take-home test conducted over a period of a couple of days. It allows a candidate to show off what they can do under realistic conditions, instead of allowing an interviewer to poke at what they can't do under highly unrealistic high-pressure conditions. A typical tech interview is more like a spelling bee than a realistic test of a candidate's abilities: if you happen to get a word/question you know, you look awesome. If you don't, you don't. (Not long ago I screwed up a tech interview because I couldn't remember/figure-out-on-the-spot the iteration condition for estimating square roots by the Newton-Raphson method, and I was not willing to cheat by looking it up on Wikipedia while I was on the phone. Their loss.)
I just wish Triplebyte would expand their outreach beyond YC companies.
Not long ago I screwed up a tech interview because I couldn't remember/figure-out-on-the-spot the iteration condition for estimating square roots by the Newton-Raphson method
(1) Better to say you were unable to "remember", rather than a "figure out". No one ever "figures out" things like the Newton-Raphson method over the phone -- not even people like Isaac Newton or Joseph Raphson (substituting whatever comparable level of distraction on had to contend with in those days, absent telephones -- "while ordering a beer at the pub", I guess).
(2) The use of this question as a binary hiring filter (mindlessly copy-and-pasted from their rough impression of what ever other company is doing in 2016) was a failure on their side, not yours.
Actually, under non-brain-wedgie conditions, I can re-derive Newton-Raphson because I do have a good conceptual grasp of it. (In fact, after I got off the phone, I did it just to convince myself that I could. It took me about five minutes, which is nothing under realistic conditions, but a long time when you're on the phone.) But at the time I had a brain wedgie, and the interviewer just kept pushing and prodding and wouldn't let it go. It was damned annoying. I was sitting there thinking, why are you so fixated on this?
It was definitely their loss because the technical problems they were facing were very similar to ones that I had faced (and solved!) in a previous startup (network optimization problems). But I never even got to talk about that.
Because of that experience, I now make it point whenever I interview someone to always ask, particularly if they're floundering, "What should I ask you about that will let you show off your strengths?" I don't have any qualms rejecting someone who can't answer that question (and a surprising number of candidates can't).
Not to sound too snobby (I would have notrecognized the Newton-Raphson method is by its name either), but I think it is at least plausible to figure out the method on the spot.
If you either know how the first order of a Taylor series looks like or just brainstorm a bit about how the derivative could help you in finding a root, you will figure out the Newton-Raphson method rather quickly. But then, it really depends on the job whether this is actually knowledge the interviewer would want to test.
That said, I completely understand that even if you would have the required knowledge, it is really easy to fumble during a high-stress situation.
figure out in the sense of discover? sure
Figure out in the sense of work out the updates, particularly for f:R -> R, if you already understand NR? That's totally doable in 5 minutes with paper; it's just figuring out an x intercept. And remembering/finding f such that f(sqrt(2)) = 0
I've also been asked, in person, the derivative of x^x. Hope you remember logarithmic differentiation! It's not like, had you happened to not have used this trick for a derivative in the last 10+ years, you could look up and recall in 5 minutes given you understand chain rule. I remembered it, but what kind of filter is this?
"Discover" in the sense of "derive ab initio, truly never having seen an iterative root-finding method, or anything analogous to it" -- like Newton and Raphson both did, separately -- I highly doubt it.
Re-derive your (or my) perhaps-more-than-a-bit-stale-by-this-point derivation, from way back when, under non-interview conditions? Yeah sure -- assuming we were actual math majors, or among the 10% or of CS majors who are burned-in math types.
But under interview conditions? Unless the role explicitly requires an actual math background (or a CS background with emphasis in numerical algorithms), really quite a silly thing to expect of someone.
oops -- when I said "figure out in the sense of discover? Sure" I was unclear, but I agree -- that request would be ludicrous.
That said, I have full faith that Gauss would pass that interview. Probably Euler, Tao, Dantzig, and Turing too =P
But it's not entirely unreasonable for optimization/OR/ML people. Mostly they have to remember how to construct the right function to find the zero of. Most applications of NR just want to find the zeroes of gradients of loss functions.
I certainly am not disputing the silliness... I personally am not good at math at a whiteboard while someone is staring at me. And full disclosure: I remember NR from the picture -- the x intercept of the tangent is (hopefully) closer to the zero than the initial guess.
If these companies would just say, in their job descriptions, that that's the calibre of people they need to debug their glorified hotel booking website (or whatever), then that would make things much simpler for everyone:
"When we say we're looking for the next Norvig or Knuth for this role, we mean it -- and you'll be tested accordingly!"
How could you debug a crud app if you're not Knuth?
Makes no sense.
I have tried using take-home tests before. The level of plagiarism was astonishing. And that's just the plagiarism I could detect.
Even with a problem that's unique to my organization, I don't know how I could trust that the actual candidate themselves was the one who completed it, and that they completed it without unfair assistance (e.g. from other people). Similarly, I have a habit of looking over someone's resume and picking a few random technologies they mentioned to discuss. I'm surprised how often candidates claim experience with a technology and can't really describe what they've done with it or discuss it intelligently. The level of dishonesty is high.
For all of the downsides of interview-based hiring, at least I know what I'm getting (modulo error bars on assessment efficacy).
> I couldn't remember/figure-out-on-the-spot the iteration condition for estimating square roots by the Newton-Raphson method, and I was not willing to cheat by looking it up on Wikipedia while I was on the phone
I don't ask the kind of questions that require obscure knowledge. I just ask questions that you can problem-solve with regular rational thinking, with questions that usually admit a "naive" brute-force style solution that can be improved upon. If you did want to look up some algorithm that would be fine with me, but I am more impressed by a quick and confident reasoning through the problem followed by a fluid implementation of the naive solution, than I am of sophisticated solutions with better algorithmic performance or accuracy.
Isn't getting back plagiarized answers a good indication though? Did you tell them you wanted it to be their own work?
As I have gotten older one of the things I'm cognizant of is the difference between what I mean and what my kids hear. So "take this problem home and solve it" from me means that they should take it home work on it themselves and bring back their best solution. But they might hear it "take this out of my sight, put the answer on it, and bring it back to me." where in the land of "out of sight" there are really no restrictions on what or how they get it done. As a result I find myself being a bit prescriptive, saying "Take this home and work on it, and bring me your solution tomorrow, we're going to talk about your process of how you got to the answer. When we talk, saying 'I asked on Stack Overflow' isn't going to be a good answer, ok?"
Their response will be informative, from moral outrage that I would suggest they can't do the work, to understanding that the integrity of the process was part of the problem set. All of that helps you understand how they approach being asked to do things.
We give take home problems and have no issue with plagiarism. In fact we actively say use the internet, books, etc..., and we still get solutions that are wrong or do not even compile.
The ones that do come back and look good, give us a starting point for the interview. If the person did just copy it from somewhere else they have will have a hard time talking about the solution and various pros/cons.
This is how we do things as well. When I walk around our office I always see people looking at SO, Google and others. Why would I hold a candidate to a different standard?
>Similarly, I have a habit of looking over someone's resume and picking a few random technologies they mentioned to discuss. I'm surprised how often candidates claim experience with a technology and can't really describe what they've done with it or discuss it intelligently
I know what you're saying, but there's different levels.
Several years ago, I read a couple of books on Hibernate/JPA and played around with it on some toy projects. Where I work never really ended up using it.
Should I put Hibernate on my resume? I know a lot more than someone who has never used it, but it's been a few years since I've done anything with it, and I never really used it in production/anger.
I wouldn't pretend to be an expert (and I'm guessing some people with my level of experience would), but I still think it's OK to put it on my resume (although I'm not sure if it's on my current resume because I don't really care to work with it :)).
I solve this by not using a skills block or anything like that. Partially because I think they're stupid but also partially because IMO it's a no-win situation to figure out what it implies, you'll always mismatch with some interviewer.
> I'm surprised how often candidates claim experience with a technology and can't really describe what they've done with it or discuss it intelligently. The level of dishonesty is high.
This is a requirement to get past the HR gatekeepers at most companies. That may not be the case at your company, but how can I tell? When a critical mass of companies require you to lie before you can even talk to a technical person, then you're going to get lied to as well.
> plagiarism
Triplebyte controls for that by having a followup on-line session where you have to walk them through your code and modify it on the spot. They probably use regular plagiarism filters too.
At one company that did a take home, the first step of the onsite was some pair programming to add a few new small features to my submitted solution.
I don't have time for that. Nobody wants to spend their evenings working on exams. I'd prefer a few hours of onsites any day.
It's more reasonable for TripleByte because they share across companies. I agree, for a single company I have to be really interested to agree to give up 4+ hours...
"Not long ago I screwed up a tech interview because I couldn't remember/figure-out-on-the-spot the iteration condition for estimating square roots by the Newton-Raphson method, and I was not willing to cheat by looking it up on Wikipedia while I was on the phone. Their loss."
Out of curiosity, what type of developer position were you interviewing for?
> what type of developer position were you interviewing for?
A square-root estimator developer position, of course.
I could see this question being a valid question to ask for a research scientist role if the applicant has a PhD in CS/Mathematics/Operations Research and their research area is optimization or machine learning, or they claim to have taken coursework in convex optimization. Because you definitely have heard of Newton's method in those contexts.
Not quite sure how to answer that. Do you mean what was the label on the job req? I don't remember. I think it was "Senior software developer" or something like that. Is that what you meant? (And if so, why do you ask?)
I'm trying to figure out what software development job that would ever come up? graphics?
Ah. No, definitely not graphics. I can't say much without giving away the identity of the company, but like I said, the technical side of their business had to do with network optimization. It was "Uber for X" for some value of X.
There was no take home test for me. It was a 45 minute multiple choice test, a timed coding problem after that which you could skip if you did well on the test, and then a 3 hour or so chat that involved an hour of coding something and various systems and algorithms questions
I view technical interviews that require algorithm solving and coding on a whiteboard as ridiculous. Primarily, because I am deathly afraid of them.
And here is why. I own and operate two online businesses in the Radio Communications space that are the de-facto standards for our industry. I've coded both of them from the ground up in PHP/MySQL and manage all the day to day administration of these sites. Our infrastructure is deployed on 20+ servers on AWS, Google Cloud, and some bare metal deployments, for which I manage solely by myself. We have 100's of TB of audio archive storage that is all developed and managed by myself. I've personally tackled the entire stack from the ground up, end to end. I've hired an outside consultant, once, to do graphic design work. I've taught myself titanium accelerator and released a highly successful mobile app for my business for Android and iOS. I've even deployed much of our API using NodeJS! Gasp! I do all security, SEO, sysadmin, scheduling, upgrades, marketing etc.
But I'm not a computer scientist. If you asked me to outline a best-case sorting algorithm for x use case my response would be "uhhh... " If you asked me to write out a for loop in PHP on a whiteboard I'd say to myself "uh... where do the semicolons go again?" But I can piece together building blocks from AWS, Stack Overflow, open source projects, multiple SAAS providers. I can also write contracts, executive license agreements with third-parties, develop highly successful and consumable APIs, and manage the financials for a multi-million dollar business. I've also deployed multiple APIs in SOAP, XML, and JSON which form the most successful parts of my business
But get me up in front of a technical interview team where the startup is looking for a computer scientist and I'll have a ton of "yea, but..." and probably wouldn't last too long.
So when I see these examples of technical interviews in organizations where I know I could add value, but realize their process for evaluating that value could certainly eliminate me very early, that scares the crap out of me. Fortunately, my business has been successful enough that this will never be a scenario I have to face. It still bothers me though.
You're argument is exactly what I call the difference between a "trade programmer" and a "computer scientist". You are describing the former, while all the Google-copycat interviews with algorithms and data structures are designed to hire the latter.
As you said, trade programmers typically glue together existing components and frameworks. Sometimes, this is really all that's necessary, as you have proven with your businesses. Computer scientists are qualified to create those underlying systems in the first place, properly weighing and selecting the algorithms and data structures to meet constraints.
I don't mean any of this to cast a negative light on trade programmers. They are 80-90% what a business needs, and I think there should be better opportunities for people to become such without the 4-year degree. [0] However, the limitations also need to be understood, and in my opinion a business is best served with a smaller set of computer scientists to provide technical guidance. Otherwise, you will see a lot of history-repeating-itself type of bad decisions.
[0] This is basically the hole that bootcamps have attempted to fill. They could also be filled with associates degrees or apprenticeships.
Part of the issue we have in software is that many companies interview for computer scientists (which they sometimes/often think they need) when they actually are looking for trade/craft software developers (but don't realize/admit it.) So many discussions around this topic reveal this fundamental mismatch in expectations/perceived needs/skillsets.
Absolutely. This is a shift that would need to made in hiring just as much as education. I consider the split pretty analogous to drafters vs architects. Both jobs have roughly the same output -- drafted plans. But the architect is properly trained and licensed to determine things like feasibility, safety, regulatory compliance, etc.
I think your percentages are too low. IMO it's more like 95-97% of businesses are 99-100% served by what you describe as a trade programmer.
The problem is that it seems that 90+% of shops think they're 0% served by trade programmers.
Sure; 87.3% of all statistics are made up on the spot anyway. [0] It will also vary greatly depending on your business scale. Google needs computer scientists; at their scale any efficiency slip is very costly. For the local small business looking to turn their Excel spreadsheet sitting on a shared network drive into a CRUD app, a trade programmer or two is probably entirely sufficient.
[0] Yes, you heard me right! 91.4% of all statistics are made up at the very moment!
Unless you're actually building a database or something like Kafka it's way more useful to have someone that knows how to use a debugger and a profiler
> You're argument
* your
"you're" expands to "you are" - substitute "you are" in the sentence above and you can see that it's incorrect.
I'm quite aware. Typo caused by my brain thinking about where it was going and not where it was.
It sounds to me like you're more of a technically inclined software executive/business person than a coder. Would you agree or disagree with that statement? Your run-of-the-mill programmer isn't going to be writing any contracts or license agreements and they're certainly not going to be managing any financials.
If the interviews consist entirely of whiteboard problems, then they're probably just planning on sticking you onto an agile team where you'll grab tickets off a queue every morning and churn through them at your own pace. It sounds to me like this is quite a bit different from what you've actually been doing. So I guess the point I'm trying to drive at here is that maybe your mistake is identifying yourself as just a software developer when you're actually an executive?
If you're trying to say that he should be seeking a CTO position instead of a developer/engineer position, then I agree.
Yes, or some sort of VP position.
Almost no one advertises for an executive that has a handle on software development, contract management, financial oversight and more.
This is pretty much almost exactly the same boat that I am in.
> These are ways to gauge if they know the langue without making them write code. You should never ask a developer to write anything from scratch, or write anything.
But.. why? You are hiring someone to write code, what better way to gauge their ability to do so than a work sample?
Obviously you don't drill someone on sorting algorithms, unless that's what you are hiring them for, but make them solve a simple task that is on the level of abstraction and in the domain your company deals with.
Having sat through interviews where candidates who had made it through screenings and talked the technical talk turned out to be unable to write actual code to solve rudimentary domain problems, there's no way I'm hiring a developer without programming with them first.
The argument I usually hear is that many people don't do well under pressure or with others looking on. So by doing coding tests or whiteboard tests or whatever, you're selecting for people who do well in high-pressure situations, rather than people who are talented coders.
But I agree with you. I've interviewed many people who have an impressive resume and can talk the talk, yet can't even do Fizzbuzz.
On the one hand, there a significant number of people that can't fizzbuzz applying for the jobs.
On the other hand, there are a significant number of people that can only do the interviews and are not good engineers in general once hired.
This is made even worse by 1) the cottage industry teaching people to crack/break the interview process, and 2) the number of people hyping their personal "brand" via conf talks, standards nonsense, etc. as a way to sidestep more engineering vetting. (Not everyone does this of course -- but there's a significant number of people that do it just for career upside).
Personal anecdote as a hiring manager: I've found that some of the best interviewees but mediocre mid-level engineers are those with a history of low to mid-level jobs at the largest companies.
> I've interviewed many people who have an impressive resume and can talk the talk, yet can't even do Fizzbuzz.
And I've interviewed many people who can do fizzbuzz because they studied for it (CTCI) and wind up being terrible programmers.
The end result? Technical interviews are, at best, a completely random hiring signal. You'd be better off flipping a coin. It's better to be lucky than good, so why not use luck as a selection criteria?
But, if you aren't hiring a developer specifically to implement fizzbuzz for you, why are you giving them that as a problem to solve?
Hiring someone to work on a Flask REST API? Make them add a REST endpoint to a little flask app. Hiring someone to do CSS? Make them style a form. Hiring someone to build a database? Make them safely write to disk.
This is far from random - it's been almost twenty years since Schmidt and Hunter showed that a work sample is one of the best predictors of future performance, 24%, vs 3% for unstructured interviewing.
http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%...
I couldn't agree more. The problem with most work sample tests is the length and the format. Most are too long and they have you start with nothing. Adding a rest endpoint to a little flask app is perfect.
It's a shame nobody actually does this kind of work sample test. And thanks for that study. It'll make for some nice ammunition. :)
Here is my take on hiring: an active Git repository with a decent amount of non-trivial code/projects generally gets applicants I have to evaluate to skip the whiteboard interview and instead grab lunch or coffee with me. We then discuss technology/software engineering. I find this approach to have yielded much more conclusive results, though it probably would not "scale" well. You can quickly tell whether someone is passionate and resourceful by talking with them, occasionally erring on research-ish stuff but always focusing on the implementation rather than the theory.
Plus I sometimes stumble on the occasional gem that is very knowledgeable and from whom I can learn.
Whiteboard interviews, coding challenges, take-home projects. All of those things are so time-consuming for both the company, the interviewer and, of course, the applicant. And all of that just in the hope that the company will accept them... maybe? Of course when nothing else is available then it is the usual drill: phone, skype, on-site 1, on-site 2. But if other signals are available then to the trash it goes.
If you start with github repositories for your candidates, aren't you filtering out people who do things other than work? Most of us work 40 to 60 hours a week, and sign paperwork that says that any code we write belongs to the company. But now we need to work Saturday and Sunday on open source projects so we're worthy of sharing a coffee with a hiring manager?
> says that any code we write belongs to the company.
I have turned down several jobs when they tried to hit me with that clause. I have negotiated a better clause that gave them the work I made for them, which just happens to line up with state law here
> But now we need to work Saturday and Sunday on open source projects so we're worthy of sharing a coffee with a hiring manager?
I wouldn't want to hire someone who didn't enjoy coding enough that they didn't have something on publicly visible repo.
>I wouldn't want to hire someone who didn't enjoy coding enough that they didn't have something on publicly visible repo.
There is lots of reason why competent developers would not actively participate to OSS or have public repos. I think you are holding applicant to an unreasonable standard that does not entails they are bad if not upheld. I have worked with some extremely talented people - far more than I ever could be - who had 0 contributions, 0 repos and publicly available code.
Why? Because they valued the time spent with their family and friends more. They got the job done which is ultimately what I pay them for. Which is all that matter really. Are they competent? Do they get work done? Can they potentially take-up bigger engineering challenges (i.e can they grow). Yes? Welcome at X co.
I agree that it is possible to be great developer with no public code.
Unfortunately their competence is not directly important, my ability to assess their competence is. I have no reliable way to evaluate a person without public code. They could be the greatest or the worst coder without public visibility.
You could ask them to e-mail you a code sample or complete an exercise.
> I wouldn't want to hire someone who didn't enjoy coding enough that they didn't have something on publicly visible repo.
Why? Those people sound like terrible employees. Those are the people who come into work to punch the clock and get paid while saving their energy and creativity for their side projects, which is what they'd really rather be working on.
Most of my coding output for my job ends up on a public github repo, which is the best of both worlds.
That would be nice. Are you a library or framework developer?
I work for a nonprofit. The downside is the pay isn't as great as it could be elsewhere. The upside is that the work is meaningful and I get to write OSS as part of my day job.
I worded my comment poorly, I had double negatives, or something.
I would prefer to hire people with publicly visible code.
Your comment was worded fine. My point is that most code written for most companies is not publicly accessible. Therefore, most code that is publicly accessible was created as a side project in their spare time.
I don't know about you, but after working an 8-10 hour day, anything I make in my off hours is a steaming pile of shit. Certainly nothing I'd be showing to potential employers. Do you know who can make jewels after 8-10 hours of work? People who punch the clock, do the bare minimum and save their creative energies for their side projects after they get home. That's not somebody I would hire.
Another scenario is the person really is just a coding machine and does so 12+ hours a day. Those people burn out, eventually.
I wouldn't want to hire someone who didn't enjoy coding enough that they didn't have something on publicly visible repo.
Shudder. Sounds like one chooses to work for you, or have a healthy life that involves non-coding/computer hobbies and relationships.
Maybe it's a good filter for us in the opposite direction.
I don't mind coding but I hate the other tasks that come with it (hardware, networking things, loads of setup). When it's part of my job sure but if I am programming instead of doing something else. I have not thought of a project that I can get so motivated about that I am willing to give up the little time I get to myself to work for free (obviously I am not going to strike it rich with my cheesy side project).
Also 99.9% of the tasks I wish to do are solved so it's not like I'm going to make my life easier by solving the task. For the few that I find that I want I understand they require extraordinary resources/programming skill that I just don't possess.
I am not filtering anyone. I use the signals that are available to me and which I can proof-check. Candidates who don't have public software forges (whether it is self-hosted Git, Gitlab, Github, or Bitbucket etc.) go through the usual (tedious) interview cycle.
Those who have don't because that would be redundant and a waste of time. This is simple.
You definitely are filtering people, unless you accept everyone who goes through the usual (tedious) interview process. This interview process is quite noisy, so being able to skip it gives a clear advantage. Whether or not this is a good thing is another question, but don't claim you aren't discriminating against people who don't code in their free time.
This is a hard problem to which there are no easy solutions, only trade-offs to be made. Here I think that I strike a reasonable middle-ground providing I act in good faith.
If this was an easy problem to solve, there wouldn't be a post on the HN front page about it every single week.
Question for you: is your judgement of the applicant affected by whether or not they have an active GitHub repo?
Do you mean does it matter what version controlling tool they use or if they self-host? or if I would favour a candidate over another because of an active Github repository?
The latter. Are you pre-judging a candidate because you can look at an open source repo instead of spending your day trudging through a tech interview?
Mmh possibly, there might be a slight bias favoring them. The shorter the recruitment lifecycle and the quicker I can go back work on actual software engineering.
But then again, I hire lots of software engineers who have 0 OSS contributions but a shit-ton of industry experience. It does not matter if your last contribution was 4 years ago by the way. I am not looking for a full green activity graph (though it demonstrates consistency and discipline which are good) but rather for non-trivial, significant and well-crafted pieces of software so I can rest easy.
I don't go in trying to shoot down candidates. That's what whiteboard interviews are for. (:
What do you consider to be non-trivial? Seems subjective. Exaggerating here, but obviously a git hub project that runs fusion reactor software is certainly non-trivial, but what about a small project that does/looks simple, but really takes a fair amount of effort to make it work? Like a triple AAA game is non-trivial compared to a breakout clone, but a breakout clone is still somewhat non-trivial (graphics, sound, "simulated" physics, GUI, gameplay logic etc.).
Do you just look at their own projects or their public activity in general? I have a lot of the latter but very little of the former and the stuff I do have in the former category isn't particularly flattering.
This is what I don't understand. During technical interviews, why don't we just give the potential employee a laptop and ask them to solve the problem as they would during a regular work day? Why can't they search Stack Overflow, and perhaps reach out to a friend or even a random person on IRC for advice? Isn't this how the real life works? They may not know anything about min heaps, but perhaps a 15 minute research will help them solve the problem better than anyone who actually memorized Cracking the Software Interview by heart? Isn't it better to measure discipline and ability to learn and solve problems instead of measuring existing knowledge?
From a Silicon Valley perspective, I didn't even know that this was something that companies considered not doing. 'Round here, a technical interview is guaranteed, it's more a question of if/when there will be anything else involved in the interview. Also, will it be a mundane technical interview, or more like 6+ hours doing Top-Coder style questions on a whiteboard? It used to be only Microsoft and Google were known for that but now it's practically everyone as far as I can tell.
Re: your last sentence, it's been common in my experience for at least the last couple of decades: that is, interviews for most of a working day, including at least one each focused on coding and design. Maybe my experience is unusual, but there were both big companies and startups.
> All in all, would do again, except not more than 1 a month because flying across a continent and back for 1.5 days is gruelling.
This is part of the problem. Aside from college graduates, who has time to fly around the country burning vacation time to maybe get an offer?
On the other hand, would you really accept an offer without having at least met the people you'd have to work with? Especially if you have to move across the country?
Video chat is good enough for me. I don't need to know about their posture or how long their legs are.
This might just be me, but video chat doesn't really do it. You don't get an idea of the building, bathrooms, cafeteria, and the general idea of how often your coworkers bathe.
All of these can be pretty important to my general mental health.
Yes, and they could easily hide a noisy, chaotic work environment in a video chat as well.
I wouldn't, no. But in the 2 situations where I have been asked to fly to a company I said I would be happy to once I had an offer of employment. Both did remote interviews and extended an offer.
I am glad to see managers that give interviewing the level attention it deserves.
Many interviewers just assume they know how to interview people to find the so-called "A player" (yeah, we're up to A+ now too). People love the idea of magic gotcha questions the answer of which determines whether a person is or is-not skilled some specific area. But the reality is most orgs are barely sophisticated enough to manage FIZZBUZZ-level screening, let alone screening for "A players." Proven interview techniques that take practice, training and coordination like the Behavioral Interview are often skipped in favor of ad-hoc, unprepared interviews that end up with a go/no-go vote.
When I worked as a technical recruiter, I found that a great way to screen candidates was to explain the "box" I was trying to put them in. I described the work I'd done to research the position, why I was screening for certain criteria, and that ultimately I wanted to get their approval on the summary I had written about them. Being non-technical, this worked better for positions I was experienced recruiting for of course.
For example, when recruiting a web developer, I'd start by asking a hiring manager what they wanted.
"Get me a full stack Rails developer who knows OO Javascript."
Then I'd just drill into why they asked for that until I didn' have manh questions. I'd be able to describe roughly what projects needed attention, how the tech stack helped solve that problem, and ask the candidate to help me sell them as someone who can do that. It wasn't perfect, but it worked better than most recruiting attempts I've experienced so far.
Now as a developer with a few years of experience, I feel I have no idea what I am doing, and am winging it at all times :)
OP: "There is a slight proclivity to conduct technical interviews within the companies that comprise the community."
The companies constitute the community. The community comprises the companies.
"In addition to its original senses, dating from the 15th century, “to include” and “to consist of ” ( The United States of America comprises 50 states), comprise has had since the late 18th century the meaning “to form or constitute” ( Fifty states comprise the United States of America)." http://www.dictionary.com/browse/comprise
This is like legitimatizing incorrect usage of "literally" or "unique" because some people don't know their definitions. It is ambiguous and sloppy to misuse a word as if it means its antonym.
And:
> as eluded in the following
It "alludes" (to), not "eludes".
And you and I are both complete jerks for being literate in at least one natural language.
It literally kills me how performant and impactful your code is to the many unique users that comprise the community. :-)
Seriously, though, the original attempt at writing actually does mean something -- if the companies do comprise communities somehow (perhaps of users or shareholders), then it makes sense to reference the subset of companies that comprise a particular community. But that's not what the author intended to say -- they just wanted a pompous way to say "all the companies" or (better) "the companies".
(And don't get me started about misusing "community" to mean "group" or "collection" or "lame way to make the preceding word plural", as in "the developer community".)