With April being the graduation month here in the Philippines, you’ll be seeing fresh graduates in various forums and discussion groups looking for advice on how to pass technical interviews. Here’s one posted over at the PHP Users Group forum earlier today:

Can you help me with this? I’m going to take a technical written exam for a job i’m applying. Here is the list of what are expected on the exam:
-Basic Programming
-OOP
-recursive programming and variables in programming
-? statement
-conditional statements
-loop statements
-flowcharting
-pseudocodes (strings,odd/even)
Can you guys give me tips and heads up on where to focus and what to expect on the exam? The exam will be next week and I want to be prepared for it. Thanks in advance.

PS: Hindi ko alam kung anong programming language ung eexam. (I don’t know what programming language will be used in the test)

Whenever I see these type of questions, the first thing I do is give a ಠ_ಠ to my monitor. The listed coverage above is so basic that every 2nd year college student should have no problem with it.

It’s like a carpenter asking what tool to focus on when applying for a carpenter position: screwdrivers, hammers, saws, or measuring tape? Yes, it’s that basic.

Unhelpful snarkiness aside, what advice would I give to these fresh grads?

There only need to do two things:

1. Relearn the basics

If you’re not confident about the things listed above once you’ve graduated college, it may mean that you don’t have a good foundation with the fundamentals yet. So the best advice I could give for that problem would be to forget everything you know and start over using the following books:

When reading these books, you may find out how outdated or incomplete your college courses were back when you were taught programming. This is normal, and is an important part of the (re)learning process.

While you are reading these books, you may do the second advice at the same time:

2. Practice. Practice. PRACTICE!!!!

Apart from lack of fundamentals, the other reason you might not be that confident in going into a technical interview is the lack of coding practice — you should’ve encountered all of the things above had you coded thousands of lines of code before graduating.

So practice! Go to Project Euler and try to solve the problems! Go to Top Coder and do the same with the High School competitions!

Find algorithms and try to implement them! Start with simple ones like the Sieve of Erasthosenes and Conway’s Game of Life, then move on to progressively harder ones like Quicksort and Dijkstra’s Algorithm.

Also, don’t be content with just writing code; make an effort to read code. Good programmers are like good novelists; they read a lot more code than they write so they know what looks right and what looks wrong.

In other words, if you can’t figure out how to code something, just search for sample code on the internet and study them.

Just to wrap things up, I’ll be commenting on the items in the “technical interview coverage” listed at the start of this post.

-Basic Programming

-…variables in programming
-conditional statements
-loop statements

If you’re not familiar with these after a CS/IT course in college, I really question the quality of your education.

-? statement

It’s the conditional operator, used for writing if-then-else statements in shorthand.

Technically speaking, you really don’t need to use this (and in turn, don’t really need to know this) but there are a lot of cases where the shorter form makes code much easier to read. (And there are a lot of cases where it makes code really hard to read, but that’s another story.)

-recursive programming …

This is recursion. There are two types of interviews that use recursion:

  • The bullshit type that makes you use recursion for tasks that can be done with simple loops like factorial and fibonacci sequence. If you know what loops are (and you should) and what recursion is, this shouldn’t be hard for you.

    Why do I find it bullshit? Because any programmer worth his/her salt knows how bad tail recursion can be in certain languages.

    If a decent technical interviewer would ask me this question, I’d expect a follow up question on how to eliminate the tail call.

  • The good type of interview that really requires recursion i.e. the ones that require stacks and backtracking. For example:

    Given a string of characters, find the longest palindrome within the string.

    These problems may be harder, but they’re very much doable if you practiced the way suggested above.

-flowcharting

As I’ve mentioned in last night’s tweet, flowcharts are cute but useless. Anything less than Data Flow Diagrams or UML Diagrams can be better written as pseudocode.

-pseudocodes (strings,odd/even)

Which brings us to this one. Pseudocode has nothing to do with “strings,odd/even”. My guess is that this just wants the applicant to be comfortable with writing pseudocode that deals with strings. (and numbers?)

-OOP

Now here’s the hard part. Even I didn’t have good OOP knowledge even after graduating from college.

Fortunately, the books listed above have decent chapters on OOP so just read up on the topic and practice.

And finally:

PS: Hindi ko alam kung anong programming language ung eexam. (I don’t know what programming language will be used in the test)

This means the test is language agnostic and you will be coding in pseudocode. Just use the language you’re most familiar with.

If the interviewer berates you for syntax errors on code written on a whiteboard or a piece of paper, you probably won’t want to work in such a company. Trust me.

In closing, most technical interviews are just there to weed out applicants who pose as developers but can’t really write a line of code. So if you really know how to code, you shouldn’t have a problem with them.

And if you do fail, just take it as a sign that you need to practice harder. Unlike in other fields, a few months of practice in programming will actually help you get better jobs.

Tagged with →  
Share →

Leave a Reply

Google+