Well, my karma is good.
Friday morning I wrote down the directions to the courthouse from Google Maps. I headed out the door at about 8:15, worried that I would miss the 9am start time and be held in contempt of court.
I saw a huge line outside the Multnomah County Courthouse, so I parked in a garage a few blocks away and stood at the back of the line, which by now was wrapping around the side of the building.
There were all kinds of people in line, and I suspected that jurors would come from all walks of life. But just to be sure I was in the right place, I asked the guy behind me if this was indeed the correct line. "This is the line just to get in the place", he responded.
Wow, so this line included jurors, witnesses, defendants, plaintiffs, reckless drivers, embezzlers, and possibly lawyers and undercover police officers.
I looked around. I knew exactly where I was. I rode my brother's scooter down here one Sunday last fall. There is a small park right out front of the courthouse with tall trees and park benches. Perhaps one of the best photographs I had ever taken was taken at the end of the block.
Just then, an officer split the line into two, starting just three people ahead of me. The officer said something inaudible to the woman and she started walking. He directed us to follow her. She led us to another entrance that reminded me of airport security.
"Sir, you must step back through, take your belt off, and place it on the conveyor belt", I take off my belt and walk through. The alarm buzzes again. "Hold your arms straight out."
I make it through security and am not surprised to see what looked like a Starbucks in the lobby! These Portlanders really like their coffee! I skip the coffee and head to Jury Room 130, where there is another line with about five people in it. They are waiting to talk to an older woman who is sitting in front of a computer and processing potential jurors. She hands the guy in front of me a badge. He looks tired. So does the woman behind me. Neither one of them wants to be here, so perhaps I felt a little guilty when the old woman at the desk told me I had been excused!
Apparently, my employer sent a letter on my behalf requesting that I be excused! The pen is truly mightier than the sword. I left the courthouse, paid for parking, and headed to work just in time for our morning coffee run, which happened to include our CEO, who has never attended a coffee run, who bought everyone's coffee and bagels, who we were able to talk to outside the walls of the office!
They say Friday the 13th is a bad day? What’s the deal with that! I don't necessarily believe that hocus pocus, but I do think that it is a day of power. It is whatever you make of it. For me, it may have saved me thousands of dollars in late fees and missed work.
Friday, July 13, 2007
Sunday, July 8, 2007
Good Code is Like Glass
I've been thinking recently about what qualities an employer wants to see in a potential software developer. Although there are plenty of other resources that have addressed this topic, I want to add my two cents.
In a previous article, I talked about how important honesty was in marketing a product to consumers. I also believe that honesty is important in all aspects of life, including selling your technical skills to an employer.
Nobody is perfect, of course. I'm not suggesting that you must represent the pinnacle of perfection. It is true that employers are interested in what knowledge you have regarding technologies they use, but more importantly, they are interested in your willingness to learn new technologies.
Software development is not a field where you learn the ropes and then that's it, you're done learning. Instead, it is a continual, never-ending process, and if you can demonstrate to an employer that you understand this concept and that you embrace it, then you've increased your chances of being hired.
Here is a list of some of the techniques an employer will use to try to rate you as a potential employee:
As software developers, employers know that we love to program. Employers assume that we will try our best on some interesting feature of a new product, but the fact is that there are some tasks that may not be the most interesting to us. I believe this is where the puzzles enter the picture. An employer will use these to try to determine not only your thought process in solving a problem, but they will also be able to gauge how much effort you put into your attempt to solve the problem.
In my interview, I was very nervous, so I drew pictures and talked out loud to myself. This helped me relay to the interviewer my thought process as well. The best thing you can do is keep trying. You don't necessarily have to solve the puzzle, but you definitely want to attack the problem like your job depends on it. Because it does!
I'm not going to cite statistics on how much money an employer will lose by hiring inept technical people. Instead, I'm going to tell you that it is very frustrating to work with people who don't know what they're doing. I'm sure everyone has had an experience in college or in another group situation where one group member wasn't able to produce. This is where it becomes really important to be honest.
I know firsthand that there are employers who value honesty, and these employers make hiring decisions based on this honesty. In my interview, I was asked to rate my skills in Java on a scale of 1 to 10. I rated myself as a 3. I didn't rate my skills as a 1 because I had done some programming in Java, and I didn't rate it as a 4 or 5 because I had no formal training in Java. I was a C++ programmer. But I believe what made the difference for me was that I was able to demonstrate that I knew there were differences, I knew that I had a lot to learn -- especially since I never took a Java course. I made this very clear in my interview.
To prepare for the Java questions, I read online Java tutorials that specifically focused on interview questions. An employer will think very highly of you if you say you don't know much about something and then confidently nail almost all of his or her questions. Contrast this approach with that of the candidate who claims to be an expert in the field but then can't answer any of the questions. People who think they know something but don't usually end up breaking things whereas the person who is more humble will likely proceed with extreme caution when tinkering with their delicate systems.
Someone once said that code doesn't rust. I believe this is true. Good code can last forever, but good code is like glass; it can shatter into a million pieces if clumsy and inept programmers are allowed to handle it. Sure, version control software does exist, but is it really possible to rollback changes submitted by one bad developer on a project that involves multiple developers without losing the changes submitted by the other developers? I'm not that knowledgeable on how CVS rollbacks work, but even if it were possible to "uncommit" changes by one developer, there is a good chance that some of the code written by the good developers would break due to dependencies on the code written by the bad developer.
In addition to Java, interviewers will probably ask about HTML, CSS, and JavaScript. Since most applications are served in a Web browser, employers will be interested to know how knowledgeable you are on these topics. Again, be honest! An employer would rather hire someone who openly admits to not having a full understanding of HTML rather than someone who claims to be an expert but who has "divitis" or "tableitis". Unless you are being hired as a front-end designer, you can probably get away with not being a master of these topics, but claiming you know something you don't will only destroy your credibility.
I was surprised to hear just how many people go to interviews without wearing a suit. Many candidates choose to not wear one, but I felt it would help differentiate me from other candidates. I was right, at least for myself. Although wearing a suit may not necessarily be the best approach for every candidate, you should definitely put some thought into looking your best and wearing something that will make you feel and look confident and competent.
In a previous article, I talked about how important honesty was in marketing a product to consumers. I also believe that honesty is important in all aspects of life, including selling your technical skills to an employer.
Nobody is perfect, of course. I'm not suggesting that you must represent the pinnacle of perfection. It is true that employers are interested in what knowledge you have regarding technologies they use, but more importantly, they are interested in your willingness to learn new technologies.
Software development is not a field where you learn the ropes and then that's it, you're done learning. Instead, it is a continual, never-ending process, and if you can demonstrate to an employer that you understand this concept and that you embrace it, then you've increased your chances of being hired.
Here is a list of some of the techniques an employer will use to try to rate you as a potential employee:
Evaluate Technical Aptitude Using Puzzles
As software developers, employers know that we love to program. Employers assume that we will try our best on some interesting feature of a new product, but the fact is that there are some tasks that may not be the most interesting to us. I believe this is where the puzzles enter the picture. An employer will use these to try to determine not only your thought process in solving a problem, but they will also be able to gauge how much effort you put into your attempt to solve the problem.
In my interview, I was very nervous, so I drew pictures and talked out loud to myself. This helped me relay to the interviewer my thought process as well. The best thing you can do is keep trying. You don't necessarily have to solve the puzzle, but you definitely want to attack the problem like your job depends on it. Because it does!
Evaluate Skills Based on Technical Questions
I'm not going to cite statistics on how much money an employer will lose by hiring inept technical people. Instead, I'm going to tell you that it is very frustrating to work with people who don't know what they're doing. I'm sure everyone has had an experience in college or in another group situation where one group member wasn't able to produce. This is where it becomes really important to be honest.
I know firsthand that there are employers who value honesty, and these employers make hiring decisions based on this honesty. In my interview, I was asked to rate my skills in Java on a scale of 1 to 10. I rated myself as a 3. I didn't rate my skills as a 1 because I had done some programming in Java, and I didn't rate it as a 4 or 5 because I had no formal training in Java. I was a C++ programmer. But I believe what made the difference for me was that I was able to demonstrate that I knew there were differences, I knew that I had a lot to learn -- especially since I never took a Java course. I made this very clear in my interview.
To prepare for the Java questions, I read online Java tutorials that specifically focused on interview questions. An employer will think very highly of you if you say you don't know much about something and then confidently nail almost all of his or her questions. Contrast this approach with that of the candidate who claims to be an expert in the field but then can't answer any of the questions. People who think they know something but don't usually end up breaking things whereas the person who is more humble will likely proceed with extreme caution when tinkering with their delicate systems.
Someone once said that code doesn't rust. I believe this is true. Good code can last forever, but good code is like glass; it can shatter into a million pieces if clumsy and inept programmers are allowed to handle it. Sure, version control software does exist, but is it really possible to rollback changes submitted by one bad developer on a project that involves multiple developers without losing the changes submitted by the other developers? I'm not that knowledgeable on how CVS rollbacks work, but even if it were possible to "uncommit" changes by one developer, there is a good chance that some of the code written by the good developers would break due to dependencies on the code written by the bad developer.
In addition to Java, interviewers will probably ask about HTML, CSS, and JavaScript. Since most applications are served in a Web browser, employers will be interested to know how knowledgeable you are on these topics. Again, be honest! An employer would rather hire someone who openly admits to not having a full understanding of HTML rather than someone who claims to be an expert but who has "divitis" or "tableitis". Unless you are being hired as a front-end designer, you can probably get away with not being a master of these topics, but claiming you know something you don't will only destroy your credibility.
Appearance in a Technical Job Interview
I was surprised to hear just how many people go to interviews without wearing a suit. Many candidates choose to not wear one, but I felt it would help differentiate me from other candidates. I was right, at least for myself. Although wearing a suit may not necessarily be the best approach for every candidate, you should definitely put some thought into looking your best and wearing something that will make you feel and look confident and competent.
Subscribe to:
Posts (Atom)