Edin Citaku

What we got wrong at our first industry conference

Edin Citaku — Fri, 10 Jul 2026 00:00:00 GMT

Ten minutes into our first industry conference, I realized almost every cold email I'd sent in the last month was wrong.

We're a startup entering workers' compensation insurance, and last week we set up our booth at CCWC in Anaheim: two founders, a stack of brochures printed the night before, and a putting green to lure people in. We made a ton of mistakes. Here are the lessons, so you can show up better prepared than we did.

Sell, sell, sell

We are entering the workers' compensation insurance market, and were still in the phase of doing user interviews to find the most painful problem our target users face.

Inspired by the book The Mom Test, I led most of my initial outreach to prospects with a research question: I told the prospect that I'm writing a report on XY and asked them to participate in exchange for access to this report once it's done.

The instinct is roughly correct. At the start of a conversation with a potential buyer you should definitely focus on understanding what problems matter most to them.

But people come to a conference to buy, so you should actually try to sell to them, don't be ashamed of that.

Unsurprisingly, the research approach did not work. Enterprise buyers already have packed schedules, and participating in "research" is not what they flew in for.

The same executives who ignored my research emails answered within hours when we changed the message to the actual problem we solve: "we can decrease your exposure by closing claims 10 times faster." Lead with the pitch.

Write like an actual human

Early in our outreach journey we used LLMs to generate the messages we sent to prospects. Nothing wrong with that in principle, but make sure whatever you send actually sounds like a human.

Later I went back and looked at some of the emails I had sent. Honestly, if I received something like that, I would never bother to respond. It sounded so obviously AI-generated.

My approach now: I handwrite the email in my own style and keep it short (LLMs somehow love to be long-winded). I still use LLMs to personalize some parts of it, but the agent only sends it out after I proofread it and give my thumbs up.

This approach is obviously slower, but the response rate is much higher. In combination of leading with the pitch the rate went from 0% (you read that right) to 5%.

Set up meetings before the conference

We had a booth, but foot traffic is hit or miss.

A conference rarely contains only your ICP. Most attendees are in the industry, but adjacent to the people you sell to.

And the people with buying power rarely look at the stands. They are way too busy with the meetings they came for.

By far the best conversations we had were in the meetings we set up before the conference. Every single one converted into a follow-up call, booked then and there.

The math is simple: a pre-booked meeting converted at 100%, a booth conversation converted at maybe one in ten. So set up as many meetings as possible before you arrive.

Bother people

Workers' comp is an extremely relationship-driven industry, so it's hard to enter without knowing the right people. Our way around this: bother as many people as possible.

Be shameless. Chat people up. Don't feel awkward if some conversations go nowhere. As a startup it's all about survival, and getting these first customers is quite literally life or death for your company. I went into overdrive pulling people off the aisle and onto our booth. Yes, some people are introverted and this is not easy for everyone, but try to step out of your comfort zone.

Try to squeeze as much as possible out of the networking events around the conference. Most conferences have after-hours events. Talk with people and ask them where they're going. Chances are they'll invite you along, and if not, and the event seems big enough, there's usually a way to sneak in. This is the one thing we got right from the start.

Keep failing

The main advantage a startup has over larger organizations is the speed of learning. And the single most effective way of learning is by figuring out what does not work, rather than finding the one perfect way of doing things from the start.

Every lesson above came from getting it wrong first and then working out why. So just get out there and make mistakes.

The Result

We walked away with over 50 leads and a handful of deeply networked people who might become advisors down the line. But the real return was the playbook for conference number two:

Book as many meetings as we can before we land. The floor is a bonus, not the plan.
Lead every message with the problem we solve, never with "research."
Handwrite every first touch. The LLM helps, but a human hits send.
Network as much as possible, get into every event you can find.

If you're prepping for your first industry conference, DM me and I'll share the pre-conference outreach template we ended up with. And if you're curious what we're building, check out veltha.ai.

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://edincitaku.com/blog/first-industry-conference/

Palantir Interview Process

Edin Citaku — Wed, 15 Jun 2022 00:00:00 GMT

Introduction

After long and grueling years as a student, it was finally time for me to set foot on the real world and start a full-time job. Well, I am now 3 months into my first role as a Forward Deployed Engineer at Palantir and very happy so far. I had to go through a lengthy and educative interview process to land this role. Since, as you already know, I love sharing my learnings, I decided to write about this experience. In this post, on top of explaining each interview, I will also link to resources that I recommend in order to exceed in that specific interview step.

I see this work as the last and biggest of my series of posts about interviewing, my personal Opus Magnum one could say, and me finishing this chapter. I might still write about interviewing and the whole process around it from time to time but I decided to change my focus to other things. What things that might be, I don't know yet. I want to keep writing, of course, more frequently actually, just not about interviewing there is already a lot of good content about that regardless.

Anyways, let's get to the real meat and talk about my personal experience interviewing for Palantir.

Initial Contact

My initial contact with Palantir was over Linkedin, the recruiter contacted me and set up a phone call. In the call they briefly asked about my past experiences and asked one or two behavioral questions, this call seemed more to be about making sure that I was a general fit and less about filtering out candidates. At the end of the call the recruiter already set up the next interview, this one was about two weeks later.

The first real interview

The interviews that followed were all over video call. The first of those was the only one that resembles typical Leetcode-style interviews one might already know from Big Tech companies.

The first half of this interview was focused on behavioral questions, here I talked about some of my past job experiences and the challenges I had to overcome there. For these kinds of questions, I recommend using the STAR method to narrate one's answers. The method is rather simple but forces you to structure your thoughts and will lead to a more impressive story in the end.

It was very helpful that I already had past job experience through internships, so I was able to confidently answer the behavioral parts of all my interviews. But even if you don't have this kind of experience it's good enough to talk about your university projects or personal projects.

In the second half of the interview, I had to solve a typical Leetcode-style challenge. I won't get into details about the specific question but my prior preparation via Leetcode helped immensely. Additionally, I had some notes when doing a mock interview with an Amazon Bar raiser that prepared me for this kind of technical interview. You can find the notes here and reading Cracking the Coding Interview might help you as well.

After the technical part of the interview, there were a few minutes left in which I could ask the interviewer questions. This is my favorite part of the interview process, as it allows me to get a better feel for the company culture and to also ask some not-so-easy questions. This Hackernews thread has questions that I found interesting, feel free to pick any from there or just ask anything that's on your mind. Be sure to use this opportunity to get some valuable data points about the company and not let it go to waste.

A few days after the interview I got a message from my recruiter, I passed. It was time to schedule the next round, this time the onsite interview.

Onsite Interview

The onsite consisted of three separate rounds that were 1 hour long each. Each interview started with a behavioral part, we chatted a bit, and the interviewers again asked me about past experiences, past challenges I had to overcome, situations that I am weak in, etc. This time the interviewers were more specific in their questions and asked me about my motivation behind wanting to work for Palantir and how I fit the role of the Forward Deployed Engineer. It is very important to have a deep understanding of the company's mission as well as the role you are applying for. I'll quickly summarize those two for Palantir's case.

The role of a Forward Deployed Engineer

The role of an FDE is a role specific to Palantir, so I didn't know about it before applying. An FDE is a Software Engineer that is working directly with the customer for the deployment of the Palantir product. Therefore they will be responsible for solving all the technical problems that might arise in that deployment. Typical tasks can be related to data integrations (Palantir works a lot with Spark and other distributed data technologies), making sure the software stack is up to date and fixing outages if any arise. Additionally, an FDE is in close contact with both the Customer as well as the Product Development Teams to ensure a quick feedback loop for the customer and continuous improvement of the product. It's not rare for FDEs to introduce changes to the Product themselves via Pull Request.

Ultimately Palantir is a company with a very low level of bureaucracy and hierarchies, which means that you are expected to shape your career and move to tasks and responsibilities that you see yourself thrive in. Therefore the responsibilities of FDEs can range widely between each person, some are very technical and later move to roles like Software Engineer or Site Reliability Engineer, while others are very focused on communication with the customer and do work that is more akin to Palantir's Deployment Strategist.

Palantir's Mission

To understand the mission as well as the culture of Palantir I recommend watching some interviews with the CEO Alex Karp. This is an interview I personally enjoyed and that gave me a good insight into Palantir's culture.

In short Palantir's mission is to help organizations get insights into their data to enable them to solve hard and important problems. Palantir's technology is built to help institutions protect civil liberties, this means that it is designed with Data Protection in mind. In my interview specifically, I mentioned my past voluntary work, which I think left a positive impression on the interviewer. While I believe voluntary work is a good way in making the world better, organizations like Palantir do this on a much bigger scale by for example enabling vaccine distribution for entire countries or helping Ukrainian refugees find shelter in the UK.

The second half of each onsite interview was technical. The first onsite interview was about Systems Design, in this kind of interview you are expected to design a scalable application that solves a specific business problem. It's up to you (or the interviewer) how deep you go in designing each specific component. Typically these kinds of interviews don't involve any coding, and if they do just some quick pseudo code or SQL queries.

This book is generally cited as a good source for Systems Design interviews. I did not read it myself but it's currently on my reading list. I was able to pass my Systems Design Interview process without any specific preparation but instead fell back on the knowledge I gathered from my University studies and prior work experience.

The second and third interviews however involved coding. They deviated from Leetcode in the sense that there was an already existing code base and I had to introduce changes to it. I was given a specific business-related problem to solve and API documentation for the code base I was working on. These interviews felt close to a real working environment as I was trying to understand an external API while figuring out how to use it to solve the problem at hand. This a situation most of you probably know from coding yourself. I liked these interviews much more than traditional Leetcode interviews because I felt much more connected to the problem and did not feel like I was just solving some brain teasers to impress my interviewer.

The onsite was in total only 3 hours but felt intense! After a week I was given positive feedback and was told the next round would be the final round.

Hiring Manager

The last interview was with the hiring manager. My final interview came with somewhat of a delay, as I was on vacation during that time.

Before the interview, my recruiter called me and explained to me what the expectations of this interview are. Something I appreciated from my recruiter and that helped me tackle the final interview!

My recruiter gave me a hint that the Hiring Manager wanted to see how aligned I was with Palantir's mission as well as the role of the Forward deployed Engineer. They told me not to simply read from the company's website but instead do some real reflection and come to some honest conclusions. And that's what I did. I watched multiple Karp interviews, took some notes, and in the end created a page in my notebook with all the reasons why I was a good fit for the role and the company.

This experience with my recruiter was extremely positive. In general keep in mind that the recruiter is on your side. They want you to succeed and will give you any help necessary for you to succeed.

The interview went very well, the hiring manager was likable, and we chatted about all sorts of things throughout the scheduled hour. As expected the interviewer asked me about my motivation to work for Palantir and the role of an FDE. As I was adequately prepared I was able to answer the questions quite well, and I think I left a good impression on them!

In my impression, the purpose of the Hiring Manager interview at Palantir is to collect additional data points about the weaknesses they saw in previous rounds.

The offer and negotiation

After a week I finally had the call with the interviewer and was beyond nervous. As the recruiter called we started with some chitchat and I could not shake off my nervousness. After the initial chitchat, I finally got the positive message and actually got the offer. The recruiter furthermore gave me additional details about the offer. The benefits were pretty normal, additionally, some RSU was offered. What was quite shocking was the Total Compensation, for my location (Munich) the compensation offered for a new grad was something unheard of. For Americans, it might be considered a normal offer, but for my location, it was compensation some engineers only reach after many years of experience if even then.

Despite this generous offer, I decided to negotiate and a few days later answered with a counteroffer. I followed this guide when negotiating. I was able to negotiate a Sign-On Bonus, effectively raising the first year's Total Compensation by a considerable amount! My advice here is to always negotiate since once you have an offer you will almost never get it rescinded just for trying to negotiate. You have nothing to lose here but plenty to win. The worst that can happen is that your offer will not change at all which is the same outcome as if you did not negotiate in the first place.

Conclusion

All in all, I would say the interview experience at Palantir was great. It was by far the best interview experience I had so far, I can tell that the company invests a lot of resources to ensure a smooth experience for its interviewees. To pass this interview it's important to be genuinely dedicated to the role description as well as the company's mission.

List of resources

STAR principle: https://en.wikipedia.org/wiki/Situation,_task,_action,_result
Interview notes with Amazon Bar raiser: https://twitter.com/Edin_Citaku/status/1479153373962285067
Blind Leetcode 75: https://leetcode.com/discuss/general-discussion/460599/blind-75-leetcode-questions
Cracking the Coding Interview: https://www.crackingthecodinginterview.com/
Questions to ask Interviewers: https://news.ycombinator.com/item?id=30278290
Forward Deployed (Software) Engineer: https://blog.palantir.com/a-day-in-the-life-of-a-palantir-forward-deployed-software-engineer-45ef2de257b1
Deployment Strategist: https://blog.palantir.com/a-day-in-the-life-of-a-palantir-deployment-strategist-951cb59a5a96
Interview with Alex Karp: https://www.youtube.com/watch?v=kBlGMHiPf1U
Designing Data-Intensive Applications: https://dataintensive.net/
Negotiating a job offer: https://haseebq.com/my-ten-rules-for-negotiating-a-job-offer/

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://edincitaku.com/blog/palantir-interview/

Explaining the hiring philosophy at big tech

Edin Citaku — Mon, 16 May 2022 00:00:00 GMT

A friend of mine recently had his last round interview at Uber and thought he nailed it, he texted me right after the interview about how excited he is about working at Uber this summer. He was so sure about getting this offer. A day later to his surprise he received a rejection, and couldn't believe it. He was positive he was the right candidate, had more than the required skills, and already had big tech experience. How could he get rejected after all of this? He knew that Uber made the wrong hiring decision.

Why does big tech reject qualified candidates?

This case is nothing special, how come people who are clearly more than qualified keep getting rejected at Big Tech companies? The answer is quite simple, these companies quite purposefully reject many qualified candidates. Well, actually they purposefully have a process in place that values false negatives, meaning they wrongfully reject a qualified candidate, over false positives, which means hiring an unqualified candidate.

This is because a bad hire at big tech can be quite expensive. Not only does a bad hire not satisfy the role they are supposed to fill, but they can also negatively impact the productivity of the whole team and badly written code can have a huge negative impact on companies that operate on the scale that big tech companies do. The onboarding process at big tech can be much longer than in other companies, mainly because they have their own tooling and their own frameworks on which a new hire needs to be trained on. This means it can take quite a while until it is clear that a new hire is underperforming, rather than onboarding just being slow. Time in which such hire is paid a lot of money and time in which the team is not getting the additional manpower it needs.

This makes a bad hire especially expensive for big tech, so expensive that they rather miss out on a few good hires instead of accidentally making a bad one.

Where to go from here?

So what’s the actionable advice from here? It’s simple, don’t give up! Big Tech hiring is quite conservative, this transforms the interview process into a numbers game. Instead of putting all your eggs in one basket, you should keep applying and never assume you’re in until you have the offer in hand.

The approach I personally take for an interview is the following: I essentially see the interview as free practice. There are services out that for mock interviews by big tech engineers tend to be very expensive. In the case of a real interview, someone who is getting paid a lot of money and has real experience at the company you want to work for is taking the time of the day to talk with you, and all of this for absolutely free. You have the opportunity to talk with that person and learn about their experiences and their perspective of the company. On top of that, you have the opportunity to sharpen your interviewing skills, and if you bomb an interviewing question, learn how to solve it better for the next time.

Getting rejected does not mean that you are not qualified to work for that company, it just means you got filtered out for one reason or another (Try to find that reason!). Software engineering at FAANG is still... well, Software Engineering, fundamentally they don’t do anything different than other companies who use tech do. So don’t be discouraged, just keep applying and sharpen your interviewing skills!

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://edincitaku.com/blog/big-tech-hiring/

My Software Engineering internship at Amazon Luxembourg

Edin Citaku — Sat, 12 Mar 2022 00:00:00 GMT

My internship at Amazon in Luxembourg just finished. During my interview preparation I searched around for information about the Luxembourg office but couldn't really find anything. I’ll try to write down everything I have observed during my short stay of four months. Note that all opinions are my own and big companies vary wildly between orgs and teams so your mileage may vary.

Office and Perks

Let’s start with whats most easy to observe, the office. Even though most managers I’ve had contact with were totally ok with working from home, I’d encourage any intern to spend as much time in the office as possible! You will be able to socialize with other people in the office and generally learn more about how work is like in the company.

As mentioned above, my internship was in Luxembourg (city) the capital of Luxembourg, a small nation bordering Germany, France and Belgium. Luxembourg (city) is rather small with very international residents (over 50% of people come from abroad). Most people there speak French, but English works well, as well as the native language Luxembourgish which has similarities to German. I enjoyed the city but personally four months were enough for me. I felt like after that time I have seen most of Luxembourg and there wasn’t much left to discover. Luckily Luxembourg is placed right in the center of Europe so traveling was definitely an option especially for quick weekend trips to say Amsterdam or Brussels.

The office itself is placed in the business district Kirchberg. It’s right next to the KPMG building and other big banks headquarters. The office building my team was in (Lux 18) was your run of the mill corporate office. Each floor had an open space plan (ew), a kitchen and plenty of meeting rooms. As expected with Amazon there were almost no office perks. There were free fruits in the receptions and we got lunch vouchers worth around 9 euro for each working day. The intern salary was quite hefty, so I was easily able to afford going to restaurants during lunch breaks, as well as any outside activities I desired. One thing to note: The coffee in this particular Amazon office may have been the worst coffee I drank in my life, I don’t know how they did it but they failed at this one basic thing every developer needs.

The people

I got quite lucky with my team, the people were very nice and welcoming. I had a lot to learn from them, my team was full of experienced and knowledgeable engineers! The floor was filled with internationals from all over the world (not just Europe) though the interns were mostly from Europe. This created an atmosphere of open mindedness and led to many interesting conversations. I made many friends in the office and also traveled with them during my internship. Many of those friends will remain even after the internship ends, it was definitely an unforgettable experience! It kind of reminded me of Erasmus in this regard.

One thing I noticed during my short stay, and something that should not surprise you at such a big company: Politics plays quite a big role at Amazon, and it is very important that your manager likes you. I have seen people quit after they got really bad work assigned to them for months while others got promoted quite quickly getting very impactful work. The main difference I observed: Their manager liked them.

The project

At Amazon interns get a project assigned to them that they are supposed to deliver by the end of their internship. Those projects are not just toy projects but are supposed to go into production. So even as an intern you already get real responsibility. Quality and impact of those projects can vary quite a lot tho. Some interns I talked to (including the previous intern at my team) got projects that were very important to the team and got good guidance. I personally got a bit unlucky, the person who was supposed to create and supervise my project got switched right before my internship. Because of that my project had low impact overall and was barely thought out. So the beginning of my internship was mostly gathering requirements and just coming up with some concrete goals of my project. As my project modified a system that was not in production yet, I could never see the impact of my work. In general I would say my particular internship project was not that great but I got quite unlucky as most of the interns I talked to had much different experiences. The tech stack in my team was fun, everything was written in native AWS, something I was quite excited to learn about.

Conclusion

Overall I would definitely recommend an internship in the Amazon office. I made many great friendships that will remain even after I have left. Personally I would not return to Luxembourg if the Chance was given, as the city was just too small for my personal taste. It is quite easy to use the return offer from the Luxembourg office and just return to another office that is more suitable for you tho, I talked to hiring managers in both Berlin and London and the process of moving teams seemed quite easy and comfortable.

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://edincitaku.com/blog/amazon-internship/

Collection of tech blogs

Edin Citaku — Mon, 25 Oct 2021 00:00:00 GMT

Like the title says, an unordered list of tech blogs I follow. I'll try to keep it updated as time passes (might lead to some of them getting removed).

Paul Grahams website - As the founder of YCombinator he has some deep insights on tech and anything else really

Dan Luus website - A blog about hardware engineering and other topics, the tone can get quite sarcastic which I like

Increment - Tech blog published by Stripe

MB SX - The beautiful blog of Mathew Butterick, a great Computer Scientist and Typographer

O'Rilley Radar Trends - A broad list of current technological trends

Pragmatic Engineer - Hands down the best blog about the european tech market, also has some great content about leadership and careers in tech

Rands in Response - Mainly about leadership and management

Vitalik Buterins blog - Some great technical content about blockchain technologies

Fefe - This one is german but definitely worth a read if you understand the language

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://edincitaku.com/blog/tech-blogs/

A quick guide on how to improve your tech resume

Edin Citaku — Mon, 03 May 2021 00:00:00 GMT

While being mod in the CS Career Hub discord I have looked at and suggested improvements for many resumes over the time. I used the knowledge I gained there to land internships at companies like jetbrains or amazon. As of recentely quite a few of my friends and acquaintances have decided to do a career move into tech or are about to finish their degree in a tech related study and many of them are asking me about advice on how to improve their resume. Since I am becoming too lazy to reitarate the same points over and over, this blog post is supposed to be a first reference before asking me for advice. A good friend of mine, lets call him Noah, whom I advised about his resume was so nice to give me permission to use his resume as an example, you will see the first version and its improvements below.

The form

First things first, what resume template should you use? Honestly it doesnt matter much, I recommend some template from overleaf and I personally use this one. But feel free to use any resume template you seem fit. Also consider that some european companies, for instance in germany, do prefer a picture in the resume. The template should fullfill some basic things, as you will see below. Lets look at the first resume Noah send me in order to see what basic form a resume should have. I removed all the personal information, he was applying for internships in the field of embedded software engineering. Just looking at this resume, I immediately advised Noah to change their resume template. There are way too many headlines that dont provide any content, the headlines "position", "time period" and "field of work" all appear a total of four times in the whole resume. Additionally the actual content is too short, Noah had multible job experiences but the resume barely explains what they entailed. Here a quick summary when looking at the form of your own resume:

Avoid using any headlines like "time period", they waste space
Keep your paragraphs short, but not too short. A recruiter should be able to skimp over your resume quickly, but it should still hold all the necessary information

The content

So after looking at those superficial but still very important aspects of a resume, lets get to the meat, the actual content. So what is my friend doing wrong here? Aside of the resume barely having any content at all, the way they talk about their past experience is wrong. They just state their job description as if it was some to-do list. What they actually should be doing is to focus on their impact first. How did they make the company money? A job posting is about business after all, you work for a company to make them more money than they pay for you. Your resume should reflect that. How did you make your company money, and what impact did you have in this process? A common mistake I see in resume (admittedly not in this one) is that people talk about all their technical skills and how they implemented XY in framework Z. What they dont realize is that the tech is not that important, the actual impact the tech had is much much more important. Why did you implement XY? Did it make some process more efficient, did it solve some business critical problem? Focus on that! Of course having some metrics would make it even more impressive, though it is not always realistic to have those at hand (How much money did ur process save?, how many people use your software regularly?, etc.) And only after you have explained all the impact you had in your company and how you improved your company from the inside, only then you should talk about what specific technologies you used to achieve that.
This is of course talking about actual job experience. In side projects most of the time you will only be able to show your technical skills, which is fine too, but also the reason why side projects are worth much less than actual job experience. So as a summary on what one should pay attention when writing their resume:

Focus on the impact when talking about your past job experience only mention the technology after that
Try to add metrics when possible

The final version

So after considering all this feedback, this is Noahs resume in its final form Much better don't you think? If you happen to be one of my friends that is planning to ask me for resume advice, please follow the guide lines on this blog post first. If you don't do that, dont be suprised if you get a link to this post as an answer to your request for advice.

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://edincitaku.com/blog/tech-resume-guide/

Make your life easier with linked databases in notion

Edin Citaku — Fri, 04 Sep 2020 00:00:00 GMT

Notion is an amazing tool! I use it to organize almost all aspects of my life. It took me quite a while to find the perfect workflow for me, that's why I want to show one of the tricks that helped me get my Notion game to the next level!

Linked Databases

One thing that always irked me about Notion was that since I use different workspaces for different areas of my life (e.g work, studies, travel, etc.), I was forced to use different calendars aswell. This was particularly annoying when I for example wanted to keep track of different due dates of different classes in university. I had to use one calendar for each class and check each calendar frequently. This got quite annoying quite fast and I switched promptly back to google calendar for this kind of task. This was of course until I learned about the glorious linked databases! They solved my problem completely and I was able to share one calendar between multible pages! So how do linked databases work? Essentially its just one single database that can be used in different workspaces where changes in one workspace affect the other one. Creating a linked database is quite easy, just go to the page where you want to create one and type the command just like in the picture below. There you can choose which database you want to link to. Of course we have to have an original database first before we can link to it. When creating a linked database, you will notice that it is not formatted properly and does not use the full width of the page. In order to fix this you have to go to the settings on the top right and enable the option 'full-width'.

A simple example

So what now? We just created a linked database but how can we use this for our benefit? I will explain it in a simple example so you can immediately see how handy they are!

Let's say we have two kinds of information we want to track in a database assignments for university and their respective due date and additionally we want to keep track of our travel plans and their dates. We want both in one singular database. Let's see how to do it!

First we create a new workspace with a single database inside. This will be our main database that we link to from any other workplace. We choose the calendar view since we want to see all dates from any workspace we use it in. The next step is to create our first linked database. Let's begin with a one for university assignments. After creating it we need to add different fields to track our assignments. In this example we have one field for the due date, one field for the pdf and a checkbox to check whether we are done with the assignment. The trick now is to add a new field, we call it "Tag", as a "Select" property type. We use this field in order to filter our different linked databases. All of our entries in our university page will have a Tag named "University". This is how an an entry will look like with all its fields. After doing all this, there is one final step: We must create a new View and add a filter to this view in order to only show entries with the proper tag. Creating a new view is quite simple as you can see on the screenshot below. Just navigate to the view selector and then click on "Add a view". In our case we create a view with the name "University".

In order to add a filter to this view we navigate to the top right of the database and click on "Filter". Here we set the filter option to "Tag is University" as seen in the screenshot. Dont forget to again set the page to full width.

Here is how the final page could look like. Note that we can just hide the "Tag" field, since it doesn't give us any important information.

Adding a second linked database

Next we want to keep track of our travel plans. So let's do this! We again create a new page create a new linked database to our calendar. We continue doing the same steps as before! Instead of creating a Tag called "University" we create one called "Travel". Additionally, our travel plans need new fields. But that's no problem. If you create a new linked database you will see all the fields from the main database, some of which you dont need. We simply hide those fields we don't need and just create new ones.

The final result

Finally we are finished! If we go back to our original calendar page we can now see ALL the events from all databases that link to them! How neat is that?! I hope you can use this trick to great use just like I do every day :)

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://edincitaku.com/blog/notion-linked-databases/

Loading html files in React

Edin Citaku — Thu, 09 Apr 2020 00:00:00 GMT

Recently I solved an issue in the webapp I am writing for the Zukunftschreiben team. Since it was a fairly easy fix and I didn't immediately find a solution on google, I wanted to write down what I came up with. The problem was that the webapp needed a page that explained its privacy policy. This policy was a huge html file and I did not want hard code its content as a react component.

The Solution

The solution was quite simple, as it turns out there is a package named html-react-parser that can parse html as a string.
But first I needed to get the html file as a string from my component. The backend of the webapp was written in nodejs with express, so I decided to provide an API that returns the string as a file.

Here we load our file and create the function that returns the html file as a string

privacyPolicy.controller.js

const fs = require('fs');
var text = fs.readFileSync("./resources/privacy-policy.html",'utf8');

exports.getPrivacyPolicy = function (req,res) {
    res.json(text)
}

Here we provide the API that returns the file as a string

privacyPolicy.route.js

module.exports = privacyPolicyRoute;

function privacyPolicyRoute(){
    var privacyPolicyController = require('../controllers/privacyPolicy.controller');

    var router = require('express').Router();
    router.get("/privacy-policy", privacyPolicyController.getPrivacyPolicy)
    return router
}

Now its time to consume this API and display our privacy policy in our frontend.

PrivacyPolicy.js

class PrivacyPolicy extends Component {
    constructor(props){
        super(props)
        this.state = {data: '' }
    }

    componentDidMount() {
        fetch('${BACKEND_IP}:${BACKEND_PORT}/api/privacy-policy')
            .then((response) => response.json())
            .then((data) => {
                        this.setState({
                            data: data
                        })
            })
    }
    render() {
        return  parse(this.state.data);
    }
}

And thats it! We were able to display a really long static html without having to hardcode it as a component! :) I will provide a github repo soon where u can try it out yourself!

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://edincitaku.com/blog/loading-html-files-in-react/

My internship experience at Jetbrains

Edin Citaku — Sun, 29 Mar 2020 00:00:00 GMT

When I first got the callback from jetbrains for an interview I was ecstatic! To work at such an impactful company was a long dream of mine. Here in Germany the job market for IT professionals is very good but it seems like the far majority of companies are some kind of consultancies that dont have any interesting products themselves. Thus I was very excited to finally get a chance to write software that really makes a difference for people! Or so was my dream at least. Of course a junior like me wouldn't change the world with his beginner level coding skills but I had the chance to learn from the brightest people in the industry and I would say that is also worth something. As it turns out I was able to convince my interviewer and actually got an offer. I just recently finished my first 2 months at the company and think its a good point to recapitulate my experience.

The perks

The first thing that I noticed, and that most people working for such companies probably already take for granted, were the amazing perks. My office in particular offered free lunch, free breakfast twice a week, a massage room with free massages, a company gym with yoga aswell as dance classes.
I was completely blown away by the sheer amount of perks! Just having free snacks and drinks in the kitchen area completely blew me away. It resulted in me visiting the kitchen way too often also partly because I was practicing my cappuccino art using the professional espresso machine.

The environment

Of course all these perks I listed were incredible and I appreciated them a lot, but that was not the reason I wanted to intern at a company like Jetbrains. The real reason was that I wanted to learn as much as possible and work on interesting projects. In this regard I was satisfied, but regardless not everything went perfectly. Although my project was super interesting, my internship started at a bad time for the team and there was not a lot of supervision for me. Regardless I managed to teach myself a lot of the required concepts and actually finished my internship with a project me and my supervisor were satisfied with! My project was to rewrite the backend of the Toolbox-App. For this I worked with tools and frameworks like docker, kubernetes, ktor and kotlinx.serialization. I had to write a multithreaded asynchronous microservice and deploy it myself (Wew, thats a lot of buzzwords at once). It was certainly a challenging task, but also very exciting!
Sadly my internship started exactly as a new release of the Toolbox-App was about to be rolled out and the small team barely had time for me. I was in the Munich office with our team lead and still could ask him questions which was good but code reviews and a little more in-depth questions often had to wait.
This turned out fine in the end, as a developer you should be able to solve problems on your own after all.

Sadly after the internship ended, my supervisor was not able to give me a return offer for the same team, since he concluded that the whole rewriting of the backend is too much responsibility for a junior. At first I was sad about this, but he gave me a letter of recommendation and I actually got an offer for the Space Team. This project is in many aspects even more interesting and I am very excited to start soon :)

Conclusion

Regardless of some hurdles, I had an amazing experience! My team was very nice and approachable as well as everyone else in the company. Even though I could not continue working on my project, I was able to land a position at an at least equally exciting project.
The internship taught me a lot and was an experience I definitely would redo.

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://edincitaku.com/blog/jetbrains-internship/