Show HN: Free, anonymous coding interview practice | Hacker News Reader

Show HN: Free, anonymous coding interview practice

interviewing.io

604 pointsleeny215 comments

Dear software professional: if you have been rejected because of a coding interview, don't feel bad or discouraged. It has little to do with how smart you are.

Unfortunately, this style of interviews is likely ineffective and leads to hiring people who look alike and have similar skills. Solving a problem with someone looking over your shoulder and forcing you to talk to explain what you are thinking is a skill that I've never seen used in the real world. I'm sure new grads spend a lot of time in classes training for this. Many great people don't function like this and still they may come up with brilliant ideas after a day or a week. Some people have breath of knowledge and study specific topics as needed. Some people can write very well and may not be super fast in tests. I know many brilliant engineers who have been rejected and are doing just fine, building amazing products, and leading teams.

If corporations really wanted a cookie cutter method to evaluate CS knowledge, then they should require a scientifically validated standardized test conducted by a third party. It would be cheaper than using engineers' time. So why don't they do that?

The reality is that they think they are doing more than that but there is no scientific proof that the interview method works. They don't want false positives but they cannot measure efficacy. If you are one of the guys who know how to perform, then you can get hired faster. In some cases if you are an outsider (older, female, different), then your chances of knowing the "secret interview code" is much lower.

"Solving a problem with someone looking over your shoulder and forcing you to talk to explain what you are thinking" is actually how problems are generally solved in most fields. Software engineering is perhaps one of the lone exceptions, and I think the pair programming movement has a bone or two to pick with your premise.

People are very diverse, some are fast and chatty, others are quiet and slow. Usually I perceive the fast and chatty types a bit arrogant. Personality and cultural background is probably an influence. Best teams have a great mix. Often caring about the work is more important than having a genius. (Of course people should be competent).

I do coding interviews exclusively since I find whiteboard interviews even more artificial. I try to match the interview to a persons skill set and ask them to implement things they should know or know how to look up if their resume isn't a lie. I don't care if they talk or not while doing the interview and I take the role of a product designer who doesn't know how to code. If they get interview anxiety I give them the space they need. If they want a keyboard & mouse I would give it to them.

What else can you do that would be an accurate simulation of their job that only takes 1hr?

I think that what you do makes sense if you take the time to read the resume, code samples, articles, and ask relevant questions. Asking to write some code is perfectly fine to see how the person works. References are also very important for more experienced candidates with a track record.

What else can you do that would be an accurate simulation of their job that only takes 1hr?

First 1/2 hour: Discuss their code samples in detail -- asking pertinent questions about each as to what they do, and why they did things they way they did. Drill down for detail, ask how they might have done things differently for different use cases, etc.

Second 1/2 hour: Bring out some of your own production code and do the same (allowing them space to ask questions this time). Works best if you let them see something that's a bit "raw", i.e. quick and dirty, which you know you could have done a lot better if you had more time or knew better about the requirements (or perhaps you're simply older and wiser now).

In both sessions, nuance (both in what they can observe, and how they chose to express themselves) is key. And it'll come out a lot more freely than in in a whiteboard interrogation precisely because they interaction will be natural, uncontrived and unforced.

Simple, non-confrontational and 100% reflective of what engineering work is like. That's what we do during the day, 99% of the time -- digging up (sometimes woefully) less-than-perfect components of production systems, and trying to make them a little bit better.

But as to how often we drag someone to a conference room, throw them at a smudgey whiteboard with creaky pens and no eraser, and force them to solve some abstract problems while we boredly look at our watch, and interrupt them with hints?

Basically never. Except, that is, in coding interviews.

Another aspect of the funhouse of one-way mirrors that is the modern conventional tech interview process:

Candidate is fast and chatty: "I don't know. He seems smart, but he was also talking a lot of fluff. Kind of pretentious and arrogant."

Candidate is slow and hesitant (and perhaps pauses awkwardly now and then): "I don't know. He seems smart, but he seems a bit underconfident. We need someone with more energy."

See, we're having trouble even testing for competency. I passed a pen and paper interview recently (did confidently well on coding, blew the SQL part because I had only used APIs and still thought I should put that on the resume) and still got the position. I'm still scared shitless that I'm going to flub day 1 and I've been cramming and exercising basic knowledge for the past two weeks. I'm worried that the test was just a screen and the real requirements are hidden.

On the other hand, everyone's favorite anecdote: "senior engineers" not passing basic tests like mine.

I still don't feel qualified for entry level (and other peoples' interview experiences don't help!) and that's because entry level and other competency levels are subjective right now. What knowledge should you know from memory? What knowledge are you safe delegating to Google to remember? However, my feelings about my skill could just be nerves.

Lines in the sand would really help the self taught crowd and could be used to bring outdated, lagging CS programs and their graduates, up to speed.

Different people are going to have a different answer to your question, but here's how I approach things:

You should commit things to memory the things your memory naturally keeps. If it doesn't it means you aren't using it often enough to bother remembering it. There's so much information I used to keep re-learning and forgetting because I never used it. I finally realized that it was a waste of time.

I guess the problem is when the job you're interviewing for will need vastly (or slightly) different things committed to memory than what your current job does.

I also like something between google and memory: cheatsheets. I have a dev notebook full of checklists and cheatsheets for various technologies I've used and tasks I've done.

Everything you've said is exactly what I do, and it works brilliantly for me, despite being self-taught :)

As a self-taught developer, I have reached the same conclusion regarding memorization. I find your concept of 'cheatsheets' inspiring, and would love to know more about how you organize that kind of information.

I used to just use text files. Now I stick everything in Evernote. Text files are good enough though.

Organization is pretty simple. Just need a decently named file with the relevant information. E.g. I would have an sql.txt file containing sql database operations that I don't use often enough to remember, but use often enough to be annoyed by having to search the web on how to do them.

Another example might be a centos5.txt file, giving me a quick rundown of the various setup options I've wanted in the past, and the location of various configuration files.

For programming languages, there's many that I use maybe once every 3 or 4 months. So ruby.txt might contain a quick rundown of how to do basic things: how to define a function, a class, perform loops, instantiate an object, access command line arguments, etc. I find it much better than having to hunt down a tutorial which will also be more wordy than needed.

I also have some for more computer science related things, such as tables of graph and search algorithms, along with their tradeoffs.

Checklists are another good thing. I have checklists for processes I've messed up.

E.g. committing new code. If I don't use my checklist, I always seem forget to forget to update a sample file. Or add a file.

Another big checklist is for giving estimates. For example, one of our legacy products is translated into 5 languages. This checklist reminds me to think of translations, because they have been a huge bottleneck in the past.

Hope that helps some.

There's a big difference between someone looking over your shoulder and forcing you to explain what you're thinking, and someone working with you to collaboratively solve problems. In the latter case, you can ask lots of questions and throw out lots of dumb half-baked ideas, and actually get a meaningful, useful response from your partner/pair in response. If you're whiteboard interviewing, good luck getting your interviewer to meaningfully engage with you, since they don't want to "give away the answer".

The best interviews I've had were legitimate pairing interviews, where the two of us were tasked with solving a problem in a real codebase that the interviewer hadn't solved before.

(The best best interviews made it an issue in an open source project, so it can be a not-canned interview without you writing potentially production-ready code for a for-profit company without being paid)

THIS right here is the dream interviewing scenario and in my opinion the singularly best way to test a candidates competence, aptitude and personality. Solving problems together exercises all of these key things in harmony.

There's also the fact that some people, like me, freeze up in these interview scenarios. I didn't get past my first interview a few weeks ago because I couldn't think straight knowing I was being judged going through this process. As soon as the interview was over and I was more relaxed, I thought of several good answers, like I normally do when employed.

The analogy I use is a coding interview is like asking a musician to play a specific song; chances are, a classically trained pianist won't know the chords to a specific pop song, but that isn't any indication of their skill as a musician.

The interviews I had with the company I work for now were amazing; they asked me some basic questions to verify my resume wasn't completely BS, then asked me to discuss previous projects I'd worked on, asking questions about technical details on the way. ("Why did you use collection type X in stead of collection type Y?") This allowed them to learn about my real world experience without the risk of asking me about one specific type of problem I may not be familiar with.

Better analogy is that classical musician is given sheet music to pop song and is told to play it on his favorite instrument. If he is good musician, he should be able to play it reasonably well even without practicing. There are musician who play extremely well but only after practicing one song for a long time - this type of interview sucks for them but they are minority. Most musicians suck with or without practicing so this type of interview is a good filter. Not ideal but no one came up with better one that scales up to thousands of applicants.

Agreed; the idea of hiring a musician without hearing them play would be madness. Not handing me a recording, not discussing intricacies of music theory, but actually playing live. And yet, a talented studio musician may suffer from performance anxiety in this situation. What to do?

I think the best thing is to ask them to warm up with something basic like a scale, and let them work their way up as their comfort level increases. I knew some people who were particularly pleasant and easy going, so they were able to relax people suffering from performance anxiety.

There are interviewers who treat coding interviews as a high pressure, adversarial exercise, though. On the other hand, those sorts of people are rarely a joy to work with.

Performing a piece of music in a high-pressure situation is exactly a professional musician's job, so an audition is quite appropriate. Another analogy could be to ask a professional composer to play one of his pieces on piano rather than listening to a competent orchestra perform it--you're using one thing as a proxy for another. Many composers would ace it--they're great players. Some aren't, though, so you'll hire only composers who happen to be great performers. It's a dumb analogy in another way, though: you only need to know whether you can work with a composer, their work should stand on its own. I suppose if we engineering types all wrote code that went into public repositories the same might be true of us, and we wouldn't be asked to perform like trained monkeys.

In an audition, musicians are usually asked to play a mix of prepared and sight-read pieces (though sometimes the sight reading is from standard repertoire, so they may have encountered before). Both are helpful in discerning how qualified the musician is. And sight-reading is incredibly important for most jobs musicians get hired for - in most freelance situations, they'd get a 3 hour rehearsal, or essentially a guided run through of the performance, then they play the gig. So that may not be an accurate analogy, given that writing on the fly isn't part of the programming repertoire - most programmers are allowed to think before they write anything down. Also musician's don't write - performing is very different than writing- so perhaps a composer would be a better analogy.

Maybe it would be a more accurate measure of ability to ask software engineering applicants to read code and explain what it does, or to judge them as you'd judge a composer, by their portfolio.

That would be an interesting way to apply something like re-captcha: ask them to fix two bugs in open source applications. One bug that you've actually already fixed, so you know how hard it should be and can calibrate; the second bug is open.

How about just asking them to code something - anything - in say, a couple of hours?

Not all codes are created equal.

To make this useful for an interview, you have to set it up so that people can't submit things they've coded up before in a much larger timeslot.

In a lot of cases, it's like a classical musician being asked to make a violin.

I recently was flown to Austin for an interview. The entire reason I was brought down was because of Python ML projects on Github. The technical interview consisted of nothing, and I mean NOTHING but super advanced SQL questions. (over the phone, I had specifically stated I hadn't used SQL in years) My expectation was that I'd be interviewed using Python and asked to perform ML related tasks.

When I mentioned that I thought that the purpose of me being brought there was to add an ML dimension to the team, which was far too data analysis (using SQL and some R)focused and with no Python expertise, I was given a blank stare.

Then it hit me: the guys interviewing me didn't know how to do any of the stuff I had been brought down (by higher ups who weren't in the room) to do, so they weren't evaluating me on it. They evaluated me on what THEY knew. It's the equivalent of Peyton Manning being asked to evaluate a linebacker, and demanding that the linebacker throw passes downfield.

The highlight was when one of the guys (typical pony-tail neck-beard type) pointed out that an alluvial flow diagram in my portfolio of data visualization projects wasn't "Tufte-esque". (It was a gross misinterpretation of Edward Tufte's commandments on his part, but am I really going to get in an argument with the guy interviewing me?)

It was clear that the guys in the room wanted someone who knew what they did and thought like they did. A brilliant recipe for getting a homogenous team with no diversity in skills.

What an epic fucking waste of time. The best part? The company only has 150 employees, and a recruiter just contacted me for a position on another team that uses Python. She was unaware of the fact that I was there a month ago. I told her that they should have thought about that when they flew me down the first fucking time.

Maybe if I am in a similar position, I should demand compensation for my time. That way I'll at least get to visit friends and see scenery around Austin. I wonder if a demand for compensation (besides airfare and stuff) would fly...

I usually just stay longer on my own dime. The company doesn't care whether they pay for flying you back immediately or two weeks later.

It would not. The only thing I could imagine countering is: Fly me to Austin for two weeks, put me up in a hotel, and hire me to do a project at $x/hr. If we both like what we see, let's talk about a full-time position.

Frankly, I think this is anti-candidate behavior if the employer suggests it, but if you actually want it, they should be willing to do it if they can vet you otherwise (github, etc).

> I told her that they should have thought about that when they flew me down the first fucking time.

Thanks for that!

On the other hand, most likely the other Python team would grind you on Python and again nothing on ML, and of course your Python ML projects suck because "blah blah blah"

Ugh, what a wasteful mess. The worst part could be my lack of surprise in reading your anecdote.

>forcing you to talk to explain what you are thinking is a skill that I've never seen used in the real world

You've never once explained your thought process to a coworker? Explained how you arrived at a conclusion? Tried to elucidate your reasoning on a piece of code to someone?

These are absolutely real world skills and they are absolutely applicable when working on an engineering team with other humans. I understand what you're getting at in your comment, but it really feels like you're throwing out the baby with the bathwater. Can interviews be improved? Absolutely. Does that mean that there is no value in these kinds of interviews? I certainly seem to glean some value out of them. Whether that is the right value is a hard question to answer.

But I want to address something. Your whole comment is about why these kinds of interviews are shit. But you offer no alternative methods, no ways to improve these kinds of interviews, and really no constructiveness. You seem so sure that interviewing this way is wrong, but you don't say what's right. I would love to hear some realistic ways to interview people that can help me find better candidates without rejecting people because they're bad under pressure.

Explaining your thought process to a coworker after you've written the code is ex post facto rationalization -- you are invariably leaving out many side-tracks, many missteps, and get to condense down a long process into a simple, seemingly obvious explanation. You already see the route, and now you're just describing it.

Trying to do the same while you're trying to solve the problem, with a judgmental crowd scoring your comments, however, is an absolutely and completely different matter. Even thinking about how I would narrate my thought process as writing this reply ("maybe I'll talk about how I'd narrate the writing of this reply") is confusing enough.

I don't disagree with the concept of technical interviews, especially given that there are countless people who hold none of the skills they claim they have mastered. A process I implemented requires developers to come in for a coding test, where they are equipped with a development machine with full internet connectivity and a full toolset, and given a problem within their skillset to solve, alone in a closed office and for as much times they need. After the test we do talk through their "thought process" and their implementation choices.

I know this offends some people, among whom I'm sure are the people who completely failed to demonstrate even a basic knowledge of skills they claimed an expert level of competency at.

As someone who is very annoyed about interview process in general, I'm not sure what you think offends some people about giving them a realistic environment and time to work. What is annoying is when a false equivalence is drawn between stress and difficulty on some ad hoc interviewing task and "even a basic knowledge of skills".

I'm speaking more to the viciously anti-technical-interview sentiment that is so commonly seen on technology sites. While there are a lot of shops that do the whole process in a ridiculous fashion, similarly there are a lot of frauds among us: we have experienced such a number of people who claimed skills that they didn't begin to have, even when warned well in advance that they were going to be tested, told how they would be tested, and given a full ability to leverage the internet. Whenever those interviews ended, awkwardly, I always imagine them heading to Reddit or wherever to tell everyone how technical interviews are so much bullshit, and can't people just hire them on their resume, etc.

The problem with these questions is the time scale in which they expect the answers. When dealing with a difficult problem, most people don't immediately come up with the right answer and adding in the pressures of an interview only makes it worse. As a development manager, I always ensure that my direct reports know all about the issues they're going to be working on at least one week in advance. I've found that the solutions they come up with are markedly better when they've had a full week of thinking time prior to writing any code.

The alternative interview technique that I like to use when hiring engineers is to send them the questions I'm going to ask a few days before the interview. I ask difficult questions, but there's no surprise. I don't really care if they talk about them with other engineers beforehand...there will always be follow-up questions that I ask to get them to defend their solution that will uncover those that haven't understood the problem fully.

Being a person requires time to clearly think about a problem and gather thoughts I couldn't up-vote this enough. I just can't solve a problem when I know that someone is evaluating me right there and then. The way I go about it is to keep thinking about it at the back of my mind while I commute, eat, sleep etc., and then once in a while write pseudo-code or gather data to verify if a solution I'm pursuing works.

I was asked to come up with a recursive-like solution for puzzle like problem. I just froze during the interview. Later on kept thinking about it for couple of days and sure enough I was able to come up with three different solutions that used various techniques such as memoization and I felt really good about it.

I guess what I'm trying to say is it's really counterproductive to evaluate someone's abilities by subjecting them to time pressure.

I really love the arguments in the category "You criticize 'X' but you offer no real alternative, solution, etc..." as if you can only criticize something if you have the alternative solution at hand. This is not one of those questions with an easy answer.

"Boy you sure criticize those Nazis a lot for genocide, but you offer no _real_ solution." "Dude... stop criticizing those banks for their greediness when you have no solution". I realize these are rather hyperbolic examples, but you see where I'm getting at.

As for the OP, this does seems like really cool stuff, even if I don't really agree with "the interview" method myself because I don't do too well at them. I mean sure, there should be some on the spot questions to get sort of an outlook feel on the candidate, but that really isn't sufficient.

Why not give the the candidate a real world problem - maybe even related to something your company is trying to solve - and a few days to come up with a solution. I don't care if they also do some copy/paste from SO and other sources on the internet. That's why the interwebz is there in the first place. What would be more important in my view, is how the candidate is able to integrate all the information he finds - be it on the internet, books or his own head - and converge to a solution. And even if he doesn't come up with a working solution, you as an interviewer can now infer a lot more useful pieces of information than with a basic interview. You can ask questions like: 'why did you choose that library over the other ones?', 'why that programming language over the others', 'how did you come across the code on Stack Overflow; is it correct?', 'why that database and not that other one?', 'why is your solution single threaded and event based, rather than multi-threaded?', 'how would you further optimize that piece of code?' and so on.

I think this kind of conversation is something much more likely to happen day to day between the candidate and his coworkers if he does get the job.

"Solving a problem with someone looking over your shoulder and forcing you to talk to explain what you are thinking is a skill that I've never seen used in the real world."

I'm often in the position to have to explain my reasoning while developing software. Code reviews and pair-programming come to mind. It's about being able to communicate complexity and being more rigorous about the software development process.

That said, this style of coding interview brings up a level of stress that I'm rarely under at work. It's an unfortunate condition of interviewing, but I don't think it's completely avoidable no matter how comfortable you make the interviewee.

The point of these type of interview questions is to see how well you can reason and communicate. It is not to see if you know how to solve that specific problem, and if an interviewer is using it like that then they are not a very good interviewer. A standardized test does not substitute for actually talking to someone while they solve a problem and seeing that they can think logically and communicate those thoughts.

It is more about the communication aspect of the question, not about getting to the answer. Because communication is a lot more important in business...even tech business...than you seem to think it is.

Right. While I wasn't interviewing for a technical position, the interviewer asked me to 'vote off' one of the 50 U.S. states, and to describe my reasoning why (perhaps this is a common question but I hadn't encountered it before). It was basically an exercise in thinking out loud, with a lot of "well, I'd probably want to first consider x, but actually before doing that I'd want to take into account y...". There wasn't any undue pressure, since there was clearly no right answer, so it allowed me to just riff out loud on the problem, exposing to the interviewer how I approach problems.

I use this same technique now when interviewing others.

The answer is florida, right?

Idaho.

Of course it's total bullshit. You still have to pass it. You can't demand that everyone else be at least as wise as you, especially since you could well still be wrong.

They don't want to do this because the secret to making money in IT is creating a glut in the supply of labor for IT workers. When you add licensing (i.e. requiring a license as a doctor or a lawyer does), this creates a barrier to entry, which will cause an upward pressure on wages for IT workers.

Good point. Perhaps we need to work through professional organization to look into hiring practices and propose practical solutions.

I'm absolutely one of these people who melt down. Give me a task and leave the room and I'm on it, but while being watched I loose all ability to think, which I think has a lot to do with the fact that I never went to college and jumped right into the industry directly after high school essentially bypassing a very important skill you learn there: test taking.

Two weeks ago the position of my dreams -- literally, exactly what I wanted to do, and at a totally rad and well-regarded company -- vanished during my second interview after (what I believe) was a killer and detailed coding challenge submission (which we discussed at length) and an excellent first interview.

Why?

Function.apply -- LOL

"Describe event delegation" -- LOL

Stuff you learn during DAY ONE of JavaScript coding (I've been programming for over ten years in a number of languages, and have built many, many large-scale applications). It was absolutely humiliating, and I'm still recovering from it in the worst of ways. My brain just froze up completely.

Thanks for putting the site up because I'm sure there are many people that will benefit. I've got an interview at Amazon at 3pm and those are notoriously difficult; wish it were already live and running! I'm not looking forward to it.

Not to be a downer, but Amazon isn't that great of a company to work for in the grand scheme of tech companies. Very few perks for engineers and penny pinching on workstations, monitors, etc. It really starts to wear on you after a while and you feel like nothing more than a 'necessary cost'.

I most definitely do not want to work at amazon :) This is a contract position till I find something that is right.

Dude, if you're that passionate about that job you just described then I'd suggest calling the company up and explaining what happened. Having interviewed many people I'd certainly be open to giving someone a second chance if they explained a situation like yours to me.

After the second interview I had an entire email written out that I was going to send to their lead, but honestly, given that the app that they asked me to develop prior to the interview was well done, detailed, commented and modern, complete with a PR flow that me and one of their devs went through via GitHub, I felt that if they were willing to pass due to me obviously locking up on a Skype + Google-Doc shared whiteboard, and on the most basic of JavaScript skills (which were clearly elaborated upon within the project), then it wasn't the right fit anyways.

"I felt that if they were willing to pass due to me obviously locking up on a Skype + Google-Doc shared whiteboard, and on the most basic of JavaScript skills (which were clearly elaborated upon within the project)"

Or it could be a simple miscommunication, or they thought somebody else done the app given your performance on the interview. Reaching out and asking will cost you little compared to potential windfall.

Exactly. I mean, it would take a fairly skeptical person to think that you submitted someone else's code but maybe they just weren't willing to take the risk.

Either way, I think you've nothing to lose by sending that mail/picking up the phone. Regardless of the doubts the interviewer may have in you post-interview they'll know that everybody is prone to a bad day every once in a while.

For those interviewers and candidates looking for a better solution than the "google doc shared whiteboard" - I suggest checking out a product I make: https://coderpad.io/

You can think of it as a much higher fidelity Stypi, Etherpad, Collabedit, etc, except that you can run the code in the browser as you write it. It really helps alleviate the choking sensation of being asked to write out an entire problem on a whiteboard without any of the modern affordances we've come to know and love.

Yeah, this actually did seem to lead to some confusion, which was the first bad sign. Google Docs obviously doesn't know how to format code, and the indentation was getting messy during the typing process leading me to have to break, think, fix indentation, resume thought, then answer to the questioner about my "preference for three spaces or two"... ? It was an obscene process that could have definitely been refined by your app and possibly led to a better outcome.

You wrote that? I love that site! I actually saw it for the first time last week when a company I was interviewing with used it as part of the interview process.

I loved how smooth and fluid it made the whole process, that they could switch between languages during the interview and the rewind functionality.

I blew a technical phone screen with Zynga and not only did the interviewer not respond to any of my follow ups, the in house recruiter actually blocked my calls. Radio silence seems to be fairly standard after deciding to reject a candidate.

It's also Zynga, though. They've gotten flak before for not being the most considerate toward their employees. Maybe that attitude extends to candidates as well?

Pretty much the same thing happened to me a year ago, I was at an onsite interview, did really well 4 out of the 5 rounds, but 1 round I just completely choked some basic linked list question and looked like an idiot.

I find code interviewing so nerve-wracking that I'm delaying my transition from another profession into a much-desired full-time programming job. I'm 40 and always aced interviews before I did my first coding interview last year. In my prior career, I literally never had an interview that failed to result in an offer.

But I blew my first coding interview both in the interview itself -- in which I repeatedly blanked out and froze -- and in my failure to show the company my best work (they asked what I was hacking on and so I showed them a half-assed blog engine I was rolling using the remnants of another project when I should have shown my more polished work.).

This interview was so bad that I cannot yet bring myself to try it again, despite spending lots of time polishing up on algorithms and data structures. Up to now, I had never experienced performance anxiety of any type -- I did very well on interviews and standardized tests like the GRE. Yet now I'm petrified of programming interviews.

By local standards, I'm a pretty good programmer (by HN standards I'm probably average). And what I lack in knowledge I made up for with enthusiasm and persistence. I've got a bunch of code of varying quality on Github, including small contributions to several very large open source projects and a moderately popular open source project that I created and maintain myself.

I'm also limited by the fact that due to my family situation, I can only consider remote jobs at the moment. But by far my main hurdle is this fear of programming interviews.

I'll definitely be taking a look at this. Maybe this will help be break through my mental block.

I'm right there with you. 39 years old and I've been doing Linux systems administration and writing code since college in the mid 90s. Aced every interview I ever went to up until a couple of years ago. These Google-style coding interviews for systems/operations roles are the death of me and it's a shame. I have deep systems experience and I spend a lot of my spare time coding in Go [1] but I have little formal CS education and my full-time gig does not involve writing code all day, errrr' day. It's so frustrating, these interviews. You want to tell them, "Look, hire me and I will make your infrastructure scaling issues disappear and I'll save you money doing it" but that never happens because they see me get hung up on a sorting algorithm and immediately lose interest.

I'm not looking for a new gig but I'll give their site a shot when I am.

[1] https://github.com/chrissnell?tab=repositories

Pragmatically, why don't you spend a couple dozen hours drilling typically interview questions? It's easy enough to learn enough about, say, sorting in a few hours to pass most interview questions about it.

Don't feel bad that you blew your first interview. Unfortunately, software interviewing skills are orthogonal to software development skills, and the only time most people get experience with interviews is during the actual interviews (no pressure or anything! :).

As such, you should fully expect to completely blow your first 1/2 dozen interviews (this includes your first 1/2 dozen when changing jobs after a couple of years). Go in with the expectation that you are going to fail. That doesn't mean you shouldn't try, just that you expect to walk out with nothing more than an hour or five behind you. You'll find a couple things happen: first, the pressure to perform will be reduced, so you'll be more comfortable and confident answering questions; second, you'll be able to better analyze where you might have gone wrong on any given interview to perform better next time.

No matter how badly you failed that first interview, you are better off now for having done it and failed than not doing it at all. The same will be true for each future interview until you land that job you want.

I have to disagree with "orthogonal". That means that there is no relation whatsoever between dev skills and interviewing skills. This just can't be true. To set the bar really low - someone who has never programmed before will never pass a code screen, while someone who has clearly has a greater than 0 chance of passing. This doesn't show much correlation, but there's clearly _some_.

If you want to be pedantic, sure, there is some small amount of correlation there. But in the real world, I've seen people pass coding interviews who were incapable of writing software and I've seen people fail coding interviews who I knew could code circles around the interviewers. But, as usual on a site like this, being a pedant is an absolute must.

I did not intend to be pedantic at all. The difference between little correlation and none is small on a number line but very large in meaning. If there was no correlation whatsoever, that would imply that pretty much every software company is behaving irrationally by wasting their time interviewing people - that is, simply hiring at random would be better. This obviously isn't the case.

Seriously: thanks for sharing. It really takes a lot of courage to post such an honest self-examination like that (even anonymously).

Thank you so much for sharing this. Look at it this way, many companies are missing great talent because of their interviewing practices and for trying to imitate Google or Microsoft. More innovative companies (think Moneyball) can take advantage of this pool of talent and target people like you. I'm trying to think how to make it easier to identify this talent. Any ideas?

I personally think there's a simple answer. Give the candidate the technical questions as a take-home exercise and let them have X number of days to finish it. Probably best to have a relatively simple exercise and give them only 1 day.

Sure, some, if not most, of the candidates will use Google, Stack Overflow, their old college textbooks, or whatever will help. But they're going to do that on the job too, like most of us do. The key would be to get them to explain, in detail, how they solved the problem and why they choose their particular solution, going line by line in the code if needed.

I think this is perfect because it doesn't put the candidate on the spot. The shyest person should be able to work on their own, and I've never met a programmer so introverted that they couldn't explain the work they've already completed. The people who just faked the exercise by copy-pasting should be readily apparent once the detailed questions about their code arise.

This is probably an overly simplistic answer but I think it would make a huge difference. In the job description, make it clear this will be your interviewing style and you'll attract quite a few of the shy-but-qualified people who would probably skip Google or any of the other high-pressure interviewing companies.

It can be all that you described. Very humbling.

My strategy was to start interviewing a lot. Don't go to your "first pick" companies first. Just go to any that look at all interesting as practice. That will take quite a bit of pressure off too. Over the course of 2 or 3 weeks I did phone screens at 20 or so companies and progressed to a code interview on most of those and then about 6 in person interviews which led to 2 offers. I never did get around to trying for my first pick companies because they are famous for dragging their feet and I was currently unemployed.

I would like to know how you got 20 phone screens in 3 weeks. :)

I've just got a new job after around 15 interviews[1], the technical bit I can do, the softer bits (people skills etc) are something that I need to practice and it takes a few interviews.

However I did put quite a bit of effort in revising my basic coding stuff before I hit the interview trail and in general I don't apply to places I really want to work at until after I've managed to get a few trial runs under my belt.

I wouldn't sweat the freezing I've done the same thing when someone asked me a question about stuff that's on my CV but no other interviewer had bothered to ask about. It should get better.

[1] some failed at phone interview, others at face to face

Here's some stuff to get you started, hope it helps: https://github.com/andreis/interview

this is awesome.

Whoa, thank you!

This looks great.

These days I skip all interviews which require me to code in the interview. I have plenty of open source code, if they cannot figure how good I am looking at, then they definitely cannot figure how good I am with a 3 hour coding interview.

IMO, coding interviews is like public speaking. Many people get nervous in front of a crowd. It's a skill one has to obtain should it be required. Coding interviews are quite irrelevant for a programmer/developer position.

Exactly my thinking as well.

Dig in, look around, its obvious what I can do, and what I'm capable of learning.

Ask me to code a sample app and comment every function with detailed explanations of my thought process.

Add me as a collaborator to GitHub and request that I make some pull requests on your product.

Live coding interviews are more irrelevant than irrelevant and completely ignore the fact that many people -- and especially introverted technical types -- just don't do well in front of groups.

Coding interviews don't ignore any facts - they are simply often the best signal/time tool available. Many people do not have time to root around in your personal repositories or wait for you to commit pull requests. They have a pipeline of people they need to screen, and you can't wait on everyone in a pool of candidates to take their sweet time before deciding on a winner.

Technical screens are synchronous and relatively well understood. If they are not the literally BEST choice of time for figuring out if someone is a good developer, they are at least a very defensible choice.

Your comment is unfortunate but true. Hopefully one day someone will think up a better way to do things.

Maybe doing well in front of groups is a skill that companies want in their employees.

...which has nothing to do with high-pressure interviews with people you've never met.

For me, even worse than an in person interview is a remote coding interview over the phone. Usually some sort of screen sharing + phone call.

I find it incredibly nerve wracking because it gives me that feeling of someone standing over my shoulder without me being able to fully interact with them or read their body language. When you sit down to hammer out a solution you have all the additional pressure of trying to stay engaged with someone you can't see. As a result I constantly drop my focus on the problem and lose what I've worked out in my head.

Worse, you simply have no way of knowing what their evaluation criteria are.

Maybe they want you to be slow and thorough (I've been nailed for not checking the exit status of print statements). OR maybe they want it quick and dirty, in which case you'll get nailed for "overengineering", or you just wont have time to do it the imaginary time frames they set for these tasks, if you go for any of the defensive practices that the other guy would have nailed you for. Fun, fun, fun.

1. Tell people what you want.

2. Actually evaluate them on that.

Anything else is a psychology test, and you aren't psychologists.

Very much yes. In an interview I was prompted to write some code that ran as quickly as possible. 10 minutes in they were concerned that I hadn't started with a naive proof-of-concept solution and improved from there. I don't disagree with their idea of good programming practice, but how could I know they wouldn't penalize me for coming up with a slow naive solution, when the prompt specifically said to run as quickly as possible?

And you have the ever fun "I'm not worried about whether it compiles", followed up with endless "you forgot a semi-colon", "you didn't declare that variable", and so on.

With someone else staring at the screen seeing every letter as I type it there have been cases where I become paralyzed and my mind goes blank on problems that I could have easily solved on my own (without resorting to Stack Overflow, of course).

It's a combination of nerves and needing to suppress a part of my natural coding process that occasionally involves a brief frenzy of guess-and-checking and pattern recognition to get my bearings on possible solutions. That part of the process is unconscious and intuitive, kind of like how athletes don't think about what they are doing. If I slow down to consciously relay those early steps of the process it breaks the spell/flow and I go blank.

I think the problem is that I have a habit of letting rapid ad-hoc intuition guide my coding, rather than being a rational agent following a pre-planned 'waterfall'. In-the-moment intuition somehow (surprisingly) produces nicely workable and even readable code much of the time, but also entails some amnesia about the steps I took along the way. I occasionally have doubts - am I built to be an engineer? By nature I am a very logical person, why can't I always conceive of a whole answer (or at least a clear direction) before "putting pen to paper"? Working memory deficiency? ADHD? Lack of practice? However, my doubts about programming potential are quelled when my friends and I look at the code I can write and the problems I have solved.

Practice makes perfect as they say. I really look forward to using this service.

>I have plenty of open source code, if they cannot figure how good I am looking at...

I've interviewed several people with lots of code on github and what looks like lots of accepted pull requests to many projects who still can't seem to reason through a problem described as "write a function that takes two unsorted lists and returns one sorted list".

I think I'll continue asking technical/coding questions...

This satisfies your problem description:

   def function(unsorted1, unsorted2):
       return [1, 2, 3]

;-)

indeed! Yet, in the interview I'm thinking of, he didn't even get this far.

poorly specified questions are very important to ask IMHO :)

I would say this is actually a very important part of interviewing. When given vague requirements, see how they respond. Building something that is technically correct isn't as good as building what you actually want.

I'm curious what language was he using?

Probably Python.

Yikes.

That is awesome. I like; "That problem has been solved so I'd Google it". Your answer is faster.

In elementary school when you were learning to do algebra did you say, "that problem has been solved id google it?" To learn you have to do the basics before you can do the advanced stuff.

-In elementary school when you were learning to do algebra did you say...

Chill, he said 'so'. i think he was just saying he looked up the answer but that persons answer was faster

Thanks autokad. base698 has the right interpretation: My response was the smarmy answer I have given in interview situations where I just felt rebellious against the energy of interviewer combined with the test questions. I actually agree with base698. An understanding of the basics is required. And the companies I've coded for - for long periods of time, and loved working at - figured out I knew the basics based on our conversations alone. I hire people without testing. It has not backfired yet. I have also tested others in the past, had people pass the test, only come on board to be dangerous to production environments.

I'd give the candidate some minutes to Google the problem, but then I'd want a solution and a good explanation. (Explaining other people's code is hard, too.)

If someone asks me to code/problem solve in an interview these days, I don't even bother to try, I just pretend to try and answer the question to see their reaction, because by that point I've already lost interest in the position. It's the equivalent of a shit-test, so I like to turn the tables around and see how they react instead.

I do this for many reasons, one of which, is they obviously weren't interested enough in my talents to throughly research me before the interview to assess my skill-set, which means, they weren't that interested in hiring me to begin with. I don't want to work for someone who is just slamming through interviews for talent; I'll bow out. I want to work for someone who is specifically interested in working with me and understands my skill-set before hand. The second reason, I don't deal with these questions is that I don't like to be put on the spot without my normal working environment, I feel at a disadvantage and uncomfortable. Keep in mind most developers are introverts.

I consider a good interview to be about people; not technicals, which can be referenced/refered or looked up; they should provide a medium to see if the employee is a comfortable fit. If goals and motives align. To talk history and such.

I do not think your attitude or position are indicative of the majority of developers. They also require a huge time investment up front by the interviewer. Even if your individual Github profile (or whatever) is organized, comprehensible, and relevant, it doesn't say anything about the vast majority of developers whose profiles are largely scattered, obtuse, and frankly not even representative of their own work.

If you are a recognized leader in a particular field your situation is obviously different, but you can't expect me as a interviewer looking for a web developer making a mostly standard CRUD app to have the time to delve into your personal history and divine your technical expertise without asking you about it.

if you want to work for one of the large major companies, thats not an option from what I have seen.

i do agree though interviews should be more focused on soft skills and not technical, even for technical jobs.

Oddly enough, people lie, unknown references can be bullshit.

The cost of hiring someone who is incompetent is high. High enough that companies generally make several attempts at finding and filtering people that might be incompetent. I don't think anyone who interviews programmers actually believes the standard technical interview process is fun or necessarily even accurate, but there's nothing else as low cost to implement that works better.

Further, someone who treated a technical problem in an engineering interview as a "shit test" would be walked out at any company I've interviewed for... Good luck with that!

list2.each {list1 << it} list1.sort()

Better:

merge_sorted(list1.sort(), list2.sort())

  > people with lots of code on github and what looks like
  > lots of accepted pull requests to many projects who still
  > can't seem to reason

How does that happen? Do you think they were lying about their github identities?

I can't really explain it. It was a puzzle to all of the interviewers.

The only reasonable hypothesis I have where I assume the candidate was honest is that the quality of the code in his github profile is largely due to help from others.

The only reason I can do well in one of these interviews is because I recently started writing poor patch code for websites.

In development, who would do design, code and review on only one change in a straight sequence? It is like asking half your brain to shut down and the gods to smite you.

Or that they are bad with on-the-spot-questions-with-short-time-limit-while-every-move-under-scrutiny-by-potential-employer situations ... Which usually only ever happen in interviews.

I wonder if those people you're talking about just froze in the interview process, like others in this thread have mentioned doing?

Presumably it's possible to distinguish people who interview badly from people who lie on their résumé. The question is "How?" Followed by "How many interviewers know how to do this?"

The interviewers in these loops are generally quite introverted themselves, I know I certainly am. I believe we are sensitive to people who are the same and cut them slack.

My goal when interviewing someone is to determine if they will, on net, add more lift or more drag. If someone is so nervous that they can't communicate, they (sadly) will almost certainly not be able to demonstrate this.

Luckily, there are personal referrals. A strong engineer who interviews very poorly but has good first hand references will be given MUCH more slack.

What is the correct answer to this? Let's try a little experiment.. I've never heard this question before, so I'm in the same boat as a naive interviewer right now. Let me elaborate my thought process.

"H'm, this looks a bit like mergesort, where you take two sorted sublists and form a bigger sorted list. So...sort the sublists using mergesort, then call the merging algorithm? (compare the heads of the two lists, and form the bigger list)"

This would be the answer I'd start giving. Tell me if it corresponds even remotely with what your idea of a correct answer is, or what points would you deduct from if it is incorrect. Off the top of my head, I'm not sure I'd be able to write the exact python code for this that covers all edge cases in less than 15 minutes.

We try very hard to NOT ask questions that have only one correct answer, and my team only interviews/hires senior people. So my approach to interviewing might be different than someone who's interviewing a fresh grad.

I treat all questions as conversational. The direction the question goes depends on where I (or other prior interviewers) think more evidence is needed.

For example: merge sort is an answer that satisfies the conditions of the problem. Given that, I would decide if I need more evidence about your ability to code, if so I'd ask you to implement merge sort; I might want more evidence on how you explain things, so I would pretend that I didn't know what merge sort was and ask you to give me a description of it.

The merge stage of merge sort will only work if the input lists are already sorted. In this case they are unsorted.

I'd ignore the fact that there were initially 2 lists and just concatinate them and sort. I.e sort(unsorted1 + unsorted2)

I'm curious, what kind of a solution are you looking for with that problem? The trivial solution of concatenating the lists and then using a library sort (or cobbling together quicksort) is about as good as it gets for small lists.

For large lists, the best you can do is copy the lists into an array, use a parallel n * log n array sort, then fix the pointers.

The problem doesn't seem to require any real thought. It is difficult to make optimizations because the problem isn't especially well defined and the optimal asymptotic performance is obvious the moment the word "sorted" is uttered.

You can do better by taking advantage of the fact that the lists are already sorted. O(n1 + n2) time, where n1 and n2 are the sizes of the original lists and O(n1 + n2) space for the output.

The "trick" is to iteratively merge your two lists: at each step you select the smallest of the two items you're at in both lists then move forward on the list whose item you picked.

An extension to this problem (I've asked, and been asked, many variations of this) is to merge K sorted lists of N items each. The naive solution is to merge them all together and sort but you can do better if you extend the algorithm above from 2 lists to K and choose a helpful intermediate data structure to optimize the "select the smallest of the K items" operation. AFAIK, all-up the best you can do then is O(NKlog[K]).

EDIT: Re-read the question, realized I read "unsorted" as "sorted" - not sure what you can do to merge two unsorted lists in better than O(Nlog[N]) time beyond non-comparison-based sorts where you make assumptions about the range or distribution of your input (radix/counting/bucket sorts).

Yeah, when the lists are sorted, you need the intuition that you can merge two sorted lists in less than n * log n time. Like you say, the best you can do for merging several sorted lists is (sum of lengths) * log(# of lists).

Yeah, having public github repos is great, but it doesn't scale when the company has a bunch of candidates waiting AND the interviewers have some other work to get done. Also, don't forget that communication is a part of the job too. If you're so introverted that you can't reason your way through a 45-minute problem that has a clearly defined "good" answer, how are we going to discuss designs for an actual system?

> the interviewers have some other work to get done

Work they'd otherwise be doing during the 3-hour coding interview?

1) wrong to assume that you'll be interviewing with the same person for 3 hours

2) if they're doing something not related to your interview during your interview, you don't want to work with them anyway

'It's a skill one has to obtain should it be required.'

Public speaking is something you really should take the time to get good at. I think you are greatly underestimating the importance of communication skills in the workplace...even for developers.

None of my engineer friends have ever had a Google style technical interview. What makes software so different?

You don't ask an electrical engineer to layout a complicated PCB on a whiteboard, you don't have a civil engineer build a bridge out of popsicle sticks.

Surely hiring an incompetent electrical engineer is just as bad as hiring an incompetent software engineer, but from talking to the EEs I know, they just get asked basic questions or go over past projects--nothing nearly as stressful as a coding interview.

If other industries can get by without them, whiteboard technical interviews must not be as necessary as they're made out to be. It seems to me they are just a damaging fad. I think the high stress technical interview could even be one of the factors contributing to the software monoculture.

Well if your job resembles writing on a whiteboard, solving problems, then they should make sure you can do that in the interview. Try going through some problems on a white board you'll probably enjoy it more than you assume!

Software engineering doesn't resemble anything like solving brain teasers on a white board while your boss watches over your shoulder.

No other engineering discipline does this, and software didn't do this until everyone started copying Google.

In fact an HR guy from Google basically said that interviews were useless. [1]

>Years ago, we did a study to determine whether anyone at Google is particularly good at hiring. We looked at tens of thousands of interviews, and everyone who had done the interviews and what they scored the candidate, and how that person ultimately performed in their job. We found zero relationship. It’s a complete random mess, except for one guy who was highly predictive because he only interviewed people for a very specialized area, where he happened to be the world’s leading expert.

Everyone else is copying Google assuming they are doing it right, but they're not. Once Google selects potential candidates and weeds out the people who lied on their resumes with basic questions, they'd probably do just as well hiring a random selection.

[1] http://www.nytimes.com/2013/06/20/business/in-head-hunting-b...

As minor feedback, it would be great if the "How it works" section actually contained how it works info.

I only see 3 steps that look more like facts than actual "how's". Totally free fully anonymous and interviewers from top companies. How does that explain how it works?

I would prefer something like:

1) Signup 2) List all available interviewers (or interviews, or subjects or something) 3) Select one, schedule it 4) Have an interview 5) See results!

Or something like that.

I have found that when you use a question as a webpage, blog or other text, it's really good when you actually answer said question instead of not. Or don't use a question as a section title perhaps?

I would be much more interested in this neat idea if I had a better way of evaluating it I had more info.

Edit: For example, can I select interviews by subject? or by interviewer ex-employer, or by level (basic, advanced, etc) or is it random? Can I rate the interviewer as well?

great feedback, will fix. thank you!

Great! thank you. I'm looking forward for this.

I love this! Too many of my friends who are great engineers melt down completely when faced with an actual interview for various reasons.

But I do wonder if I could put this to use in freelancing as well. Sometimes clients, especially early-stage startups, go for a very normal-technical-interview approach to hiring freelancers

Great...so when everyone does this and becomes good at technical interviews, SV companies will find some other meaningless, high pressure method to screen job candidates. "Steal a bone from this agitated rottweiler while you recite every other fibonacci number up to 20"

I think this is an extremely pessimistic view of what is likely to happen. Being good at interviewing (on both the candidate and interviewer side) doesn't mean that you get jobs you aren't qualified for, it means presenting a more accurate picture of your skills or what the job is. Anything that moves us in that direction is probably good.

Congrats, Aline! This is too awesome.

Be sure to check out her blog as well, "making technical recruiting suck less." Tons of fantastic content. http://blog.alinelerner.com/

>First and foremost, if you're trying to get better at technical interviews, the best way to do that is to actually do it.

So to fix problems with signaling there should more signaling and even more wasted hours?

Coding interview practice is absolutely key. I recently began interviewing for the first time with a number of companies (I'm about to graduate). I noticed that over the course of a month and 3 interviews with 3 separate companies my interviewing skills had increased hugely.

The 4th company I interviewed at had a very different perception of me than the 1st because of the month's practice, even though I had essentially the same technical skills. Coding interviews test "coding interview ability" rather than "coding ability", unfortunately the other ways (Github, aptitude tests etc..) have their own problems.

I have had Aline Lerner reach out to me as a recruiter before. She is one of the best. She worked hard to find great matches.

ohai josh! thanks!

I can easily see the benefit it provides for the interviewees, but what's in it for the interviewers?

I think this site is ignoring the value add for the interviewers as well. Interviewing others is a skill and takes practice and dedication. Many people just take some coding question and ask a candidate without thinking it through much and what they're actually analyzing. It would be good practice for interviewers as well.

You mean like: they could allow a third person to watch/listen the interview and at the end of it, rate the interviewer and give suggestions for improvement?

Every interview you run has positive expected value - you get better at the process, and it may end up in a positive-value hire. If you've got low opportunity-cost time, this is a great tool for consuming it.

I can see it as good for practicing for the interviewer. It'd also be good if I could easily make an offer out and use that as a way of sourcing candidates and getting my referral bonus on.

Interviewer can be the person responsible for hiring in a corporation/startup. He/She can hire the interviewee. This is a win win!

The intellectual challenge is a baited hook for headhunting people who aren't looking for work, so aren't actively applying for jobs or answering cold calls.

States on the page that it is possible to hire people that you interview anonymously. So it could be a good source of people.

I'm very scared of interviewing. I'm 29 and actually never got a job by interviewing and only had 1 interview in my life. It was kinda awful and the lady that interviewed me explained me how I was failing, which I understood but can't improve just by will alone. I also have big troubles on how oral communication implies a deadline (answer quickly or look bad)... I enjoy emails much more than the phone

She said I had to sell my skills much more, instead of strictly answering questions and then waiting for the next one in silence. I felt like a sociopath with no people skills.. I'm kinda shy guy that doesn't do well with strangers, or bigger groups. From my readings online, this is very common with anxious people or introverts.

In the interview there wasn't a group but there was the "this person can control my destiny" pressure, which is also irrational (you can always get another job).

Another things that affects me is impostor syndrome: selling myself feels like lying.

Also the crap unanswerable questions like "What's your biggest flaw?"

So this could actually be very good for me :)

Good idea! It leapfrogs the scores of existing "code interview practice tools" that give you a problem and a text editor and do some auto-validation on your answer by providing a human element. Something like this seems like a more relevant kind of practice.

How does the business model here work? Are interviewers paid? Are you planning on eventually expanding into recruiting?

hey, good question. right now, interviewers aren't paid, but that may change. re business model, ultimately, i'd like to have this platform be something companies can use to find candidates rather than relying on proxies like pedigree (or resume, for that matter!).

what do interviewers get out of it if they don't get paid? Are they employees?

This is very interesting. This is one of the few actual disruptions that I've seen in the interviewing/hiring space.

One small issue: I don't know what I'm getting into when I join the waiting list. I understand what the site is about, if I join will I suddenly be asked to take an interview next Friday? It would be nice to know a little more about the process.

thanks. i really hope it is too!

re what you're getting, i'll update the copy, but all that's gonna happen is that you'll get an email with an invite once we're ready for more users. nothing will ever be scheduled without your permission, and of course, no one will ever get your info.

A walkthrough video would be nice. I've never had a "technical interview" and don't know what it entails, for example. Should there maybe be a pre-testing phase to weed out those who could simply not approach the level that could pass the technical interview?

thanks! video is in the works.

Whiteboard coding problems are absolute garbage. I recently had a remote code problem where I was given a Visual Studio IDE (albeit minus Resharper) and absolutely killed it.

If I'm going to be challenged to write code in front of you, give me the tools I use every day, let me use the resources I use to solve problems efficiently (which btw can include StackOverflow) and you will get a much better picture of me. I don't write perfect code the moment it's written. Often I will mentally acknowledge something needs further thought and my brain will revisit it, sometimes days later, sometimes after multiple iterations. I'm fastidious about those types of things, and as a result I can realistically say I write some of the best and least buggy code in my company. I'm also very good at theorizing about problems and debugging, which is never looked at in an interview.

I guarantee you should hire me, but how can I show you that, and how can you gain confidence in that?

(if you have to submit to a memorization-based screen) I didn't see source materials to review for canonical algos/data structures questions. The 2 books by McDowell and Guiness ("Ace the interview" and "Crack the interview" ) are good, along with

http://algorithmsandme.blogspot.com/p/blog-page_27.html

https://news.ycombinator.com/item?id=7477095

https://news.ycombinator.com/item?id=7827048

http://www.quora.com/Which-are-the-frequently-asked-intervie...

I could put up alist for math for ML/data science as well)

This looks very interesting. I have been through a lot of interviews in the past, with small and large companies and now being in charge of hiring developers I try to make the experience as friendly and as efficient as possible. I hate white-board coding interviews because of the pressure of doing it in front of a stranger, and I choose not to have that in our company. But I do ask technical questions related to the job and I give as much time as the candidate needs to complete a very simple coding test ( fizzbuzz type ) on his/her own in a private office free of distractions and other people.

Unfortunately there are people with amazing cv's who can't solve simple problems or who can't explain what they have done in previous projects.

Interviewing is hard and there are a lot of biases at play but it needs to be done.

Reflections on whiteboarding:

Lately I have realized that I use google a lot less than I did in the past. I don't have to look things up as much, thus I have seen gains in speed when working on some functionality. The interesting part is that coding/reasoning without google feels a lot like whiteboarding. In fact I get into the same 'mental patterns' when solving a problem I don't need google for that I feel when brushing up on algorithm problems at the white board.

I don't come from long history of math rigor. I don't have a mathy degree at all and have hardly used a whiteboard in front of any professors or math nerds. But I'm also not an imbecile; computer science is built upon a foundation of mathematics and if you aren't willing to play ball then get off the fucking field.

Nice. Aline is pretty sharp for a recruiter, and this just makes it even better. Great idea!

I love the footnote on the homepage ;)

If one of the goals is encouraging meritocracy, I cannot imagine why it was decided to add voice to the interview. From someone's voice I can frequently tell their gender & maybe their socioeconomic background, sometimes their race (or what I think their race is)... Basically I don't really buy the "meritocracy" argument if you still have to say "I'm a woman" or "I'm a man" at the start of a technical interview.

As someone who is going into my senior year of college, this looks fantastic. I don't have a ton of experience with technical interviews and I would love to get some more.

I've had 3-4 so far and even for similar jobs I feel like the interviewers are looking for totally different things. Some want me to spit definitions back at them and others are looking for me solve problems. It is hard to know what to expect, especially when interviewing at startups.

Any ideas how the whole thing will be implemented. The site only contains very generic information about it.

How are the interviews going to be conducted ? What will be the different forms of interviews (as most companies have different forms and phases of interviews) ? How will the feedbacks be given ?

Hope this just doesn't turn out to be just meeting place for anonymous interviewers and interviewees .

A friend of mine surprised me recently - he is starting a "new kind of job board". Which struck me as "meh" till he explained - it's more of a "Developer Relationship Management" system.

The idea is if you have developers they will interact with other developers - so track those interactions and you get a good idea of where and how to fish

Pretty cool idea; instantly signed up.

I was thinking about posting "Ask HN: Interview me" since I don't have many interview opportunities in my corner of the world and wanted to find out how good you guys think I am.

If anyone wants to test out their interview skills with me, we could set up a meet over at talky.io and discuss some C# or js. Mail address is in my profile.

I had the same idea a year ago :) Simply, Google and other companies do CV, 2 phone screens and on-site. Someone could handle for them CV and 1st phone screen. They would not only save 45mins for recruiters and devs, but will get extra productivity. No distraction for hackers.

Charge a little to filter out people that clicked, but don't care. I'd pay.

I wonder where the interviewers will come from. That said, this is a great idea, and also along the lines of the "Show me a million new jobs" RFS [0].

[0] http://blog.ycombinator.com/new-rfs-one-million-jobs

I like this in concept. It's like how major symphony orchestras hire, put a curtain up between the performer and the judges so that the performer is never seen and is assessed solely on the merits of their performance. Interesting to see how it might play out in practice through this site.

How does it manage not to connect me with someone that I work with based on just my github profile? I work with plenty of people who don't have a github profile, or if they do I'm not connected to it. I'm probably not connected to most of them on LinkedIn either.

I really wish this had existed a year ago when I panicked during an interview. Having this type of practice is ideal in my mind for any type of technical role.

I, too, am curious about sustaining this service though. Have you considered offering tiers for participants?

There is voice but no video! How awesome is that! You invented the telephone, I guess.

Seriously, I have no idea what kind of service you are trying to describe on interviewing.io. There is only the usual BS like "totally free" and no actual answers.

Great idea!

Being Berlin based I am really curious on how tough the interviews are gonna be.

The interviews I have had here were not challenging at all. The technical problems did not even reach the difficulty of qualification round problems in Google's Code Jam.

Is it just me or shouldn't we be moving towards projects rather than code interviews? I think you can recover far more about a person in a project setting than by asking them a couple of random questions to solve in X time.

Time wise it costs too much for the candidate.

Their oAuth application URL is localhost :P (check at the time of Github authorize)

This is a great resource for first year CS co-op students at Waterloo. Even though Waterloo grads end up with at least a hundred interviews under their belts, the first few are really difficult.

Great job, keep up the work!

I'd also be interested in a "faux" simulation, perhaps where it is pre-recorded video interviewer with a countdown timer.

The video could occasionally say "Are you sure you want to do that?".

This is especially useful when you consider that companies that actually interview you absolutely will not tell you why you failed their process, or they will offer diplomatic deceptions instead.

It's like Chatroulette[1] for technical interviews.

[1] But without the dicks

I laughed at this...

I came here to say just that! :D

me too.

yeah... there is a big problem with interviews and best practices already. if you are good enough at an interview you can con your employer into giving you lots of money for not very much... can we have a service that goes the other way?

identifying that brilliant junior who is worth 5x his years or the dirty rat who has 30 years of experience working out how to not do his job and get away with it.... that's hard.

interviews are already easy to win for the prospective employee...

Why would this be free?

This is not only good for the interviewee, but also a great practice ground for interviewers. Interviewing candidates also takes skills. :)

This is awesome. There is a chance I may be looking for work later this year BUT I've been doing my own thing for > 10 years.

I only have 1 sentence: “Coding interview (democracy) is the worst form of interview (government), except for all the others”

Not a good analogy. You can design interviews and measure outcomes. The goal is not to eliminate coding if it is relevant for the position, you need to do it right. There are people who spend their life designing and validating tests, don't ask a busy engineer to wing it. Companies could use an unbiased computer-based test as a first pass. This way, candidates can prepare and feel they are getting a fair chance. In the second pass the interviewer can focus on higher level problems and soft skills.

Is there a business model here? Why are the talented engineers running the practice interviews devoting time to this?

I'm guessing because there is potential they could find a hire. Even though you can choose to be anonymous, if two people hit it off there is nothing preventing them from exchanging contact info. Seems like somewhat long odds unless the candidate is willing to relocate anywhere.

Brilliant way to connect companies that are hiring to developers without the pressure of a 'real' interview.

This is a great idea, I can keep my skills up to date and be employable, if my Canadian startup fails.

> Hi, my name is Aline. I used to code for a living. Now I hire engineers. One of the things I've done that I'm most proud of is Lessons from a year's worth of hiring data, where I showed that, in an engineering resume, pedigree isn't a particularly valuable signal (whereas typos and grammatical errors are)

So what happens if you're lystdexic?

You learn to use a word processor with spellcheck and get someone else to proofread your resume before sending it out, just like someone who isn't dyslexic should do.

It would also be great to have some sort of feedback mechanism also given in anonymity.

Silly question, why not chat (which can be saved for review etc) instead of audio?

hmm, so audio is closer to what you'd get in the wild, ultimately making for more indicative practice. logging it might be useful down the line, though, in some format (provided users agree to that)!

I suppose they could do the same with audio. Save it and perhaps also provide transcripts.

I pressed the "sign up" button and . . . nothing happened.

For me a popup appeared with a Github auth window. It's possible that your browser blocked the popup.

I did email, not Github. I no more want to log in with Github than I want to log in with Facebook.

EDIT It seems to crash in the background if you have a "+" in your email address.

thanks, will fix!

Also, if you don't email me immediately, I probably won't ever think to check my spam folder later.

Simply Awesome!

Kinda off-topic: where'd you get the batman icon?

this wont workout i suppose

I've been using https://www.interviewcake.com and highly recommend it. It's just a series of problems you work through combined with advice.

There's a lot to an interview besides just coding questions. Interacting with an actual interviewer lets you get all of the human interactions, talk in-between problems, using problems to showcase talent, etc... all this stuff I'm told I should do but have no idea how to actually do, basically.

Haha thanks for this, I actually signed up for this a while back and completely forgot the name of the site.

This is a very promising idea.

I always crack when it comes to algorithm type question. I am aware of some of the run of the mill ones like, write a palindrome detector, bubble sort.

However, I still can't figure out the crazy hard ones like:

In a pyramid of numbers, write an algorithm to find the path to the biggest sum. Write a method to produce pascal's triangle. Given a grid, where X = wall, O = space, write an algorithm to figure how big the room is and so on....

My biggest gripe is knowing that these type of questions will kick my ass and not being able to prepare because you are already supposed to know this from your comp sci courses, which I've never been to as I have been self taught through making my own software, and learning as I went along.

If you're a naturally competitive sort of person, you should try doing TopCoder and Google Code Jam. I also skipped formal CS education and when I was roughly at your level of ability I found that doing TopCoder SRMs in particular taught me a nice toolbox of common approaches to algorithmic problems.

tree of numbers -> keep track of the sum as you work your way down the branch. every visit to a node, check if that sum of the parent plus your current node is larger your your current max. if it is, replace your max, keep traversing your tree.

Submitted this by mistake, can't delete, funny how downvoters don't see that.

Right, it was at least more insightful than "This!".

This is a very interesting discussion. Would love to hear your thoughts on our London based startup www.Prehash.com which is going in a similar direction. Companies can host organization specific coding challenges on our website and developers apply by solving them. There is no time limit for developers and no one is looking over your shoulder. The only thing is that each time you run the test we take a snapshot in a github repo. Any feedback is welcome! Cheers.

I would like to know how it is different from the likes of different website which seemingly do the same thing - HackerRank, Codility, HackerEarth etc., Mind explaining what is it that you are planning to do different?

Hi bleak, Prehash helps companies to attract and engage with developers through coding challenges. Codility is a pure code testing site IMHO. HackerEarth according to crunchbase provides a SaaS application to do automated assessment of technical and logical skills of candidates HackerRank is going more in our direction with coding challenges to engage with and find candidates as opposed to testing them.

Reply on news.ycombinator.com