Context

We are growing, and our engineering team also needs to grow rapidly, but at a sustainable pace. Internships have been a very successful and low-risk source for hiring engineers at Frappe. Considering this, we decided to create a program with a batch size of ~15-20 apprentices. We created a job opening and invited students from local colleges to apply.

It's getting hard to screen good applicants

Our hiring process is pretty unscalable already; we have not found a good way to asynchronously filter out job applicants to a smaller number, which we can interview 1-1. The apprentice position got ~600 applicants, and we had to close the applications. Most applicants for this were freshers, and barring a few outliers, it was very hard to discern who was a good fit just by looking at their resume. The majority of resumes we screened were...

1. Using some LaTeX resume format like Jake's Resume.
2. Had STAR method of listing down impact in their side projects / internships.
3. Vastly exaggerated list of skills.
4. Keyword stuffing and using very fancy terms to make the resume look appealing to ATS filters.

The apprentice program was supposed to be done in-person. Considering the state of applications and tedious process of filtering, we just decided to open it up for everyone and do old-school "walk-in" style interviews. We opened up 3 days and ~120 slots for interviews. Those who were interested can just book their slot and get a shot at a short interview without any filter.

How did we end up filtering?

In the past, we've had good luck with many "smells" or "quick tests" for filtering. Usually, we can tell the outcome of an interview with very high certainty within the first 10 minutes. So we wanted to speed up this process and find one good test that we can do with everyone. We tried a few things, but eventually settled on asking applicants to design a database schema for simple applications, usually something they're already familiar with, according to their resume. e.g. E-commerce order management, Course enrollment tracker, Restaurant order management, Task scheduler, Hotel Booking, etc., etc.

We believe good data structure design is essential for writing good programs. Similarly, a good database schema design is a crucial part of web development. All of these "schema design" questions involved at least one one-to-many relationship, e.g. order and order items are usually stored separately and linked with order_id. Almost everyone failed at this basic step. Some figured it out by nudges, but almost half of the applicants couldn't figure it out at all after the nudges too. They could all name the concept "normalisation," but not do it practically.

Interviewing college graduates is always a recipe for losing whatever faith you've left in our education system, and this experience was no different. A significant chunk of "good-looking" resumes lacked an understanding of basic fundamental concepts.

Using schema design as a filter, we were able to filter out people and then do our traditional interview process for 2nd round. Please don't read this and think all you need to do to get through Frappe's interview process is learn one-to-many DB schema design. Every interview is improvised, and we are also looking at how you approach a problem... not just the outcome.

Our advice to upcoming graduates

1. Revisit your AI usage or stop using it entirely

It is never too late to course-correct your learning journey. If you've outsourced all your work to AI so far, you've likely not learned anything yourself other than what to tell LLMs. Which is useful, but not nearly enough to get a job at Frappe.

LLMs can "compile" natural language to code. This shift in a new way of writing code feels analogous to when compilers replaced hand-written assembly code. It isn't a good analogy though, as LLMs' compilation is not deterministic because natural language is rarely sufficient for good "specifications".

Nuances like performance, security and correctness in edge cases are all still "leaky" in this new age compiler and still require a proficient engineer who understands things deeply enough to evaluate the output code. At present, it feels like a massive improvement in the efficiency of writing code, but not a complete replacement for skills that an engineer should have.

We strongly recommend reducing reliance on AI and writing code yourself, at least while you're trying to master the fundamentals and not worrying about churning out 1000s of lines of code every day.

It's not all bad, though. A recurring pattern we saw was a lack of good guidance or mentorship. LLMs can be a good "mentor" if you use them that way. Ask for approaches to solving a problem instead of solutions:

• What is a good roadmap to learn X?
• Why X is always done this way?
• What are the implications of this design?
• Why should we normalise the table this way? What are the pros and cons?
• How can I evaluate different caching strategies?

2. Go back to fundamentals

A worrying number of students failed to demonstrate an "introduction to computer science" level of understanding after 3-4 years of college. They still had good-looking resumes with fancy projects and even open-source contributions. There's zero chance that you'll become a good engineer without knowing the foundational concepts. We expect everyone at Frappe to understand the following fairly well:

1. Data structures and algorithms - Not implementing them from scratch, but understanding them enough to know which one to use where. Space and time complexities.
2. Programming paradigms - Writing modular code using functions, classes and modules. Following OOP principles.
3. Databases - Designing schemas and writing basic queries by hand.
4. Testing - How to test your code and write testable code.
5. Good enough surface level understanding of how computers actually work. E.g. hardware, operating systems, compiler/interpreter, networking.

Whatever time you have left in college, it would be well spent on revisiting and studying fundamentals again.

3. Write and read A LOT OF CODE

Skills are developed with repetition; just knowing a concept is not enough if you can't apply it well to a relevant problem. The easiest way to do this is to write a lot of code yourself. This can be any mix of what you prefer:

• Leetcode / HackerRank style problem solving and DSA practice problems.
• Recreating your favourite project from scratch.
• Your hobby / side-projects.

Reading good code is equally important, as it exposes you to good "taste" that exists out there. It is pretty hard to just read source code "cover to cover", so a good way to approach it would be to use a library and frequently do "go to definition" to understand the source code as you use it. I recommend reading Flask source code. Any popular and well-maintained library is a good starting point.

4. Understand "research", worry about publishing later

Few students had published research papers on their resumes. A vast majority of student research I've seen is bullshit work done to pad resumes or increase citation count of professors. Some students seem oblivious to this reality. There are notable exceptions like top universities (Likes of IITs, IIITs, IISc, etc.), but unless you're lucky enough to study there and find a good research project, you're much better off focusing your efforts elsewhere.

If you find research interesting, then a good starting point would be to find any random "Top 50 CS papers" list and read them. You can't put that on a resume, but a 10-minute conversation with someone who understands things in depth is very different from someone who does not.

---

Frappe strongly believes in mastery and excellence in one's craft. The jury is still out on whether we will all just become AI prompters someday... until that day comes, this advice seems valid. We are all kind of vibing through this, so use your sound judgment.