DEV Community: Gerard

Write Faster SQL With AI

Gerard — Wed, 01 Feb 2023 15:24:40 +0000

Act today, not next quarter

Latitude was born with a clear focus: help companies extract value from data by improving the way you interact with it. Our team has worked (and struggled) with data for years now, and we are aware of the day-to-day challenges and issues that technical teams have been facing when it comes to working with data.

Different spreadsheet versions, manually connecting databases, fragmented data, building and maintaining pipelines, crashed BI reports, never-ending requests in queue… you name it. All of these scenarios make getting value out of data incredibly slow and inefficient.

We firmly believe that the biggest value of data interaction comes from how fast you can answer a question with reliable data. People at companies need to make decisions. Based on data. Today. Not next quarter.

Data “duties” end up more often than not at the Tech team’s table. And developers are busy with guess what… making sure the roadmap is happening and that all systems are up and running. It’s hard to navigate this sea of changing priorities and make sure that everything works fine.

That’s why any major improvement in the data process can save tons of dev resources and accelerate the decision-making inside an organization. And today, Latitude is happy to announce a major one with our new SQL AI Assistant.

Introducing the new AI SQL Assistant

We get it. Every other day, a new AI-based product comes from nowhere with the promise of “revolutionizing the way you do X or Y”. But in this case, it’s true. If you’ve been using Github Copilot for the last few months, we bet that you’ll be using this one too.

Some CTOs or Engineering Leads are not writing SQL queries every day. Some people in Product or Marketing know a few SQL functions here and there but they are not fluent. In all of these cases, data exploration takes longer than expected. But now, with our new AI SQL Assistant, these processes will be faster.

Latitude’s AI SQL Assistant uses Open AI’s GPT-3 Models to suggest code and entire SQL functions in real-time, based on your prompts and right from your data project canvas. Let’s see some examples of what you can achieve with it.

You need to filter the records on one of your tables by score, but you don’t feel like typing the whole query:

Or let’s say you have a table with your Net Promoter Score data, and you want to quickly calculate the average score. Just ask our AI Assistant and the query will be there:

From zero to insight in minutes

1. Sign up for an account

You can sign up and try Latitude without any commitment. It’s completely free, and no credit card is required. As simple as that.

2. Connect your Data Sources

Latitude connects to your database, data warehouse, and other data sources such as Google Sheets or your CRM. More than 100 data sources are supported.

The cool thing is that you can join multiple data sources in the same data exploration. Let’s say you want to create a table that merges data from your production database in PostgreSQL and your Hubspot CRM. That’s possible with Latitude.

3. Start exploring your data

With Latitude, teams can unlock the power of data through our AI SQL Assistant, manually writing SQL queries and visual programming on an infinite canvas.

4. Visualize your data

At Latitude, explore and visualize data simultaneously in one convenient place. Pick between charts or tables to add them directly to your canvas for effortless integration. Now your organization can start making the right decisions and moving forward.

What’s next?

We are barely scratching the surface of the possibilities of AI applied to data exploration and analytics. Our team is working hard on finding and developing new ways to use artificial intelligence in this landscape, so you can benefit from it and spend your time where’s most convenient.

At the end of the day, we keep thinking about the following question: What can we do so our users are able to answer questions with reliable data faster than ever before? And also they can do it without spending huge dev resources and time in the process.
That’s our commitment, so stay tuned to see upcoming developments with AI in SQL from Latitude. And we are always open to getting feedback from our users.

You can try Latitude today completely free and reach out to us here.

Why most developers fail their first tech interviews

Gerard — Mon, 11 May 2020 07:32:50 +0000

In the last 4 years interviewing candidates for development roles, I've come to realize the cohort with the highest rejection rate is applicants to entry-level positions.

What pains me to see is that most of them fall off the recruitment funnel for the simplest of mistakes, which often have nothing to do with their professional skills and could easily be avoided. These aren't failures of skill, but of communication.

In this post, we will go over the developer recruitment process at
Factorial, mostly as an excuse for me to explain what is it that makes so many entry-level candidates flop their interviews, and how you can avoid it.

The process

The recruitment process is simple: two interviews, one more generic let's-meet type of interview, and another more technical. After the second meeting, you
either get rejected or get a job offer.

The first meeting is mostly innocuous: an opportunity for us and the candidate
to assess whether we are a good match. The only piece of advice I can give you
at this point is to be honest, not be a jerk and ask as many questions as you
can. Ideally, you want to leave this encounter convinced whether you want this
job or not. We will answer almost any question you might have, and you should be
wary of any company that isn't willing to do the same.

Once introductions have been made, you will be asked to submit a take-home
exercise that will require you to write a representative chunk of your own
code. If you are prolific enough, we will gladly accept another program you
might have already developed. The second interview basically consists of you
going through your own code with some devs from our tech team. You'll get asked
technical questions about your submission and some more general aspects, if the
conversation takes us down that path.

The purpose of this exercise is many-fold, from evaluating general technical
abilities to assessing reasoning capabilities but, mostly, the purpose of this
exercise is to evaluate how well would you do the job we want you to do. Most
of these aspects are correlated, but if you fail at the latter you won't get
hired.

This is, unsurprisingly, where most candidates flop. Let's see why.

All candidates look alike

Truth is, for entry-level positions, there's little variance in the candidates'
technical skills.

We get candidates with brilliant exercises that cannot defend it accordingly
during the interview, candidates with lesser code that fair rather well during
questioning, candidates obsessed with CS theory, others more of the
learn-as-you-go type, variant degrees of experience, creativity,
resourcefulness... In the end, all these aspects average out, painting the
portrait of the default entry-level applicant who is capable of writing a fairly
decent program involving frontend and backend code, sometimes with some extra
sprinkles of infrastructure code on top.

Put another way, statistics say that if you made it to the tech interview portion
of the recruitment process you probably have the technical skillset required to get
hired. This won't always be the case but, generally, the rule holds true.

Now, if all candidates look alike, what is it that distinguishes them apart? What
makes recruiters pick one over the many others?

I'm convinced it's communication. More specifically, knowledge communication.

The success of a tech candidate is a function of their knowledge and how well
they can communicate said knowledge.

Given that we have established most junior candidates have similar technical
knowledge and that, unsurprisingly, most developers suck at communicating, you
can see how this ends up with a high rejection rate of entry-level applicants.

Let's explore further this notion of knowledge communication, and see how you can
exploit it to improve your odds at your next tech interview.

Know your code

Mind you, when I speak about communication I'm not implying you can talk your
way through the recruitment process and end up at a cushy dev job with no
technical skills to show for. At the tech interview, the beans will get spilled
and your knowledge boundaries will be put to bare. Knowledge communication
requires, well, knowledge; You have to do the work and learn your computer
sciency stuff first.

Problem is, often developers spread their knowledge surface large and thin,
sometimes too thin. They learn from repetition, which leads to a lack of
understanding, which results in poor knowledge communication.

Let's say you, as a candidate, learn about the new fancy framework du jour,
follow its documentation examples and, with today's tools, you quickly get a
pretty decent app up and running. You already look like 99.9% of the other
candidates. You even got professional stuff out of the box: JSON Web Token
authentication, cross-site scripting protection, WebSocket support, and whatnot.
You start feeling confident and end up submitting an exercise that contains code
that looks like this:

class ApplicationController < ActionController::Base
  protect_from_forgery unless: -> { request.format.json? }
end

This is the candidate's code. If I git blame it, their name will show up. And,
yet, most entry-level candidates have but a vague idea what this code does.
The result is candidates communicating their lack of knowledge about their own
code. They cannot answer what their software does and, what's worse, why it
does it.

You have to know your code.

To tackle this issue, I recommend candidates take a much more deliberate
approach and think in terms of knowledge communication. If you are an applicant,
run over every line of your exercise before you submit it and ask yourself: "Can
I explain this line of code?". This will immediately beg questions about the
what, why, and how of every piece of your program you didn't really grasp,
deepening your knowledge.

What's more important, this approach will set you down a path of reinforced
learning: Discovering how XSS protection works will take you through HTTP
headers, the different types of HTTP verbs and codes, maybe you'll understand
how your framework uses JWTs to manage your users' sessions and what this pesky
CORS error is all about.

At this point, you will arrive at the tech interview with knowledge not only on
how to build a program with a particular framework, but on how the underlying
infrastructure of the internet works to support the many features your framework
provides and your app makes use of. You will be able to communicate your
knowledge about your code and even respond to some extra curveballs the
interviewer might throw at you. Your skills will be immediately more
transferable, as all frameworks rely on the same underlying infrastructure.
You'll be a better engineer.

Sadly, you won't be able to answer everything, since the purpose of the tech
interview is precisely to test the limits of your knowledge, so let's see what
you can do about that.

Addendum: Other examples of poorly understood code I often encounter are JWTs,
OAuth, Polymorphism, db indexes & foreign keys, HTTP basics, React component
lifecycle methods, JS Promises, async/await & generators. You don't need to know
all of these but, if it's in your code, you should.

Know your unknowns

If you follow the aforementioned prescription, you'll quickly reach the second layer of your circle of competence: things you know you don't understand very well.

For example, you might feel brave and make use of the new useEffect hook from React:

const CatCounter = ({ cat }) => {
  const [counter, setCounter] = useState(0)

  useEffect(() => {
    setCounter(counter + 1)
  }, [])

  return `I have counted ${counter} cats so far!`
}

Now, useEffect is hard — otherwise, its creator wouldn't have written a
gazillion-line blog post about it — and you probably don't understand very well why you have to put that empty array as a second argument. You know, though, that if you don't the counter does not seem to refresh with every new cat you pass it as an argument. You have a thin knowledge of this piece of your code, and this is a problem.

As a rule, do not try to hide your knowledge gaps in code. You'll open
yourself to getting a question you will be playing guessing games against.
Instead, simply admit it:

const CatCounter = ({ cat }) => {
  const [counter, setCounter] = useState(0)

  // NOTE: I am not sure why I need this second argument but otherwise the
  // component does not seem to update on prop updates. Need to investigate.
  useEffect(() => {
    setCounter(counter + 1)
  }, [])

  return `I have counted ${counter} cats so far!`
}

Communicating a lack of knowledge is also knowledge communication.

You are admitting your knowledge gap, implying you know this is a problem but had to move on with it, and announcing your intention to fix it. It shows self-awareness, curiosity and the drive to improve; the kind of potential we look for in candidates at this level. It’s not a simple “I don’t know”, which would be lazy, it’s a reasonable utilitarian argument that tacitly admits failure of understanding.

At this point, the interviewer can do little more than ask if you had time to follow on your investigation which, given the circumstances, is an excellent outcome.

Addendum #2: Of course, if your exercise contains many comments like these you should reconsider whether you are ready to apply for the job. Nevertheless, do not be afraid to admit gray areas in your understanding.

Wrapping up

Most entry-level candidates are very similar, and it’s highly unlikely you’ll be the exception. Instead, focus on deep knowledge vs thin understanding, specially about those concepts you know you might get questioned about. If you can, don’t answer only with “I don’t know” but don’t play guessing games either, state your knowledge gaps, what you think you know about them, and how you plan to improve on these gray areas.

There are many more aspects we could explore in preparation for your first tech interviews, but these are the foundational aspects all candidates should be aware of. The rest, we'll explain in upcoming entries.

Cheers, and good luck in your next interview.

This post originally appeared at https://gerardclos.com

A set of programming aphorisms at Factorial

Gerard — Wed, 15 Apr 2020 09:33:54 +0000

At Factorial, we maintain an engineering Handbook where we document aspects such as common abstractions, programming principles and documentation of our architecture.

Among these, there are a set of aphorisms stemming from coding best practices and common pitfalls we have been encountering during the last 4 years building our product. Let's share some of these.

Beware, these aphorisms are language-agnostic and, thus, you might find them more or less regularly in your day to day depending on the characteristics of your preferred programming language.

Depend on contracts rather than data structures

This is my personal favorite because it's so simple yet so ubiquitous. Put
bluntly, data structures make for lousy interfaces: they are often opaque, mutable and nullable, all characteristics you wouldn't want for an interface — and yet we use them as such constantly.

The most common example is accepting a hash as a method argument:

def method(hash)
  puts hash[:foo][:bar] # This can print something, null or raise an unexpected error.
end

NOTE: This is especially prevalent in languages that make it easier to work with data structures and nullables such as Ruby or Javascript.

Using a data structure introduces an implicit dependency between your method and the data structure's shape, a dependency that could have been easily avoided by simply passing the expected value:

def method(bar: nil)
  puts bar # This can print something or null
end

In cases where the dependency with the data structure cannot be avoided, isolate it behind an API:

def method(hash)
  puts HashAccessor.new(hash).get(:bar) # This can print something or null
end

class HashAccessor
  def initialize(hash)
    @hash = hash
  end

  def get(attr)
    # ...
  end
end

Although this might come across as a superfluous refactor it minimizes the spread of the dependency and paves the way for a future refactor in which we would get rid of this data structure dependency altogether.

Avoid null values

Hardly a surprise. All the new cool kids in the block are using it.

The problem with null values was already hinted at in the previous aphorism: it's a very hard contract to enforce. This will result in errors happening far away from the underlying issue:

# main.rb
ROLES = { admin: 'admin', manager: 'manager' }
role = ROLES[user.role]
user_presenter(role)

# user_presenter.rb
def user_presenter(role)
  return 'Admin' if role == ROLES[:admin]

  ManagerRolePresenter.render(role)
end

# manager_role_presenter.rb
def manager_role_presenter(role)
  "#{role.capitalize} – Lead" # << Unexpected `capitalize` message for `nil`! This is very far from the origin of the `nil` and hard to fix
end

To avoid null values you can enforce types (if your language supports it), implement the optional pattern, use a custom contract with data validation (such as a Struct) or directly raise an exception closer to the null source.

Code should be greppable

Or, put another way, do not be too smart for your own good.

As a rule of thumb, your teammates should be able to easily navigate your code using only a pattern-matching tool like grep (or ctrl-f for those using fancier editors).

If that weren't the case it probably means your code is not explicit enough and is hiding dependencies with dangerous techniques like meta-programming:

module Jon
  class Snow
    # ...
  end
end

# main.rb
  def main
    "Jon::#{name}".constantize.new # This can blow up
  end

As if the potential error wasn't bad enough, this technique obfuscates the
author's intention and makes navigating your code more difficult than necessary.

To avoid these pitfalls and improve code quality make extensive use of static analysis tools
such as linters or static type analysis.

In the particular case of meta-programming, replace it with a good ol' Map or switch statement.

Depend on abstractions rather concretions

Lastly, a general principle. If you take a look at most of our previous examples and their proposed solutions, they all share a common property: the solution implements an abstraction.

Do not depend on data structures, depend on an abstraction that gives you access to the underlying data. Do not depend on nullable values, depend on an abstraction that handles the nullable state for you... You can see the pattern.

The advantage of abstractions over concretions is that they change less often, and this is good for code maintainability:

You often cannot control the amount of changes over time, but you can control the number of dependencies. Stay away from zone B and you will be fine.

That's it! We hope you will find some useful tips from this list that you can put to good use in your daily coding practice.

Cheers.