5n

TextQL is building full self-driving for the modern data stack. We're automating the day to day job of a data analyst, from pulling dashboards to answering data questions straight from a company's data warehouse. Non-technical users should be able to ask any data-driven question to TextQL's chat bot and get a relevant, trustworthy answer.

We just closed our seed round with ~$4M in financing, have significant revenue and a growing base of paying customers, and are well positioned to become the leader in automated data analysis.

We're looking to bring on software engineers to help us solve the most complex challenges in the data analytics space and enhance the capabilities of our TextQL platform. As a software engineer at TextQL, you'll play a vital role in revolutionizing the way data analysis is conducted, making it more accessible and efficient for everyone. You'll work on interesting technical problems and be given full autonomy in designing, implementing, and launching your solution.

Some of our current projects involve: - Building structured parsers and action executors on top of language models to provide a rich chat experience, secure python and SQL execution, dashboard search, and graceful failure handling. - Indexing our customers' entire knowledge base of dashboards, docs, and data transformations in order to write accurate queries from a business and technical context (should I use a left or inner join? is revenue inclusive or exclusive of sales commission?) - Building out connectors to a ton of data tools; warehouses, dashboards, catalogs, metrics layers, and more!

Tech stack is Haskell + Typescript (Svelte) + Nix right now. Tech stack experience not necessary if you're willing to learn.

We're looking for people who: - Are customer obsessed: Understand that making happy customers is our number one priority, not writing flashy features or adding dependent types to the codebase. Be willing to talk to and take the time to understand our customers. - Take ownership: Be willing to formulate and implement both technical and non-technical solutions to important business problems, and never say "that's not my job". - Are proactive: Identify and fix problems without being asked.

Our current team: - Mark (me) was a software engineer at Facebook working on Sigma/Haxl before leaving to start TextQL with Ethan. - Ethan led the Data Team at as an early employee at Tackle.io, a $1.25b cloud software startup. - Three other software engineers, including two extremely sharp college dropouts and two former startup founders. - One person working on Sales + Operations, the former highest-performing salesperson at Tackle.io for multiple years straight

Other facts about the job: - We are currently remote, but as we grow will likely move to require some kind of in-person work around 1-2 department headquarters. If you're located in or open to moving to either San Francisco, New York, or London, there should be no problem. Apologies for the uncertainty here. Relocation and visa support will be provided if needed. - All Experience Levels (full-time, new graduate okay, internship unlikely but happy to look) - Salary: $105k-170k with a generous equity grant scaling on seniority.

Email us at engineering at textql dot com

I'm pretty sure that the actual Copilot auto completions are still on GPT3 for speed and cost reasons

The simply-typed lambda calculus is modeled by any cartesian closed category. That means we can define categories representing domain specific interpretations such as hardware circuits or automatic differentiation, and then execute existing programs on them (in this case written in GHC Haskell.)

Seems like both of them are inspired by Functional Reactive Programing, so yeah, hard to say Elm was foundational

I've found that knowing categories to the extent that Haskell teaches them through osmosis is useful. For example, knowing functions are functors in the return type and cofunctors in the argument makes grasping co/contravariance in OO much easier.

I haven't found any utility to the CT that is above the scope of Haskell; it feels like if it's too advanced to implement in Haskell, it's too advanced to find a use case anywhere.

In this post I feed GPT-3 a bunch of high-school level CTF problems to see how well it handles basic security and cryptography tasks.

It would be really cool if this was a browser extension that talked with the AnkiConnect protocol! Then I could just open it up on an article I like, make some cards, and click which ones I want to add instead of copy and pasting.

IMO dataframes are the reason why dynamic typing fits data science so well. It's certainly possible to represent a single dataframe as a static type; but representing all the slicing, column removal, joins, etc. is actually pretty hard without dependent tricks. So bypassing types for data frames is preferable. On your ML engineering point, the other side of it is that once your dataframe's schema is finalizes it really should be statically typed so that assumptions can safely be made about what is/isn't inside of it

Would be interesting if the Chinese-Japanese ones did homographs on Kanji/Hanzi too!