Very interesting article, thanks for writing! I have but one, eh, comment:
> Your code should be commented
Sure.. but:
> * @param {string} stringToTest - the string to test.
> // make sure we have a string.
> if (typeof stringToTest !== "string") {
>
> function isPalindrome(stringToTest) {
> ...
> // if we get here, it's a palindrome
> return true;
Do we really need to explain that stringToTest means string to test? I for one find such low level comments almost completely redundant. I prefer strong variable naming and other ways of creating clean code to littering the code with comments that the code expresses naturally.
Comments should IMHO be reserved for explaining special complexities, any particular gotchyas, etc.
I came here to make the same comment (pardon the pun.)
This article takes such an expert tone. But it's just opinion. For me, that comment would be a red flag.
He also says to write the most efficient code possible. Then doesn't. See the comments at the end of the post.
Overall, I think what this shows is that as an interviewee, the best thing you can do is try to get an idea of the interviewer's expectations as quickly as possible. People love saying here that it's not a test scenario. But it is. The interviewer has a preconceived notion of what you should and shouldn't do and you need to meet that notion.
As an interviewer, recognize it's easy to think you're smarter than the other person when you already know the answer. Don't be pompous. Don't assume you know better. Try to set expectations very clearly. Try to really listen to the interviewee and understand why they're making the choices they are.
Personally, I would be frustrated by this interview. I feel like this article is a thin justification of a lot of standard interview practices that don't actually work. It and his further comments take a condescending tone that makes me worry he wouldn't be open to approaches he hasn't seen.
Reminds me of a time an interviewer basically gave up on an interview because I told him there were O(N) algorithms for sorting strings with a fixed alphabet. He said "Best case sorting is O(nlogn)" and I could hear in his voice that for him the interview was over. I knew what radix sort was but in the moment I couldn't actually explain or implement it without looking it up and things just went downhill from there.
I agree. If a comment can be automatically generated by a computer (stringToTest -> 'the string to test' can be automatically generated), it should not be a comment at all.
"// throw if we didn't get a string" before a throw statement two lines away from "make sure we have a string" would annoy the hell out of me in production code.
Right? I know developers who swear by comments and ones that swear by self describing code. You can't assume you're interviewing with one or the other.
I agree. Too many comments makes it hard to sort out which are the comments that actually provide insight to how the code works (or is supposed to) from the comments that are just bullshit the author put there so he could say he puts a lot of comments in his code.
Comments should explain the why of code, not the what or how.
From a technical standpoint you should read uncommented code and more often than not be able to tell exactly what it does (barring a lot of poorly named methods or similar architectural issues). Any comments should simply explain the business rules or decisions that led to that code. Maybe you are knowingly violating a best practice for your framework or language because following it would break business logic down the pipeline or something. This is the perfect time for a comment explaining that so a well-meaning junior developer doesn't refactor it six months from now.
And perhaps the interviewer should have been more explicit in their requirements. I have to admit I would never think to comment whiteboard code (and my production code would not contain comments like that).
I'm tired of companies asking me to code at their interviews.
I have 10 years experience with references.
I have code that I've built, deployed to production still running today.
I have cultivated my own clients, gathered requirements and built something that delivers business value.
Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Work that is small enough to be done in 1 week and big enough to deliver some value.
At the end of the week, you pay me wages and if you're not happy, you can not extend another week.
Isn't this a much better way to evaluate a good candidate?
>Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Work that is small enough to be done in 1 week and big enough to deliver some value.
Except now I have to jump through hoops with HR (let's just assume they'd be OK with this, which they almost certainly won't), get the contract in place, work with IT to get your environment set up, and bring you up to speed (so really I may get one full day of actual work)... just to realize that I don't want to hire you. Oh, and did I find you through a recruiter? Now I have to pay them a cut. Do I now get to run this little bureaucratic maze for all N candidates I'm looking at? You have become a very expensive interview across at least three departments and you're probably not worth it.
Sorry, but no. I do ask for some whiteboard coding, but it can be done in any language (or pseudo code) and I'm really only trying to tease out your thought process. For a junior or mid level position, yes; I am also trying to figure out if you can write a line of code. I'm also not sure how you're going to be able to get away from your current job for an entire week (I have literally never interviewed a candidate who wasn't fresh out of college who was unemployed at the time).
I agree that it can be a pain, but there aren't always better ways to measure your ability to take a problem and turn the solution into an algorithm.
> I'm tired of companies asking me to code at their interviews. I have 10 years experience
I just saw some code a candidate wrote (offline) who also had nearly this much experience in C#, and who apparently explicitly called out using C#6 and being a C#/.NET expert etc, etc.
Their code was written like it was 10 years old. Used array allocation (rather than collections). Time calculations like Convert.ToDouble(Convert.ToInt32(hourStr)/60)+Convet.ToInt32(minStr). Giant for loops where a simple LINQ query would do. It also failed to solve the problem.
10 years but hasn't learned anything new doesn't count for 10 years experience, in my opinion. That's why even "experienced" developers get coding questions.
(Btw, If the candidate hadn't explicitly called out their supposed expertise their use of old coding style could be overlooked; but since they had this on their resume, it either meant they were completely clueless about it, or simply lying. Either way, not a good start.)
* It can take up to a week just to get someone ramped up with access to things in many environments (setting up accounts, configuring dev environment, etc.) It's not free to create and disable a dev's access.
* Most places I've seen aren't set up to ramp someone up in a week. I think Pivotal Labs gives people a try for 3 week contracts, and they have a culture of ramping up new hires via pair programming in XP environment.
* You'd only be productive in an environment where you are already familiar with the tools they are using. If they're using Erlang, and you're coming from Java, you simply couldn't do much with Erlang in a week.
* Many places can't/won't put you to work without you passing a background check.
* Candidates who already have a job aren't likely to be in a position to take a week off to work for someone else.
>>> I have 10 years experience with references. I have code that I've built, deployed to production still running today. I have cultivated my own clients, gathered requirements and built something that delivers business value.
I don't really agree with this statement.
The truth is that there are a lot of folks with 10+ years of experience who wouldn't even pass as junior devs at many places. I've seen people with 10+ years of experience rolling out their own web frameworks (and definitely not good ones) every year or two, developers who have never written a single unit test (they don't see the point of it; also the software there was the most bug ridden product I have ever seen, surprise surprise). Their employers were not technical at all so were relatively happy with the results.
You wouldn't marry a person after knowing them for a day, just because someone said that he/she is a lovely person, would you? Same here with hiring.
But hiring is a 2-way street. If you completely disagree with the hiring procedure at a company, then you are probably not a good fit, and that's fine :)
Yes. Unless you're not the only person we're looking at hiring. We're not going to pay 10 people for a week and hire just one. We'd rather we get a sample by seeing you do some work on a whiteboard, and make some cuts right then and there.
In other words: yes, that's a better way for you to prove yourself. No, we don't have the resources for this approach.
But candidate evaluation is not an objective business, one company's perfect candidate might be complete trash at another firm. A company's interview process then is necessarily a reflection that company's character, culture, and attitude just as much as it is a process to find potential employees.
For example, your suggested hiring process of doing essentially an extended homework assignment might be great for a firm who doesn't care about "hiring the best", "building the elite team" or whatever, and instead wants to just assemble a ragtag team of misfits who trust and work well with each other to get things done.
Meanwhile, the Silicon Valley standard Googlesque hiring practice of using timed tree-inverting-list-o(log n)-optimized-talk-through-what-you-are-doing-(oh-90%-of-our-devs-use-your-oss-but-you-dont-remember-red-black-trees-so-fuck-off) algorithm questions to pinpoint the most academically smart candidate is perfect for companies who want to hire the "smartest programmer" to create a culture of intelligence oneupmanship to drive "innovation".
And unless one happens to be in a situation where one absolute needs a job right away, a candidate could really glean a lot about a potential company's direction and culture through just how they conduct their interview, and decide if this is, indeed, a place where one could do one's best for the company and continue with the application or apply elsewhere.
Out of curiosity, am I supposed to take an entire week of PTO in order to undergo such an interview process while currently employed? Because I can't really think of a single company I'd be willing to do that for.
That's great of you to offer as a candidate. However, from the interviewer's side, I can't ask candidates to do this. The people I want to hire are already busy. They don't have a whole week to devote to my interview process. Not even if I pay them for it.
I have better things to do than spend a few months of PTO interviewing with multiple companies. This won't fly with me, and I doubt it will fly with many people that are currently employed.
What I've seen suggested elsewhere is having publicly viewable code on github or the like - that would effectively be your coding resume and evidence of your ability.
I have done what you have proposed and it worked for my latest job (2 years and counting). I flat out refused a coding interview. I openly said, in my experience as a developer, great candidates fall through the cracks because they fail under a controlled environment which does not reflect the real world. They actually agreed with me.
I came in and did a one week trial, I brought in my own computer, they gave me access to a repository and a task list, told me to do what I could in the week and ask questions. Arguably, the experience was great. I was able to not only see if I wanted to work for this company, but what the people are like and what kind of problems I would be solving. It was a great way for the company to see if I got along with their team and if they liked me as a person.
Being a developer is half knowing how to code and the rest is whether or not you are a match personality wise for the company. You might be smart, but can you get along with others and work in different situations? A palindrome function or FizzBuzz during a coding interview can't tell you everything about a developer.
You know what else is great? I came onboard as a senior developer, after a year, I was running my own team of 2 other developers. Then something greater happened, I managed to change the way the company hires developers. We do the initial screening which is just a chat to see if their skillset matches the role, then we reduce the list down and bring them in to pair program with someone.
It works so well. Also what is cool is that the two developers we have brought on since I started were hired after great work performances during their week trial/interview.
Most good candidates wouldn't put up with that situation (1 week contracting) - also, years of experience can vary drastically. I recently interviewed a candidate with over 15 years of experience, predominantly in the backend, yet he didn't really have much experience scaling systems. He checked out in all ways until we drilled down into scaling issues.
> I'm tired of companies asking me to code at their interviews.
I get that. I am too.
I'm around 13+ years of experience. I have contributions to major open source projects, have given talks at a few conferences, write about my experiences on a blog... it doesn't matter. I've ran into a few interviewers who take a few minutes before the interview to skim my blog. Once I ran into someone who actually read a few posts and saw a talk I've given (always a boon).
If you really want to get a sense of how I think and what my code looks like it's out there in the open. Few people will bother to look.
Thankfully I've done enough interviews that there are some patterns I can share. Here's my unofficial guide to acing programming interviews:
1. Be honest. Don't put something on your resume because you think it will make you sound good. Yes the first screen is just keyword bingo... but at some point you might make it to a technical interview with someone who hates it when people do this and will make a point of asking you obscure questions about the ANSI C standard. If you've written a few small C programs or done a few tutorials you don't know C -- you've just used it. We tend to over-estimate our abilities which is why interviewers don't trust resumes. But if you want to get a job doing more C don't be afraid to put that out there.
2. Whiteboard coding is stupid. Instead learn logic and predicate calculus. Learn to take a written or oral description of a problem and work out what the constants are and write out an invariant or two. Use pseudo-code. Pretend you are a caricature of a white-haired professor teaching a class... write out the problem, go on tangents, explain your reasoning in steps. Write pseudo-code only if pressed.
3. Coding. Long before you start interviewing start a repository. Pick the language you're strongest in and work out the following problems: a function to detect a palindrome, a function to detect an anagram, a function to find the Nth number of the fibonacci sequence, a function to generate the list of numbers of the fibonacci sequence, and fizzbuzz. Try to come up with more than one solution to each problem. Re-type them out. Commit them to memory by rote practice. Work out problems on coding practice sites and add the most popular, boring ones to your repository. As you interview add questions you come across to your repository. Practice the most common ones. Commit them to memory. This is probably one of the most inane practices in hiring but it's also one of the easiest to overcome. 90% of interview coding problems are regurgitated Google searches for interview coding problems.
4. Prepare a list of questions to ask the interviewer before hand. At some point they're going to ask you if you have any questions for them. Grill them hard. What makes them excited about their job? What's the hardest problem they've had to overcome? What is their greatest failure? What did they do about it after? What is the most common problem they expect you to encounter in this role? Etc, etc. Know who you're talking to -- save this for the technical interviewer whom you'll likely be working alongside/for.
Before you know it you'll be done. You might get an email or a phone call letting you know whether you made it to the next round or whatever. You may not make it.
The important thing to remember: It's not personal, it's not pervasive, and it's not permanent. Remember that every person you encounter is living a life and story that is every bit as complex and deep as yours. There are a number of possible circumstances affecting your position that you have very little control over: it's not your fault if you don't ace every interview as you likely won't despite how hard you try. If you're persistent you'll eventually find something.
This reminds me of "smart and gets things done". Your idea is to test whether people can get things done. An interview can test how smart they are. Both are important.
I've seen web developers with years of experience delivering successful projects who turned out to be terrible programmers. In this situation, it is nearly always because they're not smart enough or because they have an anti-intellectual outlook on life ("I found this on stack overflow, it works, I don't understand it in depth but it's good enough for me" or "why would I know that, I never needed it") or often both. They were ok churning out 4 month projects one after the other or maintaining some business web site for years, but when you have them working on difficult and complex problems, their abilities turn out to be lacking and the brilliant kid with much less experience turns out to be much more useful.
From the perspective of a hiring company, say they have 5 final candidates. Suggesting a 1 week placement will not be practical either for most of the candidates (who still have their old job) or for the company (who has real work to do and not 5 weeks of on-boarding). Also to compare candidates they need them trying the same thing, not 5 different things.
I think a few hours discussing code is a small sacrifice for a fairer, more equitable interview process.
This is a decent solution if you are a freelancer or between jobs or family free and able to relocate short term (you could do it remote but job interviews if you actually work on premise should also be on premise to some extend). If you're currently holding another job it's pretty tough as you'd essentially have to take a week of vacation time or do all the work remote.
While I agree with your sentiment entirely I think you idea is faulty. Too much up-front cost for the employer and high risk for the employee if you need that job. I would like to see a short homework assignment which is then used to work with the interviewee. At least in some form (idea needs refinement).
"there will come a time when we are banging our heads against a problem and there is a deadline looming and we’re tired and people are pissed at us and money and jobs and reputations are all on the line."
Real response to this should be to ask how it got to the point where we are all stuck in a room with a deadline looming and our jobs are on the line if we don't come up with a whiteboard solution RIGHT NOW.
Sounds like this place has a management/expectations problem and I wouldn't want to work there in the first place.
Perhaps better named "How to win my coding interview."
Author goes into the specifics he personally expects from an interview. Since he's not positing these as universal standards (and rightly not) I'm not sure if this is relevant to anybody other than the people who intend to interview at dev mastery.
Last time I made interview rounds, about 50% of places gave whiteboard questions, 25% gave essentially the same questions but had me do them on a computer or screenshare rather than a whiteboard, and the rest had some kind of take home component that was usually larger than the whiteboard question but also more practical and relevant to my skill set. Obviously I prefer the last option, but even if you prefer to give whiteboard-style questions, why not at the very least allow them to complete it on their laptop in front of you if they so choose?
It seems incredibly arrogant to me that interviewers assume there is only one way to solve a problem, and that is by brainstorming on a whiteboard first. I don't feel comfortable standing up in front of the class to present a solution. I feel far, far, far less comfortable if it's a coding-related solution. I did significantly better, like pretty much 100% success rate on coding components when I could hit keys rather than display my chicken scratches on a whiteboard.| I move code around a lot as I prototype and it takes quite a bit of training for me to adjust to not having the option of restructuring as I code because the medium is a whiteboard or piece of paper. And every time I erase something my level of anxiety and nervousness just grows.
Probably one of the biggest mistakes developers make, is to treat coding interviews like they are standardized tests with a checklist of evaluation. They are not. They are like a date.
The other person is judging whether they want to work with you, more than anything else. No matter how good you are, you won't get into a long-term relationship (date) if you don't confirm to the (technical and social) beliefs (and biases) of your interviewer (date). The reverse is also true viz. no matter how mediocre you are, you'll get in, if you do.
First, it's not so clear in what sense "efficient" is actually a real requirement if this is a model answer.
If the average input is very small then the cost of compiling/interpreting the regex is going to dominate any modest run-time improvement over even an extremely naive implementation.
And if the inputs are very large then the probability of contradiction in the first few characters even is extremely high, so all the upfront normalization is a huge waste.
I'm having trouble imagining the typical data set where this would be an efficient implementation and where there even exist non-ridiculous inefficient implementations.
Second, doesn't using regexes kind of defeat the whole point of the Palindrome exercise from an evaluation perspective? If someone asked if me if they could use regexes in a coding interview for this question my response would be "good instinct. If you have no other way then go for it. But I was really hoping to see you work through implementing/debugging/commenting/testing an implementation without regexes."
> I'm not actually testing how well you write code on a whiteboard. I’m looking for something else
Even if you believe so, it's more likely than not you're not actually doing that. You WILL judge how well someone write code on a whiteboard. I've done that too, and it's surprisingly easy not to notice. You can't stop yourself from judging, maybe you can realize that your snap judgement mean jackshit and don't make decision based on that.
> While I don’t need a developer who can write code on a whiteboard, I do need a developer who can think on her feet, under pressure, in a room with others.
As someone who can't figure out if (9+1 === 10) is true or not under interview (true story, my mind just blanked out), I'd really love to have company who want "developer who think on her feet, under pressure" to put it on your job advertisement so we don't both waste our time.
> Let’s be honest, most developers don’t love having to write code as part of an interview process. Some have even threatened to quit the business over it.
I actually prefer a coding interview over an interview with an unprepared interviewer, who is making up questions on the fly and expects the exact answer he/she has in mind.
Am I the only one that is has been coding for years and don't expect people to know regex off the top of their head?
There are so many variants and keeping them straight between languages is a nightmare. Grep, egrep, POSIX, perl, python, php, javascript. They all have their idiosyncracies.
On the flip side of things, I might prefer to see a candidate come up with something like this as first stab rather than that 35-line mammoth of an isPalindrome() function in the article.
function isPalindrome(str) {
return (str.split("").reverse()).join("") == str;
}
Lot of people made tiny fortunes writing "How to interview" kind of self help books and blogs, just like this article they want people to believe that there is a formula to this madness and for a price you can know it. Smart people should realize that there are no shortcuts. You can't fill the void by pouring money and time into these products. The only way is to face the rejection and keep on focusing on the skill, solve real world problems, write code, learn to express ideas better, take internships.
One has to be good at programming, analytical skills, problem solving and communicating ideas. And after that a little research on how a company interviews should help. Even if someone reads all these books and cracks the interview, its very difficult to hold on to job with out the required skills.
Sometimes you can also solve whiteboard blackout issues with humor. I once was stuck because I couldn't quite figure out how to implement something (I think it was a peculiar sort). I proceeded to give up after reasoning through it for a bit and mumbled...well I can't quite get it now but let's move on since I'd probably never implement this and if I do I'd spend a lot more time on it and proceeded to add this line at the top of the whiteboard code.
import com.stackoverflow.* ;
One of the people in the room chuckled noticeably. I then went into a mini explanation of importing * vs. direct import (anticipating the obvious question) and was more or less free to use magic whenever I needed it :D
Honestly; the example answer is not good. If I was in a hiring position, I would at least talk to the person writing this and ask them to change their style.
The problem is that the answer is slightly over-engineered, over-commented, checks for input type, logs in a corner-case, looks-like-it-has-been-written-by-a-teacher-with-too-much-time-on-their-hands.
These are not problems in themselves but when you have a new person on the team and they write code like that, it may be inconsistent with what the rest of the team is doing / what the rest of code base looks like.
For comparison here is another way to test for a palindrome:
function isPalindrome(text) {
for (var i = 0; i <= text.length / 2; i++) {
if (text[i] != text[text.length - i - 1]) return false;
}
return true;
}
(Possibly add "normalization" in the beginning as they do in the article.)
> I guarantee you this, there will come a time when we are banging our heads against a problem and there is a deadline looming and we’re tired and people are pissed at us and money and jobs and reputations are all on the line. When that time comes, we’re going to have to get into a boardroom, hop on a whiteboard, and figure things out. Fast.
False, that has never happened in decades of work in my experience. All "breakthroughs" I've had came to me in the shower or other solitary place. For most people, creativity does not spring from a gun to your head in a crowded room.
The rest of the piece falls apart from there.
> Some interviewers will ask you to code an implementation of a particular algorithm. Personally, I think that’s just a giant waste of time. It’s far more important to me that you understand which algorithm to apply to which problem. You can always Google the implementation.
> It’s not unreasonable to expect that you know the basics of RegEx
So that's a fairly arbitrary distinction. Regex has a famously terse syntax. Maybe in some jobs it's used frequently, and in those cases I could expect someone to recall the basics. But it's been my experience that regex comes up just infrequently enough that I never recall the exact expression, and then spend more time googling a regex tutorial (even more if it includes groups or look behind) to refresh myself than I would have if I just had a strings library that just had .StripWhitespace() .Contains() .Startswith() .IsItAValidPhoneNumber etc etc functions.
The author have a list of secret good questions, and that is not helping anyone. He expects the candidate to think loud and be explicit, but are himself very implicit in his requirements. What I consider production code is without a doubt different from what he things is production code.
> Your code should be commented.
Then put this requirement, because judging from the example, the authors expectations, is what I fail students and junior devs for. Comments are complementary and explain things like "the why" ("pad to multiple of 256, otherwise libX will hang"). Don't expect people to automatically know your implicit requirements, it's a recipie for disaster.
> You should have error handling or at least logging.
Again, put this in the requirements. Some environments need no error handling, because the error handling is external. And don't get me started on logging. Yes it's nice in a debug situation, but in many high volume production systems you have engineers with the sole responsibility of creating a logging system that impact performance as little as possible.
> You should have a test harness.
If you say so, otherwise I'm not going to make one. Be explicit.
> Runs fast.
> Doesn’t take up more memory than it needs to.
> Is stable and easy to maintain.
1. and 2. are secondary. 3. is king, unless you have empirical evidence that warrant 1. and 2. This is something many developers struggle with, including the auther by the sound of it.
> RegEx
No, just no - the imfamous quote is "I have a problem, let's use a RegEx. Now you have two problems" and it's true 98% of the time, including testing if a string is a palindrome. Besides, regular expressions cannot identify palindromes - this is first year CS stuff. I'm well aware that some implementations allow back references, thus they are not really regular expressions but leaning on CFGs. For this particular problem, reversing the string and then compare is by far the most readable and understandable solution.
> For senior devs, I want an optimal solution, clean, maintainable code, error handling, comments, a full suite of tests. And for bonus points I want you to flag any of your assumptions in the comments.
What is optimal? With regard to execution time? Memory usage? Maintainability? Program size? What kind of error handling?
[+] [-] sundvor|9 years ago|reply
> Your code should be commented
Sure.. but:
Do we really need to explain that stringToTest means string to test? I for one find such low level comments almost completely redundant. I prefer strong variable naming and other ways of creating clean code to littering the code with comments that the code expresses naturally.Comments should IMHO be reserved for explaining special complexities, any particular gotchyas, etc.
[+] [-] bhntr3|9 years ago|reply
This article takes such an expert tone. But it's just opinion. For me, that comment would be a red flag.
He also says to write the most efficient code possible. Then doesn't. See the comments at the end of the post.
Overall, I think what this shows is that as an interviewee, the best thing you can do is try to get an idea of the interviewer's expectations as quickly as possible. People love saying here that it's not a test scenario. But it is. The interviewer has a preconceived notion of what you should and shouldn't do and you need to meet that notion.
As an interviewer, recognize it's easy to think you're smarter than the other person when you already know the answer. Don't be pompous. Don't assume you know better. Try to set expectations very clearly. Try to really listen to the interviewee and understand why they're making the choices they are.
Personally, I would be frustrated by this interview. I feel like this article is a thin justification of a lot of standard interview practices that don't actually work. It and his further comments take a condescending tone that makes me worry he wouldn't be open to approaches he hasn't seen.
Reminds me of a time an interviewer basically gave up on an interview because I told him there were O(N) algorithms for sorting strings with a fixed alphabet. He said "Best case sorting is O(nlogn)" and I could hear in his voice that for him the interview was over. I knew what radix sort was but in the moment I couldn't actually explain or implement it without looking it up and things just went downhill from there.
[+] [-] fenomas|9 years ago|reply
[+] [-] danappelxx|9 years ago|reply
[+] [-] billsparks|9 years ago|reply
[+] [-] meowface|9 years ago|reply
[+] [-] dclowd9901|9 years ago|reply
[+] [-] deciplex|9 years ago|reply
[+] [-] wp1|9 years ago|reply
[+] [-] pc86|9 years ago|reply
From a technical standpoint you should read uncommented code and more often than not be able to tell exactly what it does (barring a lot of poorly named methods or similar architectural issues). Any comments should simply explain the business rules or decisions that led to that code. Maybe you are knowingly violating a best practice for your framework or language because following it would break business logic down the pipeline or something. This is the perfect time for a comment explaining that so a well-meaning junior developer doesn't refactor it six months from now.
[+] [-] EpicEng|9 years ago|reply
[+] [-] kayman|9 years ago|reply
I have 10 years experience with references. I have code that I've built, deployed to production still running today. I have cultivated my own clients, gathered requirements and built something that delivers business value.
Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Work that is small enough to be done in 1 week and big enough to deliver some value.
At the end of the week, you pay me wages and if you're not happy, you can not extend another week.
Isn't this a much better way to evaluate a good candidate?
[+] [-] EpicEng|9 years ago|reply
Except now I have to jump through hoops with HR (let's just assume they'd be OK with this, which they almost certainly won't), get the contract in place, work with IT to get your environment set up, and bring you up to speed (so really I may get one full day of actual work)... just to realize that I don't want to hire you. Oh, and did I find you through a recruiter? Now I have to pay them a cut. Do I now get to run this little bureaucratic maze for all N candidates I'm looking at? You have become a very expensive interview across at least three departments and you're probably not worth it.
Sorry, but no. I do ask for some whiteboard coding, but it can be done in any language (or pseudo code) and I'm really only trying to tease out your thought process. For a junior or mid level position, yes; I am also trying to figure out if you can write a line of code. I'm also not sure how you're going to be able to get away from your current job for an entire week (I have literally never interviewed a candidate who wasn't fresh out of college who was unemployed at the time).
I agree that it can be a pain, but there aren't always better ways to measure your ability to take a problem and turn the solution into an algorithm.
[+] [-] gregmac|9 years ago|reply
I just saw some code a candidate wrote (offline) who also had nearly this much experience in C#, and who apparently explicitly called out using C#6 and being a C#/.NET expert etc, etc.
Their code was written like it was 10 years old. Used array allocation (rather than collections). Time calculations like Convert.ToDouble(Convert.ToInt32(hourStr)/60)+Convet.ToInt32(minStr). Giant for loops where a simple LINQ query would do. It also failed to solve the problem.
10 years but hasn't learned anything new doesn't count for 10 years experience, in my opinion. That's why even "experienced" developers get coding questions.
(Btw, If the candidate hadn't explicitly called out their supposed expertise their use of old coding style could be overlooked; but since they had this on their resume, it either meant they were completely clueless about it, or simply lying. Either way, not a good start.)
[+] [-] amorphid|9 years ago|reply
* It can take up to a week just to get someone ramped up with access to things in many environments (setting up accounts, configuring dev environment, etc.) It's not free to create and disable a dev's access.
* Most places I've seen aren't set up to ramp someone up in a week. I think Pivotal Labs gives people a try for 3 week contracts, and they have a culture of ramping up new hires via pair programming in XP environment.
* You'd only be productive in an environment where you are already familiar with the tools they are using. If they're using Erlang, and you're coming from Java, you simply couldn't do much with Erlang in a week.
* Many places can't/won't put you to work without you passing a background check.
* Candidates who already have a job aren't likely to be in a position to take a week off to work for someone else.
[+] [-] gedrap|9 years ago|reply
I don't really agree with this statement.
The truth is that there are a lot of folks with 10+ years of experience who wouldn't even pass as junior devs at many places. I've seen people with 10+ years of experience rolling out their own web frameworks (and definitely not good ones) every year or two, developers who have never written a single unit test (they don't see the point of it; also the software there was the most bug ridden product I have ever seen, surprise surprise). Their employers were not technical at all so were relatively happy with the results.
You wouldn't marry a person after knowing them for a day, just because someone said that he/she is a lovely person, would you? Same here with hiring.
But hiring is a 2-way street. If you completely disagree with the hiring procedure at a company, then you are probably not a good fit, and that's fine :)
[+] [-] richforrester|9 years ago|reply
In other words: yes, that's a better way for you to prove yourself. No, we don't have the resources for this approach.
[+] [-] ffn|9 years ago|reply
But candidate evaluation is not an objective business, one company's perfect candidate might be complete trash at another firm. A company's interview process then is necessarily a reflection that company's character, culture, and attitude just as much as it is a process to find potential employees.
For example, your suggested hiring process of doing essentially an extended homework assignment might be great for a firm who doesn't care about "hiring the best", "building the elite team" or whatever, and instead wants to just assemble a ragtag team of misfits who trust and work well with each other to get things done.
Meanwhile, the Silicon Valley standard Googlesque hiring practice of using timed tree-inverting-list-o(log n)-optimized-talk-through-what-you-are-doing-(oh-90%-of-our-devs-use-your-oss-but-you-dont-remember-red-black-trees-so-fuck-off) algorithm questions to pinpoint the most academically smart candidate is perfect for companies who want to hire the "smartest programmer" to create a culture of intelligence oneupmanship to drive "innovation".
And unless one happens to be in a situation where one absolute needs a job right away, a candidate could really glean a lot about a potential company's direction and culture through just how they conduct their interview, and decide if this is, indeed, a place where one could do one's best for the company and continue with the application or apply elsewhere.
[+] [-] nilkn|9 years ago|reply
[+] [-] modeless|9 years ago|reply
[+] [-] ori_b|9 years ago|reply
[+] [-] redcap|9 years ago|reply
[+] [-] DigitalSea|9 years ago|reply
I came in and did a one week trial, I brought in my own computer, they gave me access to a repository and a task list, told me to do what I could in the week and ask questions. Arguably, the experience was great. I was able to not only see if I wanted to work for this company, but what the people are like and what kind of problems I would be solving. It was a great way for the company to see if I got along with their team and if they liked me as a person.
Being a developer is half knowing how to code and the rest is whether or not you are a match personality wise for the company. You might be smart, but can you get along with others and work in different situations? A palindrome function or FizzBuzz during a coding interview can't tell you everything about a developer.
You know what else is great? I came onboard as a senior developer, after a year, I was running my own team of 2 other developers. Then something greater happened, I managed to change the way the company hires developers. We do the initial screening which is just a chat to see if their skillset matches the role, then we reduce the list down and bring them in to pair program with someone.
It works so well. Also what is cool is that the two developers we have brought on since I started were hired after great work performances during their week trial/interview.
[+] [-] Bahamut|9 years ago|reply
[+] [-] agentultra|9 years ago|reply
I get that. I am too.
I'm around 13+ years of experience. I have contributions to major open source projects, have given talks at a few conferences, write about my experiences on a blog... it doesn't matter. I've ran into a few interviewers who take a few minutes before the interview to skim my blog. Once I ran into someone who actually read a few posts and saw a talk I've given (always a boon).
If you really want to get a sense of how I think and what my code looks like it's out there in the open. Few people will bother to look.
Thankfully I've done enough interviews that there are some patterns I can share. Here's my unofficial guide to acing programming interviews:
1. Be honest. Don't put something on your resume because you think it will make you sound good. Yes the first screen is just keyword bingo... but at some point you might make it to a technical interview with someone who hates it when people do this and will make a point of asking you obscure questions about the ANSI C standard. If you've written a few small C programs or done a few tutorials you don't know C -- you've just used it. We tend to over-estimate our abilities which is why interviewers don't trust resumes. But if you want to get a job doing more C don't be afraid to put that out there.
2. Whiteboard coding is stupid. Instead learn logic and predicate calculus. Learn to take a written or oral description of a problem and work out what the constants are and write out an invariant or two. Use pseudo-code. Pretend you are a caricature of a white-haired professor teaching a class... write out the problem, go on tangents, explain your reasoning in steps. Write pseudo-code only if pressed.
3. Coding. Long before you start interviewing start a repository. Pick the language you're strongest in and work out the following problems: a function to detect a palindrome, a function to detect an anagram, a function to find the Nth number of the fibonacci sequence, a function to generate the list of numbers of the fibonacci sequence, and fizzbuzz. Try to come up with more than one solution to each problem. Re-type them out. Commit them to memory by rote practice. Work out problems on coding practice sites and add the most popular, boring ones to your repository. As you interview add questions you come across to your repository. Practice the most common ones. Commit them to memory. This is probably one of the most inane practices in hiring but it's also one of the easiest to overcome. 90% of interview coding problems are regurgitated Google searches for interview coding problems.
4. Prepare a list of questions to ask the interviewer before hand. At some point they're going to ask you if you have any questions for them. Grill them hard. What makes them excited about their job? What's the hardest problem they've had to overcome? What is their greatest failure? What did they do about it after? What is the most common problem they expect you to encounter in this role? Etc, etc. Know who you're talking to -- save this for the technical interviewer whom you'll likely be working alongside/for.
Before you know it you'll be done. You might get an email or a phone call letting you know whether you made it to the next round or whatever. You may not make it.
The important thing to remember: It's not personal, it's not pervasive, and it's not permanent. Remember that every person you encounter is living a life and story that is every bit as complex and deep as yours. There are a number of possible circumstances affecting your position that you have very little control over: it's not your fault if you don't ace every interview as you likely won't despite how hard you try. If you're persistent you'll eventually find something.
Happy hacking.
[+] [-] jimbokun|9 years ago|reply
[+] [-] gimpster|9 years ago|reply
I've seen web developers with years of experience delivering successful projects who turned out to be terrible programmers. In this situation, it is nearly always because they're not smart enough or because they have an anti-intellectual outlook on life ("I found this on stack overflow, it works, I don't understand it in depth but it's good enough for me" or "why would I know that, I never needed it") or often both. They were ok churning out 4 month projects one after the other or maintaining some business web site for years, but when you have them working on difficult and complex problems, their abilities turn out to be lacking and the brilliant kid with much less experience turns out to be much more useful.
[+] [-] grey-area|9 years ago|reply
I think a few hours discussing code is a small sacrifice for a fairer, more equitable interview process.
[+] [-] kriro|9 years ago|reply
[+] [-] BinaryIdiot|9 years ago|reply
[+] [-] allsystemsgo|9 years ago|reply
[+] [-] krisgenre|9 years ago|reply
[+] [-] brooklyndavs|9 years ago|reply
Real response to this should be to ask how it got to the point where we are all stuck in a room with a deadline looming and our jobs are on the line if we don't come up with a whiteboard solution RIGHT NOW.
Sounds like this place has a management/expectations problem and I wouldn't want to work there in the first place.
[+] [-] alexandercrohde|9 years ago|reply
Author goes into the specifics he personally expects from an interview. Since he's not positing these as universal standards (and rightly not) I'm not sure if this is relevant to anybody other than the people who intend to interview at dev mastery.
[+] [-] krisdol|9 years ago|reply
It seems incredibly arrogant to me that interviewers assume there is only one way to solve a problem, and that is by brainstorming on a whiteboard first. I don't feel comfortable standing up in front of the class to present a solution. I feel far, far, far less comfortable if it's a coding-related solution. I did significantly better, like pretty much 100% success rate on coding components when I could hit keys rather than display my chicken scratches on a whiteboard.| I move code around a lot as I prototype and it takes quite a bit of training for me to adjust to not having the option of restructuring as I code because the medium is a whiteboard or piece of paper. And every time I erase something my level of anxiety and nervousness just grows.
[+] [-] soham|9 years ago|reply
Probably one of the biggest mistakes developers make, is to treat coding interviews like they are standardized tests with a checklist of evaluation. They are not. They are like a date.
The other person is judging whether they want to work with you, more than anything else. No matter how good you are, you won't get into a long-term relationship (date) if you don't confirm to the (technical and social) beliefs (and biases) of your interviewer (date). The reverse is also true viz. no matter how mediocre you are, you'll get in, if you do.
So, do everything what the author says, but you'll progress faster if you keep your mindset grounded. See this: https://www.youtube.com/watch?v=v1WiCGq-PcY
[+] [-] edocecrous|9 years ago|reply
First, it's not so clear in what sense "efficient" is actually a real requirement if this is a model answer.
If the average input is very small then the cost of compiling/interpreting the regex is going to dominate any modest run-time improvement over even an extremely naive implementation.
And if the inputs are very large then the probability of contradiction in the first few characters even is extremely high, so all the upfront normalization is a huge waste.
I'm having trouble imagining the typical data set where this would be an efficient implementation and where there even exist non-ridiculous inefficient implementations.
Second, doesn't using regexes kind of defeat the whole point of the Palindrome exercise from an evaluation perspective? If someone asked if me if they could use regexes in a coding interview for this question my response would be "good instinct. If you have no other way then go for it. But I was really hoping to see you work through implementing/debugging/commenting/testing an implementation without regexes."
[+] [-] NhanH|9 years ago|reply
Even if you believe so, it's more likely than not you're not actually doing that. You WILL judge how well someone write code on a whiteboard. I've done that too, and it's surprisingly easy not to notice. You can't stop yourself from judging, maybe you can realize that your snap judgement mean jackshit and don't make decision based on that.
> While I don’t need a developer who can write code on a whiteboard, I do need a developer who can think on her feet, under pressure, in a room with others.
As someone who can't figure out if (9+1 === 10) is true or not under interview (true story, my mind just blanked out), I'd really love to have company who want "developer who think on her feet, under pressure" to put it on your job advertisement so we don't both waste our time.
[+] [-] kinkdr|9 years ago|reply
I actually prefer a coding interview over an interview with an unprepared interviewer, who is making up questions on the fly and expects the exact answer he/she has in mind.
[+] [-] jtchang|9 years ago|reply
There are so many variants and keeping them straight between languages is a nightmare. Grep, egrep, POSIX, perl, python, php, javascript. They all have their idiosyncracies.
[+] [-] scishop|9 years ago|reply
[+] [-] yanilkr|9 years ago|reply
One has to be good at programming, analytical skills, problem solving and communicating ideas. And after that a little research on how a company interviews should help. Even if someone reads all these books and cracks the interview, its very difficult to hold on to job with out the required skills.
[+] [-] FigmentEngine|9 years ago|reply
kill me now. are you testing for insight or implementation correctness?
a whiteboard is a place to draw a diagram, not code. see how they visualize and reason about strings would be better
[+] [-] kriro|9 years ago|reply
import com.stackoverflow.* ;
One of the people in the room chuckled noticeably. I then went into a mini explanation of importing * vs. direct import (anticipating the obvious question) and was more or less free to use magic whenever I needed it :D
[+] [-] chvid|9 years ago|reply
The problem is that the answer is slightly over-engineered, over-commented, checks for input type, logs in a corner-case, looks-like-it-has-been-written-by-a-teacher-with-too-much-time-on-their-hands.
These are not problems in themselves but when you have a new person on the team and they write code like that, it may be inconsistent with what the rest of the team is doing / what the rest of code base looks like.
For comparison here is another way to test for a palindrome:
(Possibly add "normalization" in the beginning as they do in the article.)[+] [-] mixmastamyk|9 years ago|reply
False, that has never happened in decades of work in my experience. All "breakthroughs" I've had came to me in the shower or other solitary place. For most people, creativity does not spring from a gun to your head in a crowded room. The rest of the piece falls apart from there.
[+] [-] dcw303|9 years ago|reply
> It’s not unreasonable to expect that you know the basics of RegEx
So that's a fairly arbitrary distinction. Regex has a famously terse syntax. Maybe in some jobs it's used frequently, and in those cases I could expect someone to recall the basics. But it's been my experience that regex comes up just infrequently enough that I never recall the exact expression, and then spend more time googling a regex tutorial (even more if it includes groups or look behind) to refresh myself than I would have if I just had a strings library that just had .StripWhitespace() .Contains() .Startswith() .IsItAValidPhoneNumber etc etc functions.
[+] [-] hvidgaard|9 years ago|reply
> Your code should be commented.
Then put this requirement, because judging from the example, the authors expectations, is what I fail students and junior devs for. Comments are complementary and explain things like "the why" ("pad to multiple of 256, otherwise libX will hang"). Don't expect people to automatically know your implicit requirements, it's a recipie for disaster.
> You should have error handling or at least logging.
Again, put this in the requirements. Some environments need no error handling, because the error handling is external. And don't get me started on logging. Yes it's nice in a debug situation, but in many high volume production systems you have engineers with the sole responsibility of creating a logging system that impact performance as little as possible.
> You should have a test harness.
If you say so, otherwise I'm not going to make one. Be explicit.
> Runs fast. > Doesn’t take up more memory than it needs to. > Is stable and easy to maintain.
1. and 2. are secondary. 3. is king, unless you have empirical evidence that warrant 1. and 2. This is something many developers struggle with, including the auther by the sound of it.
> RegEx
No, just no - the imfamous quote is "I have a problem, let's use a RegEx. Now you have two problems" and it's true 98% of the time, including testing if a string is a palindrome. Besides, regular expressions cannot identify palindromes - this is first year CS stuff. I'm well aware that some implementations allow back references, thus they are not really regular expressions but leaning on CFGs. For this particular problem, reversing the string and then compare is by far the most readable and understandable solution.
> For senior devs, I want an optimal solution, clean, maintainable code, error handling, comments, a full suite of tests. And for bonus points I want you to flag any of your assumptions in the comments.
What is optimal? With regard to execution time? Memory usage? Maintainability? Program size? What kind of error handling?
[+] [-] revetkn|9 years ago|reply
Really?
2. "replace(/[^a-z0–9]/ig, '');"
If I were interviewing and a candidate did this I would ask if he/she knows what i18n is
[+] [-] Swizec|9 years ago|reply
If you're writing in a shared text editor then sure.
And isn't all the talking you do already commemts enough?
Edit: I'm bad at reading comprehension on a mobile screen. The tests and comments bit is in a different section.