The trend would also be crazy coding interview tests that everyone must do regardless of experience.


Interview process has gone down the drain nowadays and your portfolio/experience are no longer important to many of these companies.

Everyone gets lumped into fresh grad category. Every tom d*** harry company thinks they're the next google/facebook/microsoft so they copy their hiring routines.


Then they complain why they cannot find anyone at all.

CD portfolio or even open source code is not enough. They claim that you could've taken it from other people.


The problem with coding tests is they test things that you have not used since uni or college and these tests are done on the white board, no PC.

That's why such hiring practices are sorely broken.

If an interviewer cannot properly tell then obviously they are not good enough to do proper hiring.

This post has been edited by RiddleMeThat: Aug 16 2014, 07:18 PM

The problem is when the interviewer don't even bother to test you on your own code and insist you do their parlor tricks on the whiteboard or paper and other cs stuff you forgotten after leaving uni for over 10 years.

They all want the easy way out then complain they can't find good programmers.

Every company wants or thinks they're the next google/facebook/twitter and copy these company's hiring methods.

I always read about companies complaining about our grads and programmers in Malaysia but I never see a proper counter article to these companies claims.

It's always one sided in the news.

The problem with people like you is you've never been on the end trying to hire people and lack the experience to evaluate candidates based on other factors and not hardcore technical skills. If you cannot smell bs without a coding test, you're unfit to be an interviewer, period.

I've coded much more complicated routines than ever needed in apps. I've done all those data structures and I find they're not really needed in many of the stuff we do nowadays unless you're doing OS level stuff like SQL server engines, writing OS, compilers, image manipulation software, or even develop games which I used to do. Heck, I don't even bother to remember off the hat code worth over 5 years ago I did last time unless I go back to refresh all those linked list, stacks and others I implemented for a game.

My most challenging code recently deal with queues, stacks and recursion and even that I don't bother to memorize what I did. It's a game related mobile project, but less challenging than my x86 assembly code project 10 years ago.

If I were much younger I would probably use these tests when looking for candidates in such field but I realized I am arrogant and unrealistic to do so, causing me to miss out way too many more competent candidates than necessary to fill the tasks at hand.

I realized that most interviewers who use irrelevant interviewing techniques..

1. Lack understanding of the position hiring for.

2. Has some sort of ego/insecurity/inferiority complex issues that they need to project/bully candidates.

3. Are put in as a shortcut way to get programmers which they could work with instead of what's good for the whole team, maybe because they're so sick of interviewing candidates they just use tests instead of actually talking to every one of them instead.


Never ever put a pure technical/programmer to interview candidates. They're more likely to have extreme bias purely based on that area only and because of their lack of business acumen, people soft skills and foresight, they will not be able to identify the best fit candidate. Fear of competition is also a reason why a programmer may deliberately reject someone better than them for promotion competition so they might deliberately pass on the better candidate.

When my ex-boss forced me to interview all potential candidates, I never make them do coding tests because it was unnecessary. I can easily spot their ability asking them to explain things or data structures. I don't like wasting time making them write code because that environment is not the same as actual working environment.

But i'll always give priority to those who can show me what they did before instead of those who expect me to view their grades.

Coding tests waste their time and my time. I don't even need those to evaluate fresh grads.

Now do all that without a computer, compiler, everything on the whiteboard and a marker pen within 30-60 minutes.

Which probably explains why so many companies complain about not being able to hire 'quality' programmers. Their interview process is broken because it is dominated by egoistic nerdy programmers who cannot see beyond those tests.

When I interviewed candidates I never make them do those tests. The ones I hire was able to do the work anyway so it wasn't an issue.

My only complaint is lack of application of the job position.

The test method is not very clear since we do not have a clear understanding of what the problem is.

At the very least he provides a pc and tools to do it.

The ones I am talking about are those whiteboard/paper stuff. NO hardware allowed. No googling.

But you have to understand one thing. Depending on the nature of the problem, 60 minutes may or may not be enough, so unless we know what question he is asking, we can't really say if it's a fair question for the candidate or not. The software the candidate wants to use also might take some time to download if necessary so he might exceed 60 minutes if problems crop up.

But the fact remains this. There will be less and less interest in such jobs in the future precisely because of the way interviews are conducted by egoistic programmers who're made to be in charge of the interview process.

The very same nerdy egoistic group of insecure people who have not moved on from that anti-social behaviour will be the ones who would eventually drive away interests in such jobs, and already declining pool of applicants.

Eventually when companies still cannot find the required talent, they may need to revise their hiring process and see if their developers/programmers are inadvertently sabotaging the process because of their egos.

Once again, if you can't smell bs during verbal interview and require coding tests to do it, then you as a programmer/software engineer, lack soft skills and good judgement.

This guy's experience in hiring developers mirrors mine. That's how I find candidates too.

http://devinterviews.pen.io/


Hiring Developers: You're Doing It Wrong

When Evan Carmi posted his Google job interview experience (http://ecarmi.org/writing/google-internship/ ) on HN, I felt reminded of my bygone startup days. In over a decade of "modern" IT startup job interviews we have made no progress whatsoever. If anything, I was part of the problem there for a few years. I simply copied a hiring mechanism that seemed like a standard at the time, and in doing so I failed miserably at the most important goals a company should observe when looking for new developers. Today the tech front pages are full of Larry Page's efforts to turn around the company, but I think performance problems at developer-centric companies may to a large part be burned into their DNA by a deeply faulty hiring process.

How We Did It
‾‾‾‾‾‾‾‾‾‾‾‾‾
My cofounder and I were running a small web development shop in Germany. We had started working literally out of my friend's basement. Over time, we grew, and moved into real office space. At first it was easy to find new employees, we could just ask our friends to come in and work for us. Of course, that model didn't scale, but it performed a very important function: it made sure we hired people that were a good fit for the company, both on a personal and a professional level. Then came the day when we needed to fill positions by bringing in people from the outside.

One of the redeeming features of the German regional unemployment offices is they will send you a large stack of CVs on demand, within a few hours of calling them on the phone. I was pleasantly surprised that we didn't have to hire an agency to do this. Together with the CVs we already had from people who applied to the job posting on our website, we now had some sifting to do. In the end, we agreed on about a dozen of the best and invited them for an interview. This is the part where everything went wrong:

The Standard Dev Interview
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
A candidate would come in, usually all dressed up in their best suit and tie, we'd sit down and have a talk. That talk was essentially like an oral exam in college. I would ask them to code algorithms for all the usual cute little CS problems and I'd get answers with wildly varying qualities. Some were shooting their pre-canned answers at me with unreasonable speed. They were prepared for exactly this kind of interview. Others would break under the "pressure", barely able to continue the interview.

To be honest, when we first started doing this I had to look up these puzzles in advance, mainly to make sure I didn't embarrass myself. This should have been the first warning sign that maybe we weren't exactly testing for skills that were most relevant to our requirements. If these doubts occurred to me, I must have dismissed them very quickly. After all, it was the way everyone approached the interview process.

Of course, we ended up hiring the candidate with the smoothest answers. Inevitably, the next job openings came, we did it again and again in the same fashion, for the rest of the company's lifetime. If this sounds familiar to you, you are clearly not alone.

Actual Job Performance
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
But how did the candidates we selected measure up? The truth is, we got very mixed results. Many of them were average, very few were excellent, and some were absolutely awful fits for their positions. So at best, the interview had no actual effect on the quality of people we were selecting, and I'm afraid that at worst, we may have skewed the scale in favor of the bad ones.

What does bad and good even mean in this context? Let's have a look some of the benchmarks that I consider important:

Company Culture. In hindsight, one of the most important features a new employee should have is compatibility with the spirit of the people who already work there. The Standard Dev Interview performed worst in this area, for obvious reasons. It's difficult to judge people's personalities in interviews because they are not exactly themselves. In fact, they're incentivized not to be themselves.

Programming Competence. Somewhat counterintuitively, the code examples done during the interview were a bad indicator for actual competence on the job. Real world projects rarely consist of implementing binary searches without access to a parser or literature. It turned out that employees who had done very well in the code examples were not always able to transfer theoretical knowledge into practical solutions. Having candidates write sorting algos on the whiteboard is a method that rewards people with great and precise short-term memory who come prepared for exactly these kinds of questions. In our case, we needed resourceful coders who could write neat, stable, and elegant software - and the interview process wasn't delivering them to us.

Project Management. People who did well in the interview were not necessarily good team mates or even good presenters in front of our customers. This result, too, was surprising to me. Turns out, sucking up to an interviewer for an hour is a completely different skill set than, say, being good at coordinating with your coworkers or the people who pay our bills. Nor was their interview performance indicative of the ability to write good documentation or how to behave in online communications.

The Result
‾‾‾‾‾‾‾‾‾‾
The results of a hiring process such as this may be one of the factors responsible for a company to lose its startup spirit and its creative soul. This was certainly the case with our company. As the CEO our ultimate failure was certainly my fault, however, having the wrong people on the job was a large part of the company's inability to deliver the quality and quantity of output needed to sustain it. Infighting poisoned our teams. Incompetence was covered up with good presentation skills and ass-kissing. Good people left the company because they hated the new atmosphere.

Though I had to let go many people for different reasons over the years and in the end had to deliver the hardest speech of my life on the morning I dissolved the company, I only went "full Trump" once on an employee. It was the one who had displayed the best interview performance and the best academic references of them all only a year before.

Sure, that's an extreme example. Most companies succeed regardless. But I still believe we can vastly improve the chances of finding candidates that are good fits by radically changing the way we do interviews. And in our case, that would probably have made all the difference in the world.

An Alternative
‾‾‾‾‾‾‾‾‾‾‾‾‾‾
So what should a developer job interview look like then? Simple: eliminate the exam part of the interview altogether. Instead, ask a few open-ended questions that invite your candidates to elaborate about their programming work.

- What's the last project you worked on at your former employer?
- Tell me about some of your favorite projects.
- What projects are you working on in your spare time?
- What online hacker communities do you participate in?
- Tell me about some (programming/technical) issues that you feel passionately about.

These questions are designed to reveal a great deal about the person you have in front of you. They can help you decide whether the candidate is interested in the same things as you, whether you like their way of thinking, and where their real interests lie. It's tougher for them to bullshit their way through here, because the interviewer can drill deeper into a large number of issues as they present themselves.

What about actual coding ability? Well, take a few moments after the interview and look into some code the candidate wrote. Maybe for an open source project, maybe they have to send you something that's not public, doesn't matter. Looking at actual production code tells you so much more than having them write contrived fiveliners on the whiteboard.

I'm sure you can come up with even more questions and other ways to engage the interviewee. At this point, pretty much any idea will be an improvement.

Nay-saying
‾‾‾‾‾‾‾‾‾‾
Most people are quick to defend the status quo, and sure, that's a rewarding position to hold. It's risk free and you can always fall back on the old argument "a lot of smart, rich and successful people do it the old way, so my money is on whatever they are doing".

❜❜Nice, but that doesn't work for large, successful companies. Your idea doesn't scale.❛❛
Sure it scales, in terms of effort per interview there is no difference. There is no reason this couldn't work in larger companies. In the end, the interviewer always makes a personal and deeply subjective decision, I'm merely suggesting a way that delivers more relevant information for that purpose.

❜❜The best programmers have no spare time projects.❛❛ or: ❜❜The most talented people I know work from 9 to 5 and then go home to watch football/be with their families/whatever.❛❛
This is not my experience. I'm not saying that a good programmer should not have a life. But I do believe that a certain amount of enthusiasm for programming is called for. And really, if you have such a great skill, not using it for fun seems kind of wasteful to me.

❜❜In my spare time I'm working on making the next million for my company. Oh, when I'm not working for my company? I'm with my family or friends.❛❛ (verbatim from http://news.ycombinator.com/item?id=2385148)
That's great, those people can surely show me something they have been working on. I would, however, consider the lack of any hobby projects a warning sign for _some_ development jobs.

Final Thoughts
‾‾‾‾‾‾‾‾‾‾‾‾
It has been my experience that the traditional developer interview is insufficient at finding good candidates. While the typical whiteboard coding exercises correlate somewhat with general CS competence, they are poor indicators of actual programming performance. It is my contention that we have been doing them this way for years simply because they're easy to administer, but the data that's coming out of these interviews is largely irrelevant at best. We as an industry should move to more personalized interview questions that focus on the entirety of a developer's skill set. Also, I believe it is more productive to judge production code as opposed to abstract modular puzzles that have no real connection to the actual job in question. Most importantly, I am convinced that gaining insight into the developer's real personality is just as important as checking for professional competence, because one bad fit can destroy an entire team.

Consider yourself lucky to see their company culture during interview. These types of companies are not good to work for.

When you have arrogant programmers doing the hiring, this is the result.


Why would you wanna work for dickheads and have such people as colleagues?


These type of technical people have lousy people skills and they will guarantee the company they work in will not be able to hire anyone but equal dickheads like themselves.

These insecure techies are the reason why management wanna cut their pay or restrict it because they're unprofessional.