People suck at technical interviews (2014)
seldo.com
seldo.com
Programming is both technical and artistic. It's a creative endeavour that relies on technical skill to complete.
The best analogy to another profession would be to those in the 'technical arts', those like photography, joinery, painting, sculpture, drafting, perhaps writing too.
It seems at the moment that companies are approaching programmers as if they are purely technical like an actuary or bookkeeper and are seeking to quantify artistic skill through interview tests. This is rubbing off on some programmers who begin to think of themselves in these terms.
I don't recall a single instance as a photographer where I had to quantify my technical skill, but there were hundreds of times I had to based on my artistic skill, proving I had already made a vast range of photographs with sufficient quality to 'prove' my ability and by extension proving my technical ability.
Crucially, it was the fact I had a portfolio that allowed me to prove my ability, both artistically and technically.
I see a similar need in programming. I think programmers should create their portfolios of personal or paid for projects that showcase their technical and artistic skill and companies should take those seriously.
At the moment it seems that far to many programmers are attempting to get jobs without a 'portfolio' which is why, in an creative endeavour like programming, companies that hire are trying to quantify and determine a new hires ability with these seemingly bullshit tests.
There's room for improvement in this argument and there are outliers, but I think the basic premise is sound.
Its like hiring a writer based on their grammar. A writer could have perfect grammar but their books are boring as hell.
Or even hiring a writer for adhering to the techniques of connoisseurs. The book "Ready Player One" was heavily criticized as amateur work (it was, after all, the author's very first book), but it nonetheless was hugely successful (and even has a movie in the making).
A coding analogy: A compiler or debugger can catch bugs.
If they can't form a competent sentence, they probably would fail to write a convincing hook. But some margin of error is acceptable.
As an aside, I think debugging is hard even with a debugger.
Determining a programmer's worth probably takes at least a month in my experience. Maybe even two months. I almost got fired within the first month of my first job, but quickly ramped up and turned around to be the highest value-adding employee by virtue of completing the highest paying contracts at a fast pace (the company was later acquired).
Most companies can't spend a month, but a day long take-home test is a great alternative.
There are so many facets to a programmer's worth, and so many ways to miss them or ask the wrong questions, that I just don't believe in short, high-pressure interviews. Take home tests have been highly successful in my experience (and a few others, from what I have heard).
It depends on what you are working on. A non-trivial part of my job involves working with domain expert scientists and taking their very clever, but badly written, code that solves some hard problem and turning it into fast, efficient and usable code.
I think it would be a step forward if it became standard practice to expect an online portfolio of a developer's work.
I find that this is incredibly discriminating against people who have other hobbies and don't like to spend 80 hours a week coding with only 40-50 of those being paid.
Where the programmer/photographer analogy fails is that usually, the photographer retains the right to the vast majority of their creative body of work, whereas a developer might not have anything client-facing to show at all, even if they have side projects.
But it's worth considering that in larger companies, management is often terrified of the creative aspect of programming, because it messes with their primary goal of predictability. Thus they seek, many of them openly and explicitly, to make all technical roles fungible.
And as much as that's hurtful to us creative programmer types, it's not an irrational position for them to take.
The fact (or hope) that fungible programming roles can be more easily outsourced, especially to cheap-labor countries, is of course seen as a bonus.
This situation presumably gives a big advantage to any organization willing to engage with the creative aspects of programming, but I am starting to think it's in the nature of organizatins themselves to stop embracing that risk after a certain size is reached.
(Not that this is an argument against the portfolio idea. Even if you're going to work as a fungible cog, you'll probably get a better cog-job faster with a decent portfolio.)
There's probably a decent analogy in product photography. Unless you're going high end, bashing out well lit, well edited and well presented product imagery lies firmly towards the technical end of the photography technical - art spectrum.
Trouble is, many companies think the want these 'product photography' programmers but in reality they need the equivalent of 'stock photography'. And stock photography is one of the most difficult and challenging technical/artistic balances in the industry.
Both turn out similarly neutral end products that can be used almost anywhere and replicated, but getting to those final products requires very different mindsets and approaches.
That's likely stretching the metaphor more than it can handle but hopefully illustrates the point!
And as you mentioned, having that 'personal portfolio' that allows you to sell yourself (another important distinction I made in another comment) will get you the job ahead of someone who doesn't have one.
It's about as rational as decreeing that it must not rain on Fridays, and then proceeding to fire the nearest person every time it does.
They do have some very good and rational reasons why they wish programming was not a creative job. When they assume they can change reality by wishing it, they completely destroy their people's (outsourced or not) productivity, throwing the cost of everything into the stratosphere, and the quality way under the floor.
It's a continuum, so of course nobody ever gets 100% predictability with software. But most of us, if we really needed to, could ratched down our productivity to a level where we almost always delivered exactly what we said we would in each sprint or other schedule unit.
And I think that is the crux. Most people who write software don't want to live like that, but there are a whole lot of managers dreaming of a shop floor full of "individual contributors" who are not very individual, and plenty of CEO's who will happily take that over cat-herding their way to the next iPhone.
That should give a big advantage to any company capable of embracing a little chaos and giving a happy home to talented and creative programmers.
But when I look around and see even, say, Facebook -- a company that needs to innovate and seems to know that -- building developer-hostile open-plan offices, it makes me think we may all be doomed.
A portfolio says "I encountered X problem and here's what I did about it to make this other thing and therefore solved X problem."
A web dev is a very easy job to create a portfolio for because the product can be your portfolio but when I say 'portfolio' I'm not talking about a GitHub repo of some code you've written, I'm talking about something bigger than that.
I'm talking about having examples of your code, things you've made, perhaps technical writing, perhaps a personal project, perhaps video or other 'evidence' of the programmers work/approach. If that involves making a personal embedded hardware project to show your approach then that's what's needed.
Perhaps another important attitude change needs to be established...
In a creative technical art you are not really selling your 'product' to customers. You are selling yourself. You're selling your ability to solve problems and it's incumbent on the individual to prove their ability. Web devs aren't 'selling' their previously created websites, they're 'selling' their ability to create those past projects.
It's a crucial distinction and programmers would do well to adopt this distinction - they're not 'selling' their GitHub repo for instance, they're using that as an example of how they (their mind?) work to solve problems.
For sure there will be times you work on proprietary/secret stuff or on systems of such scale you can't possibly make an equivalent scale of personal project.
But you can demonstrate your ability and sell yourself, and that's really the key to it all. You have to get to the point in a creative career where you realise you aren't just selling your final product, you're selling yourself, your approach and your way of solving a problem.
Finding a way to do that is how you get the job ahead of someone else.
You're allowed to include sketches, because you have time to make those for personal projects. But no photographs because they're all proprietary.
I often encountered situations where clients wanted to keep photos 'private'. I couldn't use them in my portfolio. To deal with that I took my camera and lenses (analogous to a computer) and made some equivalents that allowed me to demonstrate my skill in a similar way (analogous to writing some code in a personal project).
Suggesting you should sketch something to show your photo making ability is like writing pseudo code to say you can write python - it's an unrealistic analogy that doesn't happen and has no need to happen.
You can very easily use a camera or a computer for a personal project and make very real photographs or write very real code to demonstrate your ability.
That's it right there. That's the bit that makes the difference. It speaks to an attitude of 'I'm doing it, I don't need to prove it'. It's wrapped up in 'I'm doing it and I'm too busy to prove it because I should have a life and other people should just recognise my ability so I don't have to sacrifice my lifestyle to put the effort in to get the job I want"...but it really comes down to thinking I shouldn't have to show it because I'm doing it.
There's no can't show it inherent in your original statement. There's a large dollop of don't want but no can't.
You can find ways to prove you ability, to use work you do day to day, to make high quality personal projects or contribute to those that are already running (beauty of programming is it can be easier to collaborate like this and still show your skill).
It can be done. Plenty of people in all industries work one job and study, prepare or work towards another all whilst supporting families and trying to have a life.
Programmers aren't special snowflakes, they've got to work just as hard at selling themselves as all other people in the creative industries do. That's why I think programmers really need to grasp that they actually are creatives and adopt an attitude that deals with all the burdens that moniker brings with it.
Photography is IMO a flawed comparison since it's much easier and less time consuming to have some nice looking photos than it is to set up an equivalent software project. More than that, the photos you took in 2010 are likely to still be relevant in 2016, for the average user. However, for programming, your PHP4 project from 2010 might not cut it in 2016 when you're supposed to join a Scala project.
Why wouldn't you invest time in it? It's investing in yourself and could get you your next pay rise. It's not wasted time.
We're back to the point I made above about putting the effort in.
> Photography is IMO a flawed comparison since it's much easier and less time consuming to have some nice looking photos
Sure, as I already said it's not a perfect comparison, it's there to illustrate a point.
And I reject your second point very strongly. Even something simple like a single headshot can take hours of planning and setup. Something like a documentary project might take months or even years to complete.
Something like a commercial shoot might take a team of 20 a week to complete and cost hundreds of thousands of dollars - how do you get to put that sort of work in your portfolio? Sometimes you work for free, sometimes you create a whole shoot yourself at great cost. You work for it essentially. That's how.
And a single photo might be no more the 'whole' than a single file might be the 'whole' programme for instance.
Anyway, the exact vagaries of the industry aren't important, it's the assertion that programming is a creative discipline that is important.
> More than that, the photos you took in 2010 are likely to still be relevant in 2016, for the average user. However, for programming, your PHP4 project from 2010 might not cut it in 2016 when you're supposed to join a Scala project.
Possibly, but a portfolio isn't trying to sell a product it's selling 'you'. Stuff that goes in the portfolio shows how you do what you do, gives a window on how you work, how you approach a problem, how you solve it.
Many photographers will create 'behind the scenes' shoots and videos to show how they work and show clients how they solve problems for instance.
These can be independent of the exact example and just because a programming language might change you can still use an older project to show your skill and approach to a particular type of problem.
Anyway, I've laboured the point long enough, feel free to grab the last word but I think I've outlined my point well enough to be understood.
I hope you realize you're having a discussion with three different people. It's not up to you whether the community continues this discussion without you.
Except that doesn't work in programming. I can't take the core bits and re-release them in my own projects. In fact that's literally what I'm prohibited from doing.
While in photography you can make the same photo with different people, in programming you absolutely cannot simply rewrite the same code.
OK. Imagine this...
You photograph an event at an exclusive venue that you won't get access to again, with a setup you can't replicate (ever), with famous guests you'll never see again and a world famous VIP as the main subject.
Oh and to boot, the client wants total confidentiality. No photo use for portfolios whatsoever.
Seems just like the restrictions a programmer might face right? An infrastructure you can't replicate, code you can't publish, resources you won't have access too etc etc...
This was some years ago now and I've left photography behind but how did I ever get to do that job in the first place? Created stuff myself, off my own back, unpaid and at great time expense that showed I had the level of skill and ability to do it. I chased other photographers, contributed time and talent to their projects and made stuff myself.
And when the clients came looking I could show from my prior work and portfolio that I could do what they needed.
And what did I do afterwards? Took inspiration from what I saw at this event and made additions to my portfolio that showed I could solve the kind of challenges I faced there, proving to subsequent customers that new skill. I didn't just say 'oh dear, I can't use this so that was a total loss, let's not do anything about it.' I went out and made new stuff that showed equivalent skill, not recreating the photo, proving the skill.
Maybe I'm not being clear enough or maybe there's a misunderstanding of what type/level of photography I'm referring to so I'll state it plainly:
Photography was just an analogy. The key is you're not taking the original work that you did if it's restricted, the key is creating something that shows equivalent skill. Remember, I already said that as a creative you're selling yourself, not the end product, so you're not trying to recreate the particulars of the exact photo/code but demonstrate you have the skill/ability to create something of equivalent difficulty.
Need to prove you can run a big project? Well, run one. Do one yourself or join another. Find a way. Don't throw up a barrier every time something seems difficult or hard. It's meant to be hard. It might take a long time. Deal with it and get it done. That's what I'm saying.
People will tell you you're getting taken advantage of and doing too much for too little right up until you're working for some global mega corps running some incredible team, earning massive bucks and all that stuff. They'll keep telling you it until you believe it. Or you can ignore them and just keep going, keep making something to show what you can do and keep chasing the jobs you want with that big backing of proof of your ability that you've got.
I've only done very small embedded projects, like http://canonical.org/kragen/light_sensing/ and https://github.com/kragen/ar_bytebeat.
> I think programmers should create their portfolios of personal or paid for projects that showcase their technical and artistic skill and companies should take those seriously.
100% agree, and Github in particular is great for this. Sadly, in my experience very, very few candidates have such a thing. Even non-code content such as issues they've filed or stackoverflow questions and answers is a very useful way to judge someone's technical abilities, but many candidates don't provide links and either use separate identities/aliases or don't participate.
No problem getting interviews
Still have to do the "brainteaser of the hour" technical interviews. Fortunately it is often the same question I realize, so this gets easier without needing to go through the whole book on this.
For example, I build things for clients that are proprietary to their businesses. Some things are publicly accessible, like marketing pages, but the real stuff is locked behind employee-only auth. Other things run entirely on internal networks, and can't be accessed from the web. They would be rightly upset if they discovered I shared their code with a third party, or placed it on Github.
Moreover, just because Github exists, doesn't mean programmers should feel obligated to "participate". Outside of developers who maintain or participate in truly used projects, it's mostly noise. The only exception I can agree on is looking at issues a candidate has reported to gauge their depth of understanding, clarity of communication, offering of solutions, and other such valuable insights.
No, it's useless for this, because companies don't look at it. That would require the recruiters and interviewers to spend more than fifteen seconds prepping for the phone-screen call, and we can't have that.
Incidentally, after my last job hunt one of my new policies was that I hang up on any company that throws me into their fizzbuzz phone-screen after being the one to initiate contact with me. If they didn't think I had the skills they shouldn't have reached out in the first place, and if they do think I have the skills they shouldn't need to waste my time and an interviewer's time on the fizzbuzz question.
(I say this after multiple companies tried to recruit me with a "we want a Django committer, that's why we're contacting you" pitch and then put me into their fizzbuzz-esque phone screens)
Still get the pop quiz interviews almost every time (with or without coding) and it's pretty clear my chances of getting an offer is at least 90% based on how well I do on their pop quizzes.
Even for a programmer with a portfolio, it's vital that you be able to probe them with questions about design decisions and expose someone who didn't actually write it.
Does photography have some sort of solution to this problem? Can you ask a photographer about how they took a picture to easily reveal whether they actually took it?
I'm guessing there's less of a need to verify skill with photographers since most of the work is on a gig or piece-work basis where it's easy to terminate the relationship or refuse payment in case of obvious frauds. OTOH, what stops an unskilled from stealing a portfolio (or using with their consent) to get work? What happens if they produce usable work, but which doesn't look anything like the quality suggested like their portfolio?
Might have been a wedding or a commercial shoot, I'd show them stuff that would solve what they needed and talk through with them.
Similar things have happened with editing.
I suppose an equivalent would be not just code but maybe wider community contributions. As I mentioned a portfolio goes beyond just 'code' or some 'product' that you made. It's there to sell 'you' so that includes things like bug fixing, visible issue solving, maybe mailing lists, maybe run a community platform, maybe clear contributions to open source projects or whatever. Anything you wnat I guess.
It's relatively easy to become 'public' enough to be obvious who you are, or use some kind of cryptographic proof etc.
There will be problems of due diligence, those are universal, but I think individuals and companies would both be better off if they took portfolios more seriously.
Repeating what I said in another comment: during my last job hunt I had multiple companies which contacted me, unsolicited, asking me to apply to work with them, because they wanted an "extremely senior" Django person, preferably a committer (I got my commit bit in 2007). Every company which contacted me like that also put me into a fizzbuzz-esque phone screen. There is no sense in this; my work is publicly verifiable and vouched for (sometimes in an extremely literal sense, as it's my PGP key that provided the signature on a bunch of release packages of Django), so either they believe I am who I am, in which case no need for a fizzbuz, or they don't, in which case they shouldn't have been contacting me in the first place.
My policy now is to hang up on any company that reaches out to me for a skill they know I have, and then fizzbuzzes me in spite of that knowledge.
You can still test for creative ability in the traditional coding interview construct through systems design questions. It requires you to have a deep understanding of various technologies, but at the same time focuses more on how you view various trade offs which are crucial in designing complex systems.
When discussing art with its creator, you could have the same kind of discussions about various tradeoffs they made in regards to various technical topics. For a writer, use of alteration in a certain way, or a photographer trying to draw focus to a certain aspect of the larger photograph, in particular to various editing decisions.
The issue here is that the vast majority of new-grads/young programmers are fresh out of school and haven't spent any time focusing on systems design so companies focus on what they know best, asking them to be creative in the domain of algorithms. I also think its the case that since so many people's first interviews were algorithms based the process just continues to be that way.
But, at the end of the day, to say choosing a particular data structure to solve a certain type of problem has no creative aspect to it is wrong.
> The famous fizzbuzz test simply asks "are you aware of the modulo operator?"
Wait, what? No, it asks "can you write a for loop without breaking a sweat?". There's a rightfully vivid debate going on about the virtue of asking algorithmic questions in interviews, but fizzbuzz is hardly algorithmic. I'd wager that virtually all programmers iterate a collection at least once daily.
The followup sentence drives it home for me:
> Yet people will spend twenty minutes on it in an interview, a huge waste of limited time.
Well, if it takes an applicant twenty minutes to Fizzbuzz, you're done! Just saved everybody lots of time.
I used to think Fizzbuzz was insulting and bullshit until I started interviewing. I haven't yet met a programmer who couldn't solve a Fizzbuzz-level question, but I've met many who took over 10 minutes and made little logical errors. It's a great predictor for "can this person actually program, well, at all?".
How do you know, have you hired many who had trouble with the Fizzbuzz? Or are you just guessing? (I don't know either; there's a lot of missing data in interviews)
Sure it weeds out "non-programmers" - any programming task (more than "Hello World") does. But how many people who are good programmers and just suck a) under pressure, b) especially when surprised are falsely out-selected?
I once failed to answer what a right join is. I got the (freelancer) job anyway - and of course I knew all along what that is, but when I got that question I had not used any joins in years (doing infrastructure work instead), and under interview pressure I can't think except along narrow lines. I ended up doing most of the complicated SQL queries in the department, with people coming to me because to me that was easy. After failing a very simple interview question on joins.
The same comment could apply to any rejection criteria. At my employer, we do have some data, since we do reinterview candidates after years in-between, especially if they are fresh from college. I can't speak for our organization but yes, basic programming hurdles do reliably weed out bad candidates. This is based on my experience of having done more than 150 technical interviews, all of which were balanced against the feedback of the other interviewers. Failing basic programming problems is a good predictor.
> But how many people who are good programmers and just suck a) under pressure, b) especially when surprised are falsely out-selected?
Any kind of test that is given to candidates has the same risk.
But, let's break it down. Do you want to interview candidates for programming positions and _not_ have them program in some form or fashion during an interview? IMO that's nuts.
"If I roll this d6, what will the average be over time?"
I've asked this to loads of supposed graduates, and apart from the odd one who made the "WTF are these monkeys hiring me for" face, a lot of people can't figure it out from first principles.
But a lot of people choke on it. Also I've had people choke on very basic general knowledge like "think of a large emerging economy in Asia".
Maybe it's nerves, maybe it's thinking too much about a simple problem.
With coding, perhaps the surprise comes from the fact that a FizzBuzz test would seem like quite a powerful test. If you can't do it, you know you can't do it. There's no doubt that you're not a programmer if you can't solve FizzBuzz and its ilk. So why do people apply, knowing they will be tested? That's the real question.
I guess the answer is you learn where you're at when someone asks you something you can't answer. Sometimes it's not where you thought.
I'll be honest, that's a really dumb question for testing programming skill.
Still not a great question, maybe. But you grab whatever is in your bag.
(1 * 1/6) + (2 * 1/6) + (3 * 1/6) + (4 * 1/6) + (5 * 1/6) + (6 * 1/6) = 3.5
Of course no actual roll of the die will ever come up 3.5, but as you roll the die more and more times, the average of all results seen so far will begin converging on 3.5 (and given infinite rolls, that's where it would end up).
I don't mean that I can't solve problems. I mean I can't hold a conversation.
I wonder if the reason so many people fail is because we've essentially put them in an artificial situation that shuts their brain down.
(I have also been dumbfounded by the inability of recent CS graduates to do FizzBizz... I feel like it's not certain our candidates are frequently flawed. Maybe it's our environment.)
That sounds really hard. I'm sorry.
But I can't imagine any interview technique which would work reliably if you're brain dead during the interview.
What I would simply do is :
"Write fizzbuzz test for language ... use the modulo operator, which is ... for that language"
By doing this it's all about the loop.
On top of that I think the author is right, because the pressure of the candidate is sometimes huge.
I prefer giving a task that they can do at home. For example if it's a front-end position, it would be a small landing page. When I interview I usually tell the candidate :
"I really enjoyed the conversation so far. Just to let you know, the management wants from us to get from every candidate a code sample, so I will have to give you a small task that you can do at home. I'm really sorry about that, but I think it will be also helpful for you to check out what exactly you will be doing here. Do it whenever you want, just make sure you have something by the end of the week. You can also ask me anything at ..."
This sentence makes miracles. The candidate is motivated. The code is cleaner and though-trough. Then you can actually see if the person will be able to do the job.
> Wait, what? No, it asks "can you write a for loop without breaking a sweat?".
There are notorious cases where senior engineers with years of actual honest coding experience "fail" fizzbuzz. IMO, That happens in two ways:
1) Not knowing (forgotten?) what a modulus operator is, and trying to code one up from scratch with a for loop. This can totally happen when you spend a few years working on line-of-business CRUD apps that never turn out to need modulus arithmetic.
Coding modulus from scratch with just + - / * is a fun little challenge in its own right, but it'll probably take you longer than 10 minutes to write it correctly and solve fizzbuzz with it.
That means you just took more than 10 minutes on fizzbuzz, which means you failed.
2) Trying to "clean up" the solution. http://c2.com/cgi/wiki?FizzBuzzTest has a good discussion on 'Why Fizz-Buzz is "hard:"', which points out that many of the most obvious solutions have code duplication, which some people then try to eliminate, tying themselves in knots trying to make it perfect.
The third possibility, that a candidate with years of experience shipping code nonetheless struggles to write a for loop, is IMO just not as common as the above two failure cases. (Much more likely is that the candidate has lied/exaggerated on their resume.)
It's surprisingly easy actually.
var remainder = x - Math.floor(x/y)*y
(Math.floor because javascript)
def fizzbuzz_no_modulo():
counter_three = 1
counter_five = 1
for i in range(1, 101):
output = []
if counter_three == 3:
output.append('Fizz')
counter_three = 0
if counter_five == 5:
output.append('Buzz')
counter_five = 0
if not output:
output.append(str(i))
print(''.join(output))
counter_three += 1
counter_five += 1Similar to your solution, instead of two counters, you can have two iterators that cycle every 3 / 5 elements, and add them. Then fill in any blank elements with their index+1.
from itertools import cycle, zip_longest, islice
fizz_list = ['', '', 'fizz']
buzz_list = ['', '', '', '', 'buzz']
output = [
fizz + buzz for fizz, buzz
in islice(zip_longest(cycle(fizz_list), cycle(buzz_list)), 0, 100)
]
for i in range(len(output)):
print(output[i] or i+1)If you don't do fizzbuzz or equivalent, how else do you catch that?
"Okay, let's assume I have some function that tells me whether something is divisible by p. [writes it while using that function] Now, how would I implement that function? Well, I'd search for some existing library function to do that, but if I can't, then here's how I would check divisibility ..."
That's because the senior dev knows how to break the problem into solvable pieces, even and especially where they don't already know the solution to each piece.
I've seen numerous people fail on FizzBuzz despite supposedly being senior engineers.
None of them failed because they didn't know the modulo operator. For one thing, it's actually pretty easy to solve even without modulo.
If someone doesn't know modulo, I'll happily explain it.
More commonly, people struggle with even basic things like setting up a loop at all.
The compiler can optimize away the duplicate tests. That's its job.
The only time I use the modulus operator is when I'm writing something to track what record / rule I'm processing and I only want to show every 10,000th record or so. I can't think of a time I've used it otherwise.
We were doing a bunch of interviews and decided to try out FizzBuzz. I wasn't doing this round of interviews, but things ended up a bit confused with timings and I had a 30-40 minute very casual chat with each candidate prior to the actual interview.
In each of those I ended up probing a bit on technical stuff and everyone seemed to have a decent base level of competence. But they all went to pieces over fizzbuzz in the interview.
The one I actually saw, I had had a fairly in depth conversation about what it actually means to use "ref" and "val" in C#, but then watched the same guy freeze and barely scrape through fizz buzz.
My conclusion is that some people just can't write code in that kind of environment. What makes it tricky is some people (myself included) find it easy or even fun - maybe I can write fizz buzz in a single LINQ statement...Those people can assume that everyone not like them can't code.
As a candidate, I hate technical interviews. For the reasons above. As the poor schmuck asked to make the hiring decision, however, I've learned that I can't live without them.
My technical isn't complicated. A very basic SQL assignment (delivered to an audience which claims to know SQL) that is followed by a few broader database design / data process QA questions. Entire assignment is 100% job relevant (in fact, my SVP asked for a copy of the report it generates when he saw the problem on my whiteboard). I don't care about the details of syntax.
I do care, however, about candidates who produce SQL code which looks like the bastard love child of LISP and Java. About candidates who claim to know a skill but literally cannot write even basic syntax on the whiteboard. Who put "certificates" from Oracle on their bloody resume and break down under super gentle questioning and confess their tutor hasn't taught them JOINS (wtf ?) yet, never mind 5 years of claimed SQL experience at a big company on their resume.
The coding question is most definitely not an exercise in sadism. We validated it with several new hires who were confirmed to be "good at SQL". Average completion time: 2 minutes, generally with trolling about why do we waste our time with easy stuff.
That being said, my rejection rate from a basic coding interview is at least 50%, grading liberally and generally supported by several members of my team shaking their head about a candidate.
I've tried screening resumes, I've tried doing non-coding phone screens. IT DOESN'T WORK. Actually, all it does is eliminate the socially challenged and non-communicative (who actually tend to pass the whiteboard test) in favor of the liars.
And don't get me started about Python. Lest I bring up the Google-Motorola "I LUV Python heart heart heart" guy who didn't understand the difference between a list & dict.
A lot of times a job spec contains a minimum of 10-15 skill you need to know. And that's just the modest one.
Maybe employers should stop trying to find the non-existing 'developer rock-star' and people would stop lying.
The funny thing is that even the developers themselves start to behave like that when they are on the other end of the hiring (Been there, done that).
"never mind 5 years of claimed SQL experience at a big company" - you can easily have that without touching JOIN.
Most jobs are just 'stuck in a loop' ones. Where you inherit legacy stuff and you're not allowed to change anything.
The crap you can get into and stuck in it when working with legacy stuff is crazy. And you can end up working with something for years without having the liberty to experience and grow.
That's the sad truth about software development. Well one of them at least.
But then maybe the person doesn't belong in to the world of software development.
Another problem is, when you learn something outside of work it wont be enough, because they want "commercial" experience.
Like when they are hiring mobile developers and ask: "do you have any successful apps on the store?"
If I would have any successful apps on the store would I be here doing this interview with you?
What they should be looking for is just someone with good basic skills who learns fast. Of course, they won't do that.
Most of the time the hiring is about replacement, or expansion. And in expansion I mean "the current team is not enough to handle all the cr*p so we have to bring in people, preferably with the same skill set as the others, so we don't have to bother with getting them up to speed" not the "we need more people because we just started something new and we need fresh blood in the system".
Isn't that like saying 5 years of C/Java/C#/... experience and not knowing what assignment is?
It's possible but feels like you haven't gone the distance.
(Not an interview context though; it was a hack night where I was learning ruby and didn't know the right terms to use to look up that question from the docs.)
def foo
@foo
endYes, there are SQL statements without Joins. No, we don't usually run them in the reporting organization....
Reason is, I work with a CMS that handles 99% of my queries for me. It would be monstrously inefficient for me to go around handwriting sql all the time. Any time it happens is by definition an extreme circumstance, so that's how I do it when it happens - with test data, google, and several attempts.
I'm pretty sure that would be reasonable for most jobs, but I wouldn't pass the tech screen if they wanted me to just freestyle it.
I've been driving cars for twenty years, but it doesn't mean I have two decades of experience with fuel injectors.
You are not allowed to change anything and commit it :) But it's amazing how much cruft you can dig out by say, re-writting the build system so that everything links dynamically and then running an address sanitizer build in dev env.
This was about the time MySQL came out, and years before Postgres added SQL support, so at the time your rather pathetic argument might have had merit, because there wasn't actually a way to get hands-on experience with SQL without a pricey license for proprietary software.
I still don't think it's reasonable to claim that you have "SQL experience" if you haven't touched joins. That's like saying you have JavaScript experience but don't know how to define a function.
Now, though, Skype and every browser embed SQLite. If you don't know enough SQL to do a join, it's because you lack intellectual curiosity. Don't blame your employer.
When I was hiring people, I wanted people who could do the job, not people who would lie that they could, then blame my company.
Or other things have grabbed your interest. Are you saying that one lacks "intellectual curiosity" because they have had other priorities than learning this one specific technology?
If we were talking about cuckoo hashing, 386 assembly, or FIR filter design, I would agree that it's "one specific technology" that someone could easily pass over with little loss in many programming fields. But not knowing how to do a join is more like not knowing how to open a file or use floating-point math: it's a crippling deficiency in your skills as a programmer, one that will slow you down in a wide variety of tasks.
Didn't those happen nearly at the same time? Postgres95 (which PostgreSQL started from) had support for some subset of SQL (including inner joins): https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f... outer joins were added a bit later: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...
So why didn't people use SQL in Postgres95? The licensing was fine. My best guess is that the SQL support wasn't yet good enough to be useful. The database as such (transactions, data types, persistence) was already pretty solid, as I understand it.
Dating and interviews go both ways. "I don't want to hire you" is a valid as "I don't want to work for you".
This can also happen if they are just bad at writing job requirements. Remember, it is typically programmers (or their managers) writing these things, and sometimes HR or a recruiter (who doesn't understand any technical details) "cleaning" it up.
They may just mean "Here are the skills we need, we want to hire someone that knows some of these, and is able to learn the rest fairly quickly".
Of course, they could also have someone specific in mind (but are required to post the job anyway), and in some cases may be delusional and really think they can find someone with all those skills.
You may be pleasantly surprised.
Speaking for myself, I will gleefully hop over piles of candidates with a 1/4 page of alphabet soup on their CV trying to talk with the candidate who hammers Python, PHP, Javascript (etc) across a 5+ years of different projects. Even if I'm hiring for a slightly different technology, because I can be confident they actually know the trade.
Multiple skill-sets do add value if they are related and easily combined to deliver a larger solution. Eg. HTML + CSS + Javascript = Front End Web Dev + Python + SQL = Full Stack Web Developer. So I can staff that person in a larger role.
The spew of semi-related and adjacent buzzwords doesn't really help me feel comfortable with a candidate. And if I start asking you about them and learn all you did was read about them online (or used it once for a class), the rest of your resume goes into the danger zone real quick.
"I mastered X, Y, and Z and used them together to build <pure awesomeness>" will get you further than you think. Even if the job doesn't require X, Y, and Z....
Most of my experience with SQL comes from being a game designer with access to analytics database - so, not exactly a lot.
But how the hell would you not touch join even a single time while working with SQL for 5 years?!
1. Total reliance on ORMs, and never actually touching SQL (or not in 5 years since you started using ORMs)
2. Not building complex relational schemas with related items that you use SQL to pull in results of combined data that follows those relationships.
I'd wager #1 is the more common case.
And wouldn't even the most basic data, properly normalized, require joins? I mean - learning about database normalization is one of the first things you're supposed to do when you work with relational databases, right?
Most job listings I've seen don't really have that many hard requirements. They may mention technologies you'll be working with or things they'd like to see, but that shouldn't stop you from applying if you don't know them all.
Take this with a grain of salt because I've never done resume filtering, but when I interview someone, I look at their resume and ask them about the things on it that I also know. (And I'll decline the interview if there's no overlap.) So for my stage in the process, the optimal strategy is to put the things you're best at on your resume, even if they're not listed on the job description. You get to pick what we talk about. For the most part I'll assume that if you've mastered those things, you can master the things we're looking for too.
(Subject to some constraints: if there are four interviews, they shouldn't all be about the same things. So each interviewer might be assigned a broad area to discuss or have to write down their questions/area before the next interview starts so the next interviewer can pick something else.)
> "never mind 5 years of claimed SQL experience at a big company" - you can easily have that without touching JOIN.
I look for a core concept or two for each area/technology and ask about that:
* For SQL, that definitely means join. If you don't know how to join two relations, you should learn or take SQL off your resume.
* Likewise, for C/C++ I want to know that you understand memory safety. Who owns memory across an API boundary.
* For algorithms / data structures (a likely main topic if you're a recent CS grad), that for a simple problem you can use the best basic data structure (array / list / heap / balanced tree / hash table) and tell me the time and memory complexity in Big-Oh notation.
> Most jobs are just 'stuck in a loop' ones. Where you inherit legacy stuff and you're not allowed to change anything.
That's not the sort of job I do or interview people for. I have no idea what interviews for that kind of job are like. But if you're not doing sophisticated SQL or algorithms, surely you're doing something with your time? What is it? Can you emphasize it and sell it?
> The crap you can get into and stuck in it when working with legacy stuff is crazy. And you can end up working with something for years without having the liberty to experience and grow.
That's not a problem with interviews; it's a feature. Why should someone want to hire you if you haven't been growing? Or if they do, why should they want to pay you as if you were actually gaining experience for those years?
I'd be looking for a better job the whole time.
Do it long enough, and you learn how to make almost anything from nothing.
And that should be considered an employable skill....
> Doing ad-hoc reporting is the IT equivalent of being a short order cook.
Nice analogy.
I used to do a fair amount of ad-hoc reporting on an Oracle database. I used joins (inner and outer), subselects (or self-joins), aggregates, window functions (or whatever Oracle equivalent existed at the time), etc. I'd never hire someone who said they did ad-hoc reporting with SQL but didn't know joins, and I'd be skeptical of someone who didn't know some of these other concepts.
Most of these interview questions aren't designed to be trivia. It's designed because your job IS implementation of technical and business problems.
An aside, but I think interviews like this should allow Internet connections. Give the candidate a minute to look something up and digest it in their own way. It should be obvious whether they'll get the concept or just recite the Wikipedia definition. Just as important is how they do their research, and how they draw connections between foreign and familiar concepts given a blueprint of the former.
I don't store everything in my head anymore. I have a general understanding of the concept and a mental pointer in the form of the search term to put in google to refresh how to implement the thing.
I have to implement 10-20 concepts across 5-10 languages or APIs or technologies every single day usually, my brain doesn't work like a database where every record that's inserted is there permanently until I update or delete it. The stuff I'm not using regularly gets fuzzier and fuzzier and goes back to "general concept mode" if I'm not actively using it.
So when someone asks me to write a full iOS app during an interview when I've been making Microsoft business apps for the past year, even though I've written and released multiple full iOS apps at previous jobs, I can't just sit down and produce a perfectly working app like a robot, especially if I didn't have much time to prepare for the interview (that recruiter contacted me three days earlier and didn't tell me he set up an interview until 8pm the night before).
With technical questions it's even worse, because I could have been spending days and days refreshing my knowledge but you happen to choose one of the things I didn't think to refresh my brain on. And so I waffle on the answer and you go "oooh, looks like he doesn't know anything". No, I've got a full decade of making apps and software, in lead roles, in multiple industries with a bunch of different technologies. I know plenty. I just didn't have that question fresh in my head.
Then you pass, and lose out on someone you would have benefited from greatly in favor of the recent grad student that hasn't made anything but toy programs yet got tested on all those concepts within the past six months so it's fresh in their heads.
Maybe. Or you would scoff, turn your nose up, mutter "noob" under your breath, and move on, knowing you're not going to hire me.
I'm sure you yourself would do as you said, but I can't be so sure about random interviewer person.
(Standard disclaimer: Some development positions actually require the academic knowledge mentioned. Most of the time, though, a good developer will use a well-tested library instead of rolling their own.
(If anything my experience is that older developers have a stronger tendency towards implementing academically known datastructures themselves, whereas younger developers are more likely to make more use of libraries)
Now if you are asked to come up with a red black tree without any help, now that is a different story. A red black tree's implementation details are hard to derive given a set of requirements. A binary search tree, not so much.
I could pretend that Python was my favorite language, but that's more that I'm comfortable with it than any sort of actual feeling that I should prefer it over others. That is, I use it out of inertia and familiarity, not out of some sense that I've found something.
People are given a basic coding challenge. On the level of "parse roman numerals" or similar with some tests, standard kind of basic things that rosetta code will list implementations of in every possible language. The code was to be written in any language the person wanted. This was not timed, and was to be done at home.
50%, easily, didn't work. Many did not compile, or were totally incomplete. One was a broken implementation in C# submitted as a single function pasted inside a word document.
Only one person out of I think 20 sent a zipped copy of all the code, a short instruction of how to actually run it, and included some tests.
After that, I started to understand just why these kind of little programming tasks were given.
> And don't get me started about Python. Lest I bring up the Google-Motorola "I LUV Python heart heart heart" guy who didn't understand the difference between a list & dict.
Hah. I've had someone who didn't know the difference between local and global variables trying to come in as a fairly high rate contractor.
That's one of the most inadvertently funny things I've read on news.yc in a long time!
Yeah, many of these kinds of blog posts strike me as being out of touch with what hiring is like. So don't ask about algorithms, don't ask to write code, don't ask to use a whiteboard and ignore if the candidate can't handle the pressure of a standard interview? How are you expected to weed out unsuitable candidates?
Here are my rules:
1. Phone screen coding is optional. If someone is vouched for by a reliable source, you don't fizzbuzz them.
2. The phone-screen question, if used, should not presume any type of formal university CS education (i.e., asking for algorithm regurgitation is right out). Not every good programmer has a university CS degree (many of the best don't), and even among those who do, the longer they've been out of school the less of that stuff they'll remember. Their brain has long since paged the CS 101 algorithms out or even cleared them entirely to make room for the working set of things that actually turned out to be relevant to coding for a living.
3. Good phone-screen questions have solutions in under ten lines of code. Ideal phone-screen questions have solutions in under five, or may even be one-liners in your company's preferred programming language.
4. Once a candidate is past the phone screen, or once you've decided they can skip it, you get to ask them exactly one more question that involves writing code.
5. The final code question must be realistic both as a problem and as a set of conditions. Your employees write solutions to real problems, in editors or IDEs, so to find out whether someone could succeed as your employee that's what you should test. Being able/unable to solve contrived problems by coding on a whiteboard is a completely unrelated skill and does not indicate or rule out ability to solve real problems in an editor or an IDE.
6. The final code question should be a "homework", designed to take a baseline-qualified candidate approximately an hour or two to complete, but to be completed at the candidate's leisure (i.e., set a deadline a day or two after you give them the problem). They should not have to solve it perfectly in 20 minutes on a whiteboard. They should be able to use common/standard libraries. They should be able to use Google or look things up in books they have lying around. They should be able to try running their code and correct errors that turn up when they do. They should be able to do those things because those are job-relevant skills and job-relevant skills are the things you want to test, remember?
7. The interview portion of the final code question should be a collaborative review of the code, discussing design decisions, tradeoffs, and areas where it could be improved/expanded/etc. Being able to present, discuss and review code with others is a job-relevant skill.
8. In a real dev job, at most 15-20% of a developer's time is spent in directly writing code to accomplish a task. The remaining 80-85% is spent in determining requirements, researching approaches to problems, making design decisions, soliciting feedback from peers, reviewing existing or new-but-peer-written code, writing tests, writing documentation, and performing all the other mental and bureaucratic tasks which accompany the act of coding. In light of which, time spent directly writing code to solve interview questions is not permitted to exceed 15-20% of the total time taken by the interview process. The remaining 80-85% should be focused on getting to know the candidate well enough to determine how they'll do with the tasks that will take up 80-85% of their time on the actual job.
I've done my best to phrase this politely. It's based on (as of this point) 15 years of getting paid to write code and having been on both sides of the interview at multiple companies and for multiple positions at multiple points in that time span. But if it helps, feel free to put it in terms the typical tech interviewer is familiar with and think of this as a sort of fizzbuzz for interviewers/managers: anyone who can't figure out how to implement these things may not be qualified to be an interviewer or manager.
- read that file in
- store it in some sort of data structure
- allow users to run commands to retrieve movie titles based on name, release year, etc.
Command-line was totally fine, you had access to the Internet, and as much time as you wanted.
At least 50% of people couldn't do it. One candidate spent hours staring at the screen before slipping out with a note left behind, "I apologize for wasting your time"
In itself this is a good (dis)qualifier; if I give someone a problem and tell them the data will never exceed 10k rows, I expect them to be practical and not waste time setting up a database.
I don't see why you wouldn't use a database for a problem that it's particularly good at addressing.
But most of the people who successfully passed this didn't use a database, it just wasn't enough data to be meaningful - thousands of rows at most.
So it's just a matter of parsing the CSV into some native data structure in your favorite language and then computing sort indices of the columns by which rows might be queried.
For example in python: 1. Load the CSV file using the csv lib in a list of dictionary 2. Fill a sqlite database with the list 3. Read wathever the user asked for (ex: movies longer than 100 minutes and release date before 1999) and build a SQL query 4. Display results
It obviously is, for a suitable loose use of the term, "writing your own database from scratch" (unless you are using an existing library, for which many languages have ones that can be leveraged in the stdlib, including often ones that bring in SQLite). But doing a database of this extremely minimal complexity, or leveraging existing libraries to provide the functionality, is a pretty basic task that anyone expecting to get employed to do software development should be able to do with the conditions described.
I was looking for a couple of months before I went through the process with my current employer, and some of the experiences were just horrible: one company put me through 7 interviews with a single engineer each time, lasting 30-45 minutes, and then brushed me off with a two sentence email. Another wanted me to design an algorithm in 20 minutes while they watched via screen share, and if I couldn't do it in 20 minutes I wasn't good enough for them. Several asked me to take timed tests with prominent counters flashing in the corner. It's just stupid.
So I think personally we should support employers who understand how software is made, and are willing to create the right conditions for you to really practice your craft, and then judge what you've made and how you interacted with potential team mates.
Only once they ask for efficient Levenstein-distance-supporting search do you need to use any brainpower.
N.b. if you choose to parse CSV from scratch, make sure to handle commas in quoted text as well as escaped quotes. The better approach is to grab a library or code snippet and call it a day.
If candidates reason well about design decisions of their implementation, perfect or not, it at least tells me they are reliable developers who do not jump into coding before thinking carefully.
- sqlite
- Storable (perl)
- serialize some other data structure to disk
- in-memory
I seem to recall one or two people over the years who wanted to install a relational database as part of the code to store stuff - we were fine with that as long as you then showed all the right behaviors for dealing with relational databases (using transactions, catching errors, etc.)
But most people read it in and store it in memory - there was only a few thousand rows.
- find and display all movies by the specified year
- substring text searches in the title
Maybe one other. But it wasn't even approaching anything really sophisticated. We just wanted to see that people could write a basic logic flow, read-and-write data application.
Then for the people who did finish it, we looked at the code. Was it well commented, well thought out, did it have error handling (what if the input file doesn't exist? What if something eats your data file while it's running?), what assumptions did they make.
So the base test was basically a sniff test - if you can't do this, you're not a good enough developer to work here. If you can do it, we'll look at the quality of the result to assess how senior you are.
I may wind up stealing this as an alternative test for more advanced programmers; everything here can be done using the Python Standard library.
And kudos to those of you who suggested in-memory storage vs. writing it out to a table.
But the range of times was stunning. There was a lot of people that managed to pass, but it was a three or four hour exercise (I'm willing to chalk some of that up to nerves or overthinking the problem).
Basic technical interviews are a must, but someone people get hung up on "they couldn't explain a hash map implementation," because sometimes "you put a thing in the map and then get it back out later" is good enough for 99% of startup engineering tasks.
Somewhere out there is a sweet middle ground, but it seems not one agrees where it really is.
Further, they may be looking for factors that correlates with other, hard-to-measure factors. Even such as reading a "common interview questions" book - it correlates with focused pragmatism...
And I disagree that looking up the answers to common interview questions is focused pragmatism. I don't bother, even with the knowledge that it would help me get a job. I spend my time working on side projects or learning practical things. I think I will never in my life have implement a hash map, and that knowing it's all O(1) operations is sufficient. But also I guess I don't want to work for a company that is interested in my ability to jump through hoops. (shrug)
Example, if you read a SQL book a couple of years ago, you would say you have experience in SQL. You've forgotten most of it, but you are familiar. If a manager reads that same thing, he or she might think, "Oh, proficient in CRUD queries but not overly complex ones." Manager gives you a quiz on SQL, but since you don't have Google in front of you, you flail because you haven't messed with it in a long time.
It's not really lying, it's just a communications gap. I'm not saying there isn't outright misrepresentation of skills, but most of the time it isn't intentional.
Anything listed on your resume is fair game for questions, especially if you claim it as a skill. "Reading a book" is not a skill; reading a book and using the contents in that book for several real world projects probably qualifies. Especially if you can describe what you did in detail.
Harsh reality: I value everything in that section of the resume at the value of the weakest component that I find. So when we discover that your knowledge of SQL is reading a few tutorials on w3schools ten years ago, I rate EVERYTHING ELSE in that section at the same level (ouch!).
So the safe way to play this is don't list anything that you can't hold a 5 - 10 minute conversation about and explain at least the basics of how the technology works, citing real examples of where you used it (paid or unpaid, I don't care about that, as long as you're clear about what you did).
Yeah. Most of your competitors won't do this. They'll fill out the bottom of their resume with junk. But um... there's a reason they're still looking....
Incidentally my own (technical) resume has exactly two lines of IT skills... each of which I can do a 30+ min speech on. Never had a problem in that area during an interview...
I have an issue with this - i don't lie. Not in CV, not in interviews. We're not managers, we cannot talk our way out of tasks given to us, and most of us who are worth at least a pinch of salt are not desperate to get job X.
But I understand that if your experience is as it is, this is probably correct approach.
Well, I don't either. That makes it much better for me that people use a test that separates liars from honest people.
Yes, the phrasing is bad, but it is a very understandable hyperbole.
Yeah, and honestly, that includes hiring managers.
I've rejected offers because the hiring managers level of deception exceeded my tolerance for bullshit.
> About candidates who claim to know a skill but literally cannot write even basic syntax on the whiteboard.
Yes, I don't remember the syntax from 5+ languages well enough to write it in on a whiteboard. Yet somehow, I'm able to use 3-4 on a daily basis to handle millions of dollars in transactions.
So...I really think whiteboards, once again, are really the wrong way to test people. Code samples and discussing them work much, much better for everyone.
I may be biased...whiteboards, I get rejected 50% of the time. I also find, honestly, that if I ask two technical questions of the people giving the whiteboard test of similar difficulty...they rarely can answer more than 1 acceptably so I've found the failure rate to be pretty consistent with the rate they fail me.
Code samples? I get offers 90% of the time.
Not just the example you gave -- they also lie whenever they list something as "required" and then hire the go-getter who's missing some of the skills.
* Excelling through the test never to hear from the company again.
* Being (as admitted by the manager in the interview) one of two qualified candidates, the other one being from a somewhere a few hours away by plane, and then get a really cheap offer.
* being asked in a disbelieving tone if I can still code after working as a system engineer for a while. (yeah, give me an assignment already.)
I'd love to be in more interviews where I could win just by coding small small samples or discuss code on the whiteboard (that is as long as nobody is nitpicking about things that any decent IDE will catch.)
Sometimes the best available option is mediocre. ("It has been said that democracy is the worst form of Government except for all those other forms that have been tried from time to time.")
I would say the majority of our hires don't complete it and I always explain that's fine, the point is to observe the process they used to create whatever they created.
Also, it can be hard to generate code on the fly in an uncomfortable situation, and breaking the ice is important. I've often wondered if asking individuals to debug, test and fix, or to refactor code, might not be a use way to get a high level look at their product, and ease them into programming mode so when they get to actually writing a function for your next question they are tuned up and ready to go.
Plenty of known-smart, known-qualified people are criticizing tech interview processes. They're criticizing the dehumanizing approaches. They're criticizing the way it wastes the time of everyone involved. They're criticizing the way it produces huge false-negative rates.
And they're right. Many of the people criticizing tech interviewing are precisely the kind of people you say you want to hire but then design processes to exclude. You don't get to shift the blame on that one; if you're really a hiring manager, you should be finding ways to fix, not ways to make excuses for, the tech interview process.
My technical ability is readily apparent to those who have viewed my work, and by virtue of those who have praised it. I don't claim to be the best programmer in the world, just a competent one. I've also been programming for over 20 years, that might have something to do with it.
However, I suck at interviews, in any way shape or form (personality tests, technical tests, you name it). Yet I've aced every job ever given to me, and people love to work with me (even in spite of my salty attitude).
To think that you can determine what it is like to work with me over the span of a year within the span of an hour is completely and utterly ridiculous.
As it turns out, the little sub-problems they give are the most trivial part of programming. The hard part, the part it takes many years to get any good at, is coherently organizing, documenting, and ensuring the stability of a larger system, particularly concurrently with other programmers. Or designing an algorithm that you can't just Google. Or making a really tough decision about what features to cut or what direction to pivot. Or organizing a vision of what will add the most value for the customer. Or...etc
Being an introvert with a monotone voice, general lack of expression, and deadpan sarcastic humor does wonders for personality tests. Most people's default reaction to me (in interviews or otherwise) is that I am a total dick. Which I am, but the kind you don't mind hanging around.
I don't do well with programming that has a one hour deadline. But give me a day and I can produce the typical output a programmer would within a day.
If I spent all my time practicing for interviews, I'd probably be better at them (with stuff like Top Coder or Interview Cake or whatever). And I think giving these things a whirl is well worth it (not for the sake of winning in interviews). But it is not my life goal to be good at interviews. It is my goal to work in areas I am interested, and continue learning things that are directly relevant to my real-world tasks (sorry, writing a red-black tree on a white board within an hour never happens to me in the real world).
You have to look at the programming career as requiring two skills: the first is programming, and the second is finding a job. That might suck, but it's the nature of a career where you change jobs every three years or so.
I have pinged my network, and am very grateful for all the job offers that have come of it. However, at least half those offers have come with technical interviews that basically ignore my work experience, or in one case the recruiter could not even determine why my experience was relevant (even though it was). Some offers involved getting paid to continue working on Voxel Quest. However, one such offer was in a remote country where the US dollar is much stronger, and I could not have operated under the salary they were offering (at least, not without moving to their country, which is very far away).
At this point I am trying to figure out the "best" path, and that involves many factors, one of which is trying to ease up on the stress I have put my family through. By insistence I have put up Patreon although I am not yet touching the money until I know what my future job is and what that means for VQ (and as mentioned I'm also refunding all the money put into VQ).
I always thought I just wasn't as good as I think when I didn't get a job, but I know your work and it is amazing, so hiring companies just don't know what they doing anymore
I'm sure a lot of developers who are currently employed are put off applying elsewhere because the whole process has become so demanding and unpleasant and disrespectful.
One company I applied to for example asked to do a take-home test, maybe 2 hours. I did the test, only to be told it was the first stage of a long and gruelling process involving a further 8 hour take-home project (unpaid, of course) followed my several rounds of technical and non-technical interviews. I immediately withdrew my application. When would I have the time to do 8 hours - it was timed for some bizarre reason, so it had to be done in a single block of time - on a project? Maybe for my own projects, sure, but that's my spare time.
Interviewers and recruiters are, after all, being paid to sit there, while interviewees are - unless they're unemployed - taking precious time off to travel, maybe stay overnight in a hotel, sit through hours of gruelling interviews and tests, all for a job that may or may not offer anything much better than what they've already got. And yet the penny hasn't yet dropped that maybe your shitty process is the reason you haven't found anyone yet?
I'm not sure what the solution is, but I'm convinced that it wasn't this bad 5 or 10 years ago - maybe if you were interviewing at Google or Microsoft, but not if you were applying for a bog standard dev role at a startup or SME.
We should unite together and form an organization that blacklists companies with incompetent hiring practices. :)
I don't doubt that Haseeb is an excellent programmer. But not everyone has two years to devote to mastering the interview system like him, and there are plenty of skills you won't get just by doing competitive programming.
http://haseebq.com/farewell-app-academy-hello-airbnb-part-i/
He's probably a bad example to make your point with. Haseeb had some moral failings, but he is truly on another level in terms of intellect/drive/vision, and the interviewers at Airbnb probably didn't have a hard time recognizing that.
I can't stress enough how smart that guy is. He leaves an impression.
I say this based on my personal reflection, so I could be wrong. The coder I was 10 years ago was laughably bad compared to the coder I am now, and I spent pretty much every one of those years doing 80+ hours of programming per week.
That said, if I had to hire someone fresh out of college, or someone like Haseeb, the choice would easily be Haseeb. :)
" Haseeb Qureshi says: 04/23/2016 at 9:53 am
I’ll be writing more about this in my subsequent blog post. But if you have no connections at all in SV, then I might say that if you’re set on SV as a place to work (sounds like you’re on the fence?) I’d recommend mass applying, and also moving here to start interacting with folks and getting to know people. Building a network is so, so valuable for getting a foot in the door."
Unless this guy is some type of programming prodigy, who in only two years of self learning, somehow blew away all top companies, only to be turned down, then what happened was that he has friends in high places that helped sway their decision.
To be completely honest, the entire article smells like a marketing campaign for TripleByte and AppAcademy. Google wanting to put him on the C++ team, after two years coding in Rails? Get the hell out of here.
But I would agree that it reveals how confused and manipulation-prone the hiring process is; if they're hiring someone for critical, technical C++ work after only two years experience on mostly-Rails, they really don't know what they want. Ditto for upping their offers so significantly based on things that shouldn't matter that much.
I'm likewise skeptical about how Airbnb would tolerate him revealing sensitive details of a negotiation like that in ways that reflect very badly on them and weakens their bargaining position on future hires. Sure, you don't want to fire an employee just for disclosing his compensation (major legal issues there), but his post went way beyond that.
It was about writing a small application in perl (one of my favorite scripting languages) to solve a problem. It was a number converter from arabic to roman and vice versa.
Anyway I started by looking up a perl module that solved the whole thing in 3-4 lines of code.
What was the answer? Sorry that's not we wanted. We would like to see, how you would solve it with general code.
So you're saying that doing investigation work, finding an existing working solution and applying that solution is not a good answer for you?
Sorry but that's how I work. I find a problem; I investigate for a solution; if there is one I use it and implement it; if not then I will write one.
The moral of the story is: interviewing is fundamentally wrong and doesn't help you find a good candidate. There are millions of good solutions to one problem in programming. Asking for a solution you want to see and not a solution that solves the problem will never help. Then why don't you clone yourself and have an army of developers which work the same way and produce the same code with the same flaws over and over and over.
in the same circumstances I would have noted my find and copied the relevant code into my project, not because I'd do that in personal projects, but because companies only care about integrating their requirements with as few external dependencies as possible.
Also most of the times these in-house APIs are developed by if not one, but a handful of people. So if they leave, you are stuck with code which nobody understands and you keep on adding on top of it and breaking it in many ways.
Not to mention your developers will be stuck and get experience with code not used anywhere else. If you want to cripple their prospect to get better jobs and experience, this is the way to go.
It is a vicious cycle and it seems nobody is willing to break it.
Technical interviews (much as I hate the whiteboarding bullshit) do give some insight to the interviewee about the kind of work and codebase they'll be dealing with - like the time an interviewer told me "We're really enthusiastic about MongoDB!" - OK, thanks for the coffee, I'll see myself out....
Without the use of libraries I could not get my job done. I rely on Apache Camel and Apache Httpcomponents heavily. In fact I am replacing a home grown Middleware solution with one that uses Camel right this month because the homegrown solution is just not extensible. I use other libraries as well like Jdom2.
The risk in these libraries going stale exists but is low enough to outweigh the risk of me writing crappy code because my expertise is not that great in writing middleware, xml parsers and the like. My applications work as intended. My management is happy. I am productive in their eyes.
I don't have a NIH attitude.
Edit: added this statement.
At 62 years old I think I am glad I don't foresee the need to change jobs and go through the "modern" developer interview process. I feel for those that have to do this dance.
But you also need to be able to do this kind of thing yourself if you can't find an existing solution, because that also happens all the time. It's that ability that they were testing. That's perfectly valid.
They should however have told you that before the test.
Problem solving skills go a long way especially in programming.
But then the question is how far should you go down the rabbit-hole.
For example, how many variables can someone use? How optimized should the code be, regarding memory and speed? Are you looking at the code to be understandable? Should I use comments? Should I use for or while?
> For example, how many variables can someone use?
I've never heard of an interviewer explicitly limiting this, but if you have enough variables that you're asking, it might be a sign you've missed a more elegant solution to the problem...
> How optimized should the code be, regarding memory and speed?
Don't spend a lot of time on something before you know if it's what they want. You shouldn't go all the way through debugging the naive solution before you know if they're looking for something optimal; you shouldn't look for a very complex but theoretically optimal solution if they looking for fizz/buzz level of complexity.
To make it more concrete, many of my candidates just say something like "I could put everything into an array, sort it, and print it", maybe even adding "in O(n) memory and O(n log n) time". When that happens, I write down "quickly got naive solution", ask "what if we don't have O(n) memory?", and wait for them to (or help them) come up with something else. That's great from my perspective, as is asking me explicitly how much RAM is available / how large the input may be / if I want an optimal solution or an easy-to-understand one.
> Are you looking at the code to be understandable? Should I use comments?
In general, they're probably looking for it to be understandable, but they should know if you're coding under time constraints on a whiteboard that it's hard to revise quickly, that you can't fit a lot of stuff there, and that it's a lot faster to say aloud what you might otherwise put in a comment. If they don't make allowances for that, you'd probably hate working with them anyway...
Consequently, understandability might be more be about picking a meaningful variable name or thinking for a moment if you actually need to special-case some path before adding that extra if statement. Maybe drawing a quick diagram of your data structure.
And if you have extra time (a judgement call: maybe if you have a working solution, they aren't trying to move you on to another problem, you have don't have anything more to ask them), you could refine a bit.
> Should I use for or while?
They should know you haven't had the chance to read their internal style guide. They shouldn't care about this.
I also think they should give you significant leeway for minor syntax errors (saying, missing a ";"). There's a line somewhere between that kind of nitpicking and needing to see that you actually understand the language's syntax. It differs a little by interviewer. If you're anywhere close to the line, they should point out what's bothering them (perhaps saying "the compiler says ...") and give you an opportunity to correct it. If they don't, again they're probably kind of a jerk.
He should have been able to figure that out before the test. It was a test of his problem solving abilities, not his Google-fu.
Still as I wrote on one of the other replies. Yes, you use an API, but you still provide evidence of coding, because you have to write the application, which calls the API.
It was a small piece of code, which took a number from the command line and spat out in the other format. You still have to know everything else to get it to work. Reading input, writing output, etc...
I thought showing resilience by searching for an existing solution and implementing it, instead of reinventing the wheel, will give them a good impression. Clearly I was wrong.
But, when you come across a problem, what is the first thing you do? Try to find a solution and use that, or start from scratch every time? This costs money, time and manpower. Having someone who can solve a problem the fastest way possible without compromising the quality by using a known API which is used and tested by millions of others is the most effective way.
In my book it is a good solution. Believe me I worked with people who couldn't even do that and they are developers.
Their response lets their team dynamic and environment shine through. They came across an unexpected but valid solution and instead of accepting their question was beaten within the rules they rejected it. I'd wager they didn't fix the wording of the question afterwords either.
Reading people is a skill like any other, that must be learned like any other. Most people get lots of practice when young, but not getting this practice does not make you "stupid", it makes you lacking on a specific skill.
In tests like this you make it clear what's allowed - "use the standard library, no external dependencies" etc. Because in a normal working situation, his solution is perfectly valid.
If I were interviewing him it certainly wouldn't be a dealbreaker. I'd probably want to discuss more about pros and cons of in-house vs using libraries, because you tend to find out more about the skills and qualities of a developer from human conversation than scribbling on a whiteboard.
Maybe in company A they are looking for developers who come up with a solution on their own and don't rely on external libraries or Google. Maybe company B don't like developers reinventing wheels and prefer they at least research prior art first.
I don't know what kind of culture your company has, but at the very least out of courtesy you can signal what the requirements are in your test.
One has to ask, but then the mere act of asking might also annoy some interviewers.
Now, if you were signalling to them that googling a solution is the extent of your programming ability, then perhaps you were doing them a favor.
And if I follow your trail of thought, then I hope you're not using stackoverflow when you do your job, because that means you are relying on others to solve a problem for you. Does your boss know about this?
I wonder how many times you copy-pasted anything.
And just for your information I still provided a second solution for them after they frown back the first one.
But hey, sorry if I think solving a problem doesn't mean I have to write everything from scratch.
I was wrong, I moved on, so did they.
If I would have a similar test today I wouldn't go down the same route, because I know what they would expect.
Maybe it was my sysadmin past talking back then. Trying to find a good existing solution for the problem.
And there is the part 'may be a cool job'. Sometimes that part is a lie.
Yes come to us and you will be working with the newest tech and learn new things...
Oh did we forgot to mention we use CVS, Java 1.6 and Expoler 8? You want to use something else? No can't do sweety.
Mechanic: gets out the yellow pages and calls a real mechanic.
Me: ok I'll hire that guy you just called
They're not hiring someone to search. They're hiring someone to code. You proved you could search but not that you could code
Mechanic: "Yes, of course!" - he gets up and collects loads of bits and pieces, metal bars and stuff, then starts to hammer away to create a car part.
Me: "What the hell are you doing?"
Mechanic: "I'm building the part for your car."
Me: "Don't you have a spare or something?"
Mechanic: "Well I don't, but there are spares I could order."
Me: "Then do it man, order one."
Mechanic: "Nah, I like to build everything by myself."
Anyway, using an API doesn't mean you don't have to code.
I was wrong, I learned, next time will be different.
At work we've stopped doing take away tests in part for just this reason. We do have a small pair programming test (fix some SOLID code smells in a small 10 line program) and we also don't expect folks to fix all of the problems within that code.
As a pair programming exercise you can almost walk someone through the first problem with the code (there are two big problems[2] plus four minor issues that you could find) and also you can guide the scale of the response they have to the issues (For example I might prompt them and say if you use mocking frameworks in your current job lets use that and you can talk me through how to use it)
We've had pretty good success with this and does seem to avoid some of talks a good talk but can't do developers.
[1] Getting the library onto the interviewers machine might be a really big issue their firewall might block access / maybe I can't send binaries to you due to your AV
[2] Since it's only 10 lines of code the issues are the sort of thing in the "real" world you might ignore but repeated across a code base would be a problem.
When hiring someone with "fabrication skills" into a machine shop, you certainly don't expect them to order a part during the interview when you just asked them to make a part on the lathe. Which position are you interviewing for, machinist or administrator/purchasing?
This is a common interview tactic: trying to figure out if someone belongs to a group known to have particular skills by their choice of words or similar.
If it's "Could they take a problem that hasn't been solved before and solve it themselves?", then you're not really demonstrating that.
Unless I'm told otherwise, I would assume that a coding challenge would be more of the latter.
Of course, it's not how you'd solve it in real life. But that's like saying you should be allowed a calculator in a mental maths exam because you'd never try to to 27324/623 in your head these days.
The TL;DR of my (short, truth be told) blog post is the moral of your story.
I had an interview where the guy was staring at me like I was interrogated. I had to solve a problem of concatenating to arrays of integers and putting them in ascending order.
I was literally frozen and couldn't think and stood there like an idiot for 5 minutes whilst the guys was just staring at me, not making a sound.
I don't have to tell you I felt destroyed after that. I felt I was a good for nothing idiot and should go shovel dirt then develop software. I still shiver a bit when I think back.
The other things that I hate are the always reoccurring questions. Like what's an array; what's a map; what are the differences; etc...
Come on I've been developing for quite a while now. I've been a sysadmin before that. I'm working in IT for more then 10 years now. Do you really feel the need asking all these things?
This could have been poor communication on their part, or it could have been a test of your communication. Was there an opportunity to ask about requirements before coding up a solution?
When I interview (usually in person), I encourage candidates to ask questions. I'd certainly never ding anyone for asking "can I use <library X / programming language Y / tool Z>?" but my answer might be no.
I'm not a total jerk. When I see candidates make a bad assumption, I'll try to correct them, but depending on the assumption and their communication style that might take 10+ minutes (of 45). I don't want interviews to be about speed, but losing that much time (maybe more than once!) hurts for sure. I'm probably thinking of another candidate who asked the right questions, described an efficient algorithm and its time/memory complexity, implemented it, debugged it, and moved on to something else.
Ideally, interviews are a microcosm of the job. And at least in concept, that principle holds here: on the job, people often rush the requirements and design work, which wastes much more time than it saves and/or causes the project to fail.
So what I do is ask the candidate to tell me about their experience, past projects, and also frankly ask them "what are you most comfortable talking about" and continue diving from here. When they talk about a topic they claim to be experienced with, you can really see what they worth. When someone can't fluently discuss something his claims to be knowledgeable in (yes that happened), that's a bad sign.
Sometimes their skill-set overlaps with what we need, sometimes it doesn't. But the focus is figuring out what they are good at, rather than an abstract test.
Because as far as I understand it we use that process at Google because we can afford a lot of false negatives because we are inundated with a lot of resumes.
Smaller companies and startups surely are not, and finding candidates must be harder. Unless the job market is saturated with candidates.
Many perfectly good, maybe even excellent, candidates will just falter and fail in a whiteboard coding interview. I do, and many people I've interviewed have. Coding on the spot using pen and paper sucks. I think by coding. Give me Emacs and a REPL, and let me go away and think for a bit, and I'll produce something way better.
Smaller companies should think twice before trying to emulate Google, Facebook, Microsoft, etc. In a small company social cohesion is very important, so rapport and personality are very important, cultural factors are important, experience in dealing with similar types of environments, familiarity with technical stack.
That's how I used to interview before coming to Google, anyways. It seems like the industry has turned in very large part to this hostile "prove yourself" methodology...
I have heard more than a handful of CTO's and companies sling this expression around as if using this phrase put them in company with the likes of Elen Musk. It's a joke to me really. I look forward to the day one of these guys says, hey, lets be original.
Contrary to your point, I believe there is a shortage of qualified programmers... or at least senior ones that can solve hard problems independently. Smaller companies need devs that can solve problems independently, with minimal oversight. Copying Google and Facebook is what they think the path is to get there.
From this thread, and my own experience, things are going the opposite way. Companies appear to be able to afford to use more and more arbitrary filters. Which indicates an excess supply of great candidates!
In this case, the author begins the entire essay by telling us that we shouldn't hire on the basis of what someone already knows. One of his first solutions later presented is the exact opposite of this: find out about their level of existing knowledge, regarding specific technologies and frameworks.
He then goes on to rile against "team fit," because of its potential for bias. But his entire solution basically comes down to behavioral interviews, which are notorious for how bias-prone they are.
His solution basically tells us that we shouldn't consider fancy degrees or companies. And yet, in the span of 30-60 minutes, we should be able to form accurate judgement on how much talent and drive someone has, and what they will be able to do in the next 3 years? Sorry, but unless you're the Steve Jobs of character reading, there's no way you can do the above accurately. Everyone lies on interviews. They pad their accomplishments, and inflate what they have previously done. The only thing you achieve through such a discussion, is figuring out how good a talker someone is.
The following article sums up everything that is wrong with almost every "Hiring is Broken" critique ever. Every single approach people have ever thought up, is broken in so many ways, as ably demonstrated by many others. Unless someone has hard data to show why one technique's pros outweigh its cons, such discussions are almost always pointless.
I do this because the candidate pool is swimming with people with great-looking degrees and long resumes and fine references who can talk all day long about computer programming but who simply cannot program a digital computer.
So I ask a 5-minute easy warm-up question and then a 40-minute harder problem. I pace things slowly and give them all the time that they need. I happily answer any questions they may have about the problems, which can all be stated clearly in short sentences. I do not care what programming language they use or whether their syntax would compile or how descriptive their variable names are.
Essentially, I'm trying to not generate a "false negative" result. If you can't do my easy stuff, I really don't want to work with you. If you're a great candidate, you'll have fun with this and take it away in interesting directions.
(Sample easy question: Given two closed intervals [a,b] and [c,d], determine whether they overlap.)
I have conducted countless technical interviews in my lifetime. I agree with the author; it's very difficult to actually become a good interviewer. The skill to judge someone's life and career of several years in 30 to 60 minutes is not something that comes easily. Alas, it's all too assumed to be easy.
When you start, for quite some interviews, you are very likely on either extreme viz. either too strict or too lenient. It takes a while to calibrate your standard, and not give in to an extreme. And that too, only if you introspect, or when someone draws your attention to your interview results.
Many companies don't have a culture which values interviewing as a skill. Rarely if so, I come across a company which has a process of shadowing and reverse-shadowing in an interview, which they take seriously. It is viewed as a cost center, when it's actually a profit-center when done right. And due to my business, I have come across plenty of them. At least in the valley.
1. Screen resumes...throw out anything that seems bogus, hype-y etc. Time investment: 1-3 mins per resume.
2. Phone screen...ask them simple technical and project questions directly from their resume. They wrote it so they should know it. Generally, bullshitters are exposed right away. Time investment: 20-30 mins
3. Take home project. A somewhat simple but non-trivial project like: Write an autocomplete search script using a large text document as your dictionary. This will test their understanding of algos and software engineering best practices. Time investment: 10 mins to review the code
4. They talk with 3-4 other engineers. Those engineers now have a simple project to compare candidates and to question the candidate with. "Why did you choose this algo?", "How did you break down this problem?". Each engineer can ask whatever they want. Time investment: 30 mins.
5. Final engineering huddle. Compare candidates, pros and cons. Gut feelings. Etc. Time investment: 30 mins.
The small take home project is extremely revealing and more useful IMO. You get to see their actual ability at coding a small feature. Is it well-composed? Did they include tests? Do I want to maintain his/her code?
The project also spares the rest of the team from wasting time interviewing non-serious candidates.
I never think this is fair. Why is it fair for the candidate to spend a day working on a project (which you will do for even simple projects, if you actually want to get hired) when it takes you ten minutes to review the code?
> The small take home project is extremely revealing and more useful IMO. You get to see their actual ability at coding a small feature. Is it well-composed? Did they include tests? Do I want to maintain his/her code?
Honestly, you don't get to see much if that person has a day job.
You don't know who wrote it, if they had a friend review it, if they spent two or twenty hours on the project. You don't know anything about them by reading this project.
If it is shit, yes, you probably shouldn't hire them. But if it is good code...
1) The user might be doing something your devs don't understand, because they are bad devs, not because they suck.
2) "Good code" is fairly subjective. I've written some pretty good code and been shot down for "not using a graphing database."
The project is simple. In 10 mins I can easily review the project. Are there tests? Is it well-composed? Does it run? Really doesnt take long for a simple project. Since every candidate gets the same project it is pretty easy to determine a good solution from a bad one.
> You don't know anything about them by reading this project.
You actually know quite a bit about them after a phone screen plus this project. If they cant come up with a decent solution to a small and simple project then they are not advanced in the process.
Mostly, you're determining who had more time to spend on the project.
> You actually know quite a bit about them after a phone screen plus this project. If they cant come up with a decent solution to a small and simple project then they are not advanced in the process.
You're adding another thing to rule candidates out but not in. The problem with exclusion is it becomes more and more likely to rule out good candidates.
This is what really irks me about take home exercises. The candidate spends 2-4 hours (or 12 and say they did it in 2) and the interviewer has no real commitment to reading and understanding it. 10 minutes to review the code? I would expect a video call where we go over the code together.
All interviewing I do, I do while talking to them and give them ample time to explain it back to me.
The candidate is investing their time. You should have enough respect to invest your time too.
The project is simple. In 10 mins I can easily review the project. Are there tests? Is it well-composed? Does it run? Really doesnt take long for a simple project. Since every candidate gets the same project it is pretty easy to determine a good solution from a bad one.
> I would expect a video call where we go over the code together.
Thats what the next step is for.
There are some companied coming to my college for hiring. The first criteria they put was 70% aggregate marks (60% for some companies).
I have seen people who doesn’t know how to write even a small program getting hired, while people with good programming skills are not even eligible to attend the interview.
Going through 200-300 candidates in an interview might be a tedious job, I am not sure. What other choice do they have?
He didn't last long to say the least.
Of course we will never know, if he could have been a good programmer or not, but it was baffling to see people fresh out of uni with zero knowledge.
Two things I've learned about hiring / interviews: it's both very difficult and imprecise.
Process is more like dating than laboratory science; a race to establish rapport (a combination of comfort and trust). To get hired you must sufficiently possess an arbitrary blend of credentials and testing/interview performance.
Whatever it takes to make the hiring manager comfortable and trusting. Some want 10x-ers only, are soothed by strong technical chops/coding test performance, others select for culture and ability to learn. YMMV as selection criteria based on job description, sector, company stage, weather/etc.
This is why personal referrals are so powerful: trust is established MUCH faster, other flaws will be overlooked.
Employers need to screen for this more. So many horrible people making it into workplaces and ruining work cultures.
I'm completely happy doing programming puzzles in interviews myself as I've worked with people that claim to be experts in something when they aren't and some people exaggerate to the point of lying on CVs. As long as you don't penalise a candidate too much for not getting perfect answers I don't see the issue.
After that if they pass - few questions about their code, maybe drill down into some areas depending on the answers etc.
Alternatively, if someone has a project on their github profile using the tech you're looking for - few questions about that project can typically give you a go/no-go right away.
Other people are saying that is impossible to judge someone in a few hours of technical interviews/exercises.
I agree with both, but what's a better alternative? How to you minimise the risk of taking hiring a bad developer? At least, it is my belief that the technical interviews minimise the risk which is far better that ending up hiring someone who is not technically strong.
I can get a good idea of the person through those two simple questions. I throw a few simple technical questions like: What is a primary key? What is a foreign key? What is inheritance? What's the difference between a function and a procedure (Delphi days). Questions that anyone should be able to answer just by writing code.
But then most companies wont be able to show profits if the start spending that much resources on each candidate. Hence they optimize their processes only for precision and not for recall. That explains why a lot of people fail first few times.
1: https://blog.benroux.me/4-steps-to-making-your-interview-suc...
I must do the same. Buy the book and implement it. It directly deals with so many issues mentioned here (great dev but crap at silly tests, great dev but a bad interviewer, etc).
although whiteboarding is not representative of Industry workflow, I feel that it can be used as a metric for communication. everybody knows that it's coming, and everybody knows how to practice it. if you perform poorly on whiteboarding that means you didn't practice it. it's a learned skill it's not a natural thing.
anybody I've met who complains about having trouble in whiteboarding has also never seriously practiced it.
the modulo operator was obvious to me and after the interviewer kept adding conditions to the problem, they then asked me why I didn't concatenate strings instead of my approach of returning the string in each conditional statement
so fellow engineers, without having the telepathic skills I possessed that allowed me to know exactly what traits the interviewers were looking for, would you have:
a) erased your entire correct solution to write a more efficient solution, not knowing the time constraints for this problem
b) created the most efficient and scalable fizzbuzz solution known to man at the beginning? in the 15 minutes provided
c) laughed in the interviewer's faces since it was obvious the question was irrelevant to how you would solve problems for the company on a day to day basis?
d) other