There are people out there (not you, obviously) who can talk their way into an interview for programming jobs that they simply can't perform. We're talking about no skills whatsoever, apart from the ability to sling buzzwords around enough to impress a recruiter. God only knows how they get their degrees, but they have them.
Simple, straightforward programming questions that aren't already on the Web are like an immune system response to these non-programmers who interview for programming jobs. I'm truly sorry when a real programmer feels insulted when I ask them something like "given the starting and ending times of two calendar appointments, write an expression that's true if they conflict", because it's not their fault that there are people out there who will struggle for 20 minutes thinking about how to solve it before trying something like a doubly-nested loop over all the milliseconds in both intervals, testing for equality.
I am not making this up. It's a real problem. if you can program a digital computer, you have nothing to fear from a good coding interview. And if you have a better way to reliably identify the non-programmers, I'd love to hear it.
So, anymore I don't have much of a problem with simple coding questions to filter out total non-programmers (fizzbuzz, your calendar problem, etc.).
But the whole stand on one foot and implement a red-black tree in bash script on the whiteboard while I peck at my smartphone and sigh every time you pause to think has got to freaking stop.
This is a much bigger deal to me than difficult algorithm questions. Shitty interviewers give shitty interviews, regardless of what kinds of questions they ask.
The worst interview I ever had was like this. The guy showed up late, told me he forgot he even had an interview, gave me a strange question with little detail, and told me to start coding. Then ignored me for an hour while he typed on his laptop. Even when I directly asked for feedback to make sure I was solving the problem he asked and not a misunderstanding, he gave me basically no feedback. I've had interviews that I bombed before, but this was the first and only time that I felt like I bombed an interview and it was utterly not my fault. It was also the only time I've had a bad interview that actually ruined the rest of the day for me because it threw me off so much.
The only good answer to that is "I can't imagine why I'd ever need to do that, and if I had to anyway, I'd use a 3-2 tree instead because it's almost as good and nobody ever gets red-black trees right the first time."
"I am not making this up. It's a real problem. "
No, it's a survival bias. You have no way of knowing how they perform, unless you hire them, but you don't hire them, because they can't pass your interview process.
There are many reason why someone capable and experienced would "fail" an interview like that. But ultimately it just doesn't test for skills related to software development.
Be serious.
Experience taught me not to be insulted about those questions. They guarantee all collegues will be able to pass them.
http://www.geeksforgeeks.org/given-n-appointments-find-confl...
It requires the simple comparison you mentioned, but is far more complex to come up with an efficient algorithm. Needless to say, I totally failed that one. Never heard of an interval tree until I looked it up after the interview. It took me just a moment to look it up with my awesome google skills and if I had to actually use that, I could copy paste that code in an instant :-) Even better, I could find a library and not even have to copy paste.
One time I was working on a language translator at my actual job. I was storing formulas for excel columns in a database and they had to be translated from their representation in the database to the excel formula language. It turns out that the columns had dependencies on one another and they had to be processed in dependency order. This required something called a topological sort. Again, something I had never heard of before I encountered this problem at work (I do have a CS degree). But I found the solution by a quick google search and employed a library that was already in use in my client's software that contained that algorithm.
That's the actual skill that's valuable: translating your requirements into a bunch of search terms that will quickly give you the name of the algorithm you need. (and obviously building the inputs / working with the outputs of that algorithm). Yeah, I guess if you already have all of those in your in your brain already you might save some time, but what about when you encounter a problem you don't know how to solve?
A natural assumption is that two appointments conflict if their times overlap.
The example instance of the problem gives this as input:
> Input: appointments[] = { {1, 5} {3, 7}, {2, 6}, {10, 15}, {5, 6}, {4, 100}}
The problem spoke of "appointments in array" and this is an array, so apparently {1, 5} {3, 7}, {2, 6}, {10, 15}, {5, 6}, {4, 100} are the appointments themselves. So we have 6 appointments.
So I'd guess that {1, 5} means an appointment that starts at time 1 and ends at time 5. That {4, 100} concerns me, though...if the numbers are times there is no obvious unit of time for which all of these appointments make sense.
They give this as the expected output for the above input:
Output: Following are conflicting intervals
[3,7] Conflicts with [1,5]
[2,6] Conflicts with [1,5]
[5,6] Conflicts with [3,7]
[4,100] Conflicts with [1,5]
So that means my interpretation of the notation {x, y} on input meaning an appointment from time x through time y is not right.
Another idea is that {x, y} means person x and person y have an appointment together, and two appointments conflict if the same person is involved in both. Nope...that doesn't give the sample output either.
OK...maybe the sample output is wrong. So now I grabbed their code and compiled it on my Mac and ran it. It produced this output:
Following are conflicting intervals
[3,7] Conflicts with [-1960454340,32767]
[2,6] Conflicts with [-1960454340,32767]
[10,15] Conflicts with [-1960454340,32767]
[5,6] Conflicts with [-1960454340,32767]
[4,100] Conflicts with [-1960454340,32767]
Anyway, I see that there is a function in there to determine if a pair of appointments overlap:
// A utility function to check if given two intervals overlap
bool doOVerlap(Interval i1, Interval i2)
{
if (i1.low < i2.high && i2.low < i1.high)
return true;
return false;
}
Putting a printout in doOVerlap to see how it is getting used:
// A utility function to check if given two intervals overlap
bool doOVerlap(Interval i1, Interval i2)
{
cout << "check " << i1.low << "," << i1.high
<< " against " << i2.low << "," << i2.high << "\n";
if (i1.low < i2.high && i2.low < i1.high)
return true;
return false;
}
Following are conflicting intervals
check 1,5 against 3,7
[3,7] Conflicts with [1,5]
check 1,5 against 2,6
[2,6] Conflicts with [1,5]
check 1,5 against 10,15
check 3,7 against 10,15
check 1,5 against 5,6
check 3,7 against 5,6
[5,6] Conflicts with [3,7]
check 1,5 against 4,100
[4,100] Conflicts with [1,5]
I'll leave it to someone more curious than I to figure out what is wrong with their "solution".
That's what I was looking for as a hiring manager.
I think the point here is more about how experienced programmers track records are not enough to prove they can do the work sometimes.
Using whiteboard questions to prove ones competency can backfire as well in cases candidates are not really prepared but learned to game the system.
Tell me you're kidding... that this is just a contrived example. please.
The time zones in calendar appointments can change, if there's a switch between standard time and summer time.
You need to know when is the hour set back by 1 hour, and in that case sometimes the answer is ,,maybe''.
I was working at a small phone company, and handling the switch between time zones were not just non-trivial, but they caused hard-to find bugs, as these things happen only twice a year.
Once they've got the comparison out of the way, you can bring up those issues and see where they grow their implementation.
I've been reading about this on HN and reddit for years now. This last December, I was promoted high enough, that I could design the entire interview process (with executive help) for my teams. Which was important, I very much need to hire some people.
So, keeping posts like this in mind, I designed as follows:
Phone Interview - We talk about you, the company, etc. Then a few technical questions. Do you know certain things about js that make me think you are genuinely familiar with the language (as opposed to just jQuery)? Do you know certain things about sql that make me think you are genuinely familiar with the technology (as opposed to just using a table designer)?
Assessment Test - Do a quick crud app, that will require some thought behind how to query the data. Make a point when talking to the prospective applicant that the code will be read by the team members they'll be working with, so while you can do the test quickly, please spend enough time on it that we can talk about the code, your choices, etc going into the technical interview. Ie) don't just link together 3rd party plugins.
Actual Interview - Interview with leads, interview with actual team members. Offer both use of Visual Studio / SSMS / IDE of choice or whiteboard. Ask questions about technology in general. Ask the applicant to explain how he'd design out a new feature. Change the feature spec, so that there's a little bit of a hard problem. Have to populate a tree from flat sql data, or aggregate data from a service, or some other not-quite-an-algorithm question.
The RESULTS?
Recruiters figure out what questions you are most likely to ask during the phone interview, and school the candidates.
The assessment test? No one bothers, everyone just hands in the simplest 3rd party libraries plumbed together with shitty code. Was the question select top per group? How about top 1 *? The really good devs shine through here, but a huge percentage don't even bother.
Actual Interview? No one uses IDE / SSMS. All of them choose whiteboard. The ones who genuinely know how to code, have no problem answering, and would be fine answering algorithm questions straight out. The ones who can't, get confused somewhere or other. They try to implement hacks around the problem (I'd have the dba do it), then fail to actually solve the question.
So In Short? I completely understand where this guy is coming from. But I also think, that at this point, I'm so tired of interviewing people who clearly don't care about their craft, that I want to start asking nothing other than algorithm questions... because the guy or gal that actually answers them will actually care about their craft. And at least with algo questions, I can change the question easily, and frequently. Coming up with real code problems, and good probing questions is much harder, particularly if they're going to have a short shelf-life before recruiters start training their candidates with answers.
sensible: given the problem statement discuss your initial choice of algorithms and datastructures. This probably covers 80% of tech jobs out there. And you easily dig deeper with big-O and related here. You should have a very good idea if the candidate is clueless or not after this.
other: given a datastructure and algorithm, implement it. This makes sense for a minority subset of jobs/devs.
This can be entirely appropriate for most jobs/devs, depending on the datastructure/algorithm. One of the guys I work with sometimes asks people to implement mergesort. I was suspicious of this question at first but it's been quite good at weeding out mediocre candidates. Mediocre candidates will write broken code all over the board, and more telling, they won't understand why it's broken even when you point it out. Good candidates will generally make mistakes (because no one has mergesort code memorized and coding on a whiteboard is frankly tough), but they'll recognize them, typically on their own and always with pointers, and they'll be able to explain the issue and how to fix it once they see it.
There's no trick to this question. There's no riddle, no "gotcha", and it's not a hard algorithm to understand or code. Just show that you can write minimally complex code and walk through it. It's like fizzbuzz but you can't memorize it.
It sounds to me like you just had a bad crop of people, most of whom wouldn't have passed an "algorithms" style interview either.
Yes, that's most certainly an issue.
The rest is understandable. Whiteboard, cause you want design and it will be faster to point, talk, erase and change. Unless you do some deep tech, people who can do general algorithms will be able to adapt fairly quickly.
Who wants to hire an architecture astronaut who hears "design a new ORM system" when someone says "build an app to update customer addresses"?
I'm not saying whiteboard interviews are the right way to interview, but in my experience you can't trust people's judgment about themselves and their skills. You need an interview that is equally fair to the person that will exaggerate their past successes to the people that are more reserved or the people that don't have much experience yet.
Okay, but having them solve coding problems on the whiteboard doesn't provide any evidence of that either.
If they say they delivered projects on time with "great maintainable code," ask them what makes code maintainable, have them provide examples (using pseudocode) and talk through each one. Ask them about a time when they had to sacrifice maintainability for time, application performance or user experience. Ask them what they learned from the ordeal.
In my opinion you're going to be much more likely to accurately judge their expertise level based on their answers to such questions. The reason is simple: one can memorize whiteboard questions prior to the interview. They can't, however, bullshit their way through questions that are experience-based - and if they do, well, you should hire them immediately because you just found yourself a great salesperson!
Isn't this is the case for every job applicant in every industry? You look at the evidence available of someone's work history and make a judgment call.
Unless the candidate is fresh out of uni, any qualified candidate with experience should be able to provide at least several solid contacts at previous employers from which to obtain this information.
Can find out a lot about a person in a one/two hour pair coding interview.
It's troubling to know that engineers with many years of experience still have difficulties. Every job listing I see asks for someone with 6+ years, and the only feedback I ever get is "we're looking for someone with more experience, try again in 4 years."
Tech companies should really just hire for soft skills. Screw tech interviews completely. A lot of this stuff can be taught. Maybe just give people a contracted trial period. Companies are spending incredible sums of money just searching for candidates that meet their exact "needs." In reality, they're not going to know how well someone performs until they actually work with them. Stop wasting your employees' time by having them grade pointless coding quizzes. Use that time instead to train someone who's a good communicator, is passionate about the product, is creative and eager to learn, and wants build something your customers will love. Even if that doesn't work out, at least you didn't waste everyone's time.
Mind you, as someone else mentioned, some folks spend 6 years in the industry and don't gain the knowledge and experience you already have, but that doesn't mean you've attained 6 years worth of knowledge and experience.
Most companies don't need the best of the best of the best. They can save a lot of time and money by hiring someone who, with just a little bit of investigation, they know is going to come in with some decent technical skills, and can quickly learn to become a valuable asset.
One thing I unfortunately take from that period is a bitterness toward people who complain about whiteboard interviews, because I was never even given a chance to do coding problems. I understand that many of the complaints are rational (especially when the interview skills are totally misaligned from the on-the-job skills), but since I was stuck before that phase, I'd emotionally rather have less early filtering and more code-based interviews.
If I actually came into a position of hiring power, I'd take time to reevaluate and separate myself from the question, but that's the instinctual response my history has brought me to.
Now it is a couple of years later and I actually was able to land a job thanks to my new skills (not at Amazon though). But what's much more important: I found a new hobby that will keep me entertained for many more years.
Only one company denied me the request and I didn't go ahead for them. Their loss.
I've also found having a github profile where you've files issues on projects and made a couple of commits really helps the chances. It gives more data than a resume.
At one interview, the interviewer read some of my commits and he said "I don't have any doubts you can code, but I wanna ask you about design". He went on to ask why I did things in a certain way.
But seriously. "Say no to coding on whiteboards".
But even in right-to-work states, to hire a person requires extensive hoop jumping for the employee. You can't just show them previous work and tell them how you can help them, you have to PROVE it with outlandish questions they may have little to do with the actual job.
1. Make qualified job interview candidate feel stupid by asking difficult questions unrelated to the job
2. Offer candidate low salary and argue that they barely passed the job interview
3. Profit
Best solution I can offer is to not play their game. You'll lose no matter how hard you try. You're better off studying marketing and psychology for job interviews.
Well, yeah. You should know how to sell yourself (to get past the resume screening process) and analyze the company's goals/culture/intent/desires (to avoid working at the next Uber).
HA!
Currently a graduating student that goes to one of those top schools. Do you really wanna know how long many of my peers are studying for these interviews? Months!!!!! I have a few friends that spent all of last summer after their daily internships doing interview prep for fall recruiting season. I also have a cousin that spent 5-6 months unemployed(given he did a masters/bs in ee and not in cs but wanted to move into the field) doing interview prep and just landed offers from Google and Dropbox. The competition is absolutely ruthless.
I think the only way I could make it through an interview is by quitting my job and studying for a month!
I noticed the graduate course overlaps with many of those chapters and also cover: chapters 18,21,25,26, 29-32, 35.
Ideally, I would like to take both courses out of pure self-interest.
If you want to prepare to interview at one of the top companies, then afterwards procure a copy of my secret weapon: Aziz, Lee, & Prakash's "Elements of Programming Interviews". The questions there are an order of magnitude more difficult. If you are able to apply the CS concepts you are learning to questions of that difficulty, all doors will be open to you.
I can't comment on "most interviews" but that would not qualify you to work for me - or in my industry. I want someone who does embedded C, understands hard real time control, can write code doing fixed-point math in a way that can be understood later, writes safe code, state machines, signal processing, fault management, LIN or CAN networking, and some other stuff. Knowing the function "malloc" or any algorithms that may use it is not necessary as it is explicitly forbidden.
Just sayin'
On the one hand, algorithms is a broad subject, so there's a large hole for false-positives and false-negatives to slip through. Sometimes it's like they'd pass on Gerry Spence as a trial attorney because he flubbed their question on tax law.
On the other hand, can't totally drop the brain-teasers because you'll need all the IQ points you can get before the corporate retardation sets in.
Most people are good at algorithm interviews because they've practiced them a ton. They've seen basically all the different kinds of questions that get asked on an interview, and are able to use that mental database to answer any questions.
Most of the time in interviews, interviewers will commend an applicant's "problem solving" skills if they did well on a difficult algo problem, when in all likelihood they've seen that exact problem, or an extremely similar problem before. If the applicant hasn't seen dijkstra's algorithm before and is able to derive it in a 45 minute interview, you would need to hire them on the spot, assuming that Dijkstra himself didn't develop this algorithm in 45 minutes. That is a contrived example, but you get my point.
For better or for worse, algo interviews are for testing how much work you've put into studying (mostly worse).
Eventually, it even got so bad that we were instructed to copy, word for word, certain disclosures from the competitor's web site.
The big competitor is still the big competitor and my former employer is still doing OK but they'll never catch or pass anyone by copying what they're doing.
We make sure in our group to focus on application of those concepts, not memorization or detailed knowledge of the concepts themselves. But yeah, fast algorithms matter. Memory usage matters. Proper data structures matter. I don't really care if you can spit out a syntactically correct implementation of a red-black tree on the spot, but you should know what a tree is and why you might pick or tree over a hash table.
I'd rather hire a writer who can really get a concept across but relies on autocorrect for spelling than a writer who can spell the hell out of stuff but can't actually write. Dogmatic interviews weed out the software engineers with the big picture skills and performance thinking who might be fuzzy on the details, like experienced folks who are decades out from school.
THIS! It's one of my go to stories but back when I was working as a co-op during my undergrad days, in my department there was a .NET programmer who was skilled but had no understanding of the underlying data structures.
He would be mystified at how I could write Perl programs that would outperform his .NET programs, even on less robust hardware.
I'm yet to have a problem where the particular data structure makes a huge difference on performance, I'm sure the exist but I don't come across them much personally. Most of the time an inefficient list search would not be noticeably different from a dictionary lookup, sometimes faster. What I have come across quite often is people who quibble about data structures but have n+1 queries everywhere and don't know what a join is.
Another thing that's critically missing in the field is experience with a profiler, someone that knows how to use a profiler will know more about performance than anyone thinking about algorithms. In fact, it's an approach I'd like to try in future for vetting candidates.
Profile, find hotspot, then use your clever cache-friendly hand-rolled tree algorithm when it makes sense.
I'd rather a programmer understand that than to have a bunch of programming puzzled memorized.
And for seniors, architectural questions are far more critical. Fixing a hotspot may get you a multiple or maybe 10x. But architecture is what gets you orders of magnitude.
I graduated with an Aerospace Engineering degree. While I don't exactly remember how to derive the Normal Mode of a wing, I wouldn't have any issue relearning it for an interview. For my first job, I was asked questions that had very little to do with my day to day but I still answered them and didn't complain.
Because they're pointless for the vast majority of positions: why make me learn something for the interview that I'll never use again? This offends many engineers' sense of laziness.
Because it's a pithy indication about what's wrong with tech interviews: we can't ask 'are you good at delivering with weird requirements' (because the candidate says 'sure I'm the best'), and we can't check their ability to do that in 45-60 minutes. Instead, we use these shibboleth questions to see if they are like other engineers (who can deliver etc.)
Because it's gatekeeping: if you didn't study algorithms or have the time/energy to keep it fresh, you can't get past these interviews and get these jobs. It doesn't matter if you'd excel if you don't have the same opportunities as the normal privileged young white male engineer.
Because it's inefficient: plenty of engineers could perform well in the position but get screened out by these imprecise questions. Sure, for a startup of 4 employees, you can't settle for great and have to keep rejecting until you get the best, but for a mature stable company, you want people with solid skills and abilities who can learn (how to do algorithms) on the job.
My non software-engineering Interviews contained tons of questions that aren't completely relevant. For example, describe in detail how pressure and velocity are correlated in each turbofan stage and how they affect efficiency. Describe what isentropic flow is and how it relates to lift.
I also hate getting random whiteboarding questions, but I'm not going to complain about it. If I really want a job I'm going to study for it.
Whiteboard or live coding is not the problem. Bad or untrained interviewers are, along with the fact we can't do one interview that proves to multiple companies what level we are at.
Bear in mind that the companies that do put people through that kind of thing do it because they can. When you have people lined up down the street to work for you, you can be very selective in who you hire and put them through all kinds of skill tests before hiring, to triple check that they have the requisite skills. Many (most?) companies do not have that luxury.
So, most of these interviews, an experienced Software Engineer dons the hat of a psychologist (without having any qualification/experience of a psychologist) and evaluates an interviewee.
How sad is that?
Whats worse? I know a few who prepare to interview a candidate by going through "how to crack the coding interview"!
I'm only glad that there are quite a few in my circle who believe in giving a problem they have faced at work, to a candidate, and ask the candidate to solve, using the same tools they use, with the laptop hooked to a projector. Interviews where I have done this as a candidate, I feel are more respectful of the candidate.
Many of those who love the "let me be an unqualified psychologist today" interviewing style disagree with my opinion. So do I, with their's.
We have no way of knowing if someone will work out, so finding ways to rule people out makes it seem like we did our job in the hiring process. Some Wonderlic-type questions, the person asking them gets to say, "Well, look we have some quantifiable way of measuring applicants." Total BS.
No cure for it, other than to not turn around and be that asshole once you are hired. We should be more open about what the criteria is; hiring comes down to a few gut checks... do you like the person and think they will fit in, do you feel confident that they can do the work you will ask them to do, and are they in your budget?
Unless you work with a person over time, there's not going to be any way of knowing how they are as an employee. If they are smart, if they keep up on current trends, if they are a good communicator (and any good at communicating inside of your organization), if they care, if they show up on time, if they are conscientious or just pass the buck, if they are a hard worker, if they are opportunistic / selfish with praise...
Anyway HR needs to justify itself so we can't just throw darts at resumes... but essentially that's all hiring is. Trying to get a sense of someone quickly, cheaply, and correctly? Nah, just pick 2... at most.
Why would somebody for whom it is easy consider to hire somebody who can not do a seemingly simple thing?
I can understand if somebody has anxiety issues. Then maybe you can negotiate something else, homework project or coding on site for 30 minutes. But odds are you'll discuss stuff with your colleagues on a whiteboard, too.
But every problem is an opportunity :), now most of my freelance work are companies who "had a problem and couldn't find anyone willing to solve it" and me who asked "can I give it a shot?"
Showing you want to solve problem so far "works for me" much better than doing the guinea pig with riddles
I work hard, get good reviews, have nice looking work that doesn't crash and scales - and I can't interview either.
I've also interviewed great candidates that get shot for no reason at all.
That said, it is a numbers game, if you need a job keep at it - you have not other choice.
But in the long term I think our community needs to chill out a little bit.
It's just another skill that can be acquired with proper effort and concentration. I can recommend "Cracking the Code Interview", it is chock full of these problems.
I think that while whiteboard nor algorithms nor random questions about technology are perfect, they are still better then vague talking about how passionate one is or variants of beer test. The issue with talking about good code is similar - it matters whether you know the principles, but it is too easy to fake by people who have more talking bluffing skills then anything else.
Personally, I like the best when they tell me what they will ask for, so I can prepare myself - whatever that is. That seems the most fair to me - good programmer does not know everything fresh, but should be able to refresh or learn something new reasonably fast.
Interviews are broken in most environment, and that doesn't mean we should do away with them or make them easier. Rather, we should fix them, make them better, and have them test what the candidate will be doing on the job. I see people say, "you don't need to understand algorithm complexity to build a website, or to know C or assembly" Sure! But you don't know what you don't know! If you know and understand algorithm complexity, you will use it even when building websites! You will think about scale. If you understand lower level languages and you are using PHP, you might understand how your code turns to C and how choices at a higher level turns to lower level. If you never studied computer architecture, you wouldn't understand the magnitude involved in fetching something from a register, processor cache, ram, drive, over the network. Yet such things do rear their ugly heads when developing these so called simple CRUD apps.
So if you are interviewing for a PHP programming position, and you get asked about algorithm complexity or C or TCP/IP or other questions. Don't frown, those are important questions, if you don't know it, you don't know it. It doesn't mean you are a "bad programmer" but it does reveal that you are a programmer without a wide breadth of knowledge. A one trick pony for the most part. Get over it and widen your knowledge.
The other day I was using an external API that was crapping out. After hitting a dead end, I informed the vendor and they said nothing was wrong. I did a system call trace and noticed a lot of error was being returned on poll(), I fired up tcpdump and noticed an abrupt and random FIN ending the connection. With this I was able to convince the vendor to test their API from outside their network, and once they did, they agreed that the issue was on their end and they fixed it. This was a basic PHP app. Without a wide breath of knowledge, I would have been stuck, no google or stackoverflow would have solved this.
Great developers have knowledge that are wide and deep. If you fail an interview, Don't get mad, get glad that you found your weakness and brush up your skills.