I have decided that I will no longer take technical interviews.
I have 25 years of software development under my belt, I published a book, spoke at various conferences in Europe, have a Github profile (admittedly not very lively), worked for well-established enterprises and have great references. Why shall I still prove myself?
If I was a senior lawyer or an architect joining a new studio, I strongly doubt I would have to go through an interview to test if I can use the drawing table or if I know the body of laws of my countries. It is just ridiculous.
As I work as a freelance, my approach will be to offer 2 weeks of work on site for free. After the 2nd week, if they still think I'm good enough for the company, I will charge the 2 weeks, otherwise goodbye and no questions asked.
Well claiming is a very far galaxy from "demonstrating". What about references? What about networking? What about published books and papers. This stuff is very hard to make up, especially references.
It can be a chicken and the egg problem. None of those matter if the person can code and solve problems, and is a good fit. We don't care if they are 15 or 60 years old.
This. We get candidates (HFT) with a CS degree from MIT or something, with 15+ years of industry C++ experience as a senior software engineer, who can't explain the difference between a list and a vector (or when to use each), or give even a ballpark estimate for search/insert/remove times for a basic BST. At the same time, there are candidates who are technically good at coding, but terrible problem solvers. We do use whiteboards for the interview, but more as a conversation starter for the algorithmic design, and don't expect compile-able code. In fact, when I interviewed here a year ago, I didn't touch the whiteboard, and we just talked about the design, tradeoffs, wrinkles/edge cases, etc.
It is usually a pretty organic process. If we get into it and question their coding ability, we might ask a few basic questions, like how do you declare an array or vector in C++. Do you use std::algorithm? Then possibly into C++14 territory. It depends on the position. On the other hand, if they breeze through some basic coding questions, it quickly turns into a discussion and feeling the candidate out in terms of fit. But if we get a senior SE come in, and we talk about previous projects and we get "I fixed bugs, reduced memory usage, and saved $X million dollars" that is a big red flag.
> We get candidates (HFT) with a CS degree from MIT or something, with 15+ years of industry C++ experience as a senior software engineer...
Sounds like your expectations are part of the problem.
Why do you expect someone 15 years out of university, working in the now enormously wide software space to have your pet questions memorized? C++ is well known for being too big and needing to be subset(-ed). And, why not realize that such a person could become an expert in those questions in less than an hour of googling and reading?
The bigger problem is that companies are not willing to invest even four hours of training into employees!
I assume you're exaggerating slightly and that you mean "couldn't code as well as the resume suggested". How certain are you that the pressure of the interview (which often means broken concentration, poor sleep the night before, etc) and the unfamiliarity of the setting (even typing in a Google doc without proper spacing, syntax highlighting and auto completion can be incredibly disorienting) aren't a major factor? Isn't it conceivable that some worse coders are better under such circumstances than a great coder who suffers mightily under them?
I don't think he's exaggerating; for the past 4 positions I've had to fill (at six figure comps) 80%+ of candidates with extensive resumes couldn't solve a simple recursion problem. We give the a notebook with an IDE and access to the language docs.
These folks with many "senior" level positions on their resume can't manage a task our last hire did in about 6 minutes.
Your approach seems sensible as a freelancer. Hope it works out for you! But I don't think it would work for someone who's full-time employed looking for another full-time employer:
1. People can't just take two weeks off to go code for another company.
2. With so many other candidates out there, a company is typically not going to bother with an "eccentric" who refuses to interview. (not saying you are eccentric, just that's how you'll appear next to the other 100 traditional "interview me I need a job!" applicants)
I've seen #2 play out in real life. Company interviewed a guy who refused to do any code on a whiteboard, even simple fizzbuzzy stuff, pointing to his multi-decade resume full of big name companies and high-profile projects as proof that he's good. The company's response was basically "OK, there's the door".
Maybe so. We use whiteboarding as a jumping off point for discussion, not to implement trees or graph traversals. It is usually apparent within a few minutes if the candidate knows their stuff, and we move deeper. Additionally, there is always going to be an onboarding period, where the new hire is learning how our team does things. We spend a lot of time communicating and drawing out ideas on whiteboards. We need to see if you can communicate clearly. Saying "naa, I don't whiteboard" is NOT a good start. In all likelihood this person would be a bad fit.
I'm not sure I'd go for that TBH. I've seen candidates who are good on paper (one former university lecturer springs to mind) who was incredibly difficult to understand and his experience was irrelevant.
We typically need to hire quickly, and having to wait 2 weeks - and coach someone on all the different components, create accounts for them, etc. - is not "free" for us.
If you're that good you should blaze through the technical questions in half an hour, and give us all confidence we're not wasting each others' time.
Then again you're a freelancer to so it's a bit different to being hired as a contractor/permie. But either way, we want the hiring gap filled, not as something we have to revisit after 2 weeks before we decide whether we have to go back out to market.
Put it this way. You come in for an interview, refuse the tech questions and we're left thinking "this guy looks good on paper, so why doesn't he want to explain what a design pattern is?". Straight after you a guy comes in who answers the technical questions OK. Who do you think we'd hire?
Talking about patterns, technologies, how I would architect/design a specific solution or how I would approach a technical problem is not a technical interview, IMO. And I would be glad to answer these questions, which are fair and interesting.
What I'm talking about are the quizzes and the puzzles, the invert-a-binary-tree riddles or, as it happened to a friend recently, to write a full blown application with tests and stuff and don't even bother explaining why the application was rejected.
It doesn't make sense anyway. In 25 years, the sheer amount of cowboys I have seen literally bringing down projects out of incompetence and lack of humility is staggering. And these guys were hired out of technical riddles.
Oh right. In that case fair enough. I'd far rather have a walkthrough of some of your github code to see your style and reasoning.
As a Good Person, you should get taken on by clients who don't have this requirement while others who do lose you.
I've only done one of those tests in the last couple of years because I wanted the (not insignificant) pay rise and it gave me an opportunity to learn something. It's all about negotiating power (they had more).
But yeah, in general I don't have to bother with them. OTOH I don't see them as entirely negative because hopefully it should mean you'll be working with competent people (provided the tasks are small demonstrations and not full applications which smacks of incompetence).
Also, don't you think that the technical competence of a candidate is just a fraction of the elements required to work in a company? What if the guy is a complete toxic worker or dishonest etc. etc. It is not that difficult to pass a technical interview, after all.
I think that two weeks are a good time-frame to evaluate a mutual "love" and would also help better understand the soft-skill and how well the candidate fits in the company.
Yeah there'll still be a probationary period in case someone's toxic. But being inadequately skilled is a deal-breaker and something you can go some way to filtering for before you offer someone a job.
If you go with the notion of "I don't need to prove myself, I'm good enough - look at what I've made", then this is exactly how it should be. Otherwise you're still proving yourself and providing 2 weeks of your highly valuable time for free.
Those 2 weeks should determine whether it works out on other levels (e.g. are both parties comfortable with working each other) and if you do work in that time, you better charge for it.
You grossly underestimate how conservative and risk averse most clients are.
As a consultant I have tried a variation on your approach. I've offered to work for a client for 2-3 weeks. At the end of which THEY get to decide how much I'm worth. I reserve the right not to carry on working for them but for those 2-3 weeks I will accept whatever they pay including nothing.
In over a decade not one client has accepted this deal.
Dunno, not sure this applies. My reaction would be that it is too much to think about. I'd just want to pay a certain rate and be done with it, not load up on ambiguous ill-will.
Now, the GP says he will work first two weeks without pay? Simple to understand and accept.
I'm sorry, but I'm not sure I understand. Why do "they" decide how much you are worth? Don't you have a daily/hourly rate that you communicate up-front?
The whole purpose of the offer is to let the client decide how much you're worth to them. I provide no up-front rate or fee.
It's always the clients who claim to be 'innovative', 'game changing', 'disruptive' etc. that are the most risk averse. They seem completely blind to the cognitive dissonance.
Maybe it'd require a trip to their (no doubt expensive) lawyers to make sure the arrangement doesn't sound too good to be true and open them up to legal action if you're not happy. Perhaps it's not worth the time/effort/cost for them?
This is why I prefer dating contracts to deep technical interviews. If someone shows enough promise in their CV and portfolio, and they're personable enough to sell themselves reasonably, then a 1-2 week contract to cover some real work is low risk and a better measure than trivial whiteboard problems.
I can't upvote this enough. In the age of Github, if a candidate has an impressive body of work and can "talk the talk", a coding interview is wasteful, potentially misleading and insulting. As soon as enough candidates balk at them, companies will stop doing them.
I don't have a github account. All of my work previously was academic research, in which I have 10+ years of writing software, and currently it is all industry/proprietary. I thought the process I went through at my current company was great. A short phone screen, a coding test (~1 hour, with a week to complete), then an on-site, which took 1 day. The first two hours was a coding test, then I met with several teams, which were mostly high-level discussions and a few problem solving questions.
We're not architects, and nor do we have a certification system. There needs to be SOME way to probe a candidate's abilities, and it's not easy.
That sounds like a sensible way to work as a freelancer. Have you already had success with it or is it just a plan for the future for now? I'd be interested in hearing how it pans/panned out.
Well, yes and no. For around 3 years, I have been running my own consulting company with a friend. We were doing pretty much what I do as a 'solo' consultant, except that we were fronted by a company. This automatically removed the need for interviews. As soon as I sold my company and got back to solo consulting, I had to re-enter into this ridiculous circus which are technical interviews.
So, to answer your question, I will apply this approach from 2016.
What? "Implement as much of Minesweeper as you can in an hour?" If you're going to build something--evens something as simple as Minesweeper, you're still going to need time to plan it out, diagram it, decide which modules call into which other ones, decide on the data structures, etc. Diving right into writing code so you can get _something_ done in an hour is probably the worst strategy if your goal is to do it right.
I'd rather work with the person who would approach that by taking 3 hours to plan, 3 hours to code, and 2 hours to bug fix, rather than the "Ready, Fire, Aim" person who took 1 hour to code, 4 hours to fix what he did, 8 more hours to find his design was totally wrong and re-do major portions of it, 8 more fixing the bugs in that version........
Unless you plan to filter out the people who just jumped into the code, in which the exercise is just a trick question.
It's minesweeper, not an enterprise storage server. Spending 3 hours planning minesweeper would be insane. Heck even planning for more than 20 minutes, in my personal opinion, is overkill. You should be able to at least get started before the 30 minute mark and if you spent half the time planning should be close to being done before the end of the hour. At the end of the hour, just explain what you have left to do.
I don't know how to play minesweeper, so how on earth am I supposed to solve it in 30 minutes? Looking up the rule in 30 minutes? I don't know how to play Sudoku either. DO you know how to play Go? Can you implement that in 30 minuets? Do you know how to play Mofoka? Of course you don't know Mofoka I just made it up. Please think about how ridiculous it is to ask someone to implement a game in an interview.
I'd expect the interviewer to explain the rules beforehand, probably even show the game quickly. That way everyone starts off with the same amount of knowledge about the game and then it's all about programming.
I've had folks who just jump into the code without any planning. It usually bites them about 20-30 minutes in. On the other hand, I remember one guy who spent the first 20 minutes planning and only 40 coding and ended up doing better than most.
The point here is not "Write as many lines of code as you can". I want the candidate to plan - it's a crucial part of the job. FizzBuzz, sorts and the like don't require much planning. Minesweeper does.
I decided to have a go at this, even though I am at best a JavaScript dabbler.
I did plan...but if you were watching me you would not have seen me planning.
I decided right away that my display was going to be a table with one table cell per Minesweeper cell, with the table cell's ID of the form "X_Y" where X and Y are the coordinates of the corresponding Minesweeper cell. I did the rest of my planning while getting that HTML written (first in vim, and then when that was going too slow even with macro assistance by writing a little Perl script to generate the HTML).
I was not able to do it in an hour. At the end of one hour, I had everything for a rudimentary Minesweeper coded, but had a bug in the code that reveals the cells around a clicked empty cell, and it took another 20 minutes to find and fix that.
A couple of years ago I applied for a certain company that this year turned out to be a unicorn.
The automated reply said to build a Minesweeper. So I did. It took a several hours to get into a shape that is playable. Then it took several days to polish it into app store quality.
If you are wondering how it went from there, they were "evasive". Then I got a softball "center a div" interview with one of their front-ends. Then I got a polite no thanks from the recruiter.
Automated response questions are so disrespectful. "We won't take the time to see if we're in any way interested, and won't unless you devote your own time."
Even worse are automated responses from a no-reply emails like jobvite or friends.
If I already took the time to interview with you, invested hours of my personal time into you, maybe even took a day off just so I can make your weird schedule, give me at least a personal answer or a chance to ask for questions.
I love to learn new things and actually really want to learn about the mistakes I made. Giving me a "no thank you" from a noreply after all that time is like a big middle finger in the face.
Absolutely. I got one a couple of weeks ago. It asked me to design some API and other arbitrary garbage. Obviously an auto response. They also had the nerve to "cap" it at 10 hours.
I won't even respond to these "companies" anymore. It's a waste of time.
I live in Switzerland and I used to code for a living. As an external, I hire engineers for different startups in Zurich.
As I got deeper into IT-recruiting, I realised that candidate filtering at the top of the funnel is fundamentally broken.
The market for software engineers is different from the market for - let's say - actors. Especially for senior developers there is way more demand than there is supply.
This has the very important implication that as a company you can not annoy candidates too much. Asking for tedious homework, too many coding challenges or references might be already overkill. Good people do not really need to work for you; they can also work for Google Zürich (biggest engineering office outside the US), or other cool tech-companies / ETH-spinoffs.
If you look for a tech-job in the most liveable city in the world, check out my story "8 reasons why I moved to Switzerland to work in IT" on https://medium.com/@iwaninzurich/eight-reasons-why-i-moved-t... or send me a mail to the mail-address in my HN-profile.
> The market for software engineers is different from the market for - let's say - actors. Especially for senior developers there is way more demand than there is supply.
The "undersupply of engineers" meme again! This is a simplification. Supply and demand are measured at a given price. There may be way more demand than supply at one price (salary), but supply and demand is balanced at a more appropriate salary.
"I heard that meat bought in Switzerland is from Switzerland but meat bought in Germany is often from Poland or from somewhere else. In any case, meat in Switzerland is tastier than meat in Germany" - Polish meat less tasty? : ) I didn't get that one
I was joking. You are entirely entitled to give your perspective and advertise your services as long as you are transparent about it, which you were. No apologies or explanations needed.
I wonder if the OP has ever read any actual research on effective hiring practices. I have a FAQ for that.[1] The short answer that research gives is to set up an actual work-sample test for the job in question. The longer answer is to add in a VALIDATED test of the worker's general cognitive ability. But if that kind of test isn't validated, the employer can be subject to legal consequences in the United States if the test has "adverse impact" on protected minority groups. Rather than just making up hiring procedures, companies ought to do research on what works for finding better workers and what is not legally risky for the company.
I can confirm that this works incredibly well. At my previous job, my team was responsible for technical training. So our interview process involved having the interviewee give a 30-minute presentation and teach us (the interviewers) a technical topic. Everyone we hired ended up having stellar job performance.
I had an interview like this recently. A "live coding" exercise after (in their words) two excellent phone screens.
The test was to implement a class which would be run through a bunch of unit tests. Simple right? It turned out to be a disaster.
First was the choice of language. They offered to take it in JS, Ruby, Python, or Java. I'm a .NET developer whose competent with JS, but I really could be better at it. I asked to take it in C# but they refused and said it's not about specific language knowledge. So I did in in JS. I turned out to be almost completely about JS specifics and quirks. Because I've been learning JS recently, I've had the fortune of having to avoid the bad parts. When asked to recite them I struggled. This part is obviously my fault but if I had been allowed to perform in C#, I would have done a hell of a lot better.
Second was the environment. I have very limited exposure to programming on a Macbook and I spent the first few minutes struggling to translate all of my shortcuts. During a timed test it was pretty disheartening to not be able to type as fast as I could. I haven't used Sublime before but the default theme was near unreadable and I was allowed to switch it after a few minutes. The third was the test framework. I really wasn't familiar with how Jasmine worked in the browser, and it showed. Again, my fault. But taking 5 minutes to familiarize me with their setup would have made things go much, much better for me.
Before I get jumped on for blaming them for my poor performance, this was for a test automation role. I explicitly said that my JS/Jasmine/etc. skills were not that great and they still brought me on site.
Honestly, I would have preferred the whiteboard. Each test took up nearly the entire period, leaving very short time for talks about what I really care about - culture. I have a Github with a bunch of good projects. I've been employed as a developer for a while now. I can obviously program well. Drop the bullshit and lets talk.
I sympathize. I remember when I was first applying for tech jobs I was often given a mac (which I was unfamiliar with) set in Qwerty (I used Dvorak) and told "just write this."
Even asking them to change it to Dvorak for me (since I wasn't familiar with the menus) I could tell they were judging me. Once I bit the the bullet and learned the mac interface suddenly people were assuming I was super hardcore because I use Dvorak.... Stereotypes cut both ways I guess.
I explicitly and repeatedly told a recruiter and the hiring manager from a (unicorn) YC startup with a large logistics component that, while I am a data scientist, I don't do OR / stochastic processes. I took a single class on them over a decade ago and that's about it. They repeatedly assured me they also needed someone who builds classifiers/models user behavior. Guess what the the in-person interview was about...
I've had interviews where they told me to code on paper, with full syntax (no missing semicolons). This included drawing out db tables and their relations etc.
At one place - they gave me a very old computer and their actual code base and told me to fix a bug. No other information provided (that was actually a fun exercise).
Different places do it differently - but all I can say is that none of these are enjoyable to the interviewee, and I think in most cases they are not enjoyable to the interviewers either.
But the absolute worst thing is dealing with recruiters - starting with asking candidates to fill out forms so long that would put gov bureaucrats to shame. They also have a list of tech questions given to them to "screen" candidates and you can guess how that goes ("No not Linux, have you worked with LAMP?", "I am not talking about Javascript, I'm talking about jQuery, could you rate yourself on jQuery?")
Ouch, that's just a crummy interview experience. If you're coming in with the understanding that .NET is your best language, seems odd they wouldn't allow that, or at least make amends, such as letting you know in advance that it'll be about Jasmine, or using your own IDE.
Sounds like you dodged a bullet working for them. Personally, I would avoid any company that forces you to use a specific type of computer/os without a good reason (such as iOS development or Windows specific). Good companies will let developers work in what makes them most comfortable, whether that's *nix, windows or OSX.
As a counterpoint, I'm fairly confident it's possible to hire engineers without seeing the code anything at all. I'm not an expert, but I do know that I've never felt like a homework/sample code/whiteboard exercise I've done has borne any real resemblance to the work I do.
I've never been required to provide a code sample for a job interview nor have I ever asked for one. I've had pretty good luck sussing out who knows what they're doing based on their ability to talk in detail about what work they've been doing.
"You wouldn't evaluate a chef's ability to cook by depriving them of saucepans, why cut off Google?"
Depriving of recipe books is perhaps a better analogy? I think depriving of saucepans would be like hiding the keyboard!
That actually works pretty well, even doctors are expected to look things up if they get stuck. Why should programmers be any different? SO is extremely useful for funny edge cases in software that someone else spent an afternoon trying to figure out.
Uggh, been interviewing this month and it has been mostly awful. From "who was your worst boss/what is your worst quality" to "solve this problem with us watching, clock ticking, and a $150k on the line."
Also, the only profession (I know of) where twenty years experience is considered a detriment. Perhaps fashion modeling is another? ;)
It's odd, isn't it? Twenty years of experience is considered good, but twenty extra years of age is considered bad. This actually goes a long way to explaining why interviews are such an odd experience - companies recruit for experience (must have launched successfully with experience scaling), and then testing for exam-ready knowledge of second year algorithms and data structures. I suppose another way to put it is that employers would like people with 20 years of experience who graduated from college last week.
Where I work we do something similar but it's a "homework" question we give to people who pass our initial resume screen (https://github.com/maxmind/dev-hire-homework). We tell them not to spend more than 1-2 hours on it. We decide whether or not to interview them based on the quality of the code they produce.
In the interview we ask things like:
* what is OO and how is it different from procedural programming? (high level conceptual)
* why do you want to leave your current position?
* what appeals to you about this job? what do you think you might like least?
* what is the purpose of testing?
* tell us about the programming languages you've used. what's your favorite? what do you like most about it? least?
I'd rather have a more conversational interview after already having established their ability to code.
Homework exercises are a large burden on the candidate, so expect to half your pool for that reason alone. I only do about half or less of these, as most are crappy an unrelated to the job. I prefer to plan and do things thoroughly, not rush a solution out in a couple of hours. And to be honest asking for more than a couple of hours is more than you should be asking unless you are willing to pay.
"Homework exercises are a large burden on the candidate"
People keep saying that, but I'd MUCH, MUCH rather do a single couple of hour "homework exercise" that I can submit than do a full day (or more!) of "implement whatever pet algorithm/data structure I think is really swell" for like 3-6 different people in series, which is how a horrifyingly large amount of companies still tend to do things.
Give me a task, let me do it, have your tech people discuss my solution amongst themselves. If they like my solution bring me in to discuss it (to verify I didn't "cheat") and to determine culture fit. Seems like a lot less wasted time for everyone with far few of the stressors (hard time pressure, etc) that make most tech interviews so amazingly terrible.
> People keep saying that, but I'd MUCH, MUCH rather do a single couple of hour "homework exercise" that I can submit than do a full day (or more!) of "implement whatever pet algorithm/data structure I think is really swell" for like 3-6 different people in series, which is how a horrifyingly large amount of companies still tend to do things.
The best part is that a lot of companies make you do both : ) I've had that happen to me.
We've had a pretty good response rate when asking people to do this. Of course, I totally understand why someone would say no. I'd love to find a better way to evaluate someone's skills, but absent a good public FOSS portofolio, what are my options?
Ask them to bring in a sample of work and discuss it? I have plenty of work I could show people, but I don't have on github. Admittedly that won't work for everyone.
This methodology may correctly filter the candidates the author is seeking, but if this made up the bulk of any interview I attended, it would probably turn me off the role.
FWIW, when I attend an interview, as either party, I want to have a discussion, a bit of back-and-forth, and crucially to determine if it's likely we'd be able to get on, day to day. Coding competency is not the only important thing. And anyway, it can easily be established via a bit of white-boarding, conversation, and preparatory reviews of any existing work they have online. If you are in doubt, then maybe pair on a fun little algorithm,... something that's not solved, and not dull. Something original would be best.
Being given a pre-packaged task to complete feels very procedural and bland...
I get that. I just would rather not feel like a monkey being prodded whenever I attend an interview. An interview being repeatable (for comparative purposes) brings no value to the candidate.
It does if the candidate is something that the interviewer might be biased against (race, gender, opinions on Star Wars). Avoiding bias in interviews helps everyone except those who rely on irrelevant qualities to get jobs.
Maybe, but I feel that the answer to such biases is to introspect and understand your potential prejudgements, and then not let them specifically sway you. Anyway, the accepted alternative, an entirely meritocratic process, is fraught with issues too, as the playing field is inegalitarian to begin with -- so those candidates who might be the victims of unfair biases could already be at a disadvantage since they might not have received the privileges that preempt meritocratic success. It is assumed that relying totally on a candidate's coding ability somehow avoids the issue of bias and works to mend our diversity issues in this sector, but it actually merely plays into the entrenched state of things. I don't have a solution, but this entire problem-set is certainly deserving of more nuanced thought.
Interesting points. Like the idea of the giving a developer actual development tasks.
This is how I interview - We have a bitbucket set up with a project very similar to our current site. We simply ask everyone who applies to get the code from Bitbucket and install it locally. And then fix a simple bug. Most developers who are well versed in the basics are able to install the code in 2-4 hours. People new to something specific are stuck for a day. It helps us weed out people who are a) Not comfortable reading code b) Not hungry enough to ask questions or google a little bit if they do not understand c) Not able to debug and fix simple issues.
So far all developers who have lasted that test have been good technically. Its another challenge to keep them motivated over long periods of time.
Would be funny to come into an interview as the candidate and give the employer pre-packaged tasks to complete to evaluate them on, to decide if I as the candidate actually want to work there.
I've got the outline for another article along these lines (how I prepare for an interview) though it's been longer since I've been through an interview.
As a candidate, you'd bring less pre-packaged tasks and more questions and things to look out for. When I'm on the other side of the interviewing table, I evaluate the company as much as they evaluate me. Things like "What does it take to succeed at this company?" and "If I'm not meeting expectations, how will I know?" are critical to see if you want to work there.
I've been toying with the idea of asking for a reverse interview. I get to ask about the challenges they've solved in great detail and how they dealt with potential and actual issues. They get to answer and decide to I know what I'm talking about.
Do it. You'll quickly find that their interview questions go out the window since you're demonstrating your knowledge obliquely: "Oh I've never really seen the benefit of docker for most architectures". Cue discussion on architecture, SaaS, devops, etc... I would far rather meet a candidate like this.
Is this not the whole point of the interview for you now anyway? For me, if I go in somewhere and get grilled for X hours and they deprive me of a chance to ask about certain aspects of the company, you can guarantee u won't take the job.
That's what I'm counting on. Most startups are sufficiently desperate for hiring that you can ask for things like "I'd like to grab coffee with the CTO" and they will do it (that seems trivial at a 10 person company, but I've heard it happen at 100+ person teams).
Where I am right now, I'm pretty happy just turning down the interview if I don't oblige.
I was really liking this piece, but one inherent flaw of the example given is that I've already implemented minesweeper in javascript once a couple years ago for a programming challenge, so I'd have a major advantage over most candidates.
For example, I immediately recalled I solved the problem of mine placement with a 1 liner like:
Correct me if I am wrong, but wont this result in the mines being placed in the front more often than not? sort(function() { return math.rand() - .5; }) doesnt result in a truely random distribution.
It evenly distributes over 0-1. Removing .5, just distributes it evenly between -0.5 and +0.5.
Sort basically says >0, the first option should come first and if <0, the second option should come first.
I believe this still maintains a random distribution and is quite a tidy solution. Thoughts?
It can be extremely biased, and the results can depend on the sort algorithm, because what you're randomizing is the comparison results, not the order. Consider insertion sort: https://en.wikipedia.org/wiki/Insertion_sort
As the list is sorted, elements are inserted from the back by finding the first element that the new element is smaller than. The last element to be inserted is the one at the end of the unsorted array, and, with a random comparator, it has a 50% chance of being "larger" than the biggest of the rest of the elements, and thus remaining at the end of the list.
Microsoft used this technique to "randomize" a list of browsers back in 2010, but, when viewing the page in IE, it ended up putting IE in the last position (out of a set of five browsers) 50% of the time: http://www.robweir.com/blog/2010/02/microsoft-random-browser...
Am I the only one who, when being interviewed, doesn't mind whiteboard coding?
At interviews where I've later been given an offer, it's usually a relatively small algorithmic design challenge, where the specifics don't matter, just the pseudocode.
In interviews I've given involving whiteboard programming, I've always emphasized that it doesn't have to be valid or even semi-valid code for any language, just a semi-rigorous pseudocode expression of an idea.
I think, "if done correctly", whiteboard coding is a good filter for those who can think algorithmically, who can catch the bugs that aren't typos, but incorrect assumptions.
That said, that sort of mindset may not be what you need for your role. Need to consider that.
---
Tangentially, one of the better technical interview experiences I've had involved chatting for a while, the interviewer describing an actual problem they'd had (relevant to the role and the company's product), and discussing my approach to the problem. (and passing or failing the interview wasn't dependent on using the exact same approach...)
> Am I the only one who, when being interviewed, doesn't mind whiteboard coding?
I'm sure you're not, but my experience is completely opposite of yours. I'm still relatively early on in my career (I've had 3 software jobs, but have grown up coding since I was 12), but every job I scored was one that didn't use a whiteboard/paper problem during an interview.
I got a lot better at whiteboards with practice; but early on, every whiteboard problem I received resulted in me blanking on even the most basic concepts. I would have no idea how to solve problems on a whiteboard that I explicitly solved in a codebase the week prior. Then I'd step out of the interview and the solution would just hit me.
It's like state-dependent learning, in a way. As I got tested more on whiteboard coding, I figured out that whole problem-solving process better, and I do pretty well on them now. Still, I continue complain about those problems. They feel like a completely foreign, perpendicular challenge compared to having a discussion, answering questions, or writing code to solve the same problem. It's not a skill I've ever used outside of interviews, nor is it a situation that has ever been simulated at any workplace I've been at.
There's nothing wrong with evaluating a candidate's whiteboard presentation skills. If the goal is specifically to evaluate technical or algorithmic knowledge, it's worth taking into account that testing for that knowledge on a whiteboard can introduce a side-effect that bottlenecks the candidate's ability to present their answer.
Whiteboarding is a skill that the vast majority of people will have to work to obtain. It's not the natural way that we work.
Personally, if you know you're going to be interviewing, start practicing for whiteboarding. There are books and online resources available to help you get at least comfortable with it. The resources also help drive home that whiteboarding should be about process, not about perfect solutions.
Algorithms have generally taken years to perfect by PhDs, why should you be expected to perfect an algorithm you haven't memorised in 30 minutes?
Do that many places ask you to perfect an algorithm or solution? Most places me and my friends have done typically just want any brute force solution with some discussion as potential ways one might improve or discussion on why this might not be ideal without having better ideas. And this is from top places and offers. And were from non top schools.
I still think the best way to interview a programmer is to just talk to them. Ask them about their experiences. I've known a bunch of programmers in my time, and I feel I can tell if someone is the real deal within a few minutes of them speaking.
I'm happily employed at the moment (knock on wood) but when that day comes where I have to go back out an interview, I don't plan on wasting any time doing these kinds of interviews where they make you spend hours doing some kind of programming challenge. To me it's an indicator that the company doesn't have anybody knowledgeable to actually pick out the best programmers.
I can see this being misinterperted badly in the field of software engineering (it doesn't seem specific to software) as it says work sample tests are best, yet most software is large scale, and takes time to develop and ought to involve planning, architecture, coding, technology selection, testing. So most "sample work" for an interview will actually be nothing like that but a short rushed version that is supposed to emulate it in some way.
"but for many jobs there are too many variables involved day‑to‑day to allow the construction of a representative work sample. All our technical hires, whether in engineering or product management, go through a work sample test of sorts, where they are asked to solve engineering problems during the interview."
Plus a number of other things according to the article.
Sounds like they are agreeing with what I said (at least to some degree), but still asking for something anyway.
It won't work better if you give candidates so many tasks that they think, "why bother?" and go for another easier job application process instead. People have other commitments, and we are often told there is a shortage of developers.
I have told potential employees as much after they asked for a sample of my work (which I had made available for that purpose), and they after that, they still wanted a three hour exercise done before I had even spoken to anyone.
In fact I am about to start a new job in the new year, I had a few interviews, and a couple of jobs that interested me sufficiently. One involved a three hour test, the other asked for a sample for my work.
Guess which one I took?
Guess which one the interviewer said they were struggling to find candidates?
A work sample test for a developer position might be: Here is the name of a niche board game. Over the next day, find the manual. Tomorrow, come in and play a round with me.
Half of what developers do is master arcane rules from obscure texts. Is this not, in fact, a work sample?
I completely agree. Talk to me about some good times and some bad times. Talk to me about hindsight and some of the crazy ideas you have bouncing around in your head.
I did the challenge and it was a fun endeavor. I'm mainly a C# dev. I dabble in AngularJS at work but don't consider myself a pro. I'd never tried drawing to the canvas so this seemed like a good challenge.
I managed to get something fairly workable, albeit ugly code-wise, banged out in 1hr. If you reviewed my google searches, you would see that:
- I didn't know how to init a 2d array in javascript
- I didn't know that the things on the canvas couldn't be accessed directly for click handlers
- I cheated on the solution for finding neighbors because I was running out of time
I've been giving interviews for almost a decade now and I've both tried and seen many different approaches. Yet, I think the MOST important part of the 45-60 minute time slot I get with a candidate (or future coworker), is the conversation.
1) I want to see passion for solving problems in the space. There are endless problems to solve in the industry, but I want to know they'll be excited to work on my team's problems.
2) What are they doing here? Was this a numbers game (interview at a ton of different places in hopes of getting one good offer)? Were they recruited or did they actively seek this position out?
I've seen candidates where in one interview I have to throw multiple problems at them, because they think about it for 30 seconds and then come up with a correct solution and quickly write it out on the board. I'll usually run out of questions for these candidates.
Ultimately, white-board coding works well for some, and is a complete disaster for others. Yet I don't believe it means white-board interviews should be thrown away in an effort to be "fair." I just think as engineers, if we really want to land a position at a Google, Facebook, or Uber, etc, is it too much to ask that we study up on our algorithms?
Do JavaScript experts consider JSBin a decent environment for this task? JavaScript is a bit verbose and I would resent simply the aspect of having to write a substantial amount of JavaScript without autocomplete.
I just played with JSBin and it doesn't have autocomplete out of the box.
Edit: whoa I just re-read the OP and found this
> Most [candidates] tend to use the laptop & JSBin provided
That's super hypocritical, OP (see your paragraph headed "Comfortable situation")! If you "provide" them with an environment of course most are going to use what you provide since that is what you are suggesting. So now you're filtering for people for whom that laptop model and the JSBin tool are familiar and comfortable.
Or in the case of those that reject your environment and choose their own familiar and comfortable laptop and editor, you are filtering for those with the self-confidence to reject the suggestion of the interviewer, which doesn't really help with your stated goal.
It's a shame because I like some of your other points :/
My personal, preferred way to interview data scientists (besides administering a work sample test) is to talk to them about the most challenging effort they've been a part of. Start with understanding the overall business context and the technical infrastructure they were working with, and gradually follow through until you understand the key ideas that underpin the innovation.
The key is to get them to explain things until you understand the essence at a foundational level - hopefully you understand what combination of the notions of statistical independence / power / dimensionality / algorithmic complexity has birthed novel system or algorithm they built.
The process selects for people who have a) already built something substantial, and b) have the communication skills to explain it.
Completely am on-board with the descriptions of false positive/negative
I agree that this seems like a good way to establish someone's technical competence. I do wonder though from the interviewee's side what the optimal time to spend on one person is. It's kind of like dating right? (Well what I imagine dating would be like if I lived in a big city) You have concurrent first impressions with maybe second and third follow ups before you seal the deal. This may be a bit like asking for a relationship on the first date.
Demonstrating ability in this manner works for more junior people who maybe don't have a github or other personal projects, but I'd consider discussing and reviewing those more valuable.
I somehow think that the interviewer should also be interviewed at the same time. If you have that kind of experience under your belt, one might definitely be interested in knowing if the person he/she would work under is really capable or not ? Working with/under someone lesser than you n same person is taking your interview, its kind of a insult to be honest.
> "Candidates are also reviewing a company. They'll be dedicating several years of their lives to this workplace and will be looking at the interview filter to see what it takes to get in."
Really? I barely know anyone who works for several years at any place. I'm looking at whether I can tolerate it for six months. That's only so I can take a job search break for a few months before hitting the grind again. I'd love to work at a place that's so great that I'd be there for several years but that's hard to imagine. Most companies I've interviewed with don't exist in 3 years, let alone 'several' (7+).
This is a very small niche that you live in. I can tell you that a candidate with 7+ 6 month engagements would be unlikely to get a position at my current company (mid-sized business intelligence consultancy), and simply wouldn't be considered at my last company (old school enterprise environment).
The startup scene is not representative of the job market for the majority of people.
>The startup scene is not representative of the job market for the majority of people.
On that note, I'm surprised that startups would hire frequent-short-stint employees. The startup I work at has a great proportion of people who have stuck around since the early days; yet I have worked (and interviewed) at large companies where everyone bails within a couple of years max. I don't know what the West Coast "scene" is like, so my company probably doesn't resemble SV startups, but the pay is great, the people are smart and passionate, and the businesses is hitting all of its goals, so I'm not complaining.
At the Beginning
Be warm ask them how they are
Listen
Be considerate ssk if it’s still a good time
Don't Be Too Familiar
Use Appropriate Language
Explain what is going to happen
I have 25 years of software development under my belt, I published a book, spoke at various conferences in Europe, have a Github profile (admittedly not very lively), worked for well-established enterprises and have great references. Why shall I still prove myself?
If I was a senior lawyer or an architect joining a new studio, I strongly doubt I would have to go through an interview to test if I can use the drawing table or if I know the body of laws of my countries. It is just ridiculous.
As I work as a freelance, my approach will be to offer 2 weeks of work on site for free. After the 2nd week, if they still think I'm good enough for the company, I will charge the 2 weeks, otherwise goodbye and no questions asked.