Shirec posted:

I'm already on thin ice because the last refactor (the code I mentioned from last week? I think) ended up having unexpected results because it was so quick it was calling the api before the first section was done (the first section is required to be done on a separate platform before the second can fire but he wants it all done async).

baquerd posted:

Are you using callbacks or status polling endpoints? The guy is a dick but this is a reasonable problem that should have been foreseen or caught.

geeves posted:

Mapping data from one structure to another for the presentation view (or any other reason)? That's just common software engineering / CRUD-style development. I would think this will be more common these days with and without Node.js as a backend service.

I'd be interested in knowing what the questions were from the test. Database design and basic SQL, JOIN, GROUP BY is really good knowledge to have and how to use SQL, how to further write algorithms to transmogrify data into its final form for your DumbReactComponentList is just good stuff to know regardless of language and will help communication between front-end and back-end speak. We have a few services that just spit out raw Solr JSON and it's all front-end heavy to get this data and map/reduce/filter it to what is actually needed to display correctly.

The JS world wanted to have their language work on a server and have connections to mysql, mongo, etc. Well, these could be the consequences for the industry because of it. It's possible to think that more can be expected of the day-to-day JS developer.

Grump posted:

I don't want to give away too much in case someone does detective work to find the company, but one of the questions that was particularly hard was one the dealt with combining hashes, but there were a bunch of conditionals to how they had to be merged.

For example, you have two objects

JavaScript code:

{
    key1: [2, 3, 5, 6],
    key2: 'hello world',
    key3: {
        sub1: 1,
        sub2: [25, 6, 5]
    }
}

{
    key1: [3, 5, 6],
    key2: 'foo bar',
    key3: {
        sub1: 5,
        sub2: [3,5,6]
    },
    key4: 'baz'
}

if the value in an array, concat the array from the second object onto the array of the first
if the value is an string or number, use the value from the second object
if the value is another object, iterate over that object. previous rules apply

so the result needs to look something like this

JavaScript code:

{
    key1: [2, 3, 5, 6, 25, 6, 5],
    key2: 'foo bar'
    key3: {
        sub1: 5,
        sub2: [25, 6, 5, 3, 5, 6]
    },
    key4: 'baz'
}

This question really humbled the poo poo out of me because I realized that I'm not great with recursive functions and combining objects.

Grump posted:

code ...

Shirec posted:

I wasn't originally because I was sending the information grouped up so that it would be bundled with all the sections together. The last re-factor where he basically told me exactly what to do, I didn't think of it until I started testing. I agree it was something I should have thought of, but to be fair, the end points were being created for me to call so I was testing blind for most of last week until it got completed.

edit: Oh god, am I a lovely programmer? I know I'm really new but god drat, maybe it is me

dantheman650 posted:

I do almost exclusively front end these days and while this specific example out of any context might seem contrived it�s really important to be able to do things like this for front end work. The data coming from the API will often not have a structure that makes it easy for you to map it to the designs and you should be pretty comfortable manipulating it in this sort of manner. If you practice a bit you�ll get it!

Che Delilas posted:

First, hindsight is 20/20. "I should have thought of that" is an understandable reaction but a better one is, "Oh I didn't think of that. Let's fix it."

Second you are not a lovely programmer because you made a mistake or didn't think of something. You're going to write lots and lots of bugs in your career, I promise. Furthermore, if you have a fixed deadline and a nonexistent or bad testing/QA process (which is the fault of your organization, not you personally), lots and lots of bugs are going to get into production. That's a fact. You can try and improve that but I wouldn't waste your time at that job.

AAAAA! Real Muenster posted:

huhu posted:

Part rant part question...

I've been learning/doing web dev for about 3 years now and I'd say I have a pretty solid understanding of lots of disparate concepts. However, I still struggle with random interview questions like what does REST mean or what is the difference between HTTP/1.1 and HTTP/2.0. For REST, I spend most of my time building with Django REST Framework so I'm like I know this I just don't know the vocab for it. For the HTTP thing, I spent less than 5 minutes watching a tutorial and I'm like yeah, that totally makes sense and I understand the pain points of HTTP/1.1 all too well. But in the last week I've lost a final round interview and a second round interview on questions like that. Do you guys have any strategies for dealing/explaining this in an interview? I feel like the answer is probably to just browse a bunch of top X questions for FS web devs and answer all of them. Any other tips? I kind of want to avoid spending hours reading up on arcane crap when I could be learning more interesting stuff but perhaps I just have to do that.

huhu posted:

Collection of random thoughts...

It sounds like you don't quite know what you want to do. What you need to build an app versus a backend website, are similar but vastly different. It definitely took me time to figure out exactly what I wanted to do. I don't think best jumping all over the place might be the best idea though.

Also, getting stuck on difficult concepts is a common part of programming. I feel like each new problem I encounter is just a difficult as the last, it's more about building a skillset to solve them.

One strategy I have whenever I don't understand something is to break it down. Then look up each piece I don't understand and repeat until I understand it all and build everything back up to understand the original issue.

lifg posted:

What concepts are causing you trouble?

Most people learn programming by jumping into a beginners course on something they like. If you enjoy Android development, continue that. If you need SQL for work, learn that too. Then it�s a matter of steadily broadening your knowledge to cover related areas.

CS50 looks like a broad introduction to the field. I love stuff like that, and it will definitely teach you how to think like a computer scientist. If you�re sure this is what you want to do, it sounds like a strong way to start your education. But it�s definitely not the only way to become a programmer.

The Dark Wind posted:

I'm one of those people who keeps recommending CS50 on this thread, and this post is no different.

The first half is devoted to a lot of foundational stuff. You'll look at C, some algorithms (tries, BSTs, stacks, queues, etc.), and do a couple of pretty challenging projects.

The second half is all in Python with Flask + SQLite (and some JavaScript front end stuff) so you'll get some basic experience writing simple SQL queries and hooking that up to a web app. I think they do a fantastic job of pushing you into it without holding your hand, but without leaving you completely floundering either. If your company is doing web work/you're interested in web dev, then I think this is a great way of getting a good taste of both the fundamentals and the more higher level topics. Definitely give it a look if you feel that this would be right for you!

AAAAA! Real Muenster posted:

My problem is that I feel like some of these things are things that I should have already known had I earned a CS degree.

AAAAA! Real Muenster posted:

It seems like based on what I am saying is giving me trouble and what you guys are saying about the CS50 course, I should really start with that.

AAAAA! Real Muenster posted:

Simple things like "why is the file laid out this way" and "Is this layout or format a language specific thing, or is it a general rule?"

downout posted:

I end up just spending an hour before I start applying for new jobs and just straight memorize a bunch of the most common principles and definitions. I do a quick five minute refresh before any in-person tech interviews. I've generally got the book answer ready, so during the interview I can get to describing implementing or using the concept in various projects.

I'm not a fan of rote learning, but it's worked best for me for the five to ten same questions/concepts of every interview.

Grump posted:

Not really sure how I�m getting a raise and a promotion after being told I�m bad at my job???

quote:

Time to ASAP

Capri Sun Tzu posted:

In the real world, if you don't know something you spend 15 minutes on google/stack overflow/whatever relevant docs and you educate yourself as needed for what you're trying to accomplish. What is the purpose in asking questions that could be solved this way? It seems like you're just testing if they're good at interviews, not if they're good at the actual job.

Capri Sun Tzu posted:

In the real world, if you don't know something you spend 15 minutes on google/stack overflow/whatever relevant docs and you educate yourself as needed for what you're trying to accomplish. What is the purpose in asking questions that could be solved this way? It seems like you're just testing if they're good at interviews, not if they're good at the actual job.

Steve French posted:

Also, if you need to take 15 minutes on Stack Overflow to answer a bunch of basic questions for yourself that a solid developer is going to already know the answer to in basically no time at all, you aren't going to be that effective. Yes, trivia questions are lovely for interviews, but knowing the difference between a list and a set is not one of those.

3D GAY WORLD posted:

Also, if you take the argument of "you don't need to know it if you can google it and learn it in 15 mins" to it's furthest conclusion, it'd mean that human beings would basically not need to know much of anything, other than how to google things.

3D GAY WORLD posted:

human beings would basically not need to know much of anything, other than how to google things.

Joda posted:

I couldn't tell you the difference between a set and a list until I looked it up during this discussion, simply because I was unfamiliar with the terminology. And that's after 5 years of studying and programming. I still use them correctly in my work as far as I can tell, I was just not familiar with the abstractions, since I've never come across them in my studies.

Portland Sucks posted:

What do your studies consist of? This is not normal for someone who has studied computer science for 5 years.

Volguus posted:

To be fair, knowing where to look for answers is a skill in and of itself.

3D GAY WORLD posted:

Good point. I can't begin to count the number of times that someone I knew tried to find an answer to a question, only to spend 10 minutes searching and then come up with nothing (or worse yet, not even bothering to google it, and instead ask random people if they know). Then they mention their question to me, I whip out my phone and have the answer in under a minute.

People seem to be extremely bad at understanding how to use key words and omitting the useless bits, let alone actually searching for exact matches and other more advanced features.