Hacked By Imam with Love
Hacked By Not Matter who am i
i am white Hat Hacker please update your wordpress
It’s been almost exactly two years since my last post to this blog. When one considers that I am a compulsive writer who must write in order to breathe, this anomalous temporal blogging gap stands in stark contrast. What can possibly account for this 24-month blogging hiatus? My operational theory: Twitter.
Twitter is micro-blogging. Say what you want to say in 140 characters or less. Get in, get out. I think Twitter has stolen my writing thunder. This is not all bad. I post primarily from my phone when I have small chunks of down time. I share personal experiences, voice my pitiful opinions on a variety of topics, read the random ramblings of my friends and colleagues. In short, Twitter gives me social media happiness and a readily available spontaneous writing outlet.
Since I started using Twitter in 2008 I have posted nearly 2,400 tweets. At a maximum post size of 140 characters, that comes out to more than 300,000 characters, or somewhere between 50,000 and 100,000 words. That’s a lot of blogging, no matter how thick or thin you slice it.
Ironically, it appears that after two years of regular micro-blogging, when I do get back to my regular blog, I write about Twitter. Well, in any case I’ve broken the blogging silence. Glad to finally post something after such a long break. I’m so excited. Gotta hurry and tweet about this.
Yeah, I know I promised three follow-on posts after the last one on puzzle-solving interview questions. I’m getting to it. Really. But I wanted to take a minute first and specifically address some of the comments left on the last two posts.Here’s one:
In my opinion, there’s nothing wrong with hiring engineers primarily for their puzzle-solving skills; that’s their primary function.
I’m going to respectfully disagree. A software engineer’s primary job function is to write software, which involves a number of things, one of which looks a bit like puzzle-solving. But the driving function of the complexity and cost of software construction is neither writing software, nor its puzzle-solving component. The driving function of software construction is the collective emotional state of a software engineering organization.
Individual engineers have to be decently smart. Spectacularly smart is even better. But uber smart with a whiny attitude is a no hire. The smartest new college graduate at some university who can’t stay focused for more than three weeks at a time is a no hire. The kid who solves the Rubik’s cube in less than a minute blindfolded but brings other team members down emotionally is a no hire. The brilliant prima dona is a no hire. The defeatist genius who minored in learned victimhood is a no hire. Every single one of these guys can pass the puzzle questions with flying colors. Every single one is a no hire.
Failure to interview for emotional attitude, team play, communication, and can-do attitude ABOUT THINGS OTHER THAN PUZZLES is failure to interview for a successful engineering corps.
But what about division of labor? Why does an engineer have to think big? Can’t the high mucky mucks think the big thoughts and leave the puzzle-solving engineering crew to hunker down?
To wit, this comment:
When you expect or allow those same engineers to decide the direction of the company is when you’re headed for disaster. Large companies like Microsoft and Google can get away with this practice if they balance out their spiffy puzzle-solvers with globally-thinking big-picture people. Smaller companies can’t afford to specialize and compartmentalize their workforce that way and should follow different hiring practices.
Again I’ll respectfully disagree. The notion that there is some clear separation between the engineers in the trenches and everyone else in the company up to and including the CEO is a myth. The collective attitude of an organization, for better or worse, is manifest in everything the company produces, including the products it ships, the ad campaigns it runs, the personality of its sales force, the attitude of the secretary at the front desk, and the code that engineers produce, not to mention the rate at which they produce it.
Personal case study: In 1988 I was a software engineer in the Personal Computer Group at Hewlett-Packard in Sunnyvale, California. I showed up just before HP’s OEM release of OS/2 1.0 for the Vectra PC, and then stuck around to write device drivers for OS/2 1.1. I had access to all the source code for OS/2, which had been jointly developed by Microsoft and IBM. As I cruised around the code for OS/2, it was always immediately obvious which code had been written by IBM engineers and which had been written by Microsoft engineers. In all cases, the coding style was consistent with the collective corporate attitude that you could see on a billboard from a clogged expressway. You could drop code in front of me and I could tell you which company it came from.
Engineering work, even among the most junior engineering staff members, involves creativity and decision making that has nothing to do with puzzle solving. Individual engineers make stylistic decisions about design issues that were not fully clarified by someone outside their team. Attitudinal decisions that affect code maintainability happen every single day. A renegade codeslinger who refuses to follow the corporate style guide has a negative effect that no amount of puzzle-solving speed can repair.
The idea that there is a wall of separation between the puzzle-solving work of the engineers hunkered down in their cubes and the collective vision of the corporation is fantasy. Engineers who can see outside the cube (both theirs and Rubik’s) write code that blends with corporate purpose. They induce a positive ripple effect that transcends their keyboard and compiler.
Conversely, engineers who primarily solve puzzles are more likely to write unmaintainable code, because they don’t see the world from outside their own perspective. They struggle to figure out why all this coding style garbage is being shoved down everyone’s throat. They view sales and marketing as pure overhead, management as the dark side, and software engineers as the only ones around here who do any heavy lifting.
I agree that big picture thinking is absolutely essential for a small company where everyone ultimately does everything. But big picture thinking turns out to also be critically essential for a large company as well.
In my vitriolic diatribe on puzzle-solving interviews, I argue that making engineers solve puzzles as an interview strategy does nothing but confirm what their transcript already tells you, and over time yields an engineering staff incapable of strategic thinking. To my credit, I did not use the term “boneheaded,” which speaks to my inimitable sense of self-restraint.
Rebuttal from a reader: “Perhaps some real value can be found out of the puzzle question response by looking for out-of-the-box, creative thinking (both in problem analysis and solution exploration). Even if they get the thing wrong (which is not necessarily a bad thing since most puzzle questions are designed to be devious and tricky), they may prove the ability to look at the problem from a unique perspective and think critically as they problem solve.”
Agreed. There is some value in watching a person solve a puzzle in order to see not just whether they can solve the puzzle, but how they approach the solution of said puzzle. But this insight does not address the profound problem with the entire notion of a puzzle-solving interview in the first place: Puzzle solving is not even remotely the most significant skill of a superb professional software engineer!
Software is built by humans within the context of social structures. Software construction is dramatically affected by a personal productivity variable of at least an order of magnitude. That means that my good day is at least ten times more effective than my bad day. Equally important, one engineer may, on an average day, perform at least an order of magnitude more productively than another engineer on that same average day. Engineering productivity is massively impacted by the collective cognitive and emotional state of a given team, not to mention the dynamics of that team as it interacts with the rest of its company (and even further, with the company’s partners and customers).
If you want to really know whether a candidate is going to save your bacon six months from now, stop asking the puzzle questions. Now.
If you want smart and clever engineers, then limit your recruiting to schools you trust and require a minimum GPA of the students you interview. If that’s not good enough for you, then actually read their transcript and look at how they did in specific courses.
Now that you’ve determined the candidate is smart (see above), try to figure out these three things:
1) Can this candidate think intelligently about a world outside an engineering cubicle?
2) What is the ratio of bad to good days in the engineering life of this candidate?
3) Is this candidate an effective written and verbal communicator?
You then have to develop great interview questions that evoke meaningful answers to each of these three issues. I call them, “The only interview questions you’ll ever need.” All will be revealed in the next few posts.
Interviewing: The process by which an interviewer determines via a face-to-face interaction whether an interviewee possesses the chops necessary to assist the hiring company in its quest for profitability and market domination. (My definition. Feel free to quote me.)
About a decade ago, Microsoft pioneered an approach to engineering interviews based primarily on puzzle solving. The approach became so popular that companies like Google adopted it, books were written on it, and websites dedicated to it. Candidates were even encouraged to consult up to a dozen specific tomes in order to successfully crack the puzzle-solving puzzle that the interviews evolved into. (See the Wikipedia article “Microsoft interview.”)
It bugged me when I first heard about it a decade ago, and it bugs me even more now that other companies have jumped on the bandwagon. I think it’s a pathologically bad practice for reasons I will now reveal.
When you ask a senior in Computer Science to write a function for string comparison in some arbitrary language (for example), you’re testing his or her capacity to either a) regurgitate code they successfully wrote three years earlier, or b) cram puzzle-solving code snippets into their brains in order to impress an interviewer on demand. You might as well ask a candidate to solve a Rubik’s cube blindfolded in less than two minutes for all the value you derive from a question like this.
Seriously, what do you learn from this question?
- That the candidate is smart. Congratulations. You just verified their cumulative GPA and spot checked specific courses on their transcript.
- That the candidate is a puzzle solver. Congratulations. Next time just break out a Rubik’s cube and be done with it. For the bonus round, break out a blindfold.
- That the candidate knows how to prep for your highly arbitrary and ultimately predictable IQ test. Congratulations. You just learned that the candidate is motivated to game your goofy interview process in order to secure a position with you.
My most significant concern is this: Fill your company with a few thousand smart kids who know how to solve puzzles and you’ll populate an engineering staff who can’t think strategically or globally about where the company needs to go, or how products need to evolve. You may find a few who have broader abilities, but your odds of finding them are about the same as discovering new hires that can hit a sweet jump shot or play the cello. You get some by chance, but not because you interviewed for it.
My assertion/prophecy ten years ago was that companies who hired spiffy puzzle solvers via spiffy puzzle solving interviews would ultimately suffer from a vast and pervasive lack of vision and global thinking among its engineers.
Memo to the industry: Your company’s biggest problem isn’t the puzzle solving ability of your engineers. It’s your collective ability to figure out what the market will cough up for the products you never thought about building.
Interview by testing for small thinking? Don’t be shocked when you find yourself working for a fading company devoid of a critical mass of engineers capable of thinking big.
Dr. Margaret Burnett, one of my professors from my grad school days at Oregon State University, gave a wonderful keynote address at the PPIG (Psychology of Programming Interest Group) workshop in Madrid, Spain on September 20, 2010, entitled “Gender HCI and Programming.” In her keynote, Dr. Burnett outlined seven years of research that she and her colleagues have conducted into issues of gender and computer programming. (For more detail about their research, see the Gender HCI Project page.)
One of the most insightful moments for me was when Dr. Burnett pointed out that computer programming and systems often employ violent or crude metaphors that are potentially offensive or abrasive to many women. For example, we abort processes, kill programs, spawn zombies and daemons, etc. Who invented these terms? For the most part, guys. And not just normal, run of the mill, let’s shoot some hoop and watch the game sort of guys. But nerdy, hard-core, dungeons and dragons, caffeinate and code all night sort of guys.
I hereby add my own small data point. Some of my kids had been pestering me for a few months to teach them the material from BYU’s CS 100 course, “Introduction to Computing.” The Saturday after Margaret’s keynote address, I relented, and my lecture in the family room was attended by two sons (ages 17 and 14) and one daughter (age 15). At some point, near the end of my lecture, I was talking about programs and how you launch them so that they run. I said something like, “So when you click on the icon, it executes the program.” My sons nodded blankly. But my daughter cried out, “Ew! Execute the program?!” See, that’s the gender gap. My boys didn’t even blink and my daughter is having flashbacks to the French Revolution.
So there, Dr. Burnett. You can add this to the list of seemingly innocuous technical terms that in fact evoke a negative reaction from a teenage girl while her brothers, raised in the same home, don’t even notice. And we wonder why we have a gender gap in Computer Science enrollment.
The following story is true. The names have not been changed. The guilty are still guilty. And named. The heroes are also named. As they should be.
This story begins in D.C. on a road trip with my wife about one week before arriving in South Bend Indiana for a conference I was attending on the beautiful campus of the University of Notre Dame. The plan was for us to spend one of our evenings in our hotel room eating popcorn and watching the classic Notre Dame football movie, Rudy. Since we were staying at the Morris Inn, just 200 yards west of the historic Notre Dame football stadium, and since my wife had never seen the movie, this seemed a fitting part of our stay beneath the golden dome.
On our flight from New York to Chicago, my wife asked me if we in fact owned the movie Rudy, and if so, whether I had thought to bring it. My response was that, No, we did not own the movie, and that I had, in fact, thought to bring it, but as I said previously, we don’t own it. However, no problemo, says I, because it should be blindingly obvious to the casual observer that all one should have to do to obtain a copy of Rudy is to step foot in the Notre Dame Bookstore. This was my plan.
On the second day of our stay at Notre Dame, I found a gap in the schedule and beelined to the Notre Dame Bookstore where I found multiple copies of Rudy on Blu-ray, but nothing on DVD. Another search by my wife turned up nothing. A third, more thorough search by me turned up a single straggling copy of Rudy on DVD, buried beneath some other Fighting Irish propaganda. For $26! You’ve got to be kidding me. Ha, bookstore prices. Of course. Not a problem. There’s a Walmart in this town, right?
That night we ate at a nice restaurant conveniently located near a Walmart in South Bend, and after dinner we made our way to the DVD section of the world’s most popular store. No luck. Ask the clerk. Ah, they only carry Rudy during the football season. Are you serious? This is South Bend, Indiana, for crying out loud! You’re telling me there isn’t a perpetual demand for Rudy at an arbitrary Walmart in South Bend Indiana on any arbitrary day in the off-season?! Alas, this was, inexplicably, the case.
Not to fear. I noticed a video rental joint not more than a few blocks from here. Surely they will have what we need. A quick stop, one question to the clerk, and the much sought after DVD was in my hands for the sum of 54 cents. We were in business.
Back to the hotel, pop some popcorn (in the break room of the kitchen staff downstairs at the end of the hall — don’t ask), and settle in to watch the DVD on my MacBook. Approximately 10 minutes into the movie, as Rudy races with great emotion through his fellow high school seniors to hit the pad carried by his coach, the movie freezes. We stare at the grimacing Rudy, wondering if he’s going to knock the stuffing out of his coach after he unfreezes. The DVD player on my Mac gives up the ghost and dies. We restart everything, but we’ve lost about 10 minutes of the movie and the bulk of the plot setup. Unacceptable. We instead decide to watch Invictus (inspirational rugby movie, almost the same thing), and commit to plunking down the cash at the Bookstore the following evening.
One day later I scan the DVD shelf in the Notre Dame Bookstore, but find that the random copy of Rudy that I had rustled up a day before has apparently been snagged at what now seems like a bargain basement price of $26. We roll back to the hotel, somewhat dejected, unwilling to romp around town further trying to find a local establishment with enough Fighting Irish school spirit to stock a functional copy of the best Notre Dame football movie of all time.
This is when the voice of Steve Jobs comes into my mind, and I realize that there may yet be a way. I jump on iTunes, and quickly locate the heretofore elusive movie. For just $9.99 (which now feels like an absolute bargain) I secure a downloadable QuickTime movie, consuming only 1.29 GB of hard disk space in the process. No physical disc to secure in some random building in a random town. No plastic to scratch and corrupt. Just a file. Just bytes flowing through the tubes to my laptop and the movie playing for me in my hotel room.
In about the time it took my wife to secure popped popcorn (downstairs, down the hall, etc.), we were watching the elusive movie on my Mac. The beautiful thing is that it may as well have been on my iPad, sitting with the squirrels under the trees near Touchdown Jesus. But it happened to be in the hotel room, on my Mac.
As always, the brilliance of Apple is not, strictly speaking, the engineering (although that’s clearly necessary). It’s figuring out what I want to do, plus when, where and how I want to do it, and then just making it ridiculously easy for me to do that. Most companies ignore that little part because it doesn’t feel like academic or engineering rigor. It’s not “the hard stuff.” But at the end of the day, it’s really just about the only thing that actually matters.
Rudy! Rudy! Rudy!
Another round of “crazy comments from offshore spammers”:
i really hav no idea..
Wanted to moment to give you acknowledgment, yes please continue with your articles, i very enjoy them. You constantly can publish something entertaining that won’t leave you with an empty feeling like what you see on some other websites.
can’t be the real… the place is surely a big secret kept by a few important people
Let’s talk, to me is what to tell.
In my opinion you are not right. I am assured. I can defend the position. Write to me in PM, we will talk.
Wow! Thank you! I continually wanted to write in my web site something like in which. Can I get element of your post to my web log?
And now a new feature, “well-written but over the top spam from half-decent writers”:
Your internet site came up in my research and I’m moved by what you have published on this theme.
On the view defended here, there is no deontological case for holding racial partiality to be intrinsically morally wrong when it does not proceed from animus or prejudice against those who are singled out for inferior treatment.
You have the wisdom of the aged and the relevance of youth. What a great combination. It allows you to be sensitive and strong.
Just want to say your article is stunning. The lucidity in your post is simply spectacular and i can take for granted you are an expert on this field. Well with your permission allow me to grab your rss feed to keep up to date with succeeding post. Thanks a million and please keep up the a uthentic work
No. Thank you!
I recently inventoried the blog spam that my filter is catching. I’m amused by some of the offshore messages left in the blog comments. Thought I’d share a few of these (sans URL and full sales pitch, of course) for our collective entertainment.
hello it is test
Thankyou for such a facilitatory and informative post, it is appreciated!
Hello Guru, what entice you to post an article. This article was extremely interesting, especially since I was searching for thoughts on this subject last Thursday.
That’s Too nice, when it comes in india hope it can make a Rocking place for youngster.. hope that come true.
It only reserve
Quite right! I think, what is it good thought. And it has a right to a life.
Online casinos us… for free to join…
Want to spend your vacation to be remembered for long? Tourism … help you carry out your wishes !
And my personal favorite…
Much interesting, well why all exactly so?
Much offshore spam.
Make this blog a Rocking place for youngster.
Well why all exactly so?