yellow team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

Hi y'all.  We can talk about these tomorrow on our regular call.  Thanks.

Thanks to Benji for the rewrite of exercise 1 and the files he will be providing to support it.  Thanks to Graham for helping me think of the basic idea of exercise 2.

Parenthetically, we have these notes as to questions we could ask for exercise one.  They won't make sense till you have looked at the exercise.

    In Launchpad the people data is stored in a table in a relational
    database (Postgres).  Testing for indirect membership is a common
    operation.  How would you change the data storage and/or the Python
    and/or the underlying architecture to optimize this operation?  What
    would the tradeoffs be?

    You had to handle cycles for the data set in question 3.  Would you have
    wanted to disallow cycles instead?  Why or why not?  If so, how would you
    have done so?

Gary



Assignments for Interview Candidates
====================================

Exercise 1:

[Here we ask you for some Launchpad-themed implementations.  Please return them to us at least one day before our call together.]

Launchpad uses "Teams" to group people.  People may be members of teams,
and teams may also be members of teams.  Because teams can be used in
most ways that People can, Teams and People are both represented through
the Person class.

The Person class (available in person.py) has these attributes:

- id (a unique integer)
- displayname (a string)
- is_team (a boolean)
- members (a list for teams, None for non-team persons)

For all of the tasks below, we'd like to see an answer in Python.  If you
would like to *additionally* provide an implementation in another language
that better shows your programming facility, we will be happy to review it as
well. 

1. Write a function that accepts a person and a list of all people/teams
   and returns a list of all the teams of which that person is a member.
   You can import the "people" list from data1.py to use as example data
   when writing your function.

2. Does your function produce the correct results when you pass it the
   "people" list from data2.py and alice (also from data2.py)?  If not,
   modify your function so that it works correctly given that data.
   What special case does alice from data2.py represent?

3. Does your function produce the correct results when you pass it the
   "people" list from data3.py and alice (also from data3.py)?  If not,
   modify your function so that it works correctly given that data.
   What special case does alice from data3.py represent?

Procedure:

    Applicants will send in these replies to us.  We will spend 30 minutes on
    the call discussing it.  The candidates can each use up to five minutes
    initially on the call to present their code, if desired.


Exercise 2:

[Here we describe a potential feature in Launchpad, and ask for your thoughts
about it.  You will give the answers on the call, though you can optionally
provide us beforehand with whatever support materials you would like.]

Some bugs in Launchpad have dependencies.  They cannot be started until other
bugs are finished.

Some bugs are meta-bugs: they "contain" other child bugs.  Meta-bugs start
when one of the child bugs begin, and end when all of the child bugs have
completed.

Some meta-bugs may have dependencies.  Some child bugs may have dependencies.

As an example, a good example of a meta-bug is the set of bugs relating to
making Launchpad an OpenId consumer.  The top-level bug is
https://bugs.launchpad.net/launchpad/+bug/210943 .  It has many parts, or
child bugs, as you can see here:
https://dev.launchpad.net/LEP/OpenIdRoadmap#Subfeatures .

Some of the child bugs are dependent on other child bugs.  In particular, in
the "roadmap" document, step 6 is dependent on step 5.

The bug relationships in this example are modeled in the "roadmap" wiki page
and in the comments to the respective bugs.  This is hard to manage and
duplicates effort.  What if we wanted to teach Launchpad to incorporate bug
dependencies into its functionality?

Let "project users" mean the triagers, managers, and developers for a given
project in Launchpad.

- Project users want to be able to easily control and see a bug's direct
dependencies.

- Project users want to be able to see a bug's indirect dependencies.

- Independently, project users want to be able to say that a bug is comprised
of other bugs.  The bug moves to In Progress when a child bug starts, and
moves to Fix Committed and Fix Released when all of the bugs move to these
statuses.

Part A:

Choose the user interface for a small part of this problem, such as seeing and
controlling a bug's dependencies, or just seeing the full tree of
dependencies, including "parents" and "children".  Give some ideas of how we
might want to expose this in Launchpad's user interface.

Give your answer on the call.  You can optionally provide us beforehand with
support files such as image mockups, a JavaScript mockup, scanned scribbles,
or whatever works for you.

Take a problem and an approach and that shows your strengths, be they
Javascript, architecture, communications, user interface, or creativity.  Keep
your answer focused on the user's experience.

Part B:

Propose some ideas on how we might architect this.  Feel free to include
conflicting ideas, or challenging ideas!  We are interested in seeing
brainstorming informed by experience.  Right now, Launchpad is primarily a
vertically scaled application, with a central replicated Postgres database.
How might we want to model this in the DB?  What other approaches might we
consider, particularly given our interest in SOA?  What kind of tradeoffs
might we need to consider?

Procedure:

	We have 25 minutes to discuss your answers to these questions.