This is a brief but concise summary from Programming Interviews Exposed.
What the interviewer wants is to see your thought processes as you work through each stage of the programming problem.
Even if you immediately know the answer to a problem, just don’t blurt it out. Break the answer down into discrete steps and explain the thought processes behind each step.
Demonstrate that you have logical thought processes, are generally knowledgeable about computers, and can communicate well.
Keep talking! Always explain what you are doing. Otherwise, the interviewer has no way to know how you tackle complex programming problems.
- Make sure you understand the problem.
- When you understand the question, try a simple example.
- Focus on the algorithm and data structures you will use to solve the problem.
- Explain yor solution to the interviewer.
- while you code, explain what you are doing.
- Ask questions when necessary.
- Test your code with an example.
- Test it for all error and special cases, especially boundary conditions.
WHEN YOU GET STUCK:
- Go back to an example.
- Try a different data structure.
- Consider the less commonly used or more advanced aspects of the language.
Some weeks ago, thank Alan, I started working at a little software company: Caffeina (or IQ Business, it’s the same).
After a little interview with whom is in charge, he assigned me my first project, which consists on get a PDF from a JSON (long story).
- The Bad. I have to write it on PHP:
I don’t need to say that PHP sucks. Nevertheless, as Jeff Atwood says: It doesn’t matter.
From my perspective, the point of all these “PHP is broken” rants is not just to complain, but to help educate and potentially warn off new coders starting new codebases. Some fine, even historic work has been done in PHP despite the madness, unquestionably. But now we need to work together to fix what is broken. The best way to fix the PHP problem at this point is to make the alternatives so outstanding that the choice of the better hammer becomes obvious.
- The Good. Everything else:
The simple fact of being part of a software development organization without having finished university, it worth it. Regardless all I can learn and practice, that finally I have something to add to my resumé, that I have something to do on vacation and that I am advancing required internship.
I tend to be a little pessimistic sometimes, I can find the negative side to things easily. However, I also know an am conscious of the benefits y opportunities that arise to me.
So, despite I’m programming in PHP, that is like building a bookshelf with a shoe and a glass bottle, I’m glad I can grow and learn here at Caffeina.
To become a journeyman, you will need to have a passion for software craftsmanship. Apprenticeship Patterns.
What is this all about?
Training for a code interview at any company is a tough process. You must master the basic notions of programming, algorithms and data structures.
Once you decided to apply for a job or a summer internship, you have to practice a lot. I recommend this website as well a some others to get some clever problems.
Here is a step by step process to take hands on practice:
- Use paper and pen. In most cases, the interviewers don’t give you any chance to code on a computer, so you have to practice this way.
- Be systematic and careful. When the interviewer gives you the problem, he doesn’t give enough specification about the problem, so you have to consider the possible answers and ask the right questions. Don’t rush to code and proceed carefully.
- Try to explain your code in English. When writing some code, try to explain loudly your damn implementation!!! Even if you make your code as self explanatory as possible, is better.
Following these advices and reading some programmin books, you will increase your confidence and your code as well. Try to make at least an exercise every day.
What makes a good method?
“The specification should be coherent: it shouldn’t have lots of different cases. Long argument lists, deeply nested if/for/while/switch statements and boolean flags are a sign of trouble.” – MIT 6.005 2011 lecture 3.
A method should just do one thing. Handling an error is one thing. So, how do we handle errors?
The Java experts and fans preach the use of checked exceptions on some situations. But I agree with Bob Martin (Clean Code book) when he says that checked exceptions are an Open/Closed Principle violation. They can sometimes be useful when writing a really critical library (you must catch them), but in general application development the dependency costs outweigh the benefits.
Another way to handle some errors is returning special values such as null or constant errors codes. But I’ve experienced the suffering of writing and reading ugly code with nested if’s or while’s just asking if object.method() != null/-1/Class.ERROR_CODE. To avoid that kind of nasty code, don’t return null, don’t pass null and don’t use error codes of any type. Use (unchecked) exceptions or return a SPECIAL CASE object instead.
On the other hand we have seen that exception could confuse the simple communicated main flow when catching them. Then, let it be your last resource: express control flaws with sequence, messages, iteration and conditionals (in that order) wherever possible.
When you could do something with a loop or if the server class has a boolean method that verifies for you the possibility of doing something, don’t try and catch.