Permalink
Browse files

Writing improvements from using text-to-speech.

  • Loading branch information...
rudi-c committed Nov 23, 2015
1 parent 2589f19 commit 0ad55f4f777cae7b2256aa0a715432830ee4ddc0
@@ -8,18 +8,18 @@ disqus: y
This is one of four blog posts on my experiences interning at Dropbox in Fall 2014 and Summer 2015. Read more about [my second internship](/2015/10/12/dropbox-second-internship.html), [maximizing signal in interviews](/2015/10/12/dropbox-interviews.html) and [the social, cultural and business aspects](/2015/10/12/dropbox-misc.html).
-In my first internship at Dropbox, I was assigned to work on the Carousel iPhone app. In a nutshell, [Carousel](https://carousel.dropbox.com/) is a photo gallery app that auto-uploads your photos to the cloud and allows quick access to any of your photo stored in Dropbox. My first project would be high-resolution zooming on images stored in the cloud, as the app originally only displayed a screen-size thumbnail.
+In my first internship at Dropbox, I was assigned to work on the Carousel iPhone app. In a nutshell, [Carousel](https://carousel.dropbox.com/) is a photo gallery app that auto-uploads your photos to the cloud and allows quick access to any of your photo stored in Dropbox. My first project would be high-resolution zooming on images stored in the cloud, as the app originally displayed only a screen-size thumbnail.
<center><img src="/images/2015/10/carousel_ios.png" width="350"/></center>
-This was an interesting project because I got to design and implement the entire feature while keeping in mind the many practical constraints that go into doing it well. The simple approach would be to just download the higher resolution image and display it. Then I’d be done in very little time. However, the full image could be arbitrarily large and downloading the entire file could be very bandwidth intensive. In a mobile app, bandwidth is a limited resource. Furthermore, why download the full-image if the user just zooms into a portion of the screen? Therefore, I split the image into tiles and fetched the tiles on a per-need basis.
+This was an interesting project because I got to design and implement the entire feature while keeping in mind the many practical constraints that go into doing it well. The simple approach would be to download just the higher resolution image and display it. Then I’d be done in very little time. However, the full image could be arbitrarily large and downloading the entire file could be very bandwidth intensive. In a mobile app, bandwidth is a limited resource. Furthermore, why download the full-image if the user just zooms into a portion of the screen? Therefore, I split the image into tiles and fetched the tiles on a per-need basis.
-Among other projects, I also helped ship Carousel for iPad by maximizing the usage of the screen real estate. Photos are grouped into events. If all the images were the same size, then events that only have a few images would be left with whitespace. Those projects were interesting exercises in understanding the distinction between doing something and doing it well, and I learned the culture at Dropbox leans strongly towards doing it well, “sweating the details”.
+Among other projects, I also helped ship Carousel for iPad by maximizing the usage of the screen real estate. Photos are grouped into events. If all the images were the same size, then events that only have a few images would be left with whitespace. Those projects were interesting exercises in understanding the distinction between doing something and doing it well, and I learned that the culture at Dropbox leans strongly towards doing it well. They call it “sweating the details”.
From doing it to doing it well
------------------------------
-A photo gallery app sounds mundane, but as I learned more about the functionality of the project and dove into the codebase, I quickly realized that Carousel was far from “just a photo gallery”. There’s a [series of 3](https://blogs.dropbox.com/tech/2014/04/building-carousel-part-i-how-we-made-our-networked-mobile-app-feel-fast-and-local/) [blog posts](https://blogs.dropbox.com/tech/2014/08/building-carousel-part-ii-speeding-up-the-data-model/) [describing the engineering](https://blogs.dropbox.com/tech/2014/10/building-carousel-part-iii-drawing-images-on-screen/) behind Carousel that reveal the magic behind the scenes.
+A photo gallery app sounds mundane, but as I learned more about its functionality and dove into the codebase, I quickly realized that Carousel was far from “just a photo gallery”. There’s a [series of 3](https://blogs.dropbox.com/tech/2014/04/building-carousel-part-i-how-we-made-our-networked-mobile-app-feel-fast-and-local/) [blog posts](https://blogs.dropbox.com/tech/2014/08/building-carousel-part-ii-speeding-up-the-data-model/) [describing the engineering](https://blogs.dropbox.com/tech/2014/10/building-carousel-part-iii-drawing-images-on-screen/) behind Carousel that reveal the magic behind the scenes.
In a nutshell, the two technical aspects of Carousel I was most impressed by are the performance and the handling of edge cases. One of the nice features of Carousel is that I can quickly scroll through my entire photo library to look at my old photos. This sounds simple but when you have thousands of pictures going across the screen, even decoding the JPEG becomes a bottleneck. All kinds of prefetching and caching techniques went into the scrollbar alone.
@@ -32,12 +32,12 @@ Code sharing
The other aspect of working on Carousel iOS which was very educational is the unusual architecture of the codebase which works out great. Half of the iOS and Android app’s code is a shared layer of C++. To interface with C++ from Objective-C and Java, Dropbox developed an open-source [language interface generator](https://github.com/dropbox/djinni).
-It is desirable to share code across mobile platforms. How can it be done? You could write a [Java to Objective-C compiler](https://github.com/google/j2objc). But let’s assume that you don’t have unlimited resources [^0]. You could go with a portable approach like Web or one of the many cross-platform toolkits out there. However, it will be difficult to achieve a native feel, it will not have the same polish. Or you could share some native (in the sense of light on the runtime) code [^1].
+It is desirable to share code across mobile platforms. How can it be done? You could write a [Java to Objective-C compiler](https://github.com/google/j2objc). But let’s assume that you don’t have unlimited resources [^0]. You could go with a portable approach like Web or one of the many cross-platform toolkits out there. However, it will be difficult to achieve a native feel, it will not have the same polish. Or you could share some native code (native in the sense of light on the runtime) [^1].
A shared layer in C++ also has performance benefits, and C++11 with smart pointers is reasonably ergonomic to work with. I also found that having a distinct codebase for shared code forces the design of better abstractions. For example, in the context of MVC, the C++ code takes on the role of model, and it’s harder to slip up by putting model logic in the view or controller, and vice-versa.
-Finally, most companies would not have chosen this approach because the tools did not exist and had to be developed. This is the great thing about working at a top tech companies. Risks are taken and new approaches to software engineering are discovered.
+Finally, most companies would not have chosen this approach because the tools did not exist and had to be developed. This is the great thing about working at a top tech company. Risks are taken and new approaches to software engineering are discovered.
[^0]: I’m curious as to how well that approach works. Among other complexities, making a transition from tracing garbage collection to reference counting can be very hairy, from my experience working on compilers. There’s always ways to make it work, but at the cost of developer effort.
-[^1]: For high-performance apps like Carousel, latency induced by GC pauses is significant. The shared layer should not be in language with a tracing GC as having two separate garbage collectors kicking off at random times is going to lead to very challenging scenarios.
+[^1]: For high-performance apps like Carousel, latency induced by GC pauses is significant. The shared layer should not be in a language with a tracing GC. Having two separate garbage collectors kicking off at random times is going to lead to very challenging scenarios.
@@ -10,11 +10,11 @@ This is one of four blog posts on my experiences interning at Dropbox in Fall 20
_Important note: while the words “Dropbox” and “interview” are both present in the title, this isn’t a guide on “how to pass Dropbox interviews” so much as a discussion on the design of tech interview questions._
-I’m interested in how companies’ interview process are designed and evolve, because it has strong impacts on the culture. For most candidates, it is their first direct interaction with the company. I anticipate that one day, I will have to conduct interviews myself [^0].
+I’m interested in how companies’ interview process are designed and evolve, because it has strong impacts on the culture. For most candidates, it is their first direct interaction with the company, their first impression. I anticipate that one day, I will have to conduct interviews myself [^0].
Interviews are an attempt to predict one measure from another. They want to predict one set of measures such as “technical performance” and “will I get along with this person?” using another set of measures such as “past achievements” and “ability to solve coding problems”.
-To make predictions effectively, the interview process needs to minimize variance and control bias. This is a very hard problem to solve. Besides having gone through Dropbox’s interview process myself, I also shadowed a few interviews and referred a number of people, some of whom passed and some of whom did not, which gave me a good sense of how Dropbox approaches it and how hard the questions are.
+To make predictions effectively, the interview process needs to minimize variance and control bias. This is a very hard problem to solve. Besides having gone through Dropbox’s interview process myself, I also shadowed a few interviews and referred a number of people, some of whom passed and some of whom did not. This gives me a good sense of how Dropbox approaches it and how hard the questions are.
A key concept is that of “maximizing signal”. This term shows up a lot in internal training documents and discussions. You want the interview to tell you as much as possible about the candidate and minimize the number of ways the candidate could fail due to “bad luck”.
@@ -25,7 +25,7 @@ For example, interviewers at Dropbox don’t want to have the candidate stuck, e
Alternatively, while it is nice when the candidate has a mastery of their language of choice, it isn’t a big deal if they forgot the particular interface for a certain function. In real-world situations, search engines are available [^1]. This is why I'm not fond of running the program in an interview. That often requires a trivial mechanical process of fixing some syntax errors. Getting the right understanding of the problem is the non-trivial part.
-However, ‘being willing to give hints’ (from the interviewer’s perspective) and ‘being willing to ask for hints’ (from the candidate’s perspective) are both easier said than done. One story I heard is that for a while, Dropbox had trouble with European candidates. Some would stubbornly refuse to take any hints and would keep heading down dead-end paths. After a while, an intern pointed out that in some European countries, students are taught to ignore hints because it was typical for the local interview to test the candidate by trying to mislead them. These cultural differences introduce noise that can be very difficult to account for [^2].
+However, ‘being willing to give hints’ (from the interviewer’s perspective) and ‘being willing to ask for hints’ (from the candidate’s perspective) are both easier said than done. One story I heard is that for a while, Dropbox had trouble with European candidates. Some would stubbornly refuse to take any hints and would keep heading down dead-end paths. After a while, an intern pointed out that in some European countries, students are taught to ignore hints because it was typical for interviewers at local firms to test the candidate by trying to mislead them. These cultural differences introduce noise that can be very difficult to account for [^2].
Maximizing signal
-----------------
@@ -38,16 +38,16 @@ Dropbox also has some interview questions that are not particularly difficult co
In contrast, I've sometimes had interviews at other companies where I felt I was asked a question that sounds like an interview question but it's not clear what it measures beyond basic ability to write code. It can feel a little artificial. Seeing Dropbox’s interview process inspires me to choose questions I might ask myself more carefully, if nothing else.
-_Of course, everybody's experience will vary._ I think Dropbox does a good job at training the interviewers but it's not amazing to the point where everyone will have a good experience - at least one of my friends did not. While interviewers are trained in ways to maximize signals, some interviewers might be less experienced, less motivated, less sharp, less friendly, having a bad day, etc. If you've never interviewed with Dropbox but are planning to, please do maintain reasonable expectations even though I'm saying some good things about the process.
+_Of course, everybody's experience will vary._ I think Dropbox does a good job at training the interviewers but it's not amazing to the point where everyone will have a good experience - at least one of my friends who applied did not. While interviewers are trained in ways to maximize signals, some interviewers might be less experienced, less motivated, less sharp, less friendly, having a bad day, etc. If you've never interviewed with Dropbox but are planning to, please do maintain reasonable expectations even though I'm saying some good things about the process.
I personally don’t find that the questions are significantly harder than those of other major tech companies. What I think gives Dropbox [the reputation](http://qr.ae/RoSicS) [of being selective](http://qr.ae/RoSix9) really lies on the process being very comprehensive. Otherwise, the questions aren’t domain specific and there’s not much to do to prepare for them besides work on a variety of software and write lots of code.
Controlling bias
----------------
-After having interviewed at Dropbox and many other companies, I’ve been noticing more and more the connections between the company’s engineering problems and the interview process [^4]. Dropbox’s main product needs to solve a massive amount of edge cases and getting a single one of those wrong could mean the loss of customer data. The amount of data processed on a daily basis in enormous, meaning a more efficient algorithm can lead to huge savings in server costs. Everything ends up involving concurrency. Considering that, it’s no surprise that the interview aims to be very comprehensive.
+After having interviewed at Dropbox and many other companies, I’ve been noticing more and more the connections between the company’s engineering problems and the interview process [^4]. Dropbox’s main product needs to solve a massive amount of edge cases and getting a single one of those wrong could mean the loss of customer data. The amount of data processed on a daily basis is enormous, meaning a more efficient algorithm can lead to huge savings in server costs. Everything ends up involving concurrency. Considering that, it’s no surprise that the interview aims to be very comprehensive.
-Alternatively, I’ve had a startup ask me to make a small modification to their main product which is open-source code. Seems very sensible - there's hardly any way to make the evaluation more similar than the job responsibilities than this. Jane Street’s interview process is as long as Dropbox’s, but the problems are slightly harder and slightly less comprehensive - makes sense, their product is more specialized.
+Alternatively, I’ve had a startup ask me to make a small modification to their main product which is open-sourced. Seems very sensible - there's hardly any way to make the evaluation process closer to the job responsibilities than this. Jane Street’s interview process is as long as Dropbox’s, but the problems are slightly harder and slightly less comprehensive - makes sense, their product is more specialized.
Every once in a while, I’ll see an article show up on Hacker News or a question on Quora about how tech interviews are broken[^5] and how one approach is better/less discriminatory than others. In comments/answers, the same points get brought up every time: “no one implements algorithms in real-life” “I’ve never used recursion” “I did have to use recursion” “I want my candidate to know how to write efficient code” “I don’t have the time to prepare for those kinds of interviews” etc. Given that it’s all engineers discussing this topic, I find it interesting how a lot of time, these discussions miss the big picture: interview processes should be tailored to whatever the organization needs, and that’s always a different answer for each company.
@@ -57,7 +57,7 @@ Interviewing is an art, and it is one that I will inevitably need to learn.
[^1]: I was careful not to say “always” available. Google is a source of information, and function interfaces/language features are purely information. Google doesn’t solve problems for you. I could spend forever talking about this but that it’s very common to hear the excuse “I could Google it” when it’s besides the point. Yes, you would use a binary search library in production when applicable rather than writing one yourself. No, it's not always applicable - I don't know how many times I've seen problems that required subtle variations on binary search, and implementing a solution requires a good understanding of the fundamentals.
-[^2]: This is one situation that is hard to do anything to mitigate concretely besides having a diverse group of employees who collectively are aware of a lot of these differences and can communicate them to each other.
+[^2]: This is one situation that is hard to mitigate in a concrete way besides having a diverse group of employees who, collectively, are aware of these differences and can share this knowledge with each other.
[^4]: As for the companies where the connection was missing, I felt like they didn’t care enough about hiring/getting the best people.
Oops, something went wrong.

0 comments on commit 0ad55f4

Please sign in to comment.