Web3 OGs and folks in the ecosystem generally deeply believe in one or a few L1 blockchains. But how do you figure out which L1 makes most sense to you? There are as many L1s as pubs in Koramangala and its only increasing. For newbies just getting into crypto, their attention is usually diverted to one of the following:

→ Blue chip protocols - BTC, ETH. → Platforms which have had coverage cause of recent traction / bull runs / funding. → Platforms which crypto ogs and influencers tweet about / discuss. → Platforms because of which a friend / loved one has made wealth

DYOR (do your own research) is all over the web3 space, but the reality is that the activity of web3 noobs is limited to protocols which are accessible and not intimidating. Although any starting point is good, the real friction comes with progressing further. Accessibility and ease of understanding web3 platforms is seldom an enabler today, it is more of a deterrent. Listening to secondary research / unsolicited advice / a friend and making quick profits (do you, really anon?) is just easier.

In this article, I aim to help you DYOR. I’ll be talking about a framework which will help you evaluate L1 blockchains. I’ll be going through different angles to assess L1s by:

• L1s as sovereign economies

• The Trilemma

• The L1s role - Governance, Policy & Culture

• Metrics to look at - Macro & Traction

Feel free to jump to whatever’s relevant to your context. Let’s go!

L1s as sovereign economies

When talking about L1s, most initial conversations are skewed towards technicalities or the trilemma. Although this is an important aspect, at the end of the day, the value of an L1 will be based on on-chain economic value generated and initiatives taken to grow variables which will enable the same.

We of course can’t dismiss the trilemma and we will discuss the same later in the article.

The introduction to Michael Porter’s theory on the competitive advantage of nations, goes like this —

National prosperity is created, not inherited. It does not grow out of a country’s natural endowments, its labor pool, its interest rates, or its currency’s value, as classical economics insists.

A nation’s competitiveness depends on the capacity of its industry to innovate and upgrade. Companies gain advantage against the world’s best competitors because of pressure and challenge. They benefit from having strong domestic rivals, aggressive home-based suppliers, and demanding local customers.

Inspired from his framework, we will look at conditions which are crucial for an economy to flourish and extrapolate these to L1 blockchains.

1. Factors of Production

Capital - Financial and Human

→ Crypto idealists balk at announcements about VCs funding L1s with millions, questioning the real extent of decentralisation. While the intent is good, nation building requires large financial ammo. We’re transitioning from an entirely centralised world to a gradually decentralised world. A utopian decentralised world will not happen immediately and even if it does, it will break, we can’t handle it.

→ Finding good developers is hard. For an L1 to prosper, it needs an army of developers and talent who are building dApps or companies / industries on the chain.

• Initiatives taken and capital deployed by L1 to up-skill and train web2 developers to web3?

• How easy is the transition from a web2 language to the language in which L1 is written. (eg: js → solidity transition)

• Traction / awareness of the L1 in places with high developer density.

2. Domestic Competition

For any company to be internationally competitive, domestic industry must flourish with healthy competition and promote innovation and growth. An exchange on Ethereum isn’t just competing within the chain but also with exchanges on other chains.

• Is there strong competition within players in an industry on the chain?

• Balance between knowledge sharing for mutual and industry growth and respecting proprietary IP.

3. Supporting and Related Industries

New products, niches and industries don’t develop out of nowhere. Horizontally and vertically aligned products and sectors lead to this happening.

Eg: NFTs give perpetual proof of ownership and fractionalising them helps in distributed ownership. DAOs help people who would normally be unable to access high value assets to organise and come together.

The outcome of this is not just a bunch of products / industries working together, but the symbiotic relationships resulting in synergy + a moat. An L1s composability and policies + culture should accelerate creation of this moat and encourage innovation.

4. Infrastructure

The ability for chains to onboard and integrate the following is critical to their short-term growth and long-term sustainability.

Developer tooling

Tools to ease building dApps by developers post transitioning to web3 development.

• Frontend and backend APIs, Out of the box tools, Messaging and Testing.

TVL Drivers

Bringing liquidity to the platform by establishing a basic deFi system. This incentivizes the core developer community to build better tools and abstractions, thereby allowing less sophisticated ones to build more consumer-facing products.

• Lending and borrowing, AMMs, Exchanges and Staking.

Interoperability

Enabling cross-chain communication through asset or general-purpose bridges.

• Bridges, Routing and Cross-chain calls.

Data Availability

Focus on bringing quality data on chain, either through oracles or a specialized data availability layer. Indexing this data and displaying it in an easy-to-understand format is necessary (e.g. on an explorer).

• Oracles, Explorer, Storage and Indexer.

5. Demand dynamics

User personas of the demand and creators matter a lot. Having 1k high quality users who genuinely understand what’s happening and proactively use + contribute to the development of an L1 ecosystem have much more value than 10k users who don’t have a clue of what’s going on and are just lurkers on another L1.

The Trilemma

A good way to check a blockchain’s technical soundness is to understand how they’ve approached / solved the trilemma problem. The blockchain trilemma is a term coined by Vitalik is used to describe the challenges developers face while building a blockchain and keeping it decentralised, secure and fast without compromising on any facet.

Variables contributing to solving the Trilemma

→ Scalability

• Horizontal scalability - Processing power of the network must increase with the increase in the number of nodes. Although realistically it will be sub-linear, ideally, it is expected to be linear.

• Low overhead - The additional cost to ensure security and process the transaction should be minimal relative to the cost of processing the transaction.

• Short time to finality - The time taken to update the state of transaction, once submitted, must be minimal.

→ Security

• Protection from attacks - Malicious parties should not be able to convince the network that invalid transactions are valid with ease. Bad behaviour must be deterred using game theoretic incentives or cryptographic methods which make it computationally infeasible to carry out an attack on the network.

→ Decentralisation

• Node requirements - Computing requirements must be minimal to make allow more people to participate in the network.

• Freedom to participate - The platform must be censorship resistant and people must be able to discuss freely on the network.

Tradeoffs around the Trilemma and Blockchains

→ Decentralisation vs Speed

For a blockchain to be decentralised, there needs to be several nodes in the network. The tradeoff of increased decentralisation is speed. This is because of the fact that multiple confirmations needs to achieved in order to arrive at consensus.

→ Speed vs Safety

If the TPS of a network is high due to low time to finality, there is a compromise on safety. This is because, faster the block speed, lesser the time validators have to agree on state transitions. Without enough time to reach consensus, rollbacks could become frequent, thereby compromising safety.

→ Decentralisation vs Computing power (which could translate to speed / security)

To truly make the network decentralised, the computing requirements to be a node needs to be least in order to make it accessible. If this is done, then the aggregate computing power of the network is less because of less capable nodes. The hurdle for scaling will be to have a lot of nodes on the network to make up for the capability of each node.

Although there is no rule that decentralisation, speed and security are tradeoffs, it is a well recognised problem which the community is trying to solve. Several blockchains claim to have solved the trilemma, but that usually isn’t true without caveats.

The L1s role - Governance, Policy & Culture

The challenges in building and problem solving must inspire solutions and entrepreneurship, rather than demoralise or daunt the builders and users in the ecosystem. The L1 must play its part in fostering a culture and set of policies that enable and empower ecosystem participants to feel motivated and contribute with ownership.

The L1 must focus on fostering competition within industries and take initiatives to improve human, financial and infra capital to enable builders. L1 support for some niches in the ecosystem in terms of grants or subsidies must be driven by long term goals in mind and not for short term traction.

Some industries are strategic for any chain, stable coins and related products for example. Others are more strategic and to be aligned with the competitive advantage which the L1 decides to pursue / build on basis of its technical limitations / advantages and culture.

Eg: India IT and outsourcing, Korea electronics, China manufacturing. Adopting a gaming focused strategy for an L1 with high transaction speed and just enough security makes sense.

Metrics to look at to value L1s

Macro Metrics

• Market cap

• Daily trades volume

• Amount raised

• Number of dApps over time

Traction Metrics

• Daily transactions vs price - greater no of transactions means more economic activity, which in the long run reflects the demand for the currency.

• Blocks per hour

• Active Users (Daily, Weekly or Monthly)

• Total transactions (number)

• Value of transactions (value)

• Balances in smart contracts (value)

• Transactions to/from contracts (number)

• Value of transactions to/from contracts (value)

• Wallets value (value)

Although this isn’t an exhaustive or advanced set of metrics, these give a good idea of how sound an L1 is fundamentally, and if it is set to grow or not.

Hope this helped and if it did, fund me to encourage me to write more!

Feel free to reach out to me on Twitter @idlyboy_ to discuss DAO, NFT use cases or web3 in general! Peaceout 🤟🏽

I joined Pratilipi in April as a Product Designer, when COVID-19 had just broken out. Read on, as I share my experiences as a Product Designer and how I transitioned to a Product role in 6 months.

Context

I was quite excited when I joined Pratilipi. I knew it would be a great learning experience, and couldn’t wait to get started. I was offered the role of ‘Product Designer’ towards the end of March and I accepted the offer right then. COVID-19 cases were starting to rise and WFH protocols had just been put in place across organizations, so presence was already increasing in virtual workspaces.

The idea of starting my first full-time UX role online wasn’t particularly pleasing. I thrive by learning from people and being in an environment around folks to bounce off ideas and learn from — zoom calls just didn’t seem to cut it. Starting a role at Pratilipi, was in itself different from how it would’ve been at usual organizations. I had worked with flat, lean teams, but this was a step up. Let me explain:

Pratilipi’s culture is anchored around its people. We’re highly ownership driven, and seldom do we performs tasks assigned by ‘superiors’. There are priorities, goals and if you feel that a hypothesis is worth exploring and can drive growth, you’re free to experiment with the same. Of course, there needs to be some backing and rationality behind the hypothesis, but this freedom is present across teams.

Although this was exactly what I’d hoped for when I joined, the idea of being left alone to explore was slightly overwhelming and I began questioning my abilities, especially since I was WFH.

Starting my first UX role

I had introductory zoom calls with the team, where we discussed how I could start out. Based on their recommendations, I learned that it was good practice to start off a new role by solving low-hanging fruits — these were well spottable issues which if solved could give good ROI. This made sense because:

• As you solve low hanging fruits you pick up momentum and prove your abilities.

• By doing so, you gain the trust of your teammates who start to believe in you, bringing credibility.

• This enables you to pick up tougher, more complex problem statements with confidence.

I identified a set of UI/UX problems which I thought were low hanging fruits and ranked them by urgency and ROI. As I got on a call with the Product Head to discuss the same, she said that these could definitely be worked on, but that she specifically had a challenging problem statement in mind for me. Over call, she gave me some context about the onboarding problem at Pratilipi — our goal was to improve the % of users completing their first read upon installing the app.

The onboarding problem wasn’t quite a low hanging fruit. Past theses had been experimented on and it wasn’t an easy number to move. But at the same time, I had the opportunity to work on a challenging problem. I had worked on the onboarding of Tring, but this was in an entirely different context — different problems, different users, and most importantly, the difference in scale. We had barely shipped Tring to 500 beta users whereas Pratilipi was at 1.5 mn DAU when I was working on this problem.

After doing my initial research and going through the current onboarding flow, I was confident that there was scope for improvement. Even if my first set of experiments failed, I’d learn from them and iterate to improve the funnel. I pinged my product head and told her that I’d love to take it up.

I worked on my experiments for almost a month and was able to drive a single-digit % growth in our onboarding funnel. Although the outcome was positive, I had taken too much time to churn out experiments, especially considering that I had no proven track record, within or outside of Pratilipi. I will talk about this in detail later.

Gaining momentum

After my first relatively successful experiments, I was confident about my abilities to a certain extent. I was still not quite satisfied because of the turnaround time of experiments. I had been with the team for a month and had just worked on one set of experiments — I knew I could do better.

Post onboarding, I wanted to figure out / do two things:

• Upskill myself and chart a path to step up to product management.

• Experiment rapidly around different problem statements to — 1) figure out ones which I wanted to work on in-depth, and 2) rekindle my lean, iterative nature as I was being too cautious.

To do this, I picked up a few problem statements which required varied approaches. Over the next couple of months, I always had 3–4 problem statements which I was working on at any given point in time.

I ensured that I was fast and iterative in nature to learn as much as I could, in order to fuel my path to product management.

Few mistakes and learnings

Analysis Paralysis

“That’s what she said” — Michael Scott

Working on onboarding was time-consuming for me. This was because I was trying to solve it upon understanding the depth of the problem, and doing that meant learning to use Amplitude to understand users. This was the first time I was using Amplitude and a universe of user data was like porn to me- I spent time looking at a lot of data and not using it for anything solid/impactful.

Pratilipi is extremely lean, and the team (especially product) aims to churn out experiments quickly and iterate on them. Taking a month to even produce experiments wasn’t quite ideal.

I was hired as a product designer and I had to prove that I could get things done as a product designer before showing I could do much more.

I didn’t even realize a month had passed since I was working from home and the number of feedback loops in place were less.

‘Making up’ for lost time

Post my onboarding I decided to speed things up and took up 3–4 problem statements at once to ‘make up for lost time’ and prove myself. I learned the hard way that prioritizing is very important. For a week or two I was a mess and couldn’t keep up focus across different contexts. I wasn’t solving every problem to the best of my ability because of the constant context switching.

A candid discussion with my Product head and CEO helped me understand this, and moving forward, I prioritized my time better, only focusing on 1 cognitively taxing task at a time. Others on my plate were usually less cognitive or execution-oriented. This learning was quite important, especially if I wanted to step up into the Product one day.

Product design vs Product management

Upon numerous discussions with my mentors and having worked in Product teams, this is my mental model of what Product management essentially is.

PM roles, as I understand, can be broken down into 3 parts:

User & Design: All about users, their journeys on the product, and its visual aspects. Involves understanding the user and designing simple but efficient flows to achieve a goal.

Business & data: Data is an essential part of understanding your user behavior. An important aspect of product management is to translate user metrics to business goals and KPIs. North star metrics that startups strive to improve are usually a reflection of their future monetization strategy/business model.

Engineering & tech: Tech startups are at the forefront of innovation. Technology is vital in today’s context in terms of being an incredible catalyst for innovation and large scale distribution. That being said, understanding how your product is engineered and the tech stack powering it is a vital aspect of product management.

These 3 parts can have different levels of importance across different startups. This is highly dependent on the problem being solved and the approach to the same.

Something which I’ve also observed is that breaking it down from a skillset/domain point of view doesn’t quite paint the complete picture. A product manager does much more —

• Figuring out what problem statements are worth picking up and deciding their scope.

• Planning, strategizing, prioritizing.

• Understanding and mobilizing people and resources available.

• Communicating effectively and bridging stakeholders’ expectations and output across domains.

A product design role is a deep-dive into the user and design aspects. From my experience as a Product designer, this is how I’d break it down:

User Interface: UI refers to the visual aspect of the product and connecting design elements like colour, font, typography, etc. to your users and the problem you’re solving.

User Experience: UX is how you understand your users and generate insights to fit the product experience with your user’s mental model. This involves talking to users, doing research, deriving insights, and using them to create logical flows on your product which leads to user satisfaction.

Product: Good designers understand the intersection of product and design. Understanding metrics to understand users, and connecting the user experience with business goals is important. Ultimately, your design has to impact north star metrics or proxies associated with the same.

My transition to Product Management

I’ve spoken with PMs and mentors to understand what the best time to transition is, and have learned that there is no real ‘best time’ as such. A good starting point although, would be when you have a good, in-depth understanding of at least 2 out of the 3 key aspects of PM. Most importantly, you should feel more excited than intimidated about stepping up.

As a product designer, I was good with user and design, which meant that I needed to get better at data and tech. These are my learnings on how I actually stepped up and I’ve broken it down into 3 parts:

Up-skilling

From day 1 of working as a designer, I didn’t restrict myself to the role I was hired for. I took advantage of Pratilipi’s culture and took ownership of the problem statements I was trying to solve. I was highly data-driven, and I wanted to get a comprehensive, in-depth understanding of the problem and user before working on a solution.

An important part of my transition was the ability to quickly learn while executing and up-skilling as and when needed.

Example: I wanted to understand users in depth, and at scale, user interviews don’t cut it. The sample you talk to, more often than not, will not be reflective of the universe of users you’re solving problems for. (Sampling is a skill in itself and we can get a close proxy of the universe, but at scale of 1.5mn DAU the effort vs ROI didn’t quite make sense).So, I quickly picked up Amplitude, a tool we use at Pratilipi to understand user data at scale. It’s a great place to understand behavioural data, identify user patterns and leakages in funnels.

When I wanted to do analysis anchored around data points which weren’t captured on Amplitude since they were stored in the database, I realised that I needed to use SQL. So, I became proficient enough to run simple queries on my own.

Although courses work for a lot of people, I seldom did any — I learn best by doing. My teachers were articles on the internet to understand basic concepts, beyond which my team, the experiments I did and the mistakes I committed taught me best.

I constantly made it a point to have a working understanding of intersection teams. Wherever I sensed the opportunity to learn something new, however difficult it was, I did it as long as it was relevant.

By the 3rd month or so, I had a good grasp on user analytics and in fact started helping a few of my teammates with Amplitude and how to make the most of it. I loved looking at user data and translating it into insights leading to either identifying a problem, or a trend which could be used to solve a problem.

To achieve the transition, I specifically paid attention to my data skills and understanding of Pratilipi’s tech stack. I’ve gotten considerably better on the former and am constantly working on the latter as I solve problems.

Discussing the transition with your PM

I constantly kept in touch with our product head and kept hinting at my expected trajectory — through my work and attitude. It was not an accident that I was doing work beyond a designer’s role, and I made it clear that I could learn fast and get things done.

Within a few months of my joining, in our 1-on-1, we discussed my goals, charted out a path for me to explore product management. Although both of us were on board with the fact that I could explore Product full-time, we agreed that I had a lot more to learn if I wanted to step up.

Stepping up & materializing the transition

Over the next months, whatever problem statements I worked on, I ensured that in the majority of them I could dive deep or contribute from a Product pov. I constantly reconciled with my PM on if I was heading in the right direction and if my problem-solving ability was getting better.

Apart from whatever I was working on, I solved Product-first problem statements in my free time and discussed my learnings and solutions with my mentor during 1-on-1s.

3 months into the role, I started attending scrum meetings every day, to understand what tasks were being prioritized, where the engineers’ focus was and a bigger picture of how Product at Pratilipi worked. This also helped me understand tech feasibility to a certain extent in terms of timelines, bottlenecks, etc.

Every day, I worked to learn something new and in turn bridged skill gaps which made me more confident about stepping into a Product role.

After I was confident enough about stepping up and figuring out a replacement for the Product Designer position, I had a final talk with the Product Head and CEO, where my transition was finalised.

I can’t thank the Pratilipi team enough for the room and opportunities they’ve given for me to grow. Onward and upward guys ❤

Fund me to encourage writing more if you liked this piece and don’t forget to share this with aspiring PMs, especially if they’re currently designing!

In this article, I talk about my experience and then tips on cracking UX roles. Feel free to scroll to ‘Finding the right startups which fit your profile and getting in touch’ if you’d like to skip to the tips.

While evaluating my options after graduation, the startup world seemed ideal for me- I was willing to hustle and work 14 hours a day, to learn. I did have a handful of offers from startups, but I was clear about wanting to be surrounded by people I looked up to — I wanted to work with the best. It was not just a question of culture fit, but an opportunity to learn and work towards growing into a 10x version of myself. 📈

I had one problem, in that I had nothing significant to offer to the team. There was a lot I had to learn to even attempt to join the best teams in the country, because there are hundreds, if not thousands, who wish to join them. My drive to hustle alone would not cut it. (I tried applying on career portals, cold connecting with startup leaders on LinkedIn & Angel, pinging teams who were looking for enthusiastic graduates- nothing quite worked). Upon speaking to people in the ecosystem and introspecting, I learned that I wasn’t interested in sales/traditional marketing roles and didn’t qualify for most of the tech/product roles. I had no proven track record either.

I decided to upskill myself in the same, but wasn’t sure how I could do that. It was a chicken and egg problem- I wanted to work with a tech startup and learn by executing, but I needed to have worked with such a startup in the first place. 🐣

To solve this, I tried a couple of different options. I hit up few product managers who had handled products at startups and were looking to build something of their own. Quite a few of them were looking for hustlers who fit into their culture and constraints. I expected just enough compensation to stay on my on feet; learning was my primary focus. More than a couple of them were happy to have me on their team — I met/spoke to them continuously to find the right fit in terms of a couple of things:

Did I believe in the problem they were looking to solve and in their philosophy? Was my learning given importance to, or was I a resource to complete tasks? How involved would I be in decisions and the entire process itself?

Tring: My experience working with a founder as a first hire

In April 2019, a month before graduating, I started working with a Product Manager, who is currently at Rapido. He was looking to start-up then and we struck a great chord. I shared his love for problem solving, and I could really sense the ownership from his side whenever we discussed my learnings and trajectory. I started off by reading Laura Klein’s ‘Lean UX Startups’ which gave me an idea of how we were going to operate. We worked hard, validated hypotheses through experiments and were highly iterative and lean in nature. Through the next 6 months, I:

• coldly hit up 300+ people (100+ face-to-face; 200+ phone) to validate the problem, solution and understand user psyche. I studied 1,500+ user interview data, derived insights and created personas.

• analyzed 1,000+ reviews on competition apps to rank pain points and understand emotions around the problem and existing solutions.

• created wireframes, and learned to build features aligning with the psyche of different personas. Designed UI for the app & website through multiples cycles of iteration.

• learned SQL to analyze beta user behaviour on Metabase for iterations in Product & UX.

Apart from this, I carried out general startup ops, hiring, making creative assets, and worked closely with two developers (Android and Backend) to better understand the intersections we had.

I worked hard to learn, internalise my learnings and execute. This was especially not easy as in multiple places, pace of execution was crucial and my pace of learning wasn’t quite enough. I had a tough time finding time for myself, while balancing work @ Tring which led to me learning to prioritise.

By the end of 6 months we had built a product with 500+ beta users and had great professional and personal learnings. We didn’t move forward with Tring, since we got investor feedback saying that although we had built an intuitive product, the business model wasn’t scalable.

These learnings wouldn’t have been possible without the mentorship of Karan.

Why UX/Product Design?

In November, with these learnings, I figured it was time I decided on a role and worked towards charting a path for the same at a great startup team. While building Tring, I solved user problems and built interfaces according to user psyche, but I was never really a designer. It was more a tool for me to solve problems. I loved problem solving and one of my biggest learnings at Tring was this- identifying datapoints and connecting the dots to arrive at a solution. Product Management (PM) seemed like a great fit for my profile and interests, so I started applying for Product Analyst (PA) roles.

Quite confident, I sat through couple of interviews only to be disappointed with the results. This was because, most PA roles were data analytics first roles. I had an understanding of the same but wasn’t fluent at it, and it was one of the things I wanted to learn. Usually PA positions are oriented towards validating hypotheses presented by PMs via analytics and presenting their insights. I knew that I had to either change my route to Product Management or learn core data analytics + tech.

I chose the former. Since I had already designed and solved problems for users through design, I decided to start with a product / UX design role with a lateral move to Product management in my roadmap, as I made progress.

I had an idea of how to solve user problems and design a product from 0–1, and now wanted to learn how to craft experiences at scale. User was an important aspect of Product, and these learnings could lead me towards maturing into a PM.

I wasn’t sure how long it would take, but I was determined to learn data analytics and gain a good understanding of tech.

India’s digital adoption is increasing day by day, and for millions, a phone is the first digital interface they come in touch with — this interested me.

I wanted to work with a lean, fast-scaling consumer startup, solving problems for the next billion.

Finding the right startups which fit your profile and getting in touch

It’s important to think about what you want out of an experience, because you’re optimising for a conducive environment for your growth.

Some important things I wanted from my team were:

How ownership driven and flat is the team? Do I believe in the captain of the ship and the vision? Are there mentors in my team who I can learn from constantly? Is there freedom to experiment, fail and learn? Is there opportunity to grow without many barriers or hierarchy? Is the startup looking to scale aggressively in the near future?

I got in touch with Heads of Product and Design on Instagram, LinkedIn and attended a startup meet (YourStory’s Future of Work) to meet these folks and understand what their expectations from a good UXer were. Upon having honest discussions, I was confident in my abilities and felt ready to sit for UX interviews.

(Thanks a lot Adil (PhonePe) and 👑 Sidharth (Headout) for the discussions and help. Your advice was simple and actionable.)

Through the connects I’d made, openings on Angel, and cold messages on LinkedIn, I started applying around first week of March 2020. This wasn’t exactly the best time to get hired and I was aware of that. So, I applied to a varied set of startups:

• Top startups in the country that were going to grow due to COVID (more digitally driven products in spaces like consumer internet, ed-tech, etc.)

• Top startups that were going to be affected by COVID (more ops driven like mobility, food tech, etc.)

• Tier 2 startups where I had a much better chance of getting in (backup).My classification of tier 2 is based on the extent of tradeoffs I had to make in terms of what I wanted from my team.

Design Interviews and Assignments: How I prepped + Tips

Through December to Feb 2020, I sat to study and solidify my understanding of UX. I went through whatever open source library of design/UX knowledge I found, and connected it with my experience at Tring. I made a portfolio project elaborately explaining my work at Tring and I didn’t populate my portfolio with others. I figured that I’d rather do specific assignments given by startups to better display my thought process. Thanks a lot Kanika (Swiggy) for your advice and feedback. You were really helpful 🙏🏻

Most interview processes:

• Introductory call - A general conversation around getting to know the candidate and see if they are worth pursuing. Sometimes, this may be a discussion around your portfolio, but usually is just a vibe check :)

• Design assignment and discussion - For any design assignment, creating just wireframes and mockups doesn’t cut it. *How you arrived at your solution, and why you think this will work has to be explained.*Ensure that you prioritise, plan and estimate timelines for interviews. You usually receive an assignment for each startup you apply to, meaning that you’ll have to plan your applications. Applying to all at the same time means being overloaded with assignments, leading to a half-baked job on all of them. It’s important to understand the context of each assignment, give it due thought and proceed to breakdown and solve it.

Tip 1: It’s okay to ask for your assignment to be given x days later if you’re already working on one.

Tip 2: Upon discussing with the interviewer, iterate on your learnings from the conversation and send a better version of your assignment. Sometimes requested by startups, showing that you iterate based on your learnings carries immense value.

• Assessment of skills, knowledge - UX & design discussions to assess if you know user and design related theories, principles and more (NN group, Laws of UX, Product school, etc. are good open source libraries).

• Calls with Product Managers - This mostly revolves around problem solving, where the PM wants to understand your approach to a problem statement and how you’re breaking it down to find a solution.

Tip 3: Make sure you ask a lot of questions around the problem statement for clarity, make intelligent assumptions, and after each step, reconcile with the PM to see if you’re proceeding in the right direction. If not, ask more questions and pivot.

• Whiteboard exercise with designer (maybe) - Ideally, this is done face-to-face to see first-hand, how you’re thinking through a problem statement and translating the ideas to wireframes and in turn, lo-fi mockups. If this is happening through video, it’s best to have a notepad or Figma file open so you can quickly draw wireframes as you’re discussing the design problem with the interviewer.

• Culture fit - If not integrated with the above calls, HR, the hiring manager or sometimes, the CEO will assess the culture fit over a call. Just be yourself, ask any questions you have and peaceout :)

Note: I’ve seen quite a few people getting frustrated because there are ‘too many rounds’ in an interview process. It’s important to understand that in teams which are people and ownership driven, it’s necessary for both sides to build comfort and confidence in each other- from a skill and culture fit point of view.

During my interviews, I was happy to answer questions and asked as many as needed, for me to build a mental model of what working with the team was going to look like.

After getting in touch with 20+ teams and interviewing with 10, I got 4 offers excluding ones rescinded cause of COVID-19. Of these, I chose Pratilipi since it checked all my boxes. I truly felt that I could learn, loved the culture of the team and thoroughly enjoyed the interview process - it seemed like a great fit. Compensation negotiation wasn’t really a long drawn process for me here because my primary focus was to learn. They rolled out an offer which I felt was fair, and was happy to accept. It’s been 6 months since I joined and when I look back, it feels like time has flown by. I can confidently say that I made the right decision and I’m glad to be driving impact with this set of amazing people :)

Thanks guys, the last 6 months have been lit ❤

Fund and encourage me to write more if you liked this read and share it with folks looking to crack a UX role :)

To read about my 6 months at Pratilipi and how I transitioned to Product from UX, check out: “My 6 months @ Pratilipi: From UX to Product Management”

Feel free to reach out to me on Twitter or LinkedIn!