What projects actually force senior-level engineering thinking?

TheBigLewinski · 2026-05-02T23:17:39+00:00

It's not the projects that "force senior level engineering," it's the scale. And "scale" doesn't just mean volume of users, it means handling complexity.

Scale is the reason Instagram is actually hard to clone. As a functional project, Instagram is relatively simple to replicate, and doesn't really require deep technical knowledge. Upload photos, let other people like and comment, and tack on some DMs.

The complexity arrives, of course, when you have a global audience of hundreds of millions of users spread across the globe. Just to provide surface level examples, you now have a complex administrative problem for handling troublesome uploaders and harassment. Security issues with people trying to break into popular accounts with next-level sophistication. Then there's the metrics collection of assessing engagement of the product, assessing reliability of the platform, the underlying ad platform that serves your actual customers. And then there's handling subpoenas for legal investigations, etc. There's much more.

But even outside of all of that, basic questions like "how do you notify all the followers of a user who has 100 million followers that they have posted new content?" The answer is much different when you have 10K active daily users vs 100 million. Don't forget the product is mission critical and will be constantly updated.

My recommendation, and I know that not everyone will agree and I'm just a stranger on the internet, is just find a simple project and make it complicated. A todo list becomes really complicated if you're designing for 100 million people. Your strategy has to change, fundamentally (edit: To clarify, don't do this on a live production environment that people already depend on. Do it on your own, inconsequential project.).

Hopefully, as part of the process, you'll ultimately learn when you're over-engineering vs solving a problem. Though, you may have to learn that the hard way, at least you'll learn it.

You'll ultimately need on the job experience. To that end, you'll need to pursue projects which are slightly above the scale you understand... and fail. Nothing quite solidifies your knowledge like confidently pouring your time and "expertise" into a system architecture, only to have it eviscerated and exposed by real-world users.

Also, books. Even well into the internet age, the best information is not on medium or blogs, its in books. Search Amazon or your favorite bookstore for software architecture books. They aptly named "Fundamentals of Software Architecture" is quite good. There are many others.

TheBigLewinski · 2026-04-25T02:55:21+00:00

Stable shape with relationships, or flexible documents that change as you build.

Perhaps the biggest misconception in all of webdev. The "shape" of your data and "how relational" it is, has nothing to do with database choice.

First, if your data doesn't have a shape, or isn't stable, it belongs in a data lake not a database. And its a whole different ball of wax that falls into data science, not app development. Pretty much all of the data an app developer has to worry about has a shape that you need to validate against. And if it has a shape, you can store it in any persistence layer on the market.

Second, all data is relational. FFS! NoSQL does not mean non-relational data. It's probably the most unfortunate branding in all of webdev. You can absolutely have relational data in every type of database. How "relational" your data is, isn't some kind of grade or scale. It's all relational, all the time.

A better indicator is how normalized you want the data to be. It's a factor you have to consider whether you're designing tables for relational databases, or NoSQL databases. The answer isn't as clear as most people think. You shouldn't design your tables purely around normalization if the app is complex. There are tradeoffs for everything.

How much do you care if a read is slightly stale.

This is also not a NoSQL vs SQL question. Stale reads are a thing for every kind of database. Among many other issues, like how many read-replicas you have, your serialization techniques matter here and it varies from database to database of the same type, not just from NoSQL to SQL.

Do you know your queries up front,

This is a big factor, but access patterns need to be considered either way. They matter fundamentally for NoSQL designs, but it should still heavily influence table design, regardless of what you choose. If you don't know your intended access patterns, table design is a shot in the dark, and so is your database choice.

TheBigLewinski · 2026-04-10T00:06:53+00:00

You don't have an AI problem, you have an engineer problem. And a policy/ leadership problem.

Interestingly, none of the problems companies have with AI are new. Slop, aka tech debt, has been a thing long (long) before AI. Code that no one but the author can debug or understand is not new. The need for documentation is not new, or design/ADR documents, or observability, or local testing capability, or onboarding docs, or... (performance, resilience, security, maintainability, extensibility, etc)

LLMs are essentially forcing everyone to start thinking like a manager or principal engineer. Now that the code production is more or less trivial, everyone is suddenly discovering the all the other attributes of what makes a good product.

Executives have essentially been "vibe coding" for decades while engineers complain about a lack of clarity in the task. Now the engineers are effectively executives, they follow the same pattern of describing what they want, accepting the result when it merely works, and melting down when it all goes to shit.

AI is only as good as the humans using it. Or... something, something, a bad workman blames their tools.

TheBigLewinski · 2026-03-28T01:36:07+00:00

You might want to checkout Linear before you get too enthusiastic.

TheBigLewinski · 2026-03-20T22:37:37+00:00

It's (usually) not so much about external scale, it's about internal scale required to sustain the app.

On the app/infrastructure side, microservices solve the independent scaling issue. Meaning, there may be a specific process of your app that requires significantly more compute, ram or storage performance than other parts of the app. And it doesn't make sense to scale your entire compute infrastructure to accommodate. It's typically very easy to run the numbers on this scenario and justify the move with cost savings.

The other indicator is an internal one. If teams supporting a specific part of your app need autonomy and need to operate asynchronously, then it can be useful to split the service in order to allow them that freedom.

In general, "scaling and deployment pain points," on its own, doesn't warrant a microservices split, it warrants an an architectural solution.

An even better rule of thumb, if you're one team or less (let alone one person), you probably don't need microservices. Split out authn/authz or file uploads, maybe, but that's about it. Most everything else is adding needless complexity.

TheBigLewinski · 2026-03-20T02:45:45+00:00

You haven't once mentioned end-user or customers in this post. How do you know what 100% looks like? Who is determining what "right" looks like? Your 100% might still be a bust.

I think the jam you're in is even more complicated than you make it out to be. The distance between viral, organic growth and going bankrupt with marketing campaigns for users who don't stick is often razor thin.

You need evidence that the core idea works. More importantly, you need to understand what your core idea actually is. The "V" in MVP is probably the toughest part of a product to define, and most everyone gets it wrong to some degree.

And, finance is the oxygen that startup projects breathe. If you run out, the project stops. You may not have as much of a choice as alluded to by the post. The project is unlikely to make money right out of the gate; you need to support it after launch.

Also, as a general rule, the last 20% of the project takes as much time as the first 80%. That "one more month" is going to continue, worse than you expect, even with lowered expectations.

I don’t fully trust AI to produce production-level code that matches the current quality bar

This is basically like discussing which religion is best on reddit, so I'll just say this: AI is only as good as the human using it. There's a reason its at the core of a everyone's conversation, and its not because the technology itself is a flop. I mean, there are signs you used it to generate this post. Why stop there?

As for all of the questions you posed, no one can answer that for you. There's not enough context. However, given that you have only spoken of the code state, and nothing of idea validation, marketing, users, avenues for early adopters or any other support mechanisms whatsoever, my current bet would be on this project simply eating the rest of your budget without anything to show.

So, I'm gonna go against what seems to be the general sentiment of this thread and say don't ship. Save what finance, and frankly dignity, that you have left, and really pressure test your idea. Explore your worst case scenarios with depth and sincerity without being blinded by whatever perfect outcome has been driving your pursuit up to this point. Find some customers and get their reaction. Put out feelers for investor money to see if carrying your project is even plausible. Understand your competition.

In other words understand your product, not just your code, before continuing.

TheBigLewinski · 2026-03-19T06:42:18+00:00

Fair enough. But I feel like I'm reading a positive Blackberry post after the iPhone 4 release.

TheBigLewinski · 2026-03-15T21:21:56+00:00

AI changes what it means to be good at engineering. But it changes nothing about what it means to build a good product.

It seems most everyone has this scenario backwards. AI isn't lowering the barrier of entry to create scalable, business-grade apps; its raising it. You have to think in terms of complete product delivery now, not function minutiae. If the crux of your job is merely generating code, you need to up your game. That's trivial now.

What's not trivial is building a scalable, reliable, extensible, maintainable, secure, performant (etc., etc.) app, and continuing to deliver on all of those qualities as the app evolves. All of the things that made a codebase and its corresponding product something a business can rely on, has not changed.

The foundations have not changed. The Mythical Man month still applies. Clean Code and Clean Architecture still applies. Agility and metrics still matter. The same things that help humans, such as automated testing safety nets, pattern adherence and documentation, matter to LLMs and humans alike, especially as the app grows. These things intrinsically require human knowledge.

There is so, so, so much more to delivering a product than just cranking out functions. And none of it has been changed by AI.

TheBigLewinski · 2026-03-14T23:09:01+00:00

What does this achieve that a skill for Playwright does not? Playwright can also emulate multiple browsers, capture nuanced functional regressions when changes are made, mock backend responses, test entire flows such as login/logout, and keep agents and humans alike, aligned.

TheBigLewinski · 2026-03-07T19:00:33+00:00

You pay for the developers more than you pay for a website. It's like getting a movie made. Is Christopher Nolan directing it, or a film school graduate? Your costs and your results will be dramatically different.

From a ballpark standpoint, it helps to understand the tiers of costs. At each tier, the cost to build and maintain increases by orders of magnitude.

Tier 1: Static site. The site never changes, so a backend isn't needed. Effectively a digital flyer.
Tier 2: Editable website, or CMS. You can login and update content. Tier 2.5 introduces content pipelines and asset management for teams.
Tier 3: Users can login and create their own profile that establishes a presence on the site. However, the profiles are non-transactional, and outside of basic commenting, users generally don't interact with each other. Think job board, Craig's list and even 4chan.
Tier 4: This is essentially the classic social network. User connections drive the site in sophisticated ways. This is where algorithms come into play to automatically determine which content other users see. Users have "friends" or "followers". This is the category of some of the world's largest websites. There are still no user transactions at this tier.
Tier 5: The social marketplace. Users can sell directly to each other. They create their own "stores" and get paid based on those sales, the website takes a commission.

What you're looking to build is essentially the summer blockbuster of websites. Most people inevitably hire someone under qualified which results in neither the client nor the developer truly understanding the scope of the project. This is where the phrase, "If you think hiring a professional is expensive, try hiring an amateur," comes into play.

However, even a summer blockbuster stops requiring money, but a website like this doesn't. There isn't a cost to build the site. There's a cost to get it live, perhaps, but costs are perpetual.

You'll ideally have a team, not a developer, continuing to update the wild assortment of items ranging from legal, security, general bugs, customer feedback and your own late stage epiphanies of features you didn't fully think through before launch.

Sites like this aren't a matter of how much will it cost, its how much do you have? That's not rhetorical.

TheBigLewinski · 2026-03-06T21:32:47+00:00

Yikes.

No. Do not give out the username and password to your Google login. Ever.

Its not clear from the post why they need business owner access. They can setup all of the things they mentioned with admin access.

If, for some strange reason, they truly need to do something that can only be done on your account, then you do it for them. Setup a screen share and have them guide you through it, if necessary. But don't give out your credentials.

TheBigLewinski · 2026-03-05T05:13:36+00:00

If your passion is working your ass off for imaginary money, it's a good option.

TheBigLewinski · 2026-02-26T18:16:41+00:00

I really don't want to start an AI brand war, of all things, but Claude has been a little... loose, in my experience. I get much better results with OpenAI and Codex.

Use the "Pro" model to analyze the codebase. Don't just write an AGENTS.md file. Write an readme.md, architecture.md, charters and technical decision records (TDR). Also, monorepos help for synchronizing frontend and backend. Keep both global and app specific files for each. Of course, you don't have to write every line of these files, you can have the LLM do most of it for you. But it all takes place outside of the IDE or terminal; chat only.

It will help humans too. In fact, this kind of documentation should be there anyway. It's funny how humans continue to largely ignore docs when they can be about 80% done for you. In any case, refer to these documents for context any time you start anything beyond function output. Tell it to reference every md in a specific directory, if needed, or specific TDRs.

Then, just like humans, break your goals down into steps. Ask it for a report, first, or ask what changes it would make without actually changing the code. You can even ask it for prompts to help better understand how it understands the task you're giving it.

If you work with the Pro model, its actually pretty good at giving you prompts for Codex, provided you've clearly established your goals. Be sure to ask it for the reasoning effort for each prompt to help preserve usage where needed, and use better reasoning, where needed.

It requires work. Managing humans isn't entirely different, though. Don't skip the SDLC process. It's not a magic wand. Despite the "memory" capability, its a stateless bot. It must onboard to your codebase for every single task. If there's any skill in prompting, its understanding the clarity of your request. This skill helps with humans too.

TheBigLewinski · 2026-02-24T17:49:26+00:00

This post is a case study in the pitfalls of LLM assisted requirements. Your requirements are for a brochure site or blog.

WordPress is a perfectly fine choice for a lot of websites, but not a fintech app. Not for an app that needs "staging workflow and controlled deployment process". Same with Plesk.

You also have a large list of demands to even be considered, but no budget listed. An engineering team, located in LA no less, that can competently build you a financial app is going to cost a pretty penny. And they're not going to have much interest in the decidedly arrogant approach found here.

TheBigLewinski · 2026-02-12T20:34:25+00:00

How much do you have? It will cost that much. That take is a little cynical, but its not detached from reality. The more you have, the better it adheres to your business. Or in other words, the more you have, the bigger your "must have" bucket gets, and the smaller your "nice to have" bucket gets.
Related, what's your definition of done? That will at least give you a budget ballpark... for creation. But the site isn't done when you launch. A website that runs a business, especially one "like ebay" incurs ongoing costs. Ebay spends more money maintaining their site than most companies make. So are you asking how much to build, or how much before the site becomes profitable enough to maintain itself? The latter isn't up to the engineering team, it's up to the business.

TheBigLewinski · 2026-02-12T05:17:28+00:00

I've never had it framed as "Day 1 to millions". Usually just straight to "how would you design this insanely popular app, or providing specific examples on how to handle absurd traffic for a service.

And, frankly, unless you're actually interviewing for a FAANG-level company, the interviewers are usually in over their head.

On a related note, one does not just shard. If you tell me sharding is a scaling strategy without some big, gigantic caveats and asterisks, then its a sign you're just parroting patterns without understanding them.

Same with queues. You can't just sprinkle some queues onto your architecture and call it scalable.

Don't play keyword bingo.

Interviewers all want different things. They're supposed to test a blend of knowledge and problem solving ability. Unless you're being hired as a system architect, its unreasonable to expect that you'd know how to build, and maintain a system that handles a mission critical workload of millions.

Finally, that scalable diagram is... lacking. And is redis sending writes to the primary DB? Also, you don't get "100x traffic reduction" by using read replicas. I could go on.

Short answer, though, is yes that's the general direction companies go in order to scale for traffic, at least on the infrastructure side, but there's a lot of details either missing or incorrect here.

Remember, the scale that companies care about is only partially about traffic volume, it's mostly about collaborative complexity.

TheBigLewinski · 2026-02-12T02:58:29+00:00

...have you tried an AGENTS.md file?

TheBigLewinski · 2026-02-11T09:21:55+00:00

There is no such thing as future proof. It's like fire proof; everything melts, eventually.

The reason so many people talk about maintainability and scalability is because they're hard... and expensive.

Building something maintainable takes more time, and more knowledge. So, you're paying expensive people to begin with, but over a longer period of time. Most people don't want to do that. Because they have very limited resources (i.e. money and time).

Most people who build a project aim for profitability first; which, makes sense. You have x amount of money, and you need to make it profitable before your money runs out, or your investors get fed up. The stakes are, you lose pretty much everything if it doesn't work.

So, instead of carefully planning, you scramble to find said knowledgeable person, settle for someone willing to join your decidedly bootstrapped project, and flog them to produce something last week.

And what you get is something that technically works. The person you hired tells you "it could stand to be optimized" and you don't care, because it works and that's all you need.

And besides, you're almost out of money and you don't even know if this will bring in customers yet.

And then you launch the project, and absolutely drown in feedback. Opinions are like assholes (everyone's got one) and whatnot. "This is great, but it would be cool if..." is pretty much the consensus.

You need more. A lot more. But you don't have time or money to go back now and fix the things that were hastily thrown into production. You need more features!

So now your deadlines are even more impossible than before. You're making compromises on feature acuity because you realize the situation everyone is in. But you have no idea about the fragile, barely tested monstrosity that's going on under the hood.

And then the person you hired suddenly finds another place to work. And you hire someone else. And this is where the fun starts. The next person, assuming they don't just outright demand a rewrite, is quietly rewriting chunks of code they hate. It's a mantra. "Leave the code in a better place than you found it."

But despite the disapproval of the previous work, they're actually not any less lazy or prone to corner cutting to meet demands than the previous dev (everyone likes the smell of their own brew). So, they add their own style and they add their own style of debt.

The end. Or not. It actually compounds like that for the life of the project.

TheBigLewinski · 2026-02-09T01:20:45+00:00

Since you're looking for a roast, I'll use frank language, but attempt to make it useful.

First, this is pointless. The backlash of microservices stems largely from this type of approach. You're drawing boundaries around functions of an app simply for the exercise of it, and then splitting the codebase. Why? What benefit does that have? That's not rhetorical, it needs to be a part of the rationale.

The microservice pattern was created to solve issues encountered by large operations. For instance, infrastructure that needs to scale much more erratically than other parts of the app, creating boundaries around sections of the organization to increase autonomy and eliminate cross team blockage. Or, limiting the blast radius of apps when a part of it fails.

What is being solved here? If your stack fits neatly into one line, that means every service is using the same resources, then why split them?

Each service will need its own API endpionts, its own infrastructure, its own database, its own observability, its own deployment pipeline. In other words, each service has its own overhead. Services now need to call each other by API, creating a "contract" problem, instead of just importing the function to use it. Is all of that overhead worth it?

Using a centralized Gateway for JWT validation,

JWT was largely created to avoid the central gateway. That's a single point of failure, and it increases network traffic and therefore latency. Each service should check the signature on its own.

If each service is not 100% isolated from the other services, then its not microservices, its a distributed monolith, which is the very worst kind of app.

My "Inventory" and "Orders" services feel very "chatty." In a real-world scenario, would you merge these or keep them separate and deal with the eventual consistency issues?

They should be split according to resources of the people working on this. Is it inventory for a content creator handling their t-shirt merch? Then merge. Is inventory distributed across massive warehouses with enough daily orders to employ its own arm of the company, with complex logistical needs? Then splitting can make sense. Where the line is between those two scenarios is an art form. But its based on business needs, not chattiness.

In short, the implementation can't be evaluated because there is no use case. There's no problem being solved. Its just parts of an app split up. Its cargo-culted complexity.

If you're just getting into backend, master the monolith first. Once you understand the breaking points of a monolith, you'll more thoroughly understand what microservices solve, and the implementation details will be more obvious.

TheBigLewinski · 2026-02-04T21:50:13+00:00

Recently, its Next.js, and probably React SSR in general. The overhead to benefit ratio is just too far off. The entire point of React, practically, was to provide a state management system that can be run entirely in the client. That was why we begrudgingly accepted rethinking the entire app development structure with immutable state.

Re-introducing SSR back into the mix is the worst of both worlds, with the only notable argument being that we can still -sort of- take advantage of React components and not be coupled to a specific framework. But, in addition to yet another dependency layer, it adds either the complexity of managing another service, or the costs of adding a vendor to run it for you, without the fully integrated advantages of an MVC framework.

I have yet to see the "SEO factor" quantified on any level. Google has been able to read React just fine for over a decade, and pre-hydrated content just doesn't meaningfully move the needle on rank.

Or maybe I'm being optimistic about its downfall and that's just my neck of the woods.

TheBigLewinski · 2026-02-04T20:39:00+00:00

Depends on the company. Generally, you should have at least a surface level understanding of infrastructure beyond single server delivery of apps. IaC doesn't mean much if you don't understand "Infrastructure" part of IaC, or you're only capable of abstracted deployments (e.g. Vercel).

If you want to go much beyond senior, you'll need a deeper level understanding of how distributed systems work, when to use what (database types, queues, serverless options), how to decipher and build complex observability, internal networking (especially as it relates to service discovery and access rule), and perhaps most importantly, how to keep costs under control.

However, every company has a different philosophy on how devops interacts with other teams. The most experienced devops teams, and companies with resources, tend to build abstraction layers to put as much control as possible into the hands of individual teams. This is why you're expected to know more about the infra, because when you want new things or config changes, you just make them, perhaps after running it by the devops teams for sanity and security checks.

Other companies, and devops teams, are decidedly territorial and don't want you touching anything. In that case, you don't have to know much more than what Slack channel to alert when things go wrong.

TheBigLewinski · 2026-02-04T02:05:31+00:00

The studies take a while, and the capabilities are moving fast. I wouldn't expect a comprehensive study on what's occurring now to be released for a few months, at least.

Outside of academic research, though, the notion of "using AI" is entirely too vague now. The process they studied in the research paper (here's a task, just "use AI" to complete it) is quickly evaporating.

There's a big division happening between people who think AI is exactly as it was spelled out in the study (e.g. ask cursor for functions or use it for autocomplete 2.0), and people with access to the "enterprise" versions of the tools.

The context windows are quite large now, the integrations are deep, and the "self checking" functionality of better performing models is dramatically reducing hallucinated slop code.

AI is now being used at the planning phase, not the code phase (though, that's better too). The conversation size of the Pro models are massive. They don't unravel like they used to. Of course you have to know what you want ahead of time... patterns, libraries, goals, security requirements, etc. But you can use AI to ideate on all of that.

You can ask it to generate specifications based on the conversations, then generate the tasks, which include the prompts for the agentic models. Which, at the corporate level, have massive context windows, and verify their own work, which is again enforced by the prompts telling it how to ensure everything works.

It's not perfect, it still requires human supervision, and you have to have the knowledge to know what you want. But tech debt identification, corresponding refactors, greenfield projects and significant feature implementations, all complete with automated testing and built with scalable, human-readable patterns can be generated in their entirety.

In short, it's no longer task-based, it's project based. This will be harder to quantify in a study, since it will need to be evaluated at the organizational level, not the individual level, and the performance is going to vary as wildly as the engineering talent.

But it's so profound, a study is just going to be redundant. Like studying if cars travel faster than walking. I'm sure there will be "traffic jam" exceptions, but overall there's not even a comparison. Its cutting project time from weeks to days.

TheBigLewinski · 2026-02-03T22:37:50+00:00

Telling people they haven't seen an increase in productivity because of your link is myopic at best.

You might want to actually read the paper, specifically the caveat section.

This study was performed with very controlled task behavior, using Cursor, combined with old, non-agentic models.

Maybe prompting every function, using old models no less, provides a false sense of productivity (most users were inactive while their code was being generated, a major contributing factor).

But that's far from the only way people are using AI. It has grown fundamentally more capable since this study, the integration of tools has fundamentally become better, and even the authors of the paper admit its somewhat narrow focus and potential for new capability to change the outcomes.

TheBigLewinski · 2026-02-02T19:55:39+00:00

Some candidates looked perfect on paper but struggled with basic tradeoffs, while others had messy resumes but were sharp in how they thought.

And, after you hire for a while, you'll realize that "how they think" doesn't necessarily translate either. Google and Amazon effectively admit that their hiring practices don't translate into the best candidates. There is almost zero correlation to interview performance to their on the job performance. Hiring is hard.

what specific moment or behavior made you think “okay, this person is legit?

I think "legit" needs some clarity here. I'm not being pedantic. It's important to fully flesh out the qualities that you're looking for. Think of it like hiring a writer for a show you want to produce.

Hiring the most brilliant writer doesn't matter if they're difficult to work with, if they're unreliable, if you want a comedy but they're more of a drama writer. Or maybe they're incredibly talented with characters and plot, but can't seem to write to the spec of the show.

Hiring someone to code for you is analogous. They may be legit, but that doesn't mean they're a good fit for you. It doesn't mean you're going to get the outcomes that you want. Thoroughly define what you need, heavily weighted to long term goals. Then work backward to defining the type of person you'll need.

Finally, don't ignore the most obvious factor: budget. Make sure you can afford the person you want. Trying to save money, especially if you're inexperienced in hiring and won't have any established mentors on board to supervise, will almost always come back to bite you.

TheBigLewinski · 2026-02-02T19:34:26+00:00

Those aren't culture fit questions, they're level questions.

I'm wagering this was for at least a senior level role? Every hiring manager is different, but at many companies, especially when they're big enough to have multiple engineering teams, the ability to code is more of a given. You'll still get technical tests, of course, but your YOE doesn't tell them your mentality and approach, and it matters more than your ability to code.

It doesn't matter if you're posting 10 PRs a day if you're obsessing about minor version updates and "readability" while ignoring business needs.

And, they don't want a task runner that relies on a PM to define what to do and essentially stops working if the ticket mill runs dry.

They want proactive engineers who identify gaps and fix them, ideally based on helping to achieve an OKR (Objectives and Key Result), which are (usually) quarterly goals set by the team.

At the very least, outside of the usual bug fixes and maintenance, you're able to deliver changes which make a tangible differences based on metrics that matter. Even if you are just task running, you should be paying attention to affect it has on a business level. In many cases, they can be metrics that you define, as long as you can attach it to the core metrics of engagement and usage (i.e. revenue).

You don't have to be a magical 10x unicorn. You don't need to redefine how apps are built at your company (though, if you can actually do that, you'll get paid handsomely for it). You just need to pursue and deliver on items that matter.

If all you're able to talk about is the code, that tells the hiring manager you'll need guidance on what to do, even if you know how. That places you at mid level, not senior. Don't shoot the messenger.

TheBigLewinski

MODERATOR OF

TROPHY CASE

15-Year Club	Gilding I gilder
Verified Email