My Two Cents on Interviewing Software Engineers

In the technology industry, interviewing someone is a tough process. It is a very complex problem that attempts to solve a collection of goals into a [best case] mutually satisfactory outcome. The interviewer needs a person who will fit in the working environment, perform tasks that are expected, has the needed skills, and is competent to do that job, all while avoiding an undesirable hire. The interviewee is looking for a new position in a reasonable environment, with people they can trust, and that helps them obtain the lifestyle/financial goals that they wish to achieve. There are three outcomes of this process: hire, wait for more experience, or don’t hire. Dancing around the decision, or making this process more difficult helps neither party.

What I’ve found incredibly frustrating is the attitude of many of the interviewers that I have been interviewed by. Most of the individuals whom I have been interviewed by have been highly combative. They want you to prove that you know what they want you to know, whilst simultaneously proving that you would be a good cultural fit. For example, smaller organizations will throw out Google/Microsoft like interview questions just for appearances. Is this necessary for determining the quality of the applicant? I don’t believe that it is. Unless your industry requires every engineer to make close estimations, it appears to me that it is more of a way to build an unrealistic ‘tough-guy’ image. There is absolutely no reason for an interviewer to be combative with an interviewee. The goal, on the company’s side, is to find out if the applicant would provide value for the company. If an individual’s average day is fairly easy going, why make the interview stressful? It’s akin to demanding an auditioning actor to recite the entirety of Shakespeare’s work when interviewing for a non-speaking role in a 30 second commercial.

Another issue that I’ve found is the amount of criticism of interview code. I’ve had a range of this: “code portfolios,” sample programs prior to the interview, temporary assignments, IQ tests, talk and coding, and white board exercises. Only a few of these coding practices are reasonable, the others are unrealistic and stressful. The IQ/aptitude test was a part of the application process at IBM. It was a little silly, and timed, but I guess I was within their upper and/or lower limits for acceptance. The test was online and it was after the interview, so it wasn’t so stressful. I’ve had an organization request a coding portfolio; that is a horrible idea. Portfolios are required of those who do visual work, but code portfolios suffer from a lack of context, industry acceptance, and lack of time to compare and contrast multiple candidates’ submissions. I’ve had to work with one group temporarily [after the interview] as a trial period. This wasn’t so bad for a few reasons, one the company paid for my travel to get me there (going from the US to Europe), was only for a short time and lastly, it isn’t unreasonable to ask for this when considering very long distance applications. However, the downside to this is that it negatively impacts the discreteness of interviewing a new workplace.

I tend to like coding samples prior to the interview. If you’re given a problem set to choose from, it gives the interviewee a chance to emulate the conditions in which they would be working in. The interviewee is able to ponder, on his/her own schedule, about the problem, design, code, test, and package the code. I am not a fan of coding on a whiteboard. It is a completely different experience from how one codes. It strips away the tools and contexts, and expects the individual to perform their tasks in a completely foreign way. If the interviewer was asking for high level details, this request isn’t too far fetched. From my experience, there are a lot of organizations that attempt to have the interviewer watch an interviewee code via a live collaborative editor while on the phone. These are some of the worst interviews I’ve ever had. The task is not humanly possible. The tasks are usually set up in a professor/student manner. The process is usually: a problem is presented, thinking occurs, have the interviewee talk through a problem, code while explaining the code, and to use a foreign editor at the same time. To make things worse, this is all done while the interviewee is holding a phone and typing on a keyboard. It is not humanly possible for an individual to communicate, and solve deep problems at the same time, to make things worse you’re being judged at the same time.

Lastly, I have been asked to code up a problem or two, with the interviewer on a computer. This has been done in a peer-wise and non-peer-wise fashion. Usually this involves a small problem, and you’re given a new project in an IDE. At times, this may be a little tough if the IDE is unfamiliar, but this at least attempts to reproduce the working environment.

What are some of the questions that I would like to be asked?

I believe that an interview should be more for an inquisitive time between an interviewer and interviewee. There is no benefit from trying to make a stressful interview even more stressful via combative techniques. So I think there are a few questions that would make it easier:

  1. Ask questions related to the projects that the interviewee has worked on before. [Preferably a non-work based project]
  2. Ask about some of the challenges faced on the projects. For example, if the project required a high level of performance, how did they solve the communication issues between components? If the project dealt with numbers or precision or money, ask how they solved the issues with floating point math.
  3. Ask what an individual project taught the interviewee.
  4. Ask about times where the interviewee has conflict with another coworker; ask how he or she would have resolved the issue. (Don’t ask for opinions or gossip surrounding the conflict)
  5. Ask about what blogs/technical content they follow.

These questions get the interviewee to talk more about what they should be confident on talking about. The questions also demonstrate the ability to work with others, willingness to adapt, interests, technical strong points, experience, passion, and potential weak points. Lastly, to the interviewer, consider the individual that you are communicating, with being hostile won’t do you any favors if you have to work with them later.

“Wanted Java Developer” could you be a little more ambiguous?

I have a bone to pick with the industry I associate with. The tech industry struggles to clearly define the expectations of whatever is desired. This is pretty much a universal issue with the industry. There are always hidden requirements. Job listings are no different.

The bone I have to pick is with the titles/job requirements. One of the worst offenders of this is for a Java Software Engineer. Based on the availability of frameworks, and meta-frameworks, asking for a Java engineer is quite ambiguous. This could ask for a graphics developer, API designer, web developer, Computer vision expert [CV in java is possible with native libraries, trust me!], core libraries developer, or even a micro-JVM developer. The amount of variability with the language makes a generic “Java developer” title frustrating.

As a potential candidate, it is incredibly frustrating to see the “Java Developer” title. Some titles ask for experience in Spring, Hibernate, Solr, Lucene, JAI, J2EE, etc. It’s incredibly frustrating to go into an interview, where the listing asked for all of these and then only be grilled on the minute [rarely used] inner workings of Spring RMI. Just the Spring framework alone asks for a lot. Of all of the potential avenues of spring that one could master are: Message queuing, Web services, Roo, Security, Integration, Web flow, MVC, BlazeDS, Batch, Social, and mobile. That’s not even accounting for the frameworks that you can substitute between the pathways for Spring. I’ve worked with a late Spring 2.x and early 3.0, I was not even aware of the new BlazeDS, Batch, social, or even mobile options for the framework. Things change quite quickly.

Besides ranting, what is the purpose of this article? I believe that the Java title should be a bit more specific. If you want a Java developer that knows a lot of frameworks, still label it as a Java developer position. However, don’t expect him or her to know all of the inner workings: that is just silly. If your business involves multimedia display, request a developer that knows the Java 2D and 3D graphics, and maybe the JAI libraries. There is a lot there for practically any task you want to throw at Java, given you know which library to use.

Scientific or mathematical tasks, ask for a Scientific Java Developer. What libraries should they know? Colt, EJML, JAMA, etc.

Writing a Java API? Ask for a Java API Designer. Expect for them to list their favorite APIs, what works, what doesn’t, and why.

Web applications? Ask for a Java Web Developer. Maybe they should have experience with a SOAP framework, MVC framework, Play, GWT, basic Web skills, and maybe even a non-SOAP based webservice library [REST, Hessian/Binary]. Please don’t use the enterprise title unless you need someone who knows EJB, and/or ESB frameworks.

Moreover as an employer, be more specific the first interview/inquiry on what the job is asking for. If an job application asks for the common ORM Hibernate, how much should one know about it before applying for the position? Should they be able to know how to wire up beans to their DB analog? Should they know how write their own dialect for a new data source? With JUnit, should the applicant be expected to transition your current development methodology to TDD? Should they know how to extend the JUnit framework?

At this point, you should be getting the picture. Different tasks demand different skills. Specify what you’re looking for. Find people that can learn new skills and that are interested in the same problems you are. People who have an active interest can learn what is needed to get up to speed. If you go to a butcher and ask for meat, you’re always going to get what you asked for, but not what you were craving.

Addendum: This can apply to an Erlang, C++, Python, and most other developers. The role of Java currently has such a great demand, and such an ambiguous title, making this article a little easier to communicate.

Lost the Passion for Software Development?

This is a list of potential tips to help a fellow Software Engineer recover passion in his or her work:

  1. Learn A New Language: Stuck with working solely in Java and C++ languages? Learn Erlang, or Lisp. Try out Scheme, Perl, Bash, Haskell, or D.
  2. Learn a New Framework: Some of the frameworks to learn: xUnit, Testing frameworks [other than JUnit],, Apache Tapestry, XMPP, Esper (Complex Event Processing), OpenGL, JasperReports, OpenCV, Win32, OSGi, or even Hessian binary web services.
  3. Revive old projects by refactoring the code to use a new framework. Review code in open source projects.
  4. Attempt to become an expert in an open source project. You might become an authority on the subject, and write a book.
  5. Meet new developers. To do this, branch outside of your company and go to user groups related to the language. JUG for Java groups, LUG for Linux user groups, NUG for .NET user groups etc.
  6. Read and listen to lectures on InfoQ.
  7. Take a “Thirty Day Challenge” by coming up with a complex application and writing it in a completely unfamiliar framework or language. Something that would be rather unique, write a web application completely in Prolog or Erlang. I haven’t heard of anyone that has done that yet, but it would be rather interesting.
  8.  Annoyed with an application, language or framework? Fix it. If it’s open source, then write a fix for it and publically submit a patch. If it’s due to a closed source application, then rewrite the main interface [if it connects to a backend service], or rewrite the application completely.
  9. Have a business idea? The book “The Lean Startup” suggests that startup-interested developers should create a stripped down demo, to gauge market interest.
  10. Add new “favorite tags” to your StackOverflow account. Look for questions that contain lots of votes. Look for questions that have not been answered in a long time, research a solution and answer the question.
  11. Find ways to make your current job/task easier. If you are spending a lot of time writing the same type of unit tests over and over again, find a way to automate this, or write your own domain specific framework. Even better, write a Domain Specific Language for the current development project.
  12. Use coverage tools to find new places to test code that is currently untested.
  13. Read research papers. This is typically a very dull task, but there are some quality papers available. It takes some effort to find those papers, but the ones that are well written are worth ones effort.
  14. Hack: [I’m not responsible for unethical/illegal actions, I would suggest doing these things only for personal interest] Setup a VM to learn how to exploit system services, learn how to perform a privilege escalation, learn how to write a buffer overflow and run shell code, learn how an intrusion detection system works and attempt to exploit them, and attempt to crack legally obtained software.  [I advise that the reader do these things ethically (don’t share a software crack). The reader is responsible for his or her own actions. ]
  15. “Hack Hardware”- Write an application that interfaces with an Ardinio device. Root an Android or Apple phone.  You could also go the route that Linus Torvalds went, take data from existing devices and write an application that interprets the data. His project is SubSurface, its designed to take the data from a dive-computer, and to transform it into something the user can add notes to, and visually interpret the data. Write software for an embedded processor (FPGA, Basic/Java stamp).
  16. Learn how to make your own operating system. Take a Gentoo distribution, and reconfigure everything. Try out a real time Linux distribution.
  17. Look for project suggestions on Stackoverflow. There are quite a few questions from students asking about project ideas.  One popular suggestion is to write a plugin for a popular game. From my understanding, one can write a plugin for Civilization 4 by using Python.
  18. Find ways to make your job more fun, or easier. Identify tasks that are uninteresting or tedious and find a way to automate them. Learn how to configure and/or extend a build tool. Learn Ant, Maven, or Gradle.
  19. Take a vacation: Over-working one’s self is not an achievement, no one is impressed.

Lastly, (This really isn’t considered to be a tip) to help connect with others who have a similar interest to what you’re doing, write about your attempts, successes, or failures in a blog. Even if you decide that your current job is not fulfilling, then these are things that you can mention on your resume or future employers can see on your blog.

You’re a developer, as a developer you have the unique ability to create things. There is very little holding you back from developing something you want.

Have I missed some important tips? Have these tips help you? Are there any languages or frameworks that one should study? If so, leave them in the comments box.

Selling Technology Solutions to the Classroom

Technology, since the introduction of a computer that doesn’t take an entire room, has always been suggested for educational purposes. Technology is sold as an existing off the shelf solution for teaching the youth of the country that it happens to be in. Policymakers and lobbyists tend to sell the idea of technology as an easy solution that just takes money to solve a massive problem.

When an education organization purchases a technology solution many things happens. Typically, given a healthy market, products are evaluated, money is appropriated, and the solution providers bid [through their price, and service offerings]. The goal in this market is to provide business for the producer through a bulk sale, and reduces the price for the consumer [the people who run the educational organization]. This is the only place where the ultimate beneficiary, the students, is represented is by the purchaser of the products. However, since price is a consideration in the sale, the people who ultimately use and learn from the product have to compete with price.

Approximately fifteen years ago, the utopian goal of “high class education” was to have popular educational software or to have internet access in the classroom. By putting this in the classroom it was assumed that students would immediately consume it and use it to fulfill academic interests. Well intentioned as this might be, it wasn’t the case. Few students used the internet for research, and for those who did typically did, performed poor research. The research came from poor resources, and nothing was taught about how to identify a creditable source. However, can you blame the ten year old, teaching him about creditable sources isn’t extremely easy to explain when they’re struggling on algebra. Most students in schools used the internet to fulfill their immediate, typically non-education related, interests.

I would argue that most students below the age of mandatory education are unable to determine what subjects are the best investments of their time. Mandatory education provides a basic understanding of our world and the options available. It provides an understanding for the person that options exist outside of their small town or city, and that society is no longer a basic rudimentary system of barters and trades or tradition based.

Recently there has been a lot of hype over the use of embedded systems. This started with the introduction of “learning toys.” Some of these include {{LeapFrog}}, and {{VTech}} related products. Typically the premise of a learning toy is taking simple concepts, dressing them up in cute and popular characters and making an electronic version, which can be easily purchased at the local toy store. These are an easy way for a child to reinforce what is taught from another source, however, they are not a great teacher.

One of the more recent fads in technology purchases in education is the use of iPods, iPhones, and iPads. Ironically, these are all produced by the same company, which reduces competition in the market. These purchases are typically favorited by those who have a financial interest or for those who deem it hip. These devices are not built for educational use. These devices are all built to be generic multi-use devices for communication, or entertainment. Many argue that these devices can be used educational purposes; however they were not designed to entertain the needs that an educational experience requires.

For example, if an {{iPad}} is used for an educational purpose, what stops the user from switching to or texting their bff Jill when the material becomes dry and uninteresting? If anything, an iPad, in this manner, cuts down on educational value. The cost of the switch in context [going from information to a pleasure seeking mode] eliminates analysis on the material that was uninteresting. Without the device, the user may wonder why he or she did not like the subject or why it may be dull.

Additionally, the issue with selling devices that were mentioned is ignoring the actual value they may have. The value of an iInsertNameHere is completely reliant on the applications that are installed and the use of them. The users of the technology will ultimate install what they want on it. Why install the “utimate visual guide on history” when you can install the latest fart application for only $0.99 (now reduced from $50). The only few applications where I can see a tablet that would be useful for education is for reading material (books) or music (a Finale like application). However, typically the cost of the books, in the format for the tablet, and the device itself would never be less than the cost of the books themselves. Given that the only situation where the statement would be false is for rare books. Given a situation where everyone purposed books as ebooks, that possibility may not be far off.

Now for the content that is less doom and gloom. Technology can enable people to learn. There have been success stories. Two of the best success stories are electronic publishing of scholarly journals, and the second one being the OLPC project. Electronic publishing of scholarly journals, attempts to help the academics field to reduce the publishing of multiple research attempts of the same findings, create new fields of study, and providing access to academic materials to more people than ever before. Electronic journals are typically subscribed to by universities and access is provided to students. Without electronic access, this would become quite expensive at universities with large amounts of students (with a high demand for articles).

The second success story is an odd one. The project is the One Laptop Per Child project. This project’s goal is to put MORE computers in the hands of more children. However the difference in the people who are getting the machines and the ones I was ranting about before, is that these consumers are children in developing nations. The project is not putting laptops are specifically designed for situations where the internet may not be widely available, or electricity may be a concern.  Additionally these are designed for locations where educational materials may be rare or outdated. The main characteristic that makes this project successful is that these laptops are not built to be general purpose entertainment devices. These devices are created to limit the applications that the people can use.

When I was the target for these educational devices, also the time of the dinosaurs, there were a few educational games that came to mind. These games were “Mathblasters”, “Where in the world is Carmen Sandiago,” and “Oregon Trail.” These were fun games that weren’t designed to replace the educational experience.


Review: “Fooled By Randomness” by N. Taleb

{{“Fooled by Randomness”}} is a book about the negative consequences of a dynamic financial market. More specifically, the book’s focus is due to the lack of a balance criticism of the potential negative outcomes and the evaluation of performance in the market.

There are some main features of the book that could be considered to be strong points. One of them being the topic of the book, compared to the neighboring books in its genre. The book attempts to debunk the hype surrounding popular strategies as being luck rather than an effective strategy. Another strength this book accounts for is randomness. It mentions that randomness may account for many successes that individuals attribute to events. Lastly, I must commend the author for advising the reader to stay out of short term markets. Short term markets are highly volatile and are not for individuals who cannot afford a loss.

Despite the redeeming qualities, “Fooled by Randomness” has a fair amount of distracting and vexing issues. Mainly the issue is with a personal bias. The author speaks with the reader in parts of the book and brags about how everyone is foolish not to see his point of view. For example he describes a radio debate, in which the radio host is talking with him about how a market downfall caught investors who had not properly considered the risk. His retort in the book was that he had been warning “these investors” for years.  This strikes me as rather off putting and ineffectual to put in the book. Assuming he has been issuing warnings, shouldn’t one consider the lack of response as an indicator of ineffectuality’s in communication?

Halfway-through the book I started to wonder: “Who is the target audience of this book?” Earlier in the book, while he is bragging, it’s obvious that he is targeting serious day traders and employees of investment groups. However, later in the book he attempts to debunk the effectiveness of these people. For example:  For brokers he claims that the people with a history are merely people who had gotten lucky. For analysis, they were merely lucky that history had a tendency to repeat itself. For academics, their work was really only good for the time period that they were in, and that it was too little too late (complex systems researchers).  I was quite shocked about his dismissal of Complex Systems Researchers. Typically Complex Systems advocates promote the idea of randomness influencing the system, and they can account of it.

Lastly, this book leaves me with the question:

If people are able to consistently make money on the market, then how do you successfully evaluate performance? His arguments attempt to ignore performance and claim that everything is merely luck.