Did I dodge a bullet?
-
So, I've been applying to a couple of Tech Lead positions recently. I've been in Software development since 2008, and have worked with .NET since 2011. I went through several codebases throughout the years, and I have seen my fair share of atrocities done in codebases (including a critical software with 13 KLOC inside Program.cs). I believe that at least, nowadays, I know how NOT to screw things up. Recently, I had an interview with a big company in the restaurant management sector (with customers like Burger King and others in the same range). The interviewer asked me what I thought about the usage of Stored Procedures. I told them something along the lines of: "Well, they have their place. There might be situations worth considering their usage, but not always. E.g., Let's say you have a highly complex report that depends on several rounds of aggregations and calculations, and it is time critical, it might be worth considering the usage of Stored Procedures, instead of doing everything on the .NET codebase. Since the database has mechanisms to handle data better (indexes, query plans and whatnot) and it is closer to the data than the application, we could leverage these things to reduce the time needed to produce this specific report". Then, two days later, I got a rejection letter saying that my way of thinking was outdated, and that they do everything inside application code, so they would not move on with my application. So, my question is: Did I dodge a bullet, or did I in fact screw this up? How would you guys reply to this question if you were in my shoes?
-
So, I've been applying to a couple of Tech Lead positions recently. I've been in Software development since 2008, and have worked with .NET since 2011. I went through several codebases throughout the years, and I have seen my fair share of atrocities done in codebases (including a critical software with 13 KLOC inside Program.cs). I believe that at least, nowadays, I know how NOT to screw things up. Recently, I had an interview with a big company in the restaurant management sector (with customers like Burger King and others in the same range). The interviewer asked me what I thought about the usage of Stored Procedures. I told them something along the lines of: "Well, they have their place. There might be situations worth considering their usage, but not always. E.g., Let's say you have a highly complex report that depends on several rounds of aggregations and calculations, and it is time critical, it might be worth considering the usage of Stored Procedures, instead of doing everything on the .NET codebase. Since the database has mechanisms to handle data better (indexes, query plans and whatnot) and it is closer to the data than the application, we could leverage these things to reduce the time needed to produce this specific report". Then, two days later, I got a rejection letter saying that my way of thinking was outdated, and that they do everything inside application code, so they would not move on with my application. So, my question is: Did I dodge a bullet, or did I in fact screw this up? How would you guys reply to this question if you were in my shoes?
I don't believe that you were wrong in your answer. Stored Procedures are, as you say, closer to the database and so can be more efficient. They are also more secure - the only data that is passed are the parameters, and the only data that is returned is the resulting dataset. OTOH, making changes to Stored Procedures requires changes to the database. The DBA therefore becomes the critical path for any changes. (I assume that the programmers are working on their own development copy of the database, but the database instance is still the single point of change.) Doing the same work at the application's data level is much slower (the data must be read from the database, processed, and filtered), is less secure (tables must be open to reading/modification over the network, data must be passed over the network and is open to snooping), but the DBA is no longer on the critical path. This may be more important to some organizations than efficiency and security.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
So, I've been applying to a couple of Tech Lead positions recently. I've been in Software development since 2008, and have worked with .NET since 2011. I went through several codebases throughout the years, and I have seen my fair share of atrocities done in codebases (including a critical software with 13 KLOC inside Program.cs). I believe that at least, nowadays, I know how NOT to screw things up. Recently, I had an interview with a big company in the restaurant management sector (with customers like Burger King and others in the same range). The interviewer asked me what I thought about the usage of Stored Procedures. I told them something along the lines of: "Well, they have their place. There might be situations worth considering their usage, but not always. E.g., Let's say you have a highly complex report that depends on several rounds of aggregations and calculations, and it is time critical, it might be worth considering the usage of Stored Procedures, instead of doing everything on the .NET codebase. Since the database has mechanisms to handle data better (indexes, query plans and whatnot) and it is closer to the data than the application, we could leverage these things to reduce the time needed to produce this specific report". Then, two days later, I got a rejection letter saying that my way of thinking was outdated, and that they do everything inside application code, so they would not move on with my application. So, my question is: Did I dodge a bullet, or did I in fact screw this up? How would you guys reply to this question if you were in my shoes?
I'm not sure what you/they mean when you wrote "they do everything inside the application code" The reporting? If so, good thing you moved on. Also, it's rare and kind of off putting for an interviewer to say something like "your way of thinking is outdated" It tells me you've got a primadonna infestation in that team. When I interviewed for Expedia, some interviewer asked me to defend my lack of a BS degree. It was at that point that I responded "I just whiteboarded all of your problems, because while you were struggling through English lit to round out your requirements, I was coding, so defend your degree first - after all I didn't pay 80k for mine" I didn't get the job I didn't want at that point anyway.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
So, I've been applying to a couple of Tech Lead positions recently. I've been in Software development since 2008, and have worked with .NET since 2011. I went through several codebases throughout the years, and I have seen my fair share of atrocities done in codebases (including a critical software with 13 KLOC inside Program.cs). I believe that at least, nowadays, I know how NOT to screw things up. Recently, I had an interview with a big company in the restaurant management sector (with customers like Burger King and others in the same range). The interviewer asked me what I thought about the usage of Stored Procedures. I told them something along the lines of: "Well, they have their place. There might be situations worth considering their usage, but not always. E.g., Let's say you have a highly complex report that depends on several rounds of aggregations and calculations, and it is time critical, it might be worth considering the usage of Stored Procedures, instead of doing everything on the .NET codebase. Since the database has mechanisms to handle data better (indexes, query plans and whatnot) and it is closer to the data than the application, we could leverage these things to reduce the time needed to produce this specific report". Then, two days later, I got a rejection letter saying that my way of thinking was outdated, and that they do everything inside application code, so they would not move on with my application. So, my question is: Did I dodge a bullet, or did I in fact screw this up? How would you guys reply to this question if you were in my shoes?
I think your answer was correct, but it all depends on the situation of course and how the company's database is managed.
-
So, I've been applying to a couple of Tech Lead positions recently. I've been in Software development since 2008, and have worked with .NET since 2011. I went through several codebases throughout the years, and I have seen my fair share of atrocities done in codebases (including a critical software with 13 KLOC inside Program.cs). I believe that at least, nowadays, I know how NOT to screw things up. Recently, I had an interview with a big company in the restaurant management sector (with customers like Burger King and others in the same range). The interviewer asked me what I thought about the usage of Stored Procedures. I told them something along the lines of: "Well, they have their place. There might be situations worth considering their usage, but not always. E.g., Let's say you have a highly complex report that depends on several rounds of aggregations and calculations, and it is time critical, it might be worth considering the usage of Stored Procedures, instead of doing everything on the .NET codebase. Since the database has mechanisms to handle data better (indexes, query plans and whatnot) and it is closer to the data than the application, we could leverage these things to reduce the time needed to produce this specific report". Then, two days later, I got a rejection letter saying that my way of thinking was outdated, and that they do everything inside application code, so they would not move on with my application. So, my question is: Did I dodge a bullet, or did I in fact screw this up? How would you guys reply to this question if you were in my shoes?
So they want to change the ordering of data used for a report - they have to,change the app code, recompile, and redeploy - and they say your thinking is outdated ! I wouldn't want to work with them at any price. Walk away - and yes, I think you did dodge a bullet. :-D
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
-
So, I've been applying to a couple of Tech Lead positions recently. I've been in Software development since 2008, and have worked with .NET since 2011. I went through several codebases throughout the years, and I have seen my fair share of atrocities done in codebases (including a critical software with 13 KLOC inside Program.cs). I believe that at least, nowadays, I know how NOT to screw things up. Recently, I had an interview with a big company in the restaurant management sector (with customers like Burger King and others in the same range). The interviewer asked me what I thought about the usage of Stored Procedures. I told them something along the lines of: "Well, they have their place. There might be situations worth considering their usage, but not always. E.g., Let's say you have a highly complex report that depends on several rounds of aggregations and calculations, and it is time critical, it might be worth considering the usage of Stored Procedures, instead of doing everything on the .NET codebase. Since the database has mechanisms to handle data better (indexes, query plans and whatnot) and it is closer to the data than the application, we could leverage these things to reduce the time needed to produce this specific report". Then, two days later, I got a rejection letter saying that my way of thinking was outdated, and that they do everything inside application code, so they would not move on with my application. So, my question is: Did I dodge a bullet, or did I in fact screw this up? How would you guys reply to this question if you were in my shoes?
Cezar Lamann wrote:
Did I dodge a bullet
Yes. Your response of the use of DB stored procedures being situational was correct, them assuming that you were a proponent of using SPs all the time is their mistake and pretty stupid. There also maybe a person in the team who could've been your peer or worse, superior who do things their way and won't change for whatever reason. Keep miles away.
-
I'm not sure what you/they mean when you wrote "they do everything inside the application code" The reporting? If so, good thing you moved on. Also, it's rare and kind of off putting for an interviewer to say something like "your way of thinking is outdated" It tells me you've got a primadonna infestation in that team. When I interviewed for Expedia, some interviewer asked me to defend my lack of a BS degree. It was at that point that I responded "I just whiteboarded all of your problems, because while you were struggling through English lit to round out your requirements, I was coding, so defend your degree first - after all I didn't pay 80k for mine" I didn't get the job I didn't want at that point anyway.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
asked me to defend my lack of a BS degree.
That is entirely stupid line of interviewing. So, interviewer just wants to have an argument about, "Is it necessary to have a college degree?"
honey the codewitch wrote:
"I just whiteboarded all of your problems, because while you were struggling through English lit to round out your requirements, I was coding, so defend your degree first - after all I didn't pay 80k for mine"
:thumbsup: Of course there can be value in a college degree, but there is nothing that 100% proves you'll be a good dev anyways. Maybe they should make their litmus test: Have you read the entire The Art of Computer Programming by Knuth?
-
I'm not sure what you/they mean when you wrote "they do everything inside the application code" The reporting? If so, good thing you moved on. Also, it's rare and kind of off putting for an interviewer to say something like "your way of thinking is outdated" It tells me you've got a primadonna infestation in that team. When I interviewed for Expedia, some interviewer asked me to defend my lack of a BS degree. It was at that point that I responded "I just whiteboarded all of your problems, because while you were struggling through English lit to round out your requirements, I was coding, so defend your degree first - after all I didn't pay 80k for mine" I didn't get the job I didn't want at that point anyway.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Self-taught? So am I. What is a BS degree anyway? It's a directed learning path, with some discussion, a bunch of lecturing, a lot of book reading, and a little experimentation. That's something we can do entirely on our own without spending $80K on it. Hell, we can even get the same/updated books, keep them to boot, and not spend the kind of money on them the students are getting fleeced for! Of course, we do a lot more work experimenting and learning, but that's the fun part! The only downside is a lack of feedback on our work.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles. Dave Kreskowiak
-
So, I've been applying to a couple of Tech Lead positions recently. I've been in Software development since 2008, and have worked with .NET since 2011. I went through several codebases throughout the years, and I have seen my fair share of atrocities done in codebases (including a critical software with 13 KLOC inside Program.cs). I believe that at least, nowadays, I know how NOT to screw things up. Recently, I had an interview with a big company in the restaurant management sector (with customers like Burger King and others in the same range). The interviewer asked me what I thought about the usage of Stored Procedures. I told them something along the lines of: "Well, they have their place. There might be situations worth considering their usage, but not always. E.g., Let's say you have a highly complex report that depends on several rounds of aggregations and calculations, and it is time critical, it might be worth considering the usage of Stored Procedures, instead of doing everything on the .NET codebase. Since the database has mechanisms to handle data better (indexes, query plans and whatnot) and it is closer to the data than the application, we could leverage these things to reduce the time needed to produce this specific report". Then, two days later, I got a rejection letter saying that my way of thinking was outdated, and that they do everything inside application code, so they would not move on with my application. So, my question is: Did I dodge a bullet, or did I in fact screw this up? How would you guys reply to this question if you were in my shoes?
Yeah, you dodged a bullet. You even told them why it's better than doing it in-code. It seems they've forgotten why you don't do everything in-code. Their way seems to be a pile of security holes with performance issues. They may also be trying to save money on IT operations by skipping the DBA's required to write and maintain the databases and their SQL code. Congratulations, Neo.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles. Dave Kreskowiak
-
So, I've been applying to a couple of Tech Lead positions recently. I've been in Software development since 2008, and have worked with .NET since 2011. I went through several codebases throughout the years, and I have seen my fair share of atrocities done in codebases (including a critical software with 13 KLOC inside Program.cs). I believe that at least, nowadays, I know how NOT to screw things up. Recently, I had an interview with a big company in the restaurant management sector (with customers like Burger King and others in the same range). The interviewer asked me what I thought about the usage of Stored Procedures. I told them something along the lines of: "Well, they have their place. There might be situations worth considering their usage, but not always. E.g., Let's say you have a highly complex report that depends on several rounds of aggregations and calculations, and it is time critical, it might be worth considering the usage of Stored Procedures, instead of doing everything on the .NET codebase. Since the database has mechanisms to handle data better (indexes, query plans and whatnot) and it is closer to the data than the application, we could leverage these things to reduce the time needed to produce this specific report". Then, two days later, I got a rejection letter saying that my way of thinking was outdated, and that they do everything inside application code, so they would not move on with my application. So, my question is: Did I dodge a bullet, or did I in fact screw this up? How would you guys reply to this question if you were in my shoes?
I think you gave the best answer. I also prefer to have the code in the application rather than the database, but I consider the particular situation.
-
I'm not sure what you/they mean when you wrote "they do everything inside the application code" The reporting? If so, good thing you moved on. Also, it's rare and kind of off putting for an interviewer to say something like "your way of thinking is outdated" It tells me you've got a primadonna infestation in that team. When I interviewed for Expedia, some interviewer asked me to defend my lack of a BS degree. It was at that point that I responded "I just whiteboarded all of your problems, because while you were struggling through English lit to round out your requirements, I was coding, so defend your degree first - after all I didn't pay 80k for mine" I didn't get the job I didn't want at that point anyway.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Any time I hear stuff like this it reminds me of an interview with Scientific Atlanta. At the time I was a pure C coder, dabbled in C++ and I could spell object oriented. This was back in the day when companies spent BILLIONS making sure it was all designed OO and never produced anything. The techies were great, I answered all of their questions, actually debugged a problem that had been plaguing them, but the PM and the architect were two of the most pretentious pricks I ever had the displeasure to meet.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
I'm not sure what you/they mean when you wrote "they do everything inside the application code" The reporting? If so, good thing you moved on. Also, it's rare and kind of off putting for an interviewer to say something like "your way of thinking is outdated" It tells me you've got a primadonna infestation in that team. When I interviewed for Expedia, some interviewer asked me to defend my lack of a BS degree. It was at that point that I responded "I just whiteboarded all of your problems, because while you were struggling through English lit to round out your requirements, I was coding, so defend your degree first - after all I didn't pay 80k for mine" I didn't get the job I didn't want at that point anyway.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
It was at that point that I responded "I just whiteboarded all of your problems, because while you were struggling through English lit to round out your requirements, I was coding, so defend your degree first - after all I didn't pay 80k for mine"
HA! That's awesome.
-
So, I've been applying to a couple of Tech Lead positions recently. I've been in Software development since 2008, and have worked with .NET since 2011. I went through several codebases throughout the years, and I have seen my fair share of atrocities done in codebases (including a critical software with 13 KLOC inside Program.cs). I believe that at least, nowadays, I know how NOT to screw things up. Recently, I had an interview with a big company in the restaurant management sector (with customers like Burger King and others in the same range). The interviewer asked me what I thought about the usage of Stored Procedures. I told them something along the lines of: "Well, they have their place. There might be situations worth considering their usage, but not always. E.g., Let's say you have a highly complex report that depends on several rounds of aggregations and calculations, and it is time critical, it might be worth considering the usage of Stored Procedures, instead of doing everything on the .NET codebase. Since the database has mechanisms to handle data better (indexes, query plans and whatnot) and it is closer to the data than the application, we could leverage these things to reduce the time needed to produce this specific report". Then, two days later, I got a rejection letter saying that my way of thinking was outdated, and that they do everything inside application code, so they would not move on with my application. So, my question is: Did I dodge a bullet, or did I in fact screw this up? How would you guys reply to this question if you were in my shoes?
There was one thing you said that would've made me worry too, but I suspect you dodged a bullet. Here's the proper answer to that question... To give you context, I've been in this game since the 90s... 94 is when I started coding and 97 I was working as a coder. Anyway, this being the Internet expect less experienced people to disagree with what I'm about to say... ignore them. But, the proper answer to that question is: It depends. :) To start with, no expert DBA will accept a code first answer even if you're using an ORM, etc. Only coders that refuse to learn DBs buy into that. Don't ever buy into code first UNLESS they talk about migrations. Then they're smart. But, you can (and should) do migrations in raw SQL. So, that's not an excuse to not learn DBs or DB design. Otherwise, they're mentally lazy, but I digress. So, it would be nice to know "why" they believe their buzzword nonsense. When to use a sproc (stored procedure) * When you need custom logic to run that's too big for a db function. Say maybe in response to a trigger or you want to scaffold out something, etc. Never put this logic in code. Yes it's slower than code, but now you tightly coupled your DB to your code. Good luck reusing that DB. Not to mention, you may potentially have to transfer large amounts of data over the wire, which I can promise will be slower if you have a decent server not under heavy load. That's it. That's the only reason. People will talk about security, but a view or function will do the same thing. When not to use a sproc (stored procedure) * Don't use a sproc when a DB function would do the job. DB functions are meant to be concise and point driven. * Not for encapsulation/security. That's what a view is for. * Not for complex reporting. I suspect this is what made them potentially not like your answer. Sprocs are slow. Reporting is slow. A performant DB should have separate, flattened, read-only reporting DB for complex operations. Now, all of this is invalidated if we're talking about distributed computing, using NoSQL, etc. Maybe that's their case, but it sounds like they're just following the hype train. This may also be invalidated if we're working with complex graphs in GraphQL. So, this assumes we're speaking of the traditional client/server paradigm. Edit: Take away point!!!! Here's the important thing though, if they were smart enough to know the good reasons to break the mold... they would've mentioned in the interview. If they didn't, they're just probably clowns or ca
-
honey the codewitch wrote:
It was at that point that I responded "I just whiteboarded all of your problems, because while you were struggling through English lit to round out your requirements, I was coding, so defend your degree first - after all I didn't pay 80k for mine"
HA! That's awesome.
I had a mouth on me in my twenties. :laugh:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
There was one thing you said that would've made me worry too, but I suspect you dodged a bullet. Here's the proper answer to that question... To give you context, I've been in this game since the 90s... 94 is when I started coding and 97 I was working as a coder. Anyway, this being the Internet expect less experienced people to disagree with what I'm about to say... ignore them. But, the proper answer to that question is: It depends. :) To start with, no expert DBA will accept a code first answer even if you're using an ORM, etc. Only coders that refuse to learn DBs buy into that. Don't ever buy into code first UNLESS they talk about migrations. Then they're smart. But, you can (and should) do migrations in raw SQL. So, that's not an excuse to not learn DBs or DB design. Otherwise, they're mentally lazy, but I digress. So, it would be nice to know "why" they believe their buzzword nonsense. When to use a sproc (stored procedure) * When you need custom logic to run that's too big for a db function. Say maybe in response to a trigger or you want to scaffold out something, etc. Never put this logic in code. Yes it's slower than code, but now you tightly coupled your DB to your code. Good luck reusing that DB. Not to mention, you may potentially have to transfer large amounts of data over the wire, which I can promise will be slower if you have a decent server not under heavy load. That's it. That's the only reason. People will talk about security, but a view or function will do the same thing. When not to use a sproc (stored procedure) * Don't use a sproc when a DB function would do the job. DB functions are meant to be concise and point driven. * Not for encapsulation/security. That's what a view is for. * Not for complex reporting. I suspect this is what made them potentially not like your answer. Sprocs are slow. Reporting is slow. A performant DB should have separate, flattened, read-only reporting DB for complex operations. Now, all of this is invalidated if we're talking about distributed computing, using NoSQL, etc. Maybe that's their case, but it sounds like they're just following the hype train. This may also be invalidated if we're working with complex graphs in GraphQL. So, this assumes we're speaking of the traditional client/server paradigm. Edit: Take away point!!!! Here's the important thing though, if they were smart enough to know the good reasons to break the mold... they would've mentioned in the interview. If they didn't, they're just probably clowns or ca
I got your point. And the infamous "It depends" is what I really wanted to say (maybe I should have started my answer with this instead of "Well, sprocs have their place". I wouldn't blindly rule out a sproc, without knowing what is in front of me and what I should do, functionality-wise (like your last sentence - "all of this is invalidated if we're talking about distributed computing. This may also be invalidated if we're working with complex graphs in GraphQL"). Of course, I would NOT do, in this day and age, just use the .NET code as a shim for exposing sprocs and have the whole business logic in the DB (yes, I worked in an ASP Classic project, that was like this, and I hated every single second I worked on that project). I have also done my fair share of data warehousing and CQRS, and I understand that for OLAP workloads, a separate DB with denormalized tables/materialized views (e.g. "star schemas") can do wonders. Heck, I even ask this kind of question when I'm on the interviewer side (e.g. for senior dev positions), to filter out the ones that are 100% on Sproc side or 100% on code-only side. In other words, I knew how to answer this. But to get a rejection based on this (maybe other non-disclosed things as you mentioned), has bummed me out.
-
I had a mouth on me in my twenties. :laugh:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
So, I've been applying to a couple of Tech Lead positions recently. I've been in Software development since 2008, and have worked with .NET since 2011. I went through several codebases throughout the years, and I have seen my fair share of atrocities done in codebases (including a critical software with 13 KLOC inside Program.cs). I believe that at least, nowadays, I know how NOT to screw things up. Recently, I had an interview with a big company in the restaurant management sector (with customers like Burger King and others in the same range). The interviewer asked me what I thought about the usage of Stored Procedures. I told them something along the lines of: "Well, they have their place. There might be situations worth considering their usage, but not always. E.g., Let's say you have a highly complex report that depends on several rounds of aggregations and calculations, and it is time critical, it might be worth considering the usage of Stored Procedures, instead of doing everything on the .NET codebase. Since the database has mechanisms to handle data better (indexes, query plans and whatnot) and it is closer to the data than the application, we could leverage these things to reduce the time needed to produce this specific report". Then, two days later, I got a rejection letter saying that my way of thinking was outdated, and that they do everything inside application code, so they would not move on with my application. So, my question is: Did I dodge a bullet, or did I in fact screw this up? How would you guys reply to this question if you were in my shoes?
-
I had a mouth on me in my twenties. :laugh:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
honey the codewitch wrote:
asked me to defend my lack of a BS degree.
That is entirely stupid line of interviewing. So, interviewer just wants to have an argument about, "Is it necessary to have a college degree?"
honey the codewitch wrote:
"I just whiteboarded all of your problems, because while you were struggling through English lit to round out your requirements, I was coding, so defend your degree first - after all I didn't pay 80k for mine"
:thumbsup: Of course there can be value in a college degree, but there is nothing that 100% proves you'll be a good dev anyways. Maybe they should make their litmus test: Have you read the entire The Art of Computer Programming by Knuth?
raddevus wrote:
Maybe they should make their litmus test: Have you read the entire The Art of Computer Programming by Knuth?
I own and have read all four volumes. Knuth simply isn't that good outside the theoretical arena, using mathematical syntax and making APL look readable. (Yes, I wrote some in APL back in high school.) There are far better books on the same subjects.
-
I'm not sure what you/they mean when you wrote "they do everything inside the application code" The reporting? If so, good thing you moved on. Also, it's rare and kind of off putting for an interviewer to say something like "your way of thinking is outdated" It tells me you've got a primadonna infestation in that team. When I interviewed for Expedia, some interviewer asked me to defend my lack of a BS degree. It was at that point that I responded "I just whiteboarded all of your problems, because while you were struggling through English lit to round out your requirements, I was coding, so defend your degree first - after all I didn't pay 80k for mine" I didn't get the job I didn't want at that point anyway.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Not exactly the same situation, but I had something similar. At the beginning one guy (tech guru of the dept.) was getting really annoying with questions and arguments against me. I just stood up and said: "Up to this point, I do not care if you take me, I don't want to work with such a guy" and left. 2 years later, job was still not occupied... what a surprise!
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
