Showing posts with label work. Show all posts
Showing posts with label work. Show all posts

Friday, October 28, 2011

The Matt Test

In 2000, Joel Spolsky (insightful software engineering blogger) introduced The Joel Test. It tests the bare minimum for a dev team with 12 easy questions:
  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?
A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've got serious problems.
It's not a perfect test of an engineering organization, but it's a great minimum. It's great for being over a decade old - but at a decade old, some of these seem painfully basic to me now (source control and bug database).

I would add a few:
  1. Do you use Google Apps, or at least Gmail and Google Calendar?
  2. Do you deploy at least once every other week?
  3. Do you love your and respect your designer?
  4. Do you have a Twitter account that replies to users?
  5. Do you have design docs for major components that resembles reality?
  6. Do you have a wiki that employees use?
More to come, I'm sure. This is a living document. 1-6 were added on November 2, 2011. I'll annotate the addition date for new ones.

Thursday, October 27, 2011

Algo interviews are overrated

Google loves algorithms interviews. Palantir loves algorithms interviews. Pretty much every tech company who prides themselves on hiring smart people spends at least half the dev interview time on algorithms questions.

I think algo interviews are overrated. Useful to some extent, but not the only thing and not as important as most engineers think. I think Steve Yegge (mentioned yesterday) would agree.

In my opinion, these are the important things in hiring a new member on a dev team. They are not priority ordered or of equal weight.
  1. Ability to translate a problem into components.
  2. Ability to reason through a problem and feel the solution.
  3. Ability to keep trying and go deeper on problems unlike ones she's seen before.
  4. Ability to translate these solutions into code.
  5. A bag of tricks (data structure knowledge, technical knowledge) and the intuition that says "I bet there's a better way to solve this problem, I just don't know it yet."
  6. Ability to build stuff.
  7. Technical flexibility (can a SQL expert adapt to NoSQL? Can a Java person learn Ruby?).
  8. Attitude. Is the candidate going to mesh with the team? Are they going to make coworkers' days better or worse? At Google, this was "Googliness".
Good algorithms questions can address points 1 through 5, though algo problems and every day coding problems don't map perfectly. Algo problems are too neat - they're like bowling with lane bumpers whereas everyday coding is like bowling without gutters or even lanes.

The real kicker: algo interviews don't gauge the ability to build stuff. Some companies get this and ask for you to build something for them. Airbnb and RockMelt ask candidates to spend time building something on their own. Square does pair programming so you can build something together (I interviewed at Square and feel that I was at a significant disadvantage because I don't know Ruby.).

Companies are wary about having candidates build something on their own time because it adds hours to the candidate's time load. Companies and candidates alike perceive asking a candidate to spend their own time (as opposed to shared interviewer-candidate time) as arrogant and pushing too much onto the candidate.

I think it's important to gauge how good someone is at building things ahead of hiring, but I haven't figured out a method to do it that isn't burdensome.

Another problem with algorithms interviews: the distribution of questions makes it possible for a candidate to have heard 80% of the questions you're going to ask before the interview. I'm not saying the candidate knows 80% of all the problems asked on interviews, but there's effectively a finite set of questions interviewers ask in a 45 minute interview. Algo questions need:
  • Simple set up. The question needs to be intuitive and you can't spend 15 minutes for the problem set up.
  • Bounded solutions. There's probably going to be one or two efficient ways to solve it.
  • Non-esoteric solutions. Priority queues are awesome, as are tries, but they're rarely used outside of algorithms classes and algo interviews. Questions mostly come down to: divide and conquer, dynamic programming, hashing, merging, binary search, sorting, and iteration.
If you paid attention in your 100 level courses, and solve some example problems, you can probably pass your Google onsite with 10 hours of preparation. Steve Yegge (yep, I have a thing for him today) tells you how. Google has an internal list of banned questions that have become affiliated with Google, but even those are still often asked. Good algo questions are hard to find.

I've concluded that algorithms interviews can be gamed and I've concluded that even if they couldn't be gamed, they aren't the only thing to gauge during the hiring process. So where do we go from here?
  • Find a way to have candidates build something during the onsite. I don't have the answer yet, but the closer to real work candidates are doing, the better the interview will be.
  • Ask design questions. Not design patterns esoterica, but problems that almost beg the candidate to say "This is like something I did before! We solved it doing ..." and then asking about the other tradeoffs the person has made.
  • Ask questions that speak to grey (technical) issues. Ask when they'd choose between GWT and jQuery. Ask when they'd take their HashTable and throw it into MySQL, and when they'd go from MySQL to NoSQL and MapReduces. See if they've gotten the feel for products they've developed before instead of simply hacking at them.
  • Get a feel for the candidate. See if it's someone you'd enjoy working with when the server's been down for 3 hours and you still haven't figured out why.
  • And yes, still ask some algo questions. See if the candidate has the gut feel of when to use HashSets, or if they're only into brute force solutions. Ask for the runtime - if someone really gets the solution, runtime is trivial.
Too many tech companies are measuring in great detail something that has poor correlation with career success. I haven't noticed it change much in the past half decade.

Wednesday, October 12, 2011

"blogged" at work today

I wrote a long email to my tech lead that fulfilled the goal today of blogging - articulation, introspection, and expression of formed ideas. And now, after kegging the Oktoberfest beer, I'm exhausted and going to sleep.

Thursday, October 06, 2011

Some days

Some days, it feels like I get nothing done. Paying down technical debt is nice and all, but it isn't amazingly tangible.

Sunday, October 02, 2011

On my consciousness

My own ego is a blessing. It's wonderful when someone gets angry at me, I can think to myself, "I'm not a bad person, I'm worthwhile". I usually get past my impulse to brush the person aside and invalidate him. Instead, I try to listen to what's underlying his criticism - am I doing something unkind? Is he having a bad day? Is there a misunderstanding? Can I do something to turn this bad interaction to a positive one for both of us?

My ego is also a terrible force. In high school, my course work came easily. I had great teachers, I grokked the lessons, and I never had to push myself to study or learn. The first week in college, I started struggling. The material was hard. The concepts weren't as intuitive. I didn't know how to push through, I didn't know how to dig deep, and my ego told me that office hours and tutoring were for other people. My ego told me my grades were more important than my learning, and so I half learned things by just scraping by on some assignments. For exams, sometimes I learned what kind of questions would appear and how to answer those questions instead of learning for the love of learning. I understood some things for long enough to hand in the assignment. I no longer took the content and made it part of myself in a deep, self-altering way.

My short term, short-sighted focus on the deliverable recurs in some aspects of my work and my life. I have consistently worked with people at or above my intelligence level. Intellectually, some people will get some topics faster than I do, and I'll get some topics faster than others. But when I don't understand a design, an algorithm, or solution at work I struggle to ask for clarification and I didn't do the work on my own to figure it out later. My ego says "Don't admit to them, or yourself, that you don't get it." And I skated by, not growing myself as I could have.

This probably sounds like I haven't learned or that I haven't grown in the past decade. That's not true - I rocked some courses, I have put in great work on some projects. However, I have grokked things more slowly than I could have. I've wasted days of work trying to understand solutions before understanding the components of the solution. For example, I have participated in team design discussions suggesting the details of the MapReduces we'd use before reading the Wiki page on MapReduce and writing a few. Time and again I've tried to solve the problem before understanding and internalizing the components of a solution. Each time, I've done myself, and my team, a disservice.

So how do I grow myself? First, I get the ego out of the way. I admit to myself, and to others, that I don't know or don't understand. Quoting Penn Jilette talking about one of the best minds of the twentieth century, Richard Feynman:
My friend Richard Feynman said, "I don't know." I heard him say it several times. He said it just like Harold, the mentally handicapped dishwasher I worked with when I was a young man making minimum wage at Famous Bill's Restaurant in Greenfield, Massachusetts.

"I don't know" is not an apology. There's no shame. It's a simple statement of fact. When Richard Feynman didn't know, he often worked harder than anyone else to find out, but while he didn't know, he said, "I don't know."

I like to think I fit in somewhere between my friends Harold and Richard. I don't know. I try to remember to say "I don't know" just the way they both did, as a simple statement of fact. It doesn't always work, but I try.

Second, I start slower. I learn the material. I never start on a poor foundation. I don't let deadlines cause me to try to create a solution without the necessary comprehension.

Third, and the most important, is growing my consciousness. I get tunnel visioned - and my higher, self-reflective brain takes a vacation. That's the part that can actually change these habits and break the cycle. To be more self-reflective, I need to slow down - I should stop typing code when I should be thinking, asking more assertively when I don't understand. In my most panicked times, I'm doing my team a disservice by trying to fix problems before I understand the problem and the solution.

I have a few things I'm going to attempt to grow my consciousness:
  • Do one thing at a time. Be present for it.
  • Make sure each day contains one non-work thing I'm present for and do without the nagging guilt of "you should be doing something else". Cycling, yoga, weight lifting, driving the coupe, reading for an hour - anything that absorbs me completely.
  • Learn. Ask. Quiet the ego and say, "I don't understand. Would you explain that again?"
  • Slow down. Recognize that if I slow down I'm more likely to make deadlines, and if I miss a deadline I might as well learn something.
What do you think? I've checked my ego, is there something I can do to be better? Do you suffer the same?

Monday, September 12, 2011

The first 90 days

If I had written this paragraph, it would have also included the words "panic" and "anxiety." But this is a good summary of my first 90 days.

During times of rapid growth, a team doesn't necessarily take the time to stop and get to know each other because they arrive and the first thing they notice is, "Whoa. Everyone is in a big fucking hurry, so I must hurry as well." Their normal instincts regarding getting to know those around them are buried in their goal of being recognized as a person who is also in a hurry.

From Rands' post Fred Hates It.

Monday, October 09, 2006

Getting things done

I have decided I am not getting enough of my 'core job' done (I have lots of things to say I do, but I'm not making enough progress on what I am really judged by)

I will therefore:
1. Attend fewer meetings
2. Make todo lists each day