It is what it is. Anyone who is interviewing for a position in software development is just about guaranteed to be tested on their knowledge. The efficacy of tests has been discussed ad nauseum. However, I think it is fair to state that the situation is not likely to change anytime soon.

There are plenty of online sources available that have problems that are common with solutions. There a plenty of books. One of the problems in preparing for interviews is that questions can cover a wide range of topics and preparation can take a long time.

Another involve logistical issues. For instance coding on a whiteboard versus coding on Hacker Rank versus some online white board versus a take home test. My experience has been that you are called in for a face to face and haven't been tested yet you will be at the interview. So prepare accordingly. I don't think it hurts to ask before you show up for your interview how you will be tested. For instance if it is on a whiteboard then it probably is worth the time to get a whiteboard and practice. My writing style is terrible so I run out of whiteboard space pretty fast so it is worth my while to have a strategy in using the whiteboard space effectively. If you are being interviewed over the phone perhaps even via something like Skype, again I don't think it hurts to ask if you will get a coding test. You probably will so be prepared for using an online whiteboard type thing. These are much better in my view than using a real whiteboard.

Then we have the tests that are done via HackerRank and such. My experience has been that very often companies are trying to invest as little as possible in weeding out candidates. Ymmv on that though. Some sort of initial contact is made by the recruiter and then you are hit with a test. For those that fail, not much is invested. HackerRank has plenty of practice type problems so it should be more than obvious that practicing up using a HackerRank type environment should be a high priority. In a timed test environment you want to have a plan if you get stuck.

Then we have the take home tests. These can be time very consuming. Generally speaking what my limited experience and what has been posted here, the requirements are often a bit vague. Also companies are obviously looking to see you apply a wider range of development skills. I would recommend reading suzzers posts on his experience with NetFlix. They are good and informative. A thanks to suzzer for posting. I will describe a recent experience I had in another post.

That's pretty much all I have on logistics. I definitely recommend getting Cracking the Coding Interview. In that book she addresses a concern that since a lot of these questions get asked a lot won't companies come up with different problems? The portion in the book on that topic is definitely worth a read.

In the LC thread, you asked me "what programming language was this test in?"

It never mattered what programming language I used for the tests, unless I was testing for PostgreSQL. I'm guessing, in the general case, that they figure you can learn whatever language in short order, though that isn't true for SQL. I always choose to use Python because that is the easiest language for me to do a variety of things in.

Every non-SQL quiz I've had featured a variation on the following:

1- Count words in an external document, JSON request, XML document, etc.
2 - Reverse a list or word without using revers()
3- String processing. This could range from pretty simple (slicing) to quite difficult. For example, I've had one that asked me to confirm a genuine email, with no guidance on what they considered a good email.
4- Variation on I/O. This could be reading a file, doing an API request, etc.

I'm seldom tested on anything that requires difficult data structures, though it does happen once in a while. I can only think of two times where I ran into this.

SQL quizzes are kind of strange. I'm mostly given a schema with no data, then have to write code to do one thing or the other. One interview in particular was interesting, since the test was more about figuring out if I was able to dodge data landmines, but that only happened once. That was easily the best whiteboard test I've ever done.

The worst are the "improve this code" tests, since the query is often 50 lines, with nested queries, written in the worst way possible, no schema, and just impossible to understand. Without a data dump (they all are to be optimized for "millions of rows") and without knowing the settings of the machine I'm testing against, doing this is generally impossible.

I generally go for data engineering and API development roles.

But, in general, I think the coding tests are fairly simple. I've said it before and I'll say it here, the mid-level tests appear to be much easier than the entry-level tests. I'm guessing this is because entry-level tests assume you are somewhat fresh from college.

But overall, I don't think I've bombed too many tests. The real test is the "get to know you interviews" and that, I suppose, is where I struggle the most, considering I've had a coding test about 1 / 10th of all interviews.

To up my post-count...

The question I always struggle with is "do you have any questions for us?" For the most part, every question I would want to ask was covered in the back-and-forth. It is hard to believe, but in real life, I'm very to-the-point and brief. You can cover a lot of ground in 45 minutes as long as the answers aren't long-winded and you use follow-up questions.

The only questions I can think of at the end include: "what kind of role do you see me at?" (if it appears that the rhythm of the interview is moving in other directions), and sometimes, "from your impressions of me, what do you think is missing from my knowledge (technology, concepts, etc..)" I've received some interesting answers from the second, but I don't ask it that often.

I feel like I consistently struggle with the back-and-forth conversation of the interview. I generally believe I've done well (I'm not a stuttering mess, don't need many pauses, and have a mental timer of 20 seconds or so to spit out my answer*). I almost never get to the second step. Each interview is dramatically different, so I'm not sure what to expect, and just do my best to answer questions, admit when I have no clue, and just stay relaxed. Some interviewers are very good at getting you relaxed in the first minute, others... well, they keep the intensity going all the way.

It is way different from the "good questions" you see on HN. I've never been asked "explain a project you are working on," "what role do you see yourself in here," or any of the other questions like that. There is more focus on technical and really seem to be asking "can you do this?" I always feel like I can up to some reasonable N%, but I don't know. Not good at selling myself.

*Being able to run through 50 options in a second is one of my "strengths," but it took a very long to realize it. Not sure if it appears that I just jump to the first conclusion or not. I genuinely thought everyone functioned like this for most of my life.

And a cool like for a bunch of interview questions: https://www.interviewcake.com/

Lots of interesting problems in there. The site sends a free problem once a week into your inbox.

My favorite interview "question" (as the interviewer) is just to sit down at a keyboard and pair program with the interviewee. Start up a new Visual Studio project and build the Seive of Eratosthenes or something equally obvious.

Quick point, one of things to keep in mind about taking a test is that it isn't some sort of process where the person who gets the highest score on the test gets the job. My view, it is simply a way to weed out candidates. With open ended type tests, like do it at home type projects, offer a lot more opportunities to reject a candidate. FWIW when companies ask you to invest a lot more time in something like a do it at home type project, chances are high that you will just be wasting a lot of time. Ymmv as it might end up being good practice and benefit you personally.

Also, my experience is that generally speaking technically oriented people prefer technically oriented work. Involvement in the candidate selection process is usually a PITA that people just want to get through. In my view it encourages laziness and encourages people to look for reasons to reject someone in lieu in focusing on their positive values. You can use that to your advantage in preparation.

Will start applying for full time jobs soon and have been using hackerrank and leetcode to prep. So I'll make sure to keep you guys posted on any interesting problems.

I have had a very high success rate with these interviews, and my advice is not to prepare too much for them. It is better to come up with original stuff than to constantly think about whatever the ideal textbook answer is. It is also best to come off modest and ask for feedback as you come up with the answers, and then tweak your answer to the feedback, and then ask for more feedback, and tweak your answer again, etc. You'll end up learning a lot in the process and come up with something interesting.

There obviously is a whole lot of activity in connected car development in the Detroit area primarily related to seemingly driverless funtionality. I've had many inquiries from recruiters about jobs in that part of the country in the past couple of months. Recently I was contacted by a recruiter for a consulting company that hires their devs out to their client companies. It was a position about related to connected car development. They couldn't tell me much about what I would actually be doing because it was proprietary info. They seemingly have embraced test driven development, extreme programming, & pairs programming with a religious type zeal. The recruiter followed up with an email providing links to some online videos about TDD and asked me to do a coding challenge. The challenge had the following stipulations:

-- Code development was to be done in C99 only.
-- The compiler had to be GCC
-- The solution needed to be contained in a git repository
-- The code development had to be accomplished using TDD
-- Thus unit tests needed to be developed in parallel.
-- They specified a specific unit test framework that had to be used
-- They posted a link to a tutorial on using the framework
-- Use an IDE that runs on Ubuntu (LOL)

Ok, I am very familiar with Boost.Test and somewhat familiar with CPPUnit. Either one of these frameworks for unit testing would have worked fine for me. I definitely had a learning curve with the framework they indicated.

So they wanted me to develop an application that was a Roman Number calculator that would do addition and subtraction taking Roman numbers as inputs and outputting the values as Roman numbers. They provided a link that had the requirements. Let's just state that the requirements were a little sketchy which of course is pretty standard. Of course I don't do a whole lot of work with Roman numbers and I also know that there is probably a way they prefer it to be implemented. So quite naturally I used Google. A couple of things I discovered about Roman numbers, it isn't clear as to what the highest Roman number can be. There seems to be somewhat of a consensus though. It certainly wasn't part of their requirements. In fact the rules as to what a valid Roman number is wasn't specified. I found that kind of interesting because either they wanted me to ask questions and if I didn't ask questions they would assume I was just using Google. The other possibility was they actually thought it was common knowledge. Anyway I found an algorithm that I was pretty sure they were looking for. But the parsing of the inputs wasn't part of the algorithm. So I would have to write code to parse the inputs given the validity rules, do the calculation, and handle the edge cases (like underflow and overflow of min and max Roman number values). The recruiter told me the period for accomplishing all this was open ended but in the link I was sent they indicated it would take about 4 hours. Now mind you this was just to screen me to see if they were interested in interviewing me. No discussion of salary/compensation, benefits, etc. it was after a 10 minute phone call.

I went to Glassdoor to see if there was any feedback about salary, culture, and/or hiring process. From that bit of research it think it is fair to state that the company paid pretty well, the benefits were ok (not as good as Microsoft for instance), the culture was at least not toxic and perhaps really good, and the hiring process had a high probability of being drawn out with several interviewing sessions.

Using C++ and the Boost.Spirit interface the parsing is easy and in fact Boost has a tutorial that specifically addresses parsing Roman numbers. Also the way I'm guessing they wanted me to implement it would have made checking the edge cases more difficult than using Boost.Spirit. So I could be wrong about their preferred implementation. Hopefully it is clear that for such a problem I would have just used the Boost interface and be done with it pretty much in a different way than I'm guessing they were looking for.

So after spending a few hours on this I responded to the email the recruiter sent me stating that I was going to pass on this. I indicated that there were several ways to solve it and stated the guess that I made in how I thought they wanted me to implement it. I also stated that I couldn't do all this in 4 hours, that I'm not really sold on TDD, that Roman number calculators do not really apply to developing software for connected cars, and that other things really matter a lot more in connected car software development (yes I have had experienyce with connected car software).

So why did I even spend two hours on this? Well I had never used Boost.Spirit before and there are some things I'm thinking about doing where knowing it would probably be a good thing. The idea of submitting a project that parallels a lot of things I do anyways like using GCC, git, unit test framework seemed like a fair way to go about evaluating candidates. I am not stating it is unfair either. I realized that four hours to complete this assignment was something I wasn't going to able to accomplish. Why waste their time and my time when they really are looking for candidates that can do it in a total of 4 hours or less. I wasn't really that interested/motivated in doing it in C anyway.

lol 4 hrs for all that

Can you expand on this a bit? Granted, I don't ever expect to get the highest score, but I'd appreciate a token of appreciation for at least doing all of the questions.

Yeah, I see the take-homes as a learning experience. I just about always run into something I'm not entirely sure on, and once in a while, learn and use something I've never seen before.

I think that, if the applicant really put in 2+ hours to do the test, he should get nominal feedback. More often than not, it is either completely ignored, or the response is a rejection form letter.

Any query on feedback about the code or approach is always "It is against our policy to..."

Here is a copy / paste of a quiz preamble I was sent a few weeks back. Seems indicative:

What we like to do is send out a written quiz and have you fill it out and send it back. This is the same process for all senior, junior, and interns engineers. We do this partly to get some baseline software engineer skill level data - which is why everyone does the same quiz. And partly to see if you have the right temperament to work in our startup-esque environment - where ocasionally you have to do trivial tasks just to help the team out.

"This quiz is to help see how much bull**** you'll swallow without complaint!"

I used to tell people that I had no clue what the complaints about Amazon are, then say I was just joking... I'm actually not joking. *shrug*

@Dave - If you agree that tests are intended to be some objective measure of cognitive skills then having the best score would indicate one has the highest cognitive skill level. Of course it isn't always really clear because scores can be close on a test. My point is that a candidate could clearly test above the rest but that wouldn't necessarily mean they get the job. Cultural fit is at least as important, probably more so. At least that is what I have perceived. Think about it, if you can eliminate candidates by simply their test results you don't even have to consider cultural fit. If a candidate does well enough on a test but not nearly the best of the lot but is perceived to be an excellent cultural fit while the others not so much I think that candidate is the clear favorite.

If a candidate scores well on a test, how do you determine cultural fit without ever talking to the candidate?

At this point, you have:
-- a resume
-- a test with reasonable answers.

Got my first triple byte assignment. Automated response though, so it's not like anyone saw my resume and decided to move me on. Will report how it goes when I have a chance to do it. Not sure which language i have to use, but I'm rusty all around from taking a month off to move.

misread, it was a multiple choice 30 question quiz. Lots of C, Ruby, Python, JavaScript. Fair amount of time and size complexity, few in-depth algorithm and data structure questions towards the end. 2 minutes per question.

Don't think I did too well. =-/

I think its important to be able to recognize categories of problems. That is the quickest way to identify how to solve a problem... not some memorized solution.

Have two coding challenges to complete within the next week. One from Google and and another from VMware. Have to do the VMware by Sunday so I'll be using that as a practice.

Not sure what you are getting at. Of course you have face to face interviews but the tactic in using tests, as the one I was given, was to eliminate candidates before doing an unnecessary face to to face. The test results suck, no face to face needed, not much invested by the hiring outfit.

I will be interested in the feedback you get from VMWare. VMWare contacted me about a position a year or so ago. From the job description it appeared that I was marginally qualified so I passed on taking the test.

Yes this is definitely true. However, there are certain questions I have been given repeatedly like reverse a linked list. A lot of interviewers are just lazy about interviewing because they are uninterested in interviewing. They have their pet questions and quite often they are well known questions. From my experience, whiteboard solutions are characterized by this a lot.

To be fair, IF you were knowledgable about the unit test framework as well being experienced with Test Driven Development (TDD) practices then maybe 4 hours is not that far fetched. Leaving the learning curve of the Unit Test Framework out of the 4 hour period, for those that are experienced with TDD how much improvement and what kind of improvement in productivity do TDD practices yield? I would think if it shows it up shows up by having a products failure rate be acceptable in a reduced amount of time. For instance it is pretty easy to write some code that has not been tested much (throw it over the wall) and ultimately have all the testing that can done on a product weed out the bugs until the failure rate and the severity of the failures reach acceptable standards. It seems that the promise of TDD is to reduce that time period significantly.

I consider these about one step above reciting code over the phone, without pencil and paper. I never feel bad about not doing well.

I just received a link to a test in an email. I'm not entirely sure when I applied to this job, but I know it is over 2 months ago.

The test is write a simple rest API. The specs, as written, don't make a whole lot of sense to me. This part of the test is public, so I'll copy / paste it:

Your API must have:
- at least three endpoints
- all endpoints must be linked in some way

Please pay careful attention to Rest best practices and describe the application in detail in a design document including why you chose the approach you did. Also, include tests that validate success.

What should be delivered:
- A single page website that allows for retrieval of data from your endpoints
- Share your application and provide a link where it can be tested
- Design Document
- Unit Tests

I have 3 days to finish. I'm thinking about passing, which would be a first. Are they asking me to host this as well?

I decided to look a little further and signed in. What I wrote above is literally the entire test. What do they want, exactly? Apparently, creativity is part of the score. I'm definitely not doing this.