Technical interviews - prep

PaulStat

PaulStat

PaulStat

Soldato
Joined
1 Mar 2003
Posts
5,508
Location
Cotham, Bristol
So I narrowly missed the cut on the technical test I just took (14/20 required I scored 13). I am dead serious about wanting to move in the new year, so I want to be as prepared as I possibly can be.

So what are must knows for technical tests, what areas should I be reviewing? I am a Java developer, being in a small company means I do a bit of both backend and frontend.

The product I work on is client server based GUI using jnlp to download the client jars from a Tomcat webapp.

Ideally I'd like to move in to web frameworks using Spring MVC and similar, but this isn't something I use in work so I have to go on my experience with personal projects.

So far my experience tells me interviews don't tend to be specific to any frameworks/API's and focus on core language. My Java language knowledge is I think pretty good, but I suppose I am lacking in some more core computer science areas such as (I do have 2:1 comp-sci degree but it's been a while)

- Algorithms, what should I know. It's been 10 years or more since I've done things like binary search, quick sort, bubble sort etc.
- Data structures. My day to day use I use the standard ArrayList, HashSet, HashMap that's about it (our code is littered with Vectors too which I'm not overly pleased about, but refactoring these would be a big task). Things like LinkedList, TreeMap, Queue etc. I rarely use but I will occasionally look them up to remind myself
- Time complexity, I never 'got' Big-O notation when I was doing my comp-sci degree. I have looked up easier to read explanations (Wikipedia's mathematical expressions went right over my head) of it recently and I get it a bit better, but I'm not hugely confident I could look at an algorithm and say "Oh that's O(1), O(n), O(logn), O(nlogn), O(n^2) etc."
- Design patterns, I know a handful and I know the categories, there's only a few I could write without having to lookup. I'm not sure how important these are in the context of a technical interview (I'm sure interviewers would cringe if I mentioned Singleton :p).
- Are there certain logic puzzles I should be well practiced at?

I can hear some people thinking "He's a programmer, mathematical knowledge is key", but the truth is the majority of what I code is "boilerplate" code, communicating data between code layers etc.

Umm yeah, so advice please! Perhaps this could prove useful to others in a similar position.
 
Not much to add I'm afraid, aside from I'd also be really interesting in hearing more on this topic from people in 'corporate'-style environments.

I've only worked in small startup-style companies where broad general knowledge and 'making things work together' is probably more valued than in-depth technical compsci stuff.

I'm looking to move jobs to a larger company and I'm thinking the lack of 'book' knowledge is going to hold me back.
 
Some random thoughts:

- A good profile on linked in. Get your spelling right and make sure you are using "their", "they're" and "there" correctly. Use the privacy settings to stop recruiters just trawling your contact list for people. I refuse link requests from anyone I don't know - especially recruiters who haven't even bothered reading the profile.

- Algorithms, data structures, O(n) etc can be brushed up using the free courses on coursera.org.

- Design patterns come with time and experience. There's likely 5 or 6 from the gang of four book I regularly use.

- Avoid companies who screen using lots of java trivia type of questions like "which version of java introduced collections". Its either nerds waving willys or a cheap filter for mindless HR people. I regard it as pointless knowledge when it can be googled in 10 seconds. One or 2 questions like that is fine as it does filter out people who've never coded in their lives, but a coding test like the one you just did is a much better way.

- Work out what kind of developer you want to be. I think there are two broad categories, the google type nerd who lives data structures and big O notation and those that work more on the business side translating vague requirements into working code. Don't apply for jobs in one when your expertise is in the other.

- Every potential employer is different. You will find one that works for you. Remember at interview that you are also interviewing them - make sure you work out whether you want to work there.

- Recruiters are not your friends, agony aunts, career advisors or bosses. You are just a product they are working out how to sell (or not bother with). Any muppet with a phone can set up as a recruiter, so the industry is full of clueless idiots and has a huge churn rate. I've been in development 25 years and I only need one hand to count the really good ones I've spoken to. Go to theregister.co.uk and read the columns by Dominic Connor.
 
Last edited:
Thanks for that I'd love to avoid recruiters, I'm more than happy to phone companies up and say 'giz us a job'. It's how I got in to the company I'm in now. But I'm not entirely sure how to find companies in the surrounding area who are either software company's or have departments
 
In my experience, I am not sure how much sway technical tests hold (unless it's a project type exercise, which you are asked to do at home). I would think that interviewers are more interested in whether you fit into the team and that you can at least demonstrate that you know what you have said on your CV and not a complete novice. Even the most knowledgeable will make mistakes or stumble in a timed written/computer test.
 
fretted said:
In my experience, I am not sure how much sway technical tests hold (unless it's a project type exercise, which you are asked to do at home). I would think that interviewers are more interested in whether you fit into the team and that you can at least demonstrate that you know what you have said on your CV and not a complete novice. Even the most knowledgeable will make mistakes or stumble in a timed written/computer test.
Click to expand...

We put great weight in our technical tests, the personality tests are just to make sure we aren't hiring an axe murderer etc. When trying to hire the smartest graduates that have a love for computer science and, math and technology you don't find the most socially interesting people on average.


The trick with technical interviews is to see how people fail, see the processes they adopt in tackling challenging questions, how they cope with complex decision making under pressures. See how quickly their naive solution is a failure, admit that, pick up the pieces and come back with a better approach. We ask questions that almost no one resolves within the interview, but they often call up the next day to say they solved the problem because it consumed them all morning - we then offer them the job because they show the passion for such problem solving. At the opposite end of the spectrum you see people get all stressed to the point of anger, cursing and worse.
 
PaulStat said:
So I narrowly missed the cut on the technical test I just took (14/20 required I scored 13). I am dead serious about wanting to move in the new year, so I want to be as prepared as I possibly can be.

So what are must knows for technical tests, what areas should I be reviewing? I am a Java developer, being in a small company means I do a bit of both backend and frontend.

The product I work on is client server based GUI using jnlp to download the client jars from a Tomcat webapp.

Ideally I'd like to move in to web frameworks using Spring MVC and similar, but this isn't something I use in work so I have to go on my experience with personal projects.

So far my experience tells me interviews don't tend to be specific to any frameworks/API's and focus on core language. My Java language knowledge is I think pretty good, but I suppose I am lacking in some more core computer science areas such as (I do have 2:1 comp-sci degree but it's been a while)

- Algorithms, what should I know. It's been 10 years or more since I've done things like binary search, quick sort, bubble sort etc.
- Data structures. My day to day use I use the standard ArrayList, HashSet, HashMap that's about it (our code is littered with Vectors too which I'm not overly pleased about, but refactoring these would be a big task). Things like LinkedList, TreeMap, Queue etc. I rarely use but I will occasionally look them up to remind myself
- Time complexity, I never 'got' Big-O notation when I was doing my comp-sci degree. I have looked up easier to read explanations (Wikipedia's mathematical expressions went right over my head) of it recently and I get it a bit better, but I'm not hugely confident I could look at an algorithm and say "Oh that's O(1), O(n), O(logn), O(nlogn), O(n^2) etc."
- Design patterns, I know a handful and I know the categories, there's only a few I could write without having to lookup. I'm not sure how important these are in the context of a technical interview (I'm sure interviewers would cringe if I mentioned Singleton :p).
- Are there certain logic puzzles I should be well practiced at?

I can hear some people thinking "He's a programmer, mathematical knowledge is key", but the truth is the majority of what I code is "boilerplate" code, communicating data between code layers etc.

Umm yeah, so advice please! Perhaps this could prove useful to others in a similar position.
Click to expand...

MIT have excellent lecture series on you tube:
Introduction to algorithms
https://www.youtube.com/watch?v=JPyuH4qXLZ0

Analysis of algorithms
https://www.youtube.com/playlist?list=PLU2PyJOcZ7fg9wk_ZouOkgPb1PbCMja04



Being able to quickly get a good estimate of algorithmic complexity from a quick analysis of a piece of code (or pseudo code) is a very useful skill and shouldn't be too tricky. Therefore it is definitely worth learning enough for you to understand the code and algorithms sufficiently. For interviews you can geenrally get away with the basics.

a Quick 30secodn summary:
  • Iterating over a vector/list/array (VLA) of size N checking every element = O(N)
    Code: 
    for (int i=0;i< vec.size();i++) {
  if (vec[i] >0) num_positives++
}
  • Iterating over a VLA in a nested manner comparing each item to every other item = O(N^2):
    Code: 
    for (int i=0;i< vec.size();i++)  {
    for (int j=0;j< vec.size();j++)  {
         results[i] += convolution(vec[i],vec[j]);
     }
}
    IN general the item in the inner loop could be a different VLA so the run-time would be something like N*M but that can be simplified to N^2 assuming N and and are in some sense proportional. If the inner VLA was of a fixed size say 4 then you would get N*4 which is still just proportional to N, so it would b O(N)
  • Searching a binary tree where all the items are strings that have been sorted alphabetically. At each node in the tree you can throw away at least half of the elements (if the tree is balanced) So every test you half, imagine the entire tree has 1024 items then the first test will eliminate 512 , the second test will half it again and give 256, so it will take only 10 test to find the item . The has a logarithmic relationship, Log2(N). Mathematically it doesn't matter what the base of the logarithm is because it is trivial to change bases (plus with computer it is nearly always base 2 anyway), so one can just say O(log(N)).
  • Finding an element in a has map when the key is a string. This is a trick question that most people get wrong. They all learn that in the best case scenario without key collisions a lookup in a hashmap has constant time O(1). There are 2 caveats here, first if you have lots of collisions then the worst case performance falls back to whatever mechanism, is used to deal with collisions which is often just a list, so the worst case is actually O(N). sometimes a binary tree or heap is used so you get O(log(N)).

    Moreover, finding a hash in a hash map may well be O(1) on average, but you first have to generate the hash key from the unhashed key. If you want to generate a hash from a string of size M then the runtime is O(M). This is important because many other structures would offer a similar runtime, e.g. a trie tree, radix tree etc would be O(M) for strings of length M but may offer other good abilities (less memory, fast in order traversal, etc).
  • Fastest sort on a Turing machine is provably Nlog(N). It is worth learning why.
  • Exponential and factorial runtimes are typical for specialized hard problems like Travelling salesman. When working out all the permutations of a list of N items there are N! possibilities, e.g. for N cities there are N! different paths connecting them. So a naive TSP solution would be O(N!),

    Typically not applicable (either infeasible or more intelligent algorithms run better) but there are some useful results, e.g. the worst case bound on the Simplex algorithm is exponential but in real world problems tends to be polytime.
 
Some people throw a lot of math at big O notation, which can be useful in the long run but is scary and hard to begin with. If you really break it down then it should not be harder than seeing that there is a for loop checking every element, therefore the runtime is proportional to the array size = O(N).

You also have to figure that big O is looking at the worst possible runtime and not the average. this tends to make it easy. E.g if you were searching through an array to find if any element is >= 100 and stopping then depending on the contents of the array you might astop earlier or later. Finding out the average is tricky, you need to know how the numbers were entered, did they come from some kind of statistic distribution, etc. However, the worst case and thus Big O runtime is dead easy, assume the only element > 100 is the last element, therefore you have to search through the whole array. Moreover, you are only concerned with the highest order term, so if one part of the algorithm was some complex NLogN... thingy but some other art was N^2 then then N^2 term will dominate for large values so you can just say O(N^2).



Read up on Fibonacci numbers and algorithms - it is a classic interview questions but nicely demonstrates the key concepts and how they relate to different algorithms and data structures.
e.g.: http://www.ccs.neu.edu/home/lieber/courses/csg110/sp08/project/project10/dyn-prog.htm

the naive approach is O(2^N), so when N = 70 it would take over 4 years of run time. A dynamic programming approach takes a few milliseconds.


Dynamic programming is a very powerful concept and worth knowing.
 
How about a bit of advice about dealing with agents? Decided what with only a few weeks left of the year I'd start properly looking on some of the sites, and sent my CV to a couple I saw on CW jobs.

Now I'm being hounded.
 
I avoid agents like the plague. they rarely have a clue what you are looking for and charge extortionate fees on the employer which indirectly lowers your salary.
It is rare for a company to have job positions that they don't advertise and only go through an agency. Sure, they may not advertise but you just need to submit your CV and a covering letter explaining your ability, passion and contribution you could add to the company. On the flipside it can get you lots of interviews.

PS: for the technical stuff have a solid read of Cracking the coding Interview 5th edition.
It is a great guide and i have heard many companies actually use that book to find interview questions.
 
Last edited:
Appreciate the answers here; very useful stuff to know! There's a lot of stuff that I have a fair grasp on but I'm not familiar with the 'official' terms.
 
PaulStat said:
Like I said I'd love to avoid agents, but how do I find the companies without them
Click to expand...

Look on job websites but don't restrict yourself to recent job positing. Just see of a company has ever advertised job with your keywords. then just go to company website and get contact info.

Ask colleagues and friends.

Look up yellow pages or other listings for company names that sound like they might do software, need software etc.

Really it comes down to research to find out what is out there. Its not easy for sure, networking helps though.
 
Last edited:
D.P. said:
Look on job websites but don't restrict yourself to recent job positing. Just see of a company has ever advertised job with your keywords. then just go to company website and get contact info.
Click to expand...

Job websites seem to have adverts exclusively posted by agents. So company names aren't mentioned
 
PaulStat said:
Job websites seem to have adverts exclusively posted by agents. So company names aren't mentioned
Click to expand...

Do a google search for text from that posting, see if you get a google hit.

The websites I've used in the last had a load jobs posted by the companies or had the companies name me tone. This might have changed in the UK since I was last there.


But thT is just one source if possibilities. As I said, it is less about the job postings but the companies. Most companies are willing to hire and good candidate if there is an open position or not, so it is just about find the commonly names.


Do you only want to look in a certain geography region or worldwide? If the former then if possible you can just drive around the streets/technology park to get bussiness names. Really just google detective work should find you a load of companies, not quick and easy though.


I'm kind of doing the same thing as the company I work for is about to collapse. I spent 30 minutes on google maps looking at a technology park this morning and jots down a few names.



In the end you can use an agency to try to get some interviews and company names. Imy experience is you get hounded by stupid jobs that you are not interested in. If you put up with the spam the you might get some good offers.
Be warned though that a lot of companies will never touch an agency, they don't need to. Some will never even advertise a position, they want you to be proactive and approach them and convince them that you would benefit them. Also big companies normally have a careers portal where you can upload a CV , do some.p Tests and then wait until you get an interview request. I'm in the process of doing the latter for large investment bank they never ever advertise positions but I have an inside contact who told me they are always hiring.
 
What are peoples opinions on submitting code after an interview, i.e. what you would've coded if you'd had more time to consider it?

Had an interview today and I was asked to implement a StringBuffer

I did this, I realise the toString is a bit...... well crap

Code: 
package com.testing;

import java.util.ArrayList;
import java.util.List;

public class StringBuffer1 {

  private List<Character> characterBuffer;

  public StringBuffer1() {
    characterBuffer = new ArrayList<Character>();
  }

  public void append(String anotherString) {
    if(anotherString != null) {
      char[] charArray = anotherString.toCharArray();
      for(int i=0;i<charArray.length; i++) {
        characterBuffer.add(charArray[i]);
      }
    }
  }

  public String toString() {
    return characterBuffer.toString().replace("[", "").replace("]", "").replace(",", "").replace(" ", "");
  }

}

He asked me if there was a way I could improve the toString method, I blanked, 10 minutes on the way home in the car. I thought of this solution. DOH!

Code: 
package com.testing;

import java.util.ArrayList;
import java.util.List;

public class StringBuffer2 {

  private List<Character> characterBuffer;

  public StringBuffer2() {
    characterBuffer = new ArrayList<Character>();
  }

  public void append(String anotherString) {
    if(anotherString != null) {
      char[] charArray = anotherString.toCharArray();
      for(int i=0;i<charArray.length; i++) {
        characterBuffer.add(charArray[i]);
      }
    }
  }

  public String toString() {
    char[] charArray = new char[characterBuffer.size()];
    for(int i=0; i<charArray.length; i++) {
      charArray[i] = characterBuffer.get(i);
    }
    return new String(charArray);
  }

}

He also asked for alternatives and I did discuss the possibility of using a primitive char array instead as a buffer, and the buffer grows if there is an overflow.

If I'd have thought of it first I would've implemented this

Code: 
package com.testing;

import java.util.Arrays;

public class StringBuffer3 {

  private char[] characterBuffer;
  private int curIndex;

  public StringBuffer3() {
    characterBuffer = new char[5];
    curIndex = 0;
  }

  public void append(String anotherString) {
    if(anotherString != null) {
      char[] charArray = anotherString.toCharArray();
      int charArrayLength = charArray.length;
      if(overflow(charArrayLength)) {
        characterBuffer = Arrays.copyOf(characterBuffer, newLength(charArrayLength));
      } 
      for(int i=0;i<charArray.length; i++) {
        characterBuffer[curIndex++] = charArray[i];
      }
    }
  }
  
  private int newLength(int arrayLength) {
    return (characterBuffer.length + arrayLength) + 10;
  }
  
  private boolean overflow(int arrayLength) {
    return (arrayLength + curIndex) > characterBuffer.length;
  }

  public String toString() {
    return new String(characterBuffer, 0, curIndex);
  }

}

I realise the interview is done now, but it's really bugging me that I didn't pick up on what he was talking about improving my toString. I'm hoping that the fact that I discussed the possibility of option 3 will count in my favour!

So find a way of submitting the ideal solution? Or don't bother

It was a timed test. Which apparently I'm not very good at
 
You've already done all the hard work now, so what have you got to lose? I'd say go for it, most people would look on that favourably.

I'd just like to say thanks to everyone else who's replied, interesting thread!
 
You must log in or register to reply here.
Back
Top Bottom