The Best Programmers I Know
Tagged withdevculture
I have met a lot of developers in my life. Lately, I asked myself: “What does it take to be one of the best? What do they all have in common?”
In the hope that this will be an inspiration to someone out there, I wrote down the traits I observed in the most exceptional people in our craft. I wish I had that list when I was starting out. Had I followed this path, it would have saved me a lot of time.
Read the Reference
If there was one thing that I should have done as a young programmer, it would have been to read the reference of the thing I was using. I.e. read the Apache Webserver Documentation, the Python Standard Library, or the TOML spec.
Don’t go to Stack Overflow, don’t ask the LLM, don’t guess, just go straight to the source. Oftentimes, it’s surprisingly accessible and well-written.
Know Your Tools Really Well
Great devs understand the technologies they use on a fundamental level.
It’s one thing to be able to use a tool and a whole other thing to truly grok (understand) it. A mere user will fumble around, get confused easily, hold it wrong and not optimize the config.
An expert goes in (after reading the reference!) and sits down to write a config for the tool of which they understand every single line and can explain it to a colleague. That leaves no room for doubt!
To know a tool well, you have to know:
• its history: who created it? Why? To solve which problem?
• its present: who maintains it? Where do they work? On what?
• its limitations: when is the tool not a good fit? When does it break?
• its ecosystem: what libraries exist? Who uses it? What plugins?
For example, if you are a backend engineer and you make heavy use of Kafka, I expect you to know a lot about Kafka – not just things you read on Reddit. At least that’s what I expect if you want to be one of the best engineers.
Read The Error Message
As in Really Read the Error Message and Try to Understand What’s Written. Turns out, if you just sit and meditate about the error message, it starts to speak to you. The best engineers can infer a ton of information from very little context. Just by reading the error message, you can fix most of the problems on your own.
It also feels like a superpower if you help someone who doesn’t have that skill. Like “reading from a cup” or so.
Break Down Problems
Everyone gets stuck at times. The best know how to get unstuck. They simplify problems until they become digestible. That’s a hard skill to learn and requires a ton of experience. Alternatively, you just have awesome problem-solving skills, e.g., you’re clever. If not, you can train it, but there is no way around breaking down hard problems. There are problems in this world that are too hard to solve at once for anyone involved.
If you work as a professional developer, that is the bulk of the work you get paid to do: breaking down problems. If you do it right, it will feel like cheating: you just solve simple problems until you’re done.
Don’t Be Afraid To Get Your Hands Dirty
The best devs I know read a lot of code and they are not afraid to touch it. They never say “that’s not for me” or “I can’t help you here.” Instead, they just start and learn. Code is just code. They can just pick up any skill that is required with time and effort. Before you know it, they become the go-to person in the team for whatever they touched. Mostly because they were the only ones who were not afraid to touch it in the first place.
Always Help Others
A related point. Great engineers are in high demand and are always busy, but they always try to help. That’s because they are naturally curious and their supportive mind is what made them great engineers in the first place. It’s a sheer joy to have them on your team, because they are problem solvers.
Write
Most awesome engineers are well-spoken and happy to share knowledge.
The best have some outlet for their thoughts: blogs, talks, open source, or a combination of those.
I think there is a strong correlation between writing skills and programming.
Tagged withdevculture
I have met a lot of developers in my life. Lately, I asked myself: “What does it take to be one of the best? What do they all have in common?”
In the hope that this will be an inspiration to someone out there, I wrote down the traits I observed in the most exceptional people in our craft. I wish I had that list when I was starting out. Had I followed this path, it would have saved me a lot of time.
Read the Reference
If there was one thing that I should have done as a young programmer, it would have been to read the reference of the thing I was using. I.e. read the Apache Webserver Documentation, the Python Standard Library, or the TOML spec.
Don’t go to Stack Overflow, don’t ask the LLM, don’t guess, just go straight to the source. Oftentimes, it’s surprisingly accessible and well-written.
Know Your Tools Really Well
Great devs understand the technologies they use on a fundamental level.
It’s one thing to be able to use a tool and a whole other thing to truly grok (understand) it. A mere user will fumble around, get confused easily, hold it wrong and not optimize the config.
An expert goes in (after reading the reference!) and sits down to write a config for the tool of which they understand every single line and can explain it to a colleague. That leaves no room for doubt!
To know a tool well, you have to know:
• its history: who created it? Why? To solve which problem?
• its present: who maintains it? Where do they work? On what?
• its limitations: when is the tool not a good fit? When does it break?
• its ecosystem: what libraries exist? Who uses it? What plugins?
For example, if you are a backend engineer and you make heavy use of Kafka, I expect you to know a lot about Kafka – not just things you read on Reddit. At least that’s what I expect if you want to be one of the best engineers.
Read The Error Message
As in Really Read the Error Message and Try to Understand What’s Written. Turns out, if you just sit and meditate about the error message, it starts to speak to you. The best engineers can infer a ton of information from very little context. Just by reading the error message, you can fix most of the problems on your own.
It also feels like a superpower if you help someone who doesn’t have that skill. Like “reading from a cup” or so.
Break Down Problems
Everyone gets stuck at times. The best know how to get unstuck. They simplify problems until they become digestible. That’s a hard skill to learn and requires a ton of experience. Alternatively, you just have awesome problem-solving skills, e.g., you’re clever. If not, you can train it, but there is no way around breaking down hard problems. There are problems in this world that are too hard to solve at once for anyone involved.
If you work as a professional developer, that is the bulk of the work you get paid to do: breaking down problems. If you do it right, it will feel like cheating: you just solve simple problems until you’re done.
Don’t Be Afraid To Get Your Hands Dirty
The best devs I know read a lot of code and they are not afraid to touch it. They never say “that’s not for me” or “I can’t help you here.” Instead, they just start and learn. Code is just code. They can just pick up any skill that is required with time and effort. Before you know it, they become the go-to person in the team for whatever they touched. Mostly because they were the only ones who were not afraid to touch it in the first place.
Always Help Others
A related point. Great engineers are in high demand and are always busy, but they always try to help. That’s because they are naturally curious and their supportive mind is what made them great engineers in the first place. It’s a sheer joy to have them on your team, because they are problem solvers.
Write
Most awesome engineers are well-spoken and happy to share knowledge.
The best have some outlet for their thoughts: blogs, talks, open source, or a combination of those.
I think there is a strong correlation between writing skills and programming.
endler.dev
All 40 dev posts | Matthias Endler
Personal website of Matthias Endler, a Software Engineer interested in low-level programming and Backend development. Rust, Go
All the best engineers I know have good command over at least one human language – often more. Mastering the way you write is mastering the way you think and vice versa. A person’s writing style says so much about the way they think. If it’s confusing and lacks structure, their coding style will be too. If it’s concise, educational, well-structured, and witty at times, their code will be too.
Excellent programmers find joy in playing with words.
Never Stop Learning
Some of the best devs I know are 60+ years old. They can run circles around me. Part of the reason is that they keep learning. If there is a new tool they haven’t tried or a language they like, they will learn it. This way, they always stay on top of things without much effort.
That is not to be taken for granted: a lot of people stop learning really quickly after they graduate from University or start in their first job. They get stuck thinking that what they got taught in school is the “right” way to do things. Everything new is bad and not worth their time. So there are 25-year-olds who are “mentally retired” and 68-year-olds who are still fresh in their mind. I try to one day belong to the latter group.
Somewhat related, the best engineers don’t follow trends, but they will always carefully evaluate the benefits of new technology. If they dismiss it, they can tell you exactly why, when the technology would be a good choice, and what the alternatives are.
Status Doesn’t Matter
The best devs talk to principal engineers and junior devs alike. There is no hierarchy. They try to learn from everyone, young and old. The newcomers often aren’t entrenched in office politics yet and still have a fresh mind. They don’t know why things are hard and so they propose creative solutions. Maybe the obstacles from the past are no more, which makes these people a great source of inspiration.
Build a Reputation
You can be a solid engineer if you do good work, but you can only be one of the best if you’re known for your good work; at least within a (larger) organization.
There are many ways to build a reputation for yourself:
• You built and shipped a critical service for a (larger) org.
• You wrote a famous tool
• You contribute to a popular open source tool
• You wrote a book that is often mentioned
Why do I think it is important to be known for your work? All of the above are ways to extend your radius of impact in the community. Famous developers impact way more people than non-famous developers. There’s only so much code you can write. If you want to “scale” your impact, you have to become a thought leader.
Building a reputation is a long-term goal. It doesn’t happen overnight, nor does it have to. And it won’t happen by accident. You show up every day and do the work. Over time, the work will speak for itself. More people will trust you and your work and they will want to work with you. You will work on more prestigious projects and the circle will grow.
I once heard about this idea that your latest work should overshadow everything you did before. That’s a good sign that you are on the right track.
Have Patience
You need patience with computers and humans. Especially with yourself. Not everything will work right away and people take time to learn. It’s not that people around you are stupid; they just have incomplete information. Without patience, it will feel like the world is against you and everyone around you is just incompetent. That’s a miserable place to be. You’re too clever for your own good.
To be one of the best, you need an incredible amount of patience, focus, and dedication. You can’t afford to get distracted easily if you want to solve hard problems. You have to return to the keyboard to get over it. You have to put in the work to push a project over the finishing line. And if you can do so while not being an arrogant prick, that’s even better. That’s what separates the best from the rest.
Never Blame the Computer
Most developers blame the software, other people, their dog, or the weather for flaky, seemingly “random” bugs.
The best devs don’t.
Excellent programmers find joy in playing with words.
Never Stop Learning
Some of the best devs I know are 60+ years old. They can run circles around me. Part of the reason is that they keep learning. If there is a new tool they haven’t tried or a language they like, they will learn it. This way, they always stay on top of things without much effort.
That is not to be taken for granted: a lot of people stop learning really quickly after they graduate from University or start in their first job. They get stuck thinking that what they got taught in school is the “right” way to do things. Everything new is bad and not worth their time. So there are 25-year-olds who are “mentally retired” and 68-year-olds who are still fresh in their mind. I try to one day belong to the latter group.
Somewhat related, the best engineers don’t follow trends, but they will always carefully evaluate the benefits of new technology. If they dismiss it, they can tell you exactly why, when the technology would be a good choice, and what the alternatives are.
Status Doesn’t Matter
The best devs talk to principal engineers and junior devs alike. There is no hierarchy. They try to learn from everyone, young and old. The newcomers often aren’t entrenched in office politics yet and still have a fresh mind. They don’t know why things are hard and so they propose creative solutions. Maybe the obstacles from the past are no more, which makes these people a great source of inspiration.
Build a Reputation
You can be a solid engineer if you do good work, but you can only be one of the best if you’re known for your good work; at least within a (larger) organization.
There are many ways to build a reputation for yourself:
• You built and shipped a critical service for a (larger) org.
• You wrote a famous tool
• You contribute to a popular open source tool
• You wrote a book that is often mentioned
Why do I think it is important to be known for your work? All of the above are ways to extend your radius of impact in the community. Famous developers impact way more people than non-famous developers. There’s only so much code you can write. If you want to “scale” your impact, you have to become a thought leader.
Building a reputation is a long-term goal. It doesn’t happen overnight, nor does it have to. And it won’t happen by accident. You show up every day and do the work. Over time, the work will speak for itself. More people will trust you and your work and they will want to work with you. You will work on more prestigious projects and the circle will grow.
I once heard about this idea that your latest work should overshadow everything you did before. That’s a good sign that you are on the right track.
Have Patience
You need patience with computers and humans. Especially with yourself. Not everything will work right away and people take time to learn. It’s not that people around you are stupid; they just have incomplete information. Without patience, it will feel like the world is against you and everyone around you is just incompetent. That’s a miserable place to be. You’re too clever for your own good.
To be one of the best, you need an incredible amount of patience, focus, and dedication. You can’t afford to get distracted easily if you want to solve hard problems. You have to return to the keyboard to get over it. You have to put in the work to push a project over the finishing line. And if you can do so while not being an arrogant prick, that’s even better. That’s what separates the best from the rest.
Never Blame the Computer
Most developers blame the software, other people, their dog, or the weather for flaky, seemingly “random” bugs.
The best devs don’t.
endler.dev
All 40 dev posts | Matthias Endler
Personal website of Matthias Endler, a Software Engineer interested in low-level programming and Backend development. Rust, Go
No matter how erratic or mischievous the behavior of a computer seems, there is always a logical explanation: you just haven’t found it yet!
The best keep digging until they find the reason. They might not find the reason immediately, they might never find it, but they never blame external circumstances.
With this attitude, they are able to make incredible progress and learn things that others fail to. When you mistake bugs for incomprehensible magic, magic is what it will always be.
Don’t Be Afraid to Say “I Don’t Know”
In job interviews, I pushed candidates hard to at least say “I don’t know” once. The reason was not that I wanted to look superior (although some people certainly had that impression). No, I wanted to reach the boundary of their knowledge. I wanted to stand with them on the edge of what they thought they knew. Often, I myself didn’t know the answer. And to be honest, I didn’t care about the answer. What I cared about was when people bullshitted their way through the interview.
The best candidates said “Huh, I don’t know, but that’s an interesting question! If I had to guess, I would say…” and then they would proceed to deduce the answer. That’s a sign that you have the potential to be a great engineer.
If you are afraid to say “I don’t know”, you come from a position of hubris or defensiveness. I don’t like bullshitters on my team. Better to acknowledge that you can’t know everything. Once you accept that, you allow yourself to learn. “The important thing is that you don’t stop asking questions,” said Albert Einstein.
Don’t Guess
“In the Face of Ambiguity, Refuse the Temptation to Guess” That is one of my favorite rules in PEP 20 – The Zen of Python.
And it’s so, so tempting to guess!
I’ve been there many times and I failed with my own ambition.
When you guess, two things can happen:
• In the best case you’re wrong and your incorrect assumptions lead to a bug.
• In the worst case you are right… and you’ll never stop and second guess yourself. You build up your mental model based on the wrong assumptions. This can haunt you for a long time.
Again, resist the urge to guess. Ask questions, read the reference, use a debugger, be thorough. Do what it takes to get the answer.
Keep It Simple
Clever engineers write clever code. Exceptional engineers write simple code.
That’s because most of the time, simple is enough. And simple is more maintainable than complex. Sometimes it does matter to get things right, but knowing the difference is what separates the best from the rest.
You can achieve a whole lot by keeping it simple. Focus on the right things.
Final Thoughts
The above is not a checklist or a competition; and great engineering is not a race.
Just don’t trick yourself into thinking that you can skip the hard work. There is no shortcut. Good luck with your journey.
The best keep digging until they find the reason. They might not find the reason immediately, they might never find it, but they never blame external circumstances.
With this attitude, they are able to make incredible progress and learn things that others fail to. When you mistake bugs for incomprehensible magic, magic is what it will always be.
Don’t Be Afraid to Say “I Don’t Know”
In job interviews, I pushed candidates hard to at least say “I don’t know” once. The reason was not that I wanted to look superior (although some people certainly had that impression). No, I wanted to reach the boundary of their knowledge. I wanted to stand with them on the edge of what they thought they knew. Often, I myself didn’t know the answer. And to be honest, I didn’t care about the answer. What I cared about was when people bullshitted their way through the interview.
The best candidates said “Huh, I don’t know, but that’s an interesting question! If I had to guess, I would say…” and then they would proceed to deduce the answer. That’s a sign that you have the potential to be a great engineer.
If you are afraid to say “I don’t know”, you come from a position of hubris or defensiveness. I don’t like bullshitters on my team. Better to acknowledge that you can’t know everything. Once you accept that, you allow yourself to learn. “The important thing is that you don’t stop asking questions,” said Albert Einstein.
Don’t Guess
“In the Face of Ambiguity, Refuse the Temptation to Guess” That is one of my favorite rules in PEP 20 – The Zen of Python.
And it’s so, so tempting to guess!
I’ve been there many times and I failed with my own ambition.
When you guess, two things can happen:
• In the best case you’re wrong and your incorrect assumptions lead to a bug.
• In the worst case you are right… and you’ll never stop and second guess yourself. You build up your mental model based on the wrong assumptions. This can haunt you for a long time.
Again, resist the urge to guess. Ask questions, read the reference, use a debugger, be thorough. Do what it takes to get the answer.
Keep It Simple
Clever engineers write clever code. Exceptional engineers write simple code.
That’s because most of the time, simple is enough. And simple is more maintainable than complex. Sometimes it does matter to get things right, but knowing the difference is what separates the best from the rest.
You can achieve a whole lot by keeping it simple. Focus on the right things.
Final Thoughts
The above is not a checklist or a competition; and great engineering is not a race.
Just don’t trick yourself into thinking that you can skip the hard work. There is no shortcut. Good luck with your journey.
endler.dev
All 40 dev posts | Matthias Endler
Personal website of Matthias Endler, a Software Engineer interested in low-level programming and Backend development. Rust, Go
Forwarded from Asadbek Noyibjonov
A Selection of YC Interviews with First Employees at Billion-Dollar Startups
Employee #1: Yahoo
Employee #1: Apple
Employee #1: Reddit
Employee #1 Airbnb
Employee #1: Tumblr
Employee #1: Amazon
Engineer #1: Dropbox
Engineer #1 (YC W15): ReadMe
Engineer #2 at ClearBrain (YC 18): Cynthia Rogers
@asadbek
Employee #1: Yahoo
Employee #1: Apple
Employee #1: Reddit
Employee #1 Airbnb
Employee #1: Tumblr
Employee #1: Amazon
Engineer #1: Dropbox
Engineer #1 (YC W15): ReadMe
Engineer #2 at ClearBrain (YC 18): Cynthia Rogers
@asadbek
Y Combinator
Employee #1: Yahoo | Y Combinator
Employee #1 is a series of interviews focused on sharing the often untold
stories of early employees at tech companies.
Tim was the first employee at Yahoo, its Chief Product Officer for eight years,
and is now a partner at YC, so we thought it would be…
stories of early employees at tech companies.
Tim was the first employee at Yahoo, its Chief Product Officer for eight years,
and is now a partner at YC, so we thought it would be…
Forwarded from Otabek Kholmirzaev 💻
If you're a Software Engineer and you're targeting TOP JOBS, your CV should be a one-pager.
Here's a framework to build a powerful CV that fits in one page:
1. Choose a minimalistic template in Latex/Gdocs.
2. Have an ideal role in mind that you're targeting with your CV.
3. If you have more than an ideal role in mind, make one CV for each.
4. Gather the best data from your history that shows why you're a great fit.
5. Prioritize and give more space in the CV to the most recent and more "fitting the ideal role" work experiences you have.
Throughout the CV: show, don't tell.
Meaning, show you're good at something by displaying real world scenarios where you've delivered impact thanks to such skills.
Be as specific as possible, using the "Accomplished [X] as measured by [Y], by doing [Z]" framework:
❌ Built a new feature in a web app in a team of 5 developers.
✅ Enabled a 10x+ latency reduction in DB health monitoring by refactoring a Python script to retrieve data from object storage instead of querying various APIs.
Maintenance:
1. Always keep a "brag doc" where you note down the good things you're achieving at your current job.
2. Regularly update your CV with the achievements from your brag doc.
Remove the fluff:
❌ "proactive, independent developer with great communication and leadership skills"
❌ "speak Mandarin, Spanish and French"
❌ photo
Technologies, frameworks and programming languages:
❌ Have a big CV section where you include all the tech you ever used
✅ Keep such a section small, listing only your top skills. Mention the technologies you used throughout your CV in your work experience bullet points.
These are just some tips.
Full guide is here: LINK
Author: Nicola Amadio
Here's a framework to build a powerful CV that fits in one page:
1. Choose a minimalistic template in Latex/Gdocs.
2. Have an ideal role in mind that you're targeting with your CV.
3. If you have more than an ideal role in mind, make one CV for each.
4. Gather the best data from your history that shows why you're a great fit.
5. Prioritize and give more space in the CV to the most recent and more "fitting the ideal role" work experiences you have.
Throughout the CV: show, don't tell.
Meaning, show you're good at something by displaying real world scenarios where you've delivered impact thanks to such skills.
Be as specific as possible, using the "Accomplished [X] as measured by [Y], by doing [Z]" framework:
❌ Built a new feature in a web app in a team of 5 developers.
✅ Enabled a 10x+ latency reduction in DB health monitoring by refactoring a Python script to retrieve data from object storage instead of querying various APIs.
Maintenance:
1. Always keep a "brag doc" where you note down the good things you're achieving at your current job.
2. Regularly update your CV with the achievements from your brag doc.
Remove the fluff:
❌ "proactive, independent developer with great communication and leadership skills"
❌ "speak Mandarin, Spanish and French"
❌ photo
Technologies, frameworks and programming languages:
❌ Have a big CV section where you include all the tech you ever used
✅ Keep such a section small, listing only your top skills. Mention the technologies you used throughout your CV in your work experience bullet points.
These are just some tips.
Full guide is here: LINK
Author: Nicola Amadio
Node.js
* https://nodejs.org/en/learn/getting-started/introduction-to-nodejs
* https://www.youtube.com/watch?v=f2EqECiTBL8&ab_channel=DaveGray
JS
* https://nodejs.org/en/learn/getting-started/how-much-javascript-do-you-need-to-know-to-use-nodejs
OS
* https://www.youtube.com/watch?v=4rLW7zg21gI&ab_channel=ByteByteGo
* https://www.youtube.com/watch?v=vLwMl9qK4T8&ab_channel=VisualComputerScience
* https://www.youtube.com/watch?v=5sw9XJokAqw&ab_channel=CoreDumped
* https://www.youtube.com/watch?v=9GDX-IyZ_C8&list=PLIbUZ3URbL0Gqn0q2-MYJd-3nv6zw7GCQ&ab_channel=BrianWilla
* https://nodejs.org/en/learn/getting-started/introduction-to-nodejs
* https://www.youtube.com/watch?v=f2EqECiTBL8&ab_channel=DaveGray
JS
* https://nodejs.org/en/learn/getting-started/how-much-javascript-do-you-need-to-know-to-use-nodejs
OS
* https://www.youtube.com/watch?v=4rLW7zg21gI&ab_channel=ByteByteGo
* https://www.youtube.com/watch?v=vLwMl9qK4T8&ab_channel=VisualComputerScience
* https://www.youtube.com/watch?v=5sw9XJokAqw&ab_channel=CoreDumped
* https://www.youtube.com/watch?v=9GDX-IyZ_C8&list=PLIbUZ3URbL0Gqn0q2-MYJd-3nv6zw7GCQ&ab_channel=BrianWilla
nodejs.org
Introduction to Node.js | Node.js Learn
Node.js® is a free, open-source, cross-platform JavaScript runtime environment that lets developers create servers, web apps, command line tools and scripts.
601 real-world gen AI use cases from the world's leading organizations
https://cloud.google.com/transform/101-real-world-generative-ai-use-cases-from-industry-leaders
https://cloud.google.com/transform/101-real-world-generative-ai-use-cases-from-industry-leaders
Google Cloud Blog
Real-world gen AI use cases from the world's leading organizations | Google Cloud Blog
Gen AI is everywhere, as top companies, governments, researchers, and startups showcase how they're already using Google's AI solutions to enhance their work.
SOLID -
In software programming, SOLID is a mnemonic acronym for five design principles intended to make object-oriented designs more understandable, flexible, and maintainable. Although the SOLID principles apply to any object-oriented design, they can also form a core philosophy for methodologies such as agile development or adaptive software development.
Principles
1. Single responsibility principle - every class should have only one responsibility
2. Open–closed principle - software entities ... should be open for extension, but closed for modification.
3. Liskov substitution principle - functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it
4. Interface segregation principle - clients should not be forced to depend upon interfaces that they do not use
5. Dependency inversion principle - states to depend upon abstractions, [not] concretes
In software programming, SOLID is a mnemonic acronym for five design principles intended to make object-oriented designs more understandable, flexible, and maintainable. Although the SOLID principles apply to any object-oriented design, they can also form a core philosophy for methodologies such as agile development or adaptive software development.
Principles
1. Single responsibility principle - every class should have only one responsibility
2. Open–closed principle - software entities ... should be open for extension, but closed for modification.
3. Liskov substitution principle - functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it
4. Interface segregation principle - clients should not be forced to depend upon interfaces that they do not use
5. Dependency inversion principle - states to depend upon abstractions, [not] concretes
Carl Zeiss Interview Experience - FullStack Intern
January 01, 2021
Carl Zeiss came to IIIT Naya Raipur with 3 positions
FullStack Developer
Machine Learning
Python/C++
Eligibility criteria: 80%+ in 10th and 12th with 7+ CGPA in B.Tech.
I applied for the FullStack role as this is my strong point though I was tempted to go for Python/C++ because I love python but didn't because I don't know C about C++ and felt like I would grow more in the FullStack role.
Since the company came in mid-late November only 19 people in total applied and they all were asked to give the First Round.
First Round - Aptitude Test
It consisted of around 40-45 questions to be solved in 45 Minutes on the Pariksha Platform. You might need some practice beforehand to increase your speed. Almost everyone cleared this round and we were asked to attend the Placement Talk followed by a Technical Test.
Second Round - Placement Talk + Technical Test (Coding + MCQs)
We were told almost everything one could ask to know about the company, they showed the various fields the company works and various achievements of the company like
Images were taken on the moon during Apollo 11 mission used lenses made by Carl Zeiss.
Developing lens to be used by researchers and doctors to do very critical work in their fields
Working on Silicon Technology with companies like Apple
...etc, etc
We were supposed to start the test within 30 minutes after the Placement talk ended. It was conducted on Hackerearch with no camera and no full-screen mode.
Two hours long, it contained 40 MCQ questions based on OS, DBMS, and position specific questions (FullStack and development for me) alongside 3 coding questions of 20, 20, and 50 marks each. Most of the MCQs could be answered in 10-15 seconds if you knew the facts, there wasn't much heavy calculation to be done. Even after having 90 minutes for 3 coding questions, I was only able to partially solve the 2nd one and but completed the 3rd one fully because it was a standard question which I had solved previously. The other two of 20 points were a bit more mathematical (my weakness :p) hence they ended up eating up a lot of my time with just a partial solution.
Luckily the situation was the same with everyone else which is why I was able to move into the next round. A total of 16 people out of 19 were selected for the next round (Quite a good amount).
Third Round: Technical Interview
The technical Interview was taken by two members (say A and B, A was junior to B), though most of the questions were asked by the A and B was just there probably analyzing my answers and behavior.
They outright asked me what things I know so I told them JavaScript, Node, and Python (+ Django). They asked me one simple coding question, if you are close or above to 1700 in CodeChef then you don't need to worry in this section. The part which had me sweating is when they started asking a specific question regarding JavaScript like
How does JS support asynchronous nature being a single-threaded language
Difference between == and ===
How JS stores data and datatypes
and more which I can't remember :p
I was able to answer most questions with confidence and ended the interview by asking some questions from my side about the workstyle, technologies used, and how work from home is affecting them
Fourth Round: HR Interview
It was supposed to happen at least an hour after my third interview ended so I left my laptop and phone to take a stroll and coming back after 15 minutes I see 3 missed calls and a message from HR to call him back. So I did and he asked if we could do the HR round in 5 minutes and we jumped on to a video call.
It was mostly just a confirmation call that yes you have been selected and some random question here and there about my family and how many brothers and sisters I have. After which it was mostly me asking questions and discussing how the internship will take place, their views on PPO opportunity and If we will be given any task or things to learn before the joining date (& more similar questions).
January 01, 2021
Carl Zeiss came to IIIT Naya Raipur with 3 positions
FullStack Developer
Machine Learning
Python/C++
Eligibility criteria: 80%+ in 10th and 12th with 7+ CGPA in B.Tech.
I applied for the FullStack role as this is my strong point though I was tempted to go for Python/C++ because I love python but didn't because I don't know C about C++ and felt like I would grow more in the FullStack role.
Since the company came in mid-late November only 19 people in total applied and they all were asked to give the First Round.
First Round - Aptitude Test
It consisted of around 40-45 questions to be solved in 45 Minutes on the Pariksha Platform. You might need some practice beforehand to increase your speed. Almost everyone cleared this round and we were asked to attend the Placement Talk followed by a Technical Test.
Second Round - Placement Talk + Technical Test (Coding + MCQs)
We were told almost everything one could ask to know about the company, they showed the various fields the company works and various achievements of the company like
Images were taken on the moon during Apollo 11 mission used lenses made by Carl Zeiss.
Developing lens to be used by researchers and doctors to do very critical work in their fields
Working on Silicon Technology with companies like Apple
...etc, etc
We were supposed to start the test within 30 minutes after the Placement talk ended. It was conducted on Hackerearch with no camera and no full-screen mode.
Two hours long, it contained 40 MCQ questions based on OS, DBMS, and position specific questions (FullStack and development for me) alongside 3 coding questions of 20, 20, and 50 marks each. Most of the MCQs could be answered in 10-15 seconds if you knew the facts, there wasn't much heavy calculation to be done. Even after having 90 minutes for 3 coding questions, I was only able to partially solve the 2nd one and but completed the 3rd one fully because it was a standard question which I had solved previously. The other two of 20 points were a bit more mathematical (my weakness :p) hence they ended up eating up a lot of my time with just a partial solution.
Luckily the situation was the same with everyone else which is why I was able to move into the next round. A total of 16 people out of 19 were selected for the next round (Quite a good amount).
Third Round: Technical Interview
The technical Interview was taken by two members (say A and B, A was junior to B), though most of the questions were asked by the A and B was just there probably analyzing my answers and behavior.
They outright asked me what things I know so I told them JavaScript, Node, and Python (+ Django). They asked me one simple coding question, if you are close or above to 1700 in CodeChef then you don't need to worry in this section. The part which had me sweating is when they started asking a specific question regarding JavaScript like
How does JS support asynchronous nature being a single-threaded language
Difference between == and ===
How JS stores data and datatypes
and more which I can't remember :p
I was able to answer most questions with confidence and ended the interview by asking some questions from my side about the workstyle, technologies used, and how work from home is affecting them
Fourth Round: HR Interview
It was supposed to happen at least an hour after my third interview ended so I left my laptop and phone to take a stroll and coming back after 15 minutes I see 3 missed calls and a message from HR to call him back. So I did and he asked if we could do the HR round in 5 minutes and we jumped on to a video call.
It was mostly just a confirmation call that yes you have been selected and some random question here and there about my family and how many brothers and sisters I have. After which it was mostly me asking questions and discussing how the internship will take place, their views on PPO opportunity and If we will be given any task or things to learn before the joining date (& more similar questions).