5 ms·

Being on other side of the interviews like this , trust me most interviewers know that . The logic being if you can pick up leetcode in few months you can pick

Being on other side of the interviews like this , trust me most interviewers know that . The logic being if you can pick up leetcode in few months you can pick up most things on the job fast. Understand that interviewers are first and foremost are looking for ability to learn and understand complex topics , it is not all that important which specific topic it is. nobody really knows what you will be working on by the time you join or 6months later , even if the interviewer wanted to it he is not able to ask the right questions beyond the basgics. Also university education in IT is woefully behind the industry. Functional programming, or dev tooling is barely covered in most places . Maybe they teach MVC a bit , I don’t expect most kids to understand CQRS or event programming . Similarly I would be pleasantly surprised if you have setup a simple app, I wouldn’t expect you to know nuances between different cloud vendors , or have experience with zipkin,istio, helm , grafana or similar tools or be able to grok a explain analyse and fine tune a 500GB dB. it is unlikely a fresh grad has production experience at best they may already know some frameworks and maybe developed a few small apps of their own, however working in large project with 1m+ lines and complex tooling is a skill that takes time to learn , there is a lot of gotchas in every area you will learn only when you see it . So all I am left with is, does this candidate know the basics , can he understand and learn fast . That is why these questions make sense for junior developers and never for senior devs.

melvinroest 6y ago
N = 1 but here we go. Let's look at the CS bachelor/master offered at the Vrije Universiteit Amsterdam [0]. The truth is probably somewhere in the middle and I understand that university programs are heterogeneous. So let's look at my university experience and use your post as a checklist, for funzies! :D Functional programming: covered Dev tooling: covered to some extent through electives where you'd teach it yourself (I also call it the Magical Course) [1] MVC: Magical Course event programming: never heard of it :) Reading the wikipedia page, the following courses will probably help in aiding understanding: + Hardware interrupts: kernel programming, binary and malware analysis and hardware security + User events (e.g. via JavaScript): The Magical Course and Computer Graphics CQRS: never heard of it :D And while I get the need when reading the article from Martin Fowler, I do not have a backlog of knowledge where I've encountered this before. Simple app: computer graphics, the Magical Course, Distributed Multimedia Systems (the practical assignments were in HTML5/JS). Cloud vendors: nope, I learned about that when I started teaching for a coding school zipkin, istio, helm, grafana: never heard of it :D be able to grok a explain analyse and fine tune a 500GB dB: No. We did learn SQL though and how to model relationships with UML and entity diagrams. it is unlikely a fresh grad has production experience: I do, because my thesis was harder than whatever production experience I was acquiring. Going to work as a web dev and web dev instructor was my form of fleeing for my much more difficult thesis. Also, computer graphics taught me volume as my OpenGL engine was 10K lines of code. The Magical Course allowed me to produce an app that I sold for 2000 euro's. Diving into a 1 million line codebase: We did that way too briefly (the Linux OS) for just 15 minutes, unfortunately. The startups I've been at had about 100K lines of code for their complete product. In other words, a lot of companies don't have a 1M+ codebase. Anyways, when you have someone from the Vrije Universiteit Amsterdam, you can have some idea of what they do learn ;-) [0] My knowledge of the curriculum is a bit stale, so it could've changed. [1] Whenever I use this sentence, I happen to refer to one course where the teacher decided not to really teach but coach and the goal was to teach yourself whatever you wanted. I happen to have learned a lot of practical stuff that otherwise wouldn't be covered. So did many others. What did I specifically do? I created an iOS app by following Hegarthy's Stanford-based iOS course online ( https://www.youtube.com/watch?v=gI3pz7eFgfo https://www.youtube.com/watch?v=gI3pz7eFgfo ).
- manquer 6y ago
  Firstly, thank you for sharing :) Yours is above the par learning experience than most fresh graduates I have encountered. When we hire in Eupope I would very interested to try and convince some of your juniors to join! > The startups I've been at had about 100K lines of code for their complete product. In other words, a lot of companies don't have a 1M+ codebase. Most large companies who are also large employers sadly do have such complexity. In a startup it may not a single repo at 100k+, however overall 100+k lines for the product is very low for Saas product over two-three years it easily goes beyond. My N=1 in a startup: we went from one monolithic 300-400k+ L repo to a ton of repos with each one perhaps < 100k . Traditional large codebases are not designed for releasing 4 times a day, even builds can take a lot of time [1], Smaller repos does not mean complexity goes away, developers need to still document, read and understand how it works. It applies also when you use libraries or third party services, while number of lines have become less, you need a lot more domain understanding. > be able to grok a explain analyse and fine tune a 500GB dB: No. We did learn SQL though and how to model relationships with UML and entity diagrams. The reality is that most jobs are not developing new apps from scratch, it is lot more likely to work on older codebase that has its fair share of kinks. That means I am going to throw you deep end into large sized DB. Schema perhaps has evolved over time as product vision keeps changing, a dozen 'architects' have messed about it. In a typical job, you will be fixing bugs more than developing new features, handling tech debt - it doesn't matter stupid mistakes were made before, you still to work with/around those mistakes as someone will have to work with yours. Even on theoretical level NoSQL is not well taught in universities. Purpose built dbs for graphing, Time Series, KV , document DBs, search indices are all important to really understand. Each has solutions to specific problem set and come with their limitations. In a typical basic storage stack there is going to probably be something like Redis|PostgreSQL|ElasticSearch: all of them solve more than one type of storage problem in more than one way. This isn't to say the that is it all bad. Education is evolving , universities are more open to longer internships, while most don't think software engineering (not CS) should be treated as vocational course, there are positive trends. Alternative learning avenues have opened up like Coding Schools and Bootcamps who do lot better job at focusing on job skills. [1] https://news.ycombinator.com/item?id=18442941 https://news.ycombinator.com/item?id=18442941 This is infamous post, and of course the extreme example, but you get the idea.

melvinroest 6y ago

N = 1 but here we go. Let's look at the CS bachelor/master offered at the Vrije Universiteit Amsterdam [0]. The truth is probably somewhere in the middle and I understand that university programs are heterogeneous. So let's look at my university experience and use your post as a checklist, for funzies! :D Functional programming: covered Dev tooling: covered to some extent through electives where you'd teach it yourself (I also call it the Magical Course) [1] MVC: Magical Course event programming: never heard of it :) Reading the wikipedia page, the following courses will probably help in aiding understanding: + Hardware interrupts: kernel programming, binary and malware analysis and hardware security + User events (e.g. via JavaScript): The Magical Course and Computer Graphics CQRS: never heard of it :D And while I get the need when reading the article from Martin Fowler, I do not have a backlog of knowledge where I've encountered this before. Simple app: computer graphics, the Magical Course, Distributed Multimedia Systems (the practical assignments were in HTML5/JS). Cloud vendors: nope, I learned about that when I started teaching for a coding school zipkin, istio, helm, grafana: never heard of it :D be able to grok a explain analyse and fine tune a 500GB dB: No. We did learn SQL though and how to model relationships with UML and entity diagrams. it is unlikely a fresh grad has production experience: I do, because my thesis was harder than whatever production experience I was acquiring. Going to work as a web dev and web dev instructor was my form of fleeing for my much more difficult thesis. Also, computer graphics taught me volume as my OpenGL engine was 10K lines of code. The Magical Course allowed me to produce an app that I sold for 2000 euro's. Diving into a 1 million line codebase: We did that way too briefly (the Linux OS) for just 15 minutes, unfortunately. The startups I've been at had about 100K lines of code for their complete product. In other words, a lot of companies don't have a 1M+ codebase. Anyways, when you have someone from the Vrije Universiteit Amsterdam, you can have some idea of what they do learn ;-) [0] My knowledge of the curriculum is a bit stale, so it could've changed. [1] Whenever I use this sentence, I happen to refer to one course where the teacher decided not to really teach but coach and the goal was to teach yourself whatever you wanted. I happen to have learned a lot of practical stuff that otherwise wouldn't be covered. So did many others. What did I specifically do? I created an iOS app by following Hegarthy's Stanford-based iOS course online ( https://www.youtube.com/watch?v=gI3pz7eFgfo https://www.youtube.com/watch?v=gI3pz7eFgfo ).

manquer 6y ago
Firstly, thank you for sharing :) Yours is above the par learning experience than most fresh graduates I have encountered. When we hire in Eupope I would very interested to try and convince some of your juniors to join! > The startups I've been at had about 100K lines of code for their complete product. In other words, a lot of companies don't have a 1M+ codebase. Most large companies who are also large employers sadly do have such complexity. In a startup it may not a single repo at 100k+, however overall 100+k lines for the product is very low for Saas product over two-three years it easily goes beyond. My N=1 in a startup: we went from one monolithic 300-400k+ L repo to a ton of repos with each one perhaps < 100k . Traditional large codebases are not designed for releasing 4 times a day, even builds can take a lot of time [1], Smaller repos does not mean complexity goes away, developers need to still document, read and understand how it works. It applies also when you use libraries or third party services, while number of lines have become less, you need a lot more domain understanding. > be able to grok a explain analyse and fine tune a 500GB dB: No. We did learn SQL though and how to model relationships with UML and entity diagrams. The reality is that most jobs are not developing new apps from scratch, it is lot more likely to work on older codebase that has its fair share of kinks. That means I am going to throw you deep end into large sized DB. Schema perhaps has evolved over time as product vision keeps changing, a dozen 'architects' have messed about it. In a typical job, you will be fixing bugs more than developing new features, handling tech debt - it doesn't matter stupid mistakes were made before, you still to work with/around those mistakes as someone will have to work with yours. Even on theoretical level NoSQL is not well taught in universities. Purpose built dbs for graphing, Time Series, KV , document DBs, search indices are all important to really understand. Each has solutions to specific problem set and come with their limitations. In a typical basic storage stack there is going to probably be something like Redis|PostgreSQL|ElasticSearch: all of them solve more than one type of storage problem in more than one way. This isn't to say the that is it all bad. Education is evolving , universities are more open to longer internships, while most don't think software engineering (not CS) should be treated as vocational course, there are positive trends. Alternative learning avenues have opened up like Coding Schools and Bootcamps who do lot better job at focusing on job skills. [1] https://news.ycombinator.com/item?id=18442941 https://news.ycombinator.com/item?id=18442941 This is infamous post, and of course the extreme example, but you get the idea.