My initial question was “When given a take-home assignment, what is a reasonable turnaround time to get it back to them?” I now know it’s within a week.
I was given the assignment to create a basic Django app and was told to spend no more than 3 hours on it. Here’s the short text of the assignment description:
Table Metadata Extractor (Python)
Please provide a Python Django application that has one API endpoint which accepts a database connection string from your DB of choice (Redshift, BigQuery, Snowflake, MySQL, Postgres), connects to the database using SQLAlchemy and returns a list of the TableMetadata data objects (see below) for all tables in the database.
TableMetadata = {
columns: List[ColumnMetadata]
num_rows: int
schema: str
database: str
}
ColumnMetadata = {
col_name: str
col_type: str
}
Bonus points for:
· Instructive error messages for improper connection strings or other invalid input
· A solution that is efficient
As a Data Engineer/Analyst, I haven’t done web-dev stuff in years and have never used Django. My immediate instinct upon reading this project description was to find a resource to learn Django online. I’m not sure this is the right instinct, because software is about doing more than learning as Alex has mentioned so many times.
The way I see it, I have 3 ways to approach this assignment:
The first approach requires the most upfront time. The second might be longer or shorter than the first. And the third doesn’t require any upfront time but requires a commitment to being in a much better position to do the assignment in future.
This is the second time in a couple of months I’ve been in this position since I was given an assignment for a different company to build a Flask app and did a shoddy job with it.
My first question is, which of the 3 options should I do to address this time-sensitive situation?
My second is, how should I address this situation long-term? Building some web-dev projects in Python with Flask/Django/FastAPI seems pretty logical. I don’t get to work with them at work, but I could spend a few weeks building stuff with them. I guess that’s the answer, the key is to avoid tutorial hell.
My third is, how should I think about take-home assignments in general? Should they stretch me a lot in terms of learning new things or conversely, should I be, say, 80% comfortable with what I need to do, just stretching a bit here and there to do stuff?
Thanks!
This actually doesn't seem that bad (I've seen way worse from take-homes) - I think you should try it!
Tutorials aren't inherently bad or anything; it's just that you don't want to rely on them too much and get stuck in tutorial hell. Another tactic is to never just blindly follow the tutorial - At that point, you're purely a passive consumer instead of an active do-er. You should always be tinkering with what the tutorial tells you, switching out parameters, deleting code, and doing other things to experiment. That's when you get the true learning.
The first thing I recommend doing on this project is some basic decomposition as I talk about here: "How do I make software less overwhelming?"
My high-level breakdown is roughly like this:
For #1, this tutorial seems okay: https://www.bezkoder.com/django-rest-api/
I found this Medium article that seems to do #2 and #3: https://medium.com/@anushkamehra16/connecting-to-sql-database-using-sqlalchemy-in-python-2be2cf883f85
Creating the plan and finding the tutorials took me literally just ~5 minutes. From there, I would just start doing the tutorials and coding. No need to find some high-level Django book that takes 5 hours to read.
I didn't make it to the next round, but ask for feedback on why I didn't:
Hope other people can benefit if you have a similar assignment.
My third is, how should I think about take-home assignments in general? Should they stretch me a lot in terms of learning new things or conversely, should I be, say, 80% comfortable with what I need to do, just stretching a bit here and there to do stuff?
If a take-home assignment takes more than 2-3 hours of your time, just drop it. I'm not a fan of take-homes as they're so anti-candidate: They suck up a lot of time, can be cheated through, and you're getting very limited signal on the candidate as you aren't watching them code.
Also, if a take-home is in a completely new domain you haven't worked with before, it's not likely you will pass the actual interview anyways as it will probably be a deeper (and live) dive into the same domain. While any take-home can be brute-forced with sheer time, an actual interview cannot.
That being said, the economy sucks. If take-home interviews are the only thing you can get and you really want to leave your job, then you sort of have to do them. 😢
That's actually really good feedback - I'm glad they shared it with you! Those are all great system design principles to remember when building standard product/API applications.
While the rejection sucks, I'm glad this was an example of how you should actually learn system design: By building stuff and then getting feedback on how it can suck less. 😁
Thanks Alex! That decomposition is a big help! It's definitely a skill I will be honing.