How To Nail A Job Interview

What is it that certain people say or do during a job interview that makes them stand out? Why do some people struggle to find work, while others land a job in no time? I wanted to know, and the only way to find out was to experience the interview from the other side of the table. If I could be the one asking the interview questions, not answering, I could see first hand what made candidates stand out. I could then take that knowledge and cater my behavior in any future interview to give myself the best chance of getting hired.

This fellow recorded interviews, highlighted key points, and posted both here.
(via Seth)

People in Pain

Most would agree that it is probably impossible to “reason with” people who are in pain since they don’t often act in a manner that you would expect (read “normal”). The trouble, though, is that often times you can’t see their pain, and that a lot of people today seem to be in it. It is no wonder why you might have noticed that so many people seem to “act strangely” these days.

The contentment of content

A few weeks on a PBS television show hosted by Alan Alda the scientists being interviewed were talking about the “Contentment of Content”. They said the the research shows that most humans learn the bulk of their knowledge (in particular their approach for all sorts of problem solving) younger in life and never learn any new approaches later on because it would just show them how much they don’t know. In other words; it would require the act of learning and that takes work. They go on to explain that in fact, this approach not only happens at the macro level in life but also in the macro level for particular areas of expertise. For sake of discussion, I would focus on programming.
The idea is that once you learn how; you are very, very unlikely to learn “new ways of doing it”, and why would you? It makes you feel bad since it makes you look like you don’t know what you are doing. It is also very, very unpopular to admit that you don’t know everything (I wonder if it has always been this way?). This is unfortunate because most of us really never learned how to program well and in fact seems to be the complete antithesis of the behavior and approaches that are likely to have made you successful as a programmer in the first place.

Lisp as a crucible

Scheme and Lisp force you *think* from the get-go. Most engineers and programmers hate to do that and it makes them uncomfortable. Starting a program in Java or C is easy. There’s a pile of boilerplate you can type without thinking about it, and it `feels’ like you’re programming. Then you have to haul out the bag of tools like the compiler and the linker and makefiles or ant. There’s a lot of busy work needed just to get going, and you feel like you’ve accomplished something.
In Scheme or Lisp, you start it up and there you are at the REPL. You have to decide what your program is going to do. You can’t waste time writing boilerplate (it’s unnecessary), designing data structures (just cons one and specialize it later), figuring out how to build complex inheritance hierarchies (do that once you know what you are doing), you have to dive into the problem right away. If you are willing to make mistakes and learn from them, then the REPL is a great place to play. If you prefer to plan ahead so you don’t make mistakes, a REPL is a very uncomfortable place to be.

— jrm
Having experienced the “discomfort” myself, I recognize now that this development approach acts as a mirror to your strengths and weaknesses. It reveals, very very quickly, whether or not you really have got a grasp both on the problem and how you plan to solve it. There is no where to hide! It is great.
(via R6RS)

A culture of problems

It seems like my culture has expended a great amount of effort in teaching the individual how to identify and report on the sad state of affairs which he is in, but has not taken the next logical step by teaching him how to move beyond that state. He is a man who knows how to identify problems , with no chance of solving them. This is a cruel punishment that has created a culture full of problems seemingly without solutions.

Different approaches to shaping code

It is fun to see how different people solve the same problem in code because you often learn new things in the process. In this thread in comp.lang.scheme, the original poster asked about how to define a particular shape of code, but without using non-hygienic macros. My approach is posted within the thread.
The solution itself is no where near as interesting as how it was reached. Basically I followed the lessons that I have been learning by studying HtDP, and the result was basically that the solution “wrote itself”. Granted, I have not reached a “Design Recipe” for writing macros (I suspect that there is not such a recipe in the book); but the disciplined approach may be followed all the same.
Everyone who wants to become a better programmer should read HtDP!

Interesting 2009 ACM SIGs

Sometimes people ask me whether or not an ACM membership is “worth it”. The special interest groups are one reason to join. Here are some that look interesting:

  1. SIGAPP: Applied Computing
  2. SIGARCH: Computer Architecture
  3. SIGART: Artificial Intelligence
  4. SIGCAS: Computers and Society
  5. SIGCOMM : Data Communication
  6. SIGCSE: Computer Science Education
  7. SIGDOC: Design of Communication
  8. SIGIR: Information Retrieval
  9. SIGITE: Information Technology Education
  10. SIGKDD: Knowledge Discovery in Data
  11. SIGMOBILE: Mobility of Systems, Users, Data & Computing
  12. SIGMOD: Management of Data
  13. SIGOPS: Operating Systems
  14. SIGPLAN: Programming Languages
  15. SIGSAC: Security, Audit & Control
  16. SIGSOFT: Software Engineering