User Tools

Site Tools


work-stories

Work Stories

  • You solved a customer pain point.
  • You solved a complex problem.
    • You raised the bar.
    IceCondor
  • Complex/Innovation: lmdb-based index, fit in ram constraints
  • Pain point/Challenge: access control, privacy fences
  • Raised the bar: Being early to market with a unique offering
Vault
  • Innovation: portfolio balancing algorithm from meetings with domain expert
  • Challenge: correctness, code tests, manual review
  • Raised the bar: included other developers, best practices
  • Deliver Results: Finish service at the same time as nasdaq api approval
  • Be Curious: async/await promises
ChromaFund
  • Innovation: implementation from public whitepaper
  • Challenge: communicating with meteor daemon
  • Raised the bar: unique offering
  • Deliver Results: iOS app needed
  • Be Curious: helped frontend testing, learned the framework

More Questions

  • Tell me about a time when you gave a simple solution to a challenging problem.
    • the coinmanager part of Chromafund project. Specifically picking a language. The project to date was javascript. Not the best choice for numerical computations, but in the name of developer simplicity, javascript was the best choice for the coin manager piece as well.
  • Tell me about a time when you were working on an initiative and saw an opportunity to do something bigger or better than the initial focus.
    • Instead of outsourcing coinmanager, build in-house
  • Tell me about a time when you found there was a more efficient way to accomplish a task someone was working on. How did you convey it to them?
    • A coworker was tasked with implementing an internal site. They choose an obscure framework that was different than what we were using in-house. I told them what we are already using, and already have dev resources for.
  • Tell me about your most significant career failure and what you learned from it.
    • preference for startup environments, market fit and timing are hard to get right.
  • Give me an example of a time when you were 75% through a project, and had to pivot the strategy - how were you able to make that into a success story?
  • When did you take a risk, make a mistake, or fail? How did you respond, and how did you grow from that experience?
    • Replacing on-disk storage for icecondor from json to protobuf. The protobuf bits came along nicely, integrated with the build system without problem. Most of the updates to the codebase were comparmentalized and updated well. Then there was a hidden 30% of code debt that required a major refactor to finish this feature. A rewrite of the system was already on the schedule so that feature was halted and its goals added as a goal of the rewrite. learn: code coverage matters
  • How have you leveraged data to develop a strategy?
    • Icecondor keeps metrics of unique users accessing the site per day and total location data points ingested. This informs the performance monitoring.

Ownership

  1. Tell me about a time when you took on something significant outside your area of responsibility. Why was it important? What was the outcome? * I was a developer at a startup, and product owner of the backend of the web product. The front end dev team was turning out new UIs and they needed testing. I took on this responsibility to walk through every new feature, looking for bugs or incompatibilities. Its important to find bugs before the customer does. The outcome was a much more fully tested UI.
  2. Describe a time when you didn't think you were going to meet a commitment you promised. How did you identify the risk and communicate it to stakeholders? Is there anything you would do differently? * Nodejs project. A backend transition was planned, switching the ondisk format from json (inefficient but simple) to protobuf (very efficient). The change to the end user was speed of operations. The site was becoming noticably slow. Involved a lot of code changes. The first 75% of the changes went very well. The code was compartmentalized well. The last 25% hit a lot of code debt. We had to change our schedule, by changing the points assigned to that ticket. It was something that users would appreciate but werent expecting it, so we didnt notify the users. In the end the feature was rolled back. The task changed to do more refactoring to get all of the node.js code using a single set of methods for disk access.

Customer Obsession

  1. Describe a difficult interaction you had with a customer. How did you deal with it? What was the outcome? How would you handle it differently? * often my customer was the biz dev department. they had an expectation of new features to sell to new and existing clients. often their schedule was not informed by software team feedback. this led to mismatches between what was promised and what was possible. this sometimes made our scheduling difficult because our team also made a schedule based on the roadmap and the dates were very different.Basically it came down to breaking down the tasks again and again into something easier to estimate, and communicating the list of tasks to biz dev, so they had an idea as to what was involved in any given roadmap line item. After a few weeks of back and forth our schedules started to sync. Differently would be earlier communication.
  2. Tell me about a time when you went above and beyond for a customer. Why did you do it? How did the customer respond? What was the outcome? * A customer wanted their location tracking app to work with the site. It uses different json data to push location data. After looking at the job and realizing it was doable in a reasonable time frame, I extended the API to include the new format. The result was better than I expected because then I enabled the format of two other apps and it started a small ecosystem of apps that were compatible with the site.

Earn trust

1. Tell me about a time when you had to communicate a change in direction that you anticipated people would have concerns with. What did you do to understand the concerns and mitigate them? Were there any changes you made along the way after hearing these concerns? How did you handle questions and/or resistance? Were you able to get people comfortable with the change?

  • Retirement startup; Balances stored in a sql database. I setup the schema for SQL decimal columns. Some members of the team had always used floats. I had to describe the pitfalls of precision loss by using floats. After the meeting they looked up these known problems with float and agreed with the change.
  • Create a stripe customer account at the same time as user account creation, or delay until verification; delay means less work, nothing to remove, if the account is never verified. immediate creation meant a schma constraint could be added to ensure an account always existed
  • Earned trust from a major investor and largest client of the system. Consistent updates, onsite visits, answered any questions they have.
    1. Give me an example of a tough or critical piece of feedback you received. What was it and what did you do about it? * My git commit messages are terse and need more detail. First I review the problem to verify it, went over my old messages. Yes some of them are short and dont describe what the patch actually does. I tarted putting more effort into patch descriptions. This was noticed as a positive change by my coworkers.

    Have backbone, Disagree

    1. Tell me about a time when you strongly disagreed with your manager or peer on something you considered very important to the business. What was it and how did you handle it? Knowing what you know now, would you do anything differently? * Per customer custodial accounts vs one large pot; external circumstances I was unaware of, along the lines of minimum balances to earn interest; would have listened longer custodial partner; we had logs, they had logs. seemed safe enough.
    2. Describe a time when you took an unpopular stance in a meeting with peers and your leader. What was it? Why did you feel strongly about it? What did you do? What was the outcome? * My manager was pushing for extra hours when the team was already working at capacity. I knew the team was at capacity beacuse I kept up good relations with my coworkers and knew what they were feeling. I built a coalition and pushed back. Warned deadlines wont be managed well. The manager heard the feedback once they saw we all agreed, and changed course.

    Deliver results

    1. Give me an example of a time when you were able to deliver an important project under a tight deadline. What sacrifices did you have to make to meet the deadline? How did they impact the final deliverable? What was the final outcome? * Get the stock balancing service ready by the time API approval was given. * Break down the task into the smallest possible subtasks. Categorize and prioritize. For each one ask, is this part of the critical path? If not, Can it be modified or delayed? * Review subtasks with finance/mgmt, sometimes there are externalities that can have a huge impact, unaware to devs * For example, there was a parameter that represented the state of the market as a whole, intended to be deduced from API market data. this was changed to be a manual data entry by the finance dept. That eliminated some development effort and brought the finishline closer * For example, Closing a customer account This processed trimmed the final deliverable to mininum viable product.
    2. Tell me about a time when you had significant, unanticipated obstacles to overcome in achieving a key goal. What was the obstacle? Were you eventually successful? Knowing what you know now, is there anything you would have done differently? * In an early crowdfunding project, all the dev effort went into the backend and the website. it was unanticipated how important having a mobile experience was. the html was optimized for mobile but still not the same. it was decided an iOS app was needed. I was thrown onto iOS dev using Objective-c. The obstancle was defining the product's requirements, and learning Objective-C and the iOS environment. Knowing C already gave me a big head start. Knowning what I know now, we would have started earlier on the app.

    Learn be curious 1. Tell me about a time when you realized you needed a deeper level of subject matter expertise to do your job well. What did you do about it? What was the outcome? Is there anything you would have done differently?

  • Location Tracking Node.js project needed asynchronous operations with a node version that was pre-async/await. I learned Promise handling using a network of callbacks and the resolve() reject() mechanism. It demonstrated the elegance of javascript in some cases. While not the easiest to read, it stuck with existing mechanisms which made it easy to understand. I did a lot of reading of javascript instructive material including blog posts and other js github repos until I knew how to use it effecively. Then when async/await came out I had a deeper understanding that I would have normally.
    1. Describe a time when you took on work outside of your comfort area. How did you identify what you needed to learn to be successful? How did you go about building expertise to meet your goal? Did you meet your goal? * Crowdfunding Node.js project, front end needed testing help. I joined that team part time. I knew some javascript and html. I had to learn the particular js framework in use to be helpful and file tickets. The result was a higher level of confidence in the product.

    Dive deep 1. Tell me about a time when you realized you needed a deeper level of subject matter expertise to do your job well. What did you do about it? What was the outcome? Is there anything you would have done differently?

  • location database. POSTGIS was taking too many resources. storage on-disk and indexes from LMDB. created an index specification schema in json to create these indexes, created an api to query any existing index. on startup, consistency check and index rebuild if necessary
    1. Describe a time when you took on work outside of your comfort area. How did you identify what you needed to learn to be successful? How did you go about building expertise to meet your goal? Did you meet your goal? * Working on a node.js backend, realizing the responses were being processed in a single threaded fashion. The usual solution is to load balance multiple node.js processes, but some kind of central synchronization is still needed, such as redis. Complexity of this implementation started rising and rising. Pivoted to a reimplementation away from node. Something comfortable with multithreaded libs. That excluded python/ruby/GIL scripting langs. Rust seems to be very capable and an emphasis on memory efficiency and parallelism. So the decision was made to start an engineering spike to try an implementation in rust. I started reading rust instructional material, join the rust matrix chatroom. It reached alpha testing and is still ongoing.

    Bias for action 1. Give me an example of a calculated risk that you have taken where speed was critical. What was the situation and how did you handle it? What steps did you take to mitigate the risk? What was the outcome? Knowing what you know now, would you have done anything differently?

  • Interfacing with an exchange API that was launching v2. We wanted those features so we kept in contact with their dev team on their open slack server. The beta documentation helped guide our system to be ready for API V2 on day 1 of launch. The risks were implementing something in api v2 that wasnt going to happen. Being on the slack mitigated that risk.
    1. Tell me about a time when you worked against tight deadlines and didn't have time to consider all options before making a decision. How much time did you have? What approach did you take? What did you learn from the situation? * Choosing a cloud platform for launch. There are a lot of options with different features and prices. A decision was needed in a few days. To speed up evaluation of different platforms I asked devops people I trusted for their recommendations, along with my own experiences. One was selected that worked out well enough. Later on, more niche platforms were found that would have made a better first choice. Now that we're on one cloud, its too expensive to move, at least over the short term.
work-stories.txt · Last modified: 2024/01/31 04:08 by 127.0.0.1