Older blog entries for idcmp (starting at number 69)

Write Better Comments by Tomorrow Morning

I've spent some time recently trying to improve my code comments.  Most of us just write comments without much thought and carry on with the task at hand, however after a couple of weeks of iterative improvement I have some really simple tips that will make you write better comments tomorrow.

Tip 1: Delete Bad Comments

If you're working on a large code base, you'll invariably find some comment that's questionable, but sometimes you'll find comments that are even worse, and those comments simply need to go.  To me, the two kinds of comments that fit in this category are:

1. Machine generated comments: These tend to be blatant and useless.  "The getFoo method gets Foo." or "The isNotEnabled method returns the value of notEnabled.".  If you're using Eclipse, the shortcut Ctrl-D can be used to delete a line and these comments are ripe for the killing.
2. Lies: Over time code is refactored, shaped, copy-pasted, "fixed", outsourced, insourced, sold, bought until it eventually winds up in front of you.  During all this ebb and flow, some comments don't keep up with the code.  If the method signature you're looking at is "public List obtainShipments(Locale locale, Country country);" and the comment is "This method will return true if the system can ship to the given country." then you know it's wrong.   If this is not code you're currently cleaning up, then delete it.  

"Tables represent a location in a restaurant where customers are served food.  Restaurant Customers attach themselves to a Table which is then served by a number of TableWorkers including the Server Employee and TableCleaner.  It is often allocated by the Reservation system, check CustomerSeater for how Customers are seated.  Constructed Tables usually come from the TableFactory and are always added to the RestaurantBuilding."

Syndicated 2011-09-17 04:25:00 (Updated 2011-09-17 04:25:25) from Idcmp

Technical Debt

Our build came up recently in a planning session at work. It's a standard big ball of mud, with hidden knowledge all over. It's frail, inconsistent and unhelpful, it's complicated to work with and almost nobody ever gets their local build past "good enough for now" to "working well".

This has been an issue for a while and it hadn't been given the proper attention to be improved. Every change had been reactionary to various needs and it had changed hands so many times that any beliefs or design philosophies it had were long lost.

Syndicated 2011-03-30 04:07:00 (Updated 2011-04-07 23:08:43) from Idcmp

Who Owns Your Code?

At work, our marketing team is in control of deciding where development spends time on products. This is an effective way to ensure that our product meets the needs of the market we're in.

In fact, I would say we have an effective backlog of "big features" that are desired by our target market. We're only limited by the resources we have on hand to deliver these features. Therein lies the challenge; almost every feature is done on a tight timeline, and once it's in a non-laughable state, it's released and the team goes on to the next big feature. No time is really spent revisiting the overall design of the product, or just bringing its dependencies up to date.

In a previous workplace, the development team had strong say on what was worked on. This was an effective way to ensure the product was relatively nice to work on and its technology up to date. New features were strongly scrutinized and often there was a focus on picking newer technologies that made it easier to develop and service. The challenge was we'd fall behind on bolting on new business features from time to time.

In yet another workplace, our SEO team had the strongest say in what happened. Our main products were publicly accessible websites, but I feel like this was a pretty unique situation. Many technical decisions had to be discussed with the SEO team (which CMS should be chosen, which captcha system should be employed, etc..) and everything from character set encodings, performance trade offs and cache expiry times needed to have their approval. Our challenge there was that the success of some SEO practices are not easily measured, it was difficult to assign a ROI on particular decisions.

Who owns your product? How does that shape it?

Syndicated 2010-10-22 03:05:00 (Updated 2010-10-22 04:45:46) from Idcmp

Negative Velocity Developers

I've worked on a handful of projects over my career where there's been a developer that I've started to coin as "negative velocity".

Syndicated 2010-10-13 03:24:00 (Updated 2010-10-13 03:58:44) from Idcmp

What Your Hiring Process Says About You

1. Longest: Archiving Company

As a referral, I was spared an initial phone screen and instead was brought in person to meet an operations manager. His questions were non-technical and focused along the "How well do you deal with conflict? How well do you deal with challenging people to work with? Have you been in an environment where people were difficult to get along with?". We ran over time and I was asked to come back to talk to a project manager.

I returned a few days later and the interviewer was reading off situational HR questions, all with a tilt toward conflict resolution.

A few days later, I was asked to complete an assignment - write a service with certain features, complete with documentation and tests. Unfortunately I received the assignment on a Friday and was told it had to be completed before Monday morning. This was a surprise and a bit of a disappointment as it conflicted with birthday plans I had that weekend.

A few days later I was brought in for a third interview with a developer, project manager and product manager. Very few questions were asked about my assignment and the developer asked me some technical questions (some were unrelated to the problem domain they were in). One was my own question that my previous co-worker had brought with him to the company! Further general questions about process followed from their project manager and product manager.

As the interview was closing up, I discovered they'd like me to write two tests: a number matching test and an IQ test. Both timed, both while a loud lunch party was happening through the adjacent wall. The number matching was a doubled-sided, double-columned list. Each entry had a hand written number and a printed number; I was to mark an X on the ones that differed. The IQ test was pretty standard with tricky logic, English and math questions.

Two days later I received a call from their receptionist saying they were no longer interested. Naturally I contacted my reference to find out more. He responded that as far as he knew, they were still discussing it. He confirmed this later, it was a mistake on their part.

The next day he contacted me with their decision; they were no longer interested. Infact, he said that it was a mistake to even begin the interview process with me as they weren't looking for me.

(Had they been interested, I would have been asked back for an additional interview with the CEO.)

Notes

Needless to say I was disappointed in this process and if it wasn't for the initial reference, I would have given up on this path much sooner.

Explain the workflow to the candidate. Before I started the process I was told it was similar to a previous company I worked at. It was most definitely not. Not knowing the steps in the hiring workflow, a candidate has no idea that he's about to invest a dozen hours.

Screen for culture. Every organization has a different "culture", and it's important to double check that a person will fit in with the existing employees (or if they'll shake things up in a good way!)

Your questions will reflect what a candidate thinks is important to you. When three separate employees ask questions about navigating difficult people, constantly changing requirements and micromanagement, this is what your candidate will think your place is like. If you ask questions about networking protocols or multi-threaded programming, then your candidate will feel the position will involve both. When I asked "Do you use the technology you're asking me about?", I was surprised their answer was "Not really.".

Sell the company to the candidate. I was walked around the development area on two occasions and got the feel of the environment. I was told about some of the unique perks of the company too. This kept me interested.

Involve only the right people. Out of the five people who interviewed me, one was for technical purposes and the other I would potentially be reporting to. The other three were brought in "just to meet me" and "had no real serious questions to ask". As a candidate, this tells me your decision making process requires people who may be uninvolved with a decision to approve.

Limit an interview time. After about 90 minutes, my ability to continue to answer a barrage of questions begins to diminish. After two hours, I really felt that writing a surprise number-matching and IQ test was quite unfair.

Hiring processes should be fail-fast. As soon as an organization realizes it's not interested, the process should stop. Clearly this one suffered from poor internal communication and lack of direction. Consuming not only my time, but employee time too.

The "assignment" was an interesting project, but given the investment I made and how little it was referenced, I was quite disappointed to waste my time on it. I got the feeling the developer hadn't had time to read it, or that this was just an extra step he disagreed with. The length of this process gave me a lot of experience in what not to do. Had I been accepted, refactoring the hiring workflow was going to be a personal side project.

Shortest: Payment Company

Reading up about the company, I figured that I would be a good fit. I emailed a simple cover letter with some specifics of where I'd fit in. Their CTO responded back and we set up an in-person interview.

The interview with the CTO went well, but he was hoping to have me fill a different role than I was looking for. I met after with two of their developers who were prepared to ask me questions relating to the other role and were ill-prepared to ask me Java related questions.

The next day I heard back from the CTO; his team didn't feel I was Java-savvy enough.

Notes

Short, and sweet. Within a few days this company came and left my radar.

Know what you're looking for. Before bringing in candidates, clearly define the role you're looking for. If you're not sure (it happens sometimes), then spend time defining what you're not looking for.

Be prepared. Having stock questions to get a conversation going is fine, but if you haven't read the candidate's resume and don't know what to expect, you'll be ill-prepared to ask the right questions to find out their skills, and most likely opt not to hiring them simply because of this.

They did an excellent job explaining the technology, where they were going and what challenges were ahead for them. The developers I chatted with were interesting, but since they had a "systems guy" and not a "Java guy" mindset, they didn't know what to ask.

Accepted: eCommerce Company

Did some research to discover they'd been looking for someone to fill this position for a while, skipped their online application form and found the email address for hiring. I had customized my cover letter to ensure they realized I was looking for a specific role and highlighted how my experience meshes with what I was looking for.

I received a call back from their hiring team and we set up a phone screen. During the phone screen we discussed what I was looking for, salary expectations, and more about what the company does. From there I was told there was an online Java quiz to do.

The quiz was timed and fairly wide reaching.

I heard back a couple days later that they would like to schedule an in-person technical and HR interview. I asked if this was the interview or if there were multiple steps. At the time I was told that this was the interview, so I fit it in the day before I left on a trip.

I met with a developer there who knew his stuff, and he asked me a stock set of questions and asked me to clarify something from the quiz. Apparently I had got one question wrong but they were still interested. After, I met with the internal recruiter and we talked more about the company and where things were. She let me know that there were two more steps: a refactoring exercise and a second interview.

My first interview went well and I received the assignment while on my trip. Once I returned I sent back my answer and a couple days later I was asked in for a second interview. The assignment took probably an hour or two.

This interview I met with their development manager and we discussed my solution, my decisions, alternatives, drawbacks and technology in general. Later I met with their CTO who asked me some higher level questions.

Then I waited. After what seemed unusually long, I was asked to provide references. After I did, it took an additional week to check them; mid-week I was told why. The company was making some internal changes and this role may not be exactly what it initially was. After discussing it further, I was still on board and was asked for a third interview - more of a just a chat - with the person who would signoff on the hiring paperwork.

I was in the next day and chatted with the VP in question for approximately 10 minutes and he was sold; an offer was made later that day.

Notes

Internal political changes made this hiring process a lot longer than it should have been, and being accidentally mislead about the hiring process was a bit of a disappointment.

Funnel Requests. A month prior to emailing them directly, I had filled out an online application form on their site and never heard from them. Since I felt I was a strong potential, I skipped that step when I later saw the role was still unfilled. I still wonder where my first application went.. Make sure that all different interfaces candidates can apply through are given equal priority.

Have Discussions. In a previous company, I would bring whatever problem I was currently tackling to the interview and ask the candidate, providing as much background as I could. We'd work through it together and see where we got. Having a refactoring assignment to chat about simulated this and turned the interview from Q&A to more of a free flowing discussion of ideas.

Summary

The eCommerce Company with their phone screen and online quiz had a "fail-fast" process, and I met only with relevant people. They mostly knew what they were looking for, but internal change made the hiring more challenging. I only answered a handful of direct "fit" questions. Everyone I chatted with was open about the challenges they were facing but also quick to highlight some of the great things they really liked. I discovered that both the quiz and the assignment came from existing weaknesses in their team and code base.

The Checklist

• We explain our complete hiring workflow to candidates up front and keep them informed of their progress.
• We will stop the hiring process as soon as we feel the answer would be "no". Our process is optimized to make this happen as soon as possible.
• We limit the time an interview will take, but will cut it short if the answer is a definite "yes" or "no".
• All potential candidates which enter our hiring system are treated equally, regardless of source.
• We ensure candidates will be a good fit with the rest of the people here, and we feel we can do this mostly by discussing relevant topics with them.
• Our interviewers always take time to prepare before an interview.
• Our questions are relevant to the company, technology and role we're looking to fill.
• We know the specific skills needed to succeed in the role we're looking to fill.
• Our hiring process includes conversations with candidates similar to the ones that we have internally already.
• We involve the fewest people necessary, each person adds unique value to the process.
• We're honest about our challenges, and we mention the great things about our company throughout the hiring process.

Syndicated 2010-03-10 23:55:00 (Updated 2010-09-27 01:16:32) from Idcmp

6 Mar 2010 »

Winner of the Worst Java API Award Goes To.....

One of my Java interview questions revolves around the best/worst Java APIs a candidate has worked with.  Tiago Fernandez has thought to take this question to the next level and posted a poll.  While he had less than 100 respondents, it meshes pretty closely with my experience, so I would say that the results are pretty accurate.  Check out the winner of the worst Java API.  Now, how long will we have to wait for JSR-310?

Syndicated 2010-03-06 17:46:00 (Updated 2010-03-06 17:46:17) from Idcmp

24 Feb 2010 »

My Java Developer Interview Questions

Here it is! Many people have asked for this list - it's one I built, borrowed and tweaked over the years. I place a lot of value in "I don't know" over inventing answers as that's what I'd expect a colleague to do.  

It's really important to tailor questions to each candidate.  I'm a strong believer that a smart, experienced developer can pickup new frameworks, APIs, etc, so a lot of these questions are not Java specific.

Know the answers to any of these? :)

Difference Questions


These are really great kinds of questions, candidates can talk approach the answer however they feel comfortable and aren't required to give "definitions" of things.

1. What's the difference between TCP and UDP? (if they know, follow up asking about UDP vs ICMP)
2. What's the difference between Bandwidth and Latency?
3. What's the difference between an Inner Join and an Outer Join?
4. What's the difference between NoClassDefFoundError  and ClassNotFoundException?
5. What's the difference between SAX and DOM?
6. What's the difference between a Thread and Process?
7. Order from slowest to fastest: register read, disk seek, context switch, read from main memory.

Design Questions

1. Let's say you're reviewing (or writing) a simple system that requests an email address, a password and comments (in a textarea) then stores those values in a database. Pretending performance isn't an issue, what kinds of things would you ensure in place before it went live?Sometimes candidates would need some assistance on topics (security, usability, database schemas).
2. Let's say McDonald's has asked you to develop their "N millions served" counter for their main website.  This value comes from a slower system (via HTTP).  Talk a bit about how you would design this.  
3. How do you traverse a cyclic graph?

Java Specific Questions

1. What is autoboxing? Had any problems with it?
2. Every worked with JMS topic/queue, clustered?
3. How are Servlets and JSPs different?
4. What does 'final' mean?  Ever worked with a class marked final? (bonus points if they laugh on the second question)
5. What does 'static' mean?
6. List and describe different access modifiers.
7. How would you diagnose a memory leak?

Random Grab-Bag Questions

A bit of systems, object-orienteering, and such.

1. How do you check error conditions in bash? (If they list shell scripting)
2. What's the difference between lazy and greedy regular expressions?
3. What's a context switch?
4. Ever worked on an "AJAX"y system?  What challenges did you run into? (a little bit dated now I guess!)
5. What's a deadlock?  How do you prevent deadlocks?
6. What is Polymorphism?
7. What are the characteristics of a singleton?

General Opinion/Discussion Questions

1. What makes a good build tool?  What makes a bad build tool?
2. What's your favourite/least favourite API/package? Why?
3. Have you worked on a high-volume system before?  What is "high volume" to you?

What have you been asked before?

Syndicated 2010-02-24 22:08:00 (Updated 2010-02-24 22:08:25) from Idcmp

22 Feb 2010 »

97 Things Every Programmer Should Know

Short on the heels of the now-lost 97 Things Every Software Architect Should Know comes a similar list for developers.  It covers a wide variety of ideas from ethics and requirements to code formatting and testing.  You can buy it from O'Reilly or check out the 97 things online.

Syndicated 2010-02-22 20:53:00 (Updated 2010-02-22 20:54:58) from Idcmp

27 Jan 2010 (updated 27 Jan 2010 at 23:07 UTC) »

Four Easy and Practical Tips When Visiting Vancouver for the 2010 Winter Olympics

I've lived in Vancouver for a while now, and realize that you (and 2.3 million of your closest friends) may be coming to visit for the Winter Olympics. Here are some dead easy tidbits that will make your stay more enjoyable. You may want to bookmark this post for while you're here.Tip #1: EatingTypical Vancouver food is Japanese food, mainly sushi. There are many good, cheap Japanese/Sushi

Syndicated 2010-01-26 21:10:00 (Updated 2010-01-27 22:34:43) from Idcmp

60 older entries...