I’ve talked to a lot of people who really need a technical co-founder. Unfortunately, people who have a grand idea, but can’t do the programming or engineering, are a dime a dozen.

Are You a Clown? Do You Have a Good Idea and Understand the Risks?

So let's say we've met, talked for an hour, what goes through my head? I’m trying to figure out if you’re a clown, whose idea is so grand that it’s biggest value is entertainment and laughs. Most people who I talk to, unfortunately, are clowns! Don’t feel bad if you realize that you’re just clowning around instead of building a sustainable technology business. Every successful entrepreneur has been a clown at one point or another. I certainly have. I’m sure you don’t have to think very hard to find examples of Steve Jobs, Bill Gates, Mark Zuckerberg, Elon musk, or Jack Dorsey being a clown.

Why would I think you’re a clown? Maybe you are trying to build a business that would try to compete with a company like Apple on a shoestring budget. Maybe you are doing something silly, like putting the engineering before finding a good solution to your problem, like a guy who I met who wanted to build a modular car that would seat either one person or have a clip-on module to seat six people. Maybe, your management philosophy seems a too hard to work with. Maybe you’ve cornered me at a networking event and tried to chew my ear off with ridiculous ideas because your Adderall prescription is too strong. Maybe you want to build a submarine with a carbon-fiber hull, and just won’t listen to reason.

I hope you realize that the odds are against you. All high-tech startups are, at some point, an odds game. Unfortunately, it’s difficult to know the odds going in, but if you don’t seem to have a good understanding of the odds: you’re a clown. An important part of running a high tech startup is managing your risk to keep the odds in your favor.

Will You Expect Me To Work For Sweat Equity Only?

So now let’s assume that I’ve decided you’re not a clown: Your idea is solid, you’re a reasonable person, (IE, you’re not building a submarine with a carbon-fiber hull,) and you understand how to manage your risk. The next thing that I’m going to look for is, is your idea interesting to me? If it’s not, don’t feel bad. There’s a lot of high-tech startups that just have no appeal to me whatsoever, but probably could be very successful.

So now let’s assume that you’re not a clown, and you're working on something that is interesting to me. I bet you’re going to want me to quit my job right? I'm probably going to tell you my current salary and say that I can’t quit my job unless you can pay me. I hope you realize this is a bluff, sort of. Before I explain why, I will eventually be willing to quit my job and go a period without income. I’m not ready to put “sweat equity” on the table… yet.

Why am I so fixated on money? There’s many reasons. Remember how I mentioned that in high tech startups, it’s an odds game and the odds are against you? It's extremely hard for me to play the odds. Chances are I have a well-paying job that I like, (unless I am between jobs.) It probably took me a lot of time to find my job and get to a good amount of respect and clout in my organization. I’m not going to squander such a position unless I am fairly certain that I the startup will “work out” for at least two years. One way to do that is to have income at day one. I’m at a stage in my career where being on the job market is unpleasant. (Why? I’ve been around the block a few times and I have very tolerances for poorly managed engineering groups.)

But I know the startup game, I know that it is very difficult, or impossible, to raise enough money to pay me the salary I want very early in the lifetime of a company. I know that what I ask is almost impossible, which is why I say it's a bluff, sort of.

I have quit my job before to try and run a company, so I know what it’s like to chase my dream on no income. I have no intention of chasing your dream. That's why I bluff about the money. It's a control thing. Specifically, it’s about your control about what we are building.

Will You Be Willing to Give Me Creative Control in Return for my Sweat Equity?

If you want me to quit my job, to be a technical co-founder, you need to be extremely flexible about what we’re building! One thing that I’ve encountered over and over is that someone is so rigid in what they are trying to build, that it will only work out if it’s an employer employee relationship. In that situation, I will happily take whatever title you want to give me and do my best to build whatever you want! After all I’m getting paid! As long as the money lasts for a few years, I’m willing to take a chance on you.

But chances are that you have very little money and very little resources.

The only way we are going to be able to build a company is if you trust me to take your ideas and research and figure out how to do it on a shoe-string budget with no resources. This is going to require an extremely high amount of flexibility on your part: You will need to trust me completely and let go of control over the product. There are many areas of the business that I will have minimal control over too, but I trust that you will do your part.

Why? Engineering is always about compromises.

I will probably compromise the product based on my comfort level about working with certain technologies. You might think, “oh well, I’m going to keep looking until I can find someone who is going to build every detail exactly to my specification, purely for equity.” You might get lucky, but I think you will miss your market window before you find such a person. I encourage you to compromise your dreams with pragmatism and let me riff on your ideas: An MVP is always a compromise.

Can We Trust Each Other Enough to Collaborate Versus Fight for Control?

We need to be able to develop a great rapport where I trust that you to do your part in building a great company. It’s more than you being an awesome salesman or an awesome procurement person, or awesome marketing. The only way we can build this rapport is by spending time together; where I can figure out how to build something that balances:

• Your vision
• The very short time we have to build an MVP
• What is buildable in that time.

It's only when we can build the rapport that we can discuss me working for sweat equity. Without such a rapport, I’m going to hold firm that I need income.

To summarize: if you want me to be your technical co-founder, and you’re not a clown, and you want me to quit my job, and you can’t pay me the salary I want, we’re going to have to make a compromise. You’re going to have to give up the control over the product and give me a lot of your attention. In return, I can guarantee you that I will get as close to your vision as I reasonably can.

It’s well-known in the software engineering field that it’s hard to recruit software engineers. Once, a recruiter once complained to me that most software engineers ignored introductory emails. (In contrast, they told me that typically other professions have a much higher success rate.)

I will try to explain why most software engineers ignore recruiters.

TLDR: Most of the time, responding to a recruiter ends up being a waste of my time: The recruiter stops responding, the interview stinks, or I end up not wanting a job. The job market is too frustrating to interact with recruiters unless I am actively looking for a job.

Recruiter SPAM

I get a lot of spam from recruiters who never read my resume. These generally fall into these categories

1. Unskilled office work that involves a computer
2. Jobs that I am qualified for, but require relocation
3. Jobs where I have little experience in the technology stack

In all cases, I wonder if anyone actually looked at my resume before sending me an email.

These emails aren’t “honest mistakes,” either. They are clearly widely sent out, and lead me to believe that someone is just sending out hundreds or thousands of emails without checking that the people they are sending them to are good matches.

This is a problem. SPAMming job postings to a poorly chosen audience is merely recruiters pushing their work onto others. Reviewing resumes is work, and it takes a lot of work on the part of a recruiter to find appropriate candidates. When I’m a job seeker, reviewing job postings is quite time consuming. Recruiters shouldn’t push their job into my inbox.

Unfortunately, the SPAMiness of recruitment emails makes me less likely to respond to a recruiter who has personally reviewed my resume or LinkedIn profile.

How to fix this:

• Review the resume and/or Linkedin profile of each candidate you approach
• Make sure the outreach email contains some personal details that prove that you’re not SPAMing
• Only approach candidates who will need to relocate when there is a relocation package; and mention that package in the initial outreach email.

Many Recruiters Are Difficult to Work With

I’ve lost count of the number of times I’ve emailed back and forth with a recruiter, only for the thread to go cold with no response.

Some recruiters don’t understand the asynchronous nature of email, and request meetings, via email, on short notice.

Some recruiters call me while I’m in the middle of my job and expect me to drop what I’m doing to hear about their new job. (I no longer list my phone number on resumes.)

Often, it’s impossible to ask critical questions about the job.

Sometimes the recruiter’s initial email doesn’t provide any information about the job, beyond a vague location and the programming language. This is not enough information to decide if a job is worth applying for.

Many recruiters don’t know enough about software development to accurately match candidates to jobs. It ends up being guesswork for them, and it’s hard to know, when speaking with the recruiter, if I’m a good candidate.

How to fix this:

• Never, ever, let an email thread drop. Politely end email threads when you will not continue with a candidate.
• Assume that candidates need 24 hours, or more, to respond to any email.
• Be knowledgeable about software development
• Never cold call software engineers

Some Recruiters are Just Ploys to Collect Personal Information

Recently (early 2022,) recruiters started contacting me on LinkedIn about “A Software Engineering Position in Boston, MA.” Instead of providing a link to a job description, the link is for me to sign up for a hiring network. There is always a claim that, if they find me interesting, they will follow up.

I always flag these as SPAM. I don’t believe that these recruiters represent real jobs.

I will not sign up for any website merely to read a job description. I also don’t want to join another career network. I’m already on LinkedIn and get plenty of emails outside of LinkedIn.

Recruiters don’t know “The Rules”

In general, the way that hiring a software engineer works is:

1. An introductory phone call with the recruiter or hiring manager; or both
2. A technical screening. This used to be a phone call, but it’s now evolved to use a web-based coding platform or screen sharing
3. A full interview

The purpose of the introductory phone call and technical screening is to ensure that there is mutual interest between the candidate and company; that the candidate is competent; and to confirm that the candidate has required technical background. Bypassing these (introductory call and screening) ends up wasting a lot of time, because for software engineering, most candidates fail. Either there isn’t mutual interest, or the candidates fail the technical screening.

I’ve encountered a few recruiters who ignore “the rules:”

• In one case, the recruiter claimed, “we don’t get phone calls, we get interviews.” The “interview” was no different than a phone screen, and wasted my time due to travel.
• Another time I worked for a company where HR didn’t know “the rules” and scheduled day-long interviews with incompetant candidates. We could have saved these candidates their day off with a simple phone call.

I’ve learned to keep these kinds of recruiters on a short leash, and either walk away or disengage.

How to fix this:

• Be familiar with general industry best practices in hiring
• Don’t bypass critical parts of the hiring process: Determining mutual interest and introductory technical screenings save everyones’ time

I Won’t Move

Many recruiters approach me for jobs with absurd commutes, or for jobs that require that I relocate.

I’m no longer in my 20s, no longer single, and unable to move whenever I want to.

I live in a home that I built with the intention of living in it for a long time. I’m married to a wonderful wife who has her own career, I have kids, friends, and extended family. We aren’t going to move every time I change jobs.

I’ve been a telecommuter, with occasional office visits, since 2014. It’s worked out great, and the situation works out great for many other software engineers. When I see that a company is hostile to telecommuting, I interpret it as having control issues, or a desire to babysit.

How to fix this:

• Make sure to map out how long it will take a candidate to commute to an office. (Google Maps lets you estimate travel time during different times of the day.)
• Make sure to acknowledge if a candidate will have to move, or have a commute longer than 30 minutes
• Explain telecommuting policies / relocation packages in the initial email
• Explain to employers that hybrid telecommuting is needed to widen the search radius to engineers who live too far away to commute

The Pay is Probably Low

Software Engineering salaries are all over the place. I generally assume that most recruiters reaching out to me are trying to hawk lower-paying jobs.

With few exceptions, I will only pursue a job if I believe it will be a ~20% pay increase from my current job.

Software is an economic multiplier: I once heard that my 4 month project saved a company a million dollars a year. Because the software I write has substantial economic value, I expect a fair portion of the rewards.

How to fix this:

• Only accept recruitment jobs that are at or above median pay
• Give a salary range in the initial outreach email
• Remember that software is an economic multiplier

Interview Prep and Take Homes are Time Consuming

I have firsthand experience interviewing candidates for software engineering positions. It’s greuling. A big problem, when hiring, is that most candidates who come into the interview aren’t capable of doing the job. Even worse, when we hire the wrong person, the situation becomes more frustrating and grueling than the interview process.

The industry handles this by attempting to carefully screen candidates, often through a series of take home exercises, detailed technical exercises to perform in the interview, and extensive interview preparation exercises.

Interview preparation and take-home exercises compete with the time I have for my family and other commitments. Interviews during business hours require that I fib to my current employer about my whereabouts.

How to fix this:

• Make the job appealing before I need to invest precious time
• Have me meet with the hiring manager on the phone or videoconference before time consuming activities
• Make sure to explain this process in the initial contact email

The Company Probably Rejects Most Candidates

This isn’t something I admit that often.

Software engineering interviews are notoriously fickle, for so many reasons that I could write another article about all the problems I’ve encountered interviewing. In summary, for every good interview I’ve encountered, I’ve also had poorly explained questions, questions that require that I know some obscure algorithm, or interviewers who want to prove that they’re smarter than me. Sometimes I wonder if the interviewer has some bias.

When interviewing candidates, a common piece of wisdom is to reject when in doubt. I’ve interviewed a few “maybes” that I rejected. This is because it’s easier to “move to the next candidate” instead of putting up with a bad hire. I’ve also seen hiring an excellent candidate fall through because the hiring manager screwed up the process.

Aside: We really need a Credentialing Process

Many professions have a credentialing or licensing process to smooth over situations like this. My wife is a pediatrician, and the jobs she sees posted can only be applied to by credentialed pediatricians. She does not have to prove competency during the interview process.

Compared to interview prep, take-homes, or complicated interview questions, I’d much rather get credentials. It’s a better time commitment to earn credentials that I can use for any job interview; and it works out for the company’s favor because they don’t have to figure out if I’m competent.

How to fix this:

• Try to find some kind of a proxy for credentials
• Recruiters: Develop your own technical screening process so you can screen a candidate once and let them interview at multiple companies

I Might Not Like the Job / Company

Job interviews are a two-way street; I’ve bowed out of a few job interviews because I believed I wouldn’t like the job. Unless I’m desperate, I’m not going to risk leaving my current job if I have any suspicion that a job I’m interviewing for is going to be a difficult environment.

How to fix this:

• Carefully screen the hiring managers that you recruit for

Conclusion: Let’s talk the odds

When Syncplicity hired me, my manager told me that they phone screened 100 candidates, interviewed 10, and I was the first one they were comfortable hiring. (I then went on to make us an industry leader.) In my experience, this was accurate. We rejected many candidates on the phone screen, and many on the on-site.

Thus:

• Fail the interview: There is a 1% chance of getting an offer from a phone screen with a manager
• Recruiter drops the ball: There’s a high chance a recruiter won’t respond back to me
• Won’t accept the offer: There’s a high chance I won’t like the job, or the pay will be too low

Thus, in my estimation, responding to a recruiter outreach has less than a 1% success rate for landing a job. It’s a fool’s errand.

That’s why software engineers don’t respond to recruiters. We have better things to do!

Note: The article made it to the front page of hacker news! Lots of great discussion there.

---

The software engineering field has controversy over using whiteboard coding in interviews, versus candidates doing take-home coding assignments. This is a false dichotomy, the problem is bad interviews.

Quincy Larson, in his post Why is hiring broken? It starts at the whiteboard, gives some examples of bad whiteboard questions. In his article, he slams the practice as either a form of hazing, or he gives examples of horrible questions that rely on the candidate memorizing arcane algorithms.

Yet, the bad examples that Larson lists are the opposite of what Joel Spolsky recommends in Smart and Gets Things Done. The only thing I can conclude is that Larson is really complaining about bad interviews, not bad technique.

In this post I focus on the tradeoffs between take-home coding questions, and live coding exercises, such as whiteboard coding.

Examples of Bad Take-Home Questions

After I wrote the first draft of this post, I actually walked away from a job opportunity that asked me to do a horrible take home exercise. Here's the assignment, summarized to respect the company's privacy:

This should take a few hours. Create a web-based message board. Use C# and ASP.Net Core, with Angular and Material design. Use a database. When someone adds a message, update all other open browsers in real time. To make it easy for you, you don't need to implement authentication.

This isn't the first time I've walked away from such a situation. Why did I walk away? In both cases, it was the same exact reason.

The exercise was supposed to take "a few hours" according to the hiring manager, but I'm extremely rusty with ASP. I haven't done anything real time since before WebSocket, nor have I used Angular or Material design. I anticipate that such a project would take one of their engineers more than "a few hours" to finish, and take me at least a day to come up to speed with all the various APIs and patterns.

At this point, we've only had one phone screen. The company hasn't invested much time in me, but they expected me to invest a lot of time in them. I hadn't met other members of the team, and I've never seen the product.

I wondered, what if I put a lot of time into this and make a novice mistake? Will some junior engineer reject me? Is this a sign that someone in a leadership role has unreasonable expectations? What if, at the end of this process, I just don't want the job?

Take-home assignments should never have learning curves. There are reasons when it's okay to request an alphabet soup of technologies, which I explain a little later.

Another situation where I've walked away was the "fix a bug in our open source project" task. Onboarding on a complicated piece of source code can take a few days. It can be longer if the source code uses a language or idiom that I'm unfamiliar with.

"Fix a bug in our open source project" always feels like hazing to me, because I just can't compete fairly with someone who's already worked in that codebase. I always worry that I'll put a lot of time into the take-home and not get an interview.

In another case, a hiring manager emailed me a candidates' take-home coding assignment and told me that I needed to interview the candidate, in-person, later that day. The take home question was fine, but the candidate's code was awful! We should have rejected the candidate instead of flying the candidate to the office. Even worse, I suspected that one of my colleagues was rude to the candidate when reviewing the code.

An Example of a Bad Whiteboarding Question

I once interviewed at a company where a young engineer gave me a simple question, which I quickly answered with a straightforward solution. The engineer then spent the rest of the time berating me for not including an insignificant micro-optimization.

The interviewer was just as rude as my colleague was when he reviewed the bad take-home assignment. I remember telling the recruiter that I didn't think I'd like the company.

In another case, I interviewed at a video streaming company where the whiteboard question required that I know a textbook algorithm that I would never use directly. In reality, the question was asked poorly. If they said, "here's the problem and here's the algorithm you need to solve it," it would have been a great question.

But, more importantly, a bad interview can happen with either a take-home assignment or a whiteboard assignment.

The Problem is Bad Interviews

It's always important to remember that an interview is a two-way street. It's just as important to sell the job to the candidate as the candidate must sell themselves to you. Normally, it's extremely hard to find software engineers qualified to show up for an interview, so running bad interviews means that the best candidates will just walk away.

Larson, in his blog post, explains a more disturbing trend:

Whiteboard interviews are akin to a hazing ritual — a rite of passage that one must endure before joining an organization — because everyone else there did. “I went through a battery of whiteboard interviews when I got here, so why shouldn’t this person?”

I suspect companies who haze potential employees have bigger problems, the first of which is that they aren't coaching their interviewers in how to perform a good interview!

No one ever coached me in how to run a good interview. Instead, I had to take the initiative to read "Smart and Gets Things Done." When I've worked for large tech companies, the HR departments knew less about how to interview a software engineer than we, the developers running the interviews, did.

What About Interview Websites? How About The Candidate Brings Their Laptop

Sites like https://leetcode.com/ and https://coderpad.io/ offer ways to facilitate live and take-home coding questions.

I think these sites are great, especially when they provide a wealth of examples of questions to base an interview on. But, just using a tool won't magically make someone a better interviewer.

I think the biggest value of these tools is that they respect the candidate's time. Before asking a candidate to spend time traveling to your office, you can do the first part of the interview without the candidate investing travel time. This is critical if the candidate needs to fly for the interview, but also respectful for candidates on the other side of town.

I also think a great technique is to ask the candidate to bring a laptop to an on-site interview and then watch the candidate code on-screen. As a candidate, I once plugged my laptop into a projector and fired up my IDE. I personally found it easier than scribbling on a whiteboard.

Tradeoffs Between Whiteboarding vs Take-Home questions

When a company relies on take-home questions, it's low-risk for them to send anyone their take-home question, in contrast, an in-person whiteboard question requires a more time from the company's engineers.

But, a company can send out its take-home interview question indiscriminately and waste candidates' time. (This is why I walk away from time-consuming take-homes, or take-homes that require an alphabet soup of technologies.)

It's possible to cheat on a take-home, because a candidate can send it to a stronger programmer, or sit with another programmer. Cheating on a live coding interview is harder.

But, many engineers prefer to code without an audience and feel more comfortable coding in private. The take-home questions often give bigger insight into the candidate's style and ability to organize a program.

Take-home questions give little insight into how a candidate behaves in the office, or has a technical discussion. They also give little insight into a candidate's intuition, because you only see the finished product, not their working process.

With a whiteboard question, or other live coding techniques, it's easy to see a candidate's biases. These biases can expose someone who's going to struggle in your stack, or just someone who you won't get along with. They also can expose when a candidate has poor "common sense" for the kind of work you're doing.

Another advantage of whiteboard questions is that it's easy to tune them on the fly. You can see where a candidate stumbles, and you can infer a bad question based on a candidate's reactions.

It's much harder to tell when a take-home question is bad. Some candidates might want to impress you and spend an unreasonable time on the question. Other candidates might ghost. (Ghosting means the candidate just stops responding to emails and phone calls.) The feedback loop just isn't there.

As a candidate, when I get a bad whiteboarding question, it's easy for me to just muddle through it. Depending on circumstances, I'll either decline the job or discuss the odd question with someone else in the process. But, when I get a bad take-home question, I'm stuck between either ghosting, (not responding at all,) or providing feedback. I've done both, and I'm not sure which is a better approach. The one case I gave feedback, the hiring manager got defensive, which confirmed my decision to walk away.

So, take-home versus whiteboard (or another live coding technique) isn't a slam-dunk decision. It's more about knowing what's critical and weighing tradeoffs. You can also just let the candidate decide for themselves, but then you have the overhead of planning two different kinds of interviews.

How To Plan a Good Interview Question

In my experience, the purpose of a technical challenge is more than just determining competence. It's also how the interviewer verifies that a candidate has good comprehension of tasks, and can conduct themselves well during a technical discussion. Furthermore, these discussions ensure that the candidate can get along with the team.

A good question requires careful planning.

1. Focus on 2-4 very high level programming concepts that are critical for the job.
2. Have an emotional understanding of what "common sense" is for the job. (What kind of intuition should a candidate have?)
3. Accept that you can't onboard someone in your entire stack in order to screen them
4. What are specific biases you need to screen out?
5. Are some concepts better screened in a live exercise or in a take-home assignment?
6. Make sure that you're screening in people who will succeed in your questions.

Specifically, if you're trying to hire generalists, accept that new hires will have a learning curve. You won't be able to test such candidates on details of your stack because they probably haven't worked with it before.

In contrast, if you're trying to hire someone who can work in your stack from day one, it's okay for questions to require knowledge in your stack. You just need to make sure to only screen candidates who already know your stack. This is useful when screening contractors for short jobs.

Translation: Only ask someone questions about frameworks and libraries if you require direct experience with those technologies. Otherwise, If you're interviewing someone with Postgres experience for a job with Oracle, don't ask Oracle-specific questions or assign Oracle-specific tasks.

You Can Ask the Candidate to Present Code they Wrote.

One recent interview completely avoided a take-home question or a live coding exercise. Instead, they asked me to present some code of my choice. I spent some time going through my github repository finding some interesting work I've done over the past decade, and then we reviewed a fitbit watch face. Ironically, I probably spent 2-3 hours preparing; both in choosing the code to show, and then reviewing the watchface code as I hadn't looked at it in over a year.

The thing that I really like about this technique is that it's reusable. If another company asks me to present code, I'll just propose the fitbit watchface and it'll be fresh in my memory. Saves me time too!

What Makes a Good Take-Home Question

A good take-home question should take 2-3 hours.

It's important to avoid planning fallacy where you think something is simple, but then what you thought should be 2-3 hours really is 15 hours.

What's critical is to avoid pushing a learning curve on a candidate. If your take-home require specific libraries, languages, frameworks, ect, then you should discuss it with the candidate before you send the question. Any framework or tool that you ask the candidate to use should be on the candidate's resume.

Dave Rolsky, in A Technical Hiring Process Revisited, says:

When you come up with a homework exercise you must have at least two (and preferably more) of your existing staff do it, including some people who were not involved in formulating the exercise.

If the homework is in a problem domain that relates to what your company does (and it should be) then you should expect in house to staff to finish it in half the time it will take a candidate.

In my experience, the screenings that I like are "use any language, libraries, and frameworks" and then run in a shell; or verified with unit tests; or present a very basic HTTP API. You can also direct the candidate to use a language that they claim significant experience in.

My favorite assignment was for me to feel my way through a maze that was provided incrementally though a REST API. Another one had me write a RAM database and tests.

When I was desktop client architect at Syncplicity, I occasionally used a coding challenge that had candidates build a document by loading multiple XML documents from a web server. We primarily screened candidates with C# experience for a job in C#, so we asked the candidate to use C#. But, when we interviewed a Mac developer with Objective C experience, we asked the candidate to use Objective C; and if we interviewed someone who needed to learn C# on the job, we'd let the candidate use their most comfortable language. We assumed that candidates could load documents over HTTP and work with XML. Internally, we had a few engineers make sure they could do the exercise in about an hour or so.

We did not require any specific library or framework, but we did suggest two of .Net's built in XML parsers as a hint.

Working on the Syncplicity desktop client often required working with poorly documented APIs, so we deliberately kept a little bit of ambiguity in the instructions. My original version of the challenge was slightly more ambiguous, and I think "more fun" for people who can work with poorly documented APIs.

How To Plan a Good Whiteboard Question

A good whiteboard question requires careful planning. The interviewer, or team, should be able to plan a 1-hour interview in about 1-2 hours, but can re-use the interview for most candidates, and even different (but similar) positions.

1. Focus on 2-4 very high level programming concepts that are critical for the job.
2. Have an emotional understanding of what "common sense" is for the job.
3. Plan coding questions that rely on 10-20 lines of very basic code.
4. Plan the discussion: How do you give instructions? (What's written and what's verbal?) Assume you're going to have to explain all needed APIs and algorithms.
5. Plan hints
6. Anticipate biases that indicate a poor match
7. Decide if these are true whiteboarding questions, or if the candidate will bring a laptop, or if you'll do these in teleconference with an online coding tool

I personally like to include a question that tests a candidate's listening skills, where the task just requires following instructions. These aren't trick questions, instead, they're meant to ensure that the candidate can participate in design discussions and comprehend assigned tasks.

I also include a very straightforward question where I provide an API and have the candidate transform data from one format to another format. These primarily filter out candidates who don't get certain basic concepts; but I also use these to filter out candidates who's fundamental biases would mean they wouldn't fit in with our team, or demand that we refactor everything because we didn't use their framework or design pattern of choice.

As a candidate, the thing that I love about live coding exercises is that they give me a real good feel for what it's like to work with someone, and what the general team dynamics are. In the case when the interviewer slammed me for not microoptimizing my code, I realized I didn't want to work there. It was more due to their attitude than the desire to microoptimize.

What if it's important that a candidate demonstrate using an algorithm? Actually, that makes a great live coding question. Just make sure that the question involves explaining the algorithm instead of expecting the candidate to know it ahead of time. Or, before the interview, suggest that the candidate review the Wikipedia page about the algorithm.

In Summary: It's about planning a good interview

When I'm a job candidate, I really don't care if a coding question is whiteboard or take-home; nor do I care if it's truly on a whiteboard, or I need to bring my laptop, or we do a teleconference with an interview website. I like the style where I can present some code that I've written, but it's certainly not required for me.

Some candidates have preferences, and if you're in a situation where you want to please everyone, the best thing to do is let the candidate choose between some form of live coding, take home, or presenting existing code. Assuming you don't give the candidate the choice, just look at the tradeoffs and pick what's more important to you.

What's important is that you research how to plan good questions and make sure that everyone involved in the process is also trained in running a good interview.

Take Home	Live (Whiteboarding)
Some candidates feel less pressure	Other candidates want team interaction
Can evaluate more complicated code	Can evaluate collaboration and behavioral style
May not get feedback on issues with the question	Can get feedback on the question from body language, tone of voice, and reactions
Candidate can use the tools and environment where they are comfortable	Coding on a whiteboard or in an online tool is about discussion
Candidate has little time pressure	Candidate has time pressure
You evaluate the finished product as a whole	Insight into the candidate's thought process
All hints have to sent ahead of time	You can give hints on a case-by-case basis
Can not adjust the question as you go	Can adjust the question as you go
Easy to send a take-home to a "maybe" candidate	Company has to invest extra time for each "maybe" candidate
Can waste a "maybe" candidate's time	Company has to choose wisely before inviting a "maybe" candidate