Prepping for software interviews that aren't algorithm heavy

December 7, 2016 3:05 PM

I've been doing a lot of the "big 4" time complexity/algorithm heavy-style software dev interviews lately, but will soon start interviewing with smaller companies. What should I expect/prepare for?

As I mentioned above the fold, I've done interviews with big companies (Facebook, etc.) where algorithms and time/space complexity analysis are very important, and database questions and implementation questions are usually fairly marginal or more general than detail-oriented. However, I'm interviewing with some smaller software dev shops now while waiting to hear results from my first batch of interviews, and I get the impression that these interviews are usually quite different. (e.g., one I had recently required some database design questions, then some HTTP header questions, and asked for real implementation code, or as close as someone can get it on a whiteboard.)

I realize this will vary a lot based on the shop and their area of focus. I'm mostly interviewing for sort of "general" dev or full stack positions. One specializes in building business intelligence platforms, once is an IT consulting position, etc. But are there any general tips or areas that would be worthwhile to brush up on? And is it ever kosher to ask your contact what to prepare for in advance?

Important Note: I am a new grad so they won't be asking me in depth questions about my 15 years of experience in sys admin or anything like that.

posted by stoneandstar to Work & Money (11 answers total)

Best answer: I've been on both sides of interviews, but I'm pretty deep in my career at this point. So a braindump, in a mostly disorganized fashion:

I typically like answering architecture & design questions by noting tradeoffs. "We could do it this way, but it'd be expensive on disk" or "wouldn't scale horizontally" or "would be quick to implement, but may cause issues later", or "we can always denormalize this data when we hit it big".

I like the idea of a "T" shaped developer - have a focus you can articulate. For me, it's webdev, that's the vertical stroke of the T, the part I know well. And the horizontal stroke is all the other stuff I know some about. Machine Learning, DevOps, Native Apps, Electronics all fall in that category. I know some, but would have to do learning before that would be my day job. Smaller companies end up needing some of that horizontal knowledge just out of necessity.

Actually knowing SQL is a thing I've seen people struggle on. Knowing what a normalized DB looks like, and how to do joins.

When interviewing, I've asked questions along the lines of: "In ruby on rails, what does `has_many :users` actually do?" - and then dug deeper based on the answer. That's looking for how well the applicant actually understood Ruby, vs just reading docs and vomiting out code. (Although we were hiring for more advanced devs too).

General advice is to verbalize what you do know, even if you can't answer the full question. List the restrictions, note some tradeoffs, say "I bet there's a way to avoid the second loop over this array", etc. If you're verbal, there's something to grade you on, and take away. If you silently say "I don't know", then there's nothing for the interviewer to see. The actual algorithm to search an array or the design to build out an DB table is pretty boring, it's the thought process they're looking for.
posted by cschneid at 3:54 PM on December 7, 2016 [3 favorites]

One big key for me is, if it's on your resume, you'd better know it. If you claim to be a Python developer, I'm going to ask you Python questions (not obscure trivia, but real-world challenges) and you should be able to handle them. If you said you worked on a web server, I'm going to expect deep understanding of HTTP as it exists in the wild. If you have a project on your resume, I expect you to be able to explain, in detail, what you did on it, what the hard parts were, what you'd do differently in the future, and so on.

You'd be surprised how many people fail on these measures. No one knows everything, or is equally strong in all areas. But your resume is your marketing document; it is the stuff you're claiming to be strong in. It's also (likely) what got you the first interview/screen. So you need to be able to back it up.
posted by primethyme at 4:14 PM on December 7, 2016 [1 favorite]

It's entirely appropriate to ask what kinds of questions you might expect, especially if they've given you no guidance on that topic. Especially if it's a smaller shop that doesn't do a high volume of interviews, failure to provide this information is likely more a matter of somebody forgot or didn't think it was important rather than a case of wanting to make the interview process super secret. I think the only case where it would be tacky is if they did give you a document with guidance about what kinds of questions to expect and you asked anyway.

Questions are varied, so the only tips I could give would be general software interviewing tips -- talk through your thought process out loud as you're thinking; practice whiteboard coding so that you can be legible; understand that while there's some measure of leeway given that you're coding on a whiteboard it doesn't mean that you can ignore everything you know about good style and syntax; etc.
posted by phoenixy at 5:40 PM on December 7, 2016

I'm reading "cracking the coding interview" right now (which you should buy ASAP if you haven't yet) and one thing the author notes that helped me understand this is that the big top tier companies tend to focus on testing for aptitude rather than knowledge. Facebook et al can afford to reject someone who is an expert in language X but just has a bad day or doesn't deal well with interviews. Startups and smaller companies tend to care more about a new hire being able to hit the ground running with whatever tools/frameworks they use. So I think you have to do some research before interviewing at a smaller company.
posted by deathpanels at 6:16 PM on December 7, 2016 [1 favorite]

I'm not sure which city you're interviewing in, but if you were in a city with a few of the big 4 (*), I'd mention that small companies in these cities tend to be fed by people who had been at the bigger companies and learned their structured interviewing from there, for better or for worse.

From what my small-shop friends have talked about, it would probably be helpful if you showed that you knew about software engineering processes, like code review, unit testing (but also not to the point of slavish adherence to test-driven development at the expense of higher-level design), deployment, and on-call. In a few years, I guess I'd expect someone to have experiences and opinions on these things.

Why? Using testing as an example: A big company doesn't care what you think about testing because the division will probably have a test framework in place, and the culture is firm on code coverage goals, etc. and you will go with it regardless of what you think personally; a small company will probably prefer to hire someone who shares or is open to their testing philosophy, since it's much easier to refuse to go along at a smaller company.

I feel like these are also good indicators of how a shop functions, i.e. you should not join a company where you can know these things, without knowing these things.

* (dear god, is this the software company version of HYPS? Or is that Uber-Dropbox-Pinterest-AirBnB nowadays)
posted by batter_my_heart at 6:27 PM on December 7, 2016

Best answer: Oh, I'll also mention this, because it's frequently forgotten:

KNOW SOMETHING ABOUT THE COMPANY. Seriously. Read their public website, look over their Github account. Learn what tools, databases, languages, etc. they are using. If applicable, get a trial account and play around with the product. If you show some knowledge of or passion for the product, you will definitely stand out as a candidate.

Also, yes, it's totally kosher to ask about the interview! Ask if it's a "technical phone screen" or if you'll be doing white-boarding or coding. I wouldn't go so far as to ask if they're going to ask you a tree traversal problem, but knowing approximately what you're getting into is a reasonable ask.
posted by deathpanels at 7:46 PM on December 7, 2016 [1 favorite]

My experience has been that the questions don't vary a whole lot with the size and/or name recognition of the company. That said, one of the big names did ask decidedly more substantial questions at the in person stage than anyone else I've interviewed with (but I think they asked me to reverse a string in the phone interview). But generally, there tends not to be a big difference between phone screen questions and in person questions.

Definitely get a copy of Cracking the Coding Interview. AFAIK, the etiquette is that you should say when you're asked a question you've seen before, which will happen sooner or later.

I just did a job search (now with experience!) and noticed a lot of places asking about testing and wanting you to give test cases after finishing writing the code, which I didn't get when I was graduating (maybe I got asked once). I don't know if that's because I was just graduating or if it has since become fashionable to ask in interviews.

I've never been asked a SQL question. However, I'm about as far towards the engineering side of data science as you can go, so it may just be assumed I know SQL. It seems the highest level of SQL knowledge one would need in a general developer interview is knowing how to join. (I asked one of the senior developers at my old job if I could ask about window functions in an interview. He said "Well, I'm certainly never going to ask for more than a join, but if your team thinks it's fair game..." in a tone of voice that suggested I was crazy and no one would ever get it right. They do, but it's a niche population of candidates.)
posted by hoyland at 5:27 AM on December 8, 2016

I started programming in 2011, I don't think I was truly good at it until a year ago, but I've somehow managed to receive an offer of every position I've interviewed for. I feel very fortunate. I can't fully explain how I pulled it off, but I have a few things worth mentioning.

On my skills list, I have an "only enough to be dangerous" section. Almost every interviewer made a point of vocally appreciating the candor, and I was always given the benefit of the doubt with tech questions. It was better received than I could have ever hoped.

Before the interview for my current job, which I was sure I wouldn't get, a friend said "of course you'll get it, you get all excited about stuff and people like to hire that". I'm. It particularly extroverted, but its still quite evident how much I like programming.

When I interview candidates, i look for people who have developed real opinions about the tools & technologies available to them. I ask people to explain why they think a tool is best suited for a given purpose - stuff like python is great for x but java is better for x, react is overkill unless a site does x. etc. if it sounds like you have put thought into the tools you use, you're gonna look way better than candidates who don't.
posted by yorick at 5:32 AM on December 8, 2016

It is absolutely okay to ask your contact what kinds of questions will be on the interview. I usually do, and have never gotten dinged for it. I tend to phrase it along the lines of, "What kind of questions can I expect from this round?"

Small companies tend to like to ask algorithmic whiteboarding questions too nowadays, so it sounds like you're already pretty well prepared. But as you already know, though, it's going to vary by company. We can't give you a general answer.

So here's my real advice re any particular company you're interested in - go on glassdoor and read descriptions of what their dev interview is like, google around to see if anyone has described it on quora or wherevs, search linkedin to see if you have any 2nd or 3rd connections who have worked there who you can ask about the interview, &c.

Or ask on mailing lists! If you identify as female, for example, you can get on systers/devchix/techladymafia/a few others, and that can be a good place to email a group of people and see if anyone knows what the interview process at $company is like.

It's okay to ask because it's not like you're trying to cheat and find out what the precise questions are in advance - you're just looking for a sense of their general flavor. Totally legit.

Good luck!
posted by 168 at 5:47 AM on December 8, 2016 [1 favorite]

Wow, I'm going through this right now. I'm a "solutions architect" or basically I'm at the stage where I can articulate things but don't know what language feature "X" is better then language feature "Y" ... I haven't been a day-to-day developer in a longtime and I emphasize that I'm more at a management level, client-facing, can help develop solutions from a large picture but generally I wouldn't know how memory management in a RabbitMQ implementation is handled in round-robin clustered environment (I made that up). I certainly CAN look these things up, but my memory needs jogging.

That said, with 10+ years of coding under my belt at some big websites you've heard of I couldn't tell you a SQL inner-join or how to optimize joining two string arrays. When I was a couple years out of college I had design patterns memorized, and knew all this stuff. Today I'm a lazy programmer (if I program at all) and most things I deal with are solved problems that I know how to look up if I have to. Worst of all, I forget the name of half the the technical terms. When working on a team we simply don't talk as if we're designing a language spec, and people that do I usually find are more talkers and less doers, but that's another topic.

In any case, and maybe I'm just interviewing above what would be considered a senior developer position, I'll simply state either "I should know this but I don't do this," or I will say, "Oh wow, I forgot the actual definition but here's how I would use this," and just be honest. I feel comfortable in my abilities that I don't need to rattle off things. And guess what? It works. Let me give you an example:

I was interviewing for primarily a C#/.NET role and they were grilling me on how generics are implemented and some of the other cruft that enterprise languages like C#/JAVA love to use. The thing is I specifically stay away from a lot of things like internal sealed classes, or all that other nonsense. So when the questions got into that I explain when I run into things like that it usually is a pain because I'm trying to legitimately change something and a programmer over-thought it and is preventing me from changing something and no, I don't know off the top of my head the scope of what an internal sealed class can be accessed (I think its in the scope of the namespace or something). In any case I then went on to ask the interviewer when the last time he used that language feature and why he felt the need to protect his code in such a way, rather then implementing and documenting what it does and being explicit with things like unit tests as to how it should be used and letting programmers decide whether or not they should use it. He was floored, said he couldn't remember last time he used it but thought he might have in the past and then conceded that yes, when he does run into it is a pain in the ass. I then went onto explain that golang and some newer languages eschew things like generics and more "advanced" language features as they simply are only necessary when things are designed by committee, that code becomes surprisingly LESS complex and easier to maintain in the long run when someone isn't pouring over language specs to find a specific feature no one uses very often to just confuse some junior (or senior!) dev along the way.

The rest of the interview went like that, and they were impressed! I've only had one interview where they went down some checklist and didn't like the fact I said "I don't know," or "I can't off the top of my head explain the detail of GC in .NET but I do know enough to know that after 4.5 GC isn't blocking, so requests can still be made and yes I've run into issues where upgrading to 4.5 solved major performance problems." And if they do want me to know specific implementation details off the top of my head, it is probably a wonky shop where developers like to talk and not solve problems.

There are definitely firms out there where knowing low-level or actual implementation comes into play (in the .NET space Ayende's firm actually runs up against real .NET GC issues and they definitely don't deal with "simple" problems). However, unless you're going into a shop that's dedicated to machine learning, or something specific like writing a message bus I would not consider these "gotcha" questions that important or something you couldn't talk around by showing that you actually know how to Google and use Stackoverflow.

Okay one more rant because I've been doing a lot of interviews. I was asked to do a code test, which I absolutely hate. My value is in organizing large projects and making sure they get delivered, so I would almost always say that if you give me a CRUD test I'm not going to break it into a bunch of complicated design patterns that make it impossible to follow if I know that the requirements really are simple. In any case, look at sites like Twitter which had severe performance problems but more importantly, they got a viable product out the door and dealt with them later. I would argue everything in non-mission critical space is probably better to get out the door then languish in development hell.

In any case they wanted me to create a CRUD interface and a search. Since the dataset was only initially a hundred, I "cheated" and put a jQuery table and made search all clientside. I even demonstrated that the JSON payload of 10k users really was smaller then images you see on sites and in any case, it would be far either to cache this payload, offload processing to the client then run a search on the server everytime, even under load. And if performance was an issue, it would be more nuanced then simply adding Solr and some specific queries. We'd have to know what kind of queries were being made, how the users were interacting with the site, etc. In fact Solr was actually slightly slower and added quite a bit of complexity where it wasn't needed out of the box. Furthermore, I made the argument that there might not be a business case for the extra time to create a more complex solution. If it is 500ms slower doing it clientside (as a thought experiment) but it is an assistant entering in invoices for 30 minutes a day, wouldn't the cost of her spending a handful of minutes a week extra, even over several years outweigh making something complicated. DevOps and engineering time (and adding a Solr cluster!) is not a trivial cost. Much better to spend time on top line revenue. And at the end of this, I offered to setup a Solr cluster and show I knew how to use it if that's what they wanted me to do, but the requirements were simply "search" and I was under the assumption they wanted me to show that the "best" option is not simply the best on paper, but one that also makes business sense (again, disregarding that ironically my option was faster and saved theoretically on server costs of processing the queries, even if I was doing a SQL search).

They told me I didn't have the chops of someone at my level. Ironically I had a real world similar use case where I took out the Solr cluster, did exactly what I did in the example and could show bottom line savings along with the users believing performance improved as all sorting, etc. was done client-side, but they did not really care or want that.

So I know this is pretty ranty, but don't despair. This is the first time in my career I haven't been hired from an ex-colleague so I'm going through what you're going through and not used to these types of questions. I would just recommend doing what I do and explain the thought process behind it and feel free to say I don't know and question the value of the question being asked. Not in an antagonistic way, but in a, "that's interesting, why would you use that," or "man I should know how to do a SQL inner-join but I've been doing ORMs so long I couldn't tell you off the top of my head but its basically joining two tables based on a matching column." Just show thought process, I'd much rather have someone with a good thought process then someone who is the next Donald Knuth (well I kid, sort of, but he probably would be bored to death in anything I do on a day-to-day basis).
posted by geoff. at 8:14 AM on December 8, 2016 [4 favorites]

Actually knowing SQL is a thing I've seen people struggle on. Knowing what a normalized DB looks like, and how to do joins.

To be fair, SQL is turning into one of those things that people used to have to do all the time and now really only touch it if there are performance issues (and usually these are hidden with things like Lucene used for reads). Plus anything logic related in the database usually scares me as I've seen people cram everything into a complicated store procedure that no one can decipher. Plus the last several projects I've been on exclusively used document databases, I'm sure there's people out there right out of college that might have not ever really even needed to touch SQL.

Far better question would be to ask about the impact of something like an ORM on generated SQL calls. As in, here's a few classes, you need to get all cars that are red that exist in the city of Chicago, here's the current query that is slow. Why would that be slow and how would you improve it? That would be a good question as there's multiple ways to approach it and shows some understanding that ORMs are not complete magic, even if they are pretty good at hiding bad code these days. Plus even MS SQL is at this point doing a lot of its own magic in hiding bad db queries. Still it is important to at least be aware of what's happening, and not just code your way blindly and rely on the tools to completely be a crutch.

Okay I won't thread sit. :) As you can tell I just got out of a few interviews.
posted by geoff. at 8:24 AM on December 8, 2016 [1 favorite]