knesek · HackerTrans

Quench.ai | Multiple Roles | ONSITE (Hybrid) - London

Quench.ai connects to internal tools, enabling teams to search, chat, and retrieve precise answers from organizational knowledge - and to automate tasks with AI. Team of 15 based out of London AI Hub. Founded by Husayn Kassai - former CEO and Co-Founder of AI unicorn Onfido. Pre-seed of $5M raised from 8 funds including Tuesday VC (formerly Crunchbase), Firstminute Capital, Sequoia Scout Fund, Northzone Scout, and over sixty founders.

We're hiring for:

- Team Lead (Tech Lead Manager) to lead our core engineering team responsible for frontend, backend and infra

  - Location: London, On-Site Hybrid (3 days a week)

  - Link: https://www.quench.ai/job/team-lead-software-engineering  

  - E-mail: [email protected]

- Tech Lead Applied AI engineer to work on developing and improving our RAG and agentic AI technology

  - Location: London, On-Site Hybrid (3 days a week)

  - E-mail: [email protected] (pls reach out via e-mail, job not yet out in careers site)

Tech Stack: Frontend: Typescript, React, Next.js, Backend: Python, Postgres, Pinecone, Redis

knesek

8 年前議論

Hm. My team is running and developing a somewhat complex system based on jvm for years, and never encountered any of the issues in the bullet points. Having consistent test, staging and production environments produced by ansible have been working out for us (and is not hard). Are we just being lucky?

knesek

8 年前議論

When I was inexperienced I feared ORMs because of the negative performance impacts I've read they could have. I constantly worried about what would happen if the amount of data increased and I hit ORM induced problem that I could not resolve without major rewrite of data access layer. However, whenever I've actually hit those problems in production, I found the similar thing the authors of the article did - ORM induced performance problems can be fixed by 1-5 lines of code changes, if you knew where the actual problem was. In fact, I learnt that there's no "ORM induced performance problems", there are only problems induced by lack of understanding of how ORM works.

As for the knowing where the performance problem is, I find that skill (that I think should be basic) is in fact very elusive in the engineers I encounter. When I interview people, even in what would be upper intermediate to senior level in terms of years of experience, alarmingly small number have ever done or could do (or even would do) performance profiling like described in the article. Yet they do describe how they changed this ORM for that ORM, this DB for that DB, this language for that language, in the name of higher performance.

I've seen or heard of:

- Teams spending weeks exchanging SQL DB for No SQL DB because of unsolvable performance problem. When hitting the same problem with NoSQL DB, they find that addition of a simple index is solution in both cases

- Teams spending weeks exchanging Hibernate for OpenJPA in a complex application, because of performance, without doing any performance analysis, because they've read article that says Hibernate is slow

- Teams choosing complex architectures they don't really understand, for performance reasons, without being able to articulate performance requirements of the system they're building

These days, whenever someone mentions performance as a reason for anything, I judge their competence based on their response to the question "And how are you measuring and monitoring it?"

コメント