cairo140

The biggest feature I miss from Google is the constellation of citc and the distributed build system that revolves around it. Most is described or implied by "Why Google stores billions of lines of code in a single repository" (2016) [1].

The key idea is that any human-written change only ever touches ~1-100 files, and there's never any need to store or maintain the entire source tree in your local persistence store. By only ever working on deltas, you can have highly efficient distributed and cached builds. This architecture imposes significant constraints: you must express your build graph in a modular way [2], you collocate your distributed FUSE backend and build system for speed, and all development is over the network. But it comes with many benefits at scale: near-perfect caching, instant "branch switching", fast builds even with deep and wide dep graphs, and excellent affected target determination so flakes/outages in one part of the codebase don't affect the rest of it.

[1] https://dl.acm.org/doi/pdf/10.1145/2854146 [2] - https://bazel.build/

I've worked in JS for around 12 years now and welcome this change of keeping JS as a scripting language but incrementally retiring it for performance-intensive general-purpose applications.

To my eye, JavaScript has three applications:

* A GUI-building language: A language and ecosystem we use to build UIs, where code runs on the end user's machine, served over the Web or as desktop applications using a compatible API (e.g. Electron).

* A scripting language: An approachable high-level C-like language.

* A general purpose programming language: A server-side or developer machine-side programming language for computational tasks like linking dependencies, transpiling code, type checking, orchestrating tasks.

At the first it's unbeatable, and the ergonomics and ecosystem are phenomenal. This is why it "won" as a language to write even desktop apps like VSCode and Discord.

At the second, performance doesn't matter anyway, so making JS capable of this just makes it approachable for folks who learned the language for the GUI-building purpose.

It's at the third application that the fundamental limitations of JavaScript---the programming language---really show. These are things like the lack of true multithreading (technically possible with significant limitations around shared memory and messaging and high overhead with Web Workers), lack of low-level primitives to fine-tune performance, and the ease with which authors can accidentally write extremely slow code. So much of this (TypeScript compilation, NPM package resolution/linking, Webpack bundling) in the modern Web ecosystem is regrettably still done in mostly JS.

I hope the JS community rallies around one general-purpose language to offload these tasks to as well as a uniform shim layer like Ruby's C extensions so we don't end up with a chaotic mishmash of different technologies. If nothing else, it would be nice to have a good excuse to write not-JS every once in a while!

I worked on the vendor (not auditor) side of accessibility audits, which have similar structural issues as security reports. The amount of latitude individual vendors have in shaping the scope of testing, setting cadence/private review phases, and picking auditors in the first place is stunning, and even though there are public standards (VPAT/WCAG/Section 508/EN 301 549), these degrees of freedom made reports completely incomparable across even vendors with the same commodity software products. Downstream from us, 90% of customers didn't closely scrutinize the contents or quality of the report and just needed it to exist.

The problem is the ultimate consumer[1] of these reports, legal and procurement agents at buying companies, themselves don't care about the actual quality of the report except insofar as it satisfies their own transitive legal/sales requirements, and it's turtles all the way down. This harms users/customers at the end of the day because they don't have time to scrutinize the details of each individual report or have any real power. If we care about the end goal (secure, accessible software), we need for the auditing firms to collaborate we the government, judiciary, and ancillary vendors to tighten standards to include random[2], uniform checks (same auditor, same methodology, multiple vendors at once).

In the US, OSHA designates NRTLs like UL to perform safety testing, which are required everywhere from workplace standards to insurance requirements. In comparison, at least for accessibility, merely having your vendor have any assessment report is likely enough CYA to withstand a legal challenge. I acknowledge the power of recent website lawsuits to use the broader ADA to raise the bar here, but ADA's "enforcement through private lawsuits" enforcement mechanism is spotty and I think won't result in enough structural improvement.

[1] - These reports also serve as PR/marketing, which is probably moreso the case with Mozilla VPN, but in most enterprise software where these assessments are taking place, the marketing side is very much a secondary goal compared to the individual legal/sales relationship that hinges on the report.

[2] - I think removing the opportunity for vendors to fine-tune scope or prepare or respond to concerns (at least until the next review cycle) is a big step in the right direction, but unfortunately, the legal climate is very much all-or-nothing and not good at nuance. Section 508 (I'm not personally familiar with PCI/SOX/etc. but suspect those are similar) is formally speaking "all or nothing" check all the boxes things, and in that climate, good random audits will basically be always-failing, and if you make too hard a standard that even reasonable vendors can't meet with an earnest effort, you'll end up constricting the market into a meta-game of who can hack the auditing process. See federal government procurement.

Even if content license holders don't require Netflix to go above and beyond, building sophisticated DRM is a moat against other streaming services. If Netflix can build a sophisticated VPN-detection service, copyright holders will be much less willing to license their content to upstarts who can't match its capabilities.

In the same vein, it can be rational behavior for a market leader who deals in private information (most online advertising companies) to advocate for consumer privacy protections. It "hurts" them, but if the resulting regulations are so onerous that only incumbent(s) can comply, it can restrict the competitive landscape and paradoxically be advantageous to the existing leaders.

There's no secret sauce. The typical aphorisms of software development are generally correct and apply here:

* internalize the cost of core changes and don't push them downstream unless you have a really good reason * staff a core team to take care of high ROI horizontal efforts that have high fixed cost to do efficiently, e.g. TypeScript migration of a massive codebase * be careful of what you take on * complexity and code are costs and not end goals

Reading them is one thing but seeing the principles play out in detail amidst the mess of reality was illuminating for me. The author's blog[1] touches on these themes a bit more and I think are a good glimpse into their stewardship of the TS/JS codebase.

[1] http://neugierig.org/software/blog/

I worked on the infra team for a TypeScript-based product downstream of the author. His and his team's approach and writings influenced at a lot of my thinking about core development, and I'll always be grateful for having had the opportunity to learn from them by osmosis.

The success or failure with which any companies hires and retains folks like these is a mystery to me. As the evidence shows, Google (and I suspect almost any >100-person company) is far too much an amorphous glob/slime mold to even have a single coherent approach to this problem. But what are the successful strategies here? How important is it even to retain this kind of talent? How do we know how a company is even doing in this regard?

In my meager-in-comparison 6.5 years at Google, while I certainly saw many amazing SWEs come and many go, I'm far from knowing what the real trajectory was. But I can imagine that for many folks, the perceived trajectory would be a major motivating or demotivating factor to stay or to leave themselves.

Winners: The investors who bought Airbnb shares at $68 whose shares are now worth $140.

Losers: Existing Airbnb shareholders who have shares in a company that could have raised $7B in cash but instead raised $3.5B. In theory, the mispricing "cost" Airbnb around 4% of its market cap, so existing common shares are worth 4% less than they should be.

But there's a caveat[1].

Companies like Airbnb (no stable profit) are almost entirely valued on sentiment and expectation. Assuming perfect information and rational actors, in an alternate universe, a direct listing would have resulted in around a $146[2] share price, on top of which the company can raise a secondary listing for $3.5B without affecting the share price. They'd have the same assets and liabilities as they have today, except pocketing the difference (by limiting dilution) instead of handing it to investors.

However, there's no certainty that the valuation would be $146 today had they gone this route. Humans, especially hype-powered retail investors who like to jump on flashy IPOs, are very susceptible to things like IPO bumps when making their buy or sell decisions. An entire field[3] of investing with significant buying power essentially relies on predicting sentiment.

If I'm a common shareholder, sure I'm sad that my shares are worth maybe 4% less than they "should" and that the financial world pocketed the difference, but I'm probably pretty happy my shares are worth what they are and aren't too interested in, for example, rehashing the deal or picking a offering strategy that could have swayed investor sentiment in a way that made my shares worth much more than 4% less.

[1] - The impact of "more perfectly" priced IPOs on market sentiment and thus public valuation is the most significant factor, but a secondary one is the practical aspect that the IPO process consists of a lot of risk, both on the part of the underwriting investment bank who gives the company the money raised in the IPO and the small number of powerful investors get access to (often) preferential pricing from the investment bank in exchange for an advanced commitment to buy the shares and hold for some agreed upon time. This illiquid market is dominated by relatively few actors. An IPOing company who doesn't "play ball" may find itself unable to find someone willing to underwrite their funding round or buy into it at all. [2] - This theoretical loss per share is computable two ways. The easy way is that they "left $3.5B on the table" which divided into Airbnb's current market cap of $84B is ~4%. The other way is the counterfactual way. Airbnb currently has 600M shares outstanding, having issued 50M shares in the IPO in exchange for $3.5B. So if not for the issuance, Airbnb is worth $80.5B with 550M shares outstanding, or $146 per share. [3] - https://en.wikipedia.org/wiki/Technical_analysis

Disclosure: I work at Google. You can consider looking at Glassdoor[1], bearing in mind this includes data from several years ago before the wage-fixing bust and excluding natural growth. Looking at offers that I have friends have gotten at both bigtech and not, a good rule of thumb for new offers is to take the upper end of what Glassdoor says and add ~10%. If you want you can also look at H-1B data[2] which usually quotes only guaranteed base salary (and excludes bonus and RSUs). As far as I know there is no public data on this.

[1] https://www.glassdoor.com/Salary/Google-Software-Engineer-II... [2] - http://h1bdata.info/index.php?em=google&job=software+enginee...

H-1B applications often exclude expected value of bonus and RSUs (mine does) and can understate comp at bigtech by ~60k (entry level) to ~150k (mid level) to ~300k+ (senior+).

This is really terrible. Since nobody's name is actually on it, I assume their marketing team wrote it.

The founder put his name on it https://mobile.twitter.com/stewart/status/793811616760496128

Agreed this is a move by Slack that is very disappointing to me. I thought better of them.

Thank you for the reply again :). I saw your comment previously and I think you make a great point. As much as I criticize the chart for being unfairly pessimistic about equity returns, there is far too much literature suggesting you can get 7-8% real returns by parking your money in X, especially in the <20 year time frame for stocks. In comparison this chart is a good factual dose.

My concern is, that while this comparison is useful for people further along in their research trying to understand the volatility of the stock market, this chart has a number of misleading (IMO) traits that can dangerously/unfairly steer people who are newer to managing their own money away from index funds altogether.

I would hope that people see this chart, my comment, yours, and FabHK's excellent comparison to bond yields. But if you have limited attention and are getting started, I would hate for the original link to be the only thing you see.

Speaking for experience with family and friends, too many good people scared by charts like this bought gold in 2011 or trusted mutual fund managers to buy into funds with 4% front-end loads and 2% AUM fees.

To reiterate my comment another time this was posted in a comment thread:

I feel this graphic, while informative and delightful, is insidious in its choice of scale and its lack of comparisons.

On scale, it colors +3% to +7% real returns as "neutral". This makes it seem like the stock market is sometimes good sometimes bad but overall it may as well be just okay. I feel that 0% nominal returns, or even 0% real returns, is more honest as a neutral anchor, and even with the latter it would need some comparisons against other asset classes to paint an accurate picture.

On comparisons, it does a disservice to its readers by not adding a tab showing bond yields and a tab showing cash/treasury yields (which would be dark red across the board except light red around 1930).

These slights in the graphic unfairly make the stock market look unfavorable and makes the suboptimal strategy of keeping your money out of the market seem much more favorable than it is.

Adding a specific example, the "worst 20 years" is 1961 to 1981 with a BIG RED -2.0% a year, as if someone loses money and in retrospect would have been better stowing cash away under one's mattress. According to the BLS[1], US inflation was 5.7% over that period, so the mattress strategy yields at best -5.7% in real returns, not at all better than investing in the S&P.

[1] http://data.bls.gov/cgi-bin/cpicalc.pl?cost1=1&year1=1961&ye...: $1 in 1961 was $3.04 in 1981, 3.04^(1/20) = 1.057

I feel this graphic, while informative and delightful, is insidious in its choice of scale and its lack of comparisons.

On scale, it makes it seem like +3% to +7% real returns is "neutral". This makes it seem like the stock market is sometimes good sometimes bad but overall it may as well be just okay.

On comparisons, it does a huge disservice by not adding a tab showing bond yields and a tab showing cash/treasury yields (which would be dark red across the board except light red around 1930).

I feel these slights make the graphic present stock investing in an unfairly unfavorable light and makes the suboptimal strategy of keeping your money out of the market seem much more favorable than it is.

I work at Google on the main website as an SWE (non-lead). I have about 1.5 to 3 hours of scheduled meetings a week.

From reading your post, I feel the biggest issue you are facing is that there is nothing differentiating you from the common "wacko" inventor who thinks they have the next great thing. We'd get nowhere if we followed each perpetual motion machine, infinitely scalable database, and alternative theory of quantum physics. So the system is good at identifying those patterns and churning through them.

Your idea is good. Let's just say that.

What you have to do next is to differentiate yourself from the crazies. That means some of the following:

* Tech demo you can show someone in 30 seconds * A "shiny" frontend that the layperson can understand * A concrete value proposition, other than that it can be acquired

You don't want to be stuck in the following pattern, which makes you no different from the rest:

* Secrecy * Promises * Vagueness

While Google does make a lot of it's earnings from Ads, Google Cloud is supposed to surpass it's Ads business in the next 4 years.

Where do you hear this goal? Google Q2 Ads revenue was $21.5B. AWS Q2 revenue was $2.6B. Google is currently small compared to AWS.

When I was recruiting programmers I always read them, though maybe 1 out of every 10 applicants included one.

Most companies (including the one I was hiring for) cannot compete on price[1], so they only way they can hire a particularly desirable candidate is if they find a particular fit between candidate and company/role. A strong cover letter is a strong leading indicator of a potential fit, so it is very desirable.

[1] - I think the money is there and the economics probably work out to "just pay programmers more" but there are social factors that make this strategy unviable. In particular, most firms are very averse to paying programmers more than the non-technical staff to whom they report so the wage ceiling for programmers at a firm end up being capped to the market-clearing price for those business professionals.

My numbers (n=1, though this is widely true among the transplants I know) worked out in spite of the cost of living. Here is my math, though obviously the number will vary based on individual.

My rent went up by around $2000. At a marginal tax rate (Medicare + Federal + State) of ~40% this meant post tax income would have to go up by $40000 to "break even". Tack on an extra $5000 per year to cover the high state tax rate (this difference varies based on origin state). In comparison, my gross income went up by over $50k within a year and $150k within 3 years.

There are other aspects that add to "why I personally live here". (1) Job security is much better, not in the sense that companies are more loyal or successful here, but in that there is so much going on that you get job security from the strength of the market, and I feel like if I ever lost my job or wanted to change I can. (2) Because of the strength of the market, employers treat employees much better here than in smaller markets. (3) Everybody else is here. The proliferation of people who I can learn from here is amazing to take in.

There are definitely things that will tip the scale in favor of going away. Kids and buying a home are a big one, since those costs are even more outsized here than rent alone. Also, the valley is disproportionately friendly to the cutting-edge, type-A career, and the numbers (in terms of the jobs you can get) are not as friendly if you want to settle down. It's for these reasons it's likely I'll leave, but in the meantime, the cost of living is offset by a long shot, to say nothing about the intangible benefits.

I've found nytimes.com content to be great and exhibiting great technical, artistic, and journalistic merit[1]. As a result, I visit it daily and and it's the first time in my life I have a paid recurring news subscription.

However, nytimes.com has a very regrettable pricing structure, as you say. They seem to aim to be Comcast-like. The pricing is:

* Heavily promotional (special price 50%+ off sticker price)

* Difficult to cancel (you are asked to call them, although they will ultimately run it through email)

* Opaque in billing (no way to actually look at the terms of your current subscription/promotion; full payment history hidden away to obscure how much you're paying them)

They do this no doubt because it works in the short term and bumps up numbers. But as a consumer I can't help but feel they are losing goodwill and face in this new age and hope they come around to more contemporary online billing practices.

[1] http://www.nytimes.com/interactive/2015/09/21/business/media... is the best example I can find. It's very nice to get stuff like this every week. Kudos to the web team.

I believe the way Google's hiring and compensation committee's work makes it so that short of bluffing your current compensation, not disclosing your comp is equivalent to saying you currently make $0.

In my case, I was already being paid well going into Google's offer process, but considerably below Google's band for the level I got approved for. I gave them my comp and they beat it by a large margin, to the point where they clearly weren't considering my existing comp. So I think if you just refused to answer, they'd give you the minimum in the band and wait for a counter or acceptance.

Two further points that I think are relevant for a minority of candidates:

For folks who are L3/L4 or L4/L5 marginal who may get bumped up a level based on existing comp, if anything you'd rather be underleveled to start. There's so much to learn at Google and so many of the folks around me are so damned talented that I'd feel like even more of an impostor if my comp history brought me up to a level I was not at. Some anecdotes from Quora are at [1].

Secondly, there is some lore about high compensation plans (HCPs) at Google. If you believe you are paid well towards the higher end or above what Google pays for your band, you can Google around for this to get some stories of what it's about. This didn't apply to me and I don't know of anyone in this situation so I can't speak to it.

[1] https://www.quora.com/How-do-I-negotiate-a-higher-job-level-...

We gave candidates an option of a take-home screen (build a web app that consumes our single-endpoint JSON/XML API and renders content) or a live coding exercise (implement a least-recently-used key value cache to store 100 entries). Folks who could basically code did a 3/4 day onsite that included a code review of their interview project or an applied exercise if they did the live coding. Offer out within 24 hours after the onsite. Any recommendations to improve that process would be much appreciated.

Thanks for the feedback about the 4-6 engineer's worth of talents. It's good to know, and we realized a similar thing and pared down the JD to be less oppressive-sounding.

Sleep and balance was important to the team (I personally averaged around 35-45 hours a week, working one weekend and being called in maybe a half dozen times over a year and a half; the system mostly runs itself), but we didn't find a good way to surface it in the description. Any suggestions on this is appreciated too. I struggled in that when we removed or played down aspects of the job, or emphasized work-life balance, we just got more folks who were seriously green in some parts (front-end devs who can pull together jQuery but have never deployed their own code or had to write backwards-compatible apps).

Yeah "hit the ground running" was decidedly not the standard for bootcamp grads. This was our more senior unicorn hire. Like any shop though we did have simpler more isolated work that was still needing doing, so we pared those off for grads.

Roughly, someone who at the start can work independently on an existing business-critical[1], medium-sized[2] app to first fix bugs without adding major tech debt[3] and then take features from planning to deployment/maintenance, and then ultimately (6-12 months, since we were a very small shop), independently steer architecture and be solo on call.

[1] hundreds of thousands in sales a day [2] around 10-50k LOC, but a far cry from the greenfield toy apps that bootcamp devs spend 90% of their time with [3] position: relative and z-index: 100 fixes many UI bugs, but if a dev has that as a main piece of their toolkit, you take on UI code debt or drag down the team to steer solutions in the right direction.

I felt similarly incredulous when we first started searching. I'll add some details for color.

Our hiring needs didn't feel too crazy to me. We were a multi-million dollar a year e-commerce shop, I was the first in-house technical hire, and we wanted to expand the team for personnel redundancy.

Ideally, we wanted someone who would be capable of running a business-critical website. On the technical side, I was hoping for a full stack of skills (top to bottom web app security, server ops, managing technical vendor relationships and integrating third-party modules, zero downtime rollouts, performance and architecture, metrics/instrumentation, and fully-independent backend and HTML/CSS/JS skills to build a secure and pixel-perfect feature beginning to end). Plus, we wanted an early technical hire to be able to work the indirectly technical parts, including technical hiring, capacity planning, and expectations management.

None of this felt to me like we were asking for something crazy unreasonable, but you don't learn a good enough coverage of this to independently steer a ship of this scale until a few years on the job. You can learn bits and pieces on the fly with the documentation around, but it's both risky and slow. Given the hiring climate, it was a risk we ending up being comfortable taking, but it fell short of what would be ideal.

In response to some remarks about adjusting our expectations (remote work, higher salary), our particular situation was not doable for remote---there was zero 100% remote staff among 30+ FTEs and none of our workflow was set up for it---although I wish I had influenced the organization of work in more formative stages of the company to optimize more for remote given the personnel advantages. Regarding salary, it's very hard to increase salary past $150k+ because I found it very hard to publicize it in a way that meaningfully increased the quality of candidates we found entering our funnel. I wish there were a job site for "will pay very well above market for strong candidates".

Just sharing my experience here: I've been hiring in SF and found some boot camp grads, usually stronger but still far from mid-career, with expectations around 90-115k. Most of these folks got hired (some of them to us/away from us with offers all in that range).

These were folks who were months to years away from hitting the ground running, and the value of the offer was entirely on their future potential. I found great difficulty finding a mid-career developer for the 130-150k range that it started making an "investment hire" feel like a viable alternative.

Can you just have person A supply to personb.com the path to person A's sharing service (in this case persona.com) and craft share links to person A's sharing service pointing to the content from personb.com you want to share?

Let's say:

Share endpoint /share?content=URL

Content endpoint /content/ID

If personb.com knows that the client shares from persona.com/share, it can craft its share links as (excuse the escaping)

    <a href="https://persona.com/share?content=http://personb.com/content/5</a>

This seems to address your core use case as well as your stated kicker (you can't craft a request to get person A to reshare something they don't want to since persona.com/share can auth person A and confirm the share).

This is all essential how Facebook, G+, Twitter sharing all work, except you don't pass to your content site the share endpoint because it uses canonical endpoints built in.

TATCHA - San Francisco - Full time - Full stack web developer

We are looking for a Web Software Engineer to join our dynamic, fast-paced team in San Francisco.

We are interested in intermediate to principal-level candidates, both as individual contributors and as project and technical leads.

Our work focuses primarily on our eCommerce website http://www.tatcha.com/. You would be joining as a key member of the technical staff, owning major parts of our web infrastructure, and taking features all the way from inception to development to deployment and maintenance.

The greatest thing about being on the Tatcha technical team is that it's a perfect mix of small team and big impact.

We are big enough that we run an eCommerce shop with thousands of visitors and plenty of transactions a day, where any change hits a large number of customers. And we're big enough that we know what we do well; we're not pivoting for a business model or running down a funding runway.

At the same time, we are small enough that we don't deal with a lot of typical "big company" overhead (separate IT/operations, complicated technology purchasing/licensing, cumbersome architectural momentum). You pick the build tool/library/monitoring service/operating system that best allows us to get things done. And our technical vision 12 months to 5 years from now? Yours to define.

Here is a list of the primary objectives and a sample of our projects for our engineering team today:

    * New feature development: in-browser live interactive audio and video assistance, new content app development (e.g., skin consultation), streamlined gifting experience.
    * Site conversion funnel optimization: checkout page optimization, A/B testing infrastructure, landing page tests
    * Performance and infrastructure optimization: smart HTTP request caching, enhanced server caching, progressive CSS/JS/image loading.

    * Operational stack: LAMP-based stack, using Magento as our eCommerce/cart platform and ExpressionEngine as our content CMS.
    * Frontend build: Grunt.js, Bower, HAML, CloudFlare CDN, Javascript (Angular.js, jQuery), SCSS, in development: single code base (mobile/tablet-responsive).
    * Workflow: Trello, git, Bitbucket, CI on dev, weekly rollouts.

Your day-to-day could look like this:

    * Writing code
    * Participating in code reviews
    * Advising product managers on technical requirements and dev estimates
    * Working on manual technical operations (deployments, report investigations, systems maintenance)
    * Investing in our infrastructure (update our dev/deploy/sync systems, plan measures like automated testing, CI, and configuration management)

    * You’re able to own architectural decisions and know how to pick the right tool and approach for the job.
    * You work with a long-term horizon and want to come to a place where everyone sees their work the same way.
    * You love to ship features and bug-fixes that affect tens of thousands of customers every day.

    * 2+ years of professional experience building websites and web apps
    * Able to build high-quality HTML/CSS/Javascript applications independently
    * Experience with full LAMP stack or comparable (e.g., RoR) environment
    * Proficiency in maintaining a modern frontend webdev pipeline or willingness to learn+

    * 5+ years of professional experience building websites and web apps including full lifecycle (roadmapping, team selection, stakeholder management, deployment, maintenance)
    * Expert fluency in HTML/CSS/Javascript, including performance/bottleneck analysis, library maintenance, and long-term technical design
    * Strong grasp of web/network security and service architecture and maintenance
    * Strong web server and OOP proficiency

    * Experience in our particular stack and libraries
    * eCommerce experience/interest
    * Growth and conversion optimization
    * Interest in skincare or beauty
    * Customer service background

http://www.tatcha.com/careers/web-software-engineer or email careers@tatcha.com.

TATCHA • WEB SOFTWARE ENGINEER • SAN FRANCISCO, CA

Email careers@tatcha.com.

-----

ABOUT US

TATCHA is a young, innovative luxury beauty company based in San Francisco with a focus on E-Commerce excellence. We're growing our web team to build out the next generation of innovative features for our website and tech ecosystem to delight our customers all around the world.

-----

ABOUT OUR TECHNOLOGY

• Modern LAMP/PHP stack • ExpressionEngine and Magento • Grunt/Compass/SASS asset pipeline • jQuery/Angular.js frontend

-----

ABOUT THE POSITION

TATCHA is a small and growing company, so you would be joining as a key member of the team, owning features from inception to deployment to maintenance, and being responsible for major parts of our web infrastructure. On our web team, you would be deploying features to our customers on a daily basis. Here's an example of some of the challenges we're building for right now:

• Introducing live interactive audio and video skin consultations and checkout assistance in the browser. • Building and iterating on beautiful interactive brand introduction web experiences on desktop and mobile. • Revising our fragment and full-page caching structure to deliver static and catalog pages lightning fast.

-----

SKILLS AND REQUIREMENTS

• 4+ years of professional experience building websites and web apps • Fluency in HTML/CSS/Javascript, ideally also in Bootstrap, jQuery, and Angular.js • Familiarity with Grunt asset pipeline or comparable frontend frameworks (Sprockets, Rails, etc.) • Experience with full LAMP stack or comparable (e.g., RoR) environment • Proficiency in maintaining a modern webdev pipeline or willingness to learn; our pipeline includes scrum, Trello, git (BitBucket), Cloudflare, zero-downtime rollouts, and sync and setup scripts

-----

We're looking for creativity, intelligence, and initiative, and we care about that much more about that than experience with our specific stack. If you're interested in joining a fantastic team to own and build our next generation of web experiences, please write to us at careers@tatcha.com.

WEB SOFTWARE ENGINEER • SAN FRANCISCO, CA

Email careers@tatcha.com.

-----

ABOUT US

TATCHA is a young, innovative luxury beauty company based in San Francisco with a focus on E-Commerce excellence. We're growing our web team to build out the next generation of innovative features for our website and tech ecosystem to delight our customers all around the world.

-----

ABOUT OUR TECHNOLOGY

• Modern LAMP/PHP stack

• ExpressionEngine and Magento

• Grunt/Compass/SASS asset pipeline

• jQuery/Angular.js frontend

-----

ABOUT THE POSITION

TATCHA is a small and growing company, so you would be joining as a key member of the team, owning features from inception to deployment to maintenance, and being responsible for major parts of our web infrastructure.

On our web team, you would be deploying features to our customers on a daily basis. Here's an example of some of the challenges we're building for right now:

• Introducing live interactive audio and video skin consultations and checkout assistance in the browser.

• Building and iterating on beautiful interactive brand introduction web experiences on desktop and mobile.

• Revising our fragment and full-page caching structure to deliver static and catalog pages lightning fast.

-----

SKILLS AND REQUIREMENTS

• 2+ years of professional experience building websites and web apps

• Fluency in HTML/CSS/Javascript, ideally also in Bootstrap, jQuery, and Angular.js

• Familiarity with Grunt asset pipeline or comparable frontend frameworks (Sprockets, Rails, etc.)

• Experience with full LAMP stack or comparable (e.g., RoR) environment

• Proficiency in maintaining a modern webdev pipeline or willingness to learn; our pipeline includes scrum, Trello, git (BitBucket), Cloudflare, zero-downtime rollouts, and sync and setup scripts

-----

We're looking for creativity, intelligence, and initiative, and we care about that much more about that than experience with our specific stack. If you're interested in joining a fantastic team to own and build our next generation of web experiences, please write to us at careers@tatcha.com.

TATCHA • San Francisco, CA • http://www.tatcha.com/

==== Positions ====

• Full-stack/Frontend Web Engineer

Email steven@tatcha.com.

==== About Us ====

TATCHA is a young, innovative luxury beauty company based in San Francisco with a focus on E-Commerce excellence.

We're growing our web team to build out the next generation of innovative features for our website and tech ecosystem to delight our customers all around the world.

==== Technology ====

• Modern LAMP/PHP stack

• ExpressionEngine and Magento

• Grunt/Compass/SASS asset pipeline

• jQuery/Angular.js frontend

==== About The Position ====

TATCHA is a small and growing company, so you would be joining as a key member of the team, owning features from inception to deployment to maintenance, and being responsible for major parts of our web infrastructure.

On our web team, you would be deploying features to our customers on a daily basis. Here's an example of some of the challenges we're building for right now:

• Revising our fragment and full-page caching structure to deliver static and catalog pages lightning fast. • Introducing live interactive audio and video skin consultations and checkout assistance in the browser. • Building and iterating on beautiful interactive brand introduction web experiences on desktop and mobile.

We're looking for creativity, intelligence, and initiative, and we care about that much more about that than experience with our specific stack. If you're interested in joining a fantastic team to own and build our next generation of web experiences, or if you have any technical questions, please write to me at steven@tatcha.com.