They did something with property titles, and honestly can't recall the name of the company. It was a super fast call me and come in interview.

Haven't programmed professionally in six years, all of my background is an unrelated sector (game dev), and no references. Applied for a job for the first time in four years as the work seems worthwhile and I wouldn't have to relocate.

For those of you concerned with massive resume gaps, stay tuned for the inevitable conclusion to this exciting story.

I had a 6-7 year resume gap and got the first job I interviewed for, which was the second one I had applied for. I hit a guy who liked to hire "misfits" as he put it, i.e. people who have struck out on their own and done something unusual (poker in my case).

I'm making a portfolio / resume website for my cs 401 class right now lol.

This brings me to why I'm posting. Say I have a container with a bunch of .. well I'll just show you:


That, when the window is large enough such that my site is at its max horizontal width, they all line up in 3 per row.

I also want them to float over when the window resizes thinner like they do now:



So that when the window is thin, all you have is a vertical scroll and no horizontal scroll.


What is the "standard" way of going about this? (for the max-window width part, I mean. to get them lined up in thirds, evenly spaced, but still floating left so resize pops them down to 2 per row, and resize to tiny thin pops them down to 1 per row)

Currently, I am sizing my images to were I like them, floating all the divs that contain a description at the top and image below it to the left, and guess-checking a left & right margin value that lines them all up nicely when the window is at its max size (css stuff). Is this an okay solution to my problem? Is there a more "industry standard" solution to this problem?

Edit: I just realized this solution wont work for another page I have. The concept is the same: pictures with a title over them, 3 per row at max-width, then 2 per row, then 1 per row as window width goes down. On this other page, however, the total number of items (divs with a description over them and picture underneath) is dynamically-created from a database. The look is the same, but I wont have individual divs to do css guess-checks with because each div item will be dynamically created. Any ideas on a solution?

Thanks in advance for any responses xD

tl;dr

Bootstrap or zurb foundation or both

its a web dev class lol, cant do that. supposed to be learning css etc

He's correct though that the "industry standard" solution to stuff like this is Bootstrap.

Say you have something like this:

If you just want the container horizontally centered and fluid there are many ways of doing that, most simply setting text-align: center on its parent and display: inline-block plus a max-width on the container. Float the items left inside the container.

The problem is that your items will be left-aligned inside the container, and therefore won't look centered on screen unless the container happens to be the width of x items. Making the items "floating, but centered" and thus achieving the "responsive grid" look you want is very difficult in pure CSS. You pretty much have to use the @media directive and resize the container at different screen widths. The difficulty of doing these sort of grid layouts is exactly why things like Bootstrap and Foundation exist.

Oh, in that case I'd bet the answer lies in your class's book. I know that was the case for me when I took a similar class and we had to do some responsive design which I'm promptly forgot because front end design is terrible and also bootstrap exists.

Can you still play on Stars in AUS?

Assume so. Havent played poker in 2+ years.

This worked great xD

I've been so bored lately. I wish I had that option.

edit: nvm

Yeah I've been railing my canadian friend about once a week for the last few months, nostalgia for the pre-black-friday days xD

Any of you guys ever have to go research a particular data structure and then have to code it up from scratch?

Usually I am pretty good at looking at psueocode and converting it to real code. But man I think I finally hit the wall with suffix trees. I understand what suffix trees are, but the O(n) ukkonen's method for constructing it, is such a hard thing to wrap my head around. I have read a few stackoverflow posts explaining it, and also research papers but my head still hurts.

People always seem to talk about how knowing all your algorithms inside and out is super important but how true is that really? How often do you really put them to use?

Like a lot of things taught in academic CS, they are very useful in a minority of jobs in the industry and utterly useless in the majority of jobs.

Interviews. Whiteboards, HankerRank, things like that.

Seriously, not that much. Hiring outfits that emphasize "knowing your algorithms inside and out" seem to bring this up for the purposes of evaluating job candidates mostly but ymmv. The idea i think is to evaluate cognitive skills. A developer with a long work history can be a lot less productive than a developer that is relatively inexperienced but has superior cognitive skills. That is the way the thinking goes with hiring outfits in my view. Are the tests imperfect? Sure. How effective are they? My guess is that they are mostly not effective but not sure at this point. A lot of this seems to "seat of the pants" to me but I could be convinced otherwise.

With the amount of $ being invested in software development I would the process of evaluating cognitive skills that developers have to evolve and improve.

Isn't that what triplebyte is trying to do to some extent?

Give hiring managers the ability to decide which traits they desire most and hire out of pools of candidates with those traits

If anyone wants to check out my web game I'm having an alpha event in a few days most likely, pm me your email.

Not sure, will have a look

http://blog.triplebyte.com/triplebyt...genome-project

Start here imo

I don't think people should have to memorize algorithms inside and out. But I think it is valuable to be somewhat aware of what stuff is out there. That way you know what to look up when you need tackle a particular problem.

For example, in my file compression project, I have to do some kind of pattern matching during the compression of a file. The naive way would be to do a O(n*p) searching, and even something like a (n+p) KMP string matching runs awfully slow. It takes me like 5 mins to compress a 20 megabyte file. n is size of the text you are searching, p is the length of the pattern.

I think what I will try next is some kind of AVL tree since that seems a little bit easier to code. It should hopefully be better than linear searching. Will have to work out the math to make sure it is faster before coding it. The worst thing that can happen is that I spend a whole day writing this only to find out the benchmarks for file compression is the same or even worst.

With all that being said, I don't think I will ever have to do this deep of an analysis outside in the real world since most jobs are just working on CRUD apps.

Yea I heard they do blind interviews, meaning they don't even look at someone's credentials.

The blog post specifically mentions algorithms. FWIW, that test is the most difficult one I've ever done.

find in an avl should run in O(log(n))