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.
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"
That doesn't sound like sarcasm to me...
I just wish Triplebyte would expand their outreach beyond YC companies.
(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.
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).
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 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?
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.
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.
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.
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 :)).
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.
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.
Out of curiosity, what type of developer position were you interviewing for?
A square-root estimator developer position, of course.
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.
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.
The problem is that it seems that 90+% of shops think they're 0% served by trade programmers.
* your
"you're" expands to "you are" - substitute "you are" in the sentence above and you can see that it's incorrect.
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?
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.
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 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.
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?
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.
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.
Those who have don't because that would be redundant and a waste of time. This is simple.
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?
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.
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 :)
The companies constitute the community. The community comprises the companies.
> 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.
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".)
