Archive | Web Development RSS feed for this section

The Problematic Developer/Programmer Interview Process

26 Mar
Annoying Orange Fan Art, Copyright The Annoying Orange

Annoying Orange Fan Art, Copyright The Annoying Orange

I was going through Dzone and bumped into this article by Bozhidar Bozhanov explaining his frustration with the interview process at Facebook after being rejected after 3 phone interviews. In the article Bozhanov explains that the interview process consisted of algorithmic skills and general computer science test (recursion, binary search, basic data structures), basically “easy” stuff that any computer science grad should be able to solve and that is the rub that I personally have with those types of interviews. As Bhozanov puts it (better than I could have):

  • what you do on these interviews is something you never, ever do in real life: you write code without using any compiler or debugger. You do that in a limited time, with people watching you / waiting for you on the line. But let’s put that aside for now. Let’s assume that writing code without being able to run it is fine for interview purposes.
  • the skills that these puzzles are testing are skills that the majority of developers have never needed. Most people are writing business software, and it does not require red-black trees. What was the last time you used recursion in your business software? So the last time you’ve done anything like that is in college. And many of these problems are really simple if you are a freshman, you did them as a homework just the other day. But then it becomes a bit more tedious to write even things as simple as a binary search. Because you just didn’t do it yesterday. Of course you will be able to do it, but for a little more time, so that you can remember, and for sure by using a compiler. (By the way, the puzzles at facebook were really simple. I didn’t do them perfectly though, which is my bad, perhaps due to interview anxiety or because I just haven’t done anything like that for the past 3 years)
  • the skills tested are rarely what you will do in your daily work anyway. Even in these cool companies like Google and Facebook, there are still pretty regular projects that require coding to APIs, supporting existing code, etc. I don’t think you will be allowed to tweak the search engine in your first week, no matter how great you did on the interview
  • interview preparation is suggested and actually required before these interviews. Exactly as if it is a college exam. But that’s dumb – you don’t want people to study to match your artificial interview criteria. You want them to be…good programmers.
  • focusing on these computer science skills means these companies will probably miss good engineers that are simply not so interested in the low-level details.

And I agree with all of the points. I love programming, but I did not love my computer science classes. I had the most fun in classes that involved web development and database practice, but the theoretical classes,  zzzzzzzzzz… In all honesty. So it annoys me when going through an interview process and I am asked questions that I could have answered in 2003 but whose answers have long been pushed out of my general memory. Bozhanov (I agree again)  states that “obviously my problem is that I don’t like low-level and algorithmic stuff, so I wouldn’t be able to work for cool companies like Google and Facebook ” not just them but smaller companies that adopt the same practices in looking for candidates.

In my own personal experience, I was once rejected in pre-screening for a possible opportunity because I used “obtrusive Javascript” on a skill test I was given. For the uninitiated, obtrusive javascript means mixing Javascript and HTML code within the same document, proponents argue that the JS and HTML code should be contained in their own respective files, which is okay and makes sense to me for the the purpose of keeping organized code. What peeved me in this case is that the only reason I used obtrusive Javascript was to make submission of the test easier since there are email filters that block Javascript files. In the end, I figured that it was a sign that culturally in any case, I would not have been a good fit at that company. In any case, I feel like the market for developers is so hot right now that there are enough opportunities to interview with companies where you are asked and even tested about what you actually did, and will be doing at the company than algorithms I learned a decade ago. Some would argue that makes me a bad programmer, and it is fine with me, but the work I have done so far in my career did not involve me pondering what the Big O of binary search is and how to improve on it. There are cases where in pursuit of optimization there is a need to get a refresher on those concepts in order to research of to improve of them, but as I know, the life of a web developer rarely involves that detail of knowledge. If your dream job is to work for Google/Facebook/insertanybigtechcompany out here and you are willing to study for the interview, then proceed by all means, and it might be that those companies are looking for those individuals with that kind of profile but as for me, I will stick to interviews to where I am asked: “So what type of projects are you worked on?”, “Can you explain to us why you chose to implement this functionality this way?”, or better yet, “how would you go architecturally about implementing a Twitter like site?”.

PS: Jeff Atwood over at Coding Horror has his own views on the developer interview process and #5 and #6 where the biggest source of no-nos from the comment sections and the consensus in my opinion that is that the process Jeff outline was very risk averse for the company but will lose a lot of good people through it. This confirmed what I felt, is that as a developer, unless I am applying for a research oriented position don’t want to be bothered with theoretical knowledge from the past or being taken through loops which I feel are unrelated to what I worked and will be working on.

On expertise, self confidence and job hunting

12 Oct

Every time I go through a job search as I am going through right now, it is always surprising to me how much of an humbling experience it becomes. Reading job descriptions is a good way to quantify and effectively gauge what you have accomplished, that you might not even value as actual skill, and how to express it to a potential employer. My own conundrum is, to express it in a medical allegory, that as far as my web development background, I am a generalist, I’ve dealt with different architectures, frameworks and languages, and reached a point where I am trying to become a specialist. It is a little like trying to go from being a family doctor, to a foot surgeon.

I am trying to focus on front end development techniques, and especially Javascript, which I think that off all languages I have worked with, feels more like a natural fit to me because of its mix of flexibility and power. I just think that Javascript is cool.  The problem now lies in the fact that for the most positions I am considering, and given my length of experience, most companies are looking for “experts” and the way it translates is somebody that has been doing daily Javascript programming for the past let’s say five years. My experience is varied, the type of 5 years of 5 different experiences compared to 5 years of the same 1 year experience, and when given a skills matrix by a recruiter for example, I don’t feel comfortable giving myself a 5 on a scale of 1 to 5 in Javascript because I don’t feel I know everything there is to know about Javascript, not even remotely close. The truth is as far as job functions most companies are trying to gauge is you are good enough to handle all of the client side scripting their application will require, which for most front end developers and designers is definitely possible, the main differences being in quality and style of coding. So strictly from a technical point of view, I definitely know I could handle the job but I just have a hard time labeling myself as an 5-level expert on a 1-5 scale  in Javascript.

That brought me to this excellent article here I ran into today called “Do You Suffer From The Dunning-Kruger effect“,  by Jeffrey Waywhich to makes a long story short, totally related to what I am feeling right now. The Dunning Kruger effect, as defined in the article:

“The Dunning–Kruger effect is a cognitive bias in which unskilled people make poor decisions and reach erroneous conclusions, but their incompetence denies them the metacognitive ability to recognize their mistakes. The unskilled therefore suffer from illusory superiority, rating their ability as above average, much higher than it actually is, while the highly skilled underrate their own abilities, suffering from illusory inferiority.”

and  it manifests itself through “self-proclaimed” experts in a way that they:

  •     tend to overestimate their own level of skill
  •     fail to recognize genuine skill in others
  •     fail to recognize the extremity of their inadequacy
  •     recognize and acknowledge their own previous lack of skill, if they can be trained to substantially improve.

The author really hits it home for me when he expresses that “to my personal web development heroes, I feel like a hack.”, which is how I feel most of the time when seeing some of the cool stuff that is getting done out in the web development feel and it pushes me to learn more and become better. I did run into technical challenges, of various difficulty level and did solve them, and for most I shared the solution on this blog, and it gives me an ego boost but I always have a nagging feeling behind of “Is this the best way I could have handled this?”. So even if 5 years down the line of absolutely working with Javascript on a daily basis I grow to be quite good, I still doubt that I will label myself as an expert. In the mean time, my personal challenge is not to downplay my own experience (“Actual competence may weaken self-confidence“) and being able to convince the right company that I can handle the job.

Read the full article here and also consult the Wikipedia entry on Dunning-Kruger.

The First Rule Of Development: Nothing will work as expected!

24 Aug

Allow me to be bold with this one, but today I ran again into another one of those environment set up issues that make you question your sanity. No need to get into the details, but ever since the beginning of my career, which has involved quite a bit of J2EE development, one of the things that have amazed me is the ramp up time it took to get started on a project. I am not talking about merely perusing through the code, trying to understand the architecture, get a feel for what’s going on, but simply checking out a project from repository, into Eclipse, and being able to run it on my localhost. “What about the documentation?” I hear you say, you smug devil,  and I smile with full teeth at your foolish smugness. Documentation? Who has time for “Documentation”. “Documentation” means one eager programmer like you was kind enough to flesh out the major steps that should get you to where you need, but in development: THE DEVIL IS IN THE DETAILS…

Why is it that nothing ever works as expected?(Hint: Because we need enjoy the gift of debugging to become expert debuggers)  “Copy the so and so .jar to the WEB-INF folder, change this line in web.xml and you are good to go!” said the instructions, yet it’s one week later and Tomcat still won’t start.   I remember on one of the J2EE projects that i worked on, which was an offshoot of an existing project with a 50+ pages outdated development environment set up document, it took me close to two months to get an environment going. I followed the steps, but with each one a pitfall, a bug, that I had to extract a solution for from the minds of not-always-willing-to-share previous developers. It was so obvious in their minds, but not written in the documentation:

“Oh yeah, we had to change this because this and this happened, this is what you need to do…” Thanks, that could have saved me two days!

“Oh that piece of code, unless you are working on this and that you won’t need that!” Thanks, I just spent the last three days trying to get it to work.

Bottom line is that we as developers have to do a better job at documenting what we do (I hope the developers that came upon my documentation agree), and that for the sake of other developers, and not assume that a) it is not such a big deal or b) others will be able to fill in the gaps. I thought J2EE development environments were the worst but I’ve had my share of mishaps in LAMP environments as well.  I am curious, though, as I always assumed that .Net programmers must be somewhat free of those problems being that the word was MS did a good job of providing a polished development environment,  is the grass greener on the other side? Is it an open source software issue? I am interested in hearing about your experience with how easy (or not) it is to become productive within your chosen programming language and associated development environment.

Update on Programming: “It pays the bills” vs “It satisfies me”

20 Jul

I’ve gotten a lot of positive responses for my previous article: Programming: “It pays the bills” vs “It satisfies me”  and it has now be republished in Chinese here , here, and here. Thanks to my Chinese readers. I can now check off another item on my list of lifetime To-Dos. Programmers of the World, Unite!

Booyah!

Debugging: joy or necessary evil?

20 Jul

That’s it, you’ve done it. Spent countless hours programming this feature, the design was excellent, the coding grueling but finally: It is ALIIIVVVEEE…Wait! What was that? No…No, that’s not how it’s supposed to go, WTF (What The Fortran)!?. And so it begins, you now need to DEBUG! Personally, I do enjoy it and i recognize that due to its nature, it is understandably not a cause of enjoyment for all. First of all, there has to be a distinction made between debugging your own code, and debugging code written by somebody else. I do not enjoy the later as much as the first.

Debugging someone else’s code

Debugging somebody else’s code is obviously a longer process, where you have to get into their thinking mode, and reverse engineer their code. If the code lacks comments or proper documentation and is not particularly clearly written, then to me, debugging becomes a necessary, soul sucking, sarcastic evil. It can provide for some entertainment though, and is nonetheless a good learning tool whether the code is great, in which case you learn new techniques or patterns and improve yourself, or find the most horrifying pieces of code that even as an inexperienced but sharp programmer you can detect all that is wrong with. In both cases you are able to grow by learning from someone else’s coding abilities (or not).

Debugging your own code

To me this is where most of the fun is, as I think of it as me against myself type of fuel. It offers incredible insight into the way your mind works and increases your self awareness. It’s a game of highs and lows where at times I’ve felt like the smartest person on earth for coming up with a clever solution for a particular bug, or the dumbest for making such a dumb, obvious, noob programming mistake. And sometimes a mix of the two but nonetheless a rewarding experience.

The debugging mind

I’ve realized now through my career that the same set of problems usually have the same set of solutions. That is the crux of experience. My greatest gains as far as knowledge and experience have come not from designing a new solution to a problem, but rather from coming up with alternative for an existing one. The number one skill required in debugging is, and let me put it in bold: patience; this is where most realized that they were not built for computer science in college. Through the first programming assignments and the obligatory long debugging  sessions that followed to ensure that the code turned in did what it was supposed to, those that were not cut out for computer science were initially weeded out, including friends of mine. It takes patience to sit in front of a computer screen staring at lines of text that are not part of Facebook or Twitter, re-running the same piece of codes, hundreds if not thousands of time and still not getting them  (lines of text) to do what you want.And still go back to it. And again. And again…Until you get it. And this is where the second crucial component comes in, and not just in debugging but in programming in general: passion.It does not take only patience to sit in front of a computer for hours when you could be doing ten thousand other  (better?) things. It takes passion, and most of us in the field are in it because we love it and love takes sacrifice sometimes.

The Bug

The Bug, in programming, is usually of our own making. Like a rebellious child bent on destroying its genitor (at least that’s how i see it). It can be subtle, smart and refined, or on the opposite freakish, flamboyant and agressive. The latter is usually picked up at the compiler level, and can be promptly subdued and compiled merciless into submission but the former…Ahh the former, The Bug….it is the silent ninja assassin created and trained in the depth of our mind who comes out attacking in full force once the program is running. In debugging I have learned that indeed as The Ghetto Brothers have rapped about, “my mind is playing tricks on me”. Sometimes The Bug is sitting in plain sight in my code, and after pulling countless hours trying to find a solution i realize that it had just pulled an “Wandering Eyes” ninjutsu that had me looking everywhere else in the code but the most obvious part for it. I do feel dumb and taken advantage of when that happens. But it is all part of the game because as I also learned, The Machine Only Does What You Tell It To. I’ve spent countless hours screaming at the code for not getting the logic right only to find out that mine indeed was the logic that was flawed and that The Machine Only Does What You Tell It To. Enough said.

The Challenge

To those programmers that enjoy debugging, I think the enjoyment comes from The Challenge. The Bug is indeed an enemy, standing in the way of your own self assessment as a (very) good (even excellent) programmer. The Bug and The Machine are plotting against your intellect and have officially thrown “The Challenge” to your face. How disrespectful! It is as if they were 18th century Frenchmen who just pimp-slapped you (reverse of the hand) and said: ‘I challenge you Monsieur, to a coding duel!’. Are you going to take it like a Frenchman(*See legal disclaimer)? Are you? Non Monsieur! They shall soon regret rising against your algorithm magnificence!

Once down from your ego high, you realize that although it strongly feels like a duel between Man and Machine, where most of the time, you are really fighting yourself.

*Legal Disclaimer: I by no mean imply that a Frenchman taking it  is nothing more than a Frenchman taking it in the context of an 18th century duel. I have nothing against the French, in fact my best friend is French (and his name is Fry’s like in Futuruma).
 

Google/The Community

Debugging would not be the same without search engines. Debugging would not be the same without Google. As a matter of fact, I’ve gained respect for the old school programmers that used to fight it out by themselves. Today, your Google-Fu mastery may be as effective as actual coding/debugging skills to resolve problems. I would like to think that I am at least a Google-Fu black belt (I will tell you for sure next month, I am taking the certification exam). The trick in using Google, and where most brown-belt-and-under  Goog-Fu practicioners fail, is learning to properly formulate your search terms. I know the secret, polished and sharperned by years of practice, and I can teach you, for a nominal fee of $7.99, but WAIT! If you tweet this now, not only will i teach you the secret once, but i will teach it to you TWICE and if you still don’t get it I will slap you in the back of the head until you get it! But seriously, for most bugs, the developers community have been good through various sites in documenting most bugs and even in the case of new or specific-to-your-own-case ones, by being a little analytical, you are given enough of a clue to know what direction to look into. More than often this is enough to reach a “RESOLVED” status on The Bug. By the way, when you ask a question to the community on a forum, get help, or figure it out on your own, come back and post it for future generations. If you don’t fine but don’t come back and post “I’ve figured out how to do it! “, not post your solution and disappear for good in the depth of the Internet. That gets you bad karma. I know, I’ve sent it your way. Debugging can sometimes be a detective game and understanding it from that angle will sometimes help relieve the tediousness of it. It sometimes take painstaking, slow, detail oriented work to solve the crime but when that happens The Yeah! Moment is a reward in itself.

The Yeah! Moment

This is the moment we do it for, whether it’s debugging or programming, the moment where IT WORKS! The gratification, the adrenaline, the rush, the congratulations, the hugs, the smiles all in sloooooow motion. The Hollywood moment. The Kick. More than the paycheck, that’s the feeling we are craving and working for. It’s the sense of accomplishment as I was explaining to my wife that keeps you coming back. I think one of the greatest things about programming is that you can go home everyday and feel like a million bucks because you feel like you saved the world (as defined in your business requirements). The Bug has been conquered, The Machine subdued and Man reigns supreme.

The Council Of The Sages

Now a long time ago (equivalent to two hours in a Twitter moderately busy TL), a group of great programmers, The Council Of The Sages, wise from their experiences fighting The Bug, came up with design patterns, tools and methodologies to give Man success in the fight against debugging and the loss of productivity. They invented JUnit and its clan of ruthless TDD derivatives, Log4J The Recorder and The Tribe Of The Logging Tools, Firebug, the fire breathing cockroach spreading terror in the heart of Javascript critters. Those are all great tools and methods to help you in the fight against The Bug, and I encourage you to look into them to better your craft, although I admit that sometimes System.out.println is just too tempting to pass on. Bad, I admit, but it just feels so right…

Credits

So The Bug died a horrible death and the sun started setting and you and your laptop turned to the camera and shared a passionate kiss when all of a sudden…

In conclusion I hope I did not turn my one paragraph blog thought into a full fledged i-don’t-know-how-many paragraphs ramble but since it seems like i did and that I rambled more than I thought about debugging I will just accept the facts as they were and strongly encourage you to do so if you are still reading. Debugging does not have to be a drain on your morale. If it still is, just imagine The Bug and its eville associate, The Machine having a drink on you, giggling, pointing fingers at you, laughing hard hahas of the Simpson’s Nelson haha! Are you gonna take it? Are you?

Note: Be sure to come back next week for my next post: “Testers: The Enemy Within”. Yes I said it!

Programming: “It pays the bills” vs “It satisfies me”

5 Jul

At this point in my career I find myself increasingly frustrated with my day to day work. You see, living in the DMV area (DC-MD-VA), a lot of the jobs available are in government contracting and as many will tell you, those are well paying jobs with a certain level of job security added. For a while I did it and enjoyed it but deep inside i knew that this was not really what i want to be doing for the rest of my life. With things being the way they are, even when trying to switch jobs, it has been easier to do so going from one government contract to the next, with my attempted moves to the private sector being unsuccessful primarily because first my experience is mostly related to government projects, and second, the pay range was below was I was willing to go for. It is not greed on my part, but being married with kids means ” I got mouths to feed man! “(<= in Dave Chappelle’s voice) and obligations I have to tend to and can’t ignore.

This has limited the number of opportunities I considered and from a passing thought in the back of my mind it has grown into a daily contemplation of my future in this business. Over the years, I have gravitated toward doing and enjoying more of the front end work, and it’s a coincidence that the field in itself, especially when it comes to enterprise J2EE development, is becoming a full position in itself as opposed to being lumped in the “Java Developer” category just a couple of years ago (It still is, i just got another inquiry from a recruiter looking for a Java Developer where most of the work is front end related). My frustrations with the projects I have been on mostly stem from the technological limitations of working on government projects which sometimes involves outdated technologies,  security limitations and convoluted requirements that end up taking the fun out of the development process. From a design and functionality point of view, these applications lacked the “Wow” factor and being internal applications, even if they were, they were not of the “living portfolio” type of web applications that customers companies want to see when interviewing a developer.

I’ve realized that the type of work I want to be involved with has to be challenging, innovative, and current to what’s getting done today. It has to be a good mix of creative and technological skills that keeps me on my toes and gets the “Cool!” approval from family and friends when presented with it or when explained to, instead of a blank stare and a “Uh?”.

To work towards achieving that goal, I’ve started working on projects of my own, ideas i have been nurturing for a while with the hope of turning it into a startup if it gains traction. It’s a combination web/mobile app developed with CakePHP and Sencha Touch that has helped me turn some of the concepts and techniques I have been reading about and itching to try into actual code and challenged my thinking and skills in a way I had never experienced before. It has forced me to step out of my comfort zone and try new skills I didn’t practice before and it is a continually rewarding experience. I’ve also started working on side projects for friends of mine in order to expand my skill set and keep it sharp and relevant.

Through discussions with others (friends and colleagues) I’ve found out I was not the only suffering from this programmer’s “existential malaise” but some choose to go with the status quo while others like me find other projects to get involved with on the side that keeps them interested and challenged.Some have started their own startups, non-profits and organizations, building on the skills they have and pushing into new directions. Me, I figured I could spend my free time better than racking up “The Feared” accolades on Modern Warfare 2 or shouting angrily at my TV because my players messed up again in Fifa 11.

All this in waiting for that project that will bring the good mix of creativity, innovation, coolness and most of all, “will keep the kids fed, man!”(<= in Dave Chappelle’s voice).

Follow

Get every new post delivered to your Inbox.

Join 453 other followers