Oleg Dulin

What I expect from candidates, Part 2

Two of my former grad. school professors published a short article criticizing the modern academic curriculum as practiced by the majority of the computer science programs. While something tells me that Dewar and Schonberg may suffer from the Auld Lang Complex (diminishment of things present and glorification of things past), I can't help but wonder -- why do so many of the recent graduates from today's programs in comp. sci. have absolutely no depth to their knowledge ?

Someone who has just graduated with a bachelor's degree in computer science must:

• Demonstrate a basic knowledge of operating systems and computer architecture concepts. This includes Turing machine, Von Neumann, NUMA, SMP, multiprocessing, threads, concurrency, locks, semaphors, etc. When asked you should be able to say what you think is the most interesting aspect of modern computer architectures and discuss why.
• Demonstrate basic understanding of programming languages. At the very minimum you should be able to read source code in just about any commonly used language and identify what it does. By the time you graduate from a 4-year program you should've identified your preferred language and be able to discuss why.
• You must have basic understanding of human-computer interaction and GUI concepts. I don't care if the course on GUI design is not required. You should be able to think critically of user interfaces that you use and you should be able to describe the components, the layouts and the event handling of a simple GUI application.
• Display basic knowledge of data structures and algorithm analysis. At interviews I don't ask complex algorithms and automata theory questions. However, I do expect the candidates to demonstrate ability to eye-ball the time-complexity of a search and a sort algorithm.
• Demonstrate basic knowledge of tools. Pretty much all comp.sci. programs make students write simple projects. You have to understand what a compiler does and what a debugger does. If you claim you know how to use a particular OS then you should also be able to discuss commonly used tools and techniques.
• Demonstrate basic problem solving abilities and out of the box thinking. This one is somewhat hard to judge and I've been attempting to come up with a good line of questioning that can help tell a problem solver from someone who requires handholding.
• Finally, you have to be able to identify an area of interest in computer science that you are passionate about and discuss it. You have to demonstrate general curiousity about technology, problems and solutions.

Now, if you have a Masters or a few years of experience, or both. I would like to see the following:

• Demonstrate knowledge of all the basics as above.
• In addition to the basics you should be able to debate the specific implementation of the frameworks and tools you use. For example, a common question I ask at interviews is how does a ConcurrentHashMap work in Java ? If you say you've looked at the source code because you were curious then I will most definitely recommend you to my boss. If you haven't I expect you speculate and discuss pros and cons to different ways of implementing it.
• Have a common theme to your experience and a story. For example, if you have a masters then you should be able to discuss your area of concentration, why you chose it, etc. If you have years of experience then I'd like to see some commonality to each of your projects, some sort of a developing narrative. Noone writes software in a vacuum so you must have some business or application area of interest, i.e. financial, manufacturing, inventory management, healthcare, etc. There must also be an identifiable thread to your contributions -- i.e. improvements to engineering process, software quality, refactoring, reducing costs, etc

Last year I read "Java/J2EE Job Interview Companion" (see my review) and, frankly, I don't think that book is helpful as an interview prep material. I am now contemplating my own pet project of an interview prep guide and I will be posting more ideas over the coming weeks.

What I look for in candidates when I interview them

I was asked to interview a few people for junior-level Java developer positions. In trying to build a general framework for screening I came up with this. For me to give ok to my boss the candidate must demonstrate:

1. Understanding of the language. Even first day out of college they should know the language to be used on the job. In this case it is Java.
2. Understanding of the tools. I ask questions about the basics of using the IDE -- debugger, compiler, etc.
3. Understanding of the technologies. Does the candidate understand the basics of how application servers work ? Do they understand the implications of designing Java software that runs on the servers ?
4. Understanding of the algorithms and data structures, ability to spot inefficiencies.
5. Understanding of OOP, design patterns, and refactoring.

I don't think I am a tough interviewer and generally speaking I don't look for right or wrong answers. I look for critical thinking and curiosity. Without these two I can't imagine the candidate to be a good problem solver or a useful colleague.

Writing clean, reusable code is not incompatible with getting work done

In "Shop Class as Soul Craft" there was a story of an electrician who very carefully laid out the cables and labeled them. When asked why bother because, after all, all of his work will be covered by a layer of drywall anyway, he said something along these lines: "When a few years from now another electrician will come to repair or upgrade something I want them to know a professional did this."

That is how I feel about my code. There is a school of thought that refactoring and OOP get in the way of "getting the work done." I couldn't disagree more. A good software engineer can meet the needs of users and come up with well crafted code that will be used for years to come.

The discipline of software maintenance

I hold a professional membership in the ACM and as a member I receive "ACM Communications" every month. That lets me keep an eye on the developments in my field. Occasionally a blurb pops up that grabs my attention. In the June 2010 issue (Vol. 53, No. 6) on p.7 a letter to the editors caught my eye. Donald J. Reifer writes about software maintenance:

• Support consumes almost as much effort as changes and repairs
  
• Maintenance teams focus on closing high-priority trouble reports rather than making changes
• Maintenance managers must determine what they can do with the resources they have rather than what needs to be done
• Maintenance personell is more experienced since they often have to work on outdated equipment and systems.
• Maintenance tools are inferior and most modern IDEs do not support the work

Software maintenance is a rather understudied and underappreciated area of software engineering. The engineer assigned to the task must exhibit attentiveness and humility not necessarily applicable to new development. Maintenance is a dialog with the person who implemented the system and is no longer around to help. It requires dealing with the authoritative reality rather than asserting a vision of it. It demands a more humble approach that is so rare to find in an industry filled with both barely competent and with grandeur seekers.

Best recommendation ever

The founder of a company I worked for (ConfigureCode) wrote the best recommendation for me on my LinkedIn profile that I've got so far:

Oleg was more than just our Senior Developer at ConfigureCode (and Opence). Oleg is one of those developers that goes beyond the code to understand architectures and business. He is capable of leading a team by example. His strong programming skills allow him to participate, mentor and manage developers. His insight into algorithms and new processes means he is not just coding he is thinking about better requirements which result in a better design.

I not only endorse Oleg but I would work with Oleg again. Oleg has great communication skills and is just an over all pleasure to work with. One of the differentiators I noticed with Oleg is that he is not just about software, he cares about the value of the product, the usability of the product and the over all cost of the product. So while a product may have useful features, Oleg is constantly thinking about so how will people use it and how will a company profit from the idea.

Oleg likes Belgium Beer.

I believe Oleg is more than capable of development, architecture and managing teams. If you have any questions please do contact me to discussion.

Thanks Vish! This is awesome! I really appreciate that. For more please see my LinkedIn profile.

Defining challenge

I define challenge as the level of capacity utilization at which employee's skills are used at 100% and he is motivated to acquire new knowledge. This, of course, means that one employee's challenge is a piece of cake for another.

In software maintenance challenge doesn't come in the form of new technologies or interesting new work. The challenge of maintenance is much misunderstood and neglected art of coaxing a legacy application to do new things. This requires a degree of understanding software engineering that is not always necessary when building new software. It requires care and attentiveness that is foreign to many in the field.

By this reasoning, software maintenance is not only more challenging than building a new system -- but it also requires a completely different level of competence.

On having a life

When I was single my days were simple. I got up around 7:30am, went to work, left the office around 6:30pm. Sometimes I would get absorbed in coding and stay in the office till 10pm. The evenings when I didn't have my NYU grad school classes I went to the Belgian Beer Bar on W4th and 6th.

My typical day now goes like this. I wake up a 5:00am. My wife and I try to get up before the kids so we can get some morning chores done. I shower, have a coffee.

My 3.5 year old daughter gets up 5:30am and for the next hour I help her get herself ready for the day.

At about 6:35am I remind my daughter that it is time to go to school and she needs to get herself dressed. We leave the house at about 6:45am. I drop her off at school at 7:00am and make sure she is all settled and is ready for her day.

Around 7:15am I leave the daycare and drive to work. Driving is not the most optimal way to commute, but it gives me the flexibility I need to balance my work and my life. I keep a folding bike in trunk. On a good day I get to Jersey City in about 40mins, on a bad day it can be about an hour. I park at an optimal spot in Jersey City that is conveniently located within easy reach to NYC or to many employers in Jersey City.

I am in the office usually by about 8:15-8:30am. My most productive time is in the first half of the day and I feel like I get the most work done then. Around 11:30am I get myself lunch. If I wait till noon I will be standing in long lines. I eat at my desk. I try to get as much work done as I can.

My family needs me. If I don't have to work late, I don't volunteer. I leave around 5:30pm, definitely no later than 6pm, but if I can get out before 5:30pm I do. I get home typically around 6:30pm to find my wife dealing with a whiny toddler daughter and an infant boy. I take over the toddler daughter management, help her finish her dinner and take a bath, and go to sleep by 7:30pm-8:00pm. I get about 10 mins of quality time with my infant son before he goes to sleep for the night. By then, I am spent.

I have a life now. I have a wonderful family and I wouldn't change a thing. The kids are only kids for so long.

Those of us in the technology sector see it all the time: co-workers who put in incredible hours coding away as though they have nothing else in their lives. And quite often, they don't.

I used to be one of those people.

[From Nick Bradbury: Don't Trade Your Life for Tech]

We all stand on the shoulders of midgets

I am going to make a bold statement: the vast majority of software code that needs to be written has already be written before. Everything new is based on that. We are all constrained by what's been done before.

As a software engineer I start off with a machine and an operating system, both of which are the wheels few are about reinvent. On top of that there are libraries, languages, compilers, interpreters, and run-time environments.

Add into the mix legacy code, legacy systems, legacy data, mismanaged projects, developers with visions of grandeur and you have one jumbled mess of bad code. Even if I am not expected to reuse legacy code and I am rewriting the system I am still forced to rely on the code before me. I have to learn and understand the intent of the spaghetti code before I venture out and repeat the mistakes. This requires a certain degree of patience and treatment of my job as a representational art dealing with an independent reality -- and it is not always easy.

Problem: You're working in an organization that dictates that you reuse code in libraryX to solve the problem you're working on. Looking at this API, you find a jumbled mess of cluttered concepts and weird hacks, or it doesn't do half of what you want it to do.

Context: This pattern can show up not just with code libraries, but also with general architectures and databases. For example, the organization might be using a hand rolled messaging system with various limitations, or a hand rolled database with peculiar semantics, or a complicated/convoluted/contorted project management methodology.

[From Standing On The Shoulders Of Midgets]

The Joel Test: 12 Steps to Better Code - Joel on Software

I've been reading Joel Spolsky blog lately. I used to follow it closely a few years back and then lost interest for sometime. Meanwhile, I have yet to work in a place that fits all 12 points of Joel's 12 steps:

Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?

[From The Joel Test: 12 Steps to Better Code - Joel on Software]

My ideal job

One is allowed to visualize ideal scenarios, and so I am going to describe what my ideal job would be like. Of course, there are always trade offs and many things to consider when selecting a job -- compensation, paid time off, work hours, career development, location, etc. It is never really possible to land a perfect job, but it is worth it to describe it.

I am a technologist and a problem solver. I solve technical problems. I build systems. I apply technology to fulfill requirements of a business model. Therefore, my ideal job would start off as being heavy on technology. Regardless of what they really do the company I work for might as well consider themselves a technology company. If they see no value in technology they probably won't see much value in me. Technology would have to be such a core aspect of the company's business that they couldn't possible survive without it. To some extent this is why I like working on Wall St.

I am a knowledge professional. I am not a call center operator. I am most productive when given a problem to solve, access to the resources I may need, and the freedom to seclude myself in a private office. The Bionic Office is ideal.

I am a responsible and conscientious worker. I can work without supervision at the office. I can work from home. I can work from a Starbucks locations. I will get stuff done. My ideal boss would not be standing over my shoulder, checking in with me, and assuming I am not responsible enough to manage my time and deliver. My ideal job would give me freedom to choose my own schedule and to work from home as often as I need.

I am a tinkerer and a fixer. I take particular joy in maintaining and improving existing systems. I also take pride in building new ones. I expect both aspects of my personality to be respected. If the company only has a career path for those working on new development and leaves maintainers behind then I would rather not be in a dead end role. But all new development projects eventually lead to maintenance -- meanwhile an engineer's career shouldn't end with the last stage of the software lifecycle.

I am a trusted advisor. Given all of the information I will make the right decisions and offer the best solutions. I don't like secretive clique environments where management makes decisions without involving the engineers.

I like a challenge and I often challenge others, including those in authority. I like to work in teams of intelligent people with whom I can share my knowledge and learn from. I like to work with curious people who care about their work, to whom technology is not just a job but also a key aspect of their lives.

I don't seek management as a goal. I am flattered when my expertise is recognized and I am asked to advise on technology matters or to mentor the team. I will gladly accept a leadership role that evolved organically from my role as a technologist in a team of like-minded and professionals. But advisory and mentorship is where I stop -- I don't get power trips from enforcement.

On the balance my present job covers many of these aspects. I've worked here for five years now and will probably stay here for the foreseeable future. That said, though, I find that in the name of building up my personal brand going on the record never hurt.